From noreply@sourceforge.net Tue Jul 1 01:13:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 17:13:50 -0700 Subject: [Patches] [ python-Patches-763111 ] mbcs encoding should skip encodings package Message-ID: Patches item #763111, was opened at 2003-06-30 20:33 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763111&group_id=5470 Category: Windows Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: mbcs encoding should skip encodings package Initial Comment: PyUnicode_Decode and PyUnicode_AsEncodedString should have a "short circuit" for the 'mbcs' encoding, as already exists for "utf8" and "latin1" and "ascii". This prevents Win9x from using the encodings module for all os.* functions with unicode support. This also adds PyUnicode_AsMBCSString, which was declared but not implemented. If no objections within a few days, I will check this in. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-07-01 10:13 Message: Logged In: YES user_id=14198 Checking in unicodeobject.c; new revision: 2.190; previous revision: 2.189 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-07-01 02:14 Message: Logged In: YES user_id=38388 Looks good. Please check it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763111&group_id=5470 From noreply@sourceforge.net Tue Jul 1 01:18:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 17:18:28 -0700 Subject: [Patches] [ python-Patches-763580 ] Minor enhancements to Variable class Message-ID: Patches item #763580, was opened at 2003-06-30 17: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=763580&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Nobody/Anonymous (nobody) Summary: Minor enhancements to Variable class Initial Comment: Here are two enhancements to the Variable class (and subclasses): 1) Variables now have a "name" argument. This works just like the name argument on almost every other Tkinter class. Its primary purpose is to allow the user to create a new Tkinter Variable given its tk name. Justification: at present there is no reasonable way to do this. One can create a new Tkinter Variable and then assign its name property, but that relies on knowing about internals and it has the ugly side effect of creating an unused tk variable I admit that setvar and getvar can be used to work around the problem, but sometimes it's nicer to use a Tkinter Variable and often it's not convenient to pass the original Variable around to where it's needed. One can get an original Tkinter widget back again given the corresponding tk widget's name. It's time to allow this for Tkinter Variables (and tkFont.Font objects, but that's a separate issue I submitted as a bug report with associated suggested simple fix). 2) Variables now have a "value" argument to specify the initial value. This shortens: avar = StringVar() avar.set("desired value") to: avar = StringVar("desired value") Justification: it's useful. It's also harmless in that it will not break any existing code. I think one can even do something like this in tcl (i.e. define a variable and set it at the same time) and it's certainly a normal thing to do in Python itself. -- Russell ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763580&group_id=5470 From noreply@sourceforge.net Tue Jul 1 04:09:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 20:09:48 -0700 Subject: [Patches] [ python-Patches-759208 ] curses has_key emulation fix Message-ID: Patches item #759208, was opened at 2003-06-23 07:14 Message generated for change (Comment added) made by mwichmann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=759208&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Mats Wichmann (mwichmann) Assigned to: Nobody/Anonymous (nobody) Summary: curses has_key emulation fix Initial Comment: curses/has_key.py provides emulation for the ncurses has_key routine for those that don't have it. Out-of- range has_key requests cause a KeyError exception. Note that the curses regression test makes such a request! The attached trivial patch makes has_key more robust. ---------------------------------------------------------------------- >Comment By: Mats Wichmann (mwichmann) Date: 2003-06-30 21:09 Message: Logged In: YES user_id=53605 I certainly have no objection to the logic change, but don't have time right now to gen a new patch. Should be an easy manual change. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-30 10:11 Message: Logged In: YES user_id=6380 Looks harmless to me. Somebody please check this in. (Personally, I'd change the logic around so it reads: if not _capability_names.has_key(ch): return 0 ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=759208&group_id=5470 From noreply@sourceforge.net Tue Jul 1 04:47:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 20:47:06 -0700 Subject: [Patches] [ python-Patches-757997 ] Using __slots__ with str derived classes can cause segfault Message-ID: Patches item #757997, was opened at 2003-06-20 12:28 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=757997&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 7 Submitted By: John Ehresman (jpe) >Assigned to: Guido van Rossum (gvanrossum) Summary: Using __slots__ with str derived classes can cause segfault Initial Comment: The following results in a segfault on Linux with 2.3b1: ------------------------- class StringDerived(str): __slots__ = ['a'] def __init__(self, string): str.__init__(self, string) self.a = 1 class DerivedAgain(StringDerived): pass o = DerivedAgain('hello world') o.b = 2 -------------------------- Python 2.2.2 raises a TypeError when attempting to derive a class from str with a non-empty __slots__, maybe 2.3 should do the same? I have no use case for deriving from str and defining __slots__; I encountered the bug when writing test cases for a debugger. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-20 18:05 Message: Logged In: YES user_id=33168 Ain't testing grand. Found a couple more problems. Patch 2 is better, but I'm still not sure it's complete or correct. I'm thinking the slot offset should be fixed when it's set, rather than at each usage of the slot offset. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-20 17:23 Message: Logged In: YES user_id=33168 I think the problem is that strings are variable length. clear_slots() doesn't handle this condtion. The attached patch fixes the crash and works fine under valgrind, but I'm not entirely sure it's correct. Hopefully someone more familiar with the TypeObject code can review this. I'll add a test later. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-20 13:18 Message: Logged In: YES user_id=33168 unicode, list, and dict don't crash, only string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=757997&group_id=5470 From noreply@sourceforge.net Tue Jul 1 06:08:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 22:08:15 -0700 Subject: [Patches] [ python-Patches-762963 ] timemodule.c: Python loses current timezone Message-ID: Patches item #762963, was opened at 2003-06-29 21:18 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762963&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Doug Quale (quale) >Assigned to: Brett Cannon (bcannon) Summary: timemodule.c: Python loses current timezone Initial Comment: Python routines in timemodule.c sometimes force glibc to use GMT instead of the correct timezone. I think this is a longstanding bug, but I have only looked at Python 2.2 and 2.33b1. This bug has been reported before (510218) but it was misdiagnosed and closed. It also came up recently in on the python-list (http://aspn.activestate.com/ASPN/Mail/Message/python-list/1564384) where it was also misdiagnosed. Standard C and Python use a struct tm with 9 values. BSD influenced C libraries like glibc have an extra field (tm_gmtoff) that keeps the offset from UTC. BSD-style struct tm values know the correct timezone associated with the time, but Python and Standard C struct tm values don't so they can only assume the current timezone. Ideally Python would always treat stuct tm-style time tuples as being associated with the current timezone. Unfortunately in many cases Python forces glibc to use GMT rather than the current timezone. You can see the problem most graphically with the %z format in strftime(). In the transcript Python incorrectly gives the timezone offset as +0000 even though it gets the timezone name (CDT) correct: $ python2.3 Python 2.3b1+ (#2, Jun 4 2003, 03:03:32) [GCC 3.3 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> now = time.localtime() >>> print now (2003, 6, 29, 20, 3, 52, 6, 180, 1) >>> RFC822 = '%a, %d %b %Y %T %z' >>> print time.strftime(RFC822, now) Sun, 29 Jun 2003 20:03:52 +0000 >>> print time.strftime(RFC822) Sun, 29 Jun 2003 20:05:27 -0500 >>> print time.strftime('%Z', now) CDT The correct timezone is CDT and the correct offset is -0500. Notice that when time.strftime() computes the current time it it gets the correct timezone offset, but when the struct tm tuple is passed in it thinks the timezone offset is 0. (glibc does know that the correct timezone name is CDT even when passed a bad struct tm value, but that's not surprising since the timezone name is not stored in struct tm and it is not computed from timezone offset.) The problem is in the gettmargs() function in timemodule.c. When getmargs() parses a Python tm tuple it leaves the tm_gmtoff field zeroed. This specifically tells glibc that the timezone offset is 0, which is wrong for most people. (BSD libc may also be affected.) This problem does not occur when time_strfrtime() gets the current time itself since that codepath uses a struct tm value directly from the libc localtime(), leaving the tm_gmtoff field intact. Fortunately the fix is almost trivial. A call to mktime() will normalize the fields in the struct tm value, including the tm_gmtoff field. I conditionalized the patch only on HAVE_MKTIME. I'm pretty sure there's an autoconfigure test for tm_gmtoff and it would probably be better to use that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762963&group_id=5470 From noreply@sourceforge.net Tue Jul 1 06:08:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 22:08:31 -0700 Subject: [Patches] [ python-Patches-762934 ] address test_time.py failures under Redhat 6.2 Message-ID: Patches item #762934, was opened at 2003-06-29 19:44 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762934&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) >Assigned to: Brett Cannon (bcannon) Summary: address test_time.py failures under Redhat 6.2 Initial Comment: A mangled version of this patch is also in bug: http://www.python.org/sf/728051 Looks like tzset(3) is broken under Redhat 6.2 in a way that wasn't being detected by configure. This patch adds stricter tzset(3) checking to configure.in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762934&group_id=5470 From noreply@sourceforge.net Tue Jul 1 06:10:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 22:10:16 -0700 Subject: [Patches] [ python-Patches-761104 ] adding BaseSet.filter and Set.filter_update Message-ID: Patches item #761104, was opened at 2003-06-26 05:15 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761104&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: adding BaseSet.filter and Set.filter_update Initial Comment: Hi, as proposed in [0], this patch adds a method 'filter' to BaseSet and a method 'filter_update' to Set. I often see myself doing "newset = sets.Set(filter(f, someset))" or "someset = sets.Set(filter(f, someset))". This is now no longer necessary. I think this method is a good solution to this problem. I'm not sure whether it is correct to add my name to the code history since it is a small change. If this is not correct feel free to remove it. This patch also corrects the docstring: the docstring says _TemporarilyImmutableSet is not a subset of BaseSet, but it is. Gerrit. [0] http://groups.google.nl/groups?dq=&hl=nl&lr=&ie=UTF-8&oe=UTF-8&group=comp.lang.python&selm=mailman.1056577245.15021.python-list%40python.org ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-01 00:10 Message: Logged In: YES user_id=80475 Zapping this one. Don't get discouraged. Keep on coming up with ideas. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-30 11:13 Message: Logged In: YES user_id=6380 Raymond can decide to reject it. ---------------------------------------------------------------------- Comment By: Gerrit Holl (gerrit) Date: 2003-06-28 16:17 Message: Logged In: YES user_id=13298 Who decides whether it's rejected or accepted? If it's going to be rejected I won't put work in it, but if there's a chance of accept I will meet to those demands... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-26 13:45 Message: Logged In: YES user_id=80475 * I don't think this should be added to the API. filter() is a builtin because it can be used with many datatypes as an input. Most container contructors have a list format that is suitable for use with filter. It is not unduly burdensome to write: newset=Set(filter(f, oldset)). The existing approach is also more flexible because the user can opt for a list comprehension, itertools.ifilter, itertools.ifilterfalse, or any other suitable expression. * If this ends up getting accepted, consider using itertools and a simpler, factored implementation: def filter(self, f): return Set(ifilter(f, self._data)) * Also, a documentation patch and news item would be needed. * I agree with docstring patch and will apply just that piece. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761104&group_id=5470 From noreply@sourceforge.net Tue Jul 1 06:12:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 22:12:05 -0700 Subject: [Patches] [ python-Patches-756253 ] itertools roundrobin() and window() Message-ID: Patches item #756253, was opened at 2003-06-17 16:35 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756253&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jack Diederich (jackdied) Assigned to: Raymond Hettinger (rhettinger) Summary: itertools roundrobin() and window() Initial Comment: a patch to add the roundrobin() and window() objects to the itertools module. Hettinger has already seen the implementation of roundrobin, but not window. test_itertools.py in a seperate patch ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-01 00:12 Message: Logged In: YES user_id=80475 Great. I look forward to it. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2003-06-27 13:33 Message: Logged In: YES user_id=591932 pushed to 2.4 I'll put up patches that incorporate rhettinger's feedback soon, and definitely in time for the 2.4 branch. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2003-06-27 13:27 Message: Logged In: YES user_id=591932 added Lib/test/test_itertools.py patch here, deleted old item that just had that patch in it ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 15:11 Message: Logged In: YES user_id=80475 *Please post the tests to this patch and close the other patch. *Add a documentation patch to this patch *Let's drop the addition of window(). The C code for it is less than beautiful and offers only a minimal performance gain over the pure python equivalent. I've added the pure python version to the docs so folks can cut and paste it if they need it. Sorry for the wild goose chase (I had expected the C version to be much cleaner and faster and that the python verions would've been harder -- actual code was needed for me to see it). * In roundrobin_next(), replace the % operator with: if (lz->iternum==lz->itersize) lz-iternum=0; * In roundrobin_next(), remove the extra blank line following "long listsize;" * Fixup the indentation, currently it is a mix of spaces and tabs. It should be just pure tabs. * Replace the variable name 'lz' with 'rr'. I should have changed that in other places too but for new code it should be fixed. * 'unti' is mispelled in the docstring. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756253&group_id=5470 From noreply@sourceforge.net Tue Jul 1 06:14:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 22:14:13 -0700 Subject: [Patches] [ python-Patches-763681 ] Support IDLE Edit of .py/.pyw from idlelib Message-ID: Patches item #763681, was opened at 2003-07-01 00: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=763681&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Nobody/Anonymous (nobody) Summary: Support IDLE Edit of .py/.pyw from idlelib Initial Comment: Windows File Types / Actions: IDLE has moved, this patch binds editing a python file to .../Lib/idlelib/idle.pyw instead of .../Tools/idle/idle.pyw ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763681&group_id=5470 From noreply@sourceforge.net Tue Jul 1 06:27:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 22:27:18 -0700 Subject: [Patches] [ python-Patches-747364 ] BaseHTTPServer doesn't need StringIO intermediary Message-ID: Patches item #747364, was opened at 2003-06-02 02:40 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=747364&group_id=5470 Category: Library (Lib) >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Nobody/Anonymous (nobody) Summary: BaseHTTPServer doesn't need StringIO intermediary Initial Comment: This is Python2.3b1, from CVS I looked at the implementation of the BaseHTTPServer.py code where it does the actual parsing. I see that it has # Deal with pipelining bytes = "" while 1: line = self.rfile.readline() bytes = bytes + line if line == '\r\n' or line == '\n' or line == '': break # Examine the headers and look for a Connection directive hfile = cStringIO.StringIO(bytes) self.headers = self.MessageClass(hfile) The MessageClass is mimetools.Message, which uses rfc822.Message to parse the headers. The Message reads the input stream up to and including the end-of-header blank line, but no further, using while 1: ... line = self.fp.readline() ... elif self.islast(line): # Note! No pushback here! The delimiter line gets eaten break def islast(self, line): """Determine whether a line is a legal end of RFC 2822 headers. and checks for '\r\n' or '\n' so it seems the temporary copy into a StringIO isn't needed since the Message can deal with it correctly. Plus, Message takes a 'seekable' parameter which can turn off seeking on the input stream, and has for a long time (since well before Martin's "Deal with pipelining code"). The proof, as they say, is in the pudding. Thought I don't know why. Anyway, I replaced the "bytes ... " code and used self.rfile rather than the temporary StringIO hfile, as in self.headers = self.MessageClass(self.rfile) print "Does it work?", repr(self.rfile.readline()) (I added the print to make sure the data wasn't eaten) I tested it with the module's mainline self-test, and it seems to work just fine. Attached patch does the same, only without the debugging print statement. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-01 00:27 Message: Logged In: YES user_id=80475 "the proof is in the pudding" lost its clarity when it got shortened from "the proof of the pudding is in the eating" meaning that recipes are best judged by their results. The patch looks fine to me but it is too late in the development cycle to include in Py2.3. Marking as a Py2.4 idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=747364&group_id=5470 From noreply@sourceforge.net Tue Jul 1 07:20:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 23:20:26 -0700 Subject: [Patches] [ python-Patches-751062 ] Tutorial: remove string exceptions, add parnassus, #posts Message-ID: Patches item #751062, was opened at 2003-06-08 16:49 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751062&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Tutorial: remove string exceptions, add parnassus, #posts Initial Comment: This patch, agains latest CVS, changes three things in the tutorial: The subsection "Exceptions Can Be Classes" is removed: Exceptions _should_ be classes, and the described behaviour is also documented elsewhere: since string exceptions are deprecated, they should not be mentioned in the tutorial because new users will never use them and it is very improbable that they will ever encounter them. The tutorial states that c.l.py receives "around 120 messages" a day. A note is added that there are peaks with up to several hundreds of postings (i.e. pep-308). The tutorial mentions www.python.org and starship.python.net. I have added a link to parnassus, because every Python user should know about its existence. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-01 01:20 Message: Logged In: YES user_id=80475 Reworked a bit and applied as tut.tex 1.192. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=751062&group_id=5470 From noreply@sourceforge.net Tue Jul 1 11:39:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 03:39:16 -0700 Subject: [Patches] [ python-Patches-761969 ] -DPIC should be added for the -fPIC case Message-ID: Patches item #761969, was opened at 2003-06-27 19:22 Message generated for change (Comment added) made by marc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761969&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: -DPIC should be added for the -fPIC case Initial Comment: AFAIK -DPIC should always added when compiling with -DPIC. At least that's what libtool does and shown in many FAQs (like http://www.netbsd.org/Documentation/elf.html). A quick glance on NetBSD-current and FreeBSD (4.8) shows that it's evaluated in machine/asm.h. ---------------------------------------------------------------------- >Comment By: Marc Recht (marc) Date: 2003-07-01 12:39 Message: Logged In: YES user_id=205 So far I've only build tested it on NetBSD-current. And at least the generated .so differs (more than between two builds). I've added this to all archs, because AFAIK that's what libtool does, too. (And every FAQ I've looked at and also other applications.) Maybe configure could check if "-fPIC -DPIC" is supported by the platform ? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-30 18:27 Message: Logged In: YES user_id=6380 Adding -DPIC just adds a preprocessor symbol, and not a very distinguished one. If FreeBSD really needs this particular #define to work correctly when compiling with -fPIC, perhaps a FreeBSD-specific patch would be acceptable. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-06-30 12:30 Message: Logged In: YES user_id=250749 I tested this patch on both FreeBSD 48 & 5.1. AFAICT, this did not affect behaviour of the interpreter either way. I note that you've tagged quite a few platforms in this patch, thus it would need to be tested on all affected platforms to be accepted in full. At this time, it isn't clear to me what benefits this patch gets us. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761969&group_id=5470 From noreply@sourceforge.net Tue Jul 1 12:01:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 04:01:46 -0700 Subject: [Patches] [ python-Patches-761969 ] -DPIC should be added for the -fPIC case Message-ID: Patches item #761969, was opened at 2003-06-28 03:22 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761969&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: -DPIC should be added for the -fPIC case Initial Comment: AFAIK -DPIC should always added when compiling with -DPIC. At least that's what libtool does and shown in many FAQs (like http://www.netbsd.org/Documentation/elf.html). A quick glance on NetBSD-current and FreeBSD (4.8) shows that it's evaluated in machine/asm.h. ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-01 21:01 Message: Logged In: YES user_id=250749 At least on FreeBSD, the presence or absence of -DPIC doesn't appear to have any effect on behaviour of the built .sos - the same ones pass/fail the tests either way, regardless of whether the content is changed, so its not a valuable addition. >From what I've read, I'm not sure that libtool should be taken as a definitive reference. ---------------------------------------------------------------------- Comment By: Marc Recht (marc) Date: 2003-07-01 20:39 Message: Logged In: YES user_id=205 So far I've only build tested it on NetBSD-current. And at least the generated .so differs (more than between two builds). I've added this to all archs, because AFAIK that's what libtool does, too. (And every FAQ I've looked at and also other applications.) Maybe configure could check if "-fPIC -DPIC" is supported by the platform ? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-07-01 02:27 Message: Logged In: YES user_id=6380 Adding -DPIC just adds a preprocessor symbol, and not a very distinguished one. If FreeBSD really needs this particular #define to work correctly when compiling with -fPIC, perhaps a FreeBSD-specific patch would be acceptable. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-06-30 20:30 Message: Logged In: YES user_id=250749 I tested this patch on both FreeBSD 48 & 5.1. AFAICT, this did not affect behaviour of the interpreter either way. I note that you've tagged quite a few platforms in this patch, thus it would need to be tested on all affected platforms to be accepted in full. At this time, it isn't clear to me what benefits this patch gets us. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761969&group_id=5470 From noreply@sourceforge.net Tue Jul 1 12:11:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 04:11:02 -0700 Subject: [Patches] [ python-Patches-763798 ] FreeBSD 5.x needs extra define to expose all library symbols Message-ID: Patches item #763798, was opened at 2003-07-01 21: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=763798&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD 5.x needs extra define to expose all library symbols Initial Comment: With FreeBSD 5.x, a number of library symbols, and common typedefs, have been moved outside the scope of the usual _XOPEN_SOURCE and _POSIX_C_SOURCE defines. This includes getloadavg(), and typedefs for u_int, u_long etc. These typedefs are common in standard extension modules (but not in Python's core). The define required to enable the missing bits is __BSD_VISIBLE. The attached patches for configure.in and pyconfig.in add support for this define in similar fashion to defines required for similar reasons on other platforms (eg NetBSD). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763798&group_id=5470 From noreply@sourceforge.net Tue Jul 1 12:13:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 04:13:36 -0700 Subject: [Patches] [ python-Patches-763798 ] FreeBSD 5.x needs extra define to expose all library symbols Message-ID: Patches item #763798, was opened at 2003-07-01 21:11 Message generated for change (Settings changed) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763798&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) >Assigned to: Martin v. Löwis (loewis) Summary: FreeBSD 5.x needs extra define to expose all library symbols Initial Comment: With FreeBSD 5.x, a number of library symbols, and common typedefs, have been moved outside the scope of the usual _XOPEN_SOURCE and _POSIX_C_SOURCE defines. This includes getloadavg(), and typedefs for u_int, u_long etc. These typedefs are common in standard extension modules (but not in Python's core). The define required to enable the missing bits is __BSD_VISIBLE. The attached patches for configure.in and pyconfig.in add support for this define in similar fashion to defines required for similar reasons on other platforms (eg NetBSD). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763798&group_id=5470 From noreply@sourceforge.net Tue Jul 1 12:51:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 04:51:19 -0700 Subject: [Patches] [ python-Patches-675551 ] extending readline functionality Message-ID: Patches item #675551, was opened at 2003-01-27 17:52 Message generated for change (Comment added) made by fufsource You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675551&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: Invalid Priority: 5 Submitted By: Michal Vitecek (fufsource) Assigned to: Skip Montanaro (montanaro) Summary: extending readline functionality Initial Comment: this patch against vanilla 2.2.2 adds three new functions to module readline: remove_history(pos) -- remove history entry specified by pos replace_history_entry(pos, line) -- replace history entry specified by pos with the given line get_history_buffer_size() -- get current number of history entries the libreadline.tex is also modified. thank you for your consideration. ---------------------------------------------------------------------- >Comment By: Michal Vitecek (fufsource) Date: 2003-07-01 13:51 Message: Logged In: YES user_id=698198 hello, attached is a new patch against today's (1.7.2003) cvs of python. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-06-27 20:32 Message: Logged In: YES user_id=44345 Michal, Can you update this patch against the 2.3 (CVS) source? I'll take a look at it for addition after the 2.3 release. ---------------------------------------------------------------------- Comment By: Michal Vitecek (fufsource) Date: 2003-02-11 12:23 Message: Logged In: YES user_id=698198 this patch is invalid as no functionality extensions are allowed in a stable python version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675551&group_id=5470 From noreply@sourceforge.net Tue Jul 1 18:22:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 10:22:12 -0700 Subject: [Patches] [ python-Patches-763798 ] FreeBSD 5.x needs extra define to expose all library symbols Message-ID: Patches item #763798, was opened at 2003-07-01 13:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763798&group_id=5470 Category: Build Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) >Assigned to: Andrew I MacIntyre (aimacintyre) Summary: FreeBSD 5.x needs extra define to expose all library symbols Initial Comment: With FreeBSD 5.x, a number of library symbols, and common typedefs, have been moved outside the scope of the usual _XOPEN_SOURCE and _POSIX_C_SOURCE defines. This includes getloadavg(), and typedefs for u_int, u_long etc. These typedefs are common in standard extension modules (but not in Python's core). The define required to enable the missing bits is __BSD_VISIBLE. The attached patches for configure.in and pyconfig.in add support for this define in similar fashion to defines required for similar reasons on other platforms (eg NetBSD). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-01 19:22 Message: Logged In: YES user_id=21627 The patch is fine in itself, but I'm uncertain whether it is a bug fix. If you can explain why this is a bug fix, please apply it for 2.3; otherwise, apply it after 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763798&group_id=5470 From noreply@sourceforge.net Tue Jul 1 18:30:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 10:30:45 -0700 Subject: [Patches] [ python-Patches-763580 ] Minor enhancements to Variable class Message-ID: Patches item #763580, was opened at 2003-06-30 17:18 Message generated for change (Comment added) made by reowen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763580&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Nobody/Anonymous (nobody) Summary: Minor enhancements to Variable class Initial Comment: Here are two enhancements to the Variable class (and subclasses): 1) Variables now have a "name" argument. This works just like the name argument on almost every other Tkinter class. Its primary purpose is to allow the user to create a new Tkinter Variable given its tk name. Justification: at present there is no reasonable way to do this. One can create a new Tkinter Variable and then assign its name property, but that relies on knowing about internals and it has the ugly side effect of creating an unused tk variable I admit that setvar and getvar can be used to work around the problem, but sometimes it's nicer to use a Tkinter Variable and often it's not convenient to pass the original Variable around to where it's needed. One can get an original Tkinter widget back again given the corresponding tk widget's name. It's time to allow this for Tkinter Variables (and tkFont.Font objects, but that's a separate issue I submitted as a bug report with associated suggested simple fix). 2) Variables now have a "value" argument to specify the initial value. This shortens: avar = StringVar() avar.set("desired value") to: avar = StringVar("desired value") Justification: it's useful. It's also harmless in that it will not break any existing code. I think one can even do something like this in tcl (i.e. define a variable and set it at the same time) and it's certainly a normal thing to do in Python itself. -- Russell ---------------------------------------------------------------------- >Comment By: Russell Owen (reowen) Date: 2003-07-01 10:30 Message: Logged In: YES user_id=431773 Replacement patch. The difference is what to do if value is supplied and the variable already exists (not something existing users would ever see unless they were doing nasty stuff directly in tcl). The old version treated value as an initial value, this new version always honors value if it is specified. I think this will be less surprising to the user (in those rare cases where it matters). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763580&group_id=5470 From noreply@sourceforge.net Tue Jul 1 18:31:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 10:31:21 -0700 Subject: [Patches] [ python-Patches-763201 ] 3 bugs fixed: handling of SyntaxErrors in symbol table build Message-ID: Patches item #763201, was opened at 2003-06-30 07:48 Message generated for change (Comment added) made by staschuk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763201&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Steven Taschuk (staschuk) Assigned to: Jeremy Hylton (jhylton) Summary: 3 bugs fixed: handling of SyntaxErrors in symbol table build Initial Comment: All three bugs found in both 2.2.3 and 2.3b2. It's one patch instead of three because the fixes share a refactoring of Python/compile.c:symtable_build. Bug 1: Wrong file name import symtable symtable.symtable('def foo(a): global a', 'spam', 'exec') The error message says '' instead of 'spam'. (Cause: PyNode_CompileSymtable doesn't set st_filename.) Bug 2: Memory leak while True: try: compile('def foo(a): global a', 'spam', 'exec') except SyntaxError: pass (Cause: symtable_build doesn't free c->c_symtable on error.) The patch is missing a test case for this one; I don't see how to write it. Bug 3: Exception clobbered def foo(a): global a # SyntaxError def bar(): b = 1 global b # SyntaxWarning Running this as a script, the SyntaxWarning is issued, and then the interpreter dies silently (that is, without printing a traceback reporting the SyntaxError). Compiling it with compile() causes a SystemError. (Cause: see below.) What to do about bugs 1 and 2 is obvious, but bug 3 (which was actually reported on c.l.py) is not so clear to me. Here's how the problem occurs: symtable_global() sees the global statement in foo(), raises a SyntaxError, increments st_errors, and returns. Processing continues. Later, symtable_global() sees the global statement in bar() and issues a warning by (indirectly) calling PyErr_WarnExplicit(). This call clears the SyntaxError, which is still pending at that time. (It's actually cleared during the attempt to import the warnings module, in PyImport_Import, which seems to think the exception was raised in PyEval_GetGlobals.) But st_errors is still > 0, as it should be, so symtable_build() returns -1 (resp. PyNode_CompileSymtable, NULL), its callers return their error values, etc., until eventually PyErr_Print tries to print the exception that isn't there. What the patch implements is this: Do not issue SyntaxWarnings if an exception is pending; fail instead and let that exception propagate. Also, as a defensive measure against other bugs of this type (present and future), when returning with error from symtable_build(), verify that there's an exception pending (and raise SystemError if not). Finally, refactor symtable_build() so PyNode_CompileSymtable can use it and thereby benefit from that defensive measure. Alternatives (and why I don't like them): 1. Do not try to continue processing after a SyntaxError is raised. (Seems like the Right Thing to me, but also seems to be contrary to the intent of the existing code. There are oodles of places in compile.c which call symtable_node without checking st_errors immediately afterwards.) 2. Put the check for a pending exception in PyErr_WarnExplicit() instead of in the helper function in compile.c. (Doesn't seem like a common enough coding error to merit a check there. In symtable_node etc we deliberately let SyntaxErrors, er, "pend" while we do a bit more compiling, so *there* it's worth checking. Note that jcompile() already has a check for something similar, though not for the symbol-table-building phase.) 3. Squirrel the pending exception away, issue the warning, then restore the exception. (Not worth the bother, IMO. And if the warning gets strengthened into an exception, should that exception or the squirrelled one propagate? Ick.) ---------------------------------------------------------------------- >Comment By: Steven Taschuk (staschuk) Date: 2003-07-01 11:31 Message: Logged In: YES user_id=666873 Just noticed another alternative: leave the checking of whether a global statement declares a function parameter global to the later pass. There's already a check for this condition in symtable_load_symbols (with a different error message, which is a subject for another patch). The problem with this idea is that it breaks symtable.symtable(), which only uses symtable_build. Thus this function would no longer raise SyntaxErrors for this case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763201&group_id=5470 From noreply@sourceforge.net Tue Jul 1 18:56:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 10:56:45 -0700 Subject: [Patches] [ python-Patches-764121 ] docstring for spawnlp incorrect Message-ID: Patches item #764121, was opened at 2003-07-01 13:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764121&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: ejm (starlost) Assigned to: Nobody/Anonymous (nobody) Summary: docstring for spawnlp incorrect Initial Comment: It looks like the docstring for spawnlpe was simply copied for spawnlp: def spawnlp(mode, file, *args): """spawnlp(mode, file, *args) -> integer ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764121&group_id=5470 From noreply@sourceforge.net Tue Jul 1 22:14:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 14:14:43 -0700 Subject: [Patches] [ python-Patches-764217 ] Fix for tkFont.Font(name=...) Message-ID: Patches item #764217, was opened at 2003-07-01 14: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=764217&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for tkFont.Font(name=...) Initial Comment: tkFont.Font(name=xxx) crashes if a font by the specified name already exists. This is a problem for several reasons, the main one being that it makes life really tough if you want to creat a new tkFont.Font object for a given Tcl named font. This simple fix handles the problem. I've also included a new method __eq__ so that two tkFont.Font objects that point to the same Tcl named font compare as equal. I felt this is important because the fix makes it easier to have multiple such tkFont.Font objects. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764217&group_id=5470 From noreply@sourceforge.net Tue Jul 1 22:21:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 14:21:31 -0700 Subject: [Patches] [ python-Patches-764221 ] add set/getattr interface to tkFont.Font objects Message-ID: Patches item #764221, was opened at 2003-07-01 14:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764221&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Nobody/Anonymous (nobody) Summary: add set/getattr interface to tkFont.Font objects Initial Comment: A simple patch to add the dictionary style get/set attribute interface to tkFont.Font objects. This makes it act like almost all other Tkinter classes. Perhaps best saved for Python 2.4, but it's such a simple change I thought it might squeak by. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764221&group_id=5470 From noreply@sourceforge.net Wed Jul 2 03:51:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 19:51:34 -0700 Subject: [Patches] [ python-Patches-764121 ] docstring for spawnlp incorrect Message-ID: Patches item #764121, was opened at 2003-07-01 13:56 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764121&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: ejm (starlost) >Assigned to: Neal Norwitz (nnorwitz) Summary: docstring for spawnlp incorrect Initial Comment: It looks like the docstring for spawnlpe was simply copied for spawnlp: def spawnlp(mode, file, *args): """spawnlp(mode, file, *args) -> integer ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-01 22:51 Message: Logged In: YES user_id=33168 Thanks! Checked in as: * Lib/os.py 1.72 and 1.50.8.8 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764121&group_id=5470 From noreply@sourceforge.net Wed Jul 2 04:03:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 20:03:25 -0700 Subject: [Patches] [ python-Patches-762934 ] address test_time.py failures under Redhat 6.2 Message-ID: Patches item #762934, was opened at 2003-06-29 20:44 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762934&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Brett Cannon (bcannon) Summary: address test_time.py failures under Redhat 6.2 Initial Comment: A mangled version of this patch is also in bug: http://www.python.org/sf/728051 Looks like tzset(3) is broken under Redhat 6.2 in a way that wasn't being detected by configure. This patch adds stricter tzset(3) checking to configure.in. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-01 23:03 Message: Logged In: YES user_id=33168 Stuart, what boxes did you test this on? How confident are you that this won't break some other platform? I'm asking to try to determine if this should go into 2.3final (we only have 1 release candidate before release) or if this should wait for 2.3.1. Thanks for all your work on tzset. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762934&group_id=5470 From noreply@sourceforge.net Wed Jul 2 04:51:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 20:51:36 -0700 Subject: [Patches] [ python-Patches-762934 ] address test_time.py failures under Redhat 6.2 Message-ID: Patches item #762934, was opened at 2003-06-30 10:44 Message generated for change (Comment added) made by zenzen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762934&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Brett Cannon (bcannon) Summary: address test_time.py failures under Redhat 6.2 Initial Comment: A mangled version of this patch is also in bug: http://www.python.org/sf/728051 Looks like tzset(3) is broken under Redhat 6.2 in a way that wasn't being detected by configure. This patch adds stricter tzset(3) checking to configure.in. ---------------------------------------------------------------------- >Comment By: Stuart Bishop (zenzen) Date: 2003-07-02 13:51 Message: Logged In: YES user_id=46639 This patch has only been tested under OS X. I'm confident that it won't break other platforms. I have no real way of proving that it addresses the problem it is supposed to solve, however, as I don't have access to a box that fails the tzset test in test_time.py. The only reported platform that this is failing on is at http://www.python.org/sf/728051, so we could just flag this test as expected to fail on that platform, if someone knows how to do that. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-02 13:03 Message: Logged In: YES user_id=33168 Stuart, what boxes did you test this on? How confident are you that this won't break some other platform? I'm asking to try to determine if this should go into 2.3final (we only have 1 release candidate before release) or if this should wait for 2.3.1. Thanks for all your work on tzset. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762934&group_id=5470 From noreply@sourceforge.net Wed Jul 2 10:06:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 02:06:00 -0700 Subject: [Patches] [ python-Patches-764470 ] Bugfix for incorrect xmlrpclib.Fault representation Message-ID: Patches item #764470, was opened at 2003-07-02 12: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=764470&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Gavrie Philipson (gavrie) Assigned to: Nobody/Anonymous (nobody) Summary: Bugfix for incorrect xmlrpclib.Fault representation Initial Comment: The xmlrpclib library represents a Fault object with an extraneous 'args' member field. The reason for this is that the dump function blindly marshals all variables of the Fault object, and since Fault is a subclass of Exception it inherits the 'args' attribute. According to the XML-RPC spec, adding additional fields to a Fault response is not allowed. The attached patch is a simple solution to the problem. Sample Fault XML output that shows the problem: faultCode 900 args faultString boo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764470&group_id=5470 From noreply@sourceforge.net Wed Jul 2 14:50:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 06:50:01 -0700 Subject: [Patches] [ python-Patches-764594 ] Unicode strings in sys.path Message-ID: Patches item #764594, was opened at 2003-07-02 15: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=764594&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode strings in sys.path Initial Comment: I was astonished to find that Unicode strings in sys.path "did not work" in Python 2.2. They work correctly in 2.3a1 and later, and it's mentioned in the NEWS file, but not in the docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764594&group_id=5470 From noreply@sourceforge.net Wed Jul 2 15:02:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 07:02:45 -0700 Subject: [Patches] [ python-Patches-763798 ] FreeBSD 5.x needs extra define to expose all library symbols Message-ID: Patches item #763798, was opened at 2003-07-01 21:11 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763798&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Andrew I MacIntyre (aimacintyre) Summary: FreeBSD 5.x needs extra define to expose all library symbols Initial Comment: With FreeBSD 5.x, a number of library symbols, and common typedefs, have been moved outside the scope of the usual _XOPEN_SOURCE and _POSIX_C_SOURCE defines. This includes getloadavg(), and typedefs for u_int, u_long etc. These typedefs are common in standard extension modules (but not in Python's core). The define required to enable the missing bits is __BSD_VISIBLE. The attached patches for configure.in and pyconfig.in add support for this define in similar fashion to defines required for similar reasons on other platforms (eg NetBSD). ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-03 00:02 Message: Logged In: YES user_id=250749 The lack of the typedefs now controlled by __BSD_VISIBLE is the cause of the odd test_socket and test_tempfile failures reported to python-dev on 29/6/03 by pieterb@gewis.nl (subject: running tests on freebsd5). Because of these test failures, I've proceeded with applying the patches as: configure.in v1.420 configure v 1.409 pyconfig.h.in v1.82 There appears to be no requirement to backport this. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-02 03:22 Message: Logged In: YES user_id=21627 The patch is fine in itself, but I'm uncertain whether it is a bug fix. If you can explain why this is a bug fix, please apply it for 2.3; otherwise, apply it after 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763798&group_id=5470 From noreply@sourceforge.net Wed Jul 2 15:19:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 07:19:11 -0700 Subject: [Patches] [ python-Patches-764612 ] building bsddb3 on FreeBSD Message-ID: Patches item #764612, was opened at 2003-07-03 00: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=764612&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Nobody/Anonymous (nobody) Summary: building bsddb3 on FreeBSD Initial Comment: FreeBSD's ports of the Sleepcat DB releases use different naming conventions than currently catered for in setup.py. Additionally, the ports collection currently supports having both DB 4.1 and DB 4.0 installed concurrently. The current setup.py really only caters for 1 variation of any major DB version. The attached patch expands the support so that v4.1 has the correct include directory on FreeBSD, and allows for both 4.1 and 4.0 to be concurrently installed. It also adds support for DB3 (v3.3.11 in the Ports collection) on FreeBSD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764612&group_id=5470 From noreply@sourceforge.net Wed Jul 2 15:29:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 07:29:35 -0700 Subject: [Patches] [ python-Patches-764612 ] building bsddb3 on FreeBSD Message-ID: Patches item #764612, was opened at 2003-07-03 00:19 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764612&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) >Assigned to: Martin v. Löwis (loewis) Summary: building bsddb3 on FreeBSD Initial Comment: FreeBSD's ports of the Sleepcat DB releases use different naming conventions than currently catered for in setup.py. Additionally, the ports collection currently supports having both DB 4.1 and DB 4.0 installed concurrently. The current setup.py really only caters for 1 variation of any major DB version. The attached patch expands the support so that v4.1 has the correct include directory on FreeBSD, and allows for both 4.1 and 4.0 to be concurrently installed. It also adds support for DB3 (v3.3.11 in the Ports collection) on FreeBSD. ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-03 00:29 Message: Logged In: YES user_id=250749 Martin, assigned to you as setup.py's history shows you had a fair bit to do with the bsddb3 module machinery in there (Skip and Barry have both also worked on this). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764612&group_id=5470 From noreply@sourceforge.net Wed Jul 2 15:46:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 07:46:35 -0700 Subject: [Patches] [ python-Patches-732174 ] build of html docs broken (liboptparse.tex) Message-ID: Patches item #732174, was opened at 2003-05-04 09:47 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732174&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: build of html docs broken (liboptparse.tex) Initial Comment: The last known working versions is 1.6. 1.7 doesn't build anymore. latex2html returns [...] Reading aux file: /build/packages/python2.3/python2.3-2.2.102/Doc/lib.aux ... Processing macros ...,,,,++................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................Subroutine do_cmd_leftmargin redefined at (eval 732) line 1. defining handler for \leftmargin using \leftmargini .............Undefined subroutine &main::do_cmd_leftmargini called at (eval 732) line 1. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-02 10:46 Message: Logged In: YES user_id=3066 Several parts of the patch are now committed, but not everything. In particular, the changes to Doc/lib/libre.tex have not been committed, pending time for me to take a closer look. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-05-18 16:46 Message: Logged In: YES user_id=60903 Which version? py2texi.el is at 1.3 and unchanged the last six months. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 16:28 Message: Logged In: YES user_id=80475 The latest version is 1.9. Fred made changes to make it build again. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-05-18 15:08 Message: Logged In: YES user_id=60903 Attached is a patch to fix the build of the info docs. The change to libre.tex maybe controversial, as it works around a problem in py2texi.el. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-05-18 15:02 Message: Logged In: YES user_id=60903 Reopened. Please practice on other reports ;-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-17 21:51 Message: Logged In: YES user_id=31435 Assigning to Raymond for practice in finding the Submit button . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732174&group_id=5470 From noreply@sourceforge.net Thu Jul 3 11:54:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Jul 2003 03:54:11 -0700 Subject: [Patches] [ python-Patches-765238 ] fix fnmatch.__all__ Message-ID: Patches item #765238, was opened at 2003-07-03 19: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=765238&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: fix fnmatch.__all__ Initial Comment: There are two reasons for this patch. First, in the fnmatch.py, __all__ doesn't include "filter", so if you tried to use fnmatch.filter like this, >>> from fnmatch import * >>> filter built-in function, filter, is called instead of fnmatch.filter. >>> filter Second, "translate" is just a helper function used by other functions in the fnmatch module, and that's why it's not documented in the Python library reference. I think "translate" should be removed from fnmatch.__all__. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=765238&group_id=5470 From noreply@sourceforge.net Thu Jul 3 14:10:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Jul 2003 06:10:24 -0700 Subject: [Patches] [ python-Patches-764612 ] building bsddb3 on FreeBSD Message-ID: Patches item #764612, was opened at 2003-07-03 00:19 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764612&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Martin v. Löwis (loewis) Summary: building bsddb3 on FreeBSD Initial Comment: FreeBSD's ports of the Sleepcat DB releases use different naming conventions than currently catered for in setup.py. Additionally, the ports collection currently supports having both DB 4.1 and DB 4.0 installed concurrently. The current setup.py really only caters for 1 variation of any major DB version. The attached patch expands the support so that v4.1 has the correct include directory on FreeBSD, and allows for both 4.1 and 4.0 to be concurrently installed. It also adds support for DB3 (v3.3.11 in the Ports collection) on FreeBSD. ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-03 23:10 Message: Logged In: YES user_id=250749 I've concluded that the first version of this patch is unnecessarily complicated. I've uploaded a simplified second version, which gets the essentials in place. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-03 00:29 Message: Logged In: YES user_id=250749 Martin, assigned to you as setup.py's history shows you had a fair bit to do with the bsddb3 module machinery in there (Skip and Barry have both also worked on this). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764612&group_id=5470 From noreply@sourceforge.net Thu Jul 3 21:16:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Jul 2003 13:16:22 -0700 Subject: [Patches] [ python-Patches-762934 ] address test_time.py failures under Redhat 6.2 Message-ID: Patches item #762934, was opened at 2003-06-29 17:44 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762934&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Brett Cannon (bcannon) Summary: address test_time.py failures under Redhat 6.2 Initial Comment: A mangled version of this patch is also in bug: http://www.python.org/sf/728051 Looks like tzset(3) is broken under Redhat 6.2 in a way that wasn't being detected by configure. This patch adds stricter tzset(3) checking to configure.in. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-03 13:16 Message: Logged In: YES user_id=357491 We can say it should fail under Linux, but we can't specify Red Hat 6.2. I am keeping an eye on this patch for bug #763153, but I have to wait until the OP applies it and tests it. Looking at the patch, beyond not realizing that the X-mas time was GMT initially and the unneeded variable assignments, the patch looks fine to me (might want to comment that tzset does not return a value; rather non-standard) although I am no autoconf expert and I am assuming it just compiles this C code and any problems it just says it fails. Neal, what OS are you running? If it is non-OS X (sorry, that's what I am running as well) can you give the patch a try? ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-07-01 20:51 Message: Logged In: YES user_id=46639 This patch has only been tested under OS X. I'm confident that it won't break other platforms. I have no real way of proving that it addresses the problem it is supposed to solve, however, as I don't have access to a box that fails the tzset test in test_time.py. The only reported platform that this is failing on is at http://www.python.org/sf/728051, so we could just flag this test as expected to fail on that platform, if someone knows how to do that. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-01 20:03 Message: Logged In: YES user_id=33168 Stuart, what boxes did you test this on? How confident are you that this won't break some other platform? I'm asking to try to determine if this should go into 2.3final (we only have 1 release candidate before release) or if this should wait for 2.3.1. Thanks for all your work on tzset. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762934&group_id=5470 From noreply@sourceforge.net Fri Jul 4 02:00:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Jul 2003 18:00:19 -0700 Subject: [Patches] [ python-Patches-702933 ] Kill off docs for unsafe macros Message-ID: Patches item #702933, was opened at 2003-03-13 08:10 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=702933&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Pending Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Kill off docs for unsafe macros Initial Comment: I'll also attach the patch, but a message body is required: ========================================= ========================== RCS file: /cvsroot/python/python/dist/src/Doc/api/memory.tex, v retrieving revision 1.2 diff -w -u -r1.2 memory.tex --- memory.tex 6 Apr 2002 09:14:33 -0000 1.2 +++ memory.tex 13 Mar 2003 12:56:26 -0000 @@ -195,9 +195,7 @@ In addition to the functions aimed at handling raw memory blocks from the Python heap, objects in Python are allocated and released with \cfunction{PyObject_New()}, \cfunction {PyObject_NewVar()} and -\cfunction{PyObject_Del()}, or with their corresponding macros -\cfunction{PyObject_NEW()}, \cfunction {PyObject_NEW_VAR()} and -\cfunction{PyObject_DEL()}. +\cfunction{PyObject_Del()}. These will be explained in the next chapter on defining and implementing new object types in C. Index: newtypes.tex ========================================= ========================== RCS file: /cvsroot/python/python/dist/src/Doc/api/newtypes.te x,v retrieving revision 1.21 diff -w -u -r1.21 newtypes.tex --- newtypes.tex 10 Feb 2003 19:18:21 -0000 1.21 +++ newtypes.tex 13 Mar 2003 12:56:27 -0000 @@ -62,23 +62,6 @@ after this call as the memory is no longer a valid Python object. \end{cfuncdesc} -\begin{cfuncdesc}{\var{TYPE}*}{PyObject_NEW}{TYPE, PyTypeObject *type} - Macro version of \cfunction{PyObject_New()}, to gain performance at - the expense of safety. This does not check \var{type} for a \NULL{} - value. -\end{cfuncdesc} - -\begin{cfuncdesc}{\var{TYPE}*}{PyObject_NEW_VAR} {TYPE, PyTypeObject *type, - int size} - Macro version of \cfunction{PyObject_NewVar()}, to gain performance - at the expense of safety. This does not check \var {type} for a - \NULL{} value. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{PyObject_DEL}{PyObject *op} - Macro version of \cfunction{PyObject_Del()}. -\end{cfuncdesc} - \begin{cfuncdesc}{PyObject*}{Py_InitModule}{char *name, PyMethodDef *methods} Create a new module object based on a name and table of functions, ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-03 21:00 Message: Logged In: YES user_id=3066 I'm not sure what you're suggesting with this patch. Could you explain the intention? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=702933&group_id=5470 From noreply@sourceforge.net Fri Jul 4 02:06:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Jul 2003 18:06:34 -0700 Subject: [Patches] [ python-Patches-748126 ] Nails down the semantics of dict setitem Message-ID: Patches item #748126, was opened at 2003-06-03 07:57 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748126&group_id=5470 Category: Documentation Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Nails down the semantics of dict setitem Initial Comment: You could consider accomplishing the same thing in the footnotes area, but I didn't see any reason to make the reader jump around for this info. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-03 21:06 Message: Logged In: YES user_id=3066 This report is very vague. What part of the documentation are you referring to, and how do you think it should be changed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748126&group_id=5470 From noreply@sourceforge.net Fri Jul 4 03:37:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Jul 2003 19:37:25 -0700 Subject: [Patches] [ python-Patches-702933 ] Kill off docs for unsafe macros Message-ID: Patches item #702933, was opened at 2003-03-13 08:10 Message generated for change (Comment added) made by david_abrahams You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=702933&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Kill off docs for unsafe macros Initial Comment: I'll also attach the patch, but a message body is required: ========================================= ========================== RCS file: /cvsroot/python/python/dist/src/Doc/api/memory.tex, v retrieving revision 1.2 diff -w -u -r1.2 memory.tex --- memory.tex 6 Apr 2002 09:14:33 -0000 1.2 +++ memory.tex 13 Mar 2003 12:56:26 -0000 @@ -195,9 +195,7 @@ In addition to the functions aimed at handling raw memory blocks from the Python heap, objects in Python are allocated and released with \cfunction{PyObject_New()}, \cfunction {PyObject_NewVar()} and -\cfunction{PyObject_Del()}, or with their corresponding macros -\cfunction{PyObject_NEW()}, \cfunction {PyObject_NEW_VAR()} and -\cfunction{PyObject_DEL()}. +\cfunction{PyObject_Del()}. These will be explained in the next chapter on defining and implementing new object types in C. Index: newtypes.tex ========================================= ========================== RCS file: /cvsroot/python/python/dist/src/Doc/api/newtypes.te x,v retrieving revision 1.21 diff -w -u -r1.21 newtypes.tex --- newtypes.tex 10 Feb 2003 19:18:21 -0000 1.21 +++ newtypes.tex 13 Mar 2003 12:56:27 -0000 @@ -62,23 +62,6 @@ after this call as the memory is no longer a valid Python object. \end{cfuncdesc} -\begin{cfuncdesc}{\var{TYPE}*}{PyObject_NEW}{TYPE, PyTypeObject *type} - Macro version of \cfunction{PyObject_New()}, to gain performance at - the expense of safety. This does not check \var{type} for a \NULL{} - value. -\end{cfuncdesc} - -\begin{cfuncdesc}{\var{TYPE}*}{PyObject_NEW_VAR} {TYPE, PyTypeObject *type, - int size} - Macro version of \cfunction{PyObject_NewVar()}, to gain performance - at the expense of safety. This does not check \var {type} for a - \NULL{} value. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{PyObject_DEL}{PyObject *op} - Macro version of \cfunction{PyObject_Del()}. -\end{cfuncdesc} - \begin{cfuncdesc}{PyObject*}{Py_InitModule}{char *name, PyMethodDef *methods} Create a new module object based on a name and table of functions, ---------------------------------------------------------------------- >Comment By: David Abrahams (david_abrahams) Date: 2003-07-03 21:37 Message: Logged In: YES user_id=52572 I've forgotten, frankly. You might check python-dev around this date. Seems like Guido may have agreed that these macros were really not meant to be touched by users and shouild be deprecated, but I don't recall. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-03 20:00 Message: Logged In: YES user_id=3066 I'm not sure what you're suggesting with this patch. Could you explain the intention? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=702933&group_id=5470 From noreply@sourceforge.net Fri Jul 4 03:42:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Jul 2003 19:42:00 -0700 Subject: [Patches] [ python-Patches-748126 ] Nails down the semantics of dict setitem Message-ID: Patches item #748126, was opened at 2003-06-03 06:57 Message generated for change (Comment added) made by david_abrahams You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748126&group_id=5470 Category: Documentation Group: None >Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Nails down the semantics of dict setitem Initial Comment: You could consider accomplishing the same thing in the footnotes area, but I didn't see any reason to make the reader jump around for this info. ---------------------------------------------------------------------- >Comment By: David Abrahams (david_abrahams) Date: 2003-07-03 21:42 Message: Logged In: YES user_id=52572 I think I originally tried to attach a patch which SF dropped due to one of its usual bugs. I think the question was whether d[k] = y would unconditionally set the identity of the key object in d to k, or whether any previous equal key in that "slot" would be preserved. It's the latter, and the current docs don't say which one it is. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-03 20:06 Message: Logged In: YES user_id=3066 This report is very vague. What part of the documentation are you referring to, and how do you think it should be changed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748126&group_id=5470 From noreply@sourceforge.net Sat Jul 5 17:00:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 05 Jul 2003 09:00:41 -0700 Subject: [Patches] [ python-Patches-764612 ] building bsddb3 on FreeBSD Message-ID: Patches item #764612, was opened at 2003-07-02 16:19 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764612&group_id=5470 Category: Modules Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) >Assigned to: Andrew I MacIntyre (aimacintyre) Summary: building bsddb3 on FreeBSD Initial Comment: FreeBSD's ports of the Sleepcat DB releases use different naming conventions than currently catered for in setup.py. Additionally, the ports collection currently supports having both DB 4.1 and DB 4.0 installed concurrently. The current setup.py really only caters for 1 variation of any major DB version. The attached patch expands the support so that v4.1 has the correct include directory on FreeBSD, and allows for both 4.1 and 4.0 to be concurrently installed. It also adds support for DB3 (v3.3.11 in the Ports collection) on FreeBSD. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-05 18:00 Message: Logged In: YES user_id=21627 The patch is fine in principle. However, please make sure that it finds newer versions before it finds older ones, i.e. 4.1 before 4.0 (so resort the strings accordingly). ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-03 15:10 Message: Logged In: YES user_id=250749 I've concluded that the first version of this patch is unnecessarily complicated. I've uploaded a simplified second version, which gets the essentials in place. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-02 16:29 Message: Logged In: YES user_id=250749 Martin, assigned to you as setup.py's history shows you had a fair bit to do with the bsddb3 module machinery in there (Skip and Barry have both also worked on this). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764612&group_id=5470 From noreply@sourceforge.net Sat Jul 5 17:04:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 05 Jul 2003 09:04:33 -0700 Subject: [Patches] [ python-Patches-764594 ] Unicode strings in sys.path Message-ID: Patches item #764594, was opened at 2003-07-02 15:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764594&group_id=5470 Category: Documentation Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Thomas Heller (theller) >Assigned to: Thomas Heller (theller) Summary: Unicode strings in sys.path Initial Comment: I was astonished to find that Unicode strings in sys.path "did not work" in Python 2.2. They work correctly in 2.3a1 and later, and it's mentioned in the NEWS file, but not in the docs. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-05 18:04 Message: Logged In: YES user_id=21627 The patch is fine. Please use \versionchanged, though; look at other cases where versionchanged takes a parameter indicating what specifically has changed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764594&group_id=5470 From noreply@sourceforge.net Sat Jul 5 17:05:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 05 Jul 2003 09:05:12 -0700 Subject: [Patches] [ python-Patches-764470 ] Bugfix for incorrect xmlrpclib.Fault representation Message-ID: Patches item #764470, was opened at 2003-07-02 11:06 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764470&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Gavrie Philipson (gavrie) >Assigned to: Martin v. Löwis (loewis) Summary: Bugfix for incorrect xmlrpclib.Fault representation Initial Comment: The xmlrpclib library represents a Fault object with an extraneous 'args' member field. The reason for this is that the dump function blindly marshals all variables of the Fault object, and since Fault is a subclass of Exception it inherits the 'args' attribute. According to the XML-RPC spec, adding additional fields to a Fault response is not allowed. The attached patch is a simple solution to the problem. Sample Fault XML output that shows the problem: faultCode 900 args faultString boo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764470&group_id=5470 From noreply@sourceforge.net Sat Jul 5 17:02:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 05 Jul 2003 09:02:22 -0700 Subject: [Patches] [ python-Patches-765238 ] fix fnmatch.__all__ Message-ID: Patches item #765238, was opened at 2003-07-03 12:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=765238&group_id=5470 Category: Library (Lib) >Group: Python 2.4 Status: Open >Resolution: Postponed Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: fix fnmatch.__all__ Initial Comment: There are two reasons for this patch. First, in the fnmatch.py, __all__ doesn't include "filter", so if you tried to use fnmatch.filter like this, >>> from fnmatch import * >>> filter built-in function, filter, is called instead of fnmatch.filter. >>> filter Second, "translate" is just a helper function used by other functions in the fnmatch module, and that's why it's not documented in the Python library reference. I think "translate" should be removed from fnmatch.__all__. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-05 18:02 Message: Logged In: YES user_id=21627 While I agree with that, I feel that it is too late for 2.3: this is an interface change. So postponing it to 2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=765238&group_id=5470 From noreply@sourceforge.net Sat Jul 5 17:08:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 05 Jul 2003 09:08:10 -0700 Subject: [Patches] [ python-Patches-763681 ] Support IDLE Edit of .py/.pyw from idlelib Message-ID: Patches item #763681, was opened at 2003-07-01 07:14 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763681&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kurt B. Kaiser (kbk) >Assigned to: Tim Peters (tim_one) Summary: Support IDLE Edit of .py/.pyw from idlelib Initial Comment: Windows File Types / Actions: IDLE has moved, this patch binds editing a python file to .../Lib/idlelib/idle.pyw instead of .../Tools/idle/idle.pyw ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-05 18:08 Message: Logged In: YES user_id=21627 Assigning to Tim for review - the patch looks right to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763681&group_id=5470 From noreply@sourceforge.net Sat Jul 5 17:15:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 05 Jul 2003 09:15:01 -0700 Subject: [Patches] [ python-Patches-761969 ] -DPIC should be added for the -fPIC case Message-ID: Patches item #761969, was opened at 2003-06-27 19:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761969&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: -DPIC should be added for the -fPIC case Initial Comment: AFAIK -DPIC should always added when compiling with -DPIC. At least that's what libtool does and shown in many FAQs (like http://www.netbsd.org/Documentation/elf.html). A quick glance on NetBSD-current and FreeBSD (4.8) shows that it's evaluated in machine/asm.h. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-05 18:15 Message: Logged In: YES user_id=21627 I completely agree with Andrew, especially in his view of libtool. Marc, can you show us (or point us to) a fragment of asm.h that uses -DPIC? I would consider a system broken where -fPIC/-KPIC works incorrectly without -DPIC. gcc is powerful enough to automatically add this to the preprocessor if a platform really needs it, so not supplying it would be a gcc bug. We only work around clearly demonstrated bugs, and only by documenting, in the Python sources, that a certain piece of code is a work-around for a bug in some documented version of some system. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-01 13:01 Message: Logged In: YES user_id=250749 At least on FreeBSD, the presence or absence of -DPIC doesn't appear to have any effect on behaviour of the built .sos - the same ones pass/fail the tests either way, regardless of whether the content is changed, so its not a valuable addition. >From what I've read, I'm not sure that libtool should be taken as a definitive reference. ---------------------------------------------------------------------- Comment By: Marc Recht (marc) Date: 2003-07-01 12:39 Message: Logged In: YES user_id=205 So far I've only build tested it on NetBSD-current. And at least the generated .so differs (more than between two builds). I've added this to all archs, because AFAIK that's what libtool does, too. (And every FAQ I've looked at and also other applications.) Maybe configure could check if "-fPIC -DPIC" is supported by the platform ? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-30 18:27 Message: Logged In: YES user_id=6380 Adding -DPIC just adds a preprocessor symbol, and not a very distinguished one. If FreeBSD really needs this particular #define to work correctly when compiling with -fPIC, perhaps a FreeBSD-specific patch would be acceptable. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-06-30 12:30 Message: Logged In: YES user_id=250749 I tested this patch on both FreeBSD 48 & 5.1. AFAICT, this did not affect behaviour of the interpreter either way. I note that you've tagged quite a few platforms in this patch, thus it would need to be tested on all affected platforms to be accepted in full. At this time, it isn't clear to me what benefits this patch gets us. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761969&group_id=5470 From noreply@sourceforge.net Sun Jul 6 11:29:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 03:29:34 -0700 Subject: [Patches] [ python-Patches-764612 ] building bsddb3 on FreeBSD Message-ID: Patches item #764612, was opened at 2003-07-03 00:19 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764612&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Andrew I MacIntyre (aimacintyre) Summary: building bsddb3 on FreeBSD Initial Comment: FreeBSD's ports of the Sleepcat DB releases use different naming conventions than currently catered for in setup.py. Additionally, the ports collection currently supports having both DB 4.1 and DB 4.0 installed concurrently. The current setup.py really only caters for 1 variation of any major DB version. The attached patch expands the support so that v4.1 has the correct include directory on FreeBSD, and allows for both 4.1 and 4.0 to be concurrently installed. It also adds support for DB3 (v3.3.11 in the Ports collection) on FreeBSD. ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-06 20:29 Message: Logged In: YES user_id=250749 Revised version with resorted strings as requested. v2 worked fine for me, finding v4.1 before 4.0 (on FreeBSD), however there are enough variations in live installations that re-sorting the strings is prudent. If there are no objections to v3, I'll check it in later this week. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-06 02:00 Message: Logged In: YES user_id=21627 The patch is fine in principle. However, please make sure that it finds newer versions before it finds older ones, i.e. 4.1 before 4.0 (so resort the strings accordingly). ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-03 23:10 Message: Logged In: YES user_id=250749 I've concluded that the first version of this patch is unnecessarily complicated. I've uploaded a simplified second version, which gets the essentials in place. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-03 00:29 Message: Logged In: YES user_id=250749 Martin, assigned to you as setup.py's history shows you had a fair bit to do with the bsddb3 module machinery in there (Skip and Barry have both also worked on this). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764612&group_id=5470 From noreply@sourceforge.net Sun Jul 6 12:09:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 04:09:51 -0700 Subject: [Patches] [ python-Patches-766650 ] whichdb not ID'ing dbm files with GDBM backend Message-ID: Patches item #766650, was opened at 2003-07-06 21: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=766650&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Nobody/Anonymous (nobody) Summary: whichdb not ID'ing dbm files with GDBM backend Initial Comment: For the OS/2 EMX port, I build the dbm module with gdbm v1.7.3. At least with the OS/2 version of the gdbm v1.7.3 port, dbm databases consist only of the .pag file - there is no .dir file. In this case, the .pag file has the gdbm magic number. Currently whichdb fails to identify such dbm DBs on this platform because of the expectation that there be a .dir file as well as the .pag file. I'm not in any position to confirm whether the dbm module built with gdbm behaves the same way on other systems -information gratefully received on this topic. On the assumption that other platforms also have this behaviour, the attached patch attempts to detect whether a dbm DB has a gdbm signature just by checking the magic number of the .pag file. The patch involves a refactoring of the magic number code, which may be deemed inappropriate. It may be more expedient to just special case theEMX port in the dbm detection (by skipping looking for the .dir file on this platform). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766650&group_id=5470 From noreply@sourceforge.net Sun Jul 6 20:52:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 12:52:47 -0700 Subject: [Patches] [ python-Patches-542562 ] clean up trace.py Message-ID: Patches item #542562, was opened at 2002-04-11 09:34 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=542562&group_id=5470 Category: Demos and tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Skip Montanaro (montanaro) Summary: clean up trace.py Initial Comment: moderately interesting changes: * bugfix: remove "feature" of ignoring files in the tmpdir, as I was trying to run it on file in the tmpdir and couldn't figure out why it gave no answer! I think the original motivation for that feature (spurious "/tmp/" filenames for builtin functions??) has gone away, but I'm not sure. * add more usage docs and warning about common mistake pretty mundane changes: * remove unnecessary checks for backwards compatibility with a version that never escaped from my (Zooko's) laptop * add a future-compatible check: if the interpreter offers an attribute called `sys.optimized', and it is "true", and the user is trying to do something that can't be done with an optimizing interpreter, then error out ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-06 12:52 Message: Logged In: YES user_id=357491 Is this patch still relevant now that trace.py has been put into Lib? ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2002-12-18 11:38 Message: Logged In: YES user_id=52562 I merged my patch to current HEAD (-r1.12) and removed a bunch of it. Important changes (from current HEAD): * don't ignore files in $TMPDIR * add "--list-funcs" mode to usage string Minor changes (from current HEAD): * remove all code which was solely for backwards compatibility with a version that nobody except me ever had. * I updated some inline docs to point to sf.net/projects/pyutil instead of its ancestor sf.net/projects/mojonation. (Change from previous patch: I removed the part that mwh so gleefully pointed out that I aint gonna need.) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-22 06:21 Message: Logged In: YES user_id=6656 I haven't looked at the patch, but: > * add doc about usage and about how it will silently fail > if invoked with -O This probably isn't true any more. I hacked trace.py to use co_lnotab when I removed SET_LINENO. > * add a future-compatible check: if the interpreter > offers an attribute called `sys.optimized', and it is > "true", and the user is trying to do something that > can't be done with an optimizing interpreter, then > error out I want to shout "YAGNI!" for some reason... ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2002-11-22 06:14 Message: Logged In: YES user_id=52562 Here are the changes in 20995: * bugfix: remove "feature" of ignoring files in the tmpdir, as I was trying to run it on a file in the tmpdir and couldn't figure out why it gave no answer! I think the original motivation for that feature (spurious "/tmp/" filenames for builtin functions??) has gone away, but I'm not sure. * add feature "--listfuncs" which prints out whether each func was invoked or not, rather than how many times each func was invoked * remove unnecessary checks for backwards compatibility with a version that never escaped from my (Zooko's) laptop * add doc about usage and about how it will silently fail if invoked with -O * add a future-compatible check: if the interpreter offers an attribute called `sys.optimized', and it is "true", and the user is trying to do something that can't be done with an optimizing interpreter, then error out * add some commented-out debug print statements ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-22 01:14 Message: Logged In: YES user_id=21627 I have now applied file 25252 as trace.py 1.10. Skip, what is your opinion on file 20995? It applies cleanly and looks reasonable (even though I haven't tried to understand it all). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 14:21 Message: Logged In: YES user_id=21627 Skip, what kind of processing do you plan for this patch? ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2002-06-17 08:12 Message: Logged In: YES user_id=52562 This patch removes the change log, as per GvR's request. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2002-06-17 07:57 Message: Logged In: YES user_id=52562 I'll remove the change log and submit a patch momentarily. I'm afraid I cannot legally remove the copyright notice (or more precisely: my removing the copyright notice from the text would have no legal effect, and you can do it as well as I can), since I am not Autonomous Zones Industries, Inc. (AZI was my employer at the time I wrote and submitted that patch.) Regards, Zooko ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-14 03:27 Message: Logged In: YES user_id=21627 Can you also provide the other cleanup that Guido requested (change of license, removal of change logs, etc)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=542562&group_id=5470 From noreply@sourceforge.net Sun Jul 6 20:58:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 12:58:10 -0700 Subject: [Patches] [ python-Patches-543867 ] test for patch #543865 & others Message-ID: Patches item #543867, was opened at 2002-04-14 15:18 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=543867&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hernan Martinez Foffani (hfoffani) Assigned to: Nobody/Anonymous (nobody) Summary: test for patch #543865 & others Initial Comment: Here are 3 patches for: - test_complex.py: . add several checks to force execution of unvisited parts of complexobject.c code. . add a test for complex floor division corresponding bug #543387 and fix #543865 - test_complex_future.py . add test for "future" true division. (actually this is not a patch but the hole file) - test_b1.py . add test for bug #543840 and it's fix at patch #543865 Regards, -Hernan ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-06 12:58 Message: Logged In: YES user_id=357491 The patch is now severely outdated since test_complex.py has been converted to PyUnit, but it might be pertinent to go through the patch and see if any tests are there that could be added. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-22 11:38 Message: Logged In: YES user_id=112690 Regarding "the error msg for complex pow says "remainder"; it shouldn't" you are correct, the exception string has a bad wording. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-22 11:31 Message: Logged In: YES user_id=112690 On: vereq(a ** 105, a ** 105) ... etc ... The c code in complexobject.c has special cases when the exponent is > 100, < than -100, and in-between. I didn't want to test for equality with constants to avoid messing up with floating point issues. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-04-22 11:21 Message: Logged In: YES user_id=31435 I'm not sure what lines like vereq(a ** 105, a ** 105) vereq(b ** -105, b ** -105) vereq(b ** -30, b ** -30) are trying to test. That we get the same answer when we do exactly the same thing twice? Note that complex % has been deprecated: no point adding a test for a deprecated feature. The error msg for complex pow says "remainder"; it shouldn't. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-22 11:09 Message: Logged In: YES user_id=6380 OK, I've deleted them for you. Who do you expect to review this? ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-22 11:02 Message: Logged In: YES user_id=112690 Yes to both questions. I'm withdrawing test_complex.py and test_b1.py. I can't delete them and I double checked that I were correctly logged in as hfoffani. SourceForge error: File Delete: ArtifactFile: Permission Denied ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-22 10:51 Message: Logged In: YES user_id=6380 I don't understand your comment. Are you withdrawing the files test_complex.py and test_b1.py? Have you uploaded these to separate patch issues? You should be able to delete them as the original submitter; ifthis doesn't work, let me know and I'll do it. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-14 16:48 Message: Logged In: YES user_id=112690 Following Tim's advise to group together bug/fix/test, I'll leave this patch entry for improvements in the tests of complex numbers. Then the valid files are: 21173: test_complex_future.py and 21180: test_complex.diff3 ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-14 16:47 Message: Logged In: YES user_id=112690 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=543867&group_id=5470 From noreply@sourceforge.net Sun Jul 6 21:16:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 13:16:56 -0700 Subject: [Patches] [ python-Patches-597907 ] Oren Tirosh's fastnames patch Message-ID: Patches item #597907, was opened at 2002-08-20 12:20 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=597907&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 1 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: Oren Tirosh's fastnames patch Initial Comment: Oren Tirosh had a nice patch to *really* speed up global/builtin name lookup. I'm adding it here because I don't want to lose this idea. His code and some comments are here: http://www.tothink.com/python/fastnames/ I'm uploading a new version of this patch relative to current CVS. I'm still considering whether to do this; I measure at best a 1% speedup for pystone. For a modified version of Oren's benchmark (modified to use a function instead of a class for 'builtin' and 'global', so that these tests use LOAD_GLOBAL rather than LOAD_NAME, I get these test results (best of 3): builtin 1.38 global 1.54 local 1.28 fastlocal 0.90 Python 2.3 without his patch (but with my speedup hacks in LOAD_GLOBAL): builtin 1.80 global 1.52 local 1.77 fastlocal 0.91 Python 2.2 (from the 2.2 branch, which is newer than the 2.2.1 release but doesn't have any speedups) did this: builtin 2.28 global 1.86 local 1.80 fastlocal 1.10 I don't care about the speedup for the 'local' case, since this uses the LOAD_NAME opcode which is only used inside class definitions; the 'builtin' and 'global' cases are interesting. It looks like Oren's patch gives us a nice speedup for looking up a built-in name from a function. I have to think about why looking up a global from a function is slower though... ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-06 13:16 Message: Logged In: YES user_id=357491 What is the status of the mysterious new patch, Oren? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-15 08:54 Message: Logged In: YES user_id=6380 Hm, that patch doesn't have all the trickery here. Maybe Oren can explain what his intentions were? I don't have time to sort through all this -- if someone else wants to, that's fine (I've got a feeling Oren has other priorities these days). ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-11-14 22:01 Message: Logged In: YES user_id=250749 I notice Oren uploaded what appears to be an updated patch (fastnames5.patch) under patch #606098. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-11-14 21:57 Message: Logged In: YES user_id=250749 I notice Oren uploaded what appears to be an updated patch (fastnames5.patch) under patch #606098. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 09:31 Message: Logged In: YES user_id=6380 Lowered priority until Oren uploads his long-awaited new version. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-23 09:35 Message: Logged In: YES user_id=6380 Oren, any chance that you'll submit a new version of this? ---------------------------------------------------------------------- Comment By: Oren Tirosh (orenti) Date: 2002-09-03 13:22 Message: Logged In: YES user_id=562624 > I'm still considering whether to do this; I measure at > best a 1% speedup for pystone. No surprising considering the fact that pystone is dominated by fastlocals (IIRC it was something like 99.7% according to my instrumented version). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 11:29 Message: Logged In: YES user_id=6380 OK. I'm holding my breath! :-) ---------------------------------------------------------------------- Comment By: Oren Tirosh (orenti) Date: 2002-09-02 12:59 Message: Logged In: YES user_id=562624 I'm working on an improved version. Stay tuned! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-20 12:31 Message: Logged In: YES user_id=6380 Tim explained why the 'globals' case is faster than the 'builtins' case. I used 'x' as the global to look up rather than 'hex', and it so happens that the last three bits of hash('x') and hash('MANY') are the same -- MANY is an identifier I insert in the globals. I'll attach the test suite I used (with 'hex' instead of 'x'). Now I get these times: builtin 1.39 global 1.28 local 1.29 fastlocal 0.91 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=597907&group_id=5470 From noreply@sourceforge.net Sun Jul 6 21:28:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 13:28:50 -0700 Subject: [Patches] [ python-Patches-645894 ] better timer resolution for profile.py Message-ID: Patches item #645894, was opened at 2002-11-29 16:17 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645894&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: John-Mark Gurney (jmg) Assigned to: Nobody/Anonymous (nobody) Summary: better timer resolution for profile.py Initial Comment: On some platforms time.clock() does not return a high resolution counter. On FreeBSD, it's resolution is only 1/128th of a second. In order to get microsecond accuracy, the getrusage syscall from resource needs to be used. Attached is a patch that uses getrusage from the resource library in preference of os.clock. This was done on behalf of Vernier Networks, Inc. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-06 13:28 Message: Logged In: YES user_id=357491 Is there any possibility that using this could lead to worse timing under another OS? And I assume this is still an issue under FreeBSD 5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645894&group_id=5470 From noreply@sourceforge.net Sun Jul 6 21:33:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 13:33:21 -0700 Subject: [Patches] [ python-Patches-658316 ] skips.txt for regrtest.py Message-ID: Patches item #658316, was opened at 2002-12-24 12:03 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658316&group_id=5470 Category: Tests >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: skips.txt for regrtest.py Initial Comment: As I promised on python-dev here is the functionality to have a skips.txt file for regrtest.py. If the file is present in the current directory it is parsed (using the exact same code as used for the -f option for regrtest; good, old copy-n-paste) and all tests are added to the expected skip set. And as commented in the file, the name of the file is so named after Skip Montanaro because he is too shy. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-08 17:46 Message: Logged In: YES user_id=357491 OK, I am uploading a new patch but now it prints out if a test was not executed and then listed all the tests not executed. This is for several reasons. One is so you don't forget you have a skips.txt file and what tests are in it. You also don't get any possible confusion on why the test was not listed while the tests are being executed or if it was printed that it was actually run and passed. I also factored out the file parsing code used by the -f option to the function parsefile and use it for both -f and for parsing skips.txt . Can someone please just take a quick look and tell me that the "not executed" statements are reasonable? If someone gives me the all-clear I will apply the patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-23 15:27 Message: Logged In: YES user_id=357491 =) Sure thing. Noticed it was assigned to me and everything. Just need to add one feature; I want it to print out what tests were specifically skipped because of the skips.txt file so people don't forget that they have tests being skipped because of what they have in the file. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-23 11:33 Message: Logged In: YES user_id=80475 It is time to exercise your new commit priviledges. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-30 13:15 Message: Logged In: YES user_id=21627 Raymond, any further comments? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-12-29 17:37 Message: Logged In: YES user_id=357491 Oops. =) New diff includes a paragraph at the end of the module documentation that mentions how to use the new functionality. Please delete the old diff. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-12-28 21:09 Message: Logged In: YES user_id=80475 The patch looks good. Now, it needs documentation. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-12-26 13:04 Message: Logged In: YES user_id=357491 Sorry about that! I could have sworn I checked the box. I have uploaded enough files here you would think it would be habitual by now. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-26 10:10 Message: Logged In: YES user_id=33168 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658316&group_id=5470 From noreply@sourceforge.net Sun Jul 6 21:38:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 13:38:09 -0700 Subject: [Patches] [ python-Patches-663482 ] 658254: accept None for time.ctime() and friends Message-ID: Patches item #663482, was opened at 2003-01-06 19:42 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=663482&group_id=5470 Category: Modules >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Christopher Blunck (blunck2) Assigned to: Nobody/Anonymous (nobody) Summary: 658254: accept None for time.ctime() and friends Initial Comment: ctime(), gmtime(), and localtime() now support None and treat it as tho you passed no arguments at all. i am new to patching for py and am not sure if there are unit tests i should update. please advise... ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-06 13:38 Message: Logged In: YES user_id=357491 What do people think of this functionality? I personally don't see a need for it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 14:33 Message: Logged In: YES user_id=33168 There don't appear to be any direct tests, but it would still be nice to call the functions and verify they work ok. You could compare that abs(ctime() - ctime(None)) < .5, for example. Look in Lib/test/test_time.py. Also, the docs need to be updated, see Doc/lib/libtime.tex. That should be updated, ie change \optional(secs) with \optional{secs\code{ = None}}. Also, an entry in Misc/NEWS should be added since this is an API change. There is no attached file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=663482&group_id=5470 From noreply@sourceforge.net Sun Jul 6 21:32:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 13:32:14 -0700 Subject: [Patches] [ python-Patches-653938 ] Adds a builtin decimal type (FixedPoint) Message-ID: Patches item #653938, was opened at 2002-12-14 18:00 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=653938&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael McLay (mclay) Assigned to: Nobody/Anonymous (nobody) Summary: Adds a builtin decimal type (FixedPoint) Initial Comment: This patch integrates the fixedpoint module, that was created by Tim Peters, into Python as a first class object. That is, the patch adds this new number type so that it has direct syntax support like float, int, long, str., etc. within the interpreter. I use Tim's module to implement the type. This limits the patch to a small bit of code that adds the a syntax interface to this module. Syntax recognition for the new number format required a change to Parser/tokenizer.c and to Python/compile.c. This patch allows the new decimal type (I renamed the FixedPoint type to decimal in the fixedpoint.py file because the name is shorter and it is sufficient to distinguish the type from a binary float.) to be entered as a literal that is similar to a long, int, or float. The new syntax works as follows: >>> 12.00d 12.00d >>> .012d 0.012d >>> 1d 1.d >>> str(1.003d) '1.003' As you can see from the example, the default precision for decimal literals are determined by the precision entered expressed in the literal. The patch also adds glue to Python/bltinmodule.c to create a builtin decimal() function. This builtin decimal (Formally FixedPoint) function invokes the constructor of the Python implementation of the decimal class defined in the fixedpoint module. The implementation follows the familiar pattern for adding special builtin functions, much like the implementation of apply and abs. It does not follow the typical method for adding built in types. That would require a more invasive patch. The builtin decimal function works as follows: >>> decimal(1.333) 1.33d >>> decimal(1.333,4) 1.3330d >>> decimal(400,2) 400.00d The semantics of the precision parameter may be incorrect because it is only addressing the precision of the fraction part of the number. Shouldn't it reflect the number of significant digits? If that were the case then the following would have been the result: >>> decimal(400,2) 4.0e2d This problem is more noticable when exponents are large relative to the number of significant digits. For instance: >>> 40.e3d 40000.d The result should have been 40.e3d, not 40000. This implies more precision than is declared by the constant. As it currently is implemented the type pads with zeros on the integer side of the decimal point, whic implies more accuracy in the number than is true. I ran into this problem when I tried to implement the automatic conversion of string number values to decimal representation for numbers in 'e' format. >>> 3.03e5d 303000.00d The representation is incorrect. It should have returned 3.03e5d but it padded the result with bogus zeros. For this first cut at a new decimal type I am primarily interested in investigating the semantics of the new native decimal number type in Python. This type will be useful to bankers, accountants, and newbies. The backend implementation could be replaced with a C implementation without affecting the Python language semantics. The approach used in this patch makes it very easy to experiment with changes to the semantics because all of the experimentation can be done by changing the code in Lib/fixedpoint.py. The compiled wrapper doesn't have to be modified and recompiled. Unit testing so far just reuses the _test function in the fixedpoint.py module. Since I am not sure which way to go with the semantic interpretation of precision I decided to post the patch before making a significant change to fixedpoint.py. Some feedback on the interpretation of precision would be appreciated. Documentation: The following needs to be added to section 2.1 of the library reference manual: decimal(value, precision) Convert a string or a number to fixed point decimal number. If the argument is a string, it must contain a possibly signed decimal or floating point number, possibly embedded in whitespace. The precision parameter will be ignored on string values. The precision will be set based on the number of significant digits. Otherwise, the argument may be a plain or long integer or a floating point number, and a decimal number with the same value ( the precision attribute will set the precision of the fraction roundoff) is returned. Section 3.1.1 of the tutorial will add a brief description of decimal number usage after the description of floating point: There is full support for floating point; operators with mixed type operands convert the integer operand to floating point: >>> 3 * 3.75 / 1.5 7.5 >>> 7.0 / 2 3.5 Python also supports fixed point decimal numbers. These numbers do not suffer from the somewhat random roundoff errors that can occur with binary floating point numbers. A decimal number is created by adding a 'd' or 'D' suffix to a number: >>> 3.3d + 3d 6.3d >>> 3.3d + 3.03 6.3d >>> 3.3d + decimal(3.03,3) 6.330d >>> decimal(1.1, 16) 1.1000000000000001d >>> The builtin decimal constructor provides a means for converting float and int types to decimal types. Since floats are approximations of decimal floating point numbers there are often roundoff errors introduced by using floats. (The 1 in the last place of the conversion of 1.1 with 16 digits is a binary round off error.) For this reason the decimal function requires the specification of precision when converting a float to a decimal. This allows the significant digits of the number to be specified. (Accountants and bankers love this because it allows them to balance the books without pennies being lost due to the use of binary numbers.) >>> 3.3d/2 1.6d Note that in the example above the expression 3.3d/2 returned 1.6d. The rounding scheme for Python decimals uses "banking" rounding rules. With floating point numbers the result would have been as follows: >>> 3.3/2 1.6499999999999999 So as you can see the banking rules round off the .04999999999 portion of the number and calls it a an even 1.6. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-06 13:32 Message: Logged In: YES user_id=357491 Is this patch worth keeping open now that we have nondist/ sandbox/decimal/ ? Or are these two implementations going to duke it out in the end? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-12-28 21:18 Message: Logged In: YES user_id=80475 I don't think a syntax change is warranted. Most use cases I can think of do not have decimal constants in the program; rather, they are always data. FixedPoint is valuable in and of itself without any need for a new syntax. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-15 01:07 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=653938&group_id=5470 From noreply@sourceforge.net Sun Jul 6 21:55:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 13:55:59 -0700 Subject: [Patches] [ python-Patches-597907 ] Oren Tirosh's fastnames patch Message-ID: Patches item #597907, was opened at 2002-08-20 19:20 Message generated for change (Comment added) made by orenti You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=597907&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 1 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: Oren Tirosh's fastnames patch Initial Comment: Oren Tirosh had a nice patch to *really* speed up global/builtin name lookup. I'm adding it here because I don't want to lose this idea. His code and some comments are here: http://www.tothink.com/python/fastnames/ I'm uploading a new version of this patch relative to current CVS. I'm still considering whether to do this; I measure at best a 1% speedup for pystone. For a modified version of Oren's benchmark (modified to use a function instead of a class for 'builtin' and 'global', so that these tests use LOAD_GLOBAL rather than LOAD_NAME, I get these test results (best of 3): builtin 1.38 global 1.54 local 1.28 fastlocal 0.90 Python 2.3 without his patch (but with my speedup hacks in LOAD_GLOBAL): builtin 1.80 global 1.52 local 1.77 fastlocal 0.91 Python 2.2 (from the 2.2 branch, which is newer than the 2.2.1 release but doesn't have any speedups) did this: builtin 2.28 global 1.86 local 1.80 fastlocal 1.10 I don't care about the speedup for the 'local' case, since this uses the LOAD_NAME opcode which is only used inside class definitions; the 'builtin' and 'global' cases are interesting. It looks like Oren's patch gives us a nice speedup for looking up a built-in name from a function. I have to think about why looking up a global from a function is slower though... ---------------------------------------------------------------------- Comment By: Oren Tirosh (orenti) Date: 2003-07-06 20:55 Message: Logged In: YES user_id=562624 I have announced a few month ago on the list that I am no longer working on it. If anyone wants to take over I'd be happy to explain the ideas I had for further development of this patch to usable state and better performance. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-06 20:16 Message: Logged In: YES user_id=357491 What is the status of the mysterious new patch, Oren? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-15 16:54 Message: Logged In: YES user_id=6380 Hm, that patch doesn't have all the trickery here. Maybe Oren can explain what his intentions were? I don't have time to sort through all this -- if someone else wants to, that's fine (I've got a feeling Oren has other priorities these days). ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-11-15 06:01 Message: Logged In: YES user_id=250749 I notice Oren uploaded what appears to be an updated patch (fastnames5.patch) under patch #606098. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-11-15 05:57 Message: Logged In: YES user_id=250749 I notice Oren uploaded what appears to be an updated patch (fastnames5.patch) under patch #606098. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 17:31 Message: Logged In: YES user_id=6380 Lowered priority until Oren uploads his long-awaited new version. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-23 16:35 Message: Logged In: YES user_id=6380 Oren, any chance that you'll submit a new version of this? ---------------------------------------------------------------------- Comment By: Oren Tirosh (orenti) Date: 2002-09-03 20:22 Message: Logged In: YES user_id=562624 > I'm still considering whether to do this; I measure at > best a 1% speedup for pystone. No surprising considering the fact that pystone is dominated by fastlocals (IIRC it was something like 99.7% according to my instrumented version). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 18:29 Message: Logged In: YES user_id=6380 OK. I'm holding my breath! :-) ---------------------------------------------------------------------- Comment By: Oren Tirosh (orenti) Date: 2002-09-02 19:59 Message: Logged In: YES user_id=562624 I'm working on an improved version. Stay tuned! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-20 19:31 Message: Logged In: YES user_id=6380 Tim explained why the 'globals' case is faster than the 'builtins' case. I used 'x' as the global to look up rather than 'hex', and it so happens that the last three bits of hash('x') and hash('MANY') are the same -- MANY is an identifier I insert in the globals. I'll attach the test suite I used (with 'hex' instead of 'x'). Now I get these times: builtin 1.39 global 1.28 local 1.29 fastlocal 0.91 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=597907&group_id=5470 From noreply@sourceforge.net Mon Jul 7 01:08:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 17:08:21 -0700 Subject: [Patches] [ python-Patches-542562 ] clean up trace.py Message-ID: Patches item #542562, was opened at 2002-04-11 16:34 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=542562&group_id=5470 Category: Demos and tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Skip Montanaro (montanaro) Summary: clean up trace.py Initial Comment: moderately interesting changes: * bugfix: remove "feature" of ignoring files in the tmpdir, as I was trying to run it on file in the tmpdir and couldn't figure out why it gave no answer! I think the original motivation for that feature (spurious "/tmp/" filenames for builtin functions??) has gone away, but I'm not sure. * add more usage docs and warning about common mistake pretty mundane changes: * remove unnecessary checks for backwards compatibility with a version that never escaped from my (Zooko's) laptop * add a future-compatible check: if the interpreter offers an attribute called `sys.optimized', and it is "true", and the user is trying to do something that can't be done with an optimizing interpreter, then error out ---------------------------------------------------------------------- >Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-07 00:08 Message: Logged In: YES user_id=52562 Tools/scripts/trace.py should be removed. I'm going to submit a couple of small cleanups to Lib/trace.py. (I wasn't aware that trace.py had been moved to Lib until recently.) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-06 19:52 Message: Logged In: YES user_id=357491 Is this patch still relevant now that trace.py has been put into Lib? ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2002-12-18 19:38 Message: Logged In: YES user_id=52562 I merged my patch to current HEAD (-r1.12) and removed a bunch of it. Important changes (from current HEAD): * don't ignore files in $TMPDIR * add "--list-funcs" mode to usage string Minor changes (from current HEAD): * remove all code which was solely for backwards compatibility with a version that nobody except me ever had. * I updated some inline docs to point to sf.net/projects/pyutil instead of its ancestor sf.net/projects/mojonation. (Change from previous patch: I removed the part that mwh so gleefully pointed out that I aint gonna need.) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-22 14:21 Message: Logged In: YES user_id=6656 I haven't looked at the patch, but: > * add doc about usage and about how it will silently fail > if invoked with -O This probably isn't true any more. I hacked trace.py to use co_lnotab when I removed SET_LINENO. > * add a future-compatible check: if the interpreter > offers an attribute called `sys.optimized', and it is > "true", and the user is trying to do something that > can't be done with an optimizing interpreter, then > error out I want to shout "YAGNI!" for some reason... ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2002-11-22 14:14 Message: Logged In: YES user_id=52562 Here are the changes in 20995: * bugfix: remove "feature" of ignoring files in the tmpdir, as I was trying to run it on a file in the tmpdir and couldn't figure out why it gave no answer! I think the original motivation for that feature (spurious "/tmp/" filenames for builtin functions??) has gone away, but I'm not sure. * add feature "--listfuncs" which prints out whether each func was invoked or not, rather than how many times each func was invoked * remove unnecessary checks for backwards compatibility with a version that never escaped from my (Zooko's) laptop * add doc about usage and about how it will silently fail if invoked with -O * add a future-compatible check: if the interpreter offers an attribute called `sys.optimized', and it is "true", and the user is trying to do something that can't be done with an optimizing interpreter, then error out * add some commented-out debug print statements ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-22 09:14 Message: Logged In: YES user_id=21627 I have now applied file 25252 as trace.py 1.10. Skip, what is your opinion on file 20995? It applies cleanly and looks reasonable (even though I haven't tried to understand it all). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 21:21 Message: Logged In: YES user_id=21627 Skip, what kind of processing do you plan for this patch? ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2002-06-17 15:12 Message: Logged In: YES user_id=52562 This patch removes the change log, as per GvR's request. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2002-06-17 14:57 Message: Logged In: YES user_id=52562 I'll remove the change log and submit a patch momentarily. I'm afraid I cannot legally remove the copyright notice (or more precisely: my removing the copyright notice from the text would have no legal effect, and you can do it as well as I can), since I am not Autonomous Zones Industries, Inc. (AZI was my employer at the time I wrote and submitted that patch.) Regards, Zooko ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-14 10:27 Message: Logged In: YES user_id=21627 Can you also provide the other cleanup that Guido requested (change of license, removal of change logs, etc)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=542562&group_id=5470 From noreply@sourceforge.net Mon Jul 7 01:17:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 17:17:08 -0700 Subject: [Patches] [ python-Patches-766877 ] remove unnecessary code in trace.py Message-ID: Patches item #766877, was opened at 2003-07-07 00: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=766877&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: remove unnecessary code in trace.py Initial Comment: I once experimented with a different trace file format on my own computer, and made trace.py accept both my own experimental format and the normal one. I accidentally left this feature in when I submitted an improved version of trace.py for inclusion in Python, but it has never been needed, as nobody other than me has ever used this alternate trace file format. This patch removes this feature. This patch is untested by me, and not very important, so it wouldn't hurt if it went solely onto the Python 2.4 branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766877&group_id=5470 From noreply@sourceforge.net Mon Jul 7 01:20:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 17:20:32 -0700 Subject: [Patches] [ python-Patches-766879 ] Building HTML Docs Requires Perl 5.6 Message-ID: Patches item #766879, was opened at 2003-07-06 19:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766879&group_id=5470 Category: Documentation Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Nobody/Anonymous (nobody) Summary: Building HTML Docs Requires Perl 5.6 Initial Comment: Adding "use warnings" to .../Doc/perl/python.perl apparently raises the Perl requirement to 5.6.0: File Edit Options Buffers Tools Help Loading /usr/local/lib/latex2html/versions/html4_0.pl *** processing declarations *** Loading /usr/local/lib/latex2html/versions/latin1.pl Adding /home/kbk/PYTHON/python/dist/src/Doc/api to $TEXINPUTS OPENING /home/kbk/PYTHON/python/dist/src/Doc/api/api.tex Cannot create directory /home/kbk/PYTHON/python/dist/src/Doc/html/api/: File ex\ists, reusing it. Note: Working directory is /home/kbk/PYTHON/python/dist/src/Doc/html/api Note: Images will be generated in /tmp/l2h16111 texexpand V99.2beta8 (Revision 1.11) Loading /usr/local/lib/latex2html/styles/texdefs.perl... Loading /home/kbk/PYTHON/python/dist/src/Doc/perl/manual.perl Loading /usr/local/lib/latex2html/styles/report.perl Loading /usr/local/lib/latex2html/styles/alltt.perl Loading /home/kbk/PYTHON/python/dist/src/Doc/perl/python.perlCan't locate warni\ngs.pm in @INC (@INC contains: /usr/lib/perl5/5.00503/i386-linux /usr/lib/perl5\/5.00503 /usr/lib/perl5/site_perl/5.005/i386-linux /usr/lib/perl5/site_perl/5.0\05 . /usr/local/lib/latex2html /home/kbk /home/kbk/PYTHON/python/dist/src/Doc/p\erl /home/kbk/PYTHON/python/dist/src/Doc/perl) at /home/kbk/PYTHON/python/dist/\src/Doc/perl/python.perl line 11, chunk 1. BEGIN failed--compilation aborted at /home/kbk/PYTHON/python/dist/src/Doc/perl/\python.perl line 11, chunk 1. *** Session transcript and error messages are in /home/kbk/PYTHON/python/dist/s\rc/Doc/html/api/api.how. *** Exited with status 2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766879&group_id=5470 From noreply@sourceforge.net Mon Jul 7 01:22:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 17:22:04 -0700 Subject: [Patches] [ python-Patches-766879 ] Building HTML Docs Requires Perl 5.6 Message-ID: Patches item #766879, was opened at 2003-07-06 19:20 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766879&group_id=5470 Category: Documentation >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Nobody/Anonymous (nobody) Summary: Building HTML Docs Requires Perl 5.6 Initial Comment: Adding "use warnings" to .../Doc/perl/python.perl apparently raises the Perl requirement to 5.6.0: File Edit Options Buffers Tools Help Loading /usr/local/lib/latex2html/versions/html4_0.pl *** processing declarations *** Loading /usr/local/lib/latex2html/versions/latin1.pl Adding /home/kbk/PYTHON/python/dist/src/Doc/api to $TEXINPUTS OPENING /home/kbk/PYTHON/python/dist/src/Doc/api/api.tex Cannot create directory /home/kbk/PYTHON/python/dist/src/Doc/html/api/: File ex\ists, reusing it. Note: Working directory is /home/kbk/PYTHON/python/dist/src/Doc/html/api Note: Images will be generated in /tmp/l2h16111 texexpand V99.2beta8 (Revision 1.11) Loading /usr/local/lib/latex2html/styles/texdefs.perl... Loading /home/kbk/PYTHON/python/dist/src/Doc/perl/manual.perl Loading /usr/local/lib/latex2html/styles/report.perl Loading /usr/local/lib/latex2html/styles/alltt.perl Loading /home/kbk/PYTHON/python/dist/src/Doc/perl/python.perlCan't locate warni\ngs.pm in @INC (@INC contains: /usr/lib/perl5/5.00503/i386-linux /usr/lib/perl5\/5.00503 /usr/lib/perl5/site_perl/5.005/i386-linux /usr/lib/perl5/site_perl/5.0\05 . /usr/local/lib/latex2html /home/kbk /home/kbk/PYTHON/python/dist/src/Doc/p\erl /home/kbk/PYTHON/python/dist/src/Doc/perl) at /home/kbk/PYTHON/python/dist/\src/Doc/perl/python.perl line 11, chunk 1. BEGIN failed--compilation aborted at /home/kbk/PYTHON/python/dist/src/Doc/perl/\python.perl line 11, chunk 1. *** Session transcript and error messages are in /home/kbk/PYTHON/python/dist/s\rc/Doc/html/api/api.how. *** Exited with status 2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766879&group_id=5470 From noreply@sourceforge.net Mon Jul 7 01:33:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 17:33:51 -0700 Subject: [Patches] [ python-Patches-766889 ] Document thread.interrupt_main() Message-ID: Patches item #766889, was opened at 2003-07-06 19: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=766889&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Nobody/Anonymous (nobody) Summary: Document thread.interrupt_main() Initial Comment: interrupt_main function added at 2.3b2 Also: Removed the reference to the deprecated exit_thread() function...other deprecated function references have been previously removed from the documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766889&group_id=5470 From noreply@sourceforge.net Mon Jul 7 01:47:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 17:47:41 -0700 Subject: [Patches] [ python-Patches-753733 ] sys.interrupt_main() Message-ID: Patches item #753733, was opened at 2003-06-12 23:56 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=753733&group_id=5470 Category: Core (C code) >Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Kurt B. Kaiser (kbk) Summary: sys.interrupt_main() Initial Comment: Patch implements this function. Needed for interrupting IDLE subprocess when running on win32. Better here than in a separate module. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-06 19:47 Message: Logged In: YES user_id=149084 This has found a home at thread.interrupt_main() Brett Cannon updated NEWS Lib documentation in Patch 766889 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-13 07:03 Message: Logged In: YES user_id=33168 One thing that should be changed is METH_VARARGS should be METH_NOARGS (this problem was in the original code). The sys doc should be updated (Doc/lib/libsys.tex) to mention interupt*(). Probably a NEWS entry should be made too. Otherwise the patch is fine, but I didn't see a resolution on changing the name to interupt vs interupt_main. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-06-13 00:05 Message: Logged In: YES user_id=149084 Urm, check the box! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=753733&group_id=5470 From noreply@sourceforge.net Mon Jul 7 02:46:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 18:46:30 -0700 Subject: [Patches] [ python-Patches-766910 ] fix one or two bugs in trace.py Message-ID: Patches item #766910, was opened at 2003-07-07 01: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=766910&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: fix one or two bugs in trace.py Initial Comment: There is one bug and one maybe-bug in creation of the coverage file directory in trace.py. The maybe-bug is that it doesn't attempt to create the directory if it got the directory name from the name of the .py file (instead of getting the directory name from the --coverdir command line option). Normally the directory will already exist, but if you are writing out coverage files from a stored report (or, I suppose, if someone deleted the directory after the modules were loaded but before you wrote out the report), then it won't. This patch makes it so that it always attempts to create the directory before attempting to write files into it. The patch also adds a statement to that effect to the "--help" usage info. The other bug is that it attempts to create a directory with: if not os.path.exists(dir): os.makedirs(dir) , which is a race condition that will very rarely raise a spurious exception ("File exists:") if two threads or processes execute it at the same time. The fix provided in this patch is to copy from my pyutil project [1] a utility function that works around this race condition and invoke that function. On request I'll provide a slimmed-down version of that function, since we don't use all of its options in trace.py. This patch hasn't been tested at ALL. In fact, I haven't tested trace.py in general since before it moved from Tools/scripts to Lib/. As this patch ought to go into Python 2.3, it ought to be tested, and I promise to do so soon. [1] http://sf.net/projects/pyutil ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766910&group_id=5470 From noreply@sourceforge.net Mon Jul 7 02:50:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 18:50:46 -0700 Subject: [Patches] [ python-Patches-766877 ] remove unnecessary code in trace.py Message-ID: Patches item #766877, was opened at 2003-07-07 00:17 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766877&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: remove unnecessary code in trace.py Initial Comment: I once experimented with a different trace file format on my own computer, and made trace.py accept both my own experimental format and the normal one. I accidentally left this feature in when I submitted an improved version of trace.py for inclusion in Python, but it has never been needed, as nobody other than me has ever used this alternate trace file format. This patch removes this feature. This patch is untested by me, and not very important, so it wouldn't hurt if it went solely onto the Python 2.4 branch. ---------------------------------------------------------------------- >Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-07 01:50 Message: Logged In: YES user_id=52562 Here's a BETTER version of this patch. Better because it also removes the comment describing this useless feature in addition to removing the useless feature. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766877&group_id=5470 From noreply@sourceforge.net Mon Jul 7 02:53:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 18:53:39 -0700 Subject: [Patches] [ python-Patches-542562 ] clean up trace.py Message-ID: Patches item #542562, was opened at 2002-04-11 11:34 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=542562&group_id=5470 Category: Demos and tools Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Skip Montanaro (montanaro) Summary: clean up trace.py Initial Comment: moderately interesting changes: * bugfix: remove "feature" of ignoring files in the tmpdir, as I was trying to run it on file in the tmpdir and couldn't figure out why it gave no answer! I think the original motivation for that feature (spurious "/tmp/" filenames for builtin functions??) has gone away, but I'm not sure. * add more usage docs and warning about common mistake pretty mundane changes: * remove unnecessary checks for backwards compatibility with a version that never escaped from my (Zooko's) laptop * add a future-compatible check: if the interpreter offers an attribute called `sys.optimized', and it is "true", and the user is trying to do something that can't be done with an optimizing interpreter, then error out ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-07-06 20:53 Message: Logged In: YES user_id=44345 Zooko, I'm going to close this one. A lot of water has passed under the trace.py bridge since you first submitted it. Let's start afresh with a new patch. -Skip ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-06 19:08 Message: Logged In: YES user_id=52562 Tools/scripts/trace.py should be removed. I'm going to submit a couple of small cleanups to Lib/trace.py. (I wasn't aware that trace.py had been moved to Lib until recently.) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-06 14:52 Message: Logged In: YES user_id=357491 Is this patch still relevant now that trace.py has been put into Lib? ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2002-12-18 13:38 Message: Logged In: YES user_id=52562 I merged my patch to current HEAD (-r1.12) and removed a bunch of it. Important changes (from current HEAD): * don't ignore files in $TMPDIR * add "--list-funcs" mode to usage string Minor changes (from current HEAD): * remove all code which was solely for backwards compatibility with a version that nobody except me ever had. * I updated some inline docs to point to sf.net/projects/pyutil instead of its ancestor sf.net/projects/mojonation. (Change from previous patch: I removed the part that mwh so gleefully pointed out that I aint gonna need.) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-22 08:21 Message: Logged In: YES user_id=6656 I haven't looked at the patch, but: > * add doc about usage and about how it will silently fail > if invoked with -O This probably isn't true any more. I hacked trace.py to use co_lnotab when I removed SET_LINENO. > * add a future-compatible check: if the interpreter > offers an attribute called `sys.optimized', and it is > "true", and the user is trying to do something that > can't be done with an optimizing interpreter, then > error out I want to shout "YAGNI!" for some reason... ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2002-11-22 08:14 Message: Logged In: YES user_id=52562 Here are the changes in 20995: * bugfix: remove "feature" of ignoring files in the tmpdir, as I was trying to run it on a file in the tmpdir and couldn't figure out why it gave no answer! I think the original motivation for that feature (spurious "/tmp/" filenames for builtin functions??) has gone away, but I'm not sure. * add feature "--listfuncs" which prints out whether each func was invoked or not, rather than how many times each func was invoked * remove unnecessary checks for backwards compatibility with a version that never escaped from my (Zooko's) laptop * add doc about usage and about how it will silently fail if invoked with -O * add a future-compatible check: if the interpreter offers an attribute called `sys.optimized', and it is "true", and the user is trying to do something that can't be done with an optimizing interpreter, then error out * add some commented-out debug print statements ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-22 03:14 Message: Logged In: YES user_id=21627 I have now applied file 25252 as trace.py 1.10. Skip, what is your opinion on file 20995? It applies cleanly and looks reasonable (even though I haven't tried to understand it all). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 16:21 Message: Logged In: YES user_id=21627 Skip, what kind of processing do you plan for this patch? ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2002-06-17 10:12 Message: Logged In: YES user_id=52562 This patch removes the change log, as per GvR's request. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2002-06-17 09:57 Message: Logged In: YES user_id=52562 I'll remove the change log and submit a patch momentarily. I'm afraid I cannot legally remove the copyright notice (or more precisely: my removing the copyright notice from the text would have no legal effect, and you can do it as well as I can), since I am not Autonomous Zones Industries, Inc. (AZI was my employer at the time I wrote and submitted that patch.) Regards, Zooko ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-14 05:27 Message: Logged In: YES user_id=21627 Can you also provide the other cleanup that Guido requested (change of license, removal of change logs, etc)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=542562&group_id=5470 From noreply@sourceforge.net Mon Jul 7 13:32:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 05:32:57 -0700 Subject: [Patches] [ python-Patches-765238 ] fix fnmatch.__all__ Message-ID: Patches item #765238, was opened at 2003-07-03 19:54 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=765238&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: Postponed Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: fix fnmatch.__all__ Initial Comment: There are two reasons for this patch. First, in the fnmatch.py, __all__ doesn't include "filter", so if you tried to use fnmatch.filter like this, >>> from fnmatch import * >>> filter built-in function, filter, is called instead of fnmatch.filter. >>> filter Second, "translate" is just a helper function used by other functions in the fnmatch module, and that's why it's not documented in the Python library reference. I think "translate" should be removed from fnmatch.__all__. ---------------------------------------------------------------------- >Comment By: George Yoshida (quiver) Date: 2003-07-07 21:32 Message: Logged In: YES user_id=671362 > this is an interface change. If you're reluctant to remove "translate", that's OK. I just propose to add "filter" to __all__. That won't do any harm. > I feel that it is too late for 2.3: I don't feel it's too late for 2.3. There's at least one month left before the final release of 2.3. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-06 01:02 Message: Logged In: YES user_id=21627 While I agree with that, I feel that it is too late for 2.3: this is an interface change. So postponing it to 2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=765238&group_id=5470 From noreply@sourceforge.net Mon Jul 7 16:52:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 08:52:57 -0700 Subject: [Patches] [ python-Patches-766877 ] remove unnecessary code in trace.py Message-ID: Patches item #766877, was opened at 2003-07-07 00:17 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766877&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) >Assigned to: Jeremy Hylton (jhylton) Summary: remove unnecessary code in trace.py Initial Comment: I once experimented with a different trace file format on my own computer, and made trace.py accept both my own experimental format and the normal one. I accidentally left this feature in when I submitted an improved version of trace.py for inclusion in Python, but it has never been needed, as nobody other than me has ever used this alternate trace file format. This patch removes this feature. This patch is untested by me, and not very important, so it wouldn't hurt if it went solely onto the Python 2.4 branch. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-07 01:50 Message: Logged In: YES user_id=52562 Here's a BETTER version of this patch. Better because it also removes the comment describing this useless feature in addition to removing the useless feature. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766877&group_id=5470 From noreply@sourceforge.net Mon Jul 7 17:11:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 09:11:10 -0700 Subject: [Patches] [ python-Patches-766877 ] remove unnecessary code in trace.py Message-ID: Patches item #766877, was opened at 2003-07-07 00:17 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766877&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Jeremy Hylton (jhylton) Summary: remove unnecessary code in trace.py Initial Comment: I once experimented with a different trace file format on my own computer, and made trace.py accept both my own experimental format and the normal one. I accidentally left this feature in when I submitted an improved version of trace.py for inclusion in Python, but it has never been needed, as nobody other than me has ever used this alternate trace file format. This patch removes this feature. This patch is untested by me, and not very important, so it wouldn't hurt if it went solely onto the Python 2.4 branch. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-07 01:50 Message: Logged In: YES user_id=52562 Here's a BETTER version of this patch. Better because it also removes the comment describing this useless feature in addition to removing the useless feature. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766877&group_id=5470 From noreply@sourceforge.net Mon Jul 7 22:59:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 14:59:05 -0700 Subject: [Patches] [ python-Patches-766889 ] Document thread.interrupt_main() Message-ID: Patches item #766889, was opened at 2003-07-07 02:33 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766889&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Kurt B. Kaiser (kbk) >Assigned to: Kurt B. Kaiser (kbk) Summary: Document thread.interrupt_main() Initial Comment: interrupt_main function added at 2.3b2 Also: Removed the reference to the deprecated exit_thread() function...other deprecated function references have been previously removed from the documentation. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-07 23:59 Message: Logged In: YES user_id=21627 This is fine, please apply. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766889&group_id=5470 From noreply@sourceforge.net Mon Jul 7 23:00:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 15:00:00 -0700 Subject: [Patches] [ python-Patches-766879 ] Building HTML Docs Requires Perl 5.6 Message-ID: Patches item #766879, was opened at 2003-07-07 02:20 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766879&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Kurt B. Kaiser (kbk) >Assigned to: Kurt B. Kaiser (kbk) Summary: Building HTML Docs Requires Perl 5.6 Initial Comment: Adding "use warnings" to .../Doc/perl/python.perl apparently raises the Perl requirement to 5.6.0: File Edit Options Buffers Tools Help Loading /usr/local/lib/latex2html/versions/html4_0.pl *** processing declarations *** Loading /usr/local/lib/latex2html/versions/latin1.pl Adding /home/kbk/PYTHON/python/dist/src/Doc/api to $TEXINPUTS OPENING /home/kbk/PYTHON/python/dist/src/Doc/api/api.tex Cannot create directory /home/kbk/PYTHON/python/dist/src/Doc/html/api/: File ex\ists, reusing it. Note: Working directory is /home/kbk/PYTHON/python/dist/src/Doc/html/api Note: Images will be generated in /tmp/l2h16111 texexpand V99.2beta8 (Revision 1.11) Loading /usr/local/lib/latex2html/styles/texdefs.perl... Loading /home/kbk/PYTHON/python/dist/src/Doc/perl/manual.perl Loading /usr/local/lib/latex2html/styles/report.perl Loading /usr/local/lib/latex2html/styles/alltt.perl Loading /home/kbk/PYTHON/python/dist/src/Doc/perl/python.perlCan't locate warni\ngs.pm in @INC (@INC contains: /usr/lib/perl5/5.00503/i386-linux /usr/lib/perl5\/5.00503 /usr/lib/perl5/site_perl/5.005/i386-linux /usr/lib/perl5/site_perl/5.0\05 . /usr/local/lib/latex2html /home/kbk /home/kbk/PYTHON/python/dist/src/Doc/p\erl /home/kbk/PYTHON/python/dist/src/Doc/perl) at /home/kbk/PYTHON/python/dist/\src/Doc/perl/python.perl line 11, chunk 1. BEGIN failed--compilation aborted at /home/kbk/PYTHON/python/dist/src/Doc/perl/\python.perl line 11, chunk 1. *** Session transcript and error messages are in /home/kbk/PYTHON/python/dist/s\rc/Doc/html/api/api.how. *** Exited with status 2. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-08 00:00 Message: Logged In: YES user_id=21627 The patch is fine, please apply. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766879&group_id=5470 From noreply@sourceforge.net Mon Jul 7 23:05:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 15:05:12 -0700 Subject: [Patches] [ python-Patches-766650 ] whichdb not ID'ing dbm files with GDBM backend Message-ID: Patches item #766650, was opened at 2003-07-06 13:09 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766650&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Nobody/Anonymous (nobody) Summary: whichdb not ID'ing dbm files with GDBM backend Initial Comment: For the OS/2 EMX port, I build the dbm module with gdbm v1.7.3. At least with the OS/2 version of the gdbm v1.7.3 port, dbm databases consist only of the .pag file - there is no .dir file. In this case, the .pag file has the gdbm magic number. Currently whichdb fails to identify such dbm DBs on this platform because of the expectation that there be a .dir file as well as the .pag file. I'm not in any position to confirm whether the dbm module built with gdbm behaves the same way on other systems -information gratefully received on this topic. On the assumption that other platforms also have this behaviour, the attached patch attempts to detect whether a dbm DB has a gdbm signature just by checking the magic number of the .pag file. The patch involves a refactoring of the magic number code, which may be deemed inappropriate. It may be more expedient to just special case theEMX port in the dbm detection (by skipping looking for the .dir file on this platform). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-08 00:05 Message: Logged In: YES user_id=21627 The dbm module greatly varies in behaviour across platforms, depending on what underlying library is linked. On my Linux installation, the resulting files are identified as /tmp/u.dir: GNU dbm 1.x or ndbm database, little endian /tmp/u.pag: GNU dbm 1.x or ndbm database, little endian I recommend that you adjust your patch to take dbm.library into account, and go looking for gdbm magic only if you find that dbm is linked with gdbm. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766650&group_id=5470 From noreply@sourceforge.net Mon Jul 7 23:07:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 15:07:01 -0700 Subject: [Patches] [ python-Patches-742290 ] unicode "support" for shlex.py Message-ID: Patches item #742290, was opened at 2003-05-23 14:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742290&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: unicode "support" for shlex.py Initial Comment: Due to shlex.py's use of cStringIO, it behaves badly when fed unicode strings. The attached patch fixes that by always using StringIO instead of cStringIO. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-08 00:07 Message: Logged In: YES user_id=21627 I'll reject that patch for now. If you manage to complete it, feel free to reopen or submit a new one. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 14:32 Message: Logged In: YES user_id=21627 To test whether a letter is a wordchar, you should check whether it .isalnum() or equals '_'. Then you can do away with self.wordchars, and it works the same for byte strings and Unicode strings. Non-ASCII characters in byte strings then work if locale.setlocale had been invoked. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-23 14:57 Message: Logged In: YES user_id=92689 Ugh, I take that back: it doesn't fix it, there's a gross snippet in shlex.py that makes it barf: if self.posix: self.wordchars += ('??·???ÂÊÁËÈÍÎÏÌÓÔ?ÒÚÛÙ??¯???¸???' '¿¡¬????«»? ÀÃÕ????????÷ÿ??????') Help. I'd love to fix this, but I'm not sure what would be correct (my intuition says to just yank the above snippet, but I'm sure that'll make _someone_ unhappy...). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=742290&group_id=5470 From noreply@sourceforge.net Tue Jul 8 09:04:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 01:04:32 -0700 Subject: [Patches] [ python-Patches-767600 ] Add a 'isotime' format to standard logging Message-ID: Patches item #767600, was opened at 2003-07-08 18: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=767600&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: Add a 'isotime' format to standard logging Initial Comment: This patch adds a standard format string 'isotime' to go alongside 'asctime' in the standard logging module. The 'asctime' format is somewhat idiosyncratic (for instance the seconds,milliseconds part). 'isotime' produces UTC timestamps in ISO8601 format, that is %Y-%m-%dT%H:%M:%S.msecsZ e.g. 2003-07-08T18:02:34.012Z A good primer on ISO 8601 can be found at http://www.cl.cam.ac.uk/~mgk25/iso-time.html I'm not entirely sold on the name 'isotime' - an alternative would be 'stdtime'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=767600&group_id=5470 From noreply@sourceforge.net Tue Jul 8 09:35:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 01:35:27 -0700 Subject: [Patches] [ python-Patches-767600 ] Add a 'isotime' format to standard logging Message-ID: Patches item #767600, was opened at 2003-07-08 10:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=767600&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: Add a 'isotime' format to standard logging Initial Comment: This patch adds a standard format string 'isotime' to go alongside 'asctime' in the standard logging module. The 'asctime' format is somewhat idiosyncratic (for instance the seconds,milliseconds part). 'isotime' produces UTC timestamps in ISO8601 format, that is %Y-%m-%dT%H:%M:%S.msecsZ e.g. 2003-07-08T18:02:34.012Z A good primer on ISO 8601 can be found at http://www.cl.cam.ac.uk/~mgk25/iso-time.html I'm not entirely sold on the name 'isotime' - an alternative would be 'stdtime'. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-08 10:35 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=767600&group_id=5470 From noreply@sourceforge.net Tue Jul 8 16:52:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 08:52:39 -0700 Subject: [Patches] [ python-Patches-761969 ] -DPIC should be added for the -fPIC case Message-ID: Patches item #761969, was opened at 2003-06-27 19:22 Message generated for change (Comment added) made by marc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761969&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: -DPIC should be added for the -fPIC case Initial Comment: AFAIK -DPIC should always added when compiling with -DPIC. At least that's what libtool does and shown in many FAQs (like http://www.netbsd.org/Documentation/elf.html). A quick glance on NetBSD-current and FreeBSD (4.8) shows that it's evaluated in machine/asm.h. ---------------------------------------------------------------------- >Comment By: Marc Recht (marc) Date: 2003-07-08 17:52 Message: Logged In: YES user_id=205 That's the asm.h part: (complete asm.h is attached) #ifdef PIC #define PIC_PROLOGUE \ pushl %ebx; \ call 1f; \ 1: \ popl %ebx; \ addl $_GLOBAL_OFFSET_TABLE_+[.-1b], %ebx #define PIC_EPILOGUE \ popl %ebx #define PIC_PLT(x) x@PLT #define PIC_GOT(x) x@GOT(%ebx) #define PIC_GOTOFF(x) x@GOTOFF(%ebx) #else [...] (-DPIC seems not to be added by gcc's -fPIC.) Note: I didn't find any functional differences (yet?). (Though the generated .so differs.) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-05 18:15 Message: Logged In: YES user_id=21627 I completely agree with Andrew, especially in his view of libtool. Marc, can you show us (or point us to) a fragment of asm.h that uses -DPIC? I would consider a system broken where -fPIC/-KPIC works incorrectly without -DPIC. gcc is powerful enough to automatically add this to the preprocessor if a platform really needs it, so not supplying it would be a gcc bug. We only work around clearly demonstrated bugs, and only by documenting, in the Python sources, that a certain piece of code is a work-around for a bug in some documented version of some system. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-01 13:01 Message: Logged In: YES user_id=250749 At least on FreeBSD, the presence or absence of -DPIC doesn't appear to have any effect on behaviour of the built .sos - the same ones pass/fail the tests either way, regardless of whether the content is changed, so its not a valuable addition. >From what I've read, I'm not sure that libtool should be taken as a definitive reference. ---------------------------------------------------------------------- Comment By: Marc Recht (marc) Date: 2003-07-01 12:39 Message: Logged In: YES user_id=205 So far I've only build tested it on NetBSD-current. And at least the generated .so differs (more than between two builds). I've added this to all archs, because AFAIK that's what libtool does, too. (And every FAQ I've looked at and also other applications.) Maybe configure could check if "-fPIC -DPIC" is supported by the platform ? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-30 18:27 Message: Logged In: YES user_id=6380 Adding -DPIC just adds a preprocessor symbol, and not a very distinguished one. If FreeBSD really needs this particular #define to work correctly when compiling with -fPIC, perhaps a FreeBSD-specific patch would be acceptable. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-06-30 12:30 Message: Logged In: YES user_id=250749 I tested this patch on both FreeBSD 48 & 5.1. AFAICT, this did not affect behaviour of the interpreter either way. I note that you've tagged quite a few platforms in this patch, thus it would need to be tested on all affected platforms to be accepted in full. At this time, it isn't clear to me what benefits this patch gets us. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761969&group_id=5470 From noreply@sourceforge.net Tue Jul 8 17:37:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 09:37:49 -0700 Subject: [Patches] [ python-Patches-653938 ] Adds a builtin decimal type (FixedPoint) Message-ID: Patches item #653938, was opened at 2002-12-14 18:00 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=653938&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Michael McLay (mclay) Assigned to: Nobody/Anonymous (nobody) Summary: Adds a builtin decimal type (FixedPoint) Initial Comment: This patch integrates the fixedpoint module, that was created by Tim Peters, into Python as a first class object. That is, the patch adds this new number type so that it has direct syntax support like float, int, long, str., etc. within the interpreter. I use Tim's module to implement the type. This limits the patch to a small bit of code that adds the a syntax interface to this module. Syntax recognition for the new number format required a change to Parser/tokenizer.c and to Python/compile.c. This patch allows the new decimal type (I renamed the FixedPoint type to decimal in the fixedpoint.py file because the name is shorter and it is sufficient to distinguish the type from a binary float.) to be entered as a literal that is similar to a long, int, or float. The new syntax works as follows: >>> 12.00d 12.00d >>> .012d 0.012d >>> 1d 1.d >>> str(1.003d) '1.003' As you can see from the example, the default precision for decimal literals are determined by the precision entered expressed in the literal. The patch also adds glue to Python/bltinmodule.c to create a builtin decimal() function. This builtin decimal (Formally FixedPoint) function invokes the constructor of the Python implementation of the decimal class defined in the fixedpoint module. The implementation follows the familiar pattern for adding special builtin functions, much like the implementation of apply and abs. It does not follow the typical method for adding built in types. That would require a more invasive patch. The builtin decimal function works as follows: >>> decimal(1.333) 1.33d >>> decimal(1.333,4) 1.3330d >>> decimal(400,2) 400.00d The semantics of the precision parameter may be incorrect because it is only addressing the precision of the fraction part of the number. Shouldn't it reflect the number of significant digits? If that were the case then the following would have been the result: >>> decimal(400,2) 4.0e2d This problem is more noticable when exponents are large relative to the number of significant digits. For instance: >>> 40.e3d 40000.d The result should have been 40.e3d, not 40000. This implies more precision than is declared by the constant. As it currently is implemented the type pads with zeros on the integer side of the decimal point, whic implies more accuracy in the number than is true. I ran into this problem when I tried to implement the automatic conversion of string number values to decimal representation for numbers in 'e' format. >>> 3.03e5d 303000.00d The representation is incorrect. It should have returned 3.03e5d but it padded the result with bogus zeros. For this first cut at a new decimal type I am primarily interested in investigating the semantics of the new native decimal number type in Python. This type will be useful to bankers, accountants, and newbies. The backend implementation could be replaced with a C implementation without affecting the Python language semantics. The approach used in this patch makes it very easy to experiment with changes to the semantics because all of the experimentation can be done by changing the code in Lib/fixedpoint.py. The compiled wrapper doesn't have to be modified and recompiled. Unit testing so far just reuses the _test function in the fixedpoint.py module. Since I am not sure which way to go with the semantic interpretation of precision I decided to post the patch before making a significant change to fixedpoint.py. Some feedback on the interpretation of precision would be appreciated. Documentation: The following needs to be added to section 2.1 of the library reference manual: decimal(value, precision) Convert a string or a number to fixed point decimal number. If the argument is a string, it must contain a possibly signed decimal or floating point number, possibly embedded in whitespace. The precision parameter will be ignored on string values. The precision will be set based on the number of significant digits. Otherwise, the argument may be a plain or long integer or a floating point number, and a decimal number with the same value ( the precision attribute will set the precision of the fraction roundoff) is returned. Section 3.1.1 of the tutorial will add a brief description of decimal number usage after the description of floating point: There is full support for floating point; operators with mixed type operands convert the integer operand to floating point: >>> 3 * 3.75 / 1.5 7.5 >>> 7.0 / 2 3.5 Python also supports fixed point decimal numbers. These numbers do not suffer from the somewhat random roundoff errors that can occur with binary floating point numbers. A decimal number is created by adding a 'd' or 'D' suffix to a number: >>> 3.3d + 3d 6.3d >>> 3.3d + 3.03 6.3d >>> 3.3d + decimal(3.03,3) 6.330d >>> decimal(1.1, 16) 1.1000000000000001d >>> The builtin decimal constructor provides a means for converting float and int types to decimal types. Since floats are approximations of decimal floating point numbers there are often roundoff errors introduced by using floats. (The 1 in the last place of the conversion of 1.1 with 16 digits is a binary round off error.) For this reason the decimal function requires the specification of precision when converting a float to a decimal. This allows the significant digits of the number to be specified. (Accountants and bankers love this because it allows them to balance the books without pennies being lost due to the use of binary numbers.) >>> 3.3d/2 1.6d Note that in the example above the expression 3.3d/2 returned 1.6d. The rounding scheme for Python decimals uses "banking" rounding rules. With floating point numbers the result would have been as follows: >>> 3.3/2 1.6499999999999999 So as you can see the banking rules round off the .04999999999 portion of the number and calls it a an even 1.6. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-08 09:37 Message: Logged In: YES user_id=357491 With Michael's blessing I am closing this patch as rejected. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-06 13:32 Message: Logged In: YES user_id=357491 Is this patch worth keeping open now that we have nondist/ sandbox/decimal/ ? Or are these two implementations going to duke it out in the end? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-12-28 21:18 Message: Logged In: YES user_id=80475 I don't think a syntax change is warranted. Most use cases I can think of do not have decimal constants in the program; rather, they are always data. FixedPoint is valuable in and of itself without any need for a new syntax. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-15 01:07 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=653938&group_id=5470 From noreply@sourceforge.net Tue Jul 8 18:09:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 10:09:12 -0700 Subject: [Patches] [ python-Patches-766889 ] Document thread.interrupt_main() Message-ID: Patches item #766889, was opened at 2003-07-06 19:33 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766889&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Kurt B. Kaiser (kbk) Summary: Document thread.interrupt_main() Initial Comment: interrupt_main function added at 2.3b2 Also: Removed the reference to the deprecated exit_thread() function...other deprecated function references have been previously removed from the documentation. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-08 12:09 Message: Logged In: YES user_id=149084 libthread.tex Rev 1.29 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-07 16:59 Message: Logged In: YES user_id=21627 This is fine, please apply. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766889&group_id=5470 From noreply@sourceforge.net Tue Jul 8 19:06:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 11:06:01 -0700 Subject: [Patches] [ python-Patches-766879 ] Building HTML Docs Requires Perl 5.6 Message-ID: Patches item #766879, was opened at 2003-07-06 19:20 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766879&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Kurt B. Kaiser (kbk) Summary: Building HTML Docs Requires Perl 5.6 Initial Comment: Adding "use warnings" to .../Doc/perl/python.perl apparently raises the Perl requirement to 5.6.0: File Edit Options Buffers Tools Help Loading /usr/local/lib/latex2html/versions/html4_0.pl *** processing declarations *** Loading /usr/local/lib/latex2html/versions/latin1.pl Adding /home/kbk/PYTHON/python/dist/src/Doc/api to $TEXINPUTS OPENING /home/kbk/PYTHON/python/dist/src/Doc/api/api.tex Cannot create directory /home/kbk/PYTHON/python/dist/src/Doc/html/api/: File ex\ists, reusing it. Note: Working directory is /home/kbk/PYTHON/python/dist/src/Doc/html/api Note: Images will be generated in /tmp/l2h16111 texexpand V99.2beta8 (Revision 1.11) Loading /usr/local/lib/latex2html/styles/texdefs.perl... Loading /home/kbk/PYTHON/python/dist/src/Doc/perl/manual.perl Loading /usr/local/lib/latex2html/styles/report.perl Loading /usr/local/lib/latex2html/styles/alltt.perl Loading /home/kbk/PYTHON/python/dist/src/Doc/perl/python.perlCan't locate warni\ngs.pm in @INC (@INC contains: /usr/lib/perl5/5.00503/i386-linux /usr/lib/perl5\/5.00503 /usr/lib/perl5/site_perl/5.005/i386-linux /usr/lib/perl5/site_perl/5.0\05 . /usr/local/lib/latex2html /home/kbk /home/kbk/PYTHON/python/dist/src/Doc/p\erl /home/kbk/PYTHON/python/dist/src/Doc/perl) at /home/kbk/PYTHON/python/dist/\src/Doc/perl/python.perl line 11, chunk 1. BEGIN failed--compilation aborted at /home/kbk/PYTHON/python/dist/src/Doc/perl/\python.perl line 11, chunk 1. *** Session transcript and error messages are in /home/kbk/PYTHON/python/dist/s\rc/Doc/html/api/api.how. *** Exited with status 2. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-08 13:06 Message: Logged In: YES user_id=149084 README Rev 1.49 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-07 17:00 Message: Logged In: YES user_id=21627 The patch is fine, please apply. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766879&group_id=5470 From noreply@sourceforge.net Tue Jul 8 22:14:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 14:14:35 -0700 Subject: [Patches] [ python-Patches-761969 ] -DPIC should be added for the -fPIC case Message-ID: Patches item #761969, was opened at 2003-06-27 19:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761969&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: -DPIC should be added for the -fPIC case Initial Comment: AFAIK -DPIC should always added when compiling with -DPIC. At least that's what libtool does and shown in many FAQs (like http://www.netbsd.org/Documentation/elf.html). A quick glance on NetBSD-current and FreeBSD (4.8) shows that it's evaluated in machine/asm.h. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-08 23:14 Message: Logged In: YES user_id=21627 I see. Rejecting this patch: We never ever use PIC_PROLOGUE, PIC_PLT, or any macros that are based on them. ---------------------------------------------------------------------- Comment By: Marc Recht (marc) Date: 2003-07-08 17:52 Message: Logged In: YES user_id=205 That's the asm.h part: (complete asm.h is attached) #ifdef PIC #define PIC_PROLOGUE \ pushl %ebx; \ call 1f; \ 1: \ popl %ebx; \ addl $_GLOBAL_OFFSET_TABLE_+[.-1b], %ebx #define PIC_EPILOGUE \ popl %ebx #define PIC_PLT(x) x@PLT #define PIC_GOT(x) x@GOT(%ebx) #define PIC_GOTOFF(x) x@GOTOFF(%ebx) #else [...] (-DPIC seems not to be added by gcc's -fPIC.) Note: I didn't find any functional differences (yet?). (Though the generated .so differs.) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-05 18:15 Message: Logged In: YES user_id=21627 I completely agree with Andrew, especially in his view of libtool. Marc, can you show us (or point us to) a fragment of asm.h that uses -DPIC? I would consider a system broken where -fPIC/-KPIC works incorrectly without -DPIC. gcc is powerful enough to automatically add this to the preprocessor if a platform really needs it, so not supplying it would be a gcc bug. We only work around clearly demonstrated bugs, and only by documenting, in the Python sources, that a certain piece of code is a work-around for a bug in some documented version of some system. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-01 13:01 Message: Logged In: YES user_id=250749 At least on FreeBSD, the presence or absence of -DPIC doesn't appear to have any effect on behaviour of the built .sos - the same ones pass/fail the tests either way, regardless of whether the content is changed, so its not a valuable addition. >From what I've read, I'm not sure that libtool should be taken as a definitive reference. ---------------------------------------------------------------------- Comment By: Marc Recht (marc) Date: 2003-07-01 12:39 Message: Logged In: YES user_id=205 So far I've only build tested it on NetBSD-current. And at least the generated .so differs (more than between two builds). I've added this to all archs, because AFAIK that's what libtool does, too. (And every FAQ I've looked at and also other applications.) Maybe configure could check if "-fPIC -DPIC" is supported by the platform ? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-30 18:27 Message: Logged In: YES user_id=6380 Adding -DPIC just adds a preprocessor symbol, and not a very distinguished one. If FreeBSD really needs this particular #define to work correctly when compiling with -fPIC, perhaps a FreeBSD-specific patch would be acceptable. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-06-30 12:30 Message: Logged In: YES user_id=250749 I tested this patch on both FreeBSD 48 & 5.1. AFAICT, this did not affect behaviour of the interpreter either way. I note that you've tagged quite a few platforms in this patch, thus it would need to be tested on all affected platforms to be accepted in full. At this time, it isn't clear to me what benefits this patch gets us. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761969&group_id=5470 From noreply@sourceforge.net Tue Jul 8 22:58:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 14:58:33 -0700 Subject: [Patches] [ python-Patches-768079 ] configure interpreter for profiling Message-ID: Patches item #768079, was opened at 2003-07-08 16: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=768079&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Martin v. Löwis (loewis) Summary: configure interpreter for profiling Initial Comment: I think this is pretty innocuous, but since we're so close to 2.3 release it should be reviewed. Assigning to Martin since he's the configure expert. This simple patch adds an --enable-profiling flag to configure.in. It's just the first step - adding -pg to compile and link lines if $CC understands it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=768079&group_id=5470 From noreply@sourceforge.net Wed Jul 9 01:04:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 17:04:55 -0700 Subject: [Patches] [ python-Patches-727789 ] Editing of __str__ and __repr__ docs Message-ID: Patches item #727789, was opened at 2003-04-25 22:25 Message generated for change (Comment added) made by donnc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=727789&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven Taschuk (staschuk) Assigned to: Nobody/Anonymous (nobody) Summary: Editing of __str__ and __repr__ docs Initial Comment: A recent thread in comp.lang.python [1] suggests that there is some question whether the existing docs for the __str__ and __repr__ methods is clear, and whether what it says is good in the first place. The patch shows proposed changes based on the discussions in that thread. The new text treats __repr__ as a programmer-centric stringification (with eval(repr(x)) == x as a possibility, rather than a principle), and __str__ as a more general-purpose stringification-as-appropriate- to-the-object. [1] http://groups.google.com/groups?th=24b817d49ec3a59b ---------------------------------------------------------------------- Comment By: Donn Cave (donnc) Date: 2003-07-09 00:04 Message: Logged In: YES user_id=42839 In __str__, I would replace the whole commentary paragraph with "This string value is the result of converting the object data to string type, for use in applications that require a string and don't care about the original object per se." ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-09 00:20 Message: Logged In: YES user_id=357491 I agree with Raymond that it seems "wordy". For instance, the first changed paragraph is basically just trying to say "__repr__ should return something that can be past to 'eval' to return return the same object. If this is not possible then make its output useful to the programmer." Don't need to go on about it needing to be a "valid Python expression" and such. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-29 04:52 Message: Logged In: YES user_id=80475 The patch looks technically correct. It is wordy and I liked the original better, but clarity is more important. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=727789&group_id=5470 From noreply@sourceforge.net Wed Jul 9 02:07:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 18:07:30 -0700 Subject: [Patches] [ python-Patches-727789 ] Editing of __str__ and __repr__ docs Message-ID: Patches item #727789, was opened at 2003-04-25 17:25 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=727789&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven Taschuk (staschuk) Assigned to: Nobody/Anonymous (nobody) Summary: Editing of __str__ and __repr__ docs Initial Comment: A recent thread in comp.lang.python [1] suggests that there is some question whether the existing docs for the __str__ and __repr__ methods is clear, and whether what it says is good in the first place. The patch shows proposed changes based on the discussions in that thread. The new text treats __repr__ as a programmer-centric stringification (with eval(repr(x)) == x as a possibility, rather than a principle), and __str__ as a more general-purpose stringification-as-appropriate- to-the-object. [1] http://groups.google.com/groups?th=24b817d49ec3a59b ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-08 20:07 Message: Logged In: YES user_id=80475 Consider taking this back to the newsgroup to tease out some wording that everyone finds more palatable. The verbiage should be terse, factual, and general without being overly abstract or preachy. The most recent suggestion (below) is not one I would approve. The circularity and indirectness make the docs unhelpful, hard to read, and uninformative. Brett's suggestion is close to the mark. ---------------------------------------------------------------------- Comment By: Donn Cave (donnc) Date: 2003-07-08 19:04 Message: Logged In: YES user_id=42839 In __str__, I would replace the whole commentary paragraph with "This string value is the result of converting the object data to string type, for use in applications that require a string and don't care about the original object per se." ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-08 19:20 Message: Logged In: YES user_id=357491 I agree with Raymond that it seems "wordy". For instance, the first changed paragraph is basically just trying to say "__repr__ should return something that can be past to 'eval' to return return the same object. If this is not possible then make its output useful to the programmer." Don't need to go on about it needing to be a "valid Python expression" and such. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-28 23:52 Message: Logged In: YES user_id=80475 The patch looks technically correct. It is wordy and I liked the original better, but clarity is more important. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=727789&group_id=5470 From noreply@sourceforge.net Wed Jul 9 03:12:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 19:12:37 -0700 Subject: [Patches] [ python-Patches-768187 ] replace apply() with f(*args, **kwds) Message-ID: Patches item #768187, was opened at 2003-07-08 21:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=768187&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Kurt B. Kaiser (kbk) Summary: replace apply() with f(*args, **kwds) Initial Comment: The warnings module causes apply() to run nearly two orders of magnitude more slowly than f(*arg, **kwds). With this patch IDLE appears to load and execute faster (I say appears but I don't see an easy way of timing it). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=768187&group_id=5470 From noreply@sourceforge.net Wed Jul 9 06:23:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 22:23:30 -0700 Subject: [Patches] [ python-Patches-768079 ] configure interpreter for profiling Message-ID: Patches item #768079, was opened at 2003-07-08 23:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=768079&group_id=5470 Category: Build >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Skip Montanaro (montanaro) Summary: configure interpreter for profiling Initial Comment: I think this is pretty innocuous, but since we're so close to 2.3 release it should be reviewed. Assigning to Martin since he's the configure expert. This simple patch adds an --enable-profiling flag to configure.in. It's just the first step - adding -pg to compile and link lines if $CC understands it. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-09 07:23 Message: Logged In: YES user_id=21627 I have several objections: For 2.3, it is a new feature, which cannot be added at this time (changing the group to 2.4). It then only works with gcc, as other compilers don't recognize -pg. In addition, I fail to see the rationale for this change: You can already achieve the same effect by setting CC (and perhaps CXX) before invoking configure. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=768079&group_id=5470 From noreply@sourceforge.net Wed Jul 9 09:49:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 01:49:29 -0700 Subject: [Patches] [ python-Patches-768187 ] replace apply() with f(*args, **kwds) Message-ID: Patches item #768187, was opened at 2003-07-09 04:12 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=768187&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Kurt B. Kaiser (kbk) Summary: replace apply() with f(*args, **kwds) Initial Comment: The warnings module causes apply() to run nearly two orders of magnitude more slowly than f(*arg, **kwds). With this patch IDLE appears to load and execute faster (I say appears but I don't see an easy way of timing it). ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-07-09 10:49 Message: Logged In: YES user_id=89016 The first part of the patch to configDialog.py is wrong: plane is a variable with the possible values "foreground" and "background". The patch changes this to "plane". Otherwise the patch looks OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=768187&group_id=5470 From noreply@sourceforge.net Wed Jul 9 14:13:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 06:13:43 -0700 Subject: [Patches] [ python-Patches-768442 ] Warning 'assignment shadows builtin' __builtins__ fix Message-ID: Patches item #768442, was opened at 2003-07-09 13:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=768442&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Troels Therkelsen (troelst) Assigned to: Nobody/Anonymous (nobody) Summary: Warning 'assignment shadows builtin' __builtins__ fix Initial Comment: Python 2.3b2 (#1, Jun 30 2003, 13:04:39) [GCC 2.95.3 20010315 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, new >>> d = {'__builtins__':{}} >>> d['mod'] = new.module('mod') >>> d['mod'].__builtins__ = d['__builtins__'] >>> exec "mod.reload = 42" in d :1: DeprecationWarning: assignment shadows builtin >>> d['sys'] = sys >>> exec "print sys._getframe().f_builtins" in d {} Surely, the DeprecationWarning shouldn't be printed if you use __builtins__ to explicitly define your own builtins dict? I mean, the 'reload' name in this case is an unknown name until it is defined in mod. The submitted patch fixes Objects/moduleobject.c so that the warning is only done if the module global you're assigning to exists in f_builtins. The patch is somehwat naive I admit, and it reuses as much as the old code as possible. Alternatively, instead of all the work done, one could just check directly in f_builtins. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=768442&group_id=5470 From noreply@sourceforge.net Wed Jul 9 14:20:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 06:20:44 -0700 Subject: [Patches] [ python-Patches-768187 ] replace apply() with f(*args, **kwds) Message-ID: Patches item #768187, was opened at 2003-07-08 21:12 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=768187&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Kurt B. Kaiser (kbk) Summary: replace apply() with f(*args, **kwds) Initial Comment: The warnings module causes apply() to run nearly two orders of magnitude more slowly than f(*arg, **kwds). With this patch IDLE appears to load and execute faster (I say appears but I don't see an easy way of timing it). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 08:20 Message: Logged In: YES user_id=80475 Thanks for the detailed review. Here is the revised patch (only 1 line changed). ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-07-09 03:49 Message: Logged In: YES user_id=89016 The first part of the patch to configDialog.py is wrong: plane is a variable with the possible values "foreground" and "background". The patch changes this to "plane". Otherwise the patch looks OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=768187&group_id=5470 From noreply@sourceforge.net Wed Jul 9 16:37:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 08:37:21 -0700 Subject: [Patches] [ python-Patches-768079 ] configure interpreter for profiling Message-ID: Patches item #768079, was opened at 2003-07-08 16:58 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=768079&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: configure interpreter for profiling Initial Comment: I think this is pretty innocuous, but since we're so close to 2.3 release it should be reviewed. Assigning to Martin since he's the configure expert. This simple patch adds an --enable-profiling flag to configure.in. It's just the first step - adding -pg to compile and link lines if $CC understands it. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-07-09 10:37 Message: Logged In: YES user_id=44345 2.4 is fine. It should work with any compiler which understands -pg. If that's only gcc for now, that's the only one which it will get set for. Support for other compilers can be added later by people with access to other compilers. I believe it's worth adding as a configure flag because it makes it more foolproof. By configuring with -pg, all extension modules built with this particular python executable will also get profiling enabled. That's not immediately obvious to everyone. Also some people seem to think that by adding -pg to an extension module's compilation that they should get profiled results. That only works if the interpreter is compiled with -pg because it's during a modified exit() call that the data gets written. This only came up because one user is going through all sorts of hoops to try and profile his extension module. He's obviously making mistakes. I think it would be better to make it a more foolproof exercise. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-09 00:23 Message: Logged In: YES user_id=21627 I have several objections: For 2.3, it is a new feature, which cannot be added at this time (changing the group to 2.4). It then only works with gcc, as other compilers don't recognize -pg. In addition, I fail to see the rationale for this change: You can already achieve the same effect by setting CC (and perhaps CXX) before invoking configure. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=768079&group_id=5470 From noreply@sourceforge.net Wed Jul 9 17:13:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 09:13:12 -0700 Subject: [Patches] [ python-Patches-757997 ] Using __slots__ with str derived classes can cause segfault Message-ID: Patches item #757997, was opened at 2003-06-20 12:28 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=757997&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 7 Submitted By: John Ehresman (jpe) >Assigned to: Neal Norwitz (nnorwitz) Summary: Using __slots__ with str derived classes can cause segfault Initial Comment: The following results in a segfault on Linux with 2.3b1: ------------------------- class StringDerived(str): __slots__ = ['a'] def __init__(self, string): str.__init__(self, string) self.a = 1 class DerivedAgain(StringDerived): pass o = DerivedAgain('hello world') o.b = 2 -------------------------- Python 2.2.2 raises a TypeError when attempting to derive a class from str with a non-empty __slots__, maybe 2.3 should do the same? I have no use case for deriving from str and defining __slots__; I encountered the bug when writing test cases for a debugger. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-07-09 12:13 Message: Logged In: YES user_id=6380 Neal, I don't think your patch can work, unless you change the *descriptors* used for slots also: the slot offsets used by the slot descriptors will still be constant and hence overwrite the characters of the string (see structmember.c). Example (with your patch): >>> class C(str): __slots__ = ['a'] ... >>> s = C("hello world") >>> s.a '\x00\x00\x00\x00\x90\x86\x12\x08\x00\x00' >>> I'd rather see the 2.2 situation back, where it's simply illegal to use __slots__ in a str subclass (or any subclass of a class whose tp_itemsize != 0). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-20 18:05 Message: Logged In: YES user_id=33168 Ain't testing grand. Found a couple more problems. Patch 2 is better, but I'm still not sure it's complete or correct. I'm thinking the slot offset should be fixed when it's set, rather than at each usage of the slot offset. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-20 17:23 Message: Logged In: YES user_id=33168 I think the problem is that strings are variable length. clear_slots() doesn't handle this condtion. The attached patch fixes the crash and works fine under valgrind, but I'm not entirely sure it's correct. Hopefully someone more familiar with the TypeObject code can review this. I'll add a test later. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-20 13:18 Message: Logged In: YES user_id=33168 unicode, list, and dict don't crash, only string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=757997&group_id=5470 From noreply@sourceforge.net Wed Jul 9 17:22:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 09:22:48 -0700 Subject: [Patches] [ python-Patches-738094 ] for i in range(N) optimization Message-ID: Patches item #738094, was opened at 2003-05-15 03:14 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=738094&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open >Resolution: Later >Priority: 2 Submitted By: Sebastien Keim (s_keim) Assigned to: Guido van Rossum (gvanrossum) Summary: for i in range(N) optimization Initial Comment: This patch is intended to special case the built-in range function in the common "for i in range(...):" construct. The goal is to make range() return an iterator instead of creating a real list, and then being able to depreciate the xrange type. It has once been suggested to make the compiler aware of the "for i in range(N):" construct and to make it able to produce optimized bytecode. But this solution is really hard to achieve because you have to ensure that the range built-in is not overridden. The patch take an opposite approach: it let the range built-in function looks at its execution context, and return an iterator if the next frame opcode to be executed is the GET_ITER opcode. Speed increase for the piece of code "for i in range(N): pass" : N (speed gain) 10 (+ 64%) 100 (+ 29%) 1000 (+ 23%) 10000 (+ 68%) 100000 (+108%) Since the patch only affect a small construct of the language, performance improvements for real applications are less impressive but they are still interesting: pystone.py (+7%) test_userstring.py (+8%) test_datetime.py (+20%) Note that the performance loss for "A = range(10)" is not measurable (less than 1%). If the patch is accepted, the same recipe may be applicable in some few other places. So the Py_IsIterationContext function must probably live somewhere else (is there a standard location for byte-code dependent stuff?). Maybe other opcodes (for sample JUMP_IF_FALSE) could provide other useful specialization contexts. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-07-09 12:22 Message: Logged In: YES user_id=6380 In the sake of stability for Python 2.3's accelerated release schedule, I'm postponing this until after 2.3. I'm also skeptical that it ca be absolutely correct. What if there is Python code of the form for i in some_function(): ... where some_function() is a C extension that at some point invokes range(), directly from C. Then when range() peeks in the opcode stream, it would believe that it was being called in the place of some_function(). So maybe I should just reject it as unsafe? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-18 17:18 Message: Logged In: YES user_id=6380 I'm interested, but have to ponder more, which will have to wait until I'm back from vacation. I expect that any hope to deprecate xrange() will prove naive -- people will want to pass ranges around between functions or reuse them (e.g. this happens a lot in timing tests). Maybe in Python 3.0 I can make range() act as an iterator generator. You'd have to say list(range(N)) to get an actual list then. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 19:25 Message: Logged In: YES user_id=80475 Assigning to Guido to see whether he is interested because it makes xrange less necessary or whether he thinks it is a horrendous hack --or maybe both ;-) ---------------------------------------------------------------------- Comment By: Sebastien Keim (s_keim) Date: 2003-05-15 11:14 Message: Logged In: YES user_id=498191 I have also thought about slicing, map and filter which could all be replaced by itertools equivalents , but I have failed to find a way to ensure that the argument lists aren't mutated during the for loop. Maybe it could be interesting to investigate into copy on write semantic for lists objects? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-15 10:33 Message: Logged In: YES user_id=80475 zip() would benefit greatly from your approach. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=738094&group_id=5470 From noreply@sourceforge.net Wed Jul 9 19:36:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 11:36:01 -0700 Subject: [Patches] [ python-Patches-768187 ] replace apply() with f(*args, **kwds) Message-ID: Patches item #768187, was opened at 2003-07-08 21:12 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=768187&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Raymond Hettinger (rhettinger) Summary: replace apply() with f(*args, **kwds) Initial Comment: The warnings module causes apply() to run nearly two orders of magnitude more slowly than f(*arg, **kwds). With this patch IDLE appears to load and execute faster (I say appears but I don't see an easy way of timing it). ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-09 13:36 Message: Logged In: YES user_id=149084 This looks fine, please apply it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 08:20 Message: Logged In: YES user_id=80475 Thanks for the detailed review. Here is the revised patch (only 1 line changed). ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-07-09 03:49 Message: Logged In: YES user_id=89016 The first part of the patch to configDialog.py is wrong: plane is a variable with the possible values "foreground" and "background". The patch changes this to "plane". Otherwise the patch looks OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=768187&group_id=5470 From noreply@sourceforge.net Wed Jul 9 19:54:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 11:54:03 -0700 Subject: [Patches] [ python-Patches-768187 ] replace apply() with f(*args, **kwds) Message-ID: Patches item #768187, was opened at 2003-07-08 21:12 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=768187&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: replace apply() with f(*args, **kwds) Initial Comment: The warnings module causes apply() to run nearly two orders of magnitude more slowly than f(*arg, **kwds). With this patch IDLE appears to load and execute faster (I say appears but I don't see an easy way of timing it). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 13:54 Message: Logged In: YES user_id=80475 Applied. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-09 13:36 Message: Logged In: YES user_id=149084 This looks fine, please apply it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 08:20 Message: Logged In: YES user_id=80475 Thanks for the detailed review. Here is the revised patch (only 1 line changed). ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-07-09 03:49 Message: Logged In: YES user_id=89016 The first part of the patch to configDialog.py is wrong: plane is a variable with the possible values "foreground" and "background". The patch changes this to "plane". Otherwise the patch looks OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=768187&group_id=5470 From noreply@sourceforge.net Wed Jul 9 23:36:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 15:36:51 -0700 Subject: [Patches] [ python-Patches-762963 ] timemodule.c: Python loses current timezone Message-ID: Patches item #762963, was opened at 2003-06-29 19:18 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762963&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Doug Quale (quale) Assigned to: Brett Cannon (bcannon) Summary: timemodule.c: Python loses current timezone Initial Comment: Python routines in timemodule.c sometimes force glibc to use GMT instead of the correct timezone. I think this is a longstanding bug, but I have only looked at Python 2.2 and 2.33b1. This bug has been reported before (510218) but it was misdiagnosed and closed. It also came up recently in on the python-list (http://aspn.activestate.com/ASPN/Mail/Message/python-list/1564384) where it was also misdiagnosed. Standard C and Python use a struct tm with 9 values. BSD influenced C libraries like glibc have an extra field (tm_gmtoff) that keeps the offset from UTC. BSD-style struct tm values know the correct timezone associated with the time, but Python and Standard C struct tm values don't so they can only assume the current timezone. Ideally Python would always treat stuct tm-style time tuples as being associated with the current timezone. Unfortunately in many cases Python forces glibc to use GMT rather than the current timezone. You can see the problem most graphically with the %z format in strftime(). In the transcript Python incorrectly gives the timezone offset as +0000 even though it gets the timezone name (CDT) correct: $ python2.3 Python 2.3b1+ (#2, Jun 4 2003, 03:03:32) [GCC 3.3 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> now = time.localtime() >>> print now (2003, 6, 29, 20, 3, 52, 6, 180, 1) >>> RFC822 = '%a, %d %b %Y %T %z' >>> print time.strftime(RFC822, now) Sun, 29 Jun 2003 20:03:52 +0000 >>> print time.strftime(RFC822) Sun, 29 Jun 2003 20:05:27 -0500 >>> print time.strftime('%Z', now) CDT The correct timezone is CDT and the correct offset is -0500. Notice that when time.strftime() computes the current time it it gets the correct timezone offset, but when the struct tm tuple is passed in it thinks the timezone offset is 0. (glibc does know that the correct timezone name is CDT even when passed a bad struct tm value, but that's not surprising since the timezone name is not stored in struct tm and it is not computed from timezone offset.) The problem is in the gettmargs() function in timemodule.c. When getmargs() parses a Python tm tuple it leaves the tm_gmtoff field zeroed. This specifically tells glibc that the timezone offset is 0, which is wrong for most people. (BSD libc may also be affected.) This problem does not occur when time_strfrtime() gets the current time itself since that codepath uses a struct tm value directly from the libc localtime(), leaving the tm_gmtoff field intact. Fortunately the fix is almost trivial. A call to mktime() will normalize the fields in the struct tm value, including the tm_gmtoff field. I conditionalized the patch only on HAVE_MKTIME. I'm pretty sure there's an autoconfigure test for tm_gmtoff and it would probably be better to use that. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-09 15:36 Message: Logged In: YES user_id=357491 So the problem is with the %z directive not reporting the proper timezone offset, correct? If you look at http://www.python.org/ dev/doc/devel/lib/module-time.html , though, you will notice that %T is not supported as a directive for strftime or strptime nor has it ever been supported. Same goes for %T although it works in your example. Since the docs do not say that these directives are supported I am closing this patch since it would require altering both strftime and stprtime to support %z on all platforms which this patch does not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762963&group_id=5470 From noreply@sourceforge.net Thu Jul 10 00:10:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 16:10:02 -0700 Subject: [Patches] [ python-Patches-768778 ] 2.3 whatsnew typo Message-ID: Patches item #768778, was opened at 2003-07-10 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=768778&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bastian Kleineidam (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3 whatsnew typo Initial Comment: missing backslash near tix module item ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=768778&group_id=5470 From noreply@sourceforge.net Thu Jul 10 02:43:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 18:43:47 -0700 Subject: [Patches] [ python-Patches-768840 ] IRIX libmpc patch Message-ID: Patches item #768840, was opened at 2003-07-09 18: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=768840&group_id=5470 Category: Build Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Michael Pruett (mpruett) Assigned to: Nobody/Anonymous (nobody) Summary: IRIX libmpc patch Initial Comment: It is not necessary to link with -lmpc to get native threads on IRIX. I do not recall a time when this library was needed, but it was certainly prior to the release of IRIX 6.5 (in 1998). I propose removing references to this library, as is done in the following patch against Python 2.2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=768840&group_id=5470 From noreply@sourceforge.net Thu Jul 10 13:50:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 05:50:40 -0700 Subject: [Patches] [ python-Patches-764612 ] building bsddb3 on FreeBSD Message-ID: Patches item #764612, was opened at 2003-07-03 00:19 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764612&group_id=5470 Category: Modules Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Andrew I MacIntyre (aimacintyre) Summary: building bsddb3 on FreeBSD Initial Comment: FreeBSD's ports of the Sleepcat DB releases use different naming conventions than currently catered for in setup.py. Additionally, the ports collection currently supports having both DB 4.1 and DB 4.0 installed concurrently. The current setup.py really only caters for 1 variation of any major DB version. The attached patch expands the support so that v4.1 has the correct include directory on FreeBSD, and allows for both 4.1 and 4.0 to be concurrently installed. It also adds support for DB3 (v3.3.11 in the Ports collection) on FreeBSD. ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-10 22:50 Message: Logged In: YES user_id=250749 v3 checked in as setup.py v1.171. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-06 20:29 Message: Logged In: YES user_id=250749 Revised version with resorted strings as requested. v2 worked fine for me, finding v4.1 before 4.0 (on FreeBSD), however there are enough variations in live installations that re-sorting the strings is prudent. If there are no objections to v3, I'll check it in later this week. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-06 02:00 Message: Logged In: YES user_id=21627 The patch is fine in principle. However, please make sure that it finds newer versions before it finds older ones, i.e. 4.1 before 4.0 (so resort the strings accordingly). ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-03 23:10 Message: Logged In: YES user_id=250749 I've concluded that the first version of this patch is unnecessarily complicated. I've uploaded a simplified second version, which gets the essentials in place. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-03 00:29 Message: Logged In: YES user_id=250749 Martin, assigned to you as setup.py's history shows you had a fair bit to do with the bsddb3 module machinery in there (Skip and Barry have both also worked on this). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764612&group_id=5470 From noreply@sourceforge.net Thu Jul 10 14:02:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 06:02:21 -0700 Subject: [Patches] [ python-Patches-766650 ] whichdb not ID'ing dbm files with GDBM backend Message-ID: Patches item #766650, was opened at 2003-07-06 21:09 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766650&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Nobody/Anonymous (nobody) Summary: whichdb not ID'ing dbm files with GDBM backend Initial Comment: For the OS/2 EMX port, I build the dbm module with gdbm v1.7.3. At least with the OS/2 version of the gdbm v1.7.3 port, dbm databases consist only of the .pag file - there is no .dir file. In this case, the .pag file has the gdbm magic number. Currently whichdb fails to identify such dbm DBs on this platform because of the expectation that there be a .dir file as well as the .pag file. I'm not in any position to confirm whether the dbm module built with gdbm behaves the same way on other systems -information gratefully received on this topic. On the assumption that other platforms also have this behaviour, the attached patch attempts to detect whether a dbm DB has a gdbm signature just by checking the magic number of the .pag file. The patch involves a refactoring of the magic number code, which may be deemed inappropriate. It may be more expedient to just special case theEMX port in the dbm detection (by skipping looking for the .dir file on this platform). ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-10 23:02 Message: Logged In: YES user_id=250749 I've added a revised patch that attempts to address Martin's points. I've also added a patch that applies a workaround solely for the only platform (OS/2 EMX) known to me to have this issue, rather than trying to be fancy and all-encompassing. I incline to the view that the platform specific workaround would be safer for 2.3, with the more sophisticated approach added after the 2.3 release if appropriate. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-08 08:05 Message: Logged In: YES user_id=21627 The dbm module greatly varies in behaviour across platforms, depending on what underlying library is linked. On my Linux installation, the resulting files are identified as /tmp/u.dir: GNU dbm 1.x or ndbm database, little endian /tmp/u.pag: GNU dbm 1.x or ndbm database, little endian I recommend that you adjust your patch to take dbm.library into account, and go looking for gdbm magic only if you find that dbm is linked with gdbm. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766650&group_id=5470 From noreply@sourceforge.net Thu Jul 10 15:06:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 07:06:24 -0700 Subject: [Patches] [ python-Patches-763681 ] Support IDLE Edit of .py/.pyw from idlelib Message-ID: Patches item #763681, was opened at 2003-07-01 01:14 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763681&group_id=5470 Category: Windows Group: Python 2.3 Status: Open >Resolution: Accepted >Priority: 7 Submitted By: Kurt B. Kaiser (kbk) >Assigned to: Kurt B. Kaiser (kbk) Summary: Support IDLE Edit of .py/.pyw from idlelib Initial Comment: Windows File Types / Actions: IDLE has moved, this patch binds editing a python file to .../Lib/idlelib/idle.pyw instead of .../Tools/idle/idle.pyw ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-10 10:06 Message: Logged In: YES user_id=31435 Looks fine to me -- thanks! Assigned back to Kurt. Kurt, if you don't want to apply the patch, assign it back to me and I'll apply it. Boosted priority too. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-05 12:08 Message: Logged In: YES user_id=21627 Assigning to Tim for review - the patch looks right to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763681&group_id=5470 From noreply@sourceforge.net Thu Jul 10 15:13:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 07:13:23 -0700 Subject: [Patches] [ python-Patches-769142 ] CallTip trimming may loop forever. Message-ID: Patches item #769142, was opened at 2003-07-10 14:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=769142&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Scott David Daniels (scott_daniels) Assigned to: Nobody/Anonymous (nobody) Summary: CallTip trimming may loop forever. Initial Comment: (also applies to 2.2.x) While trying to understand someone else's half-developed code, I found an interesting problem in Idle. This bug is far nastier in 2.3 (which I was using at the time). testcase.py: def function(arg): ''' ''' return 1 In Idle if you type >>> import testcase >>> testcase.function( The code will loop trying to place a calltip in 2.3 (in 2.2.0, it raises an exception). After investigation, I found the following code: python/dist/src/Lib/idlelib/CallTips.py: ... while doc[:1] in " \t\n": doc = doc[1:] pos = doc.find("\n") ... With the new string semantics for 'in', this loop will be checking ('' in ' \t\n') (a bad state of affairs). The following patch should fix it: *** CallTips.py Thu Jun 26 01:16:56 2003 --- CallTips.py_old Tue Dec 31 07:59:14 2002 *************** *** 164,175 **** # See if we can use the docstring doc = getattr(ob, "__doc__", "") if doc: ! doc = doc.lstrip() pos = doc.find("\n") if pos < 0 or pos > 70: pos = 70 ! if argText and doc: argText += "\n" ! argText = (argText + doc[:pos]).rstrip() return argText --- 164,176 ---- # See if we can use the docstring doc = getattr(ob, "__doc__", "") if doc: ! while doc[:1] in " \t\n": ! doc = doc[1:] pos = doc.find("\n") if pos < 0 or pos > 70: pos = 70 ! if argText: argText += "\n" ! argText += doc[:pos] return argText Unit tests are tricky (since the 2.3 problem is an infinite loop): Attached is a test that won't get stuck in a loop. -Scott David Daniels Scott.Daniels@Acm.Org ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=769142&group_id=5470 From noreply@sourceforge.net Thu Jul 10 15:29:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 07:29:19 -0700 Subject: [Patches] [ python-Patches-762934 ] address test_time.py failures under Redhat 6.2 Message-ID: Patches item #762934, was opened at 2003-06-29 20:44 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762934&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Brett Cannon (bcannon) Summary: address test_time.py failures under Redhat 6.2 Initial Comment: A mangled version of this patch is also in bug: http://www.python.org/sf/728051 Looks like tzset(3) is broken under Redhat 6.2 in a way that wasn't being detected by configure. This patch adds stricter tzset(3) checking to configure.in. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-10 10:29 Message: Logged In: YES user_id=12800 This patch didn't break RH9. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-03 16:16 Message: Logged In: YES user_id=357491 We can say it should fail under Linux, but we can't specify Red Hat 6.2. I am keeping an eye on this patch for bug #763153, but I have to wait until the OP applies it and tests it. Looking at the patch, beyond not realizing that the X-mas time was GMT initially and the unneeded variable assignments, the patch looks fine to me (might want to comment that tzset does not return a value; rather non-standard) although I am no autoconf expert and I am assuming it just compiles this C code and any problems it just says it fails. Neal, what OS are you running? If it is non-OS X (sorry, that's what I am running as well) can you give the patch a try? ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-07-01 23:51 Message: Logged In: YES user_id=46639 This patch has only been tested under OS X. I'm confident that it won't break other platforms. I have no real way of proving that it addresses the problem it is supposed to solve, however, as I don't have access to a box that fails the tzset test in test_time.py. The only reported platform that this is failing on is at http://www.python.org/sf/728051, so we could just flag this test as expected to fail on that platform, if someone knows how to do that. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-01 23:03 Message: Logged In: YES user_id=33168 Stuart, what boxes did you test this on? How confident are you that this won't break some other platform? I'm asking to try to determine if this should go into 2.3final (we only have 1 release candidate before release) or if this should wait for 2.3.1. Thanks for all your work on tzset. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762934&group_id=5470 From noreply@sourceforge.net Thu Jul 10 16:49:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 08:49:13 -0700 Subject: [Patches] [ python-Patches-768778 ] 2.3 whatsnew typo Message-ID: Patches item #768778, was opened at 2003-07-09 18:10 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=768778&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Bastian Kleineidam (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3 whatsnew typo Initial Comment: missing backslash near tix module item ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-10 10:49 Message: Logged In: YES user_id=80475 Good catch. Applying the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=768778&group_id=5470 From noreply@sourceforge.net Thu Jul 10 17:22:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 09:22:32 -0700 Subject: [Patches] [ python-Patches-763681 ] Support IDLE Edit of .py/.pyw from idlelib Message-ID: Patches item #763681, was opened at 2003-07-01 00:14 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763681&group_id=5470 Category: Windows Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 7 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Kurt B. Kaiser (kbk) Summary: Support IDLE Edit of .py/.pyw from idlelib Initial Comment: Windows File Types / Actions: IDLE has moved, this patch binds editing a python file to .../Lib/idlelib/idle.pyw instead of .../Tools/idle/idle.pyw ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 11:22 Message: Logged In: YES user_id=149084 python20.wse Rev 1.128 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-10 09:06 Message: Logged In: YES user_id=31435 Looks fine to me -- thanks! Assigned back to Kurt. Kurt, if you don't want to apply the patch, assign it back to me and I'll apply it. Boosted priority too. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-05 11:08 Message: Logged In: YES user_id=21627 Assigning to Tim for review - the patch looks right to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763681&group_id=5470 From noreply@sourceforge.net Thu Jul 10 18:07:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 10:07:23 -0700 Subject: [Patches] [ python-Patches-769142 ] CallTip trimming may loop forever. Message-ID: Patches item #769142, was opened at 2003-07-10 14:13 Message generated for change (Settings changed) made by scott_daniels You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=769142&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Scott David Daniels (scott_daniels) Assigned to: Nobody/Anonymous (nobody) Summary: CallTip trimming may loop forever. Initial Comment: (also applies to 2.2.x) While trying to understand someone else's half-developed code, I found an interesting problem in Idle. This bug is far nastier in 2.3 (which I was using at the time). testcase.py: def function(arg): ''' ''' return 1 In Idle if you type >>> import testcase >>> testcase.function( The code will loop trying to place a calltip in 2.3 (in 2.2.0, it raises an exception). After investigation, I found the following code: python/dist/src/Lib/idlelib/CallTips.py: ... while doc[:1] in " \t\n": doc = doc[1:] pos = doc.find("\n") ... With the new string semantics for 'in', this loop will be checking ('' in ' \t\n') (a bad state of affairs). The following patch should fix it: *** CallTips.py Thu Jun 26 01:16:56 2003 --- CallTips.py_old Tue Dec 31 07:59:14 2002 *************** *** 164,175 **** # See if we can use the docstring doc = getattr(ob, "__doc__", "") if doc: ! doc = doc.lstrip() pos = doc.find("\n") if pos < 0 or pos > 70: pos = 70 ! if argText and doc: argText += "\n" ! argText = (argText + doc[:pos]).rstrip() return argText --- 164,176 ---- # See if we can use the docstring doc = getattr(ob, "__doc__", "") if doc: ! while doc[:1] in " \t\n": ! doc = doc[1:] pos = doc.find("\n") if pos < 0 or pos > 70: pos = 70 ! if argText: argText += "\n" ! argText += doc[:pos] return argText Unit tests are tricky (since the 2.3 problem is an infinite loop): Attached is a test that won't get stuck in a loop. -Scott David Daniels Scott.Daniels@Acm.Org ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=769142&group_id=5470 From noreply@sourceforge.net Thu Jul 10 19:14:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 11:14:43 -0700 Subject: [Patches] [ python-Patches-762963 ] timemodule.c: Python loses current timezone Message-ID: Patches item #762963, was opened at 2003-06-30 02:18 Message generated for change (Comment added) made by quale You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762963&group_id=5470 Category: Modules Group: None >Status: Open Resolution: Rejected Priority: 5 Submitted By: Doug Quale (quale) Assigned to: Brett Cannon (bcannon) Summary: timemodule.c: Python loses current timezone Initial Comment: Python routines in timemodule.c sometimes force glibc to use GMT instead of the correct timezone. I think this is a longstanding bug, but I have only looked at Python 2.2 and 2.33b1. This bug has been reported before (510218) but it was misdiagnosed and closed. It also came up recently in on the python-list (http://aspn.activestate.com/ASPN/Mail/Message/python-list/1564384) where it was also misdiagnosed. Standard C and Python use a struct tm with 9 values. BSD influenced C libraries like glibc have an extra field (tm_gmtoff) that keeps the offset from UTC. BSD-style struct tm values know the correct timezone associated with the time, but Python and Standard C struct tm values don't so they can only assume the current timezone. Ideally Python would always treat stuct tm-style time tuples as being associated with the current timezone. Unfortunately in many cases Python forces glibc to use GMT rather than the current timezone. You can see the problem most graphically with the %z format in strftime(). In the transcript Python incorrectly gives the timezone offset as +0000 even though it gets the timezone name (CDT) correct: $ python2.3 Python 2.3b1+ (#2, Jun 4 2003, 03:03:32) [GCC 3.3 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> now = time.localtime() >>> print now (2003, 6, 29, 20, 3, 52, 6, 180, 1) >>> RFC822 = '%a, %d %b %Y %T %z' >>> print time.strftime(RFC822, now) Sun, 29 Jun 2003 20:03:52 +0000 >>> print time.strftime(RFC822) Sun, 29 Jun 2003 20:05:27 -0500 >>> print time.strftime('%Z', now) CDT The correct timezone is CDT and the correct offset is -0500. Notice that when time.strftime() computes the current time it it gets the correct timezone offset, but when the struct tm tuple is passed in it thinks the timezone offset is 0. (glibc does know that the correct timezone name is CDT even when passed a bad struct tm value, but that's not surprising since the timezone name is not stored in struct tm and it is not computed from timezone offset.) The problem is in the gettmargs() function in timemodule.c. When getmargs() parses a Python tm tuple it leaves the tm_gmtoff field zeroed. This specifically tells glibc that the timezone offset is 0, which is wrong for most people. (BSD libc may also be affected.) This problem does not occur when time_strfrtime() gets the current time itself since that codepath uses a struct tm value directly from the libc localtime(), leaving the tm_gmtoff field intact. Fortunately the fix is almost trivial. A call to mktime() will normalize the fields in the struct tm value, including the tm_gmtoff field. I conditionalized the patch only on HAVE_MKTIME. I'm pretty sure there's an autoconfigure test for tm_gmtoff and it would probably be better to use that. ---------------------------------------------------------------------- >Comment By: Doug Quale (quale) Date: 2003-07-10 18:14 Message: Logged In: YES user_id=812266 The problem isn't in strftime. The problem is in gettmargs() in timemodule.c. Python assumes that broken down time tuples are in the local timezone. The gettmargs() routine in timemodule.c is bugged on GNU libc and possibly other BSD-inspired C libraries. gettmargs() is supposed to take a Python broken down time tuple and convert it to a C struct tm. The Python time tuple is assumed to be in the local time zone, so the struct tm should be in the local timezone also. In glibc, struct tm has timezone fields so each struct tm knows its own timezone. The gettmargs() routine never fills in these extra fields so it always creates a struct tm in GMT. The appropriate behavior would be to set tm_gmtoff to the local timezone offset. My patch fixes gettmargs() to create struct tm's in the local timezone for C libraries that have the tm_gmtoff field in struct tm. As to the docs issue, the Python docs say that other formats may be supported than the ones listed. In reality, strftime() is passed to the underlying C library so the format codes supported are whatever the C library supports. The doc statement "Additional directives may be supported on certain platforms, but only the ones listed here have a meaning standardized by ANSI C" is wrong, or at least not up to date. C99 specifies several strftime format codes that are not listed including %z. I think Tim Smith also mentions this in a Python list posting from earlier this year. In the Python time module, the docs say strftime('format') is the same as strftime('format', localtime()). This is simply broken right now on glibc as has been reported by more than one person: >>> strftime('%z') '-0500' >>> strftime('%z', localtime()) '+0000' This is wrong. Unsupported format specifiers do not have this effect, for example: >>> strftime('%L') '%L' >>> strftime('%L', localtime()) '%L' This behavior is correct. A final note on the patch: I should have looked closer at the timemodule.c source. It already uses the appropriate #ifdef in other places. Instead of #ifdef HAVE_MKTIME my patch should be conditionalized #ifdef HAVE_STRUCT_TM_TM_ZONE. It's kind of amusing to write up this long of a justification for what is essentially a 3 line patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 22:36 Message: Logged In: YES user_id=357491 So the problem is with the %z directive not reporting the proper timezone offset, correct? If you look at http://www.python.org/ dev/doc/devel/lib/module-time.html , though, you will notice that %T is not supported as a directive for strftime or strptime nor has it ever been supported. Same goes for %T although it works in your example. Since the docs do not say that these directives are supported I am closing this patch since it would require altering both strftime and stprtime to support %z on all platforms which this patch does not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762963&group_id=5470 From noreply@sourceforge.net Thu Jul 10 19:21:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 11:21:23 -0700 Subject: [Patches] [ python-Patches-768442 ] Warning 'assignment shadows builtin' __builtins__ fix Message-ID: Patches item #768442, was opened at 2003-07-09 13:13 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=768442&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Troels Therkelsen (troelst) >Assigned to: Guido van Rossum (gvanrossum) Summary: Warning 'assignment shadows builtin' __builtins__ fix Initial Comment: Python 2.3b2 (#1, Jun 30 2003, 13:04:39) [GCC 2.95.3 20010315 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, new >>> d = {'__builtins__':{}} >>> d['mod'] = new.module('mod') >>> d['mod'].__builtins__ = d['__builtins__'] >>> exec "mod.reload = 42" in d :1: DeprecationWarning: assignment shadows builtin >>> d['sys'] = sys >>> exec "print sys._getframe().f_builtins" in d {} Surely, the DeprecationWarning shouldn't be printed if you use __builtins__ to explicitly define your own builtins dict? I mean, the 'reload' name in this case is an unknown name until it is defined in mod. The submitted patch fixes Objects/moduleobject.c so that the warning is only done if the module global you're assigning to exists in f_builtins. The patch is somehwat naive I admit, and it reuses as much as the old code as possible. Alternatively, instead of all the work done, one could just check directly in f_builtins. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2003-07-10 18:21 Message: Logged In: YES user_id=35752 I'm not sure what's the right thing to do here. One simple (I think) solution would be to not warn if __builtins__ are overridden. We don't want to implement anything too complicated since the 2.3 is quickly approaching. Hopefully Guido can give me a clue as to what kind of a solution he would like to see. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=768442&group_id=5470 From noreply@sourceforge.net Thu Jul 10 20:26:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 12:26:19 -0700 Subject: [Patches] [ python-Patches-732401 ] Allows os.forkpty to work on more platforms (Solaris!) Message-ID: Patches item #732401, was opened at 2003-05-04 23:20 Message generated for change (Settings changed) made by noah You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732401&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None >Priority: 8 Submitted By: Noah Spurrier (noah) Assigned to: Nobody/Anonymous (nobody) Summary: Allows os.forkpty to work on more platforms (Solaris!) Initial Comment: Recent changes to os.openpty() make it much more portable than earlier versions. Unfortunately, os.forkpty() was not also upgraded. This patch to posixpath.c allows os.forkpty() to run on any platform that supports os.openpty(). This new os.forkpty() will use the C system call forkpty() if available. If not available, then it will do it the old fashioned way with openpty and fork (and only if those too are available, otherwise forkpty remains undefined as before). Other benefits: Since the pty module is based on os.forkpty() this patch will automatically allow pty.fork() to work properly on more platforms. The pty module does not need to be changed. The logic for supporting pty's on multiple platforms can be maintained in one spot instead of in both the posix_module.c and pty.py One of the more notable platforms that does not support the forkpty system call is Solaris. Most importantly to me, this patch will allow os.forkpty() to be available under Solaris. I am testing it with my Pexpect module which makes heavy use of the pty module. With this patch Pexpect passes all my unit tests on Solaris. Pexpect has been tested on Linux, OpenBSD, Solaris, and Cygwin. I'm looking for an OS X server to test with. The code for forkpty should be quite portable and is based on the pty code in OpenSSH and the example in Stevens' "Advanced Programming in the UNIX Environment". I have included a test script, test_forkpty.py. Yours, Noah 
# Test to see if forkpty works. (But don't worry if it
isn't available.)

import os, time
from test.test_support import verbose, TestFailed,
TestSkipped

try:
    if verbose:
        print 'Calling os.forkpty()'
    pid, fd = os.forkpty()
except AttributeError:
    raise TestSkipped, 'No os.forkpty() available.'

if pid == 0: # child
    print 'I am not a robot!'
else:
    if verbose:
        print '(pid, fd) = (%d, %d)' % (pid, fd)
    time.sleep(1) # Give the child a chance to print.
    print 'Robots always say:', os.read(fd,100)
    os.close(fd)
---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732401&group_id=5470 From noreply@sourceforge.net Thu Jul 10 21:00:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 13:00:51 -0700 Subject: [Patches] [ python-Patches-766650 ] whichdb not ID'ing dbm files with GDBM backend Message-ID: Patches item #766650, was opened at 2003-07-06 13:09 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766650&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) >Assigned to: Martin v. Löwis (loewis) Summary: whichdb not ID'ing dbm files with GDBM backend Initial Comment: For the OS/2 EMX port, I build the dbm module with gdbm v1.7.3. At least with the OS/2 version of the gdbm v1.7.3 port, dbm databases consist only of the .pag file - there is no .dir file. In this case, the .pag file has the gdbm magic number. Currently whichdb fails to identify such dbm DBs on this platform because of the expectation that there be a .dir file as well as the .pag file. I'm not in any position to confirm whether the dbm module built with gdbm behaves the same way on other systems -information gratefully received on this topic. On the assumption that other platforms also have this behaviour, the attached patch attempts to detect whether a dbm DB has a gdbm signature just by checking the magic number of the .pag file. The patch involves a refactoring of the magic number code, which may be deemed inappropriate. It may be more expedient to just special case theEMX port in the dbm detection (by skipping looking for the .dir file on this platform). ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-10 15:02 Message: Logged In: YES user_id=250749 I've added a revised patch that attempts to address Martin's points. I've also added a patch that applies a workaround solely for the only platform (OS/2 EMX) known to me to have this issue, rather than trying to be fancy and all-encompassing. I incline to the view that the platform specific workaround would be safer for 2.3, with the more sophisticated approach added after the 2.3 release if appropriate. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-08 00:05 Message: Logged In: YES user_id=21627 The dbm module greatly varies in behaviour across platforms, depending on what underlying library is linked. On my Linux installation, the resulting files are identified as /tmp/u.dir: GNU dbm 1.x or ndbm database, little endian /tmp/u.pag: GNU dbm 1.x or ndbm database, little endian I recommend that you adjust your patch to take dbm.library into account, and go looking for gdbm magic only if you find that dbm is linked with gdbm. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766650&group_id=5470 From noreply@sourceforge.net Thu Jul 10 22:09:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 14:09:24 -0700 Subject: [Patches] [ python-Patches-766650 ] whichdb not ID'ing dbm files with GDBM backend Message-ID: Patches item #766650, was opened at 2003-07-06 13:09 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766650&group_id=5470 Category: Modules Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Martin v. Löwis (loewis) Summary: whichdb not ID'ing dbm files with GDBM backend Initial Comment: For the OS/2 EMX port, I build the dbm module with gdbm v1.7.3. At least with the OS/2 version of the gdbm v1.7.3 port, dbm databases consist only of the .pag file - there is no .dir file. In this case, the .pag file has the gdbm magic number. Currently whichdb fails to identify such dbm DBs on this platform because of the expectation that there be a .dir file as well as the .pag file. I'm not in any position to confirm whether the dbm module built with gdbm behaves the same way on other systems -information gratefully received on this topic. On the assumption that other platforms also have this behaviour, the attached patch attempts to detect whether a dbm DB has a gdbm signature just by checking the magic number of the .pag file. The patch involves a refactoring of the magic number code, which may be deemed inappropriate. It may be more expedient to just special case theEMX port in the dbm detection (by skipping looking for the .dir file on this platform). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-10 23:09 Message: Logged In: YES user_id=21627 I agree that the more conservative patch is better at this point; please apply it. The regroup the patch for 2.4 and leave it open (perhaps at a lower priority also). ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-10 15:02 Message: Logged In: YES user_id=250749 I've added a revised patch that attempts to address Martin's points. I've also added a patch that applies a workaround solely for the only platform (OS/2 EMX) known to me to have this issue, rather than trying to be fancy and all-encompassing. I incline to the view that the platform specific workaround would be safer for 2.3, with the more sophisticated approach added after the 2.3 release if appropriate. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-08 00:05 Message: Logged In: YES user_id=21627 The dbm module greatly varies in behaviour across platforms, depending on what underlying library is linked. On my Linux installation, the resulting files are identified as /tmp/u.dir: GNU dbm 1.x or ndbm database, little endian /tmp/u.pag: GNU dbm 1.x or ndbm database, little endian I recommend that you adjust your patch to take dbm.library into account, and go looking for gdbm magic only if you find that dbm is linked with gdbm. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766650&group_id=5470 From noreply@sourceforge.net Thu Jul 10 22:14:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 14:14:02 -0700 Subject: [Patches] [ python-Patches-768840 ] IRIX libmpc patch Message-ID: Patches item #768840, was opened at 2003-07-10 03:43 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=768840&group_id=5470 Category: Build Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Michael Pruett (mpruett) Assigned to: Nobody/Anonymous (nobody) Summary: IRIX libmpc patch Initial Comment: It is not necessary to link with -lmpc to get native threads on IRIX. I do not recall a time when this library was needed, but it was certainly prior to the release of IRIX 6.5 (in 1998). I propose removing references to this library, as is done in the following patch against Python 2.2.3. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-10 23:14 Message: Logged In: YES user_id=21627 According to PEP 11, only Irix 4 support will get dropped, and only in Python 2.4. So Irix 5 is still supposed to work, and this patch is unacceptable unless there is confirmation that the patch does work on Irix 5. Of course, we can deprecate Irix 5 and mpc support now, i.e. give a warning in Python 2.4, and remove the code in Python 2.5. Then we would need to make sure whether all Irix 6 releases work with this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=768840&group_id=5470 From noreply@sourceforge.net Thu Jul 10 22:25:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 14:25:52 -0700 Subject: [Patches] [ python-Patches-766650 ] whichdb not ID'ing dbm files with GDBM backend Message-ID: Patches item #766650, was opened at 2003-07-06 13:09 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766650&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) >Assigned to: Andrew I MacIntyre (aimacintyre) Summary: whichdb not ID'ing dbm files with GDBM backend Initial Comment: For the OS/2 EMX port, I build the dbm module with gdbm v1.7.3. At least with the OS/2 version of the gdbm v1.7.3 port, dbm databases consist only of the .pag file - there is no .dir file. In this case, the .pag file has the gdbm magic number. Currently whichdb fails to identify such dbm DBs on this platform because of the expectation that there be a .dir file as well as the .pag file. I'm not in any position to confirm whether the dbm module built with gdbm behaves the same way on other systems -information gratefully received on this topic. On the assumption that other platforms also have this behaviour, the attached patch attempts to detect whether a dbm DB has a gdbm signature just by checking the magic number of the .pag file. The patch involves a refactoring of the magic number code, which may be deemed inappropriate. It may be more expedient to just special case theEMX port in the dbm detection (by skipping looking for the .dir file on this platform). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-10 23:09 Message: Logged In: YES user_id=21627 I agree that the more conservative patch is better at this point; please apply it. The regroup the patch for 2.4 and leave it open (perhaps at a lower priority also). ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-10 15:02 Message: Logged In: YES user_id=250749 I've added a revised patch that attempts to address Martin's points. I've also added a patch that applies a workaround solely for the only platform (OS/2 EMX) known to me to have this issue, rather than trying to be fancy and all-encompassing. I incline to the view that the platform specific workaround would be safer for 2.3, with the more sophisticated approach added after the 2.3 release if appropriate. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-08 00:05 Message: Logged In: YES user_id=21627 The dbm module greatly varies in behaviour across platforms, depending on what underlying library is linked. On my Linux installation, the resulting files are identified as /tmp/u.dir: GNU dbm 1.x or ndbm database, little endian /tmp/u.pag: GNU dbm 1.x or ndbm database, little endian I recommend that you adjust your patch to take dbm.library into account, and go looking for gdbm magic only if you find that dbm is linked with gdbm. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766650&group_id=5470 From noreply@sourceforge.net Fri Jul 11 13:21:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Jul 2003 05:21:39 -0700 Subject: [Patches] [ python-Patches-766650 ] whichdb not ID'ing dbm files with GDBM backend Message-ID: Patches item #766650, was opened at 2003-07-06 21:09 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766650&group_id=5470 Category: Modules >Group: Python 2.4 Status: Open Resolution: Accepted >Priority: 3 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Andrew I MacIntyre (aimacintyre) Summary: whichdb not ID'ing dbm files with GDBM backend Initial Comment: For the OS/2 EMX port, I build the dbm module with gdbm v1.7.3. At least with the OS/2 version of the gdbm v1.7.3 port, dbm databases consist only of the .pag file - there is no .dir file. In this case, the .pag file has the gdbm magic number. Currently whichdb fails to identify such dbm DBs on this platform because of the expectation that there be a .dir file as well as the .pag file. I'm not in any position to confirm whether the dbm module built with gdbm behaves the same way on other systems -information gratefully received on this topic. On the assumption that other platforms also have this behaviour, the attached patch attempts to detect whether a dbm DB has a gdbm signature just by checking the magic number of the .pag file. The patch involves a refactoring of the magic number code, which may be deemed inappropriate. It may be more expedient to just special case theEMX port in the dbm detection (by skipping looking for the .dir file on this platform). ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-11 22:21 Message: Logged In: YES user_id=250749 OS/2 EMX specific workaround applied to whichdb.py as v1.17. Re-grouped to 2.4; lowered to priority 3. I'll prepare a version of the revised "complete" patch to take into account application of the EMX workaround after 2.3 is out the door. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-11 07:09 Message: Logged In: YES user_id=21627 I agree that the more conservative patch is better at this point; please apply it. The regroup the patch for 2.4 and leave it open (perhaps at a lower priority also). ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-10 23:02 Message: Logged In: YES user_id=250749 I've added a revised patch that attempts to address Martin's points. I've also added a patch that applies a workaround solely for the only platform (OS/2 EMX) known to me to have this issue, rather than trying to be fancy and all-encompassing. I incline to the view that the platform specific workaround would be safer for 2.3, with the more sophisticated approach added after the 2.3 release if appropriate. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-08 08:05 Message: Logged In: YES user_id=21627 The dbm module greatly varies in behaviour across platforms, depending on what underlying library is linked. On my Linux installation, the resulting files are identified as /tmp/u.dir: GNU dbm 1.x or ndbm database, little endian /tmp/u.pag: GNU dbm 1.x or ndbm database, little endian I recommend that you adjust your patch to take dbm.library into account, and go looking for gdbm magic only if you find that dbm is linked with gdbm. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766650&group_id=5470 From noreply@sourceforge.net Fri Jul 11 14:54:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Jul 2003 06:54:26 -0700 Subject: [Patches] [ python-Patches-708374 ] add offset to mmap Message-ID: Patches item #708374, was opened at 2003-03-23 09:33 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: add offset to mmap Initial Comment: This patch is from Yotam Medini sent to me in mail. It adds support for the offset parameter to mmap. It ignores the check for mmap size "if the file is character device. Some device drivers (which I happen to use) have zero size in fstat buffer, but still one can seek() read() and tell()." I added minimal doc and tests. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-07-11 09:54 Message: Logged In: YES user_id=11375 There's nothing to test on Windows; the HAVE_FSTAT code is inside #ifdef UNIX. If it works on Unix (and it seems to for me, on Linux), then it should be checked in. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-26 23:19 Message: Logged In: YES user_id=33168 Yes, the check for block devices should go in now as a bug fix I think. Can anyone test on windows? I attached a patch for just this minimal change. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-06-26 13:05 Message: Logged In: YES user_id=11375 Shouldn't block devices also be excluded from the size check? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-05 10:59 Message: Logged In: YES user_id=33168 Since this is an enhancement, it will not go into 2.2.x. The patch is stuck right now. It needs to be tested on Windows, but I can't do that (no Windows development environment). If you can update the patch to work on both Unix and Windows, we can apply the patch. ---------------------------------------------------------------------- Comment By: Yotam Medini (yotam) Date: 2003-06-05 10:55 Message: Logged In: YES user_id=22624 Just wondering, what is the status of this patch. I guess it did not make it to 2.2.3. regards -- yotam ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-22 23:53 Message: Logged In: YES user_id=80475 This is much closer and solves the last problem. But, it fails test_mmap with a windows errocode 8: not enought memory. Raymond ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 14:20 Message: Logged In: YES user_id=33168 http://msdn.microsoft.com/library/en-us/fileio/base/mapviewoffile.asp?frame=true says the offset must be a multiple of the allocation granularity which used to be hard-coded at 64k. So maybe if we made the offset 64k it would work. The attached patch makes this test change for windows only. (I think the Unix offset must be a multiple of PAGESIZE.) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 13:53 Message: Logged In: YES user_id=80475 I had posted the wrong traceback (before the rebuild). The correct one shows Window Error #87. Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) WindowsError: [Errno 87] The parameter is incorrect [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 13:14 Message: Logged In: YES user_id=33168 Note to self: Self, make sure to backport S_ISCHR() fix. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 13:10 Message: Logged In: YES user_id=33168 Hmmm, did Modules/mmapmodule.c get rebuilt? There is code in the patch for new_mmap_object() to support the offset keyword in both Unix & Windows. I don't see a problem in the code/patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 12:01 Message: Logged In: YES user_id=80475 It doesn't run: C:\py23\Lib\test>python_d test_mmap.py Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) TypeError: 'offset' is an invalid keyword argument for this function [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-09 19:35 Message: Logged In: YES user_id=33168 Raymond, could you try to test this patch and see if it works on Windows? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-29 16:28 Message: Logged In: YES user_id=33168 Sounds fair. Attached is an updated patch which includes windows support (I think). I cannot test on Windows. Tested on Linux. Includes updates for doc, src, and test. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-27 19:12 Message: Logged In: YES user_id=21627 I think non-zero offsets need to be supported for Windows as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-23 10:37 Message: Logged In: YES user_id=33168 Email received from Yotam: I have downloaded and patched the 2.3a source. compiled locally just this module, and it worked fine for my application (with offset for character device file) I did not run the released test though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 From noreply@sourceforge.net Sat Jul 12 00:52:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Jul 2003 16:52:38 -0700 Subject: [Patches] [ python-Patches-762963 ] timemodule.c: Python loses current timezone Message-ID: Patches item #762963, was opened at 2003-06-29 21:18 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762963&group_id=5470 Category: Modules Group: None Status: Open Resolution: Rejected Priority: 5 Submitted By: Doug Quale (quale) >Assigned to: Martin v. Löwis (loewis) Summary: timemodule.c: Python loses current timezone Initial Comment: Python routines in timemodule.c sometimes force glibc to use GMT instead of the correct timezone. I think this is a longstanding bug, but I have only looked at Python 2.2 and 2.33b1. This bug has been reported before (510218) but it was misdiagnosed and closed. It also came up recently in on the python-list (http://aspn.activestate.com/ASPN/Mail/Message/python-list/1564384) where it was also misdiagnosed. Standard C and Python use a struct tm with 9 values. BSD influenced C libraries like glibc have an extra field (tm_gmtoff) that keeps the offset from UTC. BSD-style struct tm values know the correct timezone associated with the time, but Python and Standard C struct tm values don't so they can only assume the current timezone. Ideally Python would always treat stuct tm-style time tuples as being associated with the current timezone. Unfortunately in many cases Python forces glibc to use GMT rather than the current timezone. You can see the problem most graphically with the %z format in strftime(). In the transcript Python incorrectly gives the timezone offset as +0000 even though it gets the timezone name (CDT) correct: $ python2.3 Python 2.3b1+ (#2, Jun 4 2003, 03:03:32) [GCC 3.3 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> now = time.localtime() >>> print now (2003, 6, 29, 20, 3, 52, 6, 180, 1) >>> RFC822 = '%a, %d %b %Y %T %z' >>> print time.strftime(RFC822, now) Sun, 29 Jun 2003 20:03:52 +0000 >>> print time.strftime(RFC822) Sun, 29 Jun 2003 20:05:27 -0500 >>> print time.strftime('%Z', now) CDT The correct timezone is CDT and the correct offset is -0500. Notice that when time.strftime() computes the current time it it gets the correct timezone offset, but when the struct tm tuple is passed in it thinks the timezone offset is 0. (glibc does know that the correct timezone name is CDT even when passed a bad struct tm value, but that's not surprising since the timezone name is not stored in struct tm and it is not computed from timezone offset.) The problem is in the gettmargs() function in timemodule.c. When getmargs() parses a Python tm tuple it leaves the tm_gmtoff field zeroed. This specifically tells glibc that the timezone offset is 0, which is wrong for most people. (BSD libc may also be affected.) This problem does not occur when time_strfrtime() gets the current time itself since that codepath uses a struct tm value directly from the libc localtime(), leaving the tm_gmtoff field intact. Fortunately the fix is almost trivial. A call to mktime() will normalize the fields in the struct tm value, including the tm_gmtoff field. I conditionalized the patch only on HAVE_MKTIME. I'm pretty sure there's an autoconfigure test for tm_gmtoff and it would probably be better to use that. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-11 18:52 Message: Logged In: YES user_id=80475 Martin, can you diagnose whether this should be closed, applied, or deferred? ---------------------------------------------------------------------- Comment By: Doug Quale (quale) Date: 2003-07-10 13:14 Message: Logged In: YES user_id=812266 The problem isn't in strftime. The problem is in gettmargs() in timemodule.c. Python assumes that broken down time tuples are in the local timezone. The gettmargs() routine in timemodule.c is bugged on GNU libc and possibly other BSD-inspired C libraries. gettmargs() is supposed to take a Python broken down time tuple and convert it to a C struct tm. The Python time tuple is assumed to be in the local time zone, so the struct tm should be in the local timezone also. In glibc, struct tm has timezone fields so each struct tm knows its own timezone. The gettmargs() routine never fills in these extra fields so it always creates a struct tm in GMT. The appropriate behavior would be to set tm_gmtoff to the local timezone offset. My patch fixes gettmargs() to create struct tm's in the local timezone for C libraries that have the tm_gmtoff field in struct tm. As to the docs issue, the Python docs say that other formats may be supported than the ones listed. In reality, strftime() is passed to the underlying C library so the format codes supported are whatever the C library supports. The doc statement "Additional directives may be supported on certain platforms, but only the ones listed here have a meaning standardized by ANSI C" is wrong, or at least not up to date. C99 specifies several strftime format codes that are not listed including %z. I think Tim Smith also mentions this in a Python list posting from earlier this year. In the Python time module, the docs say strftime('format') is the same as strftime('format', localtime()). This is simply broken right now on glibc as has been reported by more than one person: >>> strftime('%z') '-0500' >>> strftime('%z', localtime()) '+0000' This is wrong. Unsupported format specifiers do not have this effect, for example: >>> strftime('%L') '%L' >>> strftime('%L', localtime()) '%L' This behavior is correct. A final note on the patch: I should have looked closer at the timemodule.c source. It already uses the appropriate #ifdef in other places. Instead of #ifdef HAVE_MKTIME my patch should be conditionalized #ifdef HAVE_STRUCT_TM_TM_ZONE. It's kind of amusing to write up this long of a justification for what is essentially a 3 line patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 17:36 Message: Logged In: YES user_id=357491 So the problem is with the %z directive not reporting the proper timezone offset, correct? If you look at http://www.python.org/ dev/doc/devel/lib/module-time.html , though, you will notice that %T is not supported as a directive for strftime or strptime nor has it ever been supported. Same goes for %T although it works in your example. Since the docs do not say that these directives are supported I am closing this patch since it would require altering both strftime and stprtime to support %z on all platforms which this patch does not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762963&group_id=5470 From noreply@sourceforge.net Sat Jul 12 02:06:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Jul 2003 18:06:25 -0700 Subject: [Patches] [ python-Patches-726751 ] Clarify docs for except target assignment Message-ID: Patches item #726751, was opened at 2003-04-24 03:30 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=726751&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Clarify docs for except target assignment Initial Comment: I have always found the docs dealing with the target as found in 'except' clauses misleading:: try: raise Exception('argument 1') except Exception, x: print type(x) This code outputs ```` while I would have expected ```` from the way the docs read (at least to me). So I tried to clarify this in the tutorial and references (Doc/tut/tut.tex and Doc/ref/ref7.tex respectively). If people think I am nuts and people don't get confused by the fact that having a single target gets the exception instance assigned to it while a tuple of targets gets the exception to unpack its arg values through iterating over them with the way the docs are now, then I guess I am nuts. =) Regardless of the final outcome of this patch, the result will close/ reject bug #675928 . ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-11 20:06 Message: Logged In: YES user_id=80475 Since the tutorial now only talks about class based exceptions, I've applied that part of the patch after a rewrite. See Doc/tut/tut.tex 1.195 ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 02:38 Message: Logged In: YES user_id=357491 Fair enough. Do you want me to keep this patch open as a reminder to you, Fred, or should I just go ahead and reject it? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-04-25 12:11 Message: Logged In: YES user_id=3066 There's definately a shortcoming in those docs; they really still assume the world of string exceptions. The patch, on the other hand, somewhat assumes a world of class-based exceptions. The reality is a bit more conflated; I'll see what I can do about it, but I don't think the patch as it stands is really right either. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=726751&group_id=5470 From noreply@sourceforge.net Sat Jul 12 08:54:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Jul 2003 00:54:20 -0700 Subject: [Patches] [ python-Patches-764470 ] Bugfix for incorrect xmlrpclib.Fault representation Message-ID: Patches item #764470, was opened at 2003-07-02 11:06 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764470&group_id=5470 Category: Library (Lib) Group: Python 2.2.x >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gavrie Philipson (gavrie) Assigned to: Martin v. Löwis (loewis) Summary: Bugfix for incorrect xmlrpclib.Fault representation Initial Comment: The xmlrpclib library represents a Fault object with an extraneous 'args' member field. The reason for this is that the dump function blindly marshals all variables of the Fault object, and since Fault is a subclass of Exception it inherits the 'args' attribute. According to the XML-RPC spec, adding additional fields to a Fault response is not allowed. The attached patch is a simple solution to the problem. Sample Fault XML output that shows the problem: faultCode 900 args faultString boo ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-12 09:54 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as xmlrpclib.py 1.29 and 1.15.4.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764470&group_id=5470 From noreply@sourceforge.net Sat Jul 12 19:53:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Jul 2003 11:53:53 -0700 Subject: [Patches] [ python-Patches-770244 ] Allow passing of LDFLAGS to distutils Message-ID: Patches item #770244, was opened at 2003-07-12 20: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=770244&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: Allow passing of LDFLAGS to distutils Initial Comment: Allow passing LDFLAGS to the linker command when linking a python extension. This lets us pass the right flags to correctly find libraries required for certain extensions, e.g. zlib.so. P.S.: This patch is taken from NetBSD's pkg collection and not by me. (I guess it's original author is jlam@.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=770244&group_id=5470 From noreply@sourceforge.net Sat Jul 12 19:56:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Jul 2003 11:56:53 -0700 Subject: [Patches] [ python-Patches-770245 ] LDFLAGS needed for PGEN Message-ID: Patches item #770245, was opened at 2003-07-12 20:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=770245&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: LDFLAGS needed for PGEN Initial Comment: If Python is built with non-std. libs (dmalloc in my case) then the build fails for PGEN, because LDFLAGS isn't passed to it. The attached patch for 2.3/cvs fixes that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=770245&group_id=5470 From noreply@sourceforge.net Sat Jul 12 19:57:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Jul 2003 11:57:46 -0700 Subject: [Patches] [ python-Patches-770244 ] Allow passing of LDFLAGS to distutils Message-ID: Patches item #770244, was opened at 2003-07-12 20:53 Message generated for change (Comment added) made by marc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=770244&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: Allow passing of LDFLAGS to distutils Initial Comment: Allow passing LDFLAGS to the linker command when linking a python extension. This lets us pass the right flags to correctly find libraries required for certain extensions, e.g. zlib.so. P.S.: This patch is taken from NetBSD's pkg collection and not by me. (I guess it's original author is jlam@.) ---------------------------------------------------------------------- >Comment By: Marc Recht (marc) Date: 2003-07-12 20:57 Message: Logged In: YES user_id=205 Forgot to mention, the patch is for 2.3/cvs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=770244&group_id=5470 From noreply@sourceforge.net Sat Jul 12 21:42:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Jul 2003 13:42:08 -0700 Subject: [Patches] [ python-Patches-770280 ] PyMarshal_ReadLastObjectFromFile Message-ID: Patches item #770280, was opened at 2003-07-12 16:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=770280&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Felix (paulfelix) Assigned to: Nobody/Anonymous (nobody) Summary: PyMarshal_ReadLastObjectFromFile Initial Comment: This is a new implementation of the performance boost in PyMarshal_ReadLastObjectFromFile where the pyc file data is loaded into memory before parsing. The original logic is as follows: - Get the file size. - If the file size is 16K or less, allocate a 16k char buffer on the call stack and load the file data into the buffer. - Otherwise, if file size is 256k or less, malloc a temp char buffer from the heap and load the file data into the buffer. - Otherwise, don't use a buffer. Allocating 16k on the call stack can cause a stack overflow when doing nested imports in a secondary thread. The default thread stack size on some systems is quite small (64k on HP-UX!). Also, allocating/freeing memory on the heap for this purpose may not be warranted. This patch proposes a new implentation that allocates a static 256k char buffer and uses a thread lock to keep it thread-safe. The lock/unlock function logic was taken from import.c. Note: performance tests show an improvment on some platforms when the static char buffer is defined at the file level instead of inside the function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=770280&group_id=5470 From noreply@sourceforge.net Sun Jul 13 00:01:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Jul 2003 16:01:14 -0700 Subject: [Patches] [ python-Patches-762934 ] address test_time.py failures under Redhat 6.2 Message-ID: Patches item #762934, was opened at 2003-06-29 17:44 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762934&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Brett Cannon (bcannon) Summary: address test_time.py failures under Redhat 6.2 Initial Comment: A mangled version of this patch is also in bug: http://www.python.org/sf/728051 Looks like tzset(3) is broken under Redhat 6.2 in a way that wasn't being detected by configure. This patch adds stricter tzset(3) checking to configure.in. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-12 16:01 Message: Logged In: YES user_id=357491 Well, it didn't work for two people for Red Hat 6.2 . Perhaps being more explicit for the test? To give that a shot, I am uploading a patch that tests explicitly for AEDT as the daylight-savings timezone. I snagged the code mostly from Modules/timemodule.c . Now this is untested so there could be syntax problems. I can't get a proper version of Autoconf to run on my system so I can run autoreconf. Hopefully this will deal with the problem. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-10 07:29 Message: Logged In: YES user_id=12800 This patch didn't break RH9. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-03 13:16 Message: Logged In: YES user_id=357491 We can say it should fail under Linux, but we can't specify Red Hat 6.2. I am keeping an eye on this patch for bug #763153, but I have to wait until the OP applies it and tests it. Looking at the patch, beyond not realizing that the X-mas time was GMT initially and the unneeded variable assignments, the patch looks fine to me (might want to comment that tzset does not return a value; rather non-standard) although I am no autoconf expert and I am assuming it just compiles this C code and any problems it just says it fails. Neal, what OS are you running? If it is non-OS X (sorry, that's what I am running as well) can you give the patch a try? ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-07-01 20:51 Message: Logged In: YES user_id=46639 This patch has only been tested under OS X. I'm confident that it won't break other platforms. I have no real way of proving that it addresses the problem it is supposed to solve, however, as I don't have access to a box that fails the tzset test in test_time.py. The only reported platform that this is failing on is at http://www.python.org/sf/728051, so we could just flag this test as expected to fail on that platform, if someone knows how to do that. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-01 20:03 Message: Logged In: YES user_id=33168 Stuart, what boxes did you test this on? How confident are you that this won't break some other platform? I'm asking to try to determine if this should go into 2.3final (we only have 1 release candidate before release) or if this should wait for 2.3.1. Thanks for all your work on tzset. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762934&group_id=5470 From noreply@sourceforge.net Sun Jul 13 02:05:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Jul 2003 18:05:50 -0700 Subject: [Patches] [ python-Patches-747364 ] BaseHTTPServer doesn't need StringIO intermediary Message-ID: Patches item #747364, was opened at 2003-06-02 02:40 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=747364&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) >Assigned to: Martin v. Löwis (loewis) Summary: BaseHTTPServer doesn't need StringIO intermediary Initial Comment: This is Python2.3b1, from CVS I looked at the implementation of the BaseHTTPServer.py code where it does the actual parsing. I see that it has # Deal with pipelining bytes = "" while 1: line = self.rfile.readline() bytes = bytes + line if line == '\r\n' or line == '\n' or line == '': break # Examine the headers and look for a Connection directive hfile = cStringIO.StringIO(bytes) self.headers = self.MessageClass(hfile) The MessageClass is mimetools.Message, which uses rfc822.Message to parse the headers. The Message reads the input stream up to and including the end-of-header blank line, but no further, using while 1: ... line = self.fp.readline() ... elif self.islast(line): # Note! No pushback here! The delimiter line gets eaten break def islast(self, line): """Determine whether a line is a legal end of RFC 2822 headers. and checks for '\r\n' or '\n' so it seems the temporary copy into a StringIO isn't needed since the Message can deal with it correctly. Plus, Message takes a 'seekable' parameter which can turn off seeking on the input stream, and has for a long time (since well before Martin's "Deal with pipelining code"). The proof, as they say, is in the pudding. Thought I don't know why. Anyway, I replaced the "bytes ... " code and used self.rfile rather than the temporary StringIO hfile, as in self.headers = self.MessageClass(self.rfile) print "Does it work?", repr(self.rfile.readline()) (I added the print to make sure the data wasn't eaten) I tested it with the module's mainline self-test, and it seems to work just fine. Attached patch does the same, only without the debugging print statement. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-12 20:05 Message: Logged In: YES user_id=80475 Martin, you added this code last year (ver 1.19) in response to www.python.org/sf/430706 . Was the += build from readline and the trip through CStringIO necessary? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-01 00:27 Message: Logged In: YES user_id=80475 "the proof is in the pudding" lost its clarity when it got shortened from "the proof of the pudding is in the eating" meaning that recipes are best judged by their results. The patch looks fine to me but it is too late in the development cycle to include in Py2.3. Marking as a Py2.4 idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=747364&group_id=5470 From noreply@sourceforge.net Sun Jul 13 02:37:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Jul 2003 18:37:28 -0700 Subject: [Patches] [ python-Patches-723231 ] __del__ in dumbdbm fails under some circumstances Message-ID: Patches item #723231, was opened at 2003-04-17 12:02 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723231&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None >Priority: 6 Submitted By: Tim Stone (timstone4) >Assigned to: Tim Peters (tim_one) Summary: __del__ in dumbdbm fails under some circumstances Initial Comment: Using dumbdbm for simple testing, I occasionally get the following error: Exception exceptions.AttributeError: "'NoneType' object has no attribute 'error' " in > ignored I've tracked it down to a problem with the releasing of the reference to _os during __del__, which then calls _commit. _commit proceeds to use the _os, which is given a value of None... blamo... ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-12 20:37 Message: Logged In: YES user_id=80475 Tim, did you see this during your review of dumbdbm? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723231&group_id=5470 From noreply@sourceforge.net Sun Jul 13 02:53:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Jul 2003 18:53:27 -0700 Subject: [Patches] [ python-Patches-723231 ] __del__ in dumbdbm fails under some circumstances Message-ID: Patches item #723231, was opened at 2003-04-17 13:02 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723231&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Tim Stone (timstone4) Assigned to: Tim Peters (tim_one) Summary: __del__ in dumbdbm fails under some circumstances Initial Comment: Using dumbdbm for simple testing, I occasionally get the following error: Exception exceptions.AttributeError: "'NoneType' object has no attribute 'error' " in > ignored I've tracked it down to a problem with the releasing of the reference to _os during __del__, which then calls _commit. _commit proceeds to use the _os, which is given a value of None... blamo... ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-12 21:53 Message: Logged In: YES user_id=31435 I didn't pay attention to it, but it is an obvious shutdown race. I'll fix it. Tim Stone (the OP) is a contributor to the spambayes project, and it turns out this is damned important in spambayes, because it appears the spambayes code never calls the dumbdbm.close() method explicitly. Something else I learned from the dumbdbm review is that a dumbdbm's disk files routinely get out of synch with each other, and rely on someone calling close() or __del__() to get them back in synch. If a .bak file doesn't already exist, though, this shutdown race can prevent __del__() from synch'ing the files. Boosted priority. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-12 21:37 Message: Logged In: YES user_id=80475 Tim, did you see this during your review of dumbdbm? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723231&group_id=5470 From noreply@sourceforge.net Sun Jul 13 03:23:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Jul 2003 19:23:29 -0700 Subject: [Patches] [ python-Patches-723231 ] __del__ in dumbdbm fails under some circumstances Message-ID: Patches item #723231, was opened at 2003-04-17 13:02 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723231&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Tim Stone (timstone4) Assigned to: Tim Peters (tim_one) Summary: __del__ in dumbdbm fails under some circumstances Initial Comment: Using dumbdbm for simple testing, I occasionally get the following error: Exception exceptions.AttributeError: "'NoneType' object has no attribute 'error' " in > ignored I've tracked it down to a problem with the releasing of the reference to _os during __del__, which then calls _commit. _commit proceeds to use the _os, which is given a value of None... blamo... ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-12 22:23 Message: Logged In: YES user_id=31435 Fixed, in Lib/dumbdbm.py; rev 1.26 Misc/NEWS; rev 1.810 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-12 21:53 Message: Logged In: YES user_id=31435 I didn't pay attention to it, but it is an obvious shutdown race. I'll fix it. Tim Stone (the OP) is a contributor to the spambayes project, and it turns out this is damned important in spambayes, because it appears the spambayes code never calls the dumbdbm.close() method explicitly. Something else I learned from the dumbdbm review is that a dumbdbm's disk files routinely get out of synch with each other, and rely on someone calling close() or __del__() to get them back in synch. If a .bak file doesn't already exist, though, this shutdown race can prevent __del__() from synch'ing the files. Boosted priority. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-12 21:37 Message: Logged In: YES user_id=80475 Tim, did you see this during your review of dumbdbm? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723231&group_id=5470 From noreply@sourceforge.net Sun Jul 13 03:27:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Jul 2003 19:27:30 -0700 Subject: [Patches] [ python-Patches-762934 ] address test_time.py failures under Redhat 6.2 Message-ID: Patches item #762934, was opened at 2003-06-29 17:44 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762934&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Brett Cannon (bcannon) Summary: address test_time.py failures under Redhat 6.2 Initial Comment: A mangled version of this patch is also in bug: http://www.python.org/sf/728051 Looks like tzset(3) is broken under Redhat 6.2 in a way that wasn't being detected by configure. This patch adds stricter tzset(3) checking to configure.in. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-12 19:27 Message: Logged In: YES user_id=357491 Quick update: I got autoreconf to work and it seems to work for me. I also tested the C code in isolation and had no problems. So I now I just need other people to apply the patch and say whether it works. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-12 16:01 Message: Logged In: YES user_id=357491 Well, it didn't work for two people for Red Hat 6.2 . Perhaps being more explicit for the test? To give that a shot, I am uploading a patch that tests explicitly for AEDT as the daylight-savings timezone. I snagged the code mostly from Modules/timemodule.c . Now this is untested so there could be syntax problems. I can't get a proper version of Autoconf to run on my system so I can run autoreconf. Hopefully this will deal with the problem. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-10 07:29 Message: Logged In: YES user_id=12800 This patch didn't break RH9. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-03 13:16 Message: Logged In: YES user_id=357491 We can say it should fail under Linux, but we can't specify Red Hat 6.2. I am keeping an eye on this patch for bug #763153, but I have to wait until the OP applies it and tests it. Looking at the patch, beyond not realizing that the X-mas time was GMT initially and the unneeded variable assignments, the patch looks fine to me (might want to comment that tzset does not return a value; rather non-standard) although I am no autoconf expert and I am assuming it just compiles this C code and any problems it just says it fails. Neal, what OS are you running? If it is non-OS X (sorry, that's what I am running as well) can you give the patch a try? ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-07-01 20:51 Message: Logged In: YES user_id=46639 This patch has only been tested under OS X. I'm confident that it won't break other platforms. I have no real way of proving that it addresses the problem it is supposed to solve, however, as I don't have access to a box that fails the tzset test in test_time.py. The only reported platform that this is failing on is at http://www.python.org/sf/728051, so we could just flag this test as expected to fail on that platform, if someone knows how to do that. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-01 20:03 Message: Logged In: YES user_id=33168 Stuart, what boxes did you test this on? How confident are you that this won't break some other platform? I'm asking to try to determine if this should go into 2.3final (we only have 1 release candidate before release) or if this should wait for 2.3.1. Thanks for all your work on tzset. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762934&group_id=5470 From noreply@sourceforge.net Sun Jul 13 11:06:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 03:06:16 -0700 Subject: [Patches] [ python-Patches-747364 ] BaseHTTPServer doesn't need StringIO intermediary Message-ID: Patches item #747364, was opened at 2003-06-02 09:40 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=747364&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Martin v. Löwis (loewis) Summary: BaseHTTPServer doesn't need StringIO intermediary Initial Comment: This is Python2.3b1, from CVS I looked at the implementation of the BaseHTTPServer.py code where it does the actual parsing. I see that it has # Deal with pipelining bytes = "" while 1: line = self.rfile.readline() bytes = bytes + line if line == '\r\n' or line == '\n' or line == '': break # Examine the headers and look for a Connection directive hfile = cStringIO.StringIO(bytes) self.headers = self.MessageClass(hfile) The MessageClass is mimetools.Message, which uses rfc822.Message to parse the headers. The Message reads the input stream up to and including the end-of-header blank line, but no further, using while 1: ... line = self.fp.readline() ... elif self.islast(line): # Note! No pushback here! The delimiter line gets eaten break def islast(self, line): """Determine whether a line is a legal end of RFC 2822 headers. and checks for '\r\n' or '\n' so it seems the temporary copy into a StringIO isn't needed since the Message can deal with it correctly. Plus, Message takes a 'seekable' parameter which can turn off seeking on the input stream, and has for a long time (since well before Martin's "Deal with pipelining code"). The proof, as they say, is in the pudding. Thought I don't know why. Anyway, I replaced the "bytes ... " code and used self.rfile rather than the temporary StringIO hfile, as in self.headers = self.MessageClass(self.rfile) print "Does it work?", repr(self.rfile.readline()) (I added the print to make sure the data wasn't eaten) I tested it with the module's mainline self-test, and it seems to work just fine. Attached patch does the same, only without the debugging print statement. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-13 12:06 Message: Logged In: YES user_id=21627 I agree this is a reasonable change, and I also agree that it comes too late for 2.3. I don't know what Chris Lawrence' rationale was to wrap the header in a StringIO; I'll ask him. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-13 03:05 Message: Logged In: YES user_id=80475 Martin, you added this code last year (ver 1.19) in response to www.python.org/sf/430706 . Was the += build from readline and the trip through CStringIO necessary? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-01 07:27 Message: Logged In: YES user_id=80475 "the proof is in the pudding" lost its clarity when it got shortened from "the proof of the pudding is in the eating" meaning that recipes are best judged by their results. The patch looks fine to me but it is too late in the development cycle to include in Py2.3. Marking as a Py2.4 idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=747364&group_id=5470 From noreply@sourceforge.net Sun Jul 13 11:09:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 03:09:21 -0700 Subject: [Patches] [ python-Patches-770244 ] Allow passing of LDFLAGS to distutils Message-ID: Patches item #770244, was opened at 2003-07-12 20:53 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=770244&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: Allow passing of LDFLAGS to distutils Initial Comment: Allow passing LDFLAGS to the linker command when linking a python extension. This lets us pass the right flags to correctly find libraries required for certain extensions, e.g. zlib.so. P.S.: This patch is taken from NetBSD's pkg collection and not by me. (I guess it's original author is jlam@.) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-13 12:09 Message: Logged In: YES user_id=21627 This is a new feature, which is not acceptable at this time. In addition, it needs documentation, and we need the original author to submit it (or have the original author transfer the copyright to the submitter). So I'm rejecting this patch on formal grounds; I agree that it is technically a good idea. ---------------------------------------------------------------------- Comment By: Marc Recht (marc) Date: 2003-07-12 20:57 Message: Logged In: YES user_id=205 Forgot to mention, the patch is for 2.3/cvs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=770244&group_id=5470 From noreply@sourceforge.net Sun Jul 13 11:11:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 03:11:06 -0700 Subject: [Patches] [ python-Patches-770245 ] LDFLAGS needed for PGEN Message-ID: Patches item #770245, was opened at 2003-07-12 20:56 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=770245&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: LDFLAGS needed for PGEN Initial Comment: If Python is built with non-std. libs (dmalloc in my case) then the build fails for PGEN, because LDFLAGS isn't passed to it. The attached patch for 2.3/cvs fixes that. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-13 12:11 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as 1.136. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=770245&group_id=5470 From noreply@sourceforge.net Sun Jul 13 11:27:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 03:27:25 -0700 Subject: [Patches] [ python-Patches-769142 ] CallTip trimming may loop forever. Message-ID: Patches item #769142, was opened at 2003-07-10 09:13 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=769142&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Scott David Daniels (scott_daniels) >Assigned to: Kurt B. Kaiser (kbk) Summary: CallTip trimming may loop forever. Initial Comment: (also applies to 2.2.x) While trying to understand someone else's half-developed code, I found an interesting problem in Idle. This bug is far nastier in 2.3 (which I was using at the time). testcase.py: def function(arg): ''' ''' return 1 In Idle if you type >>> import testcase >>> testcase.function( The code will loop trying to place a calltip in 2.3 (in 2.2.0, it raises an exception). After investigation, I found the following code: python/dist/src/Lib/idlelib/CallTips.py: ... while doc[:1] in " \t\n": doc = doc[1:] pos = doc.find("\n") ... With the new string semantics for 'in', this loop will be checking ('' in ' \t\n') (a bad state of affairs). The following patch should fix it: *** CallTips.py Thu Jun 26 01:16:56 2003 --- CallTips.py_old Tue Dec 31 07:59:14 2002 *************** *** 164,175 **** # See if we can use the docstring doc = getattr(ob, "__doc__", "") if doc: ! doc = doc.lstrip() pos = doc.find("\n") if pos < 0 or pos > 70: pos = 70 ! if argText and doc: argText += "\n" ! argText = (argText + doc[:pos]).rstrip() return argText --- 164,176 ---- # See if we can use the docstring doc = getattr(ob, "__doc__", "") if doc: ! while doc[:1] in " \t\n": ! doc = doc[1:] pos = doc.find("\n") if pos < 0 or pos > 70: pos = 70 ! if argText: argText += "\n" ! argText += doc[:pos] return argText Unit tests are tricky (since the 2.3 problem is an infinite loop): Attached is a test that won't get stuck in a loop. -Scott David Daniels Scott.Daniels@Acm.Org ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-13 05:27 Message: Logged In: YES user_id=80475 See Lib/idlelib/CallTips.py 1.10 Assigning to Kurt for backport. Good catch and nice patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=769142&group_id=5470 From noreply@sourceforge.net Sun Jul 13 14:57:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 06:57:50 -0700 Subject: [Patches] [ python-Patches-770521 ] make itertools type declarations static Message-ID: Patches item #770521, was opened at 2003-07-13 23: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=770521&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 3 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Raymond Hettinger (rhettinger) Summary: make itertools type declarations static Initial Comment: the intertools module defines a number of type structures, which are not declared static. these structures don't need to be symbolically visible outside the module, and I think would be better declared static to reduce namespace pollution. this became noticeable as I was building itertools in an external module on OS/2, where these type symbols were not exported from the external module (DLL) with no problem. I changed to building itertools into the core DLL, and my DLL export machinery started to export these type symbols. I've changed the core DLL export definition machinery to deal with this, so this is a low priority "cleanup" issue in my view. Assigned to Raymond, as itertools is his baby. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=770521&group_id=5470 From noreply@sourceforge.net Sun Jul 13 15:06:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 07:06:12 -0700 Subject: [Patches] [ python-Patches-732401 ] Allows os.forkpty to work on more platforms (Solaris!) Message-ID: Patches item #732401, was opened at 2003-05-05 09:20 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732401&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 8 Submitted By: Noah Spurrier (noah) >Assigned to: Martin v. Löwis (loewis) Summary: Allows os.forkpty to work on more platforms (Solaris!) Initial Comment: Recent changes to os.openpty() make it much more portable than earlier versions. Unfortunately, os.forkpty() was not also upgraded. This patch to posixpath.c allows os.forkpty() to run on any platform that supports os.openpty(). This new os.forkpty() will use the C system call forkpty() if available. If not available, then it will do it the old fashioned way with openpty and fork (and only if those too are available, otherwise forkpty remains undefined as before). Other benefits: Since the pty module is based on os.forkpty() this patch will automatically allow pty.fork() to work properly on more platforms. The pty module does not need to be changed. The logic for supporting pty's on multiple platforms can be maintained in one spot instead of in both the posix_module.c and pty.py One of the more notable platforms that does not support the forkpty system call is Solaris. Most importantly to me, this patch will allow os.forkpty() to be available under Solaris. I am testing it with my Pexpect module which makes heavy use of the pty module. With this patch Pexpect passes all my unit tests on Solaris. Pexpect has been tested on Linux, OpenBSD, Solaris, and Cygwin. I'm looking for an OS X server to test with. The code for forkpty should be quite portable and is based on the pty code in OpenSSH and the example in Stevens' "Advanced Programming in the UNIX Environment". I have included a test script, test_forkpty.py. Yours, Noah 
# Test to see if forkpty works. (But don't worry if it
isn't available.)

import os, time
from test.test_support import verbose, TestFailed,
TestSkipped

try:
    if verbose:
        print 'Calling os.forkpty()'
    pid, fd = os.forkpty()
except AttributeError:
    raise TestSkipped, 'No os.forkpty() available.'

if pid == 0: # child
    print 'I am not a robot!'
else:
    if verbose:
        print '(pid, fd) = (%d, %d)' % (pid, fd)
    time.sleep(1) # Give the child a chance to print.
    print 'Robots always say:', os.read(fd,100)
    os.close(fd)
---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-14 00:06 Message: Logged In: YES user_id=250749 Martin, I've eyeballed the patch and can't see that it would have any effect other than to extend the availability of os.forkpty (assuming that it compiles on all the platforms that it extends to). FreeBSD has forkpty(), so I can't test this myself (I haven't tried to set up a SF compile farm account yet). I'm a little wary about it being this close to 2.3 release - is this worth pursuing at this point, or should it be deferred to post-2.3? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732401&group_id=5470 From noreply@sourceforge.net Sun Jul 13 15:58:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 07:58:24 -0700 Subject: [Patches] [ python-Patches-770521 ] make itertools type declarations static Message-ID: Patches item #770521, was opened at 2003-07-13 08:57 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=770521&group_id=5470 Category: Modules Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 3 Submitted By: Andrew I MacIntyre (aimacintyre) >Assigned to: Andrew I MacIntyre (aimacintyre) Summary: make itertools type declarations static Initial Comment: the intertools module defines a number of type structures, which are not declared static. these structures don't need to be symbolically visible outside the module, and I think would be better declared static to reduce namespace pollution. this became noticeable as I was building itertools in an external module on OS/2, where these type symbols were not exported from the external module (DLL) with no problem. I changed to building itertools into the core DLL, and my DLL export machinery started to export these type symbols. I've changed the core DLL export definition machinery to deal with this, so this is a low priority "cleanup" issue in my view. Assigned to Raymond, as itertools is his baby. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=770521&group_id=5470 From noreply@sourceforge.net Sun Jul 13 16:08:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 08:08:40 -0700 Subject: [Patches] [ python-Patches-732401 ] Allows os.forkpty to work on more platforms (Solaris!) Message-ID: Patches item #732401, was opened at 2003-05-05 01:20 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732401&group_id=5470 Category: Modules >Group: Python 2.4 Status: Open Resolution: None Priority: 8 Submitted By: Noah Spurrier (noah) >Assigned to: Nobody/Anonymous (nobody) Summary: Allows os.forkpty to work on more platforms (Solaris!) Initial Comment: Recent changes to os.openpty() make it much more portable than earlier versions. Unfortunately, os.forkpty() was not also upgraded. This patch to posixpath.c allows os.forkpty() to run on any platform that supports os.openpty(). This new os.forkpty() will use the C system call forkpty() if available. If not available, then it will do it the old fashioned way with openpty and fork (and only if those too are available, otherwise forkpty remains undefined as before). Other benefits: Since the pty module is based on os.forkpty() this patch will automatically allow pty.fork() to work properly on more platforms. The pty module does not need to be changed. The logic for supporting pty's on multiple platforms can be maintained in one spot instead of in both the posix_module.c and pty.py One of the more notable platforms that does not support the forkpty system call is Solaris. Most importantly to me, this patch will allow os.forkpty() to be available under Solaris. I am testing it with my Pexpect module which makes heavy use of the pty module. With this patch Pexpect passes all my unit tests on Solaris. Pexpect has been tested on Linux, OpenBSD, Solaris, and Cygwin. I'm looking for an OS X server to test with. The code for forkpty should be quite portable and is based on the pty code in OpenSSH and the example in Stevens' "Advanced Programming in the UNIX Environment". I have included a test script, test_forkpty.py. Yours, Noah 
# Test to see if forkpty works. (But don't worry if it
isn't available.)

import os, time
from test.test_support import verbose, TestFailed,
TestSkipped

try:
    if verbose:
        print 'Calling os.forkpty()'
    pid, fd = os.forkpty()
except AttributeError:
    raise TestSkipped, 'No os.forkpty() available.'

if pid == 0: # child
    print 'I am not a robot!'
else:
    if verbose:
        print '(pid, fd) = (%d, %d)' % (pid, fd)
    time.sleep(1) # Give the child a chance to print.
    print 'Robots always say:', os.read(fd,100)
    os.close(fd)
---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-13 17:08 Message: Logged In: YES user_id=21627 It should be deferred. Mere addition of openpty has nearly made the entire pty handling nearly unusable on some systems, as the C library versions of these functions tend to be buggy beyond repair. So I'd rather don't add any more breakage here. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-13 16:06 Message: Logged In: YES user_id=250749 Martin, I've eyeballed the patch and can't see that it would have any effect other than to extend the availability of os.forkpty (assuming that it compiles on all the platforms that it extends to). FreeBSD has forkpty(), so I can't test this myself (I haven't tried to set up a SF compile farm account yet). I'm a little wary about it being this close to 2.3 release - is this worth pursuing at this point, or should it be deferred to post-2.3? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732401&group_id=5470 From noreply@sourceforge.net Sun Jul 13 16:20:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 08:20:38 -0700 Subject: [Patches] [ python-Patches-765238 ] fix fnmatch.__all__ Message-ID: Patches item #765238, was opened at 2003-07-03 05:54 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=765238&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: Postponed Priority: 5 Submitted By: George Yoshida (quiver) >Assigned to: Martin v. Löwis (loewis) Summary: fix fnmatch.__all__ Initial Comment: There are two reasons for this patch. First, in the fnmatch.py, __all__ doesn't include "filter", so if you tried to use fnmatch.filter like this, >>> from fnmatch import * >>> filter built-in function, filter, is called instead of fnmatch.filter. >>> filter Second, "translate" is just a helper function used by other functions in the fnmatch module, and that's why it's not documented in the Python library reference. I think "translate" should be removed from fnmatch.__all__. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-13 10:20 Message: Logged In: YES user_id=80475 Even in Py2.4, I prefer that "translate" not be removed -- it has already been exposed and there is not real benefit to pulling it back -- also, it may have some use as a stand- alone function. I would not mind if "filter" were added to __all__ for Py2.3 -- IMO, that part is a bug fix. Martin, is this okay with you? ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-07-07 07:32 Message: Logged In: YES user_id=671362 > this is an interface change. If you're reluctant to remove "translate", that's OK. I just propose to add "filter" to __all__. That won't do any harm. > I feel that it is too late for 2.3: I don't feel it's too late for 2.3. There's at least one month left before the final release of 2.3. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-05 11:02 Message: Logged In: YES user_id=21627 While I agree with that, I feel that it is too late for 2.3: this is an interface change. So postponing it to 2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=765238&group_id=5470 From noreply@sourceforge.net Sun Jul 13 16:29:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 08:29:01 -0700 Subject: [Patches] [ python-Patches-764221 ] add set/getattr interface to tkFont.Font objects Message-ID: Patches item #764221, was opened at 2003-07-01 16:21 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764221&group_id=5470 Category: Tkinter >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Nobody/Anonymous (nobody) Summary: add set/getattr interface to tkFont.Font objects Initial Comment: A simple patch to add the dictionary style get/set attribute interface to tkFont.Font objects. This makes it act like almost all other Tkinter classes. Perhaps best saved for Python 2.4, but it's such a simple change I thought it might squeak by. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764221&group_id=5470 From noreply@sourceforge.net Sun Jul 13 16:32:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 08:32:58 -0700 Subject: [Patches] [ python-Patches-764217 ] Fix for tkFont.Font(name=...) Message-ID: Patches item #764217, was opened at 2003-07-01 16:14 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764217&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) >Assigned to: Martin v. Löwis (loewis) Summary: Fix for tkFont.Font(name=...) Initial Comment: tkFont.Font(name=xxx) crashes if a font by the specified name already exists. This is a problem for several reasons, the main one being that it makes life really tough if you want to creat a new tkFont.Font object for a given Tcl named font. This simple fix handles the problem. I've also included a new method __eq__ so that two tkFont.Font objects that point to the same Tcl named font compare as equal. I felt this is important because the fix makes it easier to have multiple such tkFont.Font objects. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-13 10:32 Message: Logged In: YES user_id=80475 The first part of the patch appears reasonable. For the second part, it's a bit late for an API change. Martin, is this bugfix okay for Py2.3? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764217&group_id=5470 From noreply@sourceforge.net Sun Jul 13 16:33:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 08:33:20 -0700 Subject: [Patches] [ python-Patches-763580 ] Minor enhancements to Variable class Message-ID: Patches item #763580, was opened at 2003-06-30 19:18 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763580&group_id=5470 Category: Tkinter >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Nobody/Anonymous (nobody) Summary: Minor enhancements to Variable class Initial Comment: Here are two enhancements to the Variable class (and subclasses): 1) Variables now have a "name" argument. This works just like the name argument on almost every other Tkinter class. Its primary purpose is to allow the user to create a new Tkinter Variable given its tk name. Justification: at present there is no reasonable way to do this. One can create a new Tkinter Variable and then assign its name property, but that relies on knowing about internals and it has the ugly side effect of creating an unused tk variable I admit that setvar and getvar can be used to work around the problem, but sometimes it's nicer to use a Tkinter Variable and often it's not convenient to pass the original Variable around to where it's needed. One can get an original Tkinter widget back again given the corresponding tk widget's name. It's time to allow this for Tkinter Variables (and tkFont.Font objects, but that's a separate issue I submitted as a bug report with associated suggested simple fix). 2) Variables now have a "value" argument to specify the initial value. This shortens: avar = StringVar() avar.set("desired value") to: avar = StringVar("desired value") Justification: it's useful. It's also harmless in that it will not break any existing code. I think one can even do something like this in tcl (i.e. define a variable and set it at the same time) and it's certainly a normal thing to do in Python itself. -- Russell ---------------------------------------------------------------------- Comment By: Russell Owen (reowen) Date: 2003-07-01 12:30 Message: Logged In: YES user_id=431773 Replacement patch. The difference is what to do if value is supplied and the variable already exists (not something existing users would ever see unless they were doing nasty stuff directly in tcl). The old version treated value as an initial value, this new version always honors value if it is specified. I think this will be less surprising to the user (in those rare cases where it matters). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763580&group_id=5470 From noreply@sourceforge.net Sun Jul 13 16:42:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 08:42:15 -0700 Subject: [Patches] [ python-Patches-765238 ] fix fnmatch.__all__ Message-ID: Patches item #765238, was opened at 2003-07-03 12:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=765238&group_id=5470 Category: Library (Lib) >Group: Python 2.3 Status: Open Resolution: Postponed Priority: 5 Submitted By: George Yoshida (quiver) >Assigned to: Raymond Hettinger (rhettinger) Summary: fix fnmatch.__all__ Initial Comment: There are two reasons for this patch. First, in the fnmatch.py, __all__ doesn't include "filter", so if you tried to use fnmatch.filter like this, >>> from fnmatch import * >>> filter built-in function, filter, is called instead of fnmatch.filter. >>> filter Second, "translate" is just a helper function used by other functions in the fnmatch module, and that's why it's not documented in the Python library reference. I think "translate" should be removed from fnmatch.__all__. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-13 17:42 Message: Logged In: YES user_id=21627 Raymond: I agree. Adding filter is a bugfix; removing translate should not happen at all. Please make it happen before 2.3. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-13 17:20 Message: Logged In: YES user_id=80475 Even in Py2.4, I prefer that "translate" not be removed -- it has already been exposed and there is not real benefit to pulling it back -- also, it may have some use as a stand- alone function. I would not mind if "filter" were added to __all__ for Py2.3 -- IMO, that part is a bug fix. Martin, is this okay with you? ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-07-07 14:32 Message: Logged In: YES user_id=671362 > this is an interface change. If you're reluctant to remove "translate", that's OK. I just propose to add "filter" to __all__. That won't do any harm. > I feel that it is too late for 2.3: I don't feel it's too late for 2.3. There's at least one month left before the final release of 2.3. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-05 18:02 Message: Logged In: YES user_id=21627 While I agree with that, I feel that it is too late for 2.3: this is an interface change. So postponing it to 2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=765238&group_id=5470 From noreply@sourceforge.net Sun Jul 13 16:57:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 08:57:37 -0700 Subject: [Patches] [ python-Patches-764217 ] Fix for tkFont.Font(name=...) Message-ID: Patches item #764217, was opened at 2003-07-01 23:14 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764217&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Martin v. Löwis (loewis) Summary: Fix for tkFont.Font(name=...) Initial Comment: tkFont.Font(name=xxx) crashes if a font by the specified name already exists. This is a problem for several reasons, the main one being that it makes life really tough if you want to creat a new tkFont.Font object for a given Tcl named font. This simple fix handles the problem. I've also included a new method __eq__ so that two tkFont.Font objects that point to the same Tcl named font compare as equal. I felt this is important because the fix makes it easier to have multiple such tkFont.Font objects. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-13 17:57 Message: Logged In: YES user_id=21627 While the bug might be worth fixing, I think the approach taken is wrong. With the patch, it will invoke "font names" for all new tkFont objects, which might be a significant overhead. To really preserve current behaviour, it should continue to 'font create', and fall back to 'font configure' in case of an exception. Actually, it is not clear what the right behaviour is in the first place. 'font configure' would change the settings of the existing font. If the name clash is by coincidence, it would be better to raise an exception instead of silently modifying the existing font. In the face of ambiguity, refuse the temptation to guess. So to really fix this, tkFont.forName (or tkFont.existing) should be provided. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-13 17:32 Message: Logged In: YES user_id=80475 The first part of the patch appears reasonable. For the second part, it's a bit late for an API change. Martin, is this bugfix okay for Py2.3? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764217&group_id=5470 From noreply@sourceforge.net Sun Jul 13 17:07:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 09:07:02 -0700 Subject: [Patches] [ python-Patches-765238 ] fix fnmatch.__all__ Message-ID: Patches item #765238, was opened at 2003-07-03 05:54 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=765238&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Raymond Hettinger (rhettinger) Summary: fix fnmatch.__all__ Initial Comment: There are two reasons for this patch. First, in the fnmatch.py, __all__ doesn't include "filter", so if you tried to use fnmatch.filter like this, >>> from fnmatch import * >>> filter built-in function, filter, is called instead of fnmatch.filter. >>> filter Second, "translate" is just a helper function used by other functions in the fnmatch module, and that's why it's not documented in the Python library reference. I think "translate" should be removed from fnmatch.__all__. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-13 11:07 Message: Logged In: YES user_id=80475 Done. See Lib/fnmatch.py 1.14 George, thanks for submitting patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-13 10:42 Message: Logged In: YES user_id=21627 Raymond: I agree. Adding filter is a bugfix; removing translate should not happen at all. Please make it happen before 2.3. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-13 10:20 Message: Logged In: YES user_id=80475 Even in Py2.4, I prefer that "translate" not be removed -- it has already been exposed and there is not real benefit to pulling it back -- also, it may have some use as a stand- alone function. I would not mind if "filter" were added to __all__ for Py2.3 -- IMO, that part is a bug fix. Martin, is this okay with you? ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-07-07 07:32 Message: Logged In: YES user_id=671362 > this is an interface change. If you're reluctant to remove "translate", that's OK. I just propose to add "filter" to __all__. That won't do any harm. > I feel that it is too late for 2.3: I don't feel it's too late for 2.3. There's at least one month left before the final release of 2.3. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-05 11:02 Message: Logged In: YES user_id=21627 While I agree with that, I feel that it is too late for 2.3: this is an interface change. So postponing it to 2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=765238&group_id=5470 From noreply@sourceforge.net Sun Jul 13 20:52:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 12:52:42 -0700 Subject: [Patches] [ python-Patches-732401 ] Allows os.forkpty to work on more platforms (Solaris!) Message-ID: Patches item #732401, was opened at 2003-05-04 23:20 Message generated for change (Comment added) made by noah You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732401&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 8 Submitted By: Noah Spurrier (noah) Assigned to: Nobody/Anonymous (nobody) Summary: Allows os.forkpty to work on more platforms (Solaris!) Initial Comment: Recent changes to os.openpty() make it much more portable than earlier versions. Unfortunately, os.forkpty() was not also upgraded. This patch to posixpath.c allows os.forkpty() to run on any platform that supports os.openpty(). This new os.forkpty() will use the C system call forkpty() if available. If not available, then it will do it the old fashioned way with openpty and fork (and only if those too are available, otherwise forkpty remains undefined as before). Other benefits: Since the pty module is based on os.forkpty() this patch will automatically allow pty.fork() to work properly on more platforms. The pty module does not need to be changed. The logic for supporting pty's on multiple platforms can be maintained in one spot instead of in both the posix_module.c and pty.py One of the more notable platforms that does not support the forkpty system call is Solaris. Most importantly to me, this patch will allow os.forkpty() to be available under Solaris. I am testing it with my Pexpect module which makes heavy use of the pty module. With this patch Pexpect passes all my unit tests on Solaris. Pexpect has been tested on Linux, OpenBSD, Solaris, and Cygwin. I'm looking for an OS X server to test with. The code for forkpty should be quite portable and is based on the pty code in OpenSSH and the example in Stevens' "Advanced Programming in the UNIX Environment". I have included a test script, test_forkpty.py. Yours, Noah 
# Test to see if forkpty works. (But don't worry if it
isn't available.)

import os, time
from test.test_support import verbose, TestFailed,
TestSkipped

try:
    if verbose:
        print 'Calling os.forkpty()'
    pid, fd = os.forkpty()
except AttributeError:
    raise TestSkipped, 'No os.forkpty() available.'

if pid == 0: # child
    print 'I am not a robot!'
else:
    if verbose:
        print '(pid, fd) = (%d, %d)' % (pid, fd)
    time.sleep(1) # Give the child a chance to print.
    print 'Robots always say:', os.read(fd,100)
    os.close(fd)
---------------------------------------------------------------------- >Comment By: Noah Spurrier (noah) Date: 2003-07-13 19:52 Message: Logged In: YES user_id=59261 Which openpty has made pty handling unusable? There are two: os.openpty() and pty.openpty(). What is a good strategy for making pty handling more consistent? I think it's impossible to make pty handling totally platform independent, but Python's pty module could certainly be cleaned up to hide the ugliness. Platforms that are not explicitly handled should probably not define forkpty. Currently Solaris uses the wrong code -- thus leaving the user with the impression that Solaris is supported, but providing a broken implementation. Pty handling is a headache -- I never understood why it was overlooked by POSIX given that ptys are critical to every UNIX system. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-13 15:08 Message: Logged In: YES user_id=21627 It should be deferred. Mere addition of openpty has nearly made the entire pty handling nearly unusable on some systems, as the C library versions of these functions tend to be buggy beyond repair. So I'd rather don't add any more breakage here. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-13 14:06 Message: Logged In: YES user_id=250749 Martin, I've eyeballed the patch and can't see that it would have any effect other than to extend the availability of os.forkpty (assuming that it compiles on all the platforms that it extends to). FreeBSD has forkpty(), so I can't test this myself (I haven't tried to set up a SF compile farm account yet). I'm a little wary about it being this close to 2.3 release - is this worth pursuing at this point, or should it be deferred to post-2.3? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732401&group_id=5470 From noreply@sourceforge.net Sun Jul 13 21:27:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 13:27:46 -0700 Subject: [Patches] [ python-Patches-732401 ] Allows os.forkpty to work on more platforms (Solaris!) Message-ID: Patches item #732401, was opened at 2003-05-05 01:20 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732401&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 8 Submitted By: Noah Spurrier (noah) Assigned to: Nobody/Anonymous (nobody) Summary: Allows os.forkpty to work on more platforms (Solaris!) Initial Comment: Recent changes to os.openpty() make it much more portable than earlier versions. Unfortunately, os.forkpty() was not also upgraded. This patch to posixpath.c allows os.forkpty() to run on any platform that supports os.openpty(). This new os.forkpty() will use the C system call forkpty() if available. If not available, then it will do it the old fashioned way with openpty and fork (and only if those too are available, otherwise forkpty remains undefined as before). Other benefits: Since the pty module is based on os.forkpty() this patch will automatically allow pty.fork() to work properly on more platforms. The pty module does not need to be changed. The logic for supporting pty's on multiple platforms can be maintained in one spot instead of in both the posix_module.c and pty.py One of the more notable platforms that does not support the forkpty system call is Solaris. Most importantly to me, this patch will allow os.forkpty() to be available under Solaris. I am testing it with my Pexpect module which makes heavy use of the pty module. With this patch Pexpect passes all my unit tests on Solaris. Pexpect has been tested on Linux, OpenBSD, Solaris, and Cygwin. I'm looking for an OS X server to test with. The code for forkpty should be quite portable and is based on the pty code in OpenSSH and the example in Stevens' "Advanced Programming in the UNIX Environment". I have included a test script, test_forkpty.py. Yours, Noah 
# Test to see if forkpty works. (But don't worry if it
isn't available.)

import os, time
from test.test_support import verbose, TestFailed,
TestSkipped

try:
    if verbose:
        print 'Calling os.forkpty()'
    pid, fd = os.forkpty()
except AttributeError:
    raise TestSkipped, 'No os.forkpty() available.'

if pid == 0: # child
    print 'I am not a robot!'
else:
    if verbose:
        print '(pid, fd) = (%d, %d)' % (pid, fd)
    time.sleep(1) # Give the child a chance to print.
    print 'Robots always say:', os.read(fd,100)
    os.close(fd)
---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-13 22:27 Message: Logged In: YES user_id=21627 The addition of support for ptmx inside posix.openpty has caused the test suite to hang on HP-UX and other systems. A good strategy would be to find some code base, and rigorously test these on all 8 or so supported Unix variants. I'm willing to accept any code that has been tested so, but only after Python 2.3. ---------------------------------------------------------------------- Comment By: Noah Spurrier (noah) Date: 2003-07-13 21:52 Message: Logged In: YES user_id=59261 Which openpty has made pty handling unusable? There are two: os.openpty() and pty.openpty(). What is a good strategy for making pty handling more consistent? I think it's impossible to make pty handling totally platform independent, but Python's pty module could certainly be cleaned up to hide the ugliness. Platforms that are not explicitly handled should probably not define forkpty. Currently Solaris uses the wrong code -- thus leaving the user with the impression that Solaris is supported, but providing a broken implementation. Pty handling is a headache -- I never understood why it was overlooked by POSIX given that ptys are critical to every UNIX system. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-13 17:08 Message: Logged In: YES user_id=21627 It should be deferred. Mere addition of openpty has nearly made the entire pty handling nearly unusable on some systems, as the C library versions of these functions tend to be buggy beyond repair. So I'd rather don't add any more breakage here. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-13 16:06 Message: Logged In: YES user_id=250749 Martin, I've eyeballed the patch and can't see that it would have any effect other than to extend the availability of os.forkpty (assuming that it compiles on all the platforms that it extends to). FreeBSD has forkpty(), so I can't test this myself (I haven't tried to set up a SF compile farm account yet). I'm a little wary about it being this close to 2.3 release - is this worth pursuing at this point, or should it be deferred to post-2.3? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732401&group_id=5470 From noreply@sourceforge.net Sun Jul 13 23:17:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 15:17:38 -0700 Subject: [Patches] [ python-Patches-747364 ] BaseHTTPServer doesn't need StringIO intermediary Message-ID: Patches item #747364, was opened at 2003-06-02 02:40 Message generated for change (Comment added) made by lordsutch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=747364&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Martin v. Löwis (loewis) Summary: BaseHTTPServer doesn't need StringIO intermediary Initial Comment: This is Python2.3b1, from CVS I looked at the implementation of the BaseHTTPServer.py code where it does the actual parsing. I see that it has # Deal with pipelining bytes = "" while 1: line = self.rfile.readline() bytes = bytes + line if line == '\r\n' or line == '\n' or line == '': break # Examine the headers and look for a Connection directive hfile = cStringIO.StringIO(bytes) self.headers = self.MessageClass(hfile) The MessageClass is mimetools.Message, which uses rfc822.Message to parse the headers. The Message reads the input stream up to and including the end-of-header blank line, but no further, using while 1: ... line = self.fp.readline() ... elif self.islast(line): # Note! No pushback here! The delimiter line gets eaten break def islast(self, line): """Determine whether a line is a legal end of RFC 2822 headers. and checks for '\r\n' or '\n' so it seems the temporary copy into a StringIO isn't needed since the Message can deal with it correctly. Plus, Message takes a 'seekable' parameter which can turn off seeking on the input stream, and has for a long time (since well before Martin's "Deal with pipelining code"). The proof, as they say, is in the pudding. Thought I don't know why. Anyway, I replaced the "bytes ... " code and used self.rfile rather than the temporary StringIO hfile, as in self.headers = self.MessageClass(self.rfile) print "Does it work?", repr(self.rfile.readline()) (I added the print to make sure the data wasn't eaten) I tested it with the module's mainline self-test, and it seems to work just fine. Attached patch does the same, only without the debugging print statement. ---------------------------------------------------------------------- Comment By: Chris Lawrence (lordsutch) Date: 2003-07-13 17:17 Message: Logged In: YES user_id=6757 I honestly don't remember why I used the StringIO wrapper. It could have been that the seekable parameter was undocumented at the time, or added while I was evolving the patch locally, so I wasn't aware of it. (I'd probably change the parameter to False, since this is a 2.3+ patch, but that's a cosmetic issue.) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-13 05:06 Message: Logged In: YES user_id=21627 I agree this is a reasonable change, and I also agree that it comes too late for 2.3. I don't know what Chris Lawrence' rationale was to wrap the header in a StringIO; I'll ask him. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-12 20:05 Message: Logged In: YES user_id=80475 Martin, you added this code last year (ver 1.19) in response to www.python.org/sf/430706 . Was the += build from readline and the trip through CStringIO necessary? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-01 00:27 Message: Logged In: YES user_id=80475 "the proof is in the pudding" lost its clarity when it got shortened from "the proof of the pudding is in the eating" meaning that recipes are best judged by their results. The patch looks fine to me but it is too late in the development cycle to include in Py2.3. Marking as a Py2.4 idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=747364&group_id=5470 From noreply@sourceforge.net Mon Jul 14 00:25:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 16:25:39 -0700 Subject: [Patches] [ python-Patches-767600 ] Add a 'isotime' format to standard logging Message-ID: Patches item #767600, was opened at 2003-07-08 08:04 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=767600&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: Add a 'isotime' format to standard logging Initial Comment: This patch adds a standard format string 'isotime' to go alongside 'asctime' in the standard logging module. The 'asctime' format is somewhat idiosyncratic (for instance the seconds,milliseconds part). 'isotime' produces UTC timestamps in ISO8601 format, that is %Y-%m-%dT%H:%M:%S.msecsZ e.g. 2003-07-08T18:02:34.012Z A good primer on ISO 8601 can be found at http://www.cl.cam.ac.uk/~mgk25/iso-time.html I'm not entirely sold on the name 'isotime' - an alternative would be 'stdtime'. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2003-07-13 23:25 Message: Logged In: YES user_id=308438 The current implementation is supposed to produce ISO8601 format by default, unless a specific date format is specified for the formatter. According to the above web page, the only way in which the current default format is non-standard is that no 'Z' is provided to indicate a UTC time; so I think the patch should not introduce a new 'stdtime' or 'isotime' format, but rather change the current formatting implementation so that the standard format is actually produced. Currently, the millisecond separator is a comma (like log4j); Markus Kuhn's above page indicates that either a comma or a period are acceptable for this. Of course, it may be that better support for standard date/time formats should not be implemented in logging, but in a general-purpose package which can be used not only by logging, but by other applications which need this functionality. Anthony, nice to see that you are taking another look at logging :-) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-08 08:35 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=767600&group_id=5470 From noreply@sourceforge.net Mon Jul 14 03:10:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 19:10:55 -0700 Subject: [Patches] [ python-Patches-747364 ] BaseHTTPServer doesn't need StringIO intermediary Message-ID: Patches item #747364, was opened at 2003-06-02 02:40 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=747364&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Andrew Dalke (dalke) >Assigned to: Raymond Hettinger (rhettinger) Summary: BaseHTTPServer doesn't need StringIO intermediary Initial Comment: This is Python2.3b1, from CVS I looked at the implementation of the BaseHTTPServer.py code where it does the actual parsing. I see that it has # Deal with pipelining bytes = "" while 1: line = self.rfile.readline() bytes = bytes + line if line == '\r\n' or line == '\n' or line == '': break # Examine the headers and look for a Connection directive hfile = cStringIO.StringIO(bytes) self.headers = self.MessageClass(hfile) The MessageClass is mimetools.Message, which uses rfc822.Message to parse the headers. The Message reads the input stream up to and including the end-of-header blank line, but no further, using while 1: ... line = self.fp.readline() ... elif self.islast(line): # Note! No pushback here! The delimiter line gets eaten break def islast(self, line): """Determine whether a line is a legal end of RFC 2822 headers. and checks for '\r\n' or '\n' so it seems the temporary copy into a StringIO isn't needed since the Message can deal with it correctly. Plus, Message takes a 'seekable' parameter which can turn off seeking on the input stream, and has for a long time (since well before Martin's "Deal with pipelining code"). The proof, as they say, is in the pudding. Thought I don't know why. Anyway, I replaced the "bytes ... " code and used self.rfile rather than the temporary StringIO hfile, as in self.headers = self.MessageClass(self.rfile) print "Does it work?", repr(self.rfile.readline()) (I added the print to make sure the data wasn't eaten) I tested it with the module's mainline self-test, and it seems to work just fine. Attached patch does the same, only without the debugging print statement. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-13 21:10 Message: Logged In: YES user_id=80475 Okay, will post patch after Py2.3 goes out. ---------------------------------------------------------------------- Comment By: Chris Lawrence (lordsutch) Date: 2003-07-13 17:17 Message: Logged In: YES user_id=6757 I honestly don't remember why I used the StringIO wrapper. It could have been that the seekable parameter was undocumented at the time, or added while I was evolving the patch locally, so I wasn't aware of it. (I'd probably change the parameter to False, since this is a 2.3+ patch, but that's a cosmetic issue.) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-13 05:06 Message: Logged In: YES user_id=21627 I agree this is a reasonable change, and I also agree that it comes too late for 2.3. I don't know what Chris Lawrence' rationale was to wrap the header in a StringIO; I'll ask him. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-12 20:05 Message: Logged In: YES user_id=80475 Martin, you added this code last year (ver 1.19) in response to www.python.org/sf/430706 . Was the += build from readline and the trip through CStringIO necessary? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-01 00:27 Message: Logged In: YES user_id=80475 "the proof is in the pudding" lost its clarity when it got shortened from "the proof of the pudding is in the eating" meaning that recipes are best judged by their results. The patch looks fine to me but it is too late in the development cycle to include in Py2.3. Marking as a Py2.4 idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=747364&group_id=5470 From noreply@sourceforge.net Mon Jul 14 08:18:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 00:18:18 -0700 Subject: [Patches] [ python-Patches-770521 ] make itertools type declarations static Message-ID: Patches item #770521, was opened at 2003-07-13 08:57 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=770521&group_id=5470 Category: Modules Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 3 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Andrew I MacIntyre (aimacintyre) Summary: make itertools type declarations static Initial Comment: the intertools module defines a number of type structures, which are not declared static. these structures don't need to be symbolically visible outside the module, and I think would be better declared static to reduce namespace pollution. this became noticeable as I was building itertools in an external module on OS/2, where these type symbols were not exported from the external module (DLL) with no problem. I changed to building itertools into the core DLL, and my DLL export machinery started to export these type symbols. I've changed the core DLL export definition machinery to deal with this, so this is a low priority "cleanup" issue in my view. Assigned to Raymond, as itertools is his baby. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-14 02:18 Message: Logged In: YES user_id=80475 See Modules/itertoolsmodule.c 1.18 Thanks for the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=770521&group_id=5470 From noreply@sourceforge.net Mon Jul 14 08:40:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 00:40:54 -0700 Subject: [Patches] [ python-Patches-675864 ] patch for new func. string.findall Message-ID: Patches item #675864, was opened at 2003-01-27 21:00 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675864&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Hunter Peress (hfastedge) Assigned to: Nobody/Anonymous (nobody) Summary: patch for new func. string.findall Initial Comment: this finds all indices of a substring in a string returning in list form. Its not in pydoc2.3. This "patch" contains unittests. #!/usr/bin/python import string def findall(sub,s): if s =='' or sub =='': return [] ret=[] findval=0 pos=0 while findval != -1: findval = s.find(sub,pos) if findval != -1: ret.append(findval) pos = findval + len(sub) return ret if __name__ == '__main__': units = [ 'asdsad','l', 'l','asdlsds', 'l','lsdlsds', 'l','lsdsds', 'l','sdsds', 'l','sdsdsl', 'l','lsdsdsl', 'l','lsdlsdsl', 'l','l', 'l','ll', 'l','lll', 'lo','llollol', 'lo','llollolo', '','', '','asdasd', 'asdsad','' ] for i in range(0,len(units),2): sub,s = units[i],units[i+1] print "'%s' in '%s':"%(sub,s) print findall(sub,s) print "-"*30 print 'done' ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-14 02:40 Message: Logged In: YES user_id=80475 This function (aspiring method) does not have a strong enough use case to warrant fattening the API for str, unicode, UserString, etc. Am closing this one. But do keep submitting ideas to improve the language. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-28 19:59 Message: Logged In: YES user_id=357491 The string module is deprecated so adding anything to the module is a big no-no. If you still want to see this functionality it will require being added to the string type. I am also changing this to a patch since it has working code (albeit as-is it would be rejected). ---------------------------------------------------------------------- Comment By: Hunter Peress (hfastedge) Date: 2003-01-31 04:31 Message: Logged In: YES user_id=479934 Theres now a indented version of that which was pasted above that is attached to this bug. ---------------------------------------------------------------------- Comment By: Hunter Peress (hfastedge) Date: 2003-01-27 21:01 Message: Logged In: YES user_id=479934 This might be done as an iterator as well, as re.findall also is complemented by an re.finditer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675864&group_id=5470 From noreply@sourceforge.net Mon Jul 14 08:43:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 00:43:53 -0700 Subject: [Patches] [ python-Patches-562501 ] Add isxxx() methods to string objects Message-ID: Patches item #562501, was opened at 2002-05-30 13:00 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=562501&group_id=5470 Category: Core (C code) >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: Add isxxx() methods to string objects Initial Comment: Here's the patch for the isxxx methods. If it's up to spec, let me know and I'll add documentation and expand the unittests. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-20 17:20 Message: Logged In: YES user_id=38388 I'd suggest to start with the standard ASCII characters for the methods you are suggesting to add and then complete the sets using the various categories listed on http://www.unicode.org/Public/UNIDATA/UnicodeData.html e.g. punctation (P*) is a general category in the Unicode database, control too (Cc). Visibility and printability depend on available fonts, so I'm not sure what to do about these. Hex chars are the same as for 8-bit strings. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-20 16:12 Message: Logged In: YES user_id=80475 This one is taking a while because I'm not entirely clear on the inclusion/exclusion criteria for classifying Unicode characters for the various isxxx methods. I'm spending some time with the big Unicode 3.0 book and will post a patch when I know how to proceed. If any one already has a clear sense of direction, I'm all ears. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 16:46 Message: Logged In: YES user_id=21627 Raymond, any news on this? I like the idea. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-06-30 14:58 Message: Logged In: YES user_id=80475 Unassigning this because I'm away for five weeks. The equivalent Unicode operations are not as clearly defined as they are for Ascii. Was researching what is done in other programming languages. Also, there was a py-dev discussion that suggested that the function names be changed to something more clear than their names in C. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-30 13:41 Message: Logged In: YES user_id=6380 Thanks! But what about adding the same methods to Unicode objects? I think that's the point of using methods -- supporting the same operations for both string types. Also, Paul Prescod wanted ishexdigit instead of isxdigit. Not sure if I agree. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=562501&group_id=5470 From noreply@sourceforge.net Mon Jul 14 08:49:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 00:49:43 -0700 Subject: [Patches] [ python-Patches-543867 ] test for patch #543865 & others Message-ID: Patches item #543867, was opened at 2002-04-14 17:18 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=543867&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hernan Martinez Foffani (hfoffani) >Assigned to: Walter Dörwald (doerwalter) Summary: test for patch #543865 & others Initial Comment: Here are 3 patches for: - test_complex.py: . add several checks to force execution of unvisited parts of complexobject.c code. . add a test for complex floor division corresponding bug #543387 and fix #543865 - test_complex_future.py . add test for "future" true division. (actually this is not a patch but the hole file) - test_b1.py . add test for bug #543840 and it's fix at patch #543865 Regards, -Hernan ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-14 02:49 Message: Logged In: YES user_id=80475 Walter, do you care to add these in unittest form? Also, since the tests are to validate bug fixes, they are appropriate to go into Py2.3. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-06 14:58 Message: Logged In: YES user_id=357491 The patch is now severely outdated since test_complex.py has been converted to PyUnit, but it might be pertinent to go through the patch and see if any tests are there that could be added. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-22 13:38 Message: Logged In: YES user_id=112690 Regarding "the error msg for complex pow says "remainder"; it shouldn't" you are correct, the exception string has a bad wording. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-22 13:31 Message: Logged In: YES user_id=112690 On: vereq(a ** 105, a ** 105) ... etc ... The c code in complexobject.c has special cases when the exponent is > 100, < than -100, and in-between. I didn't want to test for equality with constants to avoid messing up with floating point issues. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-04-22 13:21 Message: Logged In: YES user_id=31435 I'm not sure what lines like vereq(a ** 105, a ** 105) vereq(b ** -105, b ** -105) vereq(b ** -30, b ** -30) are trying to test. That we get the same answer when we do exactly the same thing twice? Note that complex % has been deprecated: no point adding a test for a deprecated feature. The error msg for complex pow says "remainder"; it shouldn't. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-22 13:09 Message: Logged In: YES user_id=6380 OK, I've deleted them for you. Who do you expect to review this? ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-22 13:02 Message: Logged In: YES user_id=112690 Yes to both questions. I'm withdrawing test_complex.py and test_b1.py. I can't delete them and I double checked that I were correctly logged in as hfoffani. SourceForge error: File Delete: ArtifactFile: Permission Denied ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-22 12:51 Message: Logged In: YES user_id=6380 I don't understand your comment. Are you withdrawing the files test_complex.py and test_b1.py? Have you uploaded these to separate patch issues? You should be able to delete them as the original submitter; ifthis doesn't work, let me know and I'll do it. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-14 18:48 Message: Logged In: YES user_id=112690 Following Tim's advise to group together bug/fix/test, I'll leave this patch entry for improvements in the tests of complex numbers. Then the valid files are: 21173: test_complex_future.py and 21180: test_complex.diff3 ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-14 18:47 Message: Logged In: YES user_id=112690 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=543867&group_id=5470 From noreply@sourceforge.net Mon Jul 14 09:53:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 01:53:50 -0700 Subject: [Patches] [ python-Patches-543867 ] test for patch #543865 & others Message-ID: Patches item #543867, was opened at 2002-04-15 00:18 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=543867&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hernan Martinez Foffani (hfoffani) Assigned to: Walter Dörwald (doerwalter) Summary: test for patch #543865 & others Initial Comment: Here are 3 patches for: - test_complex.py: . add several checks to force execution of unvisited parts of complexobject.c code. . add a test for complex floor division corresponding bug #543387 and fix #543865 - test_complex_future.py . add test for "future" true division. (actually this is not a patch but the hole file) - test_b1.py . add test for bug #543840 and it's fix at patch #543865 Regards, -Hernan ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-07-14 10:53 Message: Logged In: YES user_id=89016 OK, I'll see if I can look at the patches later today. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-14 09:49 Message: Logged In: YES user_id=80475 Walter, do you care to add these in unittest form? Also, since the tests are to validate bug fixes, they are appropriate to go into Py2.3. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-06 21:58 Message: Logged In: YES user_id=357491 The patch is now severely outdated since test_complex.py has been converted to PyUnit, but it might be pertinent to go through the patch and see if any tests are there that could be added. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-22 20:38 Message: Logged In: YES user_id=112690 Regarding "the error msg for complex pow says "remainder"; it shouldn't" you are correct, the exception string has a bad wording. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-22 20:31 Message: Logged In: YES user_id=112690 On: vereq(a ** 105, a ** 105) ... etc ... The c code in complexobject.c has special cases when the exponent is > 100, < than -100, and in-between. I didn't want to test for equality with constants to avoid messing up with floating point issues. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-04-22 20:21 Message: Logged In: YES user_id=31435 I'm not sure what lines like vereq(a ** 105, a ** 105) vereq(b ** -105, b ** -105) vereq(b ** -30, b ** -30) are trying to test. That we get the same answer when we do exactly the same thing twice? Note that complex % has been deprecated: no point adding a test for a deprecated feature. The error msg for complex pow says "remainder"; it shouldn't. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-22 20:09 Message: Logged In: YES user_id=6380 OK, I've deleted them for you. Who do you expect to review this? ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-22 20:02 Message: Logged In: YES user_id=112690 Yes to both questions. I'm withdrawing test_complex.py and test_b1.py. I can't delete them and I double checked that I were correctly logged in as hfoffani. SourceForge error: File Delete: ArtifactFile: Permission Denied ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-22 19:51 Message: Logged In: YES user_id=6380 I don't understand your comment. Are you withdrawing the files test_complex.py and test_b1.py? Have you uploaded these to separate patch issues? You should be able to delete them as the original submitter; ifthis doesn't work, let me know and I'll do it. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-15 01:48 Message: Logged In: YES user_id=112690 Following Tim's advise to group together bug/fix/test, I'll leave this patch entry for improvements in the tests of complex numbers. Then the valid files are: 21173: test_complex_future.py and 21180: test_complex.diff3 ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-15 01:47 Message: Logged In: YES user_id=112690 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=543867&group_id=5470 From noreply@sourceforge.net Mon Jul 14 17:11:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 09:11:03 -0700 Subject: [Patches] [ python-Patches-770280 ] PyMarshal_ReadLastObjectFromFile Message-ID: Patches item #770280, was opened at 2003-07-12 16:42 Message generated for change (Comment added) made by paulfelix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=770280&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Felix (paulfelix) Assigned to: Nobody/Anonymous (nobody) Summary: PyMarshal_ReadLastObjectFromFile Initial Comment: This is a new implementation of the performance boost in PyMarshal_ReadLastObjectFromFile where the pyc file data is loaded into memory before parsing. The original logic is as follows: - Get the file size. - If the file size is 16K or less, allocate a 16k char buffer on the call stack and load the file data into the buffer. - Otherwise, if file size is 256k or less, malloc a temp char buffer from the heap and load the file data into the buffer. - Otherwise, don't use a buffer. Allocating 16k on the call stack can cause a stack overflow when doing nested imports in a secondary thread. The default thread stack size on some systems is quite small (64k on HP-UX!). Also, allocating/freeing memory on the heap for this purpose may not be warranted. This patch proposes a new implentation that allocates a static 256k char buffer and uses a thread lock to keep it thread-safe. The lock/unlock function logic was taken from import.c. Note: performance tests show an improvment on some platforms when the static char buffer is defined at the file level instead of inside the function. ---------------------------------------------------------------------- >Comment By: Paul Felix (paulfelix) Date: 2003-07-14 12:11 Message: Logged In: YES user_id=819103 Adding 256k to the core footprint is probably not acceptable either. How about 16k? Patch 2 is a compromise that uses the original logic, but allocates the 16k buffer from static memory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=770280&group_id=5470 From noreply@sourceforge.net Mon Jul 14 21:02:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 13:02:41 -0700 Subject: [Patches] [ python-Patches-708374 ] add offset to mmap Message-ID: Patches item #708374, was opened at 2003-03-23 09:33 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: add offset to mmap Initial Comment: This patch is from Yotam Medini sent to me in mail. It adds support for the offset parameter to mmap. It ignores the check for mmap size "if the file is character device. Some device drivers (which I happen to use) have zero size in fstat buffer, but still one can seek() read() and tell()." I added minimal doc and tests. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-07-14 16:02 Message: Logged In: YES user_id=11375 According to my reading of the Single Unix Specification page for sys/stat.h, st_size only has a sensible value for regular files and for symlinks. This implies that the size comparison should only be done if S_ISREG() returns true. Patch attached as mmap_reg.diff; I'll also check it in after running the tests. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-07-11 09:54 Message: Logged In: YES user_id=11375 There's nothing to test on Windows; the HAVE_FSTAT code is inside #ifdef UNIX. If it works on Unix (and it seems to for me, on Linux), then it should be checked in. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-26 23:19 Message: Logged In: YES user_id=33168 Yes, the check for block devices should go in now as a bug fix I think. Can anyone test on windows? I attached a patch for just this minimal change. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-06-26 13:05 Message: Logged In: YES user_id=11375 Shouldn't block devices also be excluded from the size check? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-05 10:59 Message: Logged In: YES user_id=33168 Since this is an enhancement, it will not go into 2.2.x. The patch is stuck right now. It needs to be tested on Windows, but I can't do that (no Windows development environment). If you can update the patch to work on both Unix and Windows, we can apply the patch. ---------------------------------------------------------------------- Comment By: Yotam Medini (yotam) Date: 2003-06-05 10:55 Message: Logged In: YES user_id=22624 Just wondering, what is the status of this patch. I guess it did not make it to 2.2.3. regards -- yotam ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-22 23:53 Message: Logged In: YES user_id=80475 This is much closer and solves the last problem. But, it fails test_mmap with a windows errocode 8: not enought memory. Raymond ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 14:20 Message: Logged In: YES user_id=33168 http://msdn.microsoft.com/library/en-us/fileio/base/mapviewoffile.asp?frame=true says the offset must be a multiple of the allocation granularity which used to be hard-coded at 64k. So maybe if we made the offset 64k it would work. The attached patch makes this test change for windows only. (I think the Unix offset must be a multiple of PAGESIZE.) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 13:53 Message: Logged In: YES user_id=80475 I had posted the wrong traceback (before the rebuild). The correct one shows Window Error #87. Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) WindowsError: [Errno 87] The parameter is incorrect [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 13:14 Message: Logged In: YES user_id=33168 Note to self: Self, make sure to backport S_ISCHR() fix. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 13:10 Message: Logged In: YES user_id=33168 Hmmm, did Modules/mmapmodule.c get rebuilt? There is code in the patch for new_mmap_object() to support the offset keyword in both Unix & Windows. I don't see a problem in the code/patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 12:01 Message: Logged In: YES user_id=80475 It doesn't run: C:\py23\Lib\test>python_d test_mmap.py Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) TypeError: 'offset' is an invalid keyword argument for this function [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-09 19:35 Message: Logged In: YES user_id=33168 Raymond, could you try to test this patch and see if it works on Windows? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-29 16:28 Message: Logged In: YES user_id=33168 Sounds fair. Attached is an updated patch which includes windows support (I think). I cannot test on Windows. Tested on Linux. Includes updates for doc, src, and test. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-27 19:12 Message: Logged In: YES user_id=21627 I think non-zero offsets need to be supported for Windows as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-23 10:37 Message: Logged In: YES user_id=33168 Email received from Yotam: I have downloaded and patched the 2.3a source. compiled locally just this module, and it worked fine for my application (with offset for character device file) I did not run the released test though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 From noreply@sourceforge.net Mon Jul 14 22:08:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 14:08:09 -0700 Subject: [Patches] [ python-Patches-543867 ] test for patch #543865 & others Message-ID: Patches item #543867, was opened at 2002-04-15 00:18 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=543867&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hernan Martinez Foffani (hfoffani) Assigned to: Walter Dörwald (doerwalter) Summary: test for patch #543865 & others Initial Comment: Here are 3 patches for: - test_complex.py: . add several checks to force execution of unvisited parts of complexobject.c code. . add a test for complex floor division corresponding bug #543387 and fix #543865 - test_complex_future.py . add test for "future" true division. (actually this is not a patch but the hole file) - test_b1.py . add test for bug #543840 and it's fix at patch #543865 Regards, -Hernan ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-07-14 23:08 Message: Logged In: YES user_id=89016 Reworking test_complex.py.diff3 into the attached diff3.txt I don't see any increase in code coverage for complexobject.c (it stays at 91.84%) except for the file writing test which brings the coverage up to 92.95%. The current tests in test_complex.py seem to cover most test cases from test_complex.py.diff3 (except that test_complex.py.diff3 uses ** and % and the current test_complex.py uses pow and __mod__). So I'd say we add the file writing test and drop the rest. I'll look at test_complex_future.py tomorrow. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-07-14 10:53 Message: Logged In: YES user_id=89016 OK, I'll see if I can look at the patches later today. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-14 09:49 Message: Logged In: YES user_id=80475 Walter, do you care to add these in unittest form? Also, since the tests are to validate bug fixes, they are appropriate to go into Py2.3. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-06 21:58 Message: Logged In: YES user_id=357491 The patch is now severely outdated since test_complex.py has been converted to PyUnit, but it might be pertinent to go through the patch and see if any tests are there that could be added. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-22 20:38 Message: Logged In: YES user_id=112690 Regarding "the error msg for complex pow says "remainder"; it shouldn't" you are correct, the exception string has a bad wording. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-22 20:31 Message: Logged In: YES user_id=112690 On: vereq(a ** 105, a ** 105) ... etc ... The c code in complexobject.c has special cases when the exponent is > 100, < than -100, and in-between. I didn't want to test for equality with constants to avoid messing up with floating point issues. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-04-22 20:21 Message: Logged In: YES user_id=31435 I'm not sure what lines like vereq(a ** 105, a ** 105) vereq(b ** -105, b ** -105) vereq(b ** -30, b ** -30) are trying to test. That we get the same answer when we do exactly the same thing twice? Note that complex % has been deprecated: no point adding a test for a deprecated feature. The error msg for complex pow says "remainder"; it shouldn't. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-22 20:09 Message: Logged In: YES user_id=6380 OK, I've deleted them for you. Who do you expect to review this? ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-22 20:02 Message: Logged In: YES user_id=112690 Yes to both questions. I'm withdrawing test_complex.py and test_b1.py. I can't delete them and I double checked that I were correctly logged in as hfoffani. SourceForge error: File Delete: ArtifactFile: Permission Denied ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-22 19:51 Message: Logged In: YES user_id=6380 I don't understand your comment. Are you withdrawing the files test_complex.py and test_b1.py? Have you uploaded these to separate patch issues? You should be able to delete them as the original submitter; ifthis doesn't work, let me know and I'll do it. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-15 01:48 Message: Logged In: YES user_id=112690 Following Tim's advise to group together bug/fix/test, I'll leave this patch entry for improvements in the tests of complex numbers. Then the valid files are: 21173: test_complex_future.py and 21180: test_complex.diff3 ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-15 01:47 Message: Logged In: YES user_id=112690 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=543867&group_id=5470 From noreply@sourceforge.net Tue Jul 15 03:37:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 19:37:52 -0700 Subject: [Patches] [ python-Patches-769142 ] CallTip trimming may loop forever. Message-ID: Patches item #769142, was opened at 2003-07-10 09:13 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=769142&group_id=5470 Category: IDLE Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 7 Submitted By: Scott David Daniels (scott_daniels) >Assigned to: Raymond Hettinger (rhettinger) Summary: CallTip trimming may loop forever. Initial Comment: (also applies to 2.2.x) While trying to understand someone else's half-developed code, I found an interesting problem in Idle. This bug is far nastier in 2.3 (which I was using at the time). testcase.py: def function(arg): ''' ''' return 1 In Idle if you type >>> import testcase >>> testcase.function( The code will loop trying to place a calltip in 2.3 (in 2.2.0, it raises an exception). After investigation, I found the following code: python/dist/src/Lib/idlelib/CallTips.py: ... while doc[:1] in " \t\n": doc = doc[1:] pos = doc.find("\n") ... With the new string semantics for 'in', this loop will be checking ('' in ' \t\n') (a bad state of affairs). The following patch should fix it: *** CallTips.py Thu Jun 26 01:16:56 2003 --- CallTips.py_old Tue Dec 31 07:59:14 2002 *************** *** 164,175 **** # See if we can use the docstring doc = getattr(ob, "__doc__", "") if doc: ! doc = doc.lstrip() pos = doc.find("\n") if pos < 0 or pos > 70: pos = 70 ! if argText and doc: argText += "\n" ! argText = (argText + doc[:pos]).rstrip() return argText --- 164,176 ---- # See if we can use the docstring doc = getattr(ob, "__doc__", "") if doc: ! while doc[:1] in " \t\n": ! doc = doc[1:] pos = doc.find("\n") if pos < 0 or pos > 70: pos = 70 ! if argText: argText += "\n" ! argText += doc[:pos] return argText Unit tests are tricky (since the 2.3 problem is an infinite loop): Attached is a test that won't get stuck in a loop. -Scott David Daniels Scott.Daniels@Acm.Org ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-13 05:27 Message: Logged In: YES user_id=80475 See Lib/idlelib/CallTips.py 1.10 Assigning to Kurt for backport. Good catch and nice patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=769142&group_id=5470 From noreply@sourceforge.net Tue Jul 15 07:16:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 23:16:58 -0700 Subject: [Patches] [ python-Patches-543867 ] test for patch #543865 & others Message-ID: Patches item #543867, was opened at 2002-04-14 17:18 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=543867&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hernan Martinez Foffani (hfoffani) Assigned to: Walter Dörwald (doerwalter) Summary: test for patch #543865 & others Initial Comment: Here are 3 patches for: - test_complex.py: . add several checks to force execution of unvisited parts of complexobject.c code. . add a test for complex floor division corresponding bug #543387 and fix #543865 - test_complex_future.py . add test for "future" true division. (actually this is not a patch but the hole file) - test_b1.py . add test for bug #543840 and it's fix at patch #543865 Regards, -Hernan ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-15 01:16 Message: Logged In: YES user_id=80475 diff3.txt looks good and runs fine on my machine. I'm surprised that it did not increase code coverage. The comparisons of a ** 105 to itself should be commented as a whitebox test of a special case code path. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-07-14 16:08 Message: Logged In: YES user_id=89016 Reworking test_complex.py.diff3 into the attached diff3.txt I don't see any increase in code coverage for complexobject.c (it stays at 91.84%) except for the file writing test which brings the coverage up to 92.95%. The current tests in test_complex.py seem to cover most test cases from test_complex.py.diff3 (except that test_complex.py.diff3 uses ** and % and the current test_complex.py uses pow and __mod__). So I'd say we add the file writing test and drop the rest. I'll look at test_complex_future.py tomorrow. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-07-14 03:53 Message: Logged In: YES user_id=89016 OK, I'll see if I can look at the patches later today. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-14 02:49 Message: Logged In: YES user_id=80475 Walter, do you care to add these in unittest form? Also, since the tests are to validate bug fixes, they are appropriate to go into Py2.3. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-06 14:58 Message: Logged In: YES user_id=357491 The patch is now severely outdated since test_complex.py has been converted to PyUnit, but it might be pertinent to go through the patch and see if any tests are there that could be added. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-22 13:38 Message: Logged In: YES user_id=112690 Regarding "the error msg for complex pow says "remainder"; it shouldn't" you are correct, the exception string has a bad wording. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-22 13:31 Message: Logged In: YES user_id=112690 On: vereq(a ** 105, a ** 105) ... etc ... The c code in complexobject.c has special cases when the exponent is > 100, < than -100, and in-between. I didn't want to test for equality with constants to avoid messing up with floating point issues. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-04-22 13:21 Message: Logged In: YES user_id=31435 I'm not sure what lines like vereq(a ** 105, a ** 105) vereq(b ** -105, b ** -105) vereq(b ** -30, b ** -30) are trying to test. That we get the same answer when we do exactly the same thing twice? Note that complex % has been deprecated: no point adding a test for a deprecated feature. The error msg for complex pow says "remainder"; it shouldn't. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-22 13:09 Message: Logged In: YES user_id=6380 OK, I've deleted them for you. Who do you expect to review this? ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-22 13:02 Message: Logged In: YES user_id=112690 Yes to both questions. I'm withdrawing test_complex.py and test_b1.py. I can't delete them and I double checked that I were correctly logged in as hfoffani. SourceForge error: File Delete: ArtifactFile: Permission Denied ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-22 12:51 Message: Logged In: YES user_id=6380 I don't understand your comment. Are you withdrawing the files test_complex.py and test_b1.py? Have you uploaded these to separate patch issues? You should be able to delete them as the original submitter; ifthis doesn't work, let me know and I'll do it. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-14 18:48 Message: Logged In: YES user_id=112690 Following Tim's advise to group together bug/fix/test, I'll leave this patch entry for improvements in the tests of complex numbers. Then the valid files are: 21173: test_complex_future.py and 21180: test_complex.diff3 ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-14 18:47 Message: Logged In: YES user_id=112690 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=543867&group_id=5470 From noreply@sourceforge.net Tue Jul 15 07:58:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 23:58:35 -0700 Subject: [Patches] [ python-Patches-543867 ] test for patch #543865 & others Message-ID: Patches item #543867, was opened at 2002-04-14 17:18 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=543867&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hernan Martinez Foffani (hfoffani) Assigned to: Walter Dörwald (doerwalter) Summary: test for patch #543865 & others Initial Comment: Here are 3 patches for: - test_complex.py: . add several checks to force execution of unvisited parts of complexobject.c code. . add a test for complex floor division corresponding bug #543387 and fix #543865 - test_complex_future.py . add test for "future" true division. (actually this is not a patch but the hole file) - test_b1.py . add test for bug #543840 and it's fix at patch #543865 Regards, -Hernan ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-15 01:58 Message: Logged In: YES user_id=80475 Converted test_complex_future.py to unittest format. See attachment. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-15 01:16 Message: Logged In: YES user_id=80475 diff3.txt looks good and runs fine on my machine. I'm surprised that it did not increase code coverage. The comparisons of a ** 105 to itself should be commented as a whitebox test of a special case code path. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-07-14 16:08 Message: Logged In: YES user_id=89016 Reworking test_complex.py.diff3 into the attached diff3.txt I don't see any increase in code coverage for complexobject.c (it stays at 91.84%) except for the file writing test which brings the coverage up to 92.95%. The current tests in test_complex.py seem to cover most test cases from test_complex.py.diff3 (except that test_complex.py.diff3 uses ** and % and the current test_complex.py uses pow and __mod__). So I'd say we add the file writing test and drop the rest. I'll look at test_complex_future.py tomorrow. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-07-14 03:53 Message: Logged In: YES user_id=89016 OK, I'll see if I can look at the patches later today. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-14 02:49 Message: Logged In: YES user_id=80475 Walter, do you care to add these in unittest form? Also, since the tests are to validate bug fixes, they are appropriate to go into Py2.3. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-06 14:58 Message: Logged In: YES user_id=357491 The patch is now severely outdated since test_complex.py has been converted to PyUnit, but it might be pertinent to go through the patch and see if any tests are there that could be added. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-22 13:38 Message: Logged In: YES user_id=112690 Regarding "the error msg for complex pow says "remainder"; it shouldn't" you are correct, the exception string has a bad wording. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-22 13:31 Message: Logged In: YES user_id=112690 On: vereq(a ** 105, a ** 105) ... etc ... The c code in complexobject.c has special cases when the exponent is > 100, < than -100, and in-between. I didn't want to test for equality with constants to avoid messing up with floating point issues. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-04-22 13:21 Message: Logged In: YES user_id=31435 I'm not sure what lines like vereq(a ** 105, a ** 105) vereq(b ** -105, b ** -105) vereq(b ** -30, b ** -30) are trying to test. That we get the same answer when we do exactly the same thing twice? Note that complex % has been deprecated: no point adding a test for a deprecated feature. The error msg for complex pow says "remainder"; it shouldn't. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-22 13:09 Message: Logged In: YES user_id=6380 OK, I've deleted them for you. Who do you expect to review this? ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-22 13:02 Message: Logged In: YES user_id=112690 Yes to both questions. I'm withdrawing test_complex.py and test_b1.py. I can't delete them and I double checked that I were correctly logged in as hfoffani. SourceForge error: File Delete: ArtifactFile: Permission Denied ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-22 12:51 Message: Logged In: YES user_id=6380 I don't understand your comment. Are you withdrawing the files test_complex.py and test_b1.py? Have you uploaded these to separate patch issues? You should be able to delete them as the original submitter; ifthis doesn't work, let me know and I'll do it. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-14 18:48 Message: Logged In: YES user_id=112690 Following Tim's advise to group together bug/fix/test, I'll leave this patch entry for improvements in the tests of complex numbers. Then the valid files are: 21173: test_complex_future.py and 21180: test_complex.diff3 ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-14 18:47 Message: Logged In: YES user_id=112690 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=543867&group_id=5470 From noreply@sourceforge.net Tue Jul 15 14:07:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 15 Jul 2003 06:07:53 -0700 Subject: [Patches] [ python-Patches-708374 ] add offset to mmap Message-ID: Patches item #708374, was opened at 2003-03-23 09:33 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: add offset to mmap Initial Comment: This patch is from Yotam Medini sent to me in mail. It adds support for the offset parameter to mmap. It ignores the check for mmap size "if the file is character device. Some device drivers (which I happen to use) have zero size in fstat buffer, but still one can seek() read() and tell()." I added minimal doc and tests. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-07-15 09:07 Message: Logged In: YES user_id=11375 The device driver check is now committed to CVS, both the trunk and 2.2 maintenance branch. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-07-14 16:02 Message: Logged In: YES user_id=11375 According to my reading of the Single Unix Specification page for sys/stat.h, st_size only has a sensible value for regular files and for symlinks. This implies that the size comparison should only be done if S_ISREG() returns true. Patch attached as mmap_reg.diff; I'll also check it in after running the tests. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-07-11 09:54 Message: Logged In: YES user_id=11375 There's nothing to test on Windows; the HAVE_FSTAT code is inside #ifdef UNIX. If it works on Unix (and it seems to for me, on Linux), then it should be checked in. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-26 23:19 Message: Logged In: YES user_id=33168 Yes, the check for block devices should go in now as a bug fix I think. Can anyone test on windows? I attached a patch for just this minimal change. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-06-26 13:05 Message: Logged In: YES user_id=11375 Shouldn't block devices also be excluded from the size check? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-05 10:59 Message: Logged In: YES user_id=33168 Since this is an enhancement, it will not go into 2.2.x. The patch is stuck right now. It needs to be tested on Windows, but I can't do that (no Windows development environment). If you can update the patch to work on both Unix and Windows, we can apply the patch. ---------------------------------------------------------------------- Comment By: Yotam Medini (yotam) Date: 2003-06-05 10:55 Message: Logged In: YES user_id=22624 Just wondering, what is the status of this patch. I guess it did not make it to 2.2.3. regards -- yotam ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-22 23:53 Message: Logged In: YES user_id=80475 This is much closer and solves the last problem. But, it fails test_mmap with a windows errocode 8: not enought memory. Raymond ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 14:20 Message: Logged In: YES user_id=33168 http://msdn.microsoft.com/library/en-us/fileio/base/mapviewoffile.asp?frame=true says the offset must be a multiple of the allocation granularity which used to be hard-coded at 64k. So maybe if we made the offset 64k it would work. The attached patch makes this test change for windows only. (I think the Unix offset must be a multiple of PAGESIZE.) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 13:53 Message: Logged In: YES user_id=80475 I had posted the wrong traceback (before the rebuild). The correct one shows Window Error #87. Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) WindowsError: [Errno 87] The parameter is incorrect [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 13:14 Message: Logged In: YES user_id=33168 Note to self: Self, make sure to backport S_ISCHR() fix. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 13:10 Message: Logged In: YES user_id=33168 Hmmm, did Modules/mmapmodule.c get rebuilt? There is code in the patch for new_mmap_object() to support the offset keyword in both Unix & Windows. I don't see a problem in the code/patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 12:01 Message: Logged In: YES user_id=80475 It doesn't run: C:\py23\Lib\test>python_d test_mmap.py Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) TypeError: 'offset' is an invalid keyword argument for this function [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-09 19:35 Message: Logged In: YES user_id=33168 Raymond, could you try to test this patch and see if it works on Windows? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-29 16:28 Message: Logged In: YES user_id=33168 Sounds fair. Attached is an updated patch which includes windows support (I think). I cannot test on Windows. Tested on Linux. Includes updates for doc, src, and test. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-27 19:12 Message: Logged In: YES user_id=21627 I think non-zero offsets need to be supported for Windows as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-23 10:37 Message: Logged In: YES user_id=33168 Email received from Yotam: I have downloaded and patched the 2.3a source. compiled locally just this module, and it worked fine for my application (with offset for character device file) I did not run the released test though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 From noreply@sourceforge.net Tue Jul 15 15:17:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 15 Jul 2003 07:17:14 -0700 Subject: [Patches] [ python-Patches-674449 ] test_htmlparser -- more robust SCRIPT tag handling Message-ID: Patches item #674449, was opened at 2003-01-24 23:02 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=674449&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: j paulson (fantoozler) Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: test_htmlparser -- more robust SCRIPT tag handling Initial Comment: This test verifies that patch 670664 works ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=674449&group_id=5470 From noreply@sourceforge.net Tue Jul 15 15:17:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 15 Jul 2003 07:17:35 -0700 Subject: [Patches] [ python-Patches-670664 ] HTMLParser.py - more robust SCRIPT tag parsing Message-ID: Patches item #670664, was opened at 2003-01-19 09:07 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670664&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: j paulson (fantoozler) Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: HTMLParser.py - more robust SCRIPT tag parsing Initial Comment: http://www.ebay.com contains a script element of the form which is not enclosed in "" comments. The parser choked on that line, indicating it was a mal-formed end tag. The changes are: interesting_cdata is now a dict mapping start tag to an re matching the end tag, a "<--" or \Z HTMLParser.set_cdata_mode takes an extra argument, the start tag ---------------------------------------------------------------------- Comment By: j paulson (fantoozler) Date: 2003-01-28 17:35 Message: Logged In: YES user_id=690612 You will get a sequence of: handle_starttag("script") handle_comment("some-javascript-code") handle_endtag("script") whereas before the sequence was: handle_starttag("script") handle_data("") handle_endtag("script") ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-28 17:24 Message: Logged In: YES user_id=3066 >From python-dev: John Paulson wrote: > [...] A side-effect of this is that > any "" within a script/style will > be parsed as a comment. If that behavior is > incorrect, the regex can be modified. Jerry Williams wrote: Does this mean that the following won't work: That could be a problem, since this is commonly used to support browsers that don't understand