From lannert@uni-duesseldorf.de Tue Dec 5 02:10:50 2000 From: lannert@uni-duesseldorf.de (lannert@uni-duesseldorf.de) Date: Wed, 5 Apr 100 18:47:19 +0200 (MEST) Subject: [Patches] Proposed changes to netrc.py Message-ID: <20000405164719.30543.qmail@lannert.rz.uni-duesseldorf.de> --ELM954953239-23322-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit This is a -c diff (and the complete source, and the disclaimer) for the netrc.py module to make it work with macdefs. (See discussion on python-bugs list.) The original author, Eric S. Raymond, hasn't yet approved of this change. Detlef --ELM954953239-23322-0_ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: attachment; filename=netrc.diff Content-Description: /tmp/netrc.diff Content-Transfer-Encoding: 7bit *** /sw/lang/python/Python-1.6a1/Lib/netrc.py Fri Feb 4 16:10:33 2000 --- netrc.py Wed Apr 5 13:39:23 2000 *************** *** 1,68 **** """An object-oriented interface to .netrc files.""" # Module and documentation by Eric S. Raymond, 21 Dec 1998 import os, shlex class netrc: def __init__(self, file=None): if not file: file = os.path.join(os.environ['HOME'], ".netrc") ! try: ! fp = open(file) ! except: ! return None self.hosts = {} ! self.macros = {} lexer = shlex.shlex(fp) ! lexer.wordchars = lexer.wordchars + '.' while 1: ! # Look for a machine, default, or macdef top-level keyword ! toplevel = tt = lexer.get_token() ! if tt == '' or tt == None: break ! elif tt == 'machine': entryname = lexer.get_token() ! elif tt == 'default': entryname = 'default' ! elif tt == 'macdef': # Just skip to end of macdefs ! entryname = lexer.get_token() ! self.macros[entryname] = [] ! lexer.whitepace = ' \t' ! while 1: ! line = lexer.instream.readline() ! if not line or line == '\012' and tt == '\012': ! lexer.whitepace = ' \t\r\n' ! break ! tt = line ! self.macros[entryname].append(line) else: raise SyntaxError, "bad toplevel token %s, file %s, line %d" \ ! % (tt, file, lexer.lineno) # We're looking at start of an entry for a named machine or default. ! if toplevel == 'machine': ! login = account = password = None ! self.hosts[entryname] = {} while 1: ! tt = lexer.get_token() ! if tt=='' or tt == 'machine' or tt == 'default' or tt == 'macdef': ! if toplevel == 'macdef': ! break; ! elif login and password: self.hosts[entryname] = (login, account, password) ! lexer.push_token(tt) ! break ! else: ! raise SyntaxError, "malformed %s entry %s terminated by %s" % (toplevel, entryname, repr(tt)) ! elif tt == 'login' or tt == 'user': login = lexer.get_token() ! elif tt == 'account': account = lexer.get_token() ! elif tt == 'password': password = lexer.get_token() else: ! raise SyntaxError, "bad follower token %s, file %s, line %d"%(tt,file,lexer.lineno) def authenticators(self, host): """Return a (user, account, password) tuple for given host.""" --- 1,73 ---- """An object-oriented interface to .netrc files.""" # Module and documentation by Eric S. Raymond, 21 Dec 1998 + # Recklessly hacked and macdefs fixed by Detlef Lannert, 05 Apr 2000 import os, shlex + import string # not from Python 1.6 onwards class netrc: def __init__(self, file=None): if not file: file = os.path.join(os.environ['HOME'], ".netrc") ! fp = open(file) self.hosts = {} ! self.macros = {} # indexed by hostnames lexer = shlex.shlex(fp) ! lexer.wordchars = lexer.wordchars + '.-' while 1: ! # Look for a machine or default top-level keyword ! nexttoken = lexer.get_token() ! if nexttoken in ('', None): break ! elif nexttoken == 'machine': entryname = lexer.get_token() ! elif nexttoken == 'default': entryname = 'default' ! elif nexttoken == 'macdef': ! # this is a toplevel macdef; what the heck is it good for?? ! entryname = '' # put it into self.macros[''] ! lexer.push_token(nexttoken) else: raise SyntaxError, "bad toplevel token %s, file %s, line %d" \ ! % (nexttoken, file, lexer.lineno) # We're looking at start of an entry for a named machine or default. ! login = account = password = None ! macdefs = {} while 1: ! nexttoken = lexer.get_token() ! if nexttoken in ('machine', 'default', ''): ! if (login and not password) or (password and not login): ! # macdef-only entries are acceptable! ! raise SyntaxError( ! "incomplete %s entry terminated by %s" ! % (`entryname`, nexttoken or "EOF")) ! if login: self.hosts[entryname] = (login, account, password) ! if macdefs: ! self.macros[entryname] = macdefs ! lexer.push_token(nexttoken) ! break ! elif nexttoken in ('login', 'user'): login = lexer.get_token() ! elif nexttoken == 'account': account = lexer.get_token() ! elif nexttoken == 'password': password = lexer.get_token() + elif nexttoken == 'macdef': + macroname = lexer.get_token() + macro = [] + while 1: # macro continues until empty line + line = lexer.instream.readline() + if not line or line == "\n": + break + macro.append(line) + macdefs[macroname] = macro else: ! raise SyntaxError( ! "bad follower token %s, file %s, line %d" ! % (nexttoken, file, lexer.lineno)) def authenticators(self, host): """Return a (user, account, password) tuple for given host.""" *************** *** 72,94 **** return self.hosts['default'] else: return None ! def __repr__(self): """Dump the class data in the format of a .netrc file.""" ! rep = "" for host in self.hosts.keys(): ! attrs = self.hosts[host] ! rep = rep + "machine "+ host + "\n\tlogin " + repr(attrs[0]) + "\n" ! if attrs[1]: ! rep = rep + "account " + repr(attrs[1]) ! rep = rep + "\tpassword " + repr(attrs[2]) + "\n" ! for macro in self.macros.keys(): ! rep = rep + "macdef " + macro + "\n" ! for line in self.macros[macro]: ! rep = rep + line ! rep = rep + "\n" ! return rep ! if __name__ == '__main__': print netrc() - --- 77,121 ---- return self.hosts['default'] else: return None ! def __repr__(self): """Dump the class data in the format of a .netrc file.""" ! result = [] ! ! # First process the mysterious top-level macdef's: ! host = "" # dummy entry ! for macroname in self.macros.get(host, {}).keys(): ! result.append("\tmacdef %s\n" % macroname) ! result.extend(self.macros[host][macroname]) ! result.append("\n") ! ! # Now for the machines (and the optional default entry): for host in self.hosts.keys(): ! login, account, password = self.hosts[host] ! result.append("machine %s \n\tlogin %s\n" % (host, login)) ! if account: ! result.append("\taccount %s\n" % account) ! result.append("\tpassword %s\n" % password) ! for macroname in self.macros.get(host, {}).keys(): ! result.append("\tmacdef %s\n" % macroname) ! result.extend(self.macros[host][macroname]) ! result.append("\n") ! ! # That's it ... ! return string.join(result, "") ! #return "".join(result) # Python 1.6? ! ! def test(): ! import sys ! if len(sys.argv) > 1: ! file = sys.argv[1] ! else: ! file = "" ! n = netrc(file) ! print "hosts:", `n.hosts` ! print "macros:", `n.macros` ! print n ! if __name__ == '__main__': + #test() print netrc() --ELM954953239-23322-0_ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: attachment; filename=netrc.py Content-Description: /tmp/netrc.py Content-Transfer-Encoding: 7bit """An object-oriented interface to .netrc files.""" # Module and documentation by Eric S. Raymond, 21 Dec 1998 # Recklessly hacked and macdefs fixed by Detlef Lannert, 05 Apr 2000 import os, shlex import string # not from Python 1.6 onwards class netrc: def __init__(self, file=None): if not file: file = os.path.join(os.environ['HOME'], ".netrc") fp = open(file) self.hosts = {} self.macros = {} # indexed by hostnames lexer = shlex.shlex(fp) lexer.wordchars = lexer.wordchars + '.-' while 1: # Look for a machine or default top-level keyword nexttoken = lexer.get_token() if nexttoken in ('', None): break elif nexttoken == 'machine': entryname = lexer.get_token() elif nexttoken == 'default': entryname = 'default' elif nexttoken == 'macdef': # this is a toplevel macdef; what the heck is it good for?? entryname = '' # put it into self.macros[''] lexer.push_token(nexttoken) else: raise SyntaxError, "bad toplevel token %s, file %s, line %d" \ % (nexttoken, file, lexer.lineno) # We're looking at start of an entry for a named machine or default. login = account = password = None macdefs = {} while 1: nexttoken = lexer.get_token() if nexttoken in ('machine', 'default', ''): if (login and not password) or (password and not login): # macdef-only entries are acceptable! raise SyntaxError( "incomplete %s entry terminated by %s" % (`entryname`, nexttoken or "EOF")) if login: self.hosts[entryname] = (login, account, password) if macdefs: self.macros[entryname] = macdefs lexer.push_token(nexttoken) break elif nexttoken in ('login', 'user'): login = lexer.get_token() elif nexttoken == 'account': account = lexer.get_token() elif nexttoken == 'password': password = lexer.get_token() elif nexttoken == 'macdef': macroname = lexer.get_token() macro = [] while 1: # macro continues until empty line line = lexer.instream.readline() if not line or line == "\n": break macro.append(line) macdefs[macroname] = macro else: raise SyntaxError( "bad follower token %s, file %s, line %d" % (nexttoken, file, lexer.lineno)) def authenticators(self, host): """Return a (user, account, password) tuple for given host.""" if self.hosts.has_key(host): return self.hosts[host] elif self.hosts.has_key('default'): return self.hosts['default'] else: return None def __repr__(self): """Dump the class data in the format of a .netrc file.""" result = [] # First process the mysterious top-level macdef's: host = "" # dummy entry for macroname in self.macros.get(host, {}).keys(): result.append("\tmacdef %s\n" % macroname) result.extend(self.macros[host][macroname]) result.append("\n") # Now for the machines (and the optional default entry): for host in self.hosts.keys(): login, account, password = self.hosts[host] result.append("machine %s \n\tlogin %s\n" % (host, login)) if account: result.append("\taccount %s\n" % account) result.append("\tpassword %s\n" % password) for macroname in self.macros.get(host, {}).keys(): result.append("\tmacdef %s\n" % macroname) result.extend(self.macros[host][macroname]) result.append("\n") # That's it ... return string.join(result, "") #return "".join(result) # Python 1.6? def test(): import sys if len(sys.argv) > 1: file = sys.argv[1] else: file = "" n = netrc(file) print "hosts:", `n.hosts` print "macros:", `n.macros` print n if __name__ == '__main__': #test() print netrc() --ELM954953239-23322-0_ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: attachment; filename=disclaimer.txt Content-Description: /sw/lang/python/disclaimer.txt Content-Transfer-Encoding: 7bit I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. --ELM954953239-23322-0_-- From lannert@uni-duesseldorf.de Tue Dec 5 02:10:50 2000 From: lannert@uni-duesseldorf.de (lannert@uni-duesseldorf.de) Date: Wed, 5 Apr 100 19:07:55 +0200 (MEST) Subject: [Patches] fileinput.py argument handling (and suggestion) Message-ID: <20000405170755.30583.qmail@lannert.rz.uni-duesseldorf.de> --ELM954954475-23322-1_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit The test driver for fileinput.py (I'm referring to the 1.6a1) evaluates some optional options (?!) but doesn't remove them from the argv array. The module then tries to open any file names given on the command line and chokes at the option switches. While I am at it ;-), may I suggest an additional parameter for the input function and for the FileInput constructor that chomps off the trailing newline (as P**l folks would call it). A loop like for line in fileinput.input('-', chop=1): process(line) ... would supply the input lines without '\n' (EOF is signalled by the loop termination anyway). Doing instead an unconditional process(line[:-1]) can fail if the last line in a file is not \n-terminated, and to always include if line[-1] == '\n': line = line[:-1] is just plain awkward. Well, this is only a suggestion ... [The diff is against 1.6a1.] Detlef --ELM954954475-23322-1_ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: attachment; filename=disclaimer.txt Content-Description: /sw/lang/python/disclaimer.txt Content-Transfer-Encoding: 7bit I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. --ELM954954475-23322-1_ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: attachment; filename=fileinput.diff Content-Description: /tmp/fileinput.diff Content-Transfer-Encoding: 7bit *** /sw/lang/python/Python-1.6a1/Lib/fileinput.py Mon Oct 18 23:41:43 1999 --- /tmp/fileinput.py Wed Apr 5 19:00:59 2000 *************** *** 77,87 **** _state = None ! def input(files=(), inplace=0, backup=""): global _state if _state and _state._file: raise RuntimeError, "input() already active" ! _state = FileInput(files, inplace, backup) return _state def close(): --- 77,87 ---- _state = None ! def input(files=(), inplace=0, backup="", chop=0): global _state if _state and _state._file: raise RuntimeError, "input() already active" ! _state = FileInput(files, inplace, backup, chop) return _state def close(): *************** *** 123,129 **** class FileInput: ! def __init__(self, files=(), inplace=0, backup=""): if type(files) == type(''): files = (files,) else: --- 123,129 ---- class FileInput: ! def __init__(self, files=(), inplace=0, backup="", chop=0): if type(files) == type(''): files = (files,) else: *************** *** 135,140 **** --- 135,141 ---- self._files = files self._inplace = inplace self._backup = backup + self._chop = chop self._savestdout = None self._output = None self._filename = None *************** *** 157,162 **** --- 158,165 ---- line = self.readline() if not line: raise IndexError, "end of input reached" + if self._chop and line[-1] == '\n': + line = line[:-1] return line def nextfile(self): *************** *** 252,264 **** import getopt inplace = 0 backup = 0 ! opts, args = getopt.getopt(sys.argv[1:], "ib:") for o, a in opts: if o == '-i': inplace = 1 if o == '-b': backup = a ! for line in input(args, inplace=inplace, backup=backup): ! if line[-1:] == '\n': line = line[:-1] ! if line[-1:] == '\r': line = line[:-1] print "%d: %s[%d]%s %s" % (lineno(), filename(), filelineno(), isfirstline() and "*" or "", line) print "%d: %s[%d]" % (lineno(), filename(), filelineno()) --- 255,275 ---- import getopt inplace = 0 backup = 0 ! chop = 0 ! repr_ = 0 ! opts, args = getopt.getopt(sys.argv[1:], "ib:cr") ! sys.argv = [sys.argv[0]] + args for o, a in opts: if o == '-i': inplace = 1 if o == '-b': backup = a ! if o == '-c': chop = 1 ! if o == '-r': repr_ = 1 ! for line in input(args, inplace=inplace, backup=backup, chop=chop): ! if repr_: ! line = `line` ! else: ! if line[-1:] == '\n': line = line[:-1] ! if line[-1:] == '\r': line = line[:-1] print "%d: %s[%d]%s %s" % (lineno(), filename(), filelineno(), isfirstline() and "*" or "", line) print "%d: %s[%d]" % (lineno(), filename(), filelineno()) --ELM954954475-23322-1_-- From prettylady@freemail.ru Tue Dec 5 02:10:50 2000 From: prettylady@freemail.ru (prettylady@freemail.ru) Date: Ñð, 14 èþí 2000 19:53:00 +0400 Subject: [Patches] Hi, its for you ! Message-ID: <07332810764701623@d203.p6.col.ru> Hi! We are Russian girls - Natali, Alla, Vika. We would like to correspond with you. Visit our site and see our photos. http://www.russiangirls.narod.ru/ With interest, Natali,Alla, Vika. P.S. (This is not spam. You can unsubscribe at any time by sending an email to prettylady@freemail.ru with the subject UNSUBSCRIBE.) From bogus@does.not.exist.com Tue Dec 5 02:10:50 2000 From: bogus@does.not.exist.com () Date: Tue Dec 5 02:12:19 2000 Subject: No subject From noreply@sourceforge.net Fri Dec 1 11:13:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 1 Dec 2000 03:13:23 -0800 Subject: [Patches] [Patch #102599] better errors for getsockaddrarg Message-ID: <200012011113.DAA13648@sf-web2.i.sourceforge.net> Patch #102599 has been updated. Project: python Category: Modules Status: Open Submitted by: mwh Assigned to : Nobody Summary: better errors for getsockaddrarg ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102599&group_id=5470 From noreply@sourceforge.net Fri Dec 1 11:18:14 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 1 Dec 2000 03:18:14 -0800 Subject: [Patches] [Patch #102599] better errors for getsockaddrarg Message-ID: <200012011118.DAA13741@sf-web2.i.sourceforge.net> Patch #102599 has been updated. Project: python Category: Modules Status: Open Submitted by: mwh Assigned to : Nobody Summary: better errors for getsockaddrarg Follow-Ups: Date: 2000-Dec-01 03:18 By: mwh Comment: This patch attempts to provide a better error message for >>> import socket >>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) >>> s.connect('localhost:234') Traceback (most recent call last): File "", line 1, in ? TypeError: 2-sequence, 13-sequence >>> It now goes: >>> import socket >>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) >>> s.connect('localhost:234') Traceback (most recent call last): File "", line 1, in ? TypeError: getsockaddrarg: AF_INET address must be tuple, not string ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102599&group_id=5470 From noreply@sourceforge.net Fri Dec 1 13:14:05 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 1 Dec 2000 05:14:05 -0800 Subject: [Patches] [Patch #102599] better errors for getsockaddrarg Message-ID: <200012011314.FAA21660@sf-web1.i.sourceforge.net> Patch #102599 has been updated. Project: python Category: Modules Status: Closed Submitted by: mwh Assigned to : Nobody Summary: better errors for getsockaddrarg Follow-Ups: Date: 2000-Dec-01 03:18 By: mwh Comment: This patch attempts to provide a better error message for >>> import socket >>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) >>> s.connect('localhost:234') Traceback (most recent call last): File "", line 1, in ? TypeError: 2-sequence, 13-sequence >>> It now goes: >>> import socket >>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) >>> s.connect('localhost:234') Traceback (most recent call last): File "", line 1, in ? TypeError: getsockaddrarg: AF_INET address must be tuple, not string ------------------------------------------------------- Date: 2000-Dec-01 05:14 By: gvanrossum Comment: Thanks, applied. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102599&group_id=5470 From noreply@sourceforge.net Fri Dec 1 23:26:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 1 Dec 2000 15:26:01 -0800 Subject: [Patches] [Patch #102588] PEP 229: Use Distutils to build Message-ID: <200012012326.PAA03116@sf-web1.i.sourceforge.net> Patch #102588 has been updated. Project: python Category: Build Status: Open Submitted by: akuchling Assigned to : Nobody Summary: PEP 229: Use Distutils to build Follow-Ups: Date: 2000-Nov-29 20:18 By: akuchling Comment: Not ready to be reviewed yet; I'm submitting this patch just to demonstrate some progress. This version of the patch just removes the use of makesetup in building the interpreter, and hard-codes the presence of strop, posix, and _sre. Still to be done: write the top-level setup.py, and handle a few tricky bits such as the signalmodule. ------------------------------------------------------- Date: 2000-Dec-01 15:26 By: gvanrossum Comment: Would you mind explaining what the patch does in the PEP? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102588&group_id=5470 From noreply@sourceforge.net Fri Dec 1 23:57:22 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 1 Dec 2000 15:57:22 -0800 Subject: [Patches] [Patch #102485] minidom.py: Check for legal children Message-ID: <200012012357.PAA07163@sf-web2.i.sourceforge.net> Patch #102485 has been updated. Project: python Category: XML Status: Open Submitted by: akuchling Assigned to : loewis Summary: minidom.py: Check for legal children Follow-Ups: Date: 2000-Nov-23 08:24 By: akuchling Comment: Revised version of patch; the first version was generated against a really old version of minidom.py. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102485&group_id=5470 From noreply@sourceforge.net Fri Dec 1 23:58:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 1 Dec 2000 15:58:00 -0800 Subject: [Patches] [Patch #102492] minidom/pulldom: remove nodes already in the tree Message-ID: <200012012358.PAA07170@sf-web2.i.sourceforge.net> Patch #102492 has been updated. Project: python Category: XML Status: Open Submitted by: akuchling Assigned to : loewis Summary: minidom/pulldom: remove nodes already in the tree Follow-Ups: Date: 2000-Nov-23 18:32 By: akuchling Comment: This patch attempts to fix bug #116677: "minidom:Node.appendChild() has wrong semantics". It changes the appendChild, insertBefore, etc. methods to remove the node being added if it's already in the tree. The patch also fixes some spots where the previousSibling/nextSibling pointers aren't being properly updated. Some changes to pulldom.py were required, and I'm unsure about them. Mostly they consist of using the published minidom interface instead of directly setting .parentNode. Judging by my debug printouts, pulldom ends up doing redundant work after this patch -- every node is added to the tree *twice*. However the resulting tree does seem to be correct. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102492&group_id=5470 From noreply@sourceforge.net Sat Dec 2 03:33:56 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 1 Dec 2000 19:33:56 -0800 Subject: [Patches] [Patch #102613] __findattr__() Message-ID: <200012020333.TAA28693@sf-web1.i.sourceforge.net> Patch #102613 has been updated. Project: python Category: core (C code) Status: Open Submitted by: bwarsaw Assigned to : Nobody Summary: __findattr__() ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102613&group_id=5470 From noreply@sourceforge.net Sat Dec 2 03:34:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 1 Dec 2000 19:34:35 -0800 Subject: [Patches] [Patch #102613] __findattr__() Message-ID: <200012020334.TAA28707@sf-web1.i.sourceforge.net> Patch #102613 has been updated. Project: python Category: core (C code) Status: Open Submitted by: bwarsaw Assigned to : Nobody Summary: __findattr__() Follow-Ups: Date: 2000-Dec-01 19:34 By: bwarsaw Comment: Implementation of __findattr__() extension, as per PEP 231. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102613&group_id=5470 From noreply@sourceforge.net Sun Dec 3 11:32:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 3 Dec 2000 03:32:18 -0800 Subject: [Patches] [Patch #102477] DOM enhancements Message-ID: <200012031132.DAA12489@sf-web3.vaspecialprojects.com> Patch #102477 has been updated. Project: python Category: XML Status: Open Submitted by: fdrake Assigned to : loewis Summary: DOM enhancements Follow-Ups: Date: 2000-Nov-22 13:39 By: fdrake Comment: This modifies PullDOM.__init__() to accept a Document object as a parameter, and changes PullDOM.startDocument() to use that object or create a one using minidom if necessary. This allows all existing client code to continue to work unchanged, while supporting use of alternate DOM implementations. ------------------------------------------------------- Date: 2000-Nov-22 22:24 By: fdrake Comment: Revised patch based on Greg Stein's note that the original would not create a new Document instance for each call to startDocument(); this version takes a document factory instead of a document object, and creates a new document with each call to startDocument(). ------------------------------------------------------- Date: 2000-Nov-27 13:38 By: gvanrossum Comment: Fred, please pick someone to review this and assign it to them. ------------------------------------------------------- Date: 2000-Nov-27 15:03 By: fdrake Comment: [Changed summary line to reflect updated patch. Assigning to Martin since he cares about this stuff. ;-) ] xml.dom.minidom changes: This improves the Node.normalize() method based on Martin's suggestions, but does not address all of his concerns (re-linking siblings in particular). Test suite is updated to test that empty Text nodes are removed. Minor improvement to an AttributeError that should not normally ever be seen by users. Adds minimal support for DocumentType and DOMImplementation. Partially fixes problem that documentElement was not properly supporting remove/replace; this should make it a little better, but sacrifices performance of using .documentElement to get it; the performance loss can be corrected by extending more methods in the Document class and removing the dynamic lookup of the documentElement attribute. xml.dom.pulldom changes: The PullDOM class now uses a DOMImplementation for the documentFactory object. It's not clear that the createDocument method is used correctly, but the DOM Level 2 documentation for DOMImplementation is seriously lacking. ------------------------------------------------------- Date: 2000-Nov-29 07:13 By: fdrake Comment: Uploading fixed patch, since something appearantly went wrong with the last upload. Removed attempted use of cStringIO; that doesn't work with Unicode that can't be encoded using the default encoding for strings (often 7-bit ASCII), so we always use the original StringIO module. ------------------------------------------------------- Date: 2000-Dec-03 03:32 By: loewis Comment: Comments in patch order: - AttributeError: Is it better style to write AttributeError(key)? - normalize: If the first text node is empty, I believe it won't be removed (unless the next node is also a text node) - Doctype.unlink is unnecessary; that is handled in Node (in general, each unlink should handle only the attributes introduced in this inheritance level) - hasFeature: I think we cannot claim conformance to "xml" yet; that would require CDATASection, Notation, Entity, EntityReference and ProcessingInstruction support. - Document: Shouldn't implementation point to the DOMImplementation instance that created the Document? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102477&group_id=5470 From noreply@sourceforge.net Sun Dec 3 11:37:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 3 Dec 2000 03:37:23 -0800 Subject: [Patches] [Patch #102485] minidom.py: Check for legal children Message-ID: <200012031137.DAA12549@sf-web3.vaspecialprojects.com> Patch #102485 has been updated. Project: python Category: XML Status: Open Submitted by: akuchling Assigned to : loewis Summary: minidom.py: Check for legal children Follow-Ups: Date: 2000-Nov-23 08:24 By: akuchling Comment: Revised version of patch; the first version was generated against a really old version of minidom.py. ------------------------------------------------------- Date: 2000-Dec-03 03:37 By: loewis Comment: I'd prefer to postpone this patch somewhat, until the official DOM exceptions are available in xml.dom, and then to raise those instead. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102485&group_id=5470 From noreply@sourceforge.net Sun Dec 3 11:42:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 3 Dec 2000 03:42:15 -0800 Subject: [Patches] [Patch #102492] minidom/pulldom: remove nodes already in the tree Message-ID: <200012031142.DAA13548@sf-web3.vaspecialprojects.com> Patch #102492 has been updated. Project: python Category: XML Status: Open Submitted by: akuchling Assigned to : loewis Summary: minidom/pulldom: remove nodes already in the tree Follow-Ups: Date: 2000-Nov-23 18:32 By: akuchling Comment: This patch attempts to fix bug #116677: "minidom:Node.appendChild() has wrong semantics". It changes the appendChild, insertBefore, etc. methods to remove the node being added if it's already in the tree. The patch also fixes some spots where the previousSibling/nextSibling pointers aren't being properly updated. Some changes to pulldom.py were required, and I'm unsure about them. Mostly they consist of using the published minidom interface instead of directly setting .parentNode. Judging by my debug printouts, pulldom ends up doing redundant work after this patch -- every node is added to the tree *twice*. However the resulting tree does seem to be correct. ------------------------------------------------------- Date: 2000-Dec-03 03:42 By: loewis Comment: I believe this patch defeats the purpose of pulldom. The intent is that processing SAX events does not create any hierarchy (and in particular no cyclic objects). Only when expandNode is called, a fully-connected hierarchy is created. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102492&group_id=5470 From noreply@sourceforge.net Sun Dec 3 11:45:42 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 3 Dec 2000 03:45:42 -0800 Subject: [Patches] [Patch #102626] Add a .first{key/item/value}() method to dictionaries Message-ID: <200012031145.DAA03459@sf-web2.i.sourceforge.net> Patch #102626 has been updated. Project: python Category: core (C code) Status: Open Submitted by: moshez Assigned to : Nobody Summary: Add a .first{key/item/value}() method to dictionaries ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102626&group_id=5470 From noreply@sourceforge.net Sun Dec 3 11:51:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 3 Dec 2000 03:51:07 -0800 Subject: [Patches] [Patch #102626] Add a .first{key/item/value}() method to dictionaries Message-ID: <200012031151.DAA03517@sf-web2.i.sourceforge.net> Patch #102626 has been updated. Project: python Category: core (C code) Status: Open Submitted by: moshez Assigned to : Nobody Summary: Add a .first{key/item/value}() method to dictionaries Follow-Ups: Date: 2000-Dec-03 03:51 By: moshez Comment: OK, this fixes some problem with the applied-and-retracted version of the methods: * It adds exception-information to the docos * It uses _SET_ITEM and not _SetItem for more efficiency. I will still build skewed dictionaries. Opinion: maybe it would do to rehash the dictionary when there are too few items too? Wouldn't that solve everything better then Tim's weird "let's keep a pointer into the dictionary" dict? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102626&group_id=5470 From noreply@sourceforge.net Sun Dec 3 12:43:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 3 Dec 2000 04:43:33 -0800 Subject: [Patches] [Patch #102627] A Set class which *can* use the .firstkey() patch Message-ID: <200012031243.EAA01519@sf-web1.i.sourceforge.net> Patch #102627 has been updated. Project: python Category: library Status: Open Submitted by: moshez Assigned to : Nobody Summary: A Set class which *can* use the .firstkey() patch ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102627&group_id=5470 From noreply@sourceforge.net Sun Dec 3 12:47:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 3 Dec 2000 04:47:46 -0800 Subject: [Patches] [Patch #102627] A Set class which *can* use the .firstkey() patch Message-ID: <200012031247.EAA02154@sf-web1.i.sourceforge.net> Patch #102627 has been updated. Project: python Category: library Status: Open Submitted by: moshez Assigned to : Nobody Summary: A Set class which *can* use the .firstkey() patch Follow-Ups: Date: 2000-Dec-03 04:47 By: moshez Comment: OK, this patch implements a Set class with an added advantage that on 102626-patched interpreter it has a method called .element() which returns some element of the set. Short summary: * supports boolean operators, substraction * supports iteration semi-efficiently * supports checking for containment semi-efficiently * supports auto-freezing when hash() is called, so can be used as key in dictionaries, and so, as an element in sets. Greg Wilson: see if this doesn't solve 95% of the problem you're trying to solve with the Set built-in type PEP. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102627&group_id=5470 From noreply@sourceforge.net Sun Dec 3 13:11:30 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 3 Dec 2000 05:11:30 -0800 Subject: [Patches] [Patch #102628] Fixing bug 124120 -- filecmp.dircmp gives an error Message-ID: <200012031311.FAA04220@sf-web1.i.sourceforge.net> Patch #102628 has been updated. Project: python Category: library Status: Open Submitted by: moshez Assigned to : Nobody Summary: Fixing bug 124120 -- filecmp.dircmp gives an error ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102628&group_id=5470 From noreply@sourceforge.net Sun Dec 3 13:13:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 3 Dec 2000 05:13:43 -0800 Subject: [Patches] [Patch #102628] Fixing bug 124120 -- filecmp.dircmp gives an error Message-ID: <200012031313.FAA04912@sf-web1.i.sourceforge.net> Patch #102628 has been updated. Project: python Category: library Status: Open Submitted by: moshez Assigned to : Nobody Summary: Fixing bug 124120 -- filecmp.dircmp gives an error Follow-Ups: Date: 2000-Dec-03 05:13 By: moshez Comment: This is a real brown paperbag -- me and Gordon didn't integrate that smoothly. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102628&group_id=5470 From noreply@sourceforge.net Sun Dec 3 14:13:22 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 3 Dec 2000 06:13:22 -0800 Subject: [Patches] [Patch #102628] Fixing bug 124120 -- filecmp.dircmp gives an error Message-ID: <200012031413.GAA05681@sf-web2.i.sourceforge.net> Patch #102628 has been updated. Project: python Category: library Status: Accepted Submitted by: moshez Assigned to : moshez Summary: Fixing bug 124120 -- filecmp.dircmp gives an error Follow-Ups: Date: 2000-Dec-03 05:13 By: moshez Comment: This is a real brown paperbag -- me and Gordon didn't integrate that smoothly. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102628&group_id=5470 From noreply@sourceforge.net Sun Dec 3 17:30:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 3 Dec 2000 09:30:59 -0800 Subject: [Patches] [Patch #102630] Don't raise TypeError from isinstance/issubclass Message-ID: <200012031730.JAA12153@sf-web2.i.sourceforge.net> Patch #102630 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nascheme Assigned to : Nobody Summary: Don't raise TypeError from isinstance/issubclass ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102630&group_id=5470 From noreply@sourceforge.net Sun Dec 3 17:52:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 3 Dec 2000 09:52:31 -0800 Subject: [Patches] [Patch #102630] Don't raise TypeError from isinstance Message-ID: <200012031752.JAA12562@sf-web2.i.sourceforge.net> Patch #102630 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nascheme Assigned to : gvanrossum Summary: Don't raise TypeError from isinstance Follow-Ups: Date: 2000-Dec-03 09:52 By: nascheme Comment: Be more permissive about what types of arguments isinstance() takes. Clarify exception message. Fixes bug #124106. Assigned to Guido because he checked in the abstrace_issubclass code. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102630&group_id=5470 From noreply@sourceforge.net Sun Dec 3 18:31:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 3 Dec 2000 10:31:25 -0800 Subject: [Patches] [Patch #102364] Fix for119822: Allow Unicode in urllib Message-ID: <200012031831.KAA09101@sf-web1.i.sourceforge.net> Patch #102364 has been updated. Project: python Category: library Status: Closed Submitted by: loewis Assigned to : loewis Summary: Fix for119822: Allow Unicode in urllib Follow-Ups: Date: 2000-Nov-12 03:09 By: loewis Comment: This fixes the bug by explicitly converting Unicode strings to ASCII. I could find no indication in the RFCs that anything but ASCII is allowed in URLs. The size of the patch primarily originates from the renaming of the type local variable to urltype, so that the builtin type function is available. ------------------------------------------------------- Date: 2000-Nov-12 05:11 By: lemburg Comment: There are movements which want to add UTF-8 support to URLs. I don't know if there already are RTFs on this, but since even MS Explorer supports this, I guess the movement must be strong ;-) It does seem to be the natural coice and DNS is moving in that direction too. ------------------------------------------------------- Date: 2000-Nov-13 00:41 By: loewis Comment: Looking at http://www.ietf.org/ids.by.wg/idn.html, there is hardly any consensus on how to do internationalized domain names. As for Unicode in URLs, there is not even an Internet Draft proposing usage of UTF-8. So I'd propose to follow established standards, until drafts for new standards come available. ------------------------------------------------------- Date: 2000-Nov-13 11:55 By: gvanrossum Comment: Looks good. Suggestion: maybe another name than 'toASCII()', since this may change to something else later? How about to8bit()? ------------------------------------------------------- Date: 2000-Dec-03 10:31 By: loewis Comment: Committed as urllib.py 1.108. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102364&group_id=5470 From noreply@sourceforge.net Mon Dec 4 12:40:34 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 4 Dec 2000 04:40:34 -0800 Subject: [Patches] [Patch #102628] Fixing bug 124120 -- filecmp.dircmp gives an error Message-ID: <200012041240.EAA29543@sf-web2.i.sourceforge.net> Patch #102628 has been updated. Project: python Category: library Status: Closed Submitted by: moshez Assigned to : moshez Summary: Fixing bug 124120 -- filecmp.dircmp gives an error Follow-Ups: Date: 2000-Dec-03 05:13 By: moshez Comment: This is a real brown paperbag -- me and Gordon didn't integrate that smoothly. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102628&group_id=5470 From noreply@sourceforge.net Mon Dec 4 12:48:42 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 4 Dec 2000 04:48:42 -0800 Subject: [Patches] [Patch #102637] A patch for gdbmmodule.c Message-ID: <200012041248.EAA28423@sf-web1.i.sourceforge.net> Patch #102637 has been updated. Project: python Category: Modules Status: Open Submitted by: Nobody Assigned to : Nobody Summary: A patch for gdbmmodule.c ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102637&group_id=5470 From noreply@sourceforge.net Mon Dec 4 12:57:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 4 Dec 2000 04:57:12 -0800 Subject: [Patches] [Patch #102638] A patch for gdbmmodule.c, by Damjan Message-ID: <200012041257.EAA29529@sf-web1.i.sourceforge.net> Patch #102638 has been updated. Project: python Category: Modules Status: Open Submitted by: Nobody Assigned to : Nobody Summary: A patch for gdbmmodule.c, by Damjan ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102638&group_id=5470 From noreply@sourceforge.net Mon Dec 4 15:17:45 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 4 Dec 2000 07:17:45 -0800 Subject: [Patches] [Patch #102630] Don't raise TypeError from isinstance Message-ID: <200012041517.HAA07367@sf-web3.vaspecialprojects.com> Patch #102630 has been updated. Project: python Category: core (C code) Status: Accepted Submitted by: nascheme Assigned to : nascheme Summary: Don't raise TypeError from isinstance Follow-Ups: Date: 2000-Dec-03 09:52 By: nascheme Comment: Be more permissive about what types of arguments isinstance() takes. Clarify exception message. Fixes bug #124106. Assigned to Guido because he checked in the abstrace_issubclass code. ------------------------------------------------------- Date: 2000-Dec-04 07:17 By: gvanrossum Comment: OK, Neil, go ahead and check it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102630&group_id=5470 From noreply@sourceforge.net Mon Dec 4 15:48:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 4 Dec 2000 07:48:04 -0800 Subject: [Patches] [Patch #102630] Don't raise TypeError from isinstance Message-ID: <200012041548.HAA00909@sf-web2.i.sourceforge.net> Patch #102630 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: nascheme Assigned to : nascheme Summary: Don't raise TypeError from isinstance Follow-Ups: Date: 2000-Dec-03 09:52 By: nascheme Comment: Be more permissive about what types of arguments isinstance() takes. Clarify exception message. Fixes bug #124106. Assigned to Guido because he checked in the abstrace_issubclass code. ------------------------------------------------------- Date: 2000-Dec-04 07:17 By: gvanrossum Comment: OK, Neil, go ahead and check it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102630&group_id=5470 From noreply@sourceforge.net Tue Dec 5 02:35:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 4 Dec 2000 18:35:23 -0800 Subject: [Patches] [Patch #102652] Reference implementation for PEP 208 (coercion) Message-ID: <200012050235.SAA25357@sf-web3.vaspecialprojects.com> Patch #102652 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nascheme Assigned to : Nobody Summary: Reference implementation for PEP 208 (coercion) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102652&group_id=5470 From noreply@sourceforge.net Tue Dec 5 02:45:11 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 4 Dec 2000 18:45:11 -0800 Subject: [Patches] [Patch #102652] Reference implementation for PEP 208 (coercion) Message-ID: <200012050245.SAA26532@sf-web3.vaspecialprojects.com> Patch #102652 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nascheme Assigned to : Nobody Summary: Reference implementation for PEP 208 (coercion) Follow-Ups: Date: 2000-Dec-04 18:45 By: nascheme Comment: This patch is a little rough yet but I guess its better here than on my website. The major source of ugliness PyObject_Compare. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102652&group_id=5470 From WebMaster@worldclassalpacas.com Tue Dec 5 04:53:34 2000 From: WebMaster@worldclassalpacas.com (Dr Greg Nelson) Date: Tue, 05 Dec 2000 04:53:34 Subject: [Patches] World Class Alpaca Auction Message-ID: <200012051151.EAA06108@www.utahdawg.com> Dear Investors, Just a quick update to announce the opening of World Class Alpacas Auction Site! http://www.worldclassalpacas.com/cgibin/auction.cgi Our Alpaca Auction is up and running with some of the most beautiful animals in the world, and incredible investment opportunities. Check out the Huacaya Starter Herd, an excellent way to begin your investment. This particular starter herd has 3 pregnant females, 2 gelding for fiber, one standing herd sire and one male with herd sire potential. Check it out, this is an incredible value! Don't forget to bookmark the auction site, check back often and see what has been added. Sincerely, Dr. Gregory T. Nelson http://www.worldclassalpacas.com/ If you have any feedback please email the WebMaster If you wish to un subscribe at any time, please send a message to with remove in the subject. Thanks From noreply@sourceforge.net Tue Dec 5 21:15:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 5 Dec 2000 13:15:18 -0800 Subject: [Patches] [Patch #102665] Different credit text for jython Message-ID: <200012052115.NAA02220@sf-web2.i.sourceforge.net> Patch #102665 has been updated. Project: python Category: Modules Status: Open Submitted by: bckfnn Assigned to : Nobody Summary: Different credit text for jython ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102665&group_id=5470 From noreply@sourceforge.net Tue Dec 5 21:19:47 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 5 Dec 2000 13:19:47 -0800 Subject: [Patches] [Patch #102665] Different credit text for jython Message-ID: <200012052119.NAA02317@sf-web2.i.sourceforge.net> Patch #102665 has been updated. Project: python Category: Modules Status: Open Submitted by: bckfnn Assigned to : Nobody Summary: Different credit text for jython Follow-Ups: Date: 2000-Dec-05 13:19 By: bckfnn Comment: This patch will show a different credit text when the site.py is used with jython. An other fine solution could be to read the credit text from a file, similar to the LICENSE file. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102665&group_id=5470 From noreply@sourceforge.net Tue Dec 5 23:49:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 5 Dec 2000 15:49:33 -0800 Subject: [Patches] [Patch #102665] Different credit text for jython Message-ID: <200012052349.PAA25550@sf-web1.i.sourceforge.net> Patch #102665 has been updated. Project: python Category: Modules Status: Accepted Submitted by: bckfnn Assigned to : bwarsaw Summary: Different credit text for jython Follow-Ups: Date: 2000-Dec-05 13:19 By: bckfnn Comment: This patch will show a different credit text when the site.py is used with jython. An other fine solution could be to read the credit text from a file, similar to the LICENSE file. ------------------------------------------------------- Date: 2000-Dec-05 15:49 By: gvanrossum Comment: Barry, please check this in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102665&group_id=5470 From noreply@sourceforge.net Wed Dec 6 02:55:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 5 Dec 2000 18:55:12 -0800 Subject: [Patches] [Patch #102669] self of some string methods is incorrect type Message-ID: <200012060255.SAA27718@sf-web3.vaspecialprojects.com> Patch #102669 has been updated. Project: python Category: core (C code) Status: Open Submitted by: tokeneater Assigned to : Nobody Summary: self of some string methods is incorrect type ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102669&group_id=5470 From noreply@sourceforge.net Wed Dec 6 03:05:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 5 Dec 2000 19:05:52 -0800 Subject: [Patches] [Patch #102670] self of some string methods is incorrect type Message-ID: <200012060305.TAA27859@sf-web3.vaspecialprojects.com> Patch #102670 has been updated. Project: python Category: core (C code) Status: Open Submitted by: tokeneater Assigned to : Nobody Summary: self of some string methods is incorrect type ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102670&group_id=5470 From noreply@sourceforge.net Wed Dec 6 03:37:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 5 Dec 2000 19:37:54 -0800 Subject: [Patches] [Patch #102670] self of some string methods is incorrect type Message-ID: <200012060337.TAA05562@sf-web1.i.sourceforge.net> Patch #102670 has been updated. Project: python Category: core (C code) Status: Accepted Submitted by: tokeneater Assigned to : fdrake Summary: self of some string methods is incorrect type Follow-Ups: Date: 2000-Dec-05 19:37 By: gvanrossum Comment: Fred, please check this in. Tokeneater is Jeffery D. Collins; a cool pseudonym! :) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102670&group_id=5470 From noreply@sourceforge.net Wed Dec 6 09:22:17 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 01:22:17 -0800 Subject: [Patches] [Patch #102678] Let SocketServer reuse addresses Message-ID: <200012060922.BAA17884@sf-web2.i.sourceforge.net> Patch #102678 has been updated. Project: python Category: library Status: Open Submitted by: moshez Assigned to : Nobody Summary: Let SocketServer reuse addresses ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102678&group_id=5470 From noreply@sourceforge.net Wed Dec 6 09:24:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 01:24:18 -0800 Subject: [Patches] [Patch #102106] sys._getframe() for getting the current stack frame Message-ID: <200012060924.BAA18574@sf-web3.vaspecialprojects.com> Patch #102106 has been updated. Project: python Category: core (C code) Status: Open Submitted by: bwarsaw Assigned to : bwarsaw Summary: sys._getframe() for getting the current stack frame Follow-Ups: Date: 2000-Oct-24 20:43 By: bwarsaw Comment: This patch adds a function to the sys module which will return a frame object. By default, it returns the frame object of the current stack frame, but an optional integer argument can be supplied to retrieve any frame higher up the stack. If the integer is greater than the depth of the stack, a ValueError is raised. ------------------------------------------------------- Date: 2000-Oct-24 21:43 By: fdrake Comment: My only comment on the docs (both docstring and LaTeX) is that it should say "ValueError is raised" rather than "a ValueError is raised" (drop the "a"). Otherwise looks good; I've not run it through the formatting. ------------------------------------------------------- Date: 2000-Oct-24 21:51 By: bwarsaw Comment: Good point. Patch updated. Thanks. ------------------------------------------------------- Date: 2000-Oct-24 21:54 By: bwarsaw Comment: Oops, fixed one small typo. ------------------------------------------------------- Date: 2000-Oct-26 07:15 By: gvanrossum Comment: The docstring and docs should say that the default depth is zero. They should also mention that this is for internal use only. Can you implement this in Jython too? ------------------------------------------------------- Date: 2000-Dec-06 01:24 By: ping Comment: It's a small point, but i'd much prefer the function to be called sys.getframe() rather than sys._getframe(). There aren't any other functions in sys that begin with an underscore, and it's understood that routines in sys manipulate the Python interpreter system anyway (such as getrefcount or exc_info). This routine isn't private within sys; it's exported by sys, so it should be called sys.getframe(). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102106&group_id=5470 From noreply@sourceforge.net Wed Dec 6 09:24:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 01:24:50 -0800 Subject: [Patches] [Patch #102678] Let SocketServer reuse addresses Message-ID: <200012060924.BAA17937@sf-web2.i.sourceforge.net> Patch #102678 has been updated. Project: python Category: library Status: Open Submitted by: moshez Assigned to : Nobody Summary: Let SocketServer reuse addresses Follow-Ups: Date: 2000-Dec-06 01:24 By: moshez Comment: Following a discussion on #python, there was a consensus there that it's a pain SocketServer.py doesn't reuse addresses. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102678&group_id=5470 From noreply@sourceforge.net Wed Dec 6 09:25:39 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 01:25:39 -0800 Subject: [Patches] [Patch #102627] A Set class which *can* use the .firstkey() patch Message-ID: <200012060925.BAA17951@sf-web2.i.sourceforge.net> Patch #102627 has been updated. Project: python Category: core (C code) Status: Open Submitted by: moshez Assigned to : Nobody Summary: A Set class which *can* use the .firstkey() patch Follow-Ups: Date: 2000-Dec-03 04:47 By: moshez Comment: OK, this patch implements a Set class with an added advantage that on 102626-patched interpreter it has a method called .element() which returns some element of the set. Short summary: * supports boolean operators, substraction * supports iteration semi-efficiently * supports checking for containment semi-efficiently * supports auto-freezing when hash() is called, so can be used as key in dictionaries, and so, as an element in sets. Greg Wilson: see if this doesn't solve 95% of the problem you're trying to solve with the Set built-in type PEP. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102627&group_id=5470 From noreply@sourceforge.net Wed Dec 6 09:29:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 01:29:53 -0800 Subject: [Patches] [Patch #102679] linuxaudiodev: better format names (and error messages) Message-ID: <200012060929.BAA18643@sf-web3.vaspecialprojects.com> Patch #102679 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : Nobody Summary: linuxaudiodev: better format names (and error messages) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102679&group_id=5470 From noreply@sourceforge.net Wed Dec 6 09:34:32 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 01:34:32 -0800 Subject: [Patches] [Patch #102679] linuxaudiodev: better format names (and error messages) Message-ID: <200012060934.BAA18726@sf-web3.vaspecialprojects.com> Patch #102679 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : Nobody Summary: linuxaudiodev: better format names (and error messages) Follow-Ups: Date: 2000-Dec-06 01:34 By: ping Comment: I know a lot more work needs to be done on linuxaudiodev to make it work properly, but for now i wanted to make the existing module a little cleaner. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102679&group_id=5470 From noreply@sourceforge.net Wed Dec 6 09:36:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 01:36:29 -0800 Subject: [Patches] [Patch #102679] linuxaudiodev: better format names (and error messages) Message-ID: <200012060936.BAA18767@sf-web3.vaspecialprojects.com> Patch #102679 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : Nobody Summary: linuxaudiodev: better format names (and error messages) Follow-Ups: Date: 2000-Dec-06 01:34 By: ping Comment: I know a lot more work needs to be done on linuxaudiodev to make it work properly, but for now i wanted to make the existing module a little cleaner. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102679&group_id=5470 From noreply@sourceforge.net Wed Dec 6 12:07:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 04:07:08 -0800 Subject: [Patches] [Patch #102681] issubclass() and isinstance() error messages Message-ID: <200012061207.EAA20397@sf-web2.i.sourceforge.net> Patch #102681 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : Nobody Summary: issubclass() and isinstance() error messages ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102681&group_id=5470 From noreply@sourceforge.net Wed Dec 6 12:08:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 04:08:19 -0800 Subject: [Patches] [Patch #102681] issubclass() and isinstance() error messages Message-ID: <200012061208.EAA20424@sf-web2.i.sourceforge.net> Patch #102681 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : Nobody Summary: issubclass() and isinstance() error messages Follow-Ups: Date: 2000-Dec-06 04:08 By: ping Comment: This small patch makes the error messages from issubclass() and isinstance() more descriptive. It also contains a couple of tiny fixes to other docstrings in bltinmodule.c. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102681&group_id=5470 From noreply@sourceforge.net Wed Dec 6 12:53:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 04:53:06 -0800 Subject: [Patches] [Patch #102684] ceval/getargs: better messages for argument handling Message-ID: <200012061253.EAA02985@sf-web1.i.sourceforge.net> Patch #102684 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : Nobody Summary: ceval/getargs: better messages for argument handling ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102684&group_id=5470 From noreply@sourceforge.net Wed Dec 6 12:56:34 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 04:56:34 -0800 Subject: [Patches] [Patch #102684] ceval/getargs: better messages for argument handling Message-ID: <200012061256.EAA04061@sf-web1.i.sourceforge.net> Patch #102684 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : Nobody Summary: ceval/getargs: better messages for argument handling Follow-Ups: Date: 2000-Dec-06 04:56 By: ping Comment: This is an attempt to unify and improve the various kinds of TypeError messages that are produced by the wrong type or number of arguments. The function name is now provided whenever possible, and presented first in the resulting error message. (Previously it was not shown in certain cases.) The messages for wrong number of arguments to built-ins and user-defined functions used to be different, and this patch makes them consistent. Also this attempts to clarify the wording of some of the less-than-obvious messages about keyword arguments. Lots of test cases and output are included. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102684&group_id=5470 From noreply@sourceforge.net Wed Dec 6 14:29:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 06:29:12 -0800 Subject: [Patches] [Patch #102670] self of some string methods is incorrect type Message-ID: <200012061429.GAA10231@sf-web3.vaspecialprojects.com> Patch #102670 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: tokeneater Assigned to : fdrake Summary: self of some string methods is incorrect type Follow-Ups: Date: 2000-Dec-05 19:37 By: gvanrossum Comment: Fred, please check this in. Tokeneater is Jeffery D. Collins; a cool pseudonym! :) ------------------------------------------------------- Date: 2000-Dec-06 06:29 By: fdrake Comment: Checked in as Objects/stringobject.c revision 2.95. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102670&group_id=5470 From noreply@sourceforge.net Wed Dec 6 16:00:45 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 08:00:45 -0800 Subject: [Patches] [Patch #102652] Reference implementation for PEP 208 (coercion) Message-ID: <200012061600.IAA24828@sf-web2.i.sourceforge.net> Patch #102652 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nascheme Assigned to : Nobody Summary: Reference implementation for PEP 208 (coercion) Follow-Ups: Date: 2000-Dec-04 18:45 By: nascheme Comment: This patch is a little rough yet but I guess its better here than on my website. The major source of ugliness PyObject_Compare. ------------------------------------------------------- Date: 2000-Dec-06 08:00 By: nascheme Comment: Cleaned up PyObject_Compare() (still needs to be optimized). __coerce__ on instances needs be to sorted out. It should probably be called if it exists for backwards compatibility. Longs and complex types still need to be converted to new style numbers. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102652&group_id=5470 From noreply@sourceforge.net Wed Dec 6 17:43:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 09:43:23 -0800 Subject: [Patches] [Patch #102637] A patch for gdbmmodule.c Message-ID: <200012061743.JAA26709@sf-web2.i.sourceforge.net> Patch #102637 has been updated. Project: python Category: Modules Status: Deleted Submitted by: Nobody Assigned to : Nobody Summary: A patch for gdbmmodule.c Follow-Ups: Date: 2000-Dec-06 09:43 By: fdrake Comment: Duplicate of patch #102638, deleted. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102637&group_id=5470 From noreply@sourceforge.net Wed Dec 6 17:45:39 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 09:45:39 -0800 Subject: [Patches] [Patch #102679] linuxaudiodev: better format names (and error messages) Message-ID: <200012061745.JAA26754@sf-web2.i.sourceforge.net> Patch #102679 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : ping Summary: linuxaudiodev: better format names (and error messages) Follow-Ups: Date: 2000-Dec-06 01:34 By: ping Comment: I know a lot more work needs to be done on linuxaudiodev to make it work properly, but for now i wanted to make the existing module a little cleaner. ------------------------------------------------------- Date: 2000-Dec-06 09:45 By: fdrake Comment: It looks like this patch inserts a conflict! Please fix this and update. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102679&group_id=5470 From noreply@sourceforge.net Wed Dec 6 17:48:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 09:48:38 -0800 Subject: [Patches] [Patch #102106] sys._getframe() for getting the current stack frame Message-ID: <200012061748.JAA26798@sf-web2.i.sourceforge.net> Patch #102106 has been updated. Project: python Category: core (C code) Status: Accepted Submitted by: bwarsaw Assigned to : bwarsaw Summary: sys._getframe() for getting the current stack frame Follow-Ups: Date: 2000-Oct-24 20:43 By: bwarsaw Comment: This patch adds a function to the sys module which will return a frame object. By default, it returns the frame object of the current stack frame, but an optional integer argument can be supplied to retrieve any frame higher up the stack. If the integer is greater than the depth of the stack, a ValueError is raised. ------------------------------------------------------- Date: 2000-Oct-24 21:43 By: fdrake Comment: My only comment on the docs (both docstring and LaTeX) is that it should say "ValueError is raised" rather than "a ValueError is raised" (drop the "a"). Otherwise looks good; I've not run it through the formatting. ------------------------------------------------------- Date: 2000-Oct-24 21:51 By: bwarsaw Comment: Good point. Patch updated. Thanks. ------------------------------------------------------- Date: 2000-Oct-24 21:54 By: bwarsaw Comment: Oops, fixed one small typo. ------------------------------------------------------- Date: 2000-Oct-26 07:15 By: gvanrossum Comment: The docstring and docs should say that the default depth is zero. They should also mention that this is for internal use only. Can you implement this in Jython too? ------------------------------------------------------- Date: 2000-Dec-06 01:24 By: ping Comment: It's a small point, but i'd much prefer the function to be called sys.getframe() rather than sys._getframe(). There aren't any other functions in sys that begin with an underscore, and it's understood that routines in sys manipulate the Python interpreter system anyway (such as getrefcount or exc_info). This routine isn't private within sys; it's exported by sys, so it should be called sys.getframe(). ------------------------------------------------------- Date: 2000-Dec-06 09:48 By: gvanrossum Comment: I disagree with Ping. The function needs to be clearly marked as non-public-API -- it's an interface that should be used only to implement a few blessed higher-level library modules. It differs from getrefcount(), which is harmless, and exc_info(), which is intended to be used in preference to exc_type etc. (in order to be thread-safe). BTW, I'm accepting the patch -- I don't know why it hasn't been checked in yet. (The doc changes suggested should still be made.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102106&group_id=5470 From noreply@sourceforge.net Wed Dec 6 17:53:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 09:53:44 -0800 Subject: [Patches] [Patch #102681] issubclass() and isinstance() error messages Message-ID: <200012061753.JAA01935@sf-web3.vaspecialprojects.com> Patch #102681 has been updated. Project: python Category: core (C code) Status: Accepted Submitted by: ping Assigned to : ping Summary: issubclass() and isinstance() error messages Follow-Ups: Date: 2000-Dec-06 04:08 By: ping Comment: This small patch makes the error messages from issubclass() and isinstance() more descriptive. It also contains a couple of tiny fixes to other docstrings in bltinmodule.c. ------------------------------------------------------- Date: 2000-Dec-06 09:53 By: fdrake Comment: Looks good, check it in! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102681&group_id=5470 From noreply@sourceforge.net Wed Dec 6 17:56:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 09:56:02 -0800 Subject: [Patches] [Patch #102681] issubclass() and isinstance() error messages Message-ID: <200012061756.JAA26945@sf-web2.i.sourceforge.net> Patch #102681 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : Nobody Summary: issubclass() and isinstance() error messages Follow-Ups: Date: 2000-Dec-06 04:08 By: ping Comment: This small patch makes the error messages from issubclass() and isinstance() more descriptive. It also contains a couple of tiny fixes to other docstrings in bltinmodule.c. ------------------------------------------------------- Date: 2000-Dec-06 09:53 By: fdrake Comment: Looks good, check it in! ------------------------------------------------------- Date: 2000-Dec-06 09:56 By: gvanrossum Comment: Ping, are you sure that adding the function name to the error message doesn't break the support for ExtensionClasses? abstract_issubclass() is also called from isinstance(). I do agree with your docstring grammar changes! I've always thought that the correct phrasing is "Return this-or-that", not "Return*s* this-or-that". ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102681&group_id=5470 From noreply@sourceforge.net Wed Dec 6 17:57:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 09:57:31 -0800 Subject: [Patches] [Patch #102684] ceval/getargs: better messages for argument handling Message-ID: <200012061757.JAA26967@sf-web2.i.sourceforge.net> Patch #102684 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : jhylton Summary: ceval/getargs: better messages for argument handling Follow-Ups: Date: 2000-Dec-06 04:56 By: ping Comment: This is an attempt to unify and improve the various kinds of TypeError messages that are produced by the wrong type or number of arguments. The function name is now provided whenever possible, and presented first in the resulting error message. (Previously it was not shown in certain cases.) The messages for wrong number of arguments to built-ins and user-defined functions used to be different, and this patch makes them consistent. Also this attempts to clarify the wording of some of the less-than-obvious messages about keyword arguments. Lots of test cases and output are included. ------------------------------------------------------- Date: 2000-Dec-06 09:57 By: gvanrossum Comment: No time to evaluate all of this, but I agree with the goal. Reviewers, please! (Temporarily assigned to Jeremy because he's the function call expert. :-) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102684&group_id=5470 From noreply@sourceforge.net Wed Dec 6 17:59:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 09:59:52 -0800 Subject: [Patches] [Patch #102678] Let SocketServer reuse addresses Message-ID: <200012061759.JAA27018@sf-web2.i.sourceforge.net> Patch #102678 has been updated. Project: python Category: library Status: Open Submitted by: moshez Assigned to : moshez Summary: Let SocketServer reuse addresses Follow-Ups: Date: 2000-Dec-06 01:24 By: moshez Comment: Following a discussion on #python, there was a consensus there that it's a pain SocketServer.py doesn't reuse addresses. ------------------------------------------------------- Date: 2000-Dec-06 09:59 By: gvanrossum Comment: Right idea, wrong implementation. Instead of this, set allow_reuse_address to 1; it's a class variable currently set to 0. Then server_bind() already does the setsockopt(). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102678&group_id=5470 From noreply@sourceforge.net Wed Dec 6 18:04:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 10:04:15 -0800 Subject: [Patches] [Patch #102627] A Set class which *can* use the .firstkey() patch Message-ID: <200012061804.KAA27096@sf-web2.i.sourceforge.net> Patch #102627 has been updated. Project: python Category: core (C code) Status: Open Submitted by: moshez Assigned to : Nobody Summary: A Set class which *can* use the .firstkey() patch Follow-Ups: Date: 2000-Dec-03 04:47 By: moshez Comment: OK, this patch implements a Set class with an added advantage that on 102626-patched interpreter it has a method called .element() which returns some element of the set. Short summary: * supports boolean operators, substraction * supports iteration semi-efficiently * supports checking for containment semi-efficiently * supports auto-freezing when hash() is called, so can be used as key in dictionaries, and so, as an element in sets. Greg Wilson: see if this doesn't solve 95% of the problem you're trying to solve with the Set built-in type PEP. ------------------------------------------------------- Date: 2000-Dec-06 10:04 By: gvanrossum Comment: I thought that instead of firstkey() we were going to implement popitem() instead? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102627&group_id=5470 From noreply@sourceforge.net Wed Dec 6 18:33:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 10:33:43 -0800 Subject: [Patches] [Patch #102681] issubclass() and isinstance() error messages Message-ID: <200012061833.KAA27734@sf-web2.i.sourceforge.net> Patch #102681 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : ping Summary: issubclass() and isinstance() error messages Follow-Ups: Date: 2000-Dec-06 04:08 By: ping Comment: This small patch makes the error messages from issubclass() and isinstance() more descriptive. It also contains a couple of tiny fixes to other docstrings in bltinmodule.c. ------------------------------------------------------- Date: 2000-Dec-06 09:53 By: fdrake Comment: Looks good, check it in! ------------------------------------------------------- Date: 2000-Dec-06 09:56 By: gvanrossum Comment: Ping, are you sure that adding the function name to the error message doesn't break the support for ExtensionClasses? abstract_issubclass() is also called from isinstance(). I do agree with your docstring grammar changes! I've always thought that the correct phrasing is "Return this-or-that", not "Return*s* this-or-that". ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102681&group_id=5470 From noreply@sourceforge.net Wed Dec 6 18:46:14 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 10:46:14 -0800 Subject: [Patches] [Patch #102627] A Set class which *can* use the .firstkey() patch Message-ID: <200012061846.KAA23313@sf-web1.i.sourceforge.net> Patch #102627 has been updated. Project: python Category: library Status: Open Submitted by: moshez Assigned to : Nobody Summary: A Set class which *can* use the .firstkey() patch Follow-Ups: Date: 2000-Dec-03 04:47 By: moshez Comment: OK, this patch implements a Set class with an added advantage that on 102626-patched interpreter it has a method called .element() which returns some element of the set. Short summary: * supports boolean operators, substraction * supports iteration semi-efficiently * supports checking for containment semi-efficiently * supports auto-freezing when hash() is called, so can be used as key in dictionaries, and so, as an element in sets. Greg Wilson: see if this doesn't solve 95% of the problem you're trying to solve with the Set built-in type PEP. ------------------------------------------------------- Date: 2000-Dec-06 10:04 By: gvanrossum Comment: I thought that instead of firstkey() we were going to implement popitem() instead? ------------------------------------------------------- Date: 2000-Dec-06 10:46 By: tim_one Comment: Changed Category to Library. Comments: Style: don't use hard tabs; add doc strings. Space efficiency: "_frozen = 0" is better at class level (most uses of sets never need it). __hash__: (1) you can cache the hash if the set is frozen, and in my experience that's important for efficiency. (2) it doesn't work correctly, although it may take some effort to provoke a failure. The problem is that you're deferring to hash(_make_elements()), _make_elements() returns a tuple, and the hash of a tuple depends on the order the keys happen to get materialized. But the hash of a set must be independent of the order the keys happen to get listed. See the code fragments I posted for a correct Set __hash__. __ior__: dict.update is much quicker than explicit iteration. The ability to apply set operators to raw sequences is unimportant, and not fully supported even if that is your intent (e.g., you don't have the "right-side" operators defined here). Confusing: most of the operators are defined in terms of add() and remove(). This will make the error msgs when they're applied to frozen sets confusing, because indirect. It's also much slower than doing the deed directly. In short, this looks like the first Set class someone writes off the top of their head in Python. That isn't bad, but something in the std distribution should be more than a finger exercise. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102627&group_id=5470 From noreply@sourceforge.net Wed Dec 6 18:55:26 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 10:55:26 -0800 Subject: [Patches] [Patch #102627] A Set class which *can* use the .firstkey() patch Message-ID: <200012061855.KAA09400@sf-web3.vaspecialprojects.com> Patch #102627 has been updated. Project: python Category: library Status: Open Submitted by: moshez Assigned to : Nobody Summary: A Set class which *can* use the .firstkey() patch Follow-Ups: Date: 2000-Dec-03 04:47 By: moshez Comment: OK, this patch implements a Set class with an added advantage that on 102626-patched interpreter it has a method called .element() which returns some element of the set. Short summary: * supports boolean operators, substraction * supports iteration semi-efficiently * supports checking for containment semi-efficiently * supports auto-freezing when hash() is called, so can be used as key in dictionaries, and so, as an element in sets. Greg Wilson: see if this doesn't solve 95% of the problem you're trying to solve with the Set built-in type PEP. ------------------------------------------------------- Date: 2000-Dec-06 10:04 By: gvanrossum Comment: I thought that instead of firstkey() we were going to implement popitem() instead? ------------------------------------------------------- Date: 2000-Dec-06 10:46 By: tim_one Comment: Changed Category to Library. Comments: Style: don't use hard tabs; add doc strings. Space efficiency: "_frozen = 0" is better at class level (most uses of sets never need it). __hash__: (1) you can cache the hash if the set is frozen, and in my experience that's important for efficiency. (2) it doesn't work correctly, although it may take some effort to provoke a failure. The problem is that you're deferring to hash(_make_elements()), _make_elements() returns a tuple, and the hash of a tuple depends on the order the keys happen to get materialized. But the hash of a set must be independent of the order the keys happen to get listed. See the code fragments I posted for a correct Set __hash__. __ior__: dict.update is much quicker than explicit iteration. The ability to apply set operators to raw sequences is unimportant, and not fully supported even if that is your intent (e.g., you don't have the "right-side" operators defined here). Confusing: most of the operators are defined in terms of add() and remove(). This will make the error msgs when they're applied to frozen sets confusing, because indirect. It's also much slower than doing the deed directly. In short, this looks like the first Set class someone writes off the top of their head in Python. That isn't bad, but something in the std distribution should be more than a finger exercise. ------------------------------------------------------- Date: 2000-Dec-06 10:55 By: tim_one Comment: Changed Category to Library. Comments: Style: don't use hard tabs; add doc strings. Space efficiency: "_frozen = 0" is better at class level (most uses of sets never need it). __hash__: (1) you can cache the hash if the set is frozen, and in my experience that's important for efficiency. (2) it doesn't work correctly, although it may take some effort to provoke a failure. The problem is that you're deferring to hash(_make_elements()), _make_elements() returns a tuple, and the hash of a tuple depends on the order the keys happen to get materialized. But the hash of a set must be independent of the order the keys happen to get listed. See the code fragments I posted for a correct Set __hash__. __ior__: dict.update is much quicker than explicit iteration. The ability to apply set operators to raw sequences is unimportant, and not fully supported even if that is your intent (e.g., you don't have the "right-side" operators defined here). Confusing: most of the operators are defined in terms of add() and remove(). This will make the error msgs when they're applied to frozen sets confusing, because indirect. It's also much slower than doing the deed directly. In short, this looks like the first Set class someone writes off the top of their head in Python. That isn't bad, but something in the std distribution should be more than a finger exercise. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102627&group_id=5470 From noreply@sourceforge.net Wed Dec 6 18:57:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 10:57:29 -0800 Subject: [Patches] [Patch #102627] A Set class which *can* use the .firstkey() patch Message-ID: <200012061857.KAA09437@sf-web3.vaspecialprojects.com> Patch #102627 has been updated. Project: python Category: library Status: Open Submitted by: moshez Assigned to : Nobody Summary: A Set class which *can* use the .firstkey() patch Follow-Ups: Date: 2000-Dec-03 04:47 By: moshez Comment: OK, this patch implements a Set class with an added advantage that on 102626-patched interpreter it has a method called .element() which returns some element of the set. Short summary: * supports boolean operators, substraction * supports iteration semi-efficiently * supports checking for containment semi-efficiently * supports auto-freezing when hash() is called, so can be used as key in dictionaries, and so, as an element in sets. Greg Wilson: see if this doesn't solve 95% of the problem you're trying to solve with the Set built-in type PEP. ------------------------------------------------------- Date: 2000-Dec-06 10:04 By: gvanrossum Comment: I thought that instead of firstkey() we were going to implement popitem() instead? ------------------------------------------------------- Date: 2000-Dec-06 10:46 By: tim_one Comment: Changed Category to Library. Comments: Style: don't use hard tabs; add doc strings. Space efficiency: "_frozen = 0" is better at class level (most uses of sets never need it). __hash__: (1) you can cache the hash if the set is frozen, and in my experience that's important for efficiency. (2) it doesn't work correctly, although it may take some effort to provoke a failure. The problem is that you're deferring to hash(_make_elements()), _make_elements() returns a tuple, and the hash of a tuple depends on the order the keys happen to get materialized. But the hash of a set must be independent of the order the keys happen to get listed. See the code fragments I posted for a correct Set __hash__. __ior__: dict.update is much quicker than explicit iteration. The ability to apply set operators to raw sequences is unimportant, and not fully supported even if that is your intent (e.g., you don't have the "right-side" operators defined here). Confusing: most of the operators are defined in terms of add() and remove(). This will make the error msgs when they're applied to frozen sets confusing, because indirect. It's also much slower than doing the deed directly. In short, this looks like the first Set class someone writes off the top of their head in Python. That isn't bad, but something in the std distribution should be more than a finger exercise. ------------------------------------------------------- Date: 2000-Dec-06 10:55 By: tim_one Comment: Changed Category to Library. Comments: Style: don't use hard tabs; add doc strings. Space efficiency: "_frozen = 0" is better at class level (most uses of sets never need it). __hash__: (1) you can cache the hash if the set is frozen, and in my experience that's important for efficiency. (2) it doesn't work correctly, although it may take some effort to provoke a failure. The problem is that you're deferring to hash(_make_elements()), _make_elements() returns a tuple, and the hash of a tuple depends on the order the keys happen to get materialized. But the hash of a set must be independent of the order the keys happen to get listed. See the code fragments I posted for a correct Set __hash__. __ior__: dict.update is much quicker than explicit iteration. The ability to apply set operators to raw sequences is unimportant, and not fully supported even if that is your intent (e.g., you don't have the "right-side" operators defined here). Confusing: most of the operators are defined in terms of add() and remove(). This will make the error msgs when they're applied to frozen sets confusing, because indirect. It's also much slower than doing the deed directly. In short, this looks like the first Set class someone writes off the top of their head in Python. That isn't bad, but something in the std distribution should be more than a finger exercise. ------------------------------------------------------- Date: 2000-Dec-06 10:57 By: tim_one Comment: Sorry about the duplicate -- I have got to learn to reboot my machine (or does it need a full power cycle?) when a SourceForge page asks whether I want to repost data! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102627&group_id=5470 From noreply@sourceforge.net Wed Dec 6 19:35:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 11:35:53 -0800 Subject: [Patches] [Patch #102679] linuxaudiodev: better format names (and error messages) Message-ID: <200012061935.LAA11263@sf-web3.vaspecialprojects.com> Patch #102679 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : ping Summary: linuxaudiodev: better format names (and error messages) Follow-Ups: Date: 2000-Dec-06 01:34 By: ping Comment: I know a lot more work needs to be done on linuxaudiodev to make it work properly, but for now i wanted to make the existing module a little cleaner. ------------------------------------------------------- Date: 2000-Dec-06 09:45 By: fdrake Comment: It looks like this patch inserts a conflict! Please fix this and update. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102679&group_id=5470 From noreply@sourceforge.net Wed Dec 6 19:40:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 11:40:13 -0800 Subject: [Patches] [Patch #102669] self of some string methods is incorrect type Message-ID: <200012061940.LAA12364@sf-web3.vaspecialprojects.com> Patch #102669 has been updated. Project: python Category: core (C code) Status: Deleted Submitted by: tokeneater Assigned to : Nobody Summary: self of some string methods is incorrect type Follow-Ups: Date: 2000-Dec-06 11:40 By: fdrake Comment: Duplicate; already accepted identical patch #102670. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102669&group_id=5470 From noreply@sourceforge.net Wed Dec 6 20:01:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 12:01:58 -0800 Subject: [Patches] [Patch #102679] linuxaudiodev: better format names (and error messages) Message-ID: <200012062001.MAA15115@sf-web3.vaspecialprojects.com> Patch #102679 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : ping Summary: linuxaudiodev: better format names (and error messages) Follow-Ups: Date: 2000-Dec-06 01:34 By: ping Comment: I know a lot more work needs to be done on linuxaudiodev to make it work properly, but for now i wanted to make the existing module a little cleaner. ------------------------------------------------------- Date: 2000-Dec-06 09:45 By: fdrake Comment: It looks like this patch inserts a conflict! Please fix this and update. ------------------------------------------------------- Date: 2000-Dec-06 12:01 By: ping Comment: I'm amazed. Honestly, i can't believe i did that. Sorry. (Fixed.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102679&group_id=5470 From noreply@sourceforge.net Wed Dec 6 20:26:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 12:26:49 -0800 Subject: [Patches] [Patch #102691] Use CXX in Misc/Makefile.pre.in and Modules/makesetup Message-ID: <200012062026.MAA29904@sf-web2.i.sourceforge.net> Patch #102691 has been updated. Project: python Category: Build Status: Open Submitted by: gvanrossum Assigned to : Nobody Summary: Use CXX in Misc/Makefile.pre.in and Modules/makesetup ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102691&group_id=5470 From noreply@sourceforge.net Wed Dec 6 20:30:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 12:30:10 -0800 Subject: [Patches] [Patch #102691] Use CXX in Misc/Makefile.pre.in and Modules/makesetup Message-ID: <200012062030.MAA29952@sf-web2.i.sourceforge.net> Patch #102691 has been updated. Project: python Category: Build Status: Open Submitted by: gvanrossum Assigned to : gvanrossum Summary: Use CXX in Misc/Makefile.pre.in and Modules/makesetup Follow-Ups: Date: 2000-Dec-06 12:30 By: gvanrossum Comment: Hopefully this fixes this bug: http://sourceforge.net/bugs/?func=detailbug&bug_id=124478&group_id=5470 Waiting for the bug reporter's feedback. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102691&group_id=5470 From noreply@sourceforge.net Wed Dec 6 21:01:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 13:01:24 -0800 Subject: [Patches] [Patch #102691] Use CXX in Misc/Makefile.pre.in and Modules/makesetup Message-ID: <200012062101.NAA23133@sf-web3.vaspecialprojects.com> Patch #102691 has been updated. Project: python Category: Build Status: Open Submitted by: gvanrossum Assigned to : gvanrossum Summary: Use CXX in Misc/Makefile.pre.in and Modules/makesetup Follow-Ups: Date: 2000-Dec-06 12:30 By: gvanrossum Comment: Hopefully this fixes this bug: http://sourceforge.net/bugs/?func=detailbug&bug_id=124478&group_id=5470 Waiting for the bug reporter's feedback. ------------------------------------------------------- Date: 2000-Dec-06 13:01 By: rossrizer Comment: I was so sure that it would work, I almost didn't test it. But I did: cd /usr/local/src/Python-2.0 patch -p0 102691.patch make clean ./configure make make install cp Misc/Makefile.pre.in mypythonmoduledir cd mypythonmoduledir make -f Makefile.pre.in make still broke: # Generated automatically from Makefile.pre by makesetup. # Generated automatically from Makefile.pre.in by sedscript. # Universal Unix Makefile for Python extensions # ============================================= # Short Instructions # ------------------ # 1. Build and install Python (1.5 or newer). # 2. "make -f Makefile.pre.in boot" # 3. "make" # You should now have a shared library. # Long Instructions # ----------------- # Build *and install* the basic Python 1.5 distribution. See the # Python README for instructions. (This version of Makefile.pre.in # only withs with Python 1.5, alpha 3 or newer.) # Create a file Setup.in for your extension. This file follows the # format of the Modules/Setup.in file; see the instructions there. # For a simple module called "spam" on file "spammodule.c", it can # contain a single line: # spam spammodule.c # You can build as many modules as you want in the same directory -- # just have a separate line for each of them in the Setup.in file. # If you want to build your extension as a shared library, insert a # line containing just the string # *shared* # at the top of your Setup.in file. # Note that the build process copies Setup.in to Setup, and then works # with Setup. It doesn't overwrite Setup when Setup.in is changed, so # while you're in the process of debugging your Setup.in file, you may # want to edit Setup instead, and copy it back to Setup.in later. # (All this is done so you can distribute your extension easily and # someone else can select the modules they actually want to build by # commenting out lines in the Setup file, without editing the # original. Editing Setup is also used to specify nonstandard # locations for include or library files.) # Copy this file (Misc/Makefile.pre.in) to the directory containing # your extension. # Run "make -f Makefile.pre.in boot". This creates Makefile # (producing Makefile.pre and sedscript as intermediate files) and # config.c, incorporating the values for sys.prefix, sys.exec_prefix # and sys.version from the installed Python binary. For this to work, # the python binary must be on your path. If this fails, try # make -f Makefile.pre.in Makefile VERSION=1.5 installdir= # where is the prefix used to install Python for installdir # (and possibly similar for exec_installdir=). # Note: "make boot" implies "make clobber" -- it assumes that when you # bootstrap you may have changed platforms so it removes all previous # output files. # If you are building your extension as a shared library (your # Setup.in file starts with *shared*), run "make" or "make sharedmods" # to build the shared library files. If you are building a statically # linked Python binary (the only solution of your platform doesn't # support shared libraries, and sometimes handy if you want to # distribute or install the resulting Python binary), run "make # python". # Note: Each time you edit Makefile.pre.in or Setup, you must run # "make Makefile" before running "make". # Hint: if you want to use VPATH, you can start in an empty # subdirectory and say (e.g.): # make -f ../Makefile.pre.in boot srcdir=.. VPATH=.. # === Bootstrap variables (edited through "make boot") === # The prefix used by "make inclinstall libainstall" of core python installdir= /usr/local # The exec_prefix used by the same exec_installdir=/usr/local # Source directory and VPATH in case you want to use VPATH. # (You will have to edit these two lines yourself -- there is no # automatic support as the Makefile is not generated by # config.status.) srcdir= . VPATH= . # === Variables that you may want to customize (rarely) === # (Static) build target TARGET= python # Installed python binary (used only by boot target) PYTHON= python # Add more -I and -D options here CFLAGS= $(OPT) -I$(INCLUDEPY) -I$(EXECINCLUDEPY) $(DEFS) # These two variables can be set in Setup to merge extensions. # See example[23]. BASELIB= BASESETUP= # === Variables set by makesetup === MODOBJS= MODLIBS= $(LOCALMODLIBS) $(BASEMODLIBS) # === Definitions added by makesetup === LOCALMODLIBS= BASEMODLIBS= SHAREDMODS= simumodule$(SO) TKPATH=:lib-tk GLHACK=-Dclear=__GLclear PYTHONPATH=$(COREPYTHONPATH) COREPYTHONPATH=$(DESTPATH)$(SITEPATH)$(TESTPATH)$(MACHDEPPATH)$(TKPATH) MACHDEPPATH=:plat-$(MACHDEP) TESTPATH= SITEPATH= DESTPATH= MACHDESTLIB=$(BINLIBDEST) DESTLIB=$(LIBDEST) SHITE2=-Wl,--no-whole-archive SHITE1=-Wl,--whole-archive CPPFLAGS= -Wall -D_DEBUG -D__WXGTK__ -I.. -I../spoon -I../simulator # === Variables from configure (through sedscript) === VERSION= 2.0 CC= gcc LINKCC= $(PURIFY) $(CC) SGI_ABI= OPT= -g -O2 -Wall -Wstrict-prototypes LDFLAGS= LDLAST= DEFS= -DHAVE_CONFIG_H LIBS= -lpthread -ldl -lutil LIBM= -lm LIBC= RANLIB= ranlib MACHDEP= linux2 SO= .so LDSHARED= gcc -shared CCSHARED= -fpic LINKFORSHARED= -Xlinker -export-dynamic CXX= # Install prefix for architecture-independent files prefix= /usr/local # Install prefix for architecture-dependent files exec_prefix= ${prefix} # Uncomment the following two lines for AIX #LINKCC= $(LIBPL)/makexp_aix $(LIBPL)/python.exp "" $(LIBRARY); $(PURIFY) $(CC) #LDSHARED= $(LIBPL)/ld_so_aix $(CC) -bI:$(LIBPL)/python.exp # === Fixed definitions === # Shell used by make (some versions default to the login shell, which is bad) SHELL= /bin/sh # Expanded directories BINDIR= $(exec_installdir)/bin LIBDIR= $(exec_prefix)/lib MANDIR= $(installdir)/man INCLUDEDIR= $(installdir)/include SCRIPTDIR= $(prefix)/lib # Detailed destination directories BINLIBDEST= $(LIBDIR)/python$(VERSION) LIBDEST= $(SCRIPTDIR)/python$(VERSION) INCLUDEPY= $(INCLUDEDIR)/python$(VERSION) EXECINCLUDEPY= $(exec_installdir)/include/python$(VERSION) LIBP= $(exec_installdir)/lib/python$(VERSION) DESTSHARED= $(BINLIBDEST)/site-packages LIBPL= $(LIBP)/config PYTHONLIBS= $(LIBPL)/libpython$(VERSION).a MAKESETUP= $(LIBPL)/makesetup MAKEFILE= $(LIBPL)/Makefile CONFIGC= $(LIBPL)/config.c CONFIGCIN= $(LIBPL)/config.c.in SETUP= $(LIBPL)/Setup.config $(LIBPL)/Setup.local $(LIBPL)/Setup SYSLIBS= $(LIBM) $(LIBC) ADDOBJS= $(LIBPL)/python.o config.o # Portable install script (configure doesn't always guess right) INSTALL= $(LIBPL)/install-sh -c # Shared libraries must be installed with executable mode on some systems; # rather than figuring out exactly which, we always give them executable mode. # Also, making them read-only seems to be a good idea... INSTALL_SHARED= ${INSTALL} -m 555 # === Fixed rules === # Default target. This builds shared libraries only default: sharedmods # Build everything all: static sharedmods # Build shared libraries from our extension modules sharedmods: $(SHAREDMODS) # Build a static Python binary containing our extension modules static: $(TARGET) $(TARGET): $(ADDOBJS) lib.a $(PYTHONLIBS) Makefile $(BASELIB) $(LINKCC) $(LDFLAGS) $(LINKFORSHARED) \ $(ADDOBJS) lib.a $(PYTHONLIBS) \ $(LINKPATH) $(BASELIB) $(MODLIBS) $(LIBS) $(SYSLIBS) \ -o $(TARGET) $(LDLAST) install: sharedmods if test ! -d $(DESTSHARED) ; then \ mkdir $(DESTSHARED) ; else true ; fi -for i in X $(SHAREDMODS); do \ if test $$i != X; \ then $(INSTALL_SHARED) $$i $(DESTSHARED)/$$i; \ fi; \ done # Build the library containing our extension modules lib.a: $(MODOBJS) -rm -f lib.a ar cr lib.a $(MODOBJS) -$(RANLIB) lib.a # This runs makesetup *twice* to use the BASESETUP definition from Setup config.c Makefile: Makefile.pre Setup $(BASESETUP) $(MAKESETUP) $(MAKESETUP) \ -m Makefile.pre -c $(CONFIGCIN) Setup -n $(BASESETUP) $(SETUP) $(MAKE) -f Makefile do-it-again # Internal target to run makesetup for the second time do-it-again: $(MAKESETUP) \ -m Makefile.pre -c $(CONFIGCIN) Setup -n $(BASESETUP) $(SETUP) # Make config.o from the config.c created by makesetup config.o: config.c $(CC) $(CFLAGS) -c config.c # Setup is copied from Setup.in *only* if it doesn't yet exist Setup: cp $(srcdir)/Setup.in Setup # Make the intermediate Makefile.pre from Makefile.pre.in Makefile.pre: Makefile.pre.in sedscript sed -f sedscript $(srcdir)/Makefile.pre.in >Makefile.pre # Shortcuts to make the sed arguments on one line P=prefix E=exec_prefix H=Generated automatically from Makefile.pre.in by sedscript. L=LINKFORSHARED # Make the sed script used to create Makefile.pre from Makefile.pre.in sedscript: $(MAKEFILE) sed -n \ -e '1s/.*/1i\\/p' \ -e '2s%.*%# $H%p' \ -e '/^VERSION=/s/^VERSION=[ ]*\(.*\)/s%@VERSION[@]%\1%/p' \ -e '/^CC=/s/^CC=[ ]*\(.*\)/s%@CC[@]%\1%/p' \ -e '/^CXX=/s/^CXX=[ ]*\(.*\)/s%#@SET_CXX[@]%CXX=\1%/p' \ -e '/^LINKCC=/s/^LINKCC=[ ]*\(.*\)/s%@LINKCC[@]%\1%/p' \ -e '/^OPT=/s/^OPT=[ ]*\(.*\)/s%@OPT[@]%\1%/p' \ -e '/^LDFLAGS=/s/^LDFLAGS=[ ]*\(.*\)/s%@LDFLAGS[@]%\1%/p' \ -e '/^LDLAST=/s/^LDLAST=[ ]*\(.*\)/s%@LDLAST[@]%\1%/p' \ -e '/^DEFS=/s/^DEFS=[ ]*\(.*\)/s%@DEFS[@]%\1%/p' \ -e '/^LIBS=/s/^LIBS=[ ]*\(.*\)/s%@LIBS[@]%\1%/p' \ -e '/^LIBM=/s/^LIBM=[ ]*\(.*\)/s%@LIBM[@]%\1%/p' \ -e '/^LIBC=/s/^LIBC=[ ]*\(.*\)/s%@LIBC[@]%\1%/p' \ -e '/^RANLIB=/s/^RANLIB=[ ]*\(.*\)/s%@RANLIB[@]%\1%/p' \ -e '/^MACHDEP=/s/^MACHDEP=[ ]*\(.*\)/s%@MACHDEP[@]%\1%/p' \ -e '/^SO=/s/^SO=[ ]*\(.*\)/s%@SO[@]%\1%/p' \ -e '/^LDSHARED=/s/^LDSHARED=[ ]*\(.*\)/s%@LDSHARED[@]%\1%/p' \ -e '/^CCSHARED=/s/^CCSHARED=[ ]*\(.*\)/s%@CCSHARED[@]%\1%/p' \ -e '/^SGI_ABI=/s/^SGI_ABI=[ ]*\(.*\)/s%@SGI_ABI[@]%\1%/p' \ -e '/^$L=/s/^$L=[ ]*\(.*\)/s%@$L[@]%\1%/p' \ -e '/^$P=/s/^$P=\(.*\)/s%^$P=.*%$P=\1%/p' \ -e '/^$E=/s/^$E=\(.*\)/s%^$E=.*%$E=\1%/p' \ $(MAKEFILE) >sedscript echo "/^CXX=/d" >>sedscript echo "/^installdir=/s%=.*%= $(installdir)%" >>sedscript echo "/^exec_installdir=/s%=.*%=$(exec_installdir)%" >>sedscript echo "/^srcdir=/s%=.*%= $(srcdir)%" >>sedscript echo "/^VPATH=/s%=.*%= $(VPATH)%" >>sedscript echo "/^LINKPATH=/s%=.*%= $(LINKPATH)%" >>sedscript echo "/^BASELIB=/s%=.*%= $(BASELIB)%" >>sedscript echo "/^BASESETUP=/s%=.*%= $(BASESETUP)%" >>sedscript # Bootstrap target boot: clobber VERSION=`$(PYTHON) -c "import sys; print sys.version[:3]"`; \ installdir=`$(PYTHON) -c "import sys; print sys.prefix"`; \ exec_installdir=`$(PYTHON) -c "import sys; print sys.exec_prefix"`; \ $(MAKE) -f $(srcdir)/Makefile.pre.in VPATH=$(VPATH) srcdir=$(srcdir) \ VERSION=$$VERSION \ installdir=$$installdir \ exec_installdir=$$exec_installdir \ Makefile # Handy target to remove intermediate files and backups clean: -rm -f *.o *~ # Handy target to remove everything that is easily regenerated clobber: clean -rm -f *.a tags TAGS config.c Makefile.pre $(TARGET) sedscript -rm -f *.so *.sl so_locations # Handy target to remove everything you don't want to distribute distclean: clobber -rm -f Makefile Setup # Rules appended by makedepend x.o: $(srcdir)/x.cpp; $(CXX) $(CCSHARED) $(CPPFLAGS) $(SHITE1) $(SHITE2) $(CFLAGS) -c $(srcdir)/x.cpp x$(SO): x.o; $(LDSHARED) x.o $(CPPFLAGS) $(SHITE1) (SHITE2) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102691&group_id=5470 From noreply@sourceforge.net Wed Dec 6 21:14:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 13:14:43 -0800 Subject: [Patches] [Patch #102691] Use CXX in Misc/Makefile.pre.in and Modules/makesetup Message-ID: <200012062114.NAA24536@sf-web3.vaspecialprojects.com> Patch #102691 has been updated. Project: python Category: Build Status: Open Submitted by: gvanrossum Assigned to : gvanrossum Summary: Use CXX in Misc/Makefile.pre.in and Modules/makesetup Follow-Ups: Date: 2000-Dec-06 12:30 By: gvanrossum Comment: Hopefully this fixes this bug: http://sourceforge.net/bugs/?func=detailbug&bug_id=124478&group_id=5470 Waiting for the bug reporter's feedback. ------------------------------------------------------- Date: 2000-Dec-06 13:01 By: rossrizer Comment: I was so sure that it would work, I almost didn't test it. But I did: cd /usr/local/src/Python-2.0 patch -p0 102691.patch make clean ./configure make make install cp Misc/Makefile.pre.in mypythonmoduledir cd mypythonmoduledir make -f Makefile.pre.in make still broke: # Generated automatically from Makefile.pre by makesetup. # Generated automatically from Makefile.pre.in by sedscript. # Universal Unix Makefile for Python extensions # ============================================= # Short Instructions # ------------------ # 1. Build and install Python (1.5 or newer). # 2. "make -f Makefile.pre.in boot" # 3. "make" # You should now have a shared library. # Long Instructions # ----------------- # Build *and install* the basic Python 1.5 distribution. See the # Python README for instructions. (This version of Makefile.pre.in # only withs with Python 1.5, alpha 3 or newer.) # Create a file Setup.in for your extension. This file follows the # format of the Modules/Setup.in file; see the instructions there. # For a simple module called "spam" on file "spammodule.c", it can # contain a single line: # spam spammodule.c # You can build as many modules as you want in the same directory -- # just have a separate line for each of them in the Setup.in file. # If you want to build your extension as a shared library, insert a # line containing just the string # *shared* # at the top of your Setup.in file. # Note that the build process copies Setup.in to Setup, and then works # with Setup. It doesn't overwrite Setup when Setup.in is changed, so # while you're in the process of debugging your Setup.in file, you may # want to edit Setup instead, and copy it back to Setup.in later. # (All this is done so you can distribute your extension easily and # someone else can select the modules they actually want to build by # commenting out lines in the Setup file, without editing the # original. Editing Setup is also used to specify nonstandard # locations for include or library files.) # Copy this file (Misc/Makefile.pre.in) to the directory containing # your extension. # Run "make -f Makefile.pre.in boot". This creates Makefile # (producing Makefile.pre and sedscript as intermediate files) and # config.c, incorporating the values for sys.prefix, sys.exec_prefix # and sys.version from the installed Python binary. For this to work, # the python binary must be on your path. If this fails, try # make -f Makefile.pre.in Makefile VERSION=1.5 installdir= # where is the prefix used to install Python for installdir # (and possibly similar for exec_installdir=). # Note: "make boot" implies "make clobber" -- it assumes that when you # bootstrap you may have changed platforms so it removes all previous # output files. # If you are building your extension as a shared library (your # Setup.in file starts with *shared*), run "make" or "make sharedmods" # to build the shared library files. If you are building a statically # linked Python binary (the only solution of your platform doesn't # support shared libraries, and sometimes handy if you want to # distribute or install the resulting Python binary), run "make # python". # Note: Each time you edit Makefile.pre.in or Setup, you must run # "make Makefile" before running "make". # Hint: if you want to use VPATH, you can start in an empty # subdirectory and say (e.g.): # make -f ../Makefile.pre.in boot srcdir=.. VPATH=.. # === Bootstrap variables (edited through "make boot") === # The prefix used by "make inclinstall libainstall" of core python installdir= /usr/local # The exec_prefix used by the same exec_installdir=/usr/local # Source directory and VPATH in case you want to use VPATH. # (You will have to edit these two lines yourself -- there is no # automatic support as the Makefile is not generated by # config.status.) srcdir= . VPATH= . # === Variables that you may want to customize (rarely) === # (Static) build target TARGET= python # Installed python binary (used only by boot target) PYTHON= python # Add more -I and -D options here CFLAGS= $(OPT) -I$(INCLUDEPY) -I$(EXECINCLUDEPY) $(DEFS) # These two variables can be set in Setup to merge extensions. # See example[23]. BASELIB= BASESETUP= # === Variables set by makesetup === MODOBJS= MODLIBS= $(LOCALMODLIBS) $(BASEMODLIBS) # === Definitions added by makesetup === LOCALMODLIBS= BASEMODLIBS= SHAREDMODS= simumodule$(SO) TKPATH=:lib-tk GLHACK=-Dclear=__GLclear PYTHONPATH=$(COREPYTHONPATH) COREPYTHONPATH=$(DESTPATH)$(SITEPATH)$(TESTPATH)$(MACHDEPPATH)$(TKPATH) MACHDEPPATH=:plat-$(MACHDEP) TESTPATH= SITEPATH= DESTPATH= MACHDESTLIB=$(BINLIBDEST) DESTLIB=$(LIBDEST) SHITE2=-Wl,--no-whole-archive SHITE1=-Wl,--whole-archive CPPFLAGS= -Wall -D_DEBUG -D__WXGTK__ -I.. -I../spoon -I../simulator # === Variables from configure (through sedscript) === VERSION= 2.0 CC= gcc LINKCC= $(PURIFY) $(CC) SGI_ABI= OPT= -g -O2 -Wall -Wstrict-prototypes LDFLAGS= LDLAST= DEFS= -DHAVE_CONFIG_H LIBS= -lpthread -ldl -lutil LIBM= -lm LIBC= RANLIB= ranlib MACHDEP= linux2 SO= .so LDSHARED= gcc -shared CCSHARED= -fpic LINKFORSHARED= -Xlinker -export-dynamic CXX= # Install prefix for architecture-independent files prefix= /usr/local # Install prefix for architecture-dependent files exec_prefix= ${prefix} # Uncomment the following two lines for AIX #LINKCC= $(LIBPL)/makexp_aix $(LIBPL)/python.exp "" $(LIBRARY); $(PURIFY) $(CC) #LDSHARED= $(LIBPL)/ld_so_aix $(CC) -bI:$(LIBPL)/python.exp # === Fixed definitions === # Shell used by make (some versions default to the login shell, which is bad) SHELL= /bin/sh # Expanded directories BINDIR= $(exec_installdir)/bin LIBDIR= $(exec_prefix)/lib MANDIR= $(installdir)/man INCLUDEDIR= $(installdir)/include SCRIPTDIR= $(prefix)/lib # Detailed destination directories BINLIBDEST= $(LIBDIR)/python$(VERSION) LIBDEST= $(SCRIPTDIR)/python$(VERSION) INCLUDEPY= $(INCLUDEDIR)/python$(VERSION) EXECINCLUDEPY= $(exec_installdir)/include/python$(VERSION) LIBP= $(exec_installdir)/lib/python$(VERSION) DESTSHARED= $(BINLIBDEST)/site-packages LIBPL= $(LIBP)/config PYTHONLIBS= $(LIBPL)/libpython$(VERSION).a MAKESETUP= $(LIBPL)/makesetup MAKEFILE= $(LIBPL)/Makefile CONFIGC= $(LIBPL)/config.c CONFIGCIN= $(LIBPL)/config.c.in SETUP= $(LIBPL)/Setup.config $(LIBPL)/Setup.local $(LIBPL)/Setup SYSLIBS= $(LIBM) $(LIBC) ADDOBJS= $(LIBPL)/python.o config.o # Portable install script (configure doesn't always guess right) INSTALL= $(LIBPL)/install-sh -c # Shared libraries must be installed with executable mode on some systems; # rather than figuring out exactly which, we always give them executable mode. # Also, making them read-only seems to be a good idea... INSTALL_SHARED= ${INSTALL} -m 555 # === Fixed rules === # Default target. This builds shared libraries only default: sharedmods # Build everything all: static sharedmods # Build shared libraries from our extension modules sharedmods: $(SHAREDMODS) # Build a static Python binary containing our extension modules static: $(TARGET) $(TARGET): $(ADDOBJS) lib.a $(PYTHONLIBS) Makefile $(BASELIB) $(LINKCC) $(LDFLAGS) $(LINKFORSHARED) \ $(ADDOBJS) lib.a $(PYTHONLIBS) \ $(LINKPATH) $(BASELIB) $(MODLIBS) $(LIBS) $(SYSLIBS) \ -o $(TARGET) $(LDLAST) install: sharedmods if test ! -d $(DESTSHARED) ; then \ mkdir $(DESTSHARED) ; else true ; fi -for i in X $(SHAREDMODS); do \ if test $$i != X; \ then $(INSTALL_SHARED) $$i $(DESTSHARED)/$$i; \ fi; \ done # Build the library containing our extension modules lib.a: $(MODOBJS) -rm -f lib.a ar cr lib.a $(MODOBJS) -$(RANLIB) lib.a # This runs makesetup *twice* to use the BASESETUP definition from Setup config.c Makefile: Makefile.pre Setup $(BASESETUP) $(MAKESETUP) $(MAKESETUP) \ -m Makefile.pre -c $(CONFIGCIN) Setup -n $(BASESETUP) $(SETUP) $(MAKE) -f Makefile do-it-again # Internal target to run makesetup for the second time do-it-again: $(MAKESETUP) \ -m Makefile.pre -c $(CONFIGCIN) Setup -n $(BASESETUP) $(SETUP) # Make config.o from the config.c created by makesetup config.o: config.c $(CC) $(CFLAGS) -c config.c # Setup is copied from Setup.in *only* if it doesn't yet exist Setup: cp $(srcdir)/Setup.in Setup # Make the intermediate Makefile.pre from Makefile.pre.in Makefile.pre: Makefile.pre.in sedscript sed -f sedscript $(srcdir)/Makefile.pre.in >Makefile.pre # Shortcuts to make the sed arguments on one line P=prefix E=exec_prefix H=Generated automatically from Makefile.pre.in by sedscript. L=LINKFORSHARED # Make the sed script used to create Makefile.pre from Makefile.pre.in sedscript: $(MAKEFILE) sed -n \ -e '1s/.*/1i\\/p' \ -e '2s%.*%# $H%p' \ -e '/^VERSION=/s/^VERSION=[ ]*\(.*\)/s%@VERSION[@]%\1%/p' \ -e '/^CC=/s/^CC=[ ]*\(.*\)/s%@CC[@]%\1%/p' \ -e '/^CXX=/s/^CXX=[ ]*\(.*\)/s%#@SET_CXX[@]%CXX=\1%/p' \ -e '/^LINKCC=/s/^LINKCC=[ ]*\(.*\)/s%@LINKCC[@]%\1%/p' \ -e '/^OPT=/s/^OPT=[ ]*\(.*\)/s%@OPT[@]%\1%/p' \ -e '/^LDFLAGS=/s/^LDFLAGS=[ ]*\(.*\)/s%@LDFLAGS[@]%\1%/p' \ -e '/^LDLAST=/s/^LDLAST=[ ]*\(.*\)/s%@LDLAST[@]%\1%/p' \ -e '/^DEFS=/s/^DEFS=[ ]*\(.*\)/s%@DEFS[@]%\1%/p' \ -e '/^LIBS=/s/^LIBS=[ ]*\(.*\)/s%@LIBS[@]%\1%/p' \ -e '/^LIBM=/s/^LIBM=[ ]*\(.*\)/s%@LIBM[@]%\1%/p' \ -e '/^LIBC=/s/^LIBC=[ ]*\(.*\)/s%@LIBC[@]%\1%/p' \ -e '/^RANLIB=/s/^RANLIB=[ ]*\(.*\)/s%@RANLIB[@]%\1%/p' \ -e '/^MACHDEP=/s/^MACHDEP=[ ]*\(.*\)/s%@MACHDEP[@]%\1%/p' \ -e '/^SO=/s/^SO=[ ]*\(.*\)/s%@SO[@]%\1%/p' \ -e '/^LDSHARED=/s/^LDSHARED=[ ]*\(.*\)/s%@LDSHARED[@]%\1%/p' \ -e '/^CCSHARED=/s/^CCSHARED=[ ]*\(.*\)/s%@CCSHARED[@]%\1%/p' \ -e '/^SGI_ABI=/s/^SGI_ABI=[ ]*\(.*\)/s%@SGI_ABI[@]%\1%/p' \ -e '/^$L=/s/^$L=[ ]*\(.*\)/s%@$L[@]%\1%/p' \ -e '/^$P=/s/^$P=\(.*\)/s%^$P=.*%$P=\1%/p' \ -e '/^$E=/s/^$E=\(.*\)/s%^$E=.*%$E=\1%/p' \ $(MAKEFILE) >sedscript echo "/^CXX=/d" >>sedscript echo "/^installdir=/s%=.*%= $(installdir)%" >>sedscript echo "/^exec_installdir=/s%=.*%=$(exec_installdir)%" >>sedscript echo "/^srcdir=/s%=.*%= $(srcdir)%" >>sedscript echo "/^VPATH=/s%=.*%= $(VPATH)%" >>sedscript echo "/^LINKPATH=/s%=.*%= $(LINKPATH)%" >>sedscript echo "/^BASELIB=/s%=.*%= $(BASELIB)%" >>sedscript echo "/^BASESETUP=/s%=.*%= $(BASESETUP)%" >>sedscript # Bootstrap target boot: clobber VERSION=`$(PYTHON) -c "import sys; print sys.version[:3]"`; \ installdir=`$(PYTHON) -c "import sys; print sys.prefix"`; \ exec_installdir=`$(PYTHON) -c "import sys; print sys.exec_prefix"`; \ $(MAKE) -f $(srcdir)/Makefile.pre.in VPATH=$(VPATH) srcdir=$(srcdir) \ VERSION=$$VERSION \ installdir=$$installdir \ exec_installdir=$$exec_installdir \ Makefile # Handy target to remove intermediate files and backups clean: -rm -f *.o *~ # Handy target to remove everything that is easily regenerated clobber: clean -rm -f *.a tags TAGS config.c Makefile.pre $(TARGET) sedscript -rm -f *.so *.sl so_locations # Handy target to remove everything you don't want to distribute distclean: clobber -rm -f Makefile Setup # Rules appended by makedepend x.o: $(srcdir)/x.cpp; $(CXX) $(CCSHARED) $(CPPFLAGS) $(SHITE1) $(SHITE2) $(CFLAGS) -c $(srcdir)/x.cpp x$(SO): x.o; $(LDSHARED) x.o $(CPPFLAGS) $(SHITE1) (SHITE2) ------------------------------------------------------- Date: 2000-Dec-06 13:14 By: gvanrossum Comment: No need to include the entire Makefile -- just the like that says "CXX=" would have been enough! You didn't follow my instructions. You must run ./configure --with-cxx=g++. Try again! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102691&group_id=5470 From noreply@sourceforge.net Wed Dec 6 21:44:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 13:44:01 -0800 Subject: [Patches] [Patch #102106] sys._getframe() for getting the current stack frame Message-ID: <200012062144.NAA31463@sf-web2.i.sourceforge.net> Patch #102106 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: bwarsaw Assigned to : bwarsaw Summary: sys._getframe() for getting the current stack frame Follow-Ups: Date: 2000-Oct-24 20:43 By: bwarsaw Comment: This patch adds a function to the sys module which will return a frame object. By default, it returns the frame object of the current stack frame, but an optional integer argument can be supplied to retrieve any frame higher up the stack. If the integer is greater than the depth of the stack, a ValueError is raised. ------------------------------------------------------- Date: 2000-Oct-24 21:43 By: fdrake Comment: My only comment on the docs (both docstring and LaTeX) is that it should say "ValueError is raised" rather than "a ValueError is raised" (drop the "a"). Otherwise looks good; I've not run it through the formatting. ------------------------------------------------------- Date: 2000-Oct-24 21:51 By: bwarsaw Comment: Good point. Patch updated. Thanks. ------------------------------------------------------- Date: 2000-Oct-24 21:54 By: bwarsaw Comment: Oops, fixed one small typo. ------------------------------------------------------- Date: 2000-Oct-26 07:15 By: gvanrossum Comment: The docstring and docs should say that the default depth is zero. They should also mention that this is for internal use only. Can you implement this in Jython too? ------------------------------------------------------- Date: 2000-Dec-06 01:24 By: ping Comment: It's a small point, but i'd much prefer the function to be called sys.getframe() rather than sys._getframe(). There aren't any other functions in sys that begin with an underscore, and it's understood that routines in sys manipulate the Python interpreter system anyway (such as getrefcount or exc_info). This routine isn't private within sys; it's exported by sys, so it should be called sys.getframe(). ------------------------------------------------------- Date: 2000-Dec-06 09:48 By: gvanrossum Comment: I disagree with Ping. The function needs to be clearly marked as non-public-API -- it's an interface that should be used only to implement a few blessed higher-level library modules. It differs from getrefcount(), which is harmless, and exc_info(), which is intended to be used in preference to exc_type etc. (in order to be thread-safe). BTW, I'm accepting the patch -- I don't know why it hasn't been checked in yet. (The doc changes suggested should still be made.) ------------------------------------------------------- Date: 2000-Dec-06 13:44 By: bwarsaw Comment: Checking in now. sysmodule.c 2.79 libsys.tex 1.43 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102106&group_id=5470 From noreply@sourceforge.net Wed Dec 6 22:20:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 14:20:08 -0800 Subject: [Patches] [Patch #102665] Different credit text for jython Message-ID: <200012062220.OAA32202@sf-web2.i.sourceforge.net> Patch #102665 has been updated. Project: python Category: Modules Status: Closed Submitted by: bckfnn Assigned to : bwarsaw Summary: Different credit text for jython Follow-Ups: Date: 2000-Dec-05 13:19 By: bckfnn Comment: This patch will show a different credit text when the site.py is used with jython. An other fine solution could be to read the credit text from a file, similar to the LICENSE file. ------------------------------------------------------- Date: 2000-Dec-05 15:49 By: gvanrossum Comment: Barry, please check this in. ------------------------------------------------------- Date: 2000-Dec-06 14:20 By: bwarsaw Comment: Applied to site.py 1.21 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102665&group_id=5470 From noreply@sourceforge.net Wed Dec 6 23:23:56 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 15:23:56 -0800 Subject: [Patches] [Patch #102691] Use CXX in Misc/Makefile.pre.in and Modules/makesetup Message-ID: <200012062323.PAA11978@sf-web1.i.sourceforge.net> Patch #102691 has been updated. Project: python Category: Build Status: Open Submitted by: gvanrossum Assigned to : gvanrossum Summary: Use CXX in Misc/Makefile.pre.in and Modules/makesetup Follow-Ups: Date: 2000-Dec-06 12:30 By: gvanrossum Comment: Hopefully this fixes this bug: http://sourceforge.net/bugs/?func=detailbug&bug_id=124478&group_id=5470 Waiting for the bug reporter's feedback. ------------------------------------------------------- Date: 2000-Dec-06 13:01 By: rossrizer Comment: I was so sure that it would work, I almost didn't test it. But I did: cd /usr/local/src/Python-2.0 patch -p0 102691.patch make clean ./configure make make install cp Misc/Makefile.pre.in mypythonmoduledir cd mypythonmoduledir make -f Makefile.pre.in make still broke: # Generated automatically from Makefile.pre by makesetup. # Generated automatically from Makefile.pre.in by sedscript. # Universal Unix Makefile for Python extensions # ============================================= # Short Instructions # ------------------ # 1. Build and install Python (1.5 or newer). # 2. "make -f Makefile.pre.in boot" # 3. "make" # You should now have a shared library. # Long Instructions # ----------------- # Build *and install* the basic Python 1.5 distribution. See the # Python README for instructions. (This version of Makefile.pre.in # only withs with Python 1.5, alpha 3 or newer.) # Create a file Setup.in for your extension. This file follows the # format of the Modules/Setup.in file; see the instructions there. # For a simple module called "spam" on file "spammodule.c", it can # contain a single line: # spam spammodule.c # You can build as many modules as you want in the same directory -- # just have a separate line for each of them in the Setup.in file. # If you want to build your extension as a shared library, insert a # line containing just the string # *shared* # at the top of your Setup.in file. # Note that the build process copies Setup.in to Setup, and then works # with Setup. It doesn't overwrite Setup when Setup.in is changed, so # while you're in the process of debugging your Setup.in file, you may # want to edit Setup instead, and copy it back to Setup.in later. # (All this is done so you can distribute your extension easily and # someone else can select the modules they actually want to build by # commenting out lines in the Setup file, without editing the # original. Editing Setup is also used to specify nonstandard # locations for include or library files.) # Copy this file (Misc/Makefile.pre.in) to the directory containing # your extension. # Run "make -f Makefile.pre.in boot". This creates Makefile # (producing Makefile.pre and sedscript as intermediate files) and # config.c, incorporating the values for sys.prefix, sys.exec_prefix # and sys.version from the installed Python binary. For this to work, # the python binary must be on your path. If this fails, try # make -f Makefile.pre.in Makefile VERSION=1.5 installdir= # where is the prefix used to install Python for installdir # (and possibly similar for exec_installdir=). # Note: "make boot" implies "make clobber" -- it assumes that when you # bootstrap you may have changed platforms so it removes all previous # output files. # If you are building your extension as a shared library (your # Setup.in file starts with *shared*), run "make" or "make sharedmods" # to build the shared library files. If you are building a statically # linked Python binary (the only solution of your platform doesn't # support shared libraries, and sometimes handy if you want to # distribute or install the resulting Python binary), run "make # python". # Note: Each time you edit Makefile.pre.in or Setup, you must run # "make Makefile" before running "make". # Hint: if you want to use VPATH, you can start in an empty # subdirectory and say (e.g.): # make -f ../Makefile.pre.in boot srcdir=.. VPATH=.. # === Bootstrap variables (edited through "make boot") === # The prefix used by "make inclinstall libainstall" of core python installdir= /usr/local # The exec_prefix used by the same exec_installdir=/usr/local # Source directory and VPATH in case you want to use VPATH. # (You will have to edit these two lines yourself -- there is no # automatic support as the Makefile is not generated by # config.status.) srcdir= . VPATH= . # === Variables that you may want to customize (rarely) === # (Static) build target TARGET= python # Installed python binary (used only by boot target) PYTHON= python # Add more -I and -D options here CFLAGS= $(OPT) -I$(INCLUDEPY) -I$(EXECINCLUDEPY) $(DEFS) # These two variables can be set in Setup to merge extensions. # See example[23]. BASELIB= BASESETUP= # === Variables set by makesetup === MODOBJS= MODLIBS= $(LOCALMODLIBS) $(BASEMODLIBS) # === Definitions added by makesetup === LOCALMODLIBS= BASEMODLIBS= SHAREDMODS= simumodule$(SO) TKPATH=:lib-tk GLHACK=-Dclear=__GLclear PYTHONPATH=$(COREPYTHONPATH) COREPYTHONPATH=$(DESTPATH)$(SITEPATH)$(TESTPATH)$(MACHDEPPATH)$(TKPATH) MACHDEPPATH=:plat-$(MACHDEP) TESTPATH= SITEPATH= DESTPATH= MACHDESTLIB=$(BINLIBDEST) DESTLIB=$(LIBDEST) SHITE2=-Wl,--no-whole-archive SHITE1=-Wl,--whole-archive CPPFLAGS= -Wall -D_DEBUG -D__WXGTK__ -I.. -I../spoon -I../simulator # === Variables from configure (through sedscript) === VERSION= 2.0 CC= gcc LINKCC= $(PURIFY) $(CC) SGI_ABI= OPT= -g -O2 -Wall -Wstrict-prototypes LDFLAGS= LDLAST= DEFS= -DHAVE_CONFIG_H LIBS= -lpthread -ldl -lutil LIBM= -lm LIBC= RANLIB= ranlib MACHDEP= linux2 SO= .so LDSHARED= gcc -shared CCSHARED= -fpic LINKFORSHARED= -Xlinker -export-dynamic CXX= # Install prefix for architecture-independent files prefix= /usr/local # Install prefix for architecture-dependent files exec_prefix= ${prefix} # Uncomment the following two lines for AIX #LINKCC= $(LIBPL)/makexp_aix $(LIBPL)/python.exp "" $(LIBRARY); $(PURIFY) $(CC) #LDSHARED= $(LIBPL)/ld_so_aix $(CC) -bI:$(LIBPL)/python.exp # === Fixed definitions === # Shell used by make (some versions default to the login shell, which is bad) SHELL= /bin/sh # Expanded directories BINDIR= $(exec_installdir)/bin LIBDIR= $(exec_prefix)/lib MANDIR= $(installdir)/man INCLUDEDIR= $(installdir)/include SCRIPTDIR= $(prefix)/lib # Detailed destination directories BINLIBDEST= $(LIBDIR)/python$(VERSION) LIBDEST= $(SCRIPTDIR)/python$(VERSION) INCLUDEPY= $(INCLUDEDIR)/python$(VERSION) EXECINCLUDEPY= $(exec_installdir)/include/python$(VERSION) LIBP= $(exec_installdir)/lib/python$(VERSION) DESTSHARED= $(BINLIBDEST)/site-packages LIBPL= $(LIBP)/config PYTHONLIBS= $(LIBPL)/libpython$(VERSION).a MAKESETUP= $(LIBPL)/makesetup MAKEFILE= $(LIBPL)/Makefile CONFIGC= $(LIBPL)/config.c CONFIGCIN= $(LIBPL)/config.c.in SETUP= $(LIBPL)/Setup.config $(LIBPL)/Setup.local $(LIBPL)/Setup SYSLIBS= $(LIBM) $(LIBC) ADDOBJS= $(LIBPL)/python.o config.o # Portable install script (configure doesn't always guess right) INSTALL= $(LIBPL)/install-sh -c # Shared libraries must be installed with executable mode on some systems; # rather than figuring out exactly which, we always give them executable mode. # Also, making them read-only seems to be a good idea... INSTALL_SHARED= ${INSTALL} -m 555 # === Fixed rules === # Default target. This builds shared libraries only default: sharedmods # Build everything all: static sharedmods # Build shared libraries from our extension modules sharedmods: $(SHAREDMODS) # Build a static Python binary containing our extension modules static: $(TARGET) $(TARGET): $(ADDOBJS) lib.a $(PYTHONLIBS) Makefile $(BASELIB) $(LINKCC) $(LDFLAGS) $(LINKFORSHARED) \ $(ADDOBJS) lib.a $(PYTHONLIBS) \ $(LINKPATH) $(BASELIB) $(MODLIBS) $(LIBS) $(SYSLIBS) \ -o $(TARGET) $(LDLAST) install: sharedmods if test ! -d $(DESTSHARED) ; then \ mkdir $(DESTSHARED) ; else true ; fi -for i in X $(SHAREDMODS); do \ if test $$i != X; \ then $(INSTALL_SHARED) $$i $(DESTSHARED)/$$i; \ fi; \ done # Build the library containing our extension modules lib.a: $(MODOBJS) -rm -f lib.a ar cr lib.a $(MODOBJS) -$(RANLIB) lib.a # This runs makesetup *twice* to use the BASESETUP definition from Setup config.c Makefile: Makefile.pre Setup $(BASESETUP) $(MAKESETUP) $(MAKESETUP) \ -m Makefile.pre -c $(CONFIGCIN) Setup -n $(BASESETUP) $(SETUP) $(MAKE) -f Makefile do-it-again # Internal target to run makesetup for the second time do-it-again: $(MAKESETUP) \ -m Makefile.pre -c $(CONFIGCIN) Setup -n $(BASESETUP) $(SETUP) # Make config.o from the config.c created by makesetup config.o: config.c $(CC) $(CFLAGS) -c config.c # Setup is copied from Setup.in *only* if it doesn't yet exist Setup: cp $(srcdir)/Setup.in Setup # Make the intermediate Makefile.pre from Makefile.pre.in Makefile.pre: Makefile.pre.in sedscript sed -f sedscript $(srcdir)/Makefile.pre.in >Makefile.pre # Shortcuts to make the sed arguments on one line P=prefix E=exec_prefix H=Generated automatically from Makefile.pre.in by sedscript. L=LINKFORSHARED # Make the sed script used to create Makefile.pre from Makefile.pre.in sedscript: $(MAKEFILE) sed -n \ -e '1s/.*/1i\\/p' \ -e '2s%.*%# $H%p' \ -e '/^VERSION=/s/^VERSION=[ ]*\(.*\)/s%@VERSION[@]%\1%/p' \ -e '/^CC=/s/^CC=[ ]*\(.*\)/s%@CC[@]%\1%/p' \ -e '/^CXX=/s/^CXX=[ ]*\(.*\)/s%#@SET_CXX[@]%CXX=\1%/p' \ -e '/^LINKCC=/s/^LINKCC=[ ]*\(.*\)/s%@LINKCC[@]%\1%/p' \ -e '/^OPT=/s/^OPT=[ ]*\(.*\)/s%@OPT[@]%\1%/p' \ -e '/^LDFLAGS=/s/^LDFLAGS=[ ]*\(.*\)/s%@LDFLAGS[@]%\1%/p' \ -e '/^LDLAST=/s/^LDLAST=[ ]*\(.*\)/s%@LDLAST[@]%\1%/p' \ -e '/^DEFS=/s/^DEFS=[ ]*\(.*\)/s%@DEFS[@]%\1%/p' \ -e '/^LIBS=/s/^LIBS=[ ]*\(.*\)/s%@LIBS[@]%\1%/p' \ -e '/^LIBM=/s/^LIBM=[ ]*\(.*\)/s%@LIBM[@]%\1%/p' \ -e '/^LIBC=/s/^LIBC=[ ]*\(.*\)/s%@LIBC[@]%\1%/p' \ -e '/^RANLIB=/s/^RANLIB=[ ]*\(.*\)/s%@RANLIB[@]%\1%/p' \ -e '/^MACHDEP=/s/^MACHDEP=[ ]*\(.*\)/s%@MACHDEP[@]%\1%/p' \ -e '/^SO=/s/^SO=[ ]*\(.*\)/s%@SO[@]%\1%/p' \ -e '/^LDSHARED=/s/^LDSHARED=[ ]*\(.*\)/s%@LDSHARED[@]%\1%/p' \ -e '/^CCSHARED=/s/^CCSHARED=[ ]*\(.*\)/s%@CCSHARED[@]%\1%/p' \ -e '/^SGI_ABI=/s/^SGI_ABI=[ ]*\(.*\)/s%@SGI_ABI[@]%\1%/p' \ -e '/^$L=/s/^$L=[ ]*\(.*\)/s%@$L[@]%\1%/p' \ -e '/^$P=/s/^$P=\(.*\)/s%^$P=.*%$P=\1%/p' \ -e '/^$E=/s/^$E=\(.*\)/s%^$E=.*%$E=\1%/p' \ $(MAKEFILE) >sedscript echo "/^CXX=/d" >>sedscript echo "/^installdir=/s%=.*%= $(installdir)%" >>sedscript echo "/^exec_installdir=/s%=.*%=$(exec_installdir)%" >>sedscript echo "/^srcdir=/s%=.*%= $(srcdir)%" >>sedscript echo "/^VPATH=/s%=.*%= $(VPATH)%" >>sedscript echo "/^LINKPATH=/s%=.*%= $(LINKPATH)%" >>sedscript echo "/^BASELIB=/s%=.*%= $(BASELIB)%" >>sedscript echo "/^BASESETUP=/s%=.*%= $(BASESETUP)%" >>sedscript # Bootstrap target boot: clobber VERSION=`$(PYTHON) -c "import sys; print sys.version[:3]"`; \ installdir=`$(PYTHON) -c "import sys; print sys.prefix"`; \ exec_installdir=`$(PYTHON) -c "import sys; print sys.exec_prefix"`; \ $(MAKE) -f $(srcdir)/Makefile.pre.in VPATH=$(VPATH) srcdir=$(srcdir) \ VERSION=$$VERSION \ installdir=$$installdir \ exec_installdir=$$exec_installdir \ Makefile # Handy target to remove intermediate files and backups clean: -rm -f *.o *~ # Handy target to remove everything that is easily regenerated clobber: clean -rm -f *.a tags TAGS config.c Makefile.pre $(TARGET) sedscript -rm -f *.so *.sl so_locations # Handy target to remove everything you don't want to distribute distclean: clobber -rm -f Makefile Setup # Rules appended by makedepend x.o: $(srcdir)/x.cpp; $(CXX) $(CCSHARED) $(CPPFLAGS) $(SHITE1) $(SHITE2) $(CFLAGS) -c $(srcdir)/x.cpp x$(SO): x.o; $(LDSHARED) x.o $(CPPFLAGS) $(SHITE1) (SHITE2) ------------------------------------------------------- Date: 2000-Dec-06 13:14 By: gvanrossum Comment: No need to include the entire Makefile -- just the like that says "CXX=" would have been enough! You didn't follow my instructions. You must run ./configure --with-cxx=g++. Try again! ------------------------------------------------------- Date: 2000-Dec-06 15:23 By: rossrizer Comment: Ok! That fixed it. Thanks! But will every RH7 user need to know to add --with-gcc=g++? That's a big drag, eh? cd /usr/local/src/Python-2.0 patch -p0 102691.patch make clean ./configure --with-gcc=g++ make make install cp Misc/Makefile.pre.in mypythonmoduledir cd mypythonmoduledir make -f Makefile.pre.in make Success! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102691&group_id=5470 From noreply@sourceforge.net Wed Dec 6 23:47:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 15:47:21 -0800 Subject: [Patches] [Patch #102691] Use CXX in Misc/Makefile.pre.in and Modules/makesetup Message-ID: <200012062347.PAA01261@sf-web2.i.sourceforge.net> Patch #102691 has been updated. Project: python Category: Build Status: Closed Submitted by: gvanrossum Assigned to : gvanrossum Summary: Use CXX in Misc/Makefile.pre.in and Modules/makesetup Follow-Ups: Date: 2000-Dec-06 12:30 By: gvanrossum Comment: Hopefully this fixes this bug: http://sourceforge.net/bugs/?func=detailbug&bug_id=124478&group_id=5470 Waiting for the bug reporter's feedback. ------------------------------------------------------- Date: 2000-Dec-06 13:01 By: rossrizer Comment: I was so sure that it would work, I almost didn't test it. But I did: cd /usr/local/src/Python-2.0 patch -p0 102691.patch make clean ./configure make make install cp Misc/Makefile.pre.in mypythonmoduledir cd mypythonmoduledir make -f Makefile.pre.in make still broke: # Generated automatically from Makefile.pre by makesetup. # Generated automatically from Makefile.pre.in by sedscript. # Universal Unix Makefile for Python extensions # ============================================= # Short Instructions # ------------------ # 1. Build and install Python (1.5 or newer). # 2. "make -f Makefile.pre.in boot" # 3. "make" # You should now have a shared library. # Long Instructions # ----------------- # Build *and install* the basic Python 1.5 distribution. See the # Python README for instructions. (This version of Makefile.pre.in # only withs with Python 1.5, alpha 3 or newer.) # Create a file Setup.in for your extension. This file follows the # format of the Modules/Setup.in file; see the instructions there. # For a simple module called "spam" on file "spammodule.c", it can # contain a single line: # spam spammodule.c # You can build as many modules as you want in the same directory -- # just have a separate line for each of them in the Setup.in file. # If you want to build your extension as a shared library, insert a # line containing just the string # *shared* # at the top of your Setup.in file. # Note that the build process copies Setup.in to Setup, and then works # with Setup. It doesn't overwrite Setup when Setup.in is changed, so # while you're in the process of debugging your Setup.in file, you may # want to edit Setup instead, and copy it back to Setup.in later. # (All this is done so you can distribute your extension easily and # someone else can select the modules they actually want to build by # commenting out lines in the Setup file, without editing the # original. Editing Setup is also used to specify nonstandard # locations for include or library files.) # Copy this file (Misc/Makefile.pre.in) to the directory containing # your extension. # Run "make -f Makefile.pre.in boot". This creates Makefile # (producing Makefile.pre and sedscript as intermediate files) and # config.c, incorporating the values for sys.prefix, sys.exec_prefix # and sys.version from the installed Python binary. For this to work, # the python binary must be on your path. If this fails, try # make -f Makefile.pre.in Makefile VERSION=1.5 installdir= # where is the prefix used to install Python for installdir # (and possibly similar for exec_installdir=). # Note: "make boot" implies "make clobber" -- it assumes that when you # bootstrap you may have changed platforms so it removes all previous # output files. # If you are building your extension as a shared library (your # Setup.in file starts with *shared*), run "make" or "make sharedmods" # to build the shared library files. If you are building a statically # linked Python binary (the only solution of your platform doesn't # support shared libraries, and sometimes handy if you want to # distribute or install the resulting Python binary), run "make # python". # Note: Each time you edit Makefile.pre.in or Setup, you must run # "make Makefile" before running "make". # Hint: if you want to use VPATH, you can start in an empty # subdirectory and say (e.g.): # make -f ../Makefile.pre.in boot srcdir=.. VPATH=.. # === Bootstrap variables (edited through "make boot") === # The prefix used by "make inclinstall libainstall" of core python installdir= /usr/local # The exec_prefix used by the same exec_installdir=/usr/local # Source directory and VPATH in case you want to use VPATH. # (You will have to edit these two lines yourself -- there is no # automatic support as the Makefile is not generated by # config.status.) srcdir= . VPATH= . # === Variables that you may want to customize (rarely) === # (Static) build target TARGET= python # Installed python binary (used only by boot target) PYTHON= python # Add more -I and -D options here CFLAGS= $(OPT) -I$(INCLUDEPY) -I$(EXECINCLUDEPY) $(DEFS) # These two variables can be set in Setup to merge extensions. # See example[23]. BASELIB= BASESETUP= # === Variables set by makesetup === MODOBJS= MODLIBS= $(LOCALMODLIBS) $(BASEMODLIBS) # === Definitions added by makesetup === LOCALMODLIBS= BASEMODLIBS= SHAREDMODS= simumodule$(SO) TKPATH=:lib-tk GLHACK=-Dclear=__GLclear PYTHONPATH=$(COREPYTHONPATH) COREPYTHONPATH=$(DESTPATH)$(SITEPATH)$(TESTPATH)$(MACHDEPPATH)$(TKPATH) MACHDEPPATH=:plat-$(MACHDEP) TESTPATH= SITEPATH= DESTPATH= MACHDESTLIB=$(BINLIBDEST) DESTLIB=$(LIBDEST) SHITE2=-Wl,--no-whole-archive SHITE1=-Wl,--whole-archive CPPFLAGS= -Wall -D_DEBUG -D__WXGTK__ -I.. -I../spoon -I../simulator # === Variables from configure (through sedscript) === VERSION= 2.0 CC= gcc LINKCC= $(PURIFY) $(CC) SGI_ABI= OPT= -g -O2 -Wall -Wstrict-prototypes LDFLAGS= LDLAST= DEFS= -DHAVE_CONFIG_H LIBS= -lpthread -ldl -lutil LIBM= -lm LIBC= RANLIB= ranlib MACHDEP= linux2 SO= .so LDSHARED= gcc -shared CCSHARED= -fpic LINKFORSHARED= -Xlinker -export-dynamic CXX= # Install prefix for architecture-independent files prefix= /usr/local # Install prefix for architecture-dependent files exec_prefix= ${prefix} # Uncomment the following two lines for AIX #LINKCC= $(LIBPL)/makexp_aix $(LIBPL)/python.exp "" $(LIBRARY); $(PURIFY) $(CC) #LDSHARED= $(LIBPL)/ld_so_aix $(CC) -bI:$(LIBPL)/python.exp # === Fixed definitions === # Shell used by make (some versions default to the login shell, which is bad) SHELL= /bin/sh # Expanded directories BINDIR= $(exec_installdir)/bin LIBDIR= $(exec_prefix)/lib MANDIR= $(installdir)/man INCLUDEDIR= $(installdir)/include SCRIPTDIR= $(prefix)/lib # Detailed destination directories BINLIBDEST= $(LIBDIR)/python$(VERSION) LIBDEST= $(SCRIPTDIR)/python$(VERSION) INCLUDEPY= $(INCLUDEDIR)/python$(VERSION) EXECINCLUDEPY= $(exec_installdir)/include/python$(VERSION) LIBP= $(exec_installdir)/lib/python$(VERSION) DESTSHARED= $(BINLIBDEST)/site-packages LIBPL= $(LIBP)/config PYTHONLIBS= $(LIBPL)/libpython$(VERSION).a MAKESETUP= $(LIBPL)/makesetup MAKEFILE= $(LIBPL)/Makefile CONFIGC= $(LIBPL)/config.c CONFIGCIN= $(LIBPL)/config.c.in SETUP= $(LIBPL)/Setup.config $(LIBPL)/Setup.local $(LIBPL)/Setup SYSLIBS= $(LIBM) $(LIBC) ADDOBJS= $(LIBPL)/python.o config.o # Portable install script (configure doesn't always guess right) INSTALL= $(LIBPL)/install-sh -c # Shared libraries must be installed with executable mode on some systems; # rather than figuring out exactly which, we always give them executable mode. # Also, making them read-only seems to be a good idea... INSTALL_SHARED= ${INSTALL} -m 555 # === Fixed rules === # Default target. This builds shared libraries only default: sharedmods # Build everything all: static sharedmods # Build shared libraries from our extension modules sharedmods: $(SHAREDMODS) # Build a static Python binary containing our extension modules static: $(TARGET) $(TARGET): $(ADDOBJS) lib.a $(PYTHONLIBS) Makefile $(BASELIB) $(LINKCC) $(LDFLAGS) $(LINKFORSHARED) \ $(ADDOBJS) lib.a $(PYTHONLIBS) \ $(LINKPATH) $(BASELIB) $(MODLIBS) $(LIBS) $(SYSLIBS) \ -o $(TARGET) $(LDLAST) install: sharedmods if test ! -d $(DESTSHARED) ; then \ mkdir $(DESTSHARED) ; else true ; fi -for i in X $(SHAREDMODS); do \ if test $$i != X; \ then $(INSTALL_SHARED) $$i $(DESTSHARED)/$$i; \ fi; \ done # Build the library containing our extension modules lib.a: $(MODOBJS) -rm -f lib.a ar cr lib.a $(MODOBJS) -$(RANLIB) lib.a # This runs makesetup *twice* to use the BASESETUP definition from Setup config.c Makefile: Makefile.pre Setup $(BASESETUP) $(MAKESETUP) $(MAKESETUP) \ -m Makefile.pre -c $(CONFIGCIN) Setup -n $(BASESETUP) $(SETUP) $(MAKE) -f Makefile do-it-again # Internal target to run makesetup for the second time do-it-again: $(MAKESETUP) \ -m Makefile.pre -c $(CONFIGCIN) Setup -n $(BASESETUP) $(SETUP) # Make config.o from the config.c created by makesetup config.o: config.c $(CC) $(CFLAGS) -c config.c # Setup is copied from Setup.in *only* if it doesn't yet exist Setup: cp $(srcdir)/Setup.in Setup # Make the intermediate Makefile.pre from Makefile.pre.in Makefile.pre: Makefile.pre.in sedscript sed -f sedscript $(srcdir)/Makefile.pre.in >Makefile.pre # Shortcuts to make the sed arguments on one line P=prefix E=exec_prefix H=Generated automatically from Makefile.pre.in by sedscript. L=LINKFORSHARED # Make the sed script used to create Makefile.pre from Makefile.pre.in sedscript: $(MAKEFILE) sed -n \ -e '1s/.*/1i\\/p' \ -e '2s%.*%# $H%p' \ -e '/^VERSION=/s/^VERSION=[ ]*\(.*\)/s%@VERSION[@]%\1%/p' \ -e '/^CC=/s/^CC=[ ]*\(.*\)/s%@CC[@]%\1%/p' \ -e '/^CXX=/s/^CXX=[ ]*\(.*\)/s%#@SET_CXX[@]%CXX=\1%/p' \ -e '/^LINKCC=/s/^LINKCC=[ ]*\(.*\)/s%@LINKCC[@]%\1%/p' \ -e '/^OPT=/s/^OPT=[ ]*\(.*\)/s%@OPT[@]%\1%/p' \ -e '/^LDFLAGS=/s/^LDFLAGS=[ ]*\(.*\)/s%@LDFLAGS[@]%\1%/p' \ -e '/^LDLAST=/s/^LDLAST=[ ]*\(.*\)/s%@LDLAST[@]%\1%/p' \ -e '/^DEFS=/s/^DEFS=[ ]*\(.*\)/s%@DEFS[@]%\1%/p' \ -e '/^LIBS=/s/^LIBS=[ ]*\(.*\)/s%@LIBS[@]%\1%/p' \ -e '/^LIBM=/s/^LIBM=[ ]*\(.*\)/s%@LIBM[@]%\1%/p' \ -e '/^LIBC=/s/^LIBC=[ ]*\(.*\)/s%@LIBC[@]%\1%/p' \ -e '/^RANLIB=/s/^RANLIB=[ ]*\(.*\)/s%@RANLIB[@]%\1%/p' \ -e '/^MACHDEP=/s/^MACHDEP=[ ]*\(.*\)/s%@MACHDEP[@]%\1%/p' \ -e '/^SO=/s/^SO=[ ]*\(.*\)/s%@SO[@]%\1%/p' \ -e '/^LDSHARED=/s/^LDSHARED=[ ]*\(.*\)/s%@LDSHARED[@]%\1%/p' \ -e '/^CCSHARED=/s/^CCSHARED=[ ]*\(.*\)/s%@CCSHARED[@]%\1%/p' \ -e '/^SGI_ABI=/s/^SGI_ABI=[ ]*\(.*\)/s%@SGI_ABI[@]%\1%/p' \ -e '/^$L=/s/^$L=[ ]*\(.*\)/s%@$L[@]%\1%/p' \ -e '/^$P=/s/^$P=\(.*\)/s%^$P=.*%$P=\1%/p' \ -e '/^$E=/s/^$E=\(.*\)/s%^$E=.*%$E=\1%/p' \ $(MAKEFILE) >sedscript echo "/^CXX=/d" >>sedscript echo "/^installdir=/s%=.*%= $(installdir)%" >>sedscript echo "/^exec_installdir=/s%=.*%=$(exec_installdir)%" >>sedscript echo "/^srcdir=/s%=.*%= $(srcdir)%" >>sedscript echo "/^VPATH=/s%=.*%= $(VPATH)%" >>sedscript echo "/^LINKPATH=/s%=.*%= $(LINKPATH)%" >>sedscript echo "/^BASELIB=/s%=.*%= $(BASELIB)%" >>sedscript echo "/^BASESETUP=/s%=.*%= $(BASESETUP)%" >>sedscript # Bootstrap target boot: clobber VERSION=`$(PYTHON) -c "import sys; print sys.version[:3]"`; \ installdir=`$(PYTHON) -c "import sys; print sys.prefix"`; \ exec_installdir=`$(PYTHON) -c "import sys; print sys.exec_prefix"`; \ $(MAKE) -f $(srcdir)/Makefile.pre.in VPATH=$(VPATH) srcdir=$(srcdir) \ VERSION=$$VERSION \ installdir=$$installdir \ exec_installdir=$$exec_installdir \ Makefile # Handy target to remove intermediate files and backups clean: -rm -f *.o *~ # Handy target to remove everything that is easily regenerated clobber: clean -rm -f *.a tags TAGS config.c Makefile.pre $(TARGET) sedscript -rm -f *.so *.sl so_locations # Handy target to remove everything you don't want to distribute distclean: clobber -rm -f Makefile Setup # Rules appended by makedepend x.o: $(srcdir)/x.cpp; $(CXX) $(CCSHARED) $(CPPFLAGS) $(SHITE1) $(SHITE2) $(CFLAGS) -c $(srcdir)/x.cpp x$(SO): x.o; $(LDSHARED) x.o $(CPPFLAGS) $(SHITE1) (SHITE2) ------------------------------------------------------- Date: 2000-Dec-06 13:14 By: gvanrossum Comment: No need to include the entire Makefile -- just the like that says "CXX=" would have been enough! You didn't follow my instructions. You must run ./configure --with-cxx=g++. Try again! ------------------------------------------------------- Date: 2000-Dec-06 15:23 By: rossrizer Comment: Ok! That fixed it. Thanks! But will every RH7 user need to know to add --with-gcc=g++? That's a big drag, eh? cd /usr/local/src/Python-2.0 patch -p0 102691.patch make clean ./configure --with-gcc=g++ make make install cp Misc/Makefile.pre.in mypythonmoduledir cd mypythonmoduledir make -f Makefile.pre.in make Success! ------------------------------------------------------- Date: 2000-Dec-06 15:47 By: gvanrossum Comment: You're right. I'll enter a separate bug report indicating that the C++ compiler could be guessed by the configure script. Closing this patch. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102691&group_id=5470 From noreply@sourceforge.net Thu Dec 7 01:48:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 17:48:59 -0800 Subject: [Patches] [Patch #102698] Fix for StreamReader bug Message-ID: <200012070148.RAA03130@sf-web2.i.sourceforge.net> Patch #102698 has been updated. Project: python Category: None Status: Open Submitted by: akuchling Assigned to : Nobody Summary: Fix for StreamReader bug ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102698&group_id=5470 From noreply@sourceforge.net Thu Dec 7 01:53:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Dec 2000 17:53:55 -0800 Subject: [Patches] [Patch #102698] Fix for StreamReader bug Message-ID: <200012070153.RAA03248@sf-web2.i.sourceforge.net> Patch #102698 has been updated. Project: python Category: library Status: Open Submitted by: akuchling Assigned to : bwarsaw Summary: Fix for StreamReader bug Follow-Ups: Date: 2000-Dec-06 17:53 By: akuchling Comment: Fix for a bug reported in c.l.p by Wade Leftwich: StreamReader ignores the errors parameter passed to its constructor: import codecs from StringIO import StringIO encode, decode, reader, writer = codecs.lookup('UTF-8') s = 'ab\346c' print decode(s, 'replace') # outputs (u'ab\uFFFDc', 4) fh = StringIO(s) sr = reader(fh, 'replace') print repr(sr.read()) # dies with a UnicodeError exception Randomly assigning to Barry -- this just needs a quick sanity check ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102698&group_id=5470 From noreply@sourceforge.net Thu Dec 7 09:14:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 7 Dec 2000 01:14:21 -0800 Subject: [Patches] [Patch #102698] Fix for StreamReader bug Message-ID: <200012070914.BAA05191@sf-web3.vaspecialprojects.com> Patch #102698 has been updated. Project: python Category: library Status: Open Submitted by: akuchling Assigned to : bwarsaw Summary: Fix for StreamReader bug Follow-Ups: Date: 2000-Dec-06 17:53 By: akuchling Comment: Fix for a bug reported in c.l.p by Wade Leftwich: StreamReader ignores the errors parameter passed to its constructor: import codecs from StringIO import StringIO encode, decode, reader, writer = codecs.lookup('UTF-8') s = 'ab\346c' print decode(s, 'replace') # outputs (u'ab\uFFFDc', 4) fh = StringIO(s) sr = reader(fh, 'replace') print repr(sr.read()) # dies with a UnicodeError exception Randomly assigning to Barry -- this just needs a quick sanity check ------------------------------------------------------- Date: 2000-Dec-07 01:14 By: Nobody Comment: The patch looks OK to me. -- Marc-Andre ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102698&group_id=5470 From noreply@sourceforge.net Thu Dec 7 21:37:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 7 Dec 2000 13:37:23 -0800 Subject: [Patches] [Patch #102715] Prototype for PEP 230 Message-ID: <200012072137.NAA13626@sf-web1.i.sourceforge.net> Patch #102715 has been updated. Project: python Category: library Status: Open Submitted by: gvanrossum Assigned to : Nobody Summary: Prototype for PEP 230 ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102715&group_id=5470 From noreply@sourceforge.net Thu Dec 7 21:37:36 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 7 Dec 2000 13:37:36 -0800 Subject: [Patches] [Patch #102715] Prototype for PEP 230 Message-ID: <200012072137.NAA13632@sf-web1.i.sourceforge.net> Patch #102715 has been updated. Project: python Category: library Status: Open Submitted by: gvanrossum Assigned to : gvanrossum Summary: Prototype for PEP 230 ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102715&group_id=5470 From noreply@sourceforge.net Fri Dec 8 02:34:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 7 Dec 2000 18:34:08 -0800 Subject: [Patches] [Patch #102652] Reference implementation for PEP 208 (coercion) Message-ID: <200012080234.SAA10281@sf-web1.i.sourceforge.net> Patch #102652 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nascheme Assigned to : Nobody Summary: Reference implementation for PEP 208 (coercion) Follow-Ups: Date: 2000-Dec-04 18:45 By: nascheme Comment: This patch is a little rough yet but I guess its better here than on my website. The major source of ugliness PyObject_Compare. ------------------------------------------------------- Date: 2000-Dec-06 08:00 By: nascheme Comment: Cleaned up PyObject_Compare() (still needs to be optimized). __coerce__ on instances needs be to sorted out. It should probably be called if it exists for backwards compatibility. Longs and complex types still need to be converted to new style numbers. ------------------------------------------------------- Date: 2000-Dec-07 18:34 By: nascheme Comment: Fix some reference counts. Make use of macros to reduce duplicate code. Remove some unused code in classobject. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102652&group_id=5470 From noreply@sourceforge.net Fri Dec 8 05:19:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 7 Dec 2000 21:19:33 -0800 Subject: [Patches] [Patch #102169] Additional docs for __iadd__ hooks Message-ID: <200012080519.VAA25738@sf-web1.i.sourceforge.net> Patch #102169 has been updated. Project: python Category: documentation Status: Open Submitted by: twouters Assigned to : fdrake Summary: Additional docs for __iadd__ hooks Follow-Ups: Date: 2000-Oct-30 05:02 By: twouters Comment: 'Fix' for 'bug' #117178: add description of the in-place hooks to the Reference manual, section 3.3. Untested TeX code, but likely to be correct (mostly copy-and-paste work.) ------------------------------------------------------- Date: 2000-Nov-02 10:23 By: fdrake Comment: You really need to provide more specific description of how these methods are supposed to behave (about returning self meaning in-place operation occurred, a new object means replace self with new object (in context), etc. ------------------------------------------------------- Date: 2000-Dec-07 21:19 By: twouters Comment: Slightly better docs, and probably hard to improve without dropping the "expert's eye" look and feel of the reference manual. One nit: it speaks of 'methods' rather than 'functions, because I think it's clearer, in this context. The regular __add__ hooks still speak of 'functions'. Apologies for the time it took me ;P ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102169&group_id=5470 From noreply@sourceforge.net Fri Dec 8 15:14:41 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 8 Dec 2000 07:14:41 -0800 Subject: [Patches] [Patch #102613] __findattr__() Message-ID: <200012081514.HAA10544@sf-web2.i.sourceforge.net> Patch #102613 has been updated. Project: python Category: core (C code) Status: Rejected Submitted by: bwarsaw Assigned to : Nobody Summary: __findattr__() Follow-Ups: Date: 2000-Dec-01 19:34 By: bwarsaw Comment: Implementation of __findattr__() extension, as per PEP 231. ------------------------------------------------------- Date: 2000-Dec-08 07:14 By: gvanrossum Comment: I'll add an explanation of the rejection to the PEP. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102613&group_id=5470 From noreply@sourceforge.net Fri Dec 8 18:24:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 8 Dec 2000 10:24:00 -0800 Subject: [Patches] [Patch #102733] {}.popitem() implementation Message-ID: <200012081824.KAA31284@sf-web3.vaspecialprojects.com> Patch #102733 has been updated. Project: python Category: core (C code) Status: Open Submitted by: gvanrossum Assigned to : Nobody Summary: {}.popitem() implementation ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102733&group_id=5470 From noreply@sourceforge.net Fri Dec 8 18:28:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 8 Dec 2000 10:28:16 -0800 Subject: [Patches] [Patch #102733] {}.popitem() implementation Message-ID: <200012081828.KAA31387@sf-web3.vaspecialprojects.com> Patch #102733 has been updated. Project: python Category: core (C code) Status: Open Submitted by: gvanrossum Assigned to : tim_one Summary: {}.popitem() implementation Follow-Ups: Date: 2000-Dec-08 10:28 By: gvanrossum Comment: Tim (or anyone else): can you improve this? It has excellent performance as long as you only do a single dictionary at a time, but goes quadratic if you call popitem() for two identical dictionaries in lock-step. Maybe jumping criss-cross through the hash table like lookdict does would improve that; but I don't understand the math used for that ("Cycle through GF(2^n)-{0}" ???). Here's a test program: import time for run in range(1000): print "run =", run for log2size in range(10, 18): size = 2**log2size print "log2size =", log2size, print "size =", size a = {} t0 = time.clock() while 1: i = len(a) if i >= size: break a[`i`] = i t1 = time.clock() print "%.1f usec per item to build (total %.3f sec)" % ( (1e6*(t1-t0)/size), t1-t0) b = a.copy() t0 = time.clock() try: while 1: a.popitem() b.popitem() except KeyError: pass t1 = time.clock() print "%.1f usec per item to destroy twins (total %.3f sec)" % ( (1e6*(t1-t0)/size), t1-t0) assert not a, a assert not b, b ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102733&group_id=5470 From noreply@sourceforge.net Fri Dec 8 18:58:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 8 Dec 2000 10:58:28 -0800 Subject: [Patches] [Patch #102733] {}.popitem() implementation Message-ID: <200012081858.KAA14759@sf-web2.i.sourceforge.net> Patch #102733 has been updated. Project: python Category: core (C code) Status: Open Submitted by: gvanrossum Assigned to : tim_one Summary: {}.popitem() implementation Follow-Ups: Date: 2000-Dec-08 10:28 By: gvanrossum Comment: Tim (or anyone else): can you improve this? It has excellent performance as long as you only do a single dictionary at a time, but goes quadratic if you call popitem() for two identical dictionaries in lock-step. Maybe jumping criss-cross through the hash table like lookdict does would improve that; but I don't understand the math used for that ("Cycle through GF(2^n)-{0}" ???). Here's a test program: import time for run in range(1000): print "run =", run for log2size in range(10, 18): size = 2**log2size print "log2size =", log2size, print "size =", size a = {} t0 = time.clock() while 1: i = len(a) if i >= size: break a[`i`] = i t1 = time.clock() print "%.1f usec per item to build (total %.3f sec)" % ( (1e6*(t1-t0)/size), t1-t0) b = a.copy() t0 = time.clock() try: while 1: a.popitem() b.popitem() except KeyError: pass t1 = time.clock() print "%.1f usec per item to destroy twins (total %.3f sec)" % ( (1e6*(t1-t0)/size), t1-t0) assert not a, a assert not b, b ------------------------------------------------------- Date: 2000-Dec-08 10:58 By: tim_one Comment: While I haven't yet actually tried it, I'm pretty sure you'd get much better performance (linear) in your test case by changing "finger = i+1" to "finger = i", and no matter how many dicts you march over in lockstep. In the case of a single dict, it adds a trivial amount of overhead per lookup (one extra C-speed trip around the loop per lookup). The reason "GF(2^n)-{)}" confuses you is because he should have written "**" instead of "^" . In essense, it means "visit each of the 2**n bit patterns exactly once, except for the all-zero pattern", and the "GF" means Galois Field, the theoretical basis for why the bit manipulations actually achieve that. I don't believe it would help: the sequence of bit patterns visited remains fixed, and if you continue to move the finger "one beyond" you'll get the same problem (the first pass thru two lockstep iters creates gaps that the second pass has to skip over; the second pass doubles the size of those gaps; the third pass doubles them again, etc). I agree that sharing one finger is very attractive. +1. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102733&group_id=5470 From noreply@sourceforge.net Fri Dec 8 19:04:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 8 Dec 2000 11:04:48 -0800 Subject: [Patches] [Patch #102733] {}.popitem() implementation Message-ID: <200012081904.LAB14879@sf-web2.i.sourceforge.net> Patch #102733 has been updated. Project: python Category: core (C code) Status: Open Submitted by: gvanrossum Assigned to : tim_one Summary: {}.popitem() implementation Follow-Ups: Date: 2000-Dec-08 10:28 By: gvanrossum Comment: Tim (or anyone else): can you improve this? It has excellent performance as long as you only do a single dictionary at a time, but goes quadratic if you call popitem() for two identical dictionaries in lock-step. Maybe jumping criss-cross through the hash table like lookdict does would improve that; but I don't understand the math used for that ("Cycle through GF(2^n)-{0}" ???). Here's a test program: import time for run in range(1000): print "run =", run for log2size in range(10, 18): size = 2**log2size print "log2size =", log2size, print "size =", size a = {} t0 = time.clock() while 1: i = len(a) if i >= size: break a[`i`] = i t1 = time.clock() print "%.1f usec per item to build (total %.3f sec)" % ( (1e6*(t1-t0)/size), t1-t0) b = a.copy() t0 = time.clock() try: while 1: a.popitem() b.popitem() except KeyError: pass t1 = time.clock() print "%.1f usec per item to destroy twins (total %.3f sec)" % ( (1e6*(t1-t0)/size), t1-t0) assert not a, a assert not b, b ------------------------------------------------------- Date: 2000-Dec-08 10:58 By: tim_one Comment: While I haven't yet actually tried it, I'm pretty sure you'd get much better performance (linear) in your test case by changing "finger = i+1" to "finger = i", and no matter how many dicts you march over in lockstep. In the case of a single dict, it adds a trivial amount of overhead per lookup (one extra C-speed trip around the loop per lookup). The reason "GF(2^n)-{)}" confuses you is because he should have written "**" instead of "^" . In essense, it means "visit each of the 2**n bit patterns exactly once, except for the all-zero pattern", and the "GF" means Galois Field, the theoretical basis for why the bit manipulations actually achieve that. I don't believe it would help: the sequence of bit patterns visited remains fixed, and if you continue to move the finger "one beyond" you'll get the same problem (the first pass thru two lockstep iters creates gaps that the second pass has to skip over; the second pass doubles the size of those gaps; the third pass doubles them again, etc). I agree that sharing one finger is very attractive. +1. ------------------------------------------------------- Date: 2000-Dec-08 11:04 By: gvanrossum Comment: New patch with Tim's suggestion. Works well! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102733&group_id=5470 From noreply@sourceforge.net Sat Dec 9 06:48:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 8 Dec 2000 22:48:07 -0800 Subject: [Patches] [Patch #102746] strip \n so that Unix and Windows dbs are interoperable Message-ID: <200012090648.WAA07886@usw-sf-web1.sourceforge.net> Patch #102746 has been updated. Project: python Category: Modules Status: Open Submitted by: nobody Assigned to : nobody Summary: strip \n so that Unix and Windows dbs are interoperable ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102746&group_id=5470 From noreply@sourceforge.net Sat Dec 9 06:49:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 8 Dec 2000 22:49:52 -0800 Subject: [Patches] [Patch #102746] strip \n so that Unix and Windows dbs are interoperable Message-ID: <200012090649.WAA09666@usw-sf-web2.sourceforge.net> Patch #102746 has been updated. Project: python Category: Modules Status: Open Submitted by: nobody Assigned to : nobody Summary: strip \n so that Unix and Windows dbs are interoperable Follow-Ups: Date: 2000-Dec-08 22:49 By: eaj Comment: Oops. Submitted without logging in. This is a simple fix. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102746&group_id=5470 From noreply@sourceforge.net Sat Dec 9 22:01:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 9 Dec 2000 14:01:01 -0800 Subject: [Patches] [Patch #102733] {}.popitem() implementation Message-ID: <200012092201.OAA27384@usw-sf-web2.sourceforge.net> Patch #102733 has been updated. Project: python Category: core (C code) Status: Open Submitted by: gvanrossum Assigned to : tim_one Summary: {}.popitem() implementation Follow-Ups: Date: 2000-Dec-09 14:01 By: gvanrossum Comment: New patch uploaded. This is really Tim Peters's patch, including the correction he posted on Sat, 9 Dec 2000 16:09:30. I don't know why Tim's original suggested "improvement" worked so well for me -- it really did improve a lot over the original version. Oh well. ------------------------------------------------------- Date: 2000-Dec-08 10:28 By: gvanrossum Comment: Tim (or anyone else): can you improve this? It has excellent performance as long as you only do a single dictionary at a time, but goes quadratic if you call popitem() for two identical dictionaries in lock-step. Maybe jumping criss-cross through the hash table like lookdict does would improve that; but I don't understand the math used for that ("Cycle through GF(2^n)-{0}" ???). Here's a test program: import time for run in range(1000): print "run =", run for log2size in range(10, 18): size = 2**log2size print "log2size =", log2size, print "size =", size a = {} t0 = time.clock() while 1: i = len(a) if i >= size: break a[`i`] = i t1 = time.clock() print "%.1f usec per item to build (total %.3f sec)" % ( (1e6*(t1-t0)/size), t1-t0) b = a.copy() t0 = time.clock() try: while 1: a.popitem() b.popitem() except KeyError: pass t1 = time.clock() print "%.1f usec per item to destroy twins (total %.3f sec)" % ( (1e6*(t1-t0)/size), t1-t0) assert not a, a assert not b, b ------------------------------------------------------- Date: 2000-Dec-08 10:58 By: tim_one Comment: While I haven't yet actually tried it, I'm pretty sure you'd get much better performance (linear) in your test case by changing "finger = i+1" to "finger = i", and no matter how many dicts you march over in lockstep. In the case of a single dict, it adds a trivial amount of overhead per lookup (one extra C-speed trip around the loop per lookup). The reason "GF(2^n)-{)}" confuses you is because he should have written "**" instead of "^" . In essense, it means "visit each of the 2**n bit patterns exactly once, except for the all-zero pattern", and the "GF" means Galois Field, the theoretical basis for why the bit manipulations actually achieve that. I don't believe it would help: the sequence of bit patterns visited remains fixed, and if you continue to move the finger "one beyond" you'll get the same problem (the first pass thru two lockstep iters creates gaps that the second pass has to skip over; the second pass doubles the size of those gaps; the third pass doubles them again, etc). I agree that sharing one finger is very attractive. +1. ------------------------------------------------------- Date: 2000-Dec-08 11:04 By: gvanrossum Comment: New patch with Tim's suggestion. Works well! ------------------------------------------------------- Date: 2000-Dec-08 14:55 By: tim_one Comment: Actually, your test program with the new patch continues to show rotten behavior for me. dict.copy() returns a dict with the same value, but not necessarily the same internal structure. This is easy to see by changing the test's inner loop to while 1: gota = a.popitem() gotb = b.popitem() assert gota == gotb, (gota, gotb, len(a), len(b)) This fails instantly for me: run = 0 log2size = 10 size = 1024 10.2 usec per item to build (total 0.010 sec) Traceback (most recent call last): File "tdict.py", line 27, in ? assert gota == gotb, (gota, gotb, len(a), len(b)) AssertionError: (('773', 773), ('479', 479), 1023, 1023) If I make the dicts truly identical, by building b via the same operations in the same order as occurred for a, then the assert doesn't trigger and performance is wonderful (deleting the dicts is faster than building them). But in that case, the original "finger = i+1" is also very good (just a little slower). My head analysis of that case was wrong: the first pass does create a checkerboard pattern in both dicts, but the second pass systematically hits the holes created by the first pass. Are you sure your test program worked a lot better after the patch? Best I can tell, what I'm seeing has very little to do with the finger strategy and very much to do with accidents in the way dict.copy() works. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102733&group_id=5470 From noreply@sourceforge.net Sun Dec 10 23:12:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 10 Dec 2000 15:12:40 -0800 Subject: [Patches] [Patch #102733] {}.popitem() implementation Message-ID: <200012102312.PAA32445@usw-sf-web2.sourceforge.net> Patch #102733 has been updated. Project: python Category: core (C code) Status: Open Submitted by: gvanrossum Assigned to : tim_one Summary: {}.popitem() implementation Follow-Ups: Date: 2000-Dec-10 15:12 By: tim_one Comment: +1. I think .popitem() is a good addition, providing a (now predictably) efficient way to do something useful that couldn't be done efficiently before, and with no bad effects on time or space use elsewhere. I don't see any real point to additional .popkey() or .popvalue() methods. The patch is missing: + Docs. + Test cases. + docstrings (although all of dictobject.c is missing docstrings). I would really like to understand why the original suggestion did good for you. For starters, which platform did you run it on? I don't see anything in the code that should vary across 32-bit platforms (not the string hash codes, or the GF-cycling business, ... even computing the initial value of incr is careful to cast hash to unsigned before the right shift). On the platform where it did help, what does this print (w/ the current patch -- this will reveal the internal storage order for a and b)? N = 128 ints = range(N) a = {} for i in ints: a[`i`] = i b = a.copy() aorder = [a.popitem()[1] for i in ints] border = [b.popitem()[1] for i in ints] assert not a assert not b for aval, bval in zip(aorder, border): print "%6d %6d" % (aval, bval), if aval == bval: print "ok" else: print "******* out of synch *******" Here's what I get: 34 34 ok 35 35 ok 36 36 ok 37 37 ok 30 30 ok 31 31 ok 32 32 ok 33 33 ok 38 95 ******* out of synch ******* 39 38 ******* out of synch ******* 78 39 ******* out of synch ******* 79 78 ******* out of synch ******* 107 79 ******* out of synch ******* 106 107 ******* out of synch ******* 101 106 ******* out of synch ******* 100 101 ******* out of synch ******* 103 100 ******* out of synch ******* 102 103 ******* out of synch ******* 70 102 ******* out of synch ******* 71 70 ******* out of synch ******* 72 71 ******* out of synch ******* 73 72 ******* out of synch ******* 74 73 ******* out of synch ******* 75 74 ******* out of synch ******* 76 75 ******* out of synch ******* 77 76 ******* out of synch ******* 59 77 ******* out of synch ******* 54 108 ******* out of synch ******* 55 9 ******* out of synch ******* 58 7 ******* out of synch ******* 9 5 ******* out of synch ******* 7 3 ******* out of synch ******* 5 1 ******* out of synch ******* 3 41 ******* out of synch ******* 1 40 ******* out of synch ******* 41 43 ******* out of synch ******* 40 42 ******* out of synch ******* 43 45 ******* out of synch ******* 42 44 ******* out of synch ******* 45 47 ******* out of synch ******* 44 46 ******* out of synch ******* 47 49 ******* out of synch ******* 46 48 ******* out of synch ******* 49 85 ******* out of synch ******* 48 84 ******* out of synch ******* 85 87 ******* out of synch ******* 84 86 ******* out of synch ******* 87 81 ******* out of synch ******* 86 80 ******* out of synch ******* 81 83 ******* out of synch ******* 80 82 ******* out of synch ******* 83 112 ******* out of synch ******* 82 113 ******* out of synch ******* 112 110 ******* out of synch ******* 113 111 ******* out of synch ******* 110 89 ******* out of synch ******* 111 88 ******* out of synch ******* 89 114 ******* out of synch ******* 88 115 ******* out of synch ******* 114 99 ******* out of synch ******* 115 124 ******* out of synch ******* 122 52 ******* out of synch ******* 120 53 ******* out of synch ******* 117 50 ******* out of synch ******* 52 51 ******* out of synch ******* 53 56 ******* out of synch ******* 50 57 ******* out of synch ******* 51 54 ******* out of synch ******* 56 55 ******* out of synch ******* 57 16 ******* out of synch ******* 18 17 ******* out of synch ******* 19 58 ******* out of synch ******* 16 59 ******* out of synch ******* 17 19 ******* out of synch ******* 14 13 ******* out of synch ******* 15 18 ******* out of synch ******* 12 11 ******* out of synch ******* 13 96 ******* out of synch ******* 10 97 ******* out of synch ******* 11 94 ******* out of synch ******* 96 14 ******* out of synch ******* 97 92 ******* out of synch ******* 94 93 ******* out of synch ******* 95 90 ******* out of synch ******* 92 91 ******* out of synch ******* 93 127 ******* out of synch ******* 90 126 ******* out of synch ******* 91 125 ******* out of synch ******* 127 15 ******* out of synch ******* 126 123 ******* out of synch ******* 125 122 ******* out of synch ******* 124 98 ******* out of synch ******* 123 120 ******* out of synch ******* 116 118 ******* out of synch ******* 98 119 ******* out of synch ******* 99 10 ******* out of synch ******* 118 12 ******* out of synch ******* 119 69 ******* out of synch ******* 104 8 ******* out of synch ******* 109 6 ******* out of synch ******* 8 4 ******* out of synch ******* 6 2 ******* out of synch ******* 4 0 ******* out of synch ******* 2 61 ******* out of synch ******* 0 29 ******* out of synch ******* 29 28 ******* out of synch ******* 28 62 ******* out of synch ******* 23 23 ok 22 22 ok 21 21 ok 20 20 ok 27 27 ok 26 26 ok 25 25 ok 24 24 ok 105 105 ok 69 104 ******* out of synch ******* 68 68 ok 67 67 ok 66 66 ok 65 65 ok 64 64 ok 63 63 ok 62 117 ******* out of synch ******* 61 116 ******* out of synch ******* 60 60 ok 108 109 ******* out of synch ******* 121 121 ok ------------------------------------------------------- Date: 2000-Dec-09 14:01 By: gvanrossum Comment: New patch uploaded. This is really Tim Peters's patch, including the correction he posted on Sat, 9 Dec 2000 16:09:30. I don't know why Tim's original suggested "improvement" worked so well for me -- it really did improve a lot over the original version. Oh well. ------------------------------------------------------- Date: 2000-Dec-08 10:28 By: gvanrossum Comment: Tim (or anyone else): can you improve this? It has excellent performance as long as you only do a single dictionary at a time, but goes quadratic if you call popitem() for two identical dictionaries in lock-step. Maybe jumping criss-cross through the hash table like lookdict does would improve that; but I don't understand the math used for that ("Cycle through GF(2^n)-{0}" ???). Here's a test program: import time for run in range(1000): print "run =", run for log2size in range(10, 18): size = 2**log2size print "log2size =", log2size, print "size =", size a = {} t0 = time.clock() while 1: i = len(a) if i >= size: break a[`i`] = i t1 = time.clock() print "%.1f usec per item to build (total %.3f sec)" % ( (1e6*(t1-t0)/size), t1-t0) b = a.copy() t0 = time.clock() try: while 1: a.popitem() b.popitem() except KeyError: pass t1 = time.clock() print "%.1f usec per item to destroy twins (total %.3f sec)" % ( (1e6*(t1-t0)/size), t1-t0) assert not a, a assert not b, b ------------------------------------------------------- Date: 2000-Dec-08 10:58 By: tim_one Comment: While I haven't yet actually tried it, I'm pretty sure you'd get much better performance (linear) in your test case by changing "finger = i+1" to "finger = i", and no matter how many dicts you march over in lockstep. In the case of a single dict, it adds a trivial amount of overhead per lookup (one extra C-speed trip around the loop per lookup). The reason "GF(2^n)-{)}" confuses you is because he should have written "**" instead of "^" . In essense, it means "visit each of the 2**n bit patterns exactly once, except for the all-zero pattern", and the "GF" means Galois Field, the theoretical basis for why the bit manipulations actually achieve that. I don't believe it would help: the sequence of bit patterns visited remains fixed, and if you continue to move the finger "one beyond" you'll get the same problem (the first pass thru two lockstep iters creates gaps that the second pass has to skip over; the second pass doubles the size of those gaps; the third pass doubles them again, etc). I agree that sharing one finger is very attractive. +1. ------------------------------------------------------- Date: 2000-Dec-08 11:04 By: gvanrossum Comment: New patch with Tim's suggestion. Works well! ------------------------------------------------------- Date: 2000-Dec-08 14:55 By: tim_one Comment: Actually, your test program with the new patch continues to show rotten behavior for me. dict.copy() returns a dict with the same value, but not necessarily the same internal structure. This is easy to see by changing the test's inner loop to while 1: gota = a.popitem() gotb = b.popitem() assert gota == gotb, (gota, gotb, len(a), len(b)) This fails instantly for me: run = 0 log2size = 10 size = 1024 10.2 usec per item to build (total 0.010 sec) Traceback (most recent call last): File "tdict.py", line 27, in ? assert gota == gotb, (gota, gotb, len(a), len(b)) AssertionError: (('773', 773), ('479', 479), 1023, 1023) If I make the dicts truly identical, by building b via the same operations in the same order as occurred for a, then the assert doesn't trigger and performance is wonderful (deleting the dicts is faster than building them). But in that case, the original "finger = i+1" is also very good (just a little slower). My head analysis of that case was wrong: the first pass does create a checkerboard pattern in both dicts, but the second pass systematically hits the holes created by the first pass. Are you sure your test program worked a lot better after the patch? Best I can tell, what I'm seeing has very little to do with the finger strategy and very much to do with accidents in the way dict.copy() works. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102733&group_id=5470 From noreply@sourceforge.net Mon Dec 11 02:44:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 10 Dec 2000 18:44:21 -0800 Subject: [Patches] [Patch #102733] {}.popitem() implementation Message-ID: <200012110244.SAA31392@usw-sf-web1.sourceforge.net> Patch #102733 has been updated. Project: python Category: core (C code) Status: Open Submitted by: gvanrossum Assigned to : tim_one Summary: {}.popitem() implementation Follow-Ups: Date: 2000-Dec-10 18:44 By: gvanrossum Comment: I get the exact same output as you, Tim. I tried to reproduce my original results with the original implementation again, and indeed I get the same times with or without your "improvement". My best guess as to why I thought it made a difference is that I misread the poorly designed output from the test program. I'll add docs and test cases. ------------------------------------------------------- Date: 2000-Dec-10 15:12 By: tim_one Comment: +1. I think .popitem() is a good addition, providing a (now predictably) efficient way to do something useful that couldn't be done efficiently before, and with no bad effects on time or space use elsewhere. I don't see any real point to additional .popkey() or .popvalue() methods. The patch is missing: + Docs. + Test cases. + docstrings (although all of dictobject.c is missing docstrings). I would really like to understand why the original suggestion did good for you. For starters, which platform did you run it on? I don't see anything in the code that should vary across 32-bit platforms (not the string hash codes, or the GF-cycling business, ... even computing the initial value of incr is careful to cast hash to unsigned before the right shift). On the platform where it did help, what does this print (w/ the current patch -- this will reveal the internal storage order for a and b)? N = 128 ints = range(N) a = {} for i in ints: a[`i`] = i b = a.copy() aorder = [a.popitem()[1] for i in ints] border = [b.popitem()[1] for i in ints] assert not a assert not b for aval, bval in zip(aorder, border): print "%6d %6d" % (aval, bval), if aval == bval: print "ok" else: print "******* out of synch *******" Here's what I get: 34 34 ok 35 35 ok 36 36 ok 37 37 ok 30 30 ok 31 31 ok 32 32 ok 33 33 ok 38 95 ******* out of synch ******* 39 38 ******* out of synch ******* 78 39 ******* out of synch ******* 79 78 ******* out of synch ******* 107 79 ******* out of synch ******* 106 107 ******* out of synch ******* 101 106 ******* out of synch ******* 100 101 ******* out of synch ******* 103 100 ******* out of synch ******* 102 103 ******* out of synch ******* 70 102 ******* out of synch ******* 71 70 ******* out of synch ******* 72 71 ******* out of synch ******* 73 72 ******* out of synch ******* 74 73 ******* out of synch ******* 75 74 ******* out of synch ******* 76 75 ******* out of synch ******* 77 76 ******* out of synch ******* 59 77 ******* out of synch ******* 54 108 ******* out of synch ******* 55 9 ******* out of synch ******* 58 7 ******* out of synch ******* 9 5 ******* out of synch ******* 7 3 ******* out of synch ******* 5 1 ******* out of synch ******* 3 41 ******* out of synch ******* 1 40 ******* out of synch ******* 41 43 ******* out of synch ******* 40 42 ******* out of synch ******* 43 45 ******* out of synch ******* 42 44 ******* out of synch ******* 45 47 ******* out of synch ******* 44 46 ******* out of synch ******* 47 49 ******* out of synch ******* 46 48 ******* out of synch ******* 49 85 ******* out of synch ******* 48 84 ******* out of synch ******* 85 87 ******* out of synch ******* 84 86 ******* out of synch ******* 87 81 ******* out of synch ******* 86 80 ******* out of synch ******* 81 83 ******* out of synch ******* 80 82 ******* out of synch ******* 83 112 ******* out of synch ******* 82 113 ******* out of synch ******* 112 110 ******* out of synch ******* 113 111 ******* out of synch ******* 110 89 ******* out of synch ******* 111 88 ******* out of synch ******* 89 114 ******* out of synch ******* 88 115 ******* out of synch ******* 114 99 ******* out of synch ******* 115 124 ******* out of synch ******* 122 52 ******* out of synch ******* 120 53 ******* out of synch ******* 117 50 ******* out of synch ******* 52 51 ******* out of synch ******* 53 56 ******* out of synch ******* 50 57 ******* out of synch ******* 51 54 ******* out of synch ******* 56 55 ******* out of synch ******* 57 16 ******* out of synch ******* 18 17 ******* out of synch ******* 19 58 ******* out of synch ******* 16 59 ******* out of synch ******* 17 19 ******* out of synch ******* 14 13 ******* out of synch ******* 15 18 ******* out of synch ******* 12 11 ******* out of synch ******* 13 96 ******* out of synch ******* 10 97 ******* out of synch ******* 11 94 ******* out of synch ******* 96 14 ******* out of synch ******* 97 92 ******* out of synch ******* 94 93 ******* out of synch ******* 95 90 ******* out of synch ******* 92 91 ******* out of synch ******* 93 127 ******* out of synch ******* 90 126 ******* out of synch ******* 91 125 ******* out of synch ******* 127 15 ******* out of synch ******* 126 123 ******* out of synch ******* 125 122 ******* out of synch ******* 124 98 ******* out of synch ******* 123 120 ******* out of synch ******* 116 118 ******* out of synch ******* 98 119 ******* out of synch ******* 99 10 ******* out of synch ******* 118 12 ******* out of synch ******* 119 69 ******* out of synch ******* 104 8 ******* out of synch ******* 109 6 ******* out of synch ******* 8 4 ******* out of synch ******* 6 2 ******* out of synch ******* 4 0 ******* out of synch ******* 2 61 ******* out of synch ******* 0 29 ******* out of synch ******* 29 28 ******* out of synch ******* 28 62 ******* out of synch ******* 23 23 ok 22 22 ok 21 21 ok 20 20 ok 27 27 ok 26 26 ok 25 25 ok 24 24 ok 105 105 ok 69 104 ******* out of synch ******* 68 68 ok 67 67 ok 66 66 ok 65 65 ok 64 64 ok 63 63 ok 62 117 ******* out of synch ******* 61 116 ******* out of synch ******* 60 60 ok 108 109 ******* out of synch ******* 121 121 ok ------------------------------------------------------- Date: 2000-Dec-09 14:01 By: gvanrossum Comment: New patch uploaded. This is really Tim Peters's patch, including the correction he posted on Sat, 9 Dec 2000 16:09:30. I don't know why Tim's original suggested "improvement" worked so well for me -- it really did improve a lot over the original version. Oh well. ------------------------------------------------------- Date: 2000-Dec-08 10:28 By: gvanrossum Comment: Tim (or anyone else): can you improve this? It has excellent performance as long as you only do a single dictionary at a time, but goes quadratic if you call popitem() for two identical dictionaries in lock-step. Maybe jumping criss-cross through the hash table like lookdict does would improve that; but I don't understand the math used for that ("Cycle through GF(2^n)-{0}" ???). Here's a test program: import time for run in range(1000): print "run =", run for log2size in range(10, 18): size = 2**log2size print "log2size =", log2size, print "size =", size a = {} t0 = time.clock() while 1: i = len(a) if i >= size: break a[`i`] = i t1 = time.clock() print "%.1f usec per item to build (total %.3f sec)" % ( (1e6*(t1-t0)/size), t1-t0) b = a.copy() t0 = time.clock() try: while 1: a.popitem() b.popitem() except KeyError: pass t1 = time.clock() print "%.1f usec per item to destroy twins (total %.3f sec)" % ( (1e6*(t1-t0)/size), t1-t0) assert not a, a assert not b, b ------------------------------------------------------- Date: 2000-Dec-08 10:58 By: tim_one Comment: While I haven't yet actually tried it, I'm pretty sure you'd get much better performance (linear) in your test case by changing "finger = i+1" to "finger = i", and no matter how many dicts you march over in lockstep. In the case of a single dict, it adds a trivial amount of overhead per lookup (one extra C-speed trip around the loop per lookup). The reason "GF(2^n)-{)}" confuses you is because he should have written "**" instead of "^" . In essense, it means "visit each of the 2**n bit patterns exactly once, except for the all-zero pattern", and the "GF" means Galois Field, the theoretical basis for why the bit manipulations actually achieve that. I don't believe it would help: the sequence of bit patterns visited remains fixed, and if you continue to move the finger "one beyond" you'll get the same problem (the first pass thru two lockstep iters creates gaps that the second pass has to skip over; the second pass doubles the size of those gaps; the third pass doubles them again, etc). I agree that sharing one finger is very attractive. +1. ------------------------------------------------------- Date: 2000-Dec-08 11:04 By: gvanrossum Comment: New patch with Tim's suggestion. Works well! ------------------------------------------------------- Date: 2000-Dec-08 14:55 By: tim_one Comment: Actually, your test program with the new patch continues to show rotten behavior for me. dict.copy() returns a dict with the same value, but not necessarily the same internal structure. This is easy to see by changing the test's inner loop to while 1: gota = a.popitem() gotb = b.popitem() assert gota == gotb, (gota, gotb, len(a), len(b)) This fails instantly for me: run = 0 log2size = 10 size = 1024 10.2 usec per item to build (total 0.010 sec) Traceback (most recent call last): File "tdict.py", line 27, in ? assert gota == gotb, (gota, gotb, len(a), len(b)) AssertionError: (('773', 773), ('479', 479), 1023, 1023) If I make the dicts truly identical, by building b via the same operations in the same order as occurred for a, then the assert doesn't trigger and performance is wonderful (deleting the dicts is faster than building them). But in that case, the original "finger = i+1" is also very good (just a little slower). My head analysis of that case was wrong: the first pass does create a checkerboard pattern in both dicts, but the second pass systematically hits the holes created by the first pass. Are you sure your test program worked a lot better after the patch? Best I can tell, what I'm seeing has very little to do with the finger strategy and very much to do with accidents in the way dict.copy() works. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102733&group_id=5470 From noreply@sourceforge.net Mon Dec 11 03:03:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 10 Dec 2000 19:03:53 -0800 Subject: [Patches] [Patch #102733] {}.popitem() implementation Message-ID: <200012110303.TAA31814@usw-sf-web1.sourceforge.net> Patch #102733 has been updated. Project: python Category: core (C code) Status: Open Submitted by: gvanrossum Assigned to : tim_one Summary: {}.popitem() implementation Follow-Ups: Date: 2000-Dec-10 19:03 By: tim_one Comment: Good! Not all is lost: random blobs of the string and dict code got a thorough code review out of it . BTW, if you're going to Pronounce favorably on .popitem(), feel free to tell me to finish the job (just an offer, not a request -- either way is fine by me). ------------------------------------------------------- Date: 2000-Dec-10 18:44 By: gvanrossum Comment: I get the exact same output as you, Tim. I tried to reproduce my original results with the original implementation again, and indeed I get the same times with or without your "improvement". My best guess as to why I thought it made a difference is that I misread the poorly designed output from the test program. I'll add docs and test cases. ------------------------------------------------------- Date: 2000-Dec-10 15:12 By: tim_one Comment: +1. I think .popitem() is a good addition, providing a (now predictably) efficient way to do something useful that couldn't be done efficiently before, and with no bad effects on time or space use elsewhere. I don't see any real point to additional .popkey() or .popvalue() methods. The patch is missing: + Docs. + Test cases. + docstrings (although all of dictobject.c is missing docstrings). I would really like to understand why the original suggestion did good for you. For starters, which platform did you run it on? I don't see anything in the code that should vary across 32-bit platforms (not the string hash codes, or the GF-cycling business, ... even computing the initial value of incr is careful to cast hash to unsigned before the right shift). On the platform where it did help, what does this print (w/ the current patch -- this will reveal the internal storage order for a and b)? N = 128 ints = range(N) a = {} for i in ints: a[`i`] = i b = a.copy() aorder = [a.popitem()[1] for i in ints] border = [b.popitem()[1] for i in ints] assert not a assert not b for aval, bval in zip(aorder, border): print "%6d %6d" % (aval, bval), if aval == bval: print "ok" else: print "******* out of synch *******" Here's what I get: 34 34 ok 35 35 ok 36 36 ok 37 37 ok 30 30 ok 31 31 ok 32 32 ok 33 33 ok 38 95 ******* out of synch ******* 39 38 ******* out of synch ******* 78 39 ******* out of synch ******* 79 78 ******* out of synch ******* 107 79 ******* out of synch ******* 106 107 ******* out of synch ******* 101 106 ******* out of synch ******* 100 101 ******* out of synch ******* 103 100 ******* out of synch ******* 102 103 ******* out of synch ******* 70 102 ******* out of synch ******* 71 70 ******* out of synch ******* 72 71 ******* out of synch ******* 73 72 ******* out of synch ******* 74 73 ******* out of synch ******* 75 74 ******* out of synch ******* 76 75 ******* out of synch ******* 77 76 ******* out of synch ******* 59 77 ******* out of synch ******* 54 108 ******* out of synch ******* 55 9 ******* out of synch ******* 58 7 ******* out of synch ******* 9 5 ******* out of synch ******* 7 3 ******* out of synch ******* 5 1 ******* out of synch ******* 3 41 ******* out of synch ******* 1 40 ******* out of synch ******* 41 43 ******* out of synch ******* 40 42 ******* out of synch ******* 43 45 ******* out of synch ******* 42 44 ******* out of synch ******* 45 47 ******* out of synch ******* 44 46 ******* out of synch ******* 47 49 ******* out of synch ******* 46 48 ******* out of synch ******* 49 85 ******* out of synch ******* 48 84 ******* out of synch ******* 85 87 ******* out of synch ******* 84 86 ******* out of synch ******* 87 81 ******* out of synch ******* 86 80 ******* out of synch ******* 81 83 ******* out of synch ******* 80 82 ******* out of synch ******* 83 112 ******* out of synch ******* 82 113 ******* out of synch ******* 112 110 ******* out of synch ******* 113 111 ******* out of synch ******* 110 89 ******* out of synch ******* 111 88 ******* out of synch ******* 89 114 ******* out of synch ******* 88 115 ******* out of synch ******* 114 99 ******* out of synch ******* 115 124 ******* out of synch ******* 122 52 ******* out of synch ******* 120 53 ******* out of synch ******* 117 50 ******* out of synch ******* 52 51 ******* out of synch ******* 53 56 ******* out of synch ******* 50 57 ******* out of synch ******* 51 54 ******* out of synch ******* 56 55 ******* out of synch ******* 57 16 ******* out of synch ******* 18 17 ******* out of synch ******* 19 58 ******* out of synch ******* 16 59 ******* out of synch ******* 17 19 ******* out of synch ******* 14 13 ******* out of synch ******* 15 18 ******* out of synch ******* 12 11 ******* out of synch ******* 13 96 ******* out of synch ******* 10 97 ******* out of synch ******* 11 94 ******* out of synch ******* 96 14 ******* out of synch ******* 97 92 ******* out of synch ******* 94 93 ******* out of synch ******* 95 90 ******* out of synch ******* 92 91 ******* out of synch ******* 93 127 ******* out of synch ******* 90 126 ******* out of synch ******* 91 125 ******* out of synch ******* 127 15 ******* out of synch ******* 126 123 ******* out of synch ******* 125 122 ******* out of synch ******* 124 98 ******* out of synch ******* 123 120 ******* out of synch ******* 116 118 ******* out of synch ******* 98 119 ******* out of synch ******* 99 10 ******* out of synch ******* 118 12 ******* out of synch ******* 119 69 ******* out of synch ******* 104 8 ******* out of synch ******* 109 6 ******* out of synch ******* 8 4 ******* out of synch ******* 6 2 ******* out of synch ******* 4 0 ******* out of synch ******* 2 61 ******* out of synch ******* 0 29 ******* out of synch ******* 29 28 ******* out of synch ******* 28 62 ******* out of synch ******* 23 23 ok 22 22 ok 21 21 ok 20 20 ok 27 27 ok 26 26 ok 25 25 ok 24 24 ok 105 105 ok 69 104 ******* out of synch ******* 68 68 ok 67 67 ok 66 66 ok 65 65 ok 64 64 ok 63 63 ok 62 117 ******* out of synch ******* 61 116 ******* out of synch ******* 60 60 ok 108 109 ******* out of synch ******* 121 121 ok ------------------------------------------------------- Date: 2000-Dec-09 14:01 By: gvanrossum Comment: New patch uploaded. This is really Tim Peters's patch, including the correction he posted on Sat, 9 Dec 2000 16:09:30. I don't know why Tim's original suggested "improvement" worked so well for me -- it really did improve a lot over the original version. Oh well. ------------------------------------------------------- Date: 2000-Dec-08 10:28 By: gvanrossum Comment: Tim (or anyone else): can you improve this? It has excellent performance as long as you only do a single dictionary at a time, but goes quadratic if you call popitem() for two identical dictionaries in lock-step. Maybe jumping criss-cross through the hash table like lookdict does would improve that; but I don't understand the math used for that ("Cycle through GF(2^n)-{0}" ???). Here's a test program: import time for run in range(1000): print "run =", run for log2size in range(10, 18): size = 2**log2size print "log2size =", log2size, print "size =", size a = {} t0 = time.clock() while 1: i = len(a) if i >= size: break a[`i`] = i t1 = time.clock() print "%.1f usec per item to build (total %.3f sec)" % ( (1e6*(t1-t0)/size), t1-t0) b = a.copy() t0 = time.clock() try: while 1: a.popitem() b.popitem() except KeyError: pass t1 = time.clock() print "%.1f usec per item to destroy twins (total %.3f sec)" % ( (1e6*(t1-t0)/size), t1-t0) assert not a, a assert not b, b ------------------------------------------------------- Date: 2000-Dec-08 10:58 By: tim_one Comment: While I haven't yet actually tried it, I'm pretty sure you'd get much better performance (linear) in your test case by changing "finger = i+1" to "finger = i", and no matter how many dicts you march over in lockstep. In the case of a single dict, it adds a trivial amount of overhead per lookup (one extra C-speed trip around the loop per lookup). The reason "GF(2^n)-{)}" confuses you is because he should have written "**" instead of "^" . In essense, it means "visit each of the 2**n bit patterns exactly once, except for the all-zero pattern", and the "GF" means Galois Field, the theoretical basis for why the bit manipulations actually achieve that. I don't believe it would help: the sequence of bit patterns visited remains fixed, and if you continue to move the finger "one beyond" you'll get the same problem (the first pass thru two lockstep iters creates gaps that the second pass has to skip over; the second pass doubles the size of those gaps; the third pass doubles them again, etc). I agree that sharing one finger is very attractive. +1. ------------------------------------------------------- Date: 2000-Dec-08 11:04 By: gvanrossum Comment: New patch with Tim's suggestion. Works well! ------------------------------------------------------- Date: 2000-Dec-08 14:55 By: tim_one Comment: Actually, your test program with the new patch continues to show rotten behavior for me. dict.copy() returns a dict with the same value, but not necessarily the same internal structure. This is easy to see by changing the test's inner loop to while 1: gota = a.popitem() gotb = b.popitem() assert gota == gotb, (gota, gotb, len(a), len(b)) This fails instantly for me: run = 0 log2size = 10 size = 1024 10.2 usec per item to build (total 0.010 sec) Traceback (most recent call last): File "tdict.py", line 27, in ? assert gota == gotb, (gota, gotb, len(a), len(b)) AssertionError: (('773', 773), ('479', 479), 1023, 1023) If I make the dicts truly identical, by building b via the same operations in the same order as occurred for a, then the assert doesn't trigger and performance is wonderful (deleting the dicts is faster than building them). But in that case, the original "finger = i+1" is also very good (just a little slower). My head analysis of that case was wrong: the first pass does create a checkerboard pattern in both dicts, but the second pass systematically hits the holes created by the first pass. Are you sure your test program worked a lot better after the patch? Best I can tell, what I'm seeing has very little to do with the finger strategy and very much to do with accidents in the way dict.copy() works. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102733&group_id=5470 From noreply@sourceforge.net Mon Dec 11 03:07:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 10 Dec 2000 19:07:58 -0800 Subject: [Patches] [Patch #102733] {}.popitem() implementation Message-ID: <200012110307.TAA31894@usw-sf-web1.sourceforge.net> Patch #102733 has been updated. Project: python Category: core (C code) Status: Open Submitted by: gvanrossum Assigned to : tim_one Summary: {}.popitem() implementation Follow-Ups: Date: 2000-Dec-10 19:07 By: gvanrossum Comment: Here's a new version. Unchanged Objects/dictobject.c patch; added Lib/UserDict.py, Lib/test/test_types.py, Doc/lib/libstdtypes.tex. I'll check it in after a 24 hour wait period. ------------------------------------------------------- Date: 2000-Dec-10 19:03 By: tim_one Comment: Good! Not all is lost: random blobs of the string and dict code got a thorough code review out of it . BTW, if you're going to Pronounce favorably on .popitem(), feel free to tell me to finish the job (just an offer, not a request -- either way is fine by me). ------------------------------------------------------- Date: 2000-Dec-10 18:44 By: gvanrossum Comment: I get the exact same output as you, Tim. I tried to reproduce my original results with the original implementation again, and indeed I get the same times with or without your "improvement". My best guess as to why I thought it made a difference is that I misread the poorly designed output from the test program. I'll add docs and test cases. ------------------------------------------------------- Date: 2000-Dec-10 15:12 By: tim_one Comment: +1. I think .popitem() is a good addition, providing a (now predictably) efficient way to do something useful that couldn't be done efficiently before, and with no bad effects on time or space use elsewhere. I don't see any real point to additional .popkey() or .popvalue() methods. The patch is missing: + Docs. + Test cases. + docstrings (although all of dictobject.c is missing docstrings). I would really like to understand why the original suggestion did good for you. For starters, which platform did you run it on? I don't see anything in the code that should vary across 32-bit platforms (not the string hash codes, or the GF-cycling business, ... even computing the initial value of incr is careful to cast hash to unsigned before the right shift). On the platform where it did help, what does this print (w/ the current patch -- this will reveal the internal storage order for a and b)? N = 128 ints = range(N) a = {} for i in ints: a[`i`] = i b = a.copy() aorder = [a.popitem()[1] for i in ints] border = [b.popitem()[1] for i in ints] assert not a assert not b for aval, bval in zip(aorder, border): print "%6d %6d" % (aval, bval), if aval == bval: print "ok" else: print "******* out of synch *******" Here's what I get: 34 34 ok 35 35 ok 36 36 ok 37 37 ok 30 30 ok 31 31 ok 32 32 ok 33 33 ok 38 95 ******* out of synch ******* 39 38 ******* out of synch ******* 78 39 ******* out of synch ******* 79 78 ******* out of synch ******* 107 79 ******* out of synch ******* 106 107 ******* out of synch ******* 101 106 ******* out of synch ******* 100 101 ******* out of synch ******* 103 100 ******* out of synch ******* 102 103 ******* out of synch ******* 70 102 ******* out of synch ******* 71 70 ******* out of synch ******* 72 71 ******* out of synch ******* 73 72 ******* out of synch ******* 74 73 ******* out of synch ******* 75 74 ******* out of synch ******* 76 75 ******* out of synch ******* 77 76 ******* out of synch ******* 59 77 ******* out of synch ******* 54 108 ******* out of synch ******* 55 9 ******* out of synch ******* 58 7 ******* out of synch ******* 9 5 ******* out of synch ******* 7 3 ******* out of synch ******* 5 1 ******* out of synch ******* 3 41 ******* out of synch ******* 1 40 ******* out of synch ******* 41 43 ******* out of synch ******* 40 42 ******* out of synch ******* 43 45 ******* out of synch ******* 42 44 ******* out of synch ******* 45 47 ******* out of synch ******* 44 46 ******* out of synch ******* 47 49 ******* out of synch ******* 46 48 ******* out of synch ******* 49 85 ******* out of synch ******* 48 84 ******* out of synch ******* 85 87 ******* out of synch ******* 84 86 ******* out of synch ******* 87 81 ******* out of synch ******* 86 80 ******* out of synch ******* 81 83 ******* out of synch ******* 80 82 ******* out of synch ******* 83 112 ******* out of synch ******* 82 113 ******* out of synch ******* 112 110 ******* out of synch ******* 113 111 ******* out of synch ******* 110 89 ******* out of synch ******* 111 88 ******* out of synch ******* 89 114 ******* out of synch ******* 88 115 ******* out of synch ******* 114 99 ******* out of synch ******* 115 124 ******* out of synch ******* 122 52 ******* out of synch ******* 120 53 ******* out of synch ******* 117 50 ******* out of synch ******* 52 51 ******* out of synch ******* 53 56 ******* out of synch ******* 50 57 ******* out of synch ******* 51 54 ******* out of synch ******* 56 55 ******* out of synch ******* 57 16 ******* out of synch ******* 18 17 ******* out of synch ******* 19 58 ******* out of synch ******* 16 59 ******* out of synch ******* 17 19 ******* out of synch ******* 14 13 ******* out of synch ******* 15 18 ******* out of synch ******* 12 11 ******* out of synch ******* 13 96 ******* out of synch ******* 10 97 ******* out of synch ******* 11 94 ******* out of synch ******* 96 14 ******* out of synch ******* 97 92 ******* out of synch ******* 94 93 ******* out of synch ******* 95 90 ******* out of synch ******* 92 91 ******* out of synch ******* 93 127 ******* out of synch ******* 90 126 ******* out of synch ******* 91 125 ******* out of synch ******* 127 15 ******* out of synch ******* 126 123 ******* out of synch ******* 125 122 ******* out of synch ******* 124 98 ******* out of synch ******* 123 120 ******* out of synch ******* 116 118 ******* out of synch ******* 98 119 ******* out of synch ******* 99 10 ******* out of synch ******* 118 12 ******* out of synch ******* 119 69 ******* out of synch ******* 104 8 ******* out of synch ******* 109 6 ******* out of synch ******* 8 4 ******* out of synch ******* 6 2 ******* out of synch ******* 4 0 ******* out of synch ******* 2 61 ******* out of synch ******* 0 29 ******* out of synch ******* 29 28 ******* out of synch ******* 28 62 ******* out of synch ******* 23 23 ok 22 22 ok 21 21 ok 20 20 ok 27 27 ok 26 26 ok 25 25 ok 24 24 ok 105 105 ok 69 104 ******* out of synch ******* 68 68 ok 67 67 ok 66 66 ok 65 65 ok 64 64 ok 63 63 ok 62 117 ******* out of synch ******* 61 116 ******* out of synch ******* 60 60 ok 108 109 ******* out of synch ******* 121 121 ok ------------------------------------------------------- Date: 2000-Dec-09 14:01 By: gvanrossum Comment: New patch uploaded. This is really Tim Peters's patch, including the correction he posted on Sat, 9 Dec 2000 16:09:30. I don't know why Tim's original suggested "improvement" worked so well for me -- it really did improve a lot over the original version. Oh well. ------------------------------------------------------- Date: 2000-Dec-08 10:28 By: gvanrossum Comment: Tim (or anyone else): can you improve this? It has excellent performance as long as you only do a single dictionary at a time, but goes quadratic if you call popitem() for two identical dictionaries in lock-step. Maybe jumping criss-cross through the hash table like lookdict does would improve that; but I don't understand the math used for that ("Cycle through GF(2^n)-{0}" ???). Here's a test program: import time for run in range(1000): print "run =", run for log2size in range(10, 18): size = 2**log2size print "log2size =", log2size, print "size =", size a = {} t0 = time.clock() while 1: i = len(a) if i >= size: break a[`i`] = i t1 = time.clock() print "%.1f usec per item to build (total %.3f sec)" % ( (1e6*(t1-t0)/size), t1-t0) b = a.copy() t0 = time.clock() try: while 1: a.popitem() b.popitem() except KeyError: pass t1 = time.clock() print "%.1f usec per item to destroy twins (total %.3f sec)" % ( (1e6*(t1-t0)/size), t1-t0) assert not a, a assert not b, b ------------------------------------------------------- Date: 2000-Dec-08 10:58 By: tim_one Comment: While I haven't yet actually tried it, I'm pretty sure you'd get much better performance (linear) in your test case by changing "finger = i+1" to "finger = i", and no matter how many dicts you march over in lockstep. In the case of a single dict, it adds a trivial amount of overhead per lookup (one extra C-speed trip around the loop per lookup). The reason "GF(2^n)-{)}" confuses you is because he should have written "**" instead of "^" . In essense, it means "visit each of the 2**n bit patterns exactly once, except for the all-zero pattern", and the "GF" means Galois Field, the theoretical basis for why the bit manipulations actually achieve that. I don't believe it would help: the sequence of bit patterns visited remains fixed, and if you continue to move the finger "one beyond" you'll get the same problem (the first pass thru two lockstep iters creates gaps that the second pass has to skip over; the second pass doubles the size of those gaps; the third pass doubles them again, etc). I agree that sharing one finger is very attractive. +1. ------------------------------------------------------- Date: 2000-Dec-08 11:04 By: gvanrossum Comment: New patch with Tim's suggestion. Works well! ------------------------------------------------------- Date: 2000-Dec-08 14:55 By: tim_one Comment: Actually, your test program with the new patch continues to show rotten behavior for me. dict.copy() returns a dict with the same value, but not necessarily the same internal structure. This is easy to see by changing the test's inner loop to while 1: gota = a.popitem() gotb = b.popitem() assert gota == gotb, (gota, gotb, len(a), len(b)) This fails instantly for me: run = 0 log2size = 10 size = 1024 10.2 usec per item to build (total 0.010 sec) Traceback (most recent call last): File "tdict.py", line 27, in ? assert gota == gotb, (gota, gotb, len(a), len(b)) AssertionError: (('773', 773), ('479', 479), 1023, 1023) If I make the dicts truly identical, by building b via the same operations in the same order as occurred for a, then the assert doesn't trigger and performance is wonderful (deleting the dicts is faster than building them). But in that case, the original "finger = i+1" is also very good (just a little slower). My head analysis of that case was wrong: the first pass does create a checkerboard pattern in both dicts, but the second pass systematically hits the holes created by the first pass. Are you sure your test program worked a lot better after the patch? Best I can tell, what I'm seeing has very little to do with the finger strategy and very much to do with accidents in the way dict.copy() works. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102733&group_id=5470 From noreply@sourceforge.net Mon Dec 11 03:23:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 10 Dec 2000 19:23:48 -0800 Subject: [Patches] [Patch #102733] {}.popitem() implementation Message-ID: <200012110323.TAA05294@usw-sf-web2.sourceforge.net> Patch #102733 has been updated. Project: python Category: core (C code) Status: Accepted Submitted by: gvanrossum Assigned to : gvanrossum Summary: {}.popitem() implementation Follow-Ups: Date: 2000-Dec-10 19:23 By: tim_one Comment: OK, looks good. Changed status to Accepted and assigned back to you for checkin. ------------------------------------------------------- Date: 2000-Dec-10 19:07 By: gvanrossum Comment: Here's a new version. Unchanged Objects/dictobject.c patch; added Lib/UserDict.py, Lib/test/test_types.py, Doc/lib/libstdtypes.tex. I'll check it in after a 24 hour wait period. ------------------------------------------------------- Date: 2000-Dec-10 19:03 By: tim_one Comment: Good! Not all is lost: random blobs of the string and dict code got a thorough code review out of it . BTW, if you're going to Pronounce favorably on .popitem(), feel free to tell me to finish the job (just an offer, not a request -- either way is fine by me). ------------------------------------------------------- Date: 2000-Dec-10 18:44 By: gvanrossum Comment: I get the exact same output as you, Tim. I tried to reproduce my original results with the original implementation again, and indeed I get the same times with or without your "improvement". My best guess as to why I thought it made a difference is that I misread the poorly designed output from the test program. I'll add docs and test cases. ------------------------------------------------------- Date: 2000-Dec-10 15:12 By: tim_one Comment: +1. I think .popitem() is a good addition, providing a (now predictably) efficient way to do something useful that couldn't be done efficiently before, and with no bad effects on time or space use elsewhere. I don't see any real point to additional .popkey() or .popvalue() methods. The patch is missing: + Docs. + Test cases. + docstrings (although all of dictobject.c is missing docstrings). I would really like to understand why the original suggestion did good for you. For starters, which platform did you run it on? I don't see anything in the code that should vary across 32-bit platforms (not the string hash codes, or the GF-cycling business, ... even computing the initial value of incr is careful to cast hash to unsigned before the right shift). On the platform where it did help, what does this print (w/ the current patch -- this will reveal the internal storage order for a and b)? N = 128 ints = range(N) a = {} for i in ints: a[`i`] = i b = a.copy() aorder = [a.popitem()[1] for i in ints] border = [b.popitem()[1] for i in ints] assert not a assert not b for aval, bval in zip(aorder, border): print "%6d %6d" % (aval, bval), if aval == bval: print "ok" else: print "******* out of synch *******" Here's what I get: 34 34 ok 35 35 ok 36 36 ok 37 37 ok 30 30 ok 31 31 ok 32 32 ok 33 33 ok 38 95 ******* out of synch ******* 39 38 ******* out of synch ******* 78 39 ******* out of synch ******* 79 78 ******* out of synch ******* 107 79 ******* out of synch ******* 106 107 ******* out of synch ******* 101 106 ******* out of synch ******* 100 101 ******* out of synch ******* 103 100 ******* out of synch ******* 102 103 ******* out of synch ******* 70 102 ******* out of synch ******* 71 70 ******* out of synch ******* 72 71 ******* out of synch ******* 73 72 ******* out of synch ******* 74 73 ******* out of synch ******* 75 74 ******* out of synch ******* 76 75 ******* out of synch ******* 77 76 ******* out of synch ******* 59 77 ******* out of synch ******* 54 108 ******* out of synch ******* 55 9 ******* out of synch ******* 58 7 ******* out of synch ******* 9 5 ******* out of synch ******* 7 3 ******* out of synch ******* 5 1 ******* out of synch ******* 3 41 ******* out of synch ******* 1 40 ******* out of synch ******* 41 43 ******* out of synch ******* 40 42 ******* out of synch ******* 43 45 ******* out of synch ******* 42 44 ******* out of synch ******* 45 47 ******* out of synch ******* 44 46 ******* out of synch ******* 47 49 ******* out of synch ******* 46 48 ******* out of synch ******* 49 85 ******* out of synch ******* 48 84 ******* out of synch ******* 85 87 ******* out of synch ******* 84 86 ******* out of synch ******* 87 81 ******* out of synch ******* 86 80 ******* out of synch ******* 81 83 ******* out of synch ******* 80 82 ******* out of synch ******* 83 112 ******* out of synch ******* 82 113 ******* out of synch ******* 112 110 ******* out of synch ******* 113 111 ******* out of synch ******* 110 89 ******* out of synch ******* 111 88 ******* out of synch ******* 89 114 ******* out of synch ******* 88 115 ******* out of synch ******* 114 99 ******* out of synch ******* 115 124 ******* out of synch ******* 122 52 ******* out of synch ******* 120 53 ******* out of synch ******* 117 50 ******* out of synch ******* 52 51 ******* out of synch ******* 53 56 ******* out of synch ******* 50 57 ******* out of synch ******* 51 54 ******* out of synch ******* 56 55 ******* out of synch ******* 57 16 ******* out of synch ******* 18 17 ******* out of synch ******* 19 58 ******* out of synch ******* 16 59 ******* out of synch ******* 17 19 ******* out of synch ******* 14 13 ******* out of synch ******* 15 18 ******* out of synch ******* 12 11 ******* out of synch ******* 13 96 ******* out of synch ******* 10 97 ******* out of synch ******* 11 94 ******* out of synch ******* 96 14 ******* out of synch ******* 97 92 ******* out of synch ******* 94 93 ******* out of synch ******* 95 90 ******* out of synch ******* 92 91 ******* out of synch ******* 93 127 ******* out of synch ******* 90 126 ******* out of synch ******* 91 125 ******* out of synch ******* 127 15 ******* out of synch ******* 126 123 ******* out of synch ******* 125 122 ******* out of synch ******* 124 98 ******* out of synch ******* 123 120 ******* out of synch ******* 116 118 ******* out of synch ******* 98 119 ******* out of synch ******* 99 10 ******* out of synch ******* 118 12 ******* out of synch ******* 119 69 ******* out of synch ******* 104 8 ******* out of synch ******* 109 6 ******* out of synch ******* 8 4 ******* out of synch ******* 6 2 ******* out of synch ******* 4 0 ******* out of synch ******* 2 61 ******* out of synch ******* 0 29 ******* out of synch ******* 29 28 ******* out of synch ******* 28 62 ******* out of synch ******* 23 23 ok 22 22 ok 21 21 ok 20 20 ok 27 27 ok 26 26 ok 25 25 ok 24 24 ok 105 105 ok 69 104 ******* out of synch ******* 68 68 ok 67 67 ok 66 66 ok 65 65 ok 64 64 ok 63 63 ok 62 117 ******* out of synch ******* 61 116 ******* out of synch ******* 60 60 ok 108 109 ******* out of synch ******* 121 121 ok ------------------------------------------------------- Date: 2000-Dec-09 14:01 By: gvanrossum Comment: New patch uploaded. This is really Tim Peters's patch, including the correction he posted on Sat, 9 Dec 2000 16:09:30. I don't know why Tim's original suggested "improvement" worked so well for me -- it really did improve a lot over the original version. Oh well. ------------------------------------------------------- Date: 2000-Dec-08 10:28 By: gvanrossum Comment: Tim (or anyone else): can you improve this? It has excellent performance as long as you only do a single dictionary at a time, but goes quadratic if you call popitem() for two identical dictionaries in lock-step. Maybe jumping criss-cross through the hash table like lookdict does would improve that; but I don't understand the math used for that ("Cycle through GF(2^n)-{0}" ???). Here's a test program: import time for run in range(1000): print "run =", run for log2size in range(10, 18): size = 2**log2size print "log2size =", log2size, print "size =", size a = {} t0 = time.clock() while 1: i = len(a) if i >= size: break a[`i`] = i t1 = time.clock() print "%.1f usec per item to build (total %.3f sec)" % ( (1e6*(t1-t0)/size), t1-t0) b = a.copy() t0 = time.clock() try: while 1: a.popitem() b.popitem() except KeyError: pass t1 = time.clock() print "%.1f usec per item to destroy twins (total %.3f sec)" % ( (1e6*(t1-t0)/size), t1-t0) assert not a, a assert not b, b ------------------------------------------------------- Date: 2000-Dec-08 10:58 By: tim_one Comment: While I haven't yet actually tried it, I'm pretty sure you'd get much better performance (linear) in your test case by changing "finger = i+1" to "finger = i", and no matter how many dicts you march over in lockstep. In the case of a single dict, it adds a trivial amount of overhead per lookup (one extra C-speed trip around the loop per lookup). The reason "GF(2^n)-{)}" confuses you is because he should have written "**" instead of "^" . In essense, it means "visit each of the 2**n bit patterns exactly once, except for the all-zero pattern", and the "GF" means Galois Field, the theoretical basis for why the bit manipulations actually achieve that. I don't believe it would help: the sequence of bit patterns visited remains fixed, and if you continue to move the finger "one beyond" you'll get the same problem (the first pass thru two lockstep iters creates gaps that the second pass has to skip over; the second pass doubles the size of those gaps; the third pass doubles them again, etc). I agree that sharing one finger is very attractive. +1. ------------------------------------------------------- Date: 2000-Dec-08 11:04 By: gvanrossum Comment: New patch with Tim's suggestion. Works well! ------------------------------------------------------- Date: 2000-Dec-08 14:55 By: tim_one Comment: Actually, your test program with the new patch continues to show rotten behavior for me. dict.copy() returns a dict with the same value, but not necessarily the same internal structure. This is easy to see by changing the test's inner loop to while 1: gota = a.popitem() gotb = b.popitem() assert gota == gotb, (gota, gotb, len(a), len(b)) This fails instantly for me: run = 0 log2size = 10 size = 1024 10.2 usec per item to build (total 0.010 sec) Traceback (most recent call last): File "tdict.py", line 27, in ? assert gota == gotb, (gota, gotb, len(a), len(b)) AssertionError: (('773', 773), ('479', 479), 1023, 1023) If I make the dicts truly identical, by building b via the same operations in the same order as occurred for a, then the assert doesn't trigger and performance is wonderful (deleting the dicts is faster than building them). But in that case, the original "finger = i+1" is also very good (just a little slower). My head analysis of that case was wrong: the first pass does create a checkerboard pattern in both dicts, but the second pass systematically hits the holes created by the first pass. Are you sure your test program worked a lot better after the patch? Best I can tell, what I'm seeing has very little to do with the finger strategy and very much to do with accidents in the way dict.copy() works. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102733&group_id=5470 From noreply@sourceforge.net Mon Dec 11 04:09:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 10 Dec 2000 20:09:23 -0800 Subject: [Patches] [Patch #102715] Prototype for PEP 230 - warnings Message-ID: <200012110409.UAA00704@usw-sf-web1.sourceforge.net> Patch #102715 has been updated. Project: python Category: core (C code) Status: Open Submitted by: gvanrossum Assigned to : gvanrossum Summary: Prototype for PEP 230 - warnings Follow-Ups: Date: 2000-Dec-10 20:09 By: gvanrossum Comment: All the C code is redone, to postpone the import of warnings.py until PyErr_Warn() is actually called. This should also be more robust in the light of multiple interpreters (no globals are used). The warning category exceptions are now created as standard exceptions. The Python code redone for the new situation, and with some of Paul Prescod's suggestions implemented. ------------------------------------------------------- Date: 2000-Dec-08 14:38 By: gvanrossum Comment: Here's a more elaborate version of the patch, that adds the C API. (The C API imports warnings.py though.) Note that in contradition to PEP 230, the C routine to issue a warning is called PyErr_Warn(category, message) rather than Py_Warn(message, category). This is open for discussion. Since the category is a kind of exception, it seems to make sense to be consistent with the other PyErr_*() functions rather than with the Python warn(message[, category]) function. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102715&group_id=5470 From noreply@sourceforge.net Mon Dec 11 04:11:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 10 Dec 2000 20:11:00 -0800 Subject: [Patches] [Patch #102715] Prototype for PEP 230 - warnings Message-ID: <200012110411.UAA06260@usw-sf-web2.sourceforge.net> Patch #102715 has been updated. Project: python Category: core (C code) Status: Open Submitted by: gvanrossum Assigned to : tim_one Summary: Prototype for PEP 230 - warnings Follow-Ups: Date: 2000-Dec-10 20:11 By: gvanrossum Comment: Assigned to Tim since he's awake. ------------------------------------------------------- Date: 2000-Dec-10 20:09 By: gvanrossum Comment: All the C code is redone, to postpone the import of warnings.py until PyErr_Warn() is actually called. This should also be more robust in the light of multiple interpreters (no globals are used). The warning category exceptions are now created as standard exceptions. The Python code redone for the new situation, and with some of Paul Prescod's suggestions implemented. ------------------------------------------------------- Date: 2000-Dec-08 14:38 By: gvanrossum Comment: Here's a more elaborate version of the patch, that adds the C API. (The C API imports warnings.py though.) Note that in contradition to PEP 230, the C routine to issue a warning is called PyErr_Warn(category, message) rather than Py_Warn(message, category). This is open for discussion. Since the category is a kind of exception, it seems to make sense to be consistent with the other PyErr_*() functions rather than with the Python warn(message[, category]) function. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102715&group_id=5470 From noreply@sourceforge.net Mon Dec 11 15:02:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Dec 2000 07:02:44 -0800 Subject: [Patches] [Patch #102715] Prototype for PEP 230 - warnings Message-ID: <200012111502.HAA19744@usw-sf-web2.sourceforge.net> Patch #102715 has been updated. Project: python Category: core (C code) Status: Open Submitted by: gvanrossum Assigned to : tim_one Summary: Prototype for PEP 230 - warnings Follow-Ups: Date: 2000-Dec-11 07:02 By: gvanrossum Comment: I have a new version fof warnings.py that fixes a few nits, but there's a problem with SF that prevents me from uploading it. Mail me. ------------------------------------------------------- Date: 2000-Dec-10 20:11 By: gvanrossum Comment: Assigned to Tim since he's awake. ------------------------------------------------------- Date: 2000-Dec-10 20:09 By: gvanrossum Comment: All the C code is redone, to postpone the import of warnings.py until PyErr_Warn() is actually called. This should also be more robust in the light of multiple interpreters (no globals are used). The warning category exceptions are now created as standard exceptions. The Python code redone for the new situation, and with some of Paul Prescod's suggestions implemented. ------------------------------------------------------- Date: 2000-Dec-08 14:38 By: gvanrossum Comment: Here's a more elaborate version of the patch, that adds the C API. (The C API imports warnings.py though.) Note that in contradition to PEP 230, the C routine to issue a warning is called PyErr_Warn(category, message) rather than Py_Warn(message, category). This is open for discussion. Since the category is a kind of exception, it seems to make sense to be consistent with the other PyErr_*() functions rather than with the Python warn(message[, category]) function. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102715&group_id=5470 From noreply@sourceforge.net Mon Dec 11 16:03:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Dec 2000 08:03:38 -0800 Subject: [Patches] [Patch #102780] SET_LINENO for augassign Message-ID: <200012111603.IAA17782@usw-sf-web3.sourceforge.net> Patch #102780 has been updated. Project: python Category: demos and tools Status: Open Submitted by: nascheme Assigned to : nobody Summary: SET_LINENO for augassign ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102780&group_id=5470 From noreply@sourceforge.net Mon Dec 11 16:05:39 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Dec 2000 08:05:39 -0800 Subject: [Patches] [Patch #102780] SET_LINENO for augassign Message-ID: <200012111605.IAA17842@usw-sf-web3.sourceforge.net> Patch #102780 has been updated. Project: python Category: demos and tools Status: Open Submitted by: nascheme Assigned to : jhylton Summary: SET_LINENO for augassign Follow-Ups: Date: 2000-Dec-11 08:05 By: nascheme Comment: Line numbers are currently not set for augmented assignment statements for code compiled by Tools/compiler. Here is a one line fix. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102780&group_id=5470 From noreply@sourceforge.net Mon Dec 11 18:32:51 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Dec 2000 10:32:51 -0800 Subject: [Patches] [Patch #102715] Prototype for PEP 230 - warnings Message-ID: <200012111832.KAA21636@usw-sf-web3.sourceforge.net> Patch #102715 has been updated. Project: python Category: core (C code) Status: Open Submitted by: gvanrossum Assigned to : tim_one Summary: Prototype for PEP 230 - warnings Follow-Ups: Date: 2000-Dec-11 07:02 By: gvanrossum Comment: I have a new version fof warnings.py that fixes a few nits, but there's a problem with SF that prevents me from uploading it. Mail me. ------------------------------------------------------- Date: 2000-Dec-10 20:11 By: gvanrossum Comment: Assigned to Tim since he's awake. ------------------------------------------------------- Date: 2000-Dec-10 20:09 By: gvanrossum Comment: All the C code is redone, to postpone the import of warnings.py until PyErr_Warn() is actually called. This should also be more robust in the light of multiple interpreters (no globals are used). The warning category exceptions are now created as standard exceptions. The Python code redone for the new situation, and with some of Paul Prescod's suggestions implemented. ------------------------------------------------------- Date: 2000-Dec-08 14:38 By: gvanrossum Comment: Here's a more elaborate version of the patch, that adds the C API. (The C API imports warnings.py though.) Note that in contradition to PEP 230, the C routine to issue a warning is called PyErr_Warn(category, message) rather than Py_Warn(message, category). This is open for discussion. Since the category is a kind of exception, it seems to make sense to be consistent with the other PyErr_*() functions rather than with the Python warn(message[, category]) function. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102715&group_id=5470 From noreply@sourceforge.net Mon Dec 11 18:36:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Dec 2000 10:36:29 -0800 Subject: [Patches] [Patch #102715] Prototype for PEP 230 - warnings Message-ID: <200012111836.KAA21715@usw-sf-web3.sourceforge.net> Patch #102715 has been updated. Project: python Category: core (C code) Status: Open Submitted by: gvanrossum Assigned to : bwarsaw Summary: Prototype for PEP 230 - warnings Follow-Ups: Date: 2000-Dec-11 10:36 By: gvanrossum Comment: Latest version uploaded (the SF glitch seems fixed). Just for fun, this adds warnings for raising string exceptions and raising class exception that aren't derived from Exception, and it also adds warnings to the functions in the string module and to the strop module. These need work, but give an indication that this is a useful feature: it caught lots of offenders in the test suite! (Patches to sre.py and sre_parse.py included.) Assigning to Barry if he wants to review it. ------------------------------------------------------- Date: 2000-Dec-11 07:02 By: gvanrossum Comment: I have a new version fof warnings.py that fixes a few nits, but there's a problem with SF that prevents me from uploading it. Mail me. ------------------------------------------------------- Date: 2000-Dec-10 20:11 By: gvanrossum Comment: Assigned to Tim since he's awake. ------------------------------------------------------- Date: 2000-Dec-10 20:09 By: gvanrossum Comment: All the C code is redone, to postpone the import of warnings.py until PyErr_Warn() is actually called. This should also be more robust in the light of multiple interpreters (no globals are used). The warning category exceptions are now created as standard exceptions. The Python code redone for the new situation, and with some of Paul Prescod's suggestions implemented. ------------------------------------------------------- Date: 2000-Dec-08 14:38 By: gvanrossum Comment: Here's a more elaborate version of the patch, that adds the C API. (The C API imports warnings.py though.) Note that in contradition to PEP 230, the C routine to issue a warning is called PyErr_Warn(category, message) rather than Py_Warn(message, category). This is open for discussion. Since the category is a kind of exception, it seems to make sense to be consistent with the other PyErr_*() functions rather than with the Python warn(message[, category]) function. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102715&group_id=5470 From noreply@sourceforge.net Mon Dec 11 19:14:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Dec 2000 11:14:28 -0800 Subject: [Patches] [Patch #102652] Reference implementation for PEP 208 (coercion) Message-ID: <200012111914.LAA17516@usw-sf-web1.sourceforge.net> Patch #102652 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nascheme Assigned to : nobody Summary: Reference implementation for PEP 208 (coercion) Follow-Ups: Date: 2000-Dec-11 11:14 By: nascheme Comment: Operations on instances now call __coerce__ if it exists. I think the patch is now complete. Converting other builtin types to "new style numbers" can be done with a separate patch. ------------------------------------------------------- Date: 2000-Dec-04 18:45 By: nascheme Comment: This patch is a little rough yet but I guess its better here than on my website. The major source of ugliness PyObject_Compare. ------------------------------------------------------- Date: 2000-Dec-06 08:00 By: nascheme Comment: Cleaned up PyObject_Compare() (still needs to be optimized). __coerce__ on instances needs be to sorted out. It should probably be called if it exists for backwards compatibility. Longs and complex types still need to be converted to new style numbers. ------------------------------------------------------- Date: 2000-Dec-07 18:34 By: nascheme Comment: Fix some reference counts. Make use of macros to reduce duplicate code. Remove some unused code in classobject. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102652&group_id=5470 From noreply@sourceforge.net Mon Dec 11 20:35:09 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Dec 2000 12:35:09 -0800 Subject: [Patches] [Patch #102746] strip \n so that Unix and Windows dbs are interoperable Message-ID: <200012112035.MAA28000@usw-sf-web2.sourceforge.net> Patch #102746 has been updated. Project: python Category: Modules Status: Closed Submitted by: nobody Assigned to : gvanrossum Summary: strip \n so that Unix and Windows dbs are interoperable Follow-Ups: Date: 2000-Dec-11 12:35 By: gvanrossum Comment: Thanks! I've checked in a slight variation, which uses the .rstrip() method rather than importing the string module. ------------------------------------------------------- Date: 2000-Dec-08 22:49 By: eaj Comment: Oops. Submitted without logging in. This is a simple fix. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102746&group_id=5470 From noreply@sourceforge.net Mon Dec 11 20:35:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Dec 2000 12:35:25 -0800 Subject: [Patches] [Patch #102746] strip \n so that Unix and Windows dbs are interoperable Message-ID: <200012112035.MAA24746@usw-sf-web3.sourceforge.net> Patch #102746 has been updated. Project: python Category: library Status: Closed Submitted by: nobody Assigned to : gvanrossum Summary: strip \n so that Unix and Windows dbs are interoperable Follow-Ups: Date: 2000-Dec-11 12:35 By: gvanrossum Comment: Thanks! I've checked in a slight variation, which uses the .rstrip() method rather than importing the string module. ------------------------------------------------------- Date: 2000-Dec-08 22:49 By: eaj Comment: Oops. Submitted without logging in. This is a simple fix. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102746&group_id=5470 From noreply@sourceforge.net Mon Dec 11 20:39:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Dec 2000 12:39:54 -0800 Subject: [Patches] [Patch #102652] Reference implementation for PEP 208 (coercion) Message-ID: <200012112039.MAA28126@usw-sf-web2.sourceforge.net> Patch #102652 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nascheme Assigned to : gvanrossum Summary: Reference implementation for PEP 208 (coercion) Follow-Ups: Date: 2000-Dec-11 12:39 By: gvanrossum Comment: I'm now actively reviewing Neil's code (while at the same time trying to figure out how to fit in rich comparisons). ------------------------------------------------------- Date: 2000-Dec-11 11:14 By: nascheme Comment: Operations on instances now call __coerce__ if it exists. I think the patch is now complete. Converting other builtin types to "new style numbers" can be done with a separate patch. ------------------------------------------------------- Date: 2000-Dec-04 18:45 By: nascheme Comment: This patch is a little rough yet but I guess its better here than on my website. The major source of ugliness PyObject_Compare. ------------------------------------------------------- Date: 2000-Dec-06 08:00 By: nascheme Comment: Cleaned up PyObject_Compare() (still needs to be optimized). __coerce__ on instances needs be to sorted out. It should probably be called if it exists for backwards compatibility. Longs and complex types still need to be converted to new style numbers. ------------------------------------------------------- Date: 2000-Dec-07 18:34 By: nascheme Comment: Fix some reference counts. Make use of macros to reduce duplicate code. Remove some unused code in classobject. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102652&group_id=5470 From noreply@sourceforge.net Mon Dec 11 20:40:05 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Dec 2000 12:40:05 -0800 Subject: [Patches] [Patch #102588] PEP 229: Use Distutils to build Message-ID: <200012112040.MAA24879@usw-sf-web3.sourceforge.net> Patch #102588 has been updated. Project: python Category: Build Status: Open Submitted by: akuchling Assigned to : akuchling Summary: PEP 229: Use Distutils to build Follow-Ups: Date: 2000-Nov-29 20:18 By: akuchling Comment: Not ready to be reviewed yet; I'm submitting this patch just to demonstrate some progress. This version of the patch just removes the use of makesetup in building the interpreter, and hard-codes the presence of strop, posix, and _sre. Still to be done: write the top-level setup.py, and handle a few tricky bits such as the signalmodule. ------------------------------------------------------- Date: 2000-Dec-01 15:26 By: gvanrossum Comment: Would you mind explaining what the patch does in the PEP? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102588&group_id=5470 From noreply@sourceforge.net Mon Dec 11 20:40:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Dec 2000 12:40:21 -0800 Subject: [Patches] [Patch #102626] Add a .first{key/item/value}() method to dictionaries Message-ID: <200012112040.MAA19968@usw-sf-web1.sourceforge.net> Patch #102626 has been updated. Project: python Category: core (C code) Status: Rejected Submitted by: moshez Assigned to : nobody Summary: Add a .first{key/item/value}() method to dictionaries Follow-Ups: Date: 2000-Dec-11 12:40 By: gvanrossum Comment: Rejected in favor of popitem(). ------------------------------------------------------- Date: 2000-Dec-03 03:51 By: moshez Comment: OK, this fixes some problem with the applied-and-retracted version of the methods: * It adds exception-information to the docos * It uses _SET_ITEM and not _SetItem for more efficiency. I will still build skewed dictionaries. Opinion: maybe it would do to rehash the dictionary when there are too few items too? Wouldn't that solve everything better then Tim's weird "let's keep a pointer into the dictionary" dict? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102626&group_id=5470 From noreply@sourceforge.net Mon Dec 11 20:42:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Dec 2000 12:42:01 -0800 Subject: [Patches] [Patch #102627] A Set class which *can* use the .firstkey() patch Message-ID: <200012112042.MAA28189@usw-sf-web2.sourceforge.net> Patch #102627 has been updated. Project: python Category: library Status: Postponed Submitted by: moshez Assigned to : nobody Summary: A Set class which *can* use the .firstkey() patch Follow-Ups: Date: 2000-Dec-11 12:42 By: gvanrossum Comment: Changed status to Postponed -- this would need a lot of work. Also, there's a PEP on a Set addition (in the pie-in-the-sky category). All work on adding sets to Python should go through that PEP. (And note that there are several other competing set classes.) ------------------------------------------------------- Date: 2000-Dec-03 04:47 By: moshez Comment: OK, this patch implements a Set class with an added advantage that on 102626-patched interpreter it has a method called .element() which returns some element of the set. Short summary: * supports boolean operators, substraction * supports iteration semi-efficiently * supports checking for containment semi-efficiently * supports auto-freezing when hash() is called, so can be used as key in dictionaries, and so, as an element in sets. Greg Wilson: see if this doesn't solve 95% of the problem you're trying to solve with the Set built-in type PEP. ------------------------------------------------------- Date: 2000-Dec-06 10:04 By: gvanrossum Comment: I thought that instead of firstkey() we were going to implement popitem() instead? ------------------------------------------------------- Date: 2000-Dec-06 10:46 By: tim_one Comment: Changed Category to Library. Comments: Style: don't use hard tabs; add doc strings. Space efficiency: "_frozen = 0" is better at class level (most uses of sets never need it). __hash__: (1) you can cache the hash if the set is frozen, and in my experience that's important for efficiency. (2) it doesn't work correctly, although it may take some effort to provoke a failure. The problem is that you're deferring to hash(_make_elements()), _make_elements() returns a tuple, and the hash of a tuple depends on the order the keys happen to get materialized. But the hash of a set must be independent of the order the keys happen to get listed. See the code fragments I posted for a correct Set __hash__. __ior__: dict.update is much quicker than explicit iteration. The ability to apply set operators to raw sequences is unimportant, and not fully supported even if that is your intent (e.g., you don't have the "right-side" operators defined here). Confusing: most of the operators are defined in terms of add() and remove(). This will make the error msgs when they're applied to frozen sets confusing, because indirect. It's also much slower than doing the deed directly. In short, this looks like the first Set class someone writes off the top of their head in Python. That isn't bad, but something in the std distribution should be more than a finger exercise. ------------------------------------------------------- Date: 2000-Dec-06 10:55 By: tim_one Comment: Changed Category to Library. Comments: Style: don't use hard tabs; add doc strings. Space efficiency: "_frozen = 0" is better at class level (most uses of sets never need it). __hash__: (1) you can cache the hash if the set is frozen, and in my experience that's important for efficiency. (2) it doesn't work correctly, although it may take some effort to provoke a failure. The problem is that you're deferring to hash(_make_elements()), _make_elements() returns a tuple, and the hash of a tuple depends on the order the keys happen to get materialized. But the hash of a set must be independent of the order the keys happen to get listed. See the code fragments I posted for a correct Set __hash__. __ior__: dict.update is much quicker than explicit iteration. The ability to apply set operators to raw sequences is unimportant, and not fully supported even if that is your intent (e.g., you don't have the "right-side" operators defined here). Confusing: most of the operators are defined in terms of add() and remove(). This will make the error msgs when they're applied to frozen sets confusing, because indirect. It's also much slower than doing the deed directly. In short, this looks like the first Set class someone writes off the top of their head in Python. That isn't bad, but something in the std distribution should be more than a finger exercise. ------------------------------------------------------- Date: 2000-Dec-06 10:57 By: tim_one Comment: Sorry about the duplicate -- I have got to learn to reboot my machine (or does it need a full power cycle?) when a SourceForge page asks whether I want to repost data! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102627&group_id=5470 From noreply@sourceforge.net Mon Dec 11 20:45:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Dec 2000 12:45:00 -0800 Subject: [Patches] [Patch #102638] A patch for gdbmmodule.c, by Damjan Message-ID: <200012112045.MAA20088@usw-sf-web1.sourceforge.net> Patch #102638 has been updated. Project: python Category: Modules Status: Open Submitted by: nobody Assigned to : nobody Summary: A patch for gdbmmodule.c, by Damjan Follow-Ups: Date: 2000-Dec-11 12:45 By: gvanrossum Comment: (1) What does the patch do? (2) Why does it remove the 'f' GDBM_FAST option? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102638&group_id=5470 From noreply@sourceforge.net Mon Dec 11 20:45:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Dec 2000 12:45:40 -0800 Subject: [Patches] [Patch #102737] Add DOM exception classes Message-ID: <200012112045.MAA28302@usw-sf-web2.sourceforge.net> Patch #102737 has been updated. Project: python Category: XML Status: Open Submitted by: loewis Assigned to : fdrake Summary: Add DOM exception classes Follow-Ups: Date: 2000-Dec-08 13:45 By: loewis Comment: This patch adds DOMException and subclasses to xml.dom. It differs from the implementation in PyXML in the following ways: - DOMException is an abstract class, creating DOMException objects by giving a code is supported in PyXML only for backwards compatibility - Default exception message texts (from en_US.py) are not provided. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102737&group_id=5470 From noreply@sourceforge.net Mon Dec 11 20:45:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Dec 2000 12:45:48 -0800 Subject: [Patches] [Patch #102638] A patch for gdbmmodule.c, by Damjan Message-ID: <200012112045.MAA20122@usw-sf-web1.sourceforge.net> Patch #102638 has been updated. Project: python Category: Modules Status: Open Submitted by: nobody Assigned to : gvanrossum Summary: A patch for gdbmmodule.c, by Damjan Follow-Ups: Date: 2000-Dec-11 12:45 By: gvanrossum Comment: (1) What does the patch do? (2) Why does it remove the 'f' GDBM_FAST option? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102638&group_id=5470 From noreply@sourceforge.net Mon Dec 11 21:02:22 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Dec 2000 13:02:22 -0800 Subject: [Patches] [Patch #102737] Add DOM exception classes Message-ID: <200012112102.NAA20550@usw-sf-web1.sourceforge.net> Patch #102737 has been updated. Project: python Category: XML Status: Accepted Submitted by: loewis Assigned to : loewis Summary: Add DOM exception classes Follow-Ups: Date: 2000-Dec-11 13:02 By: fdrake Comment: Looks good to me! Go ahead and check it in. I should be able to look at the other DOM patches this week as well. ------------------------------------------------------- Date: 2000-Dec-08 13:45 By: loewis Comment: This patch adds DOMException and subclasses to xml.dom. It differs from the implementation in PyXML in the following ways: - DOMException is an abstract class, creating DOMException objects by giving a code is supported in PyXML only for backwards compatibility - Default exception message texts (from en_US.py) are not provided. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102737&group_id=5470 From noreply@sourceforge.net Mon Dec 11 22:49:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Dec 2000 14:49:19 -0800 Subject: [Patches] [Patch #102169] Additional docs for __iadd__ hooks Message-ID: <200012112249.OAA28192@usw-sf-web3.sourceforge.net> Patch #102169 has been updated. Project: python Category: documentation Status: Accepted Submitted by: twouters Assigned to : twouters Summary: Additional docs for __iadd__ hooks Follow-Ups: Date: 2000-Dec-11 14:49 By: fdrake Comment: OK, let's check it in (and close the bug) and worry about improvements when there are enough complaints. ;-) Thanks! ------------------------------------------------------- Date: 2000-Oct-30 05:02 By: twouters Comment: 'Fix' for 'bug' #117178: add description of the in-place hooks to the Reference manual, section 3.3. Untested TeX code, but likely to be correct (mostly copy-and-paste work.) ------------------------------------------------------- Date: 2000-Nov-02 10:23 By: fdrake Comment: You really need to provide more specific description of how these methods are supposed to behave (about returning self meaning in-place operation occurred, a new object means replace self with new object (in context), etc. ------------------------------------------------------- Date: 2000-Dec-07 21:19 By: twouters Comment: Slightly better docs, and probably hard to improve without dropping the "expert's eye" look and feel of the reference manual. One nit: it speaks of 'methods' rather than 'functions, because I think it's clearer, in this context. The regular __add__ hooks still speak of 'functions'. Apologies for the time it took me ;P ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102169&group_id=5470 From noreply@sourceforge.net Mon Dec 11 23:12:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Dec 2000 15:12:59 -0800 Subject: [Patches] [Patch #102169] Additional docs for __iadd__ hooks Message-ID: <200012112312.PAA23887@usw-sf-web1.sourceforge.net> Patch #102169 has been updated. Project: python Category: documentation Status: Closed Submitted by: twouters Assigned to : twouters Summary: Additional docs for __iadd__ hooks Follow-Ups: Date: 2000-Dec-11 15:12 By: twouters Comment: Checked in, revision 1.54 of Doc/ref/ref3.tex. ------------------------------------------------------- Date: 2000-Dec-11 14:49 By: fdrake Comment: OK, let's check it in (and close the bug) and worry about improvements when there are enough complaints. ;-) Thanks! ------------------------------------------------------- Date: 2000-Oct-30 05:02 By: twouters Comment: 'Fix' for 'bug' #117178: add description of the in-place hooks to the Reference manual, section 3.3. Untested TeX code, but likely to be correct (mostly copy-and-paste work.) ------------------------------------------------------- Date: 2000-Nov-02 10:23 By: fdrake Comment: You really need to provide more specific description of how these methods are supposed to behave (about returning self meaning in-place operation occurred, a new object means replace self with new object (in context), etc. ------------------------------------------------------- Date: 2000-Dec-07 21:19 By: twouters Comment: Slightly better docs, and probably hard to improve without dropping the "expert's eye" look and feel of the reference manual. One nit: it speaks of 'methods' rather than 'functions, because I think it's clearer, in this context. The regular __add__ hooks still speak of 'functions'. Apologies for the time it took me ;P ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102169&group_id=5470 From noreply@sourceforge.net Tue Dec 12 00:28:09 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Dec 2000 16:28:09 -0800 Subject: [Patches] [Patch #102794] trivial typo fix Message-ID: <200012120028.QAA01233@usw-sf-web2.sourceforge.net> Patch #102794 has been updated. Project: python Category: core (C code) Status: Open Submitted by: cgw Assigned to : nobody Summary: trivial typo fix ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102794&group_id=5470 From noreply@sourceforge.net Tue Dec 12 00:38:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Dec 2000 16:38:21 -0800 Subject: [Patches] [Patch #102794] trivial typo fix Message-ID: <200012120038.QAA30665@usw-sf-web3.sourceforge.net> Patch #102794 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: cgw Assigned to : gvanrossum Summary: trivial typo fix Follow-Ups: Date: 2000-Dec-11 16:38 By: gvanrossum Comment: Gee. Hardly worth the SF overhead. :-) Checked in now. Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102794&group_id=5470 From noreply@sourceforge.net Tue Dec 12 13:44:39 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Dec 2000 05:44:39 -0800 Subject: [Patches] [Patch #102638] A patch for gdbmmodule.c, by Damjan Message-ID: <200012121344.FAA09667@usw-sf-web1.sourceforge.net> Patch #102638 has been updated. Project: python Category: Modules Status: Open Submitted by: nobody Assigned to : montanaro Summary: A patch for gdbmmodule.c, by Damjan Follow-Ups: Date: 2000-Dec-12 05:44 By: gvanrossum Comment: Damjan replied via private mail: """ From the gdbm info page: ...The following may also be logically or'd into the database flags: GDBM_SYNC, which causes all database operations to be synchronized to the disk, and GDBM_NOLOCK, which prevents the library from performing any locking on the database file. The option GDBM_FAST is now obsolete, since `gdbm' defaults to no-sync mode... ^^^^^^^^ (1) My patch adds two options to the gdbm.open(..) function. These are 'u' for GDBM_NOLOCK, and 's' for GDBM_SYNC. (2) GDBM_FAST is obsolete because gdbm defaults to GDBM_FAST, so it's removed. I'm also thinking about adding a lock and unlock methods to the gdbm object, but it seems that a gdbm database can only be locked and not unlocked. """ Can amybody else who knows more about gdbm review the patch please? (Randomly asigned to Skip.) ------------------------------------------------------- Date: 2000-Dec-11 12:45 By: gvanrossum Comment: (1) What does the patch do? (2) Why does it remove the 'f' GDBM_FAST option? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102638&group_id=5470 From noreply@sourceforge.net Tue Dec 12 14:03:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Dec 2000 06:03:13 -0800 Subject: [Patches] [Patch #102638] A patch for gdbmmodule.c, by Damjan Message-ID: <200012121403.GAA18327@usw-sf-web2.sourceforge.net> Patch #102638 has been updated. Project: python Category: Modules Status: Open Submitted by: nobody Assigned to : montanaro Summary: A patch for gdbmmodule.c, by Damjan Follow-Ups: Date: 2000-Dec-12 06:03 By: moshez Comment: Well, from the documentation I have installed on my system (RH 6.2), this patch seems to do the right thing -- for small enough values of the right thing. First of all, 'f' should still translate to GDBM_FAST: it's obsolete, but still supported for backwards compat. and so should we. Second, the string part seems a bit dodgy (isn't there an undefined reference of flags[2] if flags is only the string "r", say? ------------------------------------------------------- Date: 2000-Dec-12 05:44 By: gvanrossum Comment: Damjan replied via private mail: """ From the gdbm info page: ...The following may also be logically or'd into the database flags: GDBM_SYNC, which causes all database operations to be synchronized to the disk, and GDBM_NOLOCK, which prevents the library from performing any locking on the database file. The option GDBM_FAST is now obsolete, since `gdbm' defaults to no-sync mode... ^^^^^^^^ (1) My patch adds two options to the gdbm.open(..) function. These are 'u' for GDBM_NOLOCK, and 's' for GDBM_SYNC. (2) GDBM_FAST is obsolete because gdbm defaults to GDBM_FAST, so it's removed. I'm also thinking about adding a lock and unlock methods to the gdbm object, but it seems that a gdbm database can only be locked and not unlocked. """ Can amybody else who knows more about gdbm review the patch please? (Randomly asigned to Skip.) ------------------------------------------------------- Date: 2000-Dec-11 12:45 By: gvanrossum Comment: (1) What does the patch do? (2) Why does it remove the 'f' GDBM_FAST option? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102638&group_id=5470 From noreply@sourceforge.net Tue Dec 12 14:05:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Dec 2000 06:05:54 -0800 Subject: [Patches] [Patch #102638] A patch for gdbmmodule.c, by Damjan Message-ID: <200012121405.GAA18393@usw-sf-web2.sourceforge.net> Patch #102638 has been updated. Project: python Category: Modules Status: Open Submitted by: nobody Assigned to : moshez Summary: A patch for gdbmmodule.c, by Damjan Follow-Ups: Date: 2000-Dec-12 06:05 By: gvanrossum Comment: Thanks Moshe. I'm assigning the patch to you. Feel free to upload a new version! ------------------------------------------------------- Date: 2000-Dec-12 06:03 By: moshez Comment: Well, from the documentation I have installed on my system (RH 6.2), this patch seems to do the right thing -- for small enough values of the right thing. First of all, 'f' should still translate to GDBM_FAST: it's obsolete, but still supported for backwards compat. and so should we. Second, the string part seems a bit dodgy (isn't there an undefined reference of flags[2] if flags is only the string "r", say? ------------------------------------------------------- Date: 2000-Dec-12 05:44 By: gvanrossum Comment: Damjan replied via private mail: """ From the gdbm info page: ...The following may also be logically or'd into the database flags: GDBM_SYNC, which causes all database operations to be synchronized to the disk, and GDBM_NOLOCK, which prevents the library from performing any locking on the database file. The option GDBM_FAST is now obsolete, since `gdbm' defaults to no-sync mode... ^^^^^^^^ (1) My patch adds two options to the gdbm.open(..) function. These are 'u' for GDBM_NOLOCK, and 's' for GDBM_SYNC. (2) GDBM_FAST is obsolete because gdbm defaults to GDBM_FAST, so it's removed. I'm also thinking about adding a lock and unlock methods to the gdbm object, but it seems that a gdbm database can only be locked and not unlocked. """ Can amybody else who knows more about gdbm review the patch please? (Randomly asigned to Skip.) ------------------------------------------------------- Date: 2000-Dec-11 12:45 By: gvanrossum Comment: (1) What does the patch do? (2) Why does it remove the 'f' GDBM_FAST option? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102638&group_id=5470 From noreply@sourceforge.net Tue Dec 12 14:10:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Dec 2000 06:10:31 -0800 Subject: [Patches] [Patch #102638] A patch for gdbmmodule.c, by Damjan Message-ID: <200012121410.GAA18526@usw-sf-web2.sourceforge.net> Patch #102638 has been updated. Project: python Category: Modules Status: Open Submitted by: nobody Assigned to : moshez Summary: A patch for gdbmmodule.c, by Damjan Follow-Ups: Date: 2000-Dec-12 06:10 By: gvanrossum Comment: Thanks Moshe. I'm assigning the patch to you. Feel free to upload a new version! ------------------------------------------------------- Date: 2000-Dec-12 06:05 By: gvanrossum Comment: Thanks Moshe. I'm assigning the patch to you. Feel free to upload a new version! ------------------------------------------------------- Date: 2000-Dec-12 06:03 By: moshez Comment: Well, from the documentation I have installed on my system (RH 6.2), this patch seems to do the right thing -- for small enough values of the right thing. First of all, 'f' should still translate to GDBM_FAST: it's obsolete, but still supported for backwards compat. and so should we. Second, the string part seems a bit dodgy (isn't there an undefined reference of flags[2] if flags is only the string "r", say? ------------------------------------------------------- Date: 2000-Dec-12 05:44 By: gvanrossum Comment: Damjan replied via private mail: """ From the gdbm info page: ...The following may also be logically or'd into the database flags: GDBM_SYNC, which causes all database operations to be synchronized to the disk, and GDBM_NOLOCK, which prevents the library from performing any locking on the database file. The option GDBM_FAST is now obsolete, since `gdbm' defaults to no-sync mode... ^^^^^^^^ (1) My patch adds two options to the gdbm.open(..) function. These are 'u' for GDBM_NOLOCK, and 's' for GDBM_SYNC. (2) GDBM_FAST is obsolete because gdbm defaults to GDBM_FAST, so it's removed. I'm also thinking about adding a lock and unlock methods to the gdbm object, but it seems that a gdbm database can only be locked and not unlocked. """ Can amybody else who knows more about gdbm review the patch please? (Randomly asigned to Skip.) ------------------------------------------------------- Date: 2000-Dec-11 12:45 By: gvanrossum Comment: (1) What does the patch do? (2) Why does it remove the 'f' GDBM_FAST option? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102638&group_id=5470 From noreply@sourceforge.net Tue Dec 12 16:49:03 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Dec 2000 08:49:03 -0800 Subject: [Patches] [Patch #102802] Support new gdbm flags Message-ID: <200012121649.IAA19343@usw-sf-web3.sourceforge.net> Patch #102802 has been updated. Project: python Category: Modules Status: Open Submitted by: nascheme Assigned to : moshez Summary: Support new gdbm flags Follow-Ups: Date: 2000-Dec-12 08:49 By: nascheme Comment: Alternative to #102638. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102802&group_id=5470 From noreply@sourceforge.net Tue Dec 12 22:03:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Dec 2000 14:03:10 -0800 Subject: [Patches] [Patch #102733] {}.popitem() implementation Message-ID: <200012122203.OAA22520@usw-sf-web1.sourceforge.net> Patch #102733 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: gvanrossum Assigned to : gvanrossum Summary: {}.popitem() implementation Follow-Ups: Date: 2000-Dec-12 14:03 By: gvanrossum Comment: OK, checked in. ------------------------------------------------------- Date: 2000-Dec-10 15:12 By: tim_one Comment: +1. I think .popitem() is a good addition, providing a (now predictably) efficient way to do something useful that couldn't be done efficiently before, and with no bad effects on time or space use elsewhere. I don't see any real point to additional .popkey() or .popvalue() methods. The patch is missing: + Docs. + Test cases. + docstrings (although all of dictobject.c is missing docstrings). I would really like to understand why the original suggestion did good for you. For starters, which platform did you run it on? I don't see anything in the code that should vary across 32-bit platforms (not the string hash codes, or the GF-cycling business, ... even computing the initial value of incr is careful to cast hash to unsigned before the right shift). On the platform where it did help, what does this print (w/ the current patch -- this will reveal the internal storage order for a and b)? N = 128 ints = range(N) a = {} for i in ints: a[`i`] = i b = a.copy() aorder = [a.popitem()[1] for i in ints] border = [b.popitem()[1] for i in ints] assert not a assert not b for aval, bval in zip(aorder, border): print "%6d %6d" % (aval, bval), if aval == bval: print "ok" else: print "******* out of synch *******" Here's what I get: 34 34 ok 35 35 ok 36 36 ok 37 37 ok 30 30 ok 31 31 ok 32 32 ok 33 33 ok 38 95 ******* out of synch ******* 39 38 ******* out of synch ******* 78 39 ******* out of synch ******* 79 78 ******* out of synch ******* 107 79 ******* out of synch ******* 106 107 ******* out of synch ******* 101 106 ******* out of synch ******* 100 101 ******* out of synch ******* 103 100 ******* out of synch ******* 102 103 ******* out of synch ******* 70 102 ******* out of synch ******* 71 70 ******* out of synch ******* 72 71 ******* out of synch ******* 73 72 ******* out of synch ******* 74 73 ******* out of synch ******* 75 74 ******* out of synch ******* 76 75 ******* out of synch ******* 77 76 ******* out of synch ******* 59 77 ******* out of synch ******* 54 108 ******* out of synch ******* 55 9 ******* out of synch ******* 58 7 ******* out of synch ******* 9 5 ******* out of synch ******* 7 3 ******* out of synch ******* 5 1 ******* out of synch ******* 3 41 ******* out of synch ******* 1 40 ******* out of synch ******* 41 43 ******* out of synch ******* 40 42 ******* out of synch ******* 43 45 ******* out of synch ******* 42 44 ******* out of synch ******* 45 47 ******* out of synch ******* 44 46 ******* out of synch ******* 47 49 ******* out of synch ******* 46 48 ******* out of synch ******* 49 85 ******* out of synch ******* 48 84 ******* out of synch ******* 85 87 ******* out of synch ******* 84 86 ******* out of synch ******* 87 81 ******* out of synch ******* 86 80 ******* out of synch ******* 81 83 ******* out of synch ******* 80 82 ******* out of synch ******* 83 112 ******* out of synch ******* 82 113 ******* out of synch ******* 112 110 ******* out of synch ******* 113 111 ******* out of synch ******* 110 89 ******* out of synch ******* 111 88 ******* out of synch ******* 89 114 ******* out of synch ******* 88 115 ******* out of synch ******* 114 99 ******* out of synch ******* 115 124 ******* out of synch ******* 122 52 ******* out of synch ******* 120 53 ******* out of synch ******* 117 50 ******* out of synch ******* 52 51 ******* out of synch ******* 53 56 ******* out of synch ******* 50 57 ******* out of synch ******* 51 54 ******* out of synch ******* 56 55 ******* out of synch ******* 57 16 ******* out of synch ******* 18 17 ******* out of synch ******* 19 58 ******* out of synch ******* 16 59 ******* out of synch ******* 17 19 ******* out of synch ******* 14 13 ******* out of synch ******* 15 18 ******* out of synch ******* 12 11 ******* out of synch ******* 13 96 ******* out of synch ******* 10 97 ******* out of synch ******* 11 94 ******* out of synch ******* 96 14 ******* out of synch ******* 97 92 ******* out of synch ******* 94 93 ******* out of synch ******* 95 90 ******* out of synch ******* 92 91 ******* out of synch ******* 93 127 ******* out of synch ******* 90 126 ******* out of synch ******* 91 125 ******* out of synch ******* 127 15 ******* out of synch ******* 126 123 ******* out of synch ******* 125 122 ******* out of synch ******* 124 98 ******* out of synch ******* 123 120 ******* out of synch ******* 116 118 ******* out of synch ******* 98 119 ******* out of synch ******* 99 10 ******* out of synch ******* 118 12 ******* out of synch ******* 119 69 ******* out of synch ******* 104 8 ******* out of synch ******* 109 6 ******* out of synch ******* 8 4 ******* out of synch ******* 6 2 ******* out of synch ******* 4 0 ******* out of synch ******* 2 61 ******* out of synch ******* 0 29 ******* out of synch ******* 29 28 ******* out of synch ******* 28 62 ******* out of synch ******* 23 23 ok 22 22 ok 21 21 ok 20 20 ok 27 27 ok 26 26 ok 25 25 ok 24 24 ok 105 105 ok 69 104 ******* out of synch ******* 68 68 ok 67 67 ok 66 66 ok 65 65 ok 64 64 ok 63 63 ok 62 117 ******* out of synch ******* 61 116 ******* out of synch ******* 60 60 ok 108 109 ******* out of synch ******* 121 121 ok ------------------------------------------------------- Date: 2000-Dec-10 19:23 By: tim_one Comment: OK, looks good. Changed status to Accepted and assigned back to you for checkin. ------------------------------------------------------- Date: 2000-Dec-10 19:07 By: gvanrossum Comment: Here's a new version. Unchanged Objects/dictobject.c patch; added Lib/UserDict.py, Lib/test/test_types.py, Doc/lib/libstdtypes.tex. I'll check it in after a 24 hour wait period. ------------------------------------------------------- Date: 2000-Dec-10 19:03 By: tim_one Comment: Good! Not all is lost: random blobs of the string and dict code got a thorough code review out of it . BTW, if you're going to Pronounce favorably on .popitem(), feel free to tell me to finish the job (just an offer, not a request -- either way is fine by me). ------------------------------------------------------- Date: 2000-Dec-10 18:44 By: gvanrossum Comment: I get the exact same output as you, Tim. I tried to reproduce my original results with the original implementation again, and indeed I get the same times with or without your "improvement". My best guess as to why I thought it made a difference is that I misread the poorly designed output from the test program. I'll add docs and test cases. ------------------------------------------------------- Date: 2000-Dec-09 14:01 By: gvanrossum Comment: New patch uploaded. This is really Tim Peters's patch, including the correction he posted on Sat, 9 Dec 2000 16:09:30. I don't know why Tim's original suggested "improvement" worked so well for me -- it really did improve a lot over the original version. Oh well. ------------------------------------------------------- Date: 2000-Dec-08 10:28 By: gvanrossum Comment: Tim (or anyone else): can you improve this? It has excellent performance as long as you only do a single dictionary at a time, but goes quadratic if you call popitem() for two identical dictionaries in lock-step. Maybe jumping criss-cross through the hash table like lookdict does would improve that; but I don't understand the math used for that ("Cycle through GF(2^n)-{0}" ???). Here's a test program: import time for run in range(1000): print "run =", run for log2size in range(10, 18): size = 2**log2size print "log2size =", log2size, print "size =", size a = {} t0 = time.clock() while 1: i = len(a) if i >= size: break a[`i`] = i t1 = time.clock() print "%.1f usec per item to build (total %.3f sec)" % ( (1e6*(t1-t0)/size), t1-t0) b = a.copy() t0 = time.clock() try: while 1: a.popitem() b.popitem() except KeyError: pass t1 = time.clock() print "%.1f usec per item to destroy twins (total %.3f sec)" % ( (1e6*(t1-t0)/size), t1-t0) assert not a, a assert not b, b ------------------------------------------------------- Date: 2000-Dec-08 10:58 By: tim_one Comment: While I haven't yet actually tried it, I'm pretty sure you'd get much better performance (linear) in your test case by changing "finger = i+1" to "finger = i", and no matter how many dicts you march over in lockstep. In the case of a single dict, it adds a trivial amount of overhead per lookup (one extra C-speed trip around the loop per lookup). The reason "GF(2^n)-{)}" confuses you is because he should have written "**" instead of "^" . In essense, it means "visit each of the 2**n bit patterns exactly once, except for the all-zero pattern", and the "GF" means Galois Field, the theoretical basis for why the bit manipulations actually achieve that. I don't believe it would help: the sequence of bit patterns visited remains fixed, and if you continue to move the finger "one beyond" you'll get the same problem (the first pass thru two lockstep iters creates gaps that the second pass has to skip over; the second pass doubles the size of those gaps; the third pass doubles them again, etc). I agree that sharing one finger is very attractive. +1. ------------------------------------------------------- Date: 2000-Dec-08 11:04 By: gvanrossum Comment: New patch with Tim's suggestion. Works well! ------------------------------------------------------- Date: 2000-Dec-08 14:55 By: tim_one Comment: Actually, your test program with the new patch continues to show rotten behavior for me. dict.copy() returns a dict with the same value, but not necessarily the same internal structure. This is easy to see by changing the test's inner loop to while 1: gota = a.popitem() gotb = b.popitem() assert gota == gotb, (gota, gotb, len(a), len(b)) This fails instantly for me: run = 0 log2size = 10 size = 1024 10.2 usec per item to build (total 0.010 sec) Traceback (most recent call last): File "tdict.py", line 27, in ? assert gota == gotb, (gota, gotb, len(a), len(b)) AssertionError: (('773', 773), ('479', 479), 1023, 1023) If I make the dicts truly identical, by building b via the same operations in the same order as occurred for a, then the assert doesn't trigger and performance is wonderful (deleting the dicts is faster than building them). But in that case, the original "finger = i+1" is also very good (just a little slower). My head analysis of that case was wrong: the first pass does create a checkerboard pattern in both dicts, but the second pass systematically hits the holes created by the first pass. Are you sure your test program worked a lot better after the patch? Best I can tell, what I'm seeing has very little to do with the finger strategy and very much to do with accidents in the way dict.copy() works. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102733&group_id=5470 From noreply@sourceforge.net Tue Dec 12 22:13:26 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Dec 2000 14:13:26 -0800 Subject: [Patches] [Patch #101993] Fix prepare_input_stream bug Message-ID: <200012122213.OAA22774@usw-sf-web1.sourceforge.net> Patch #101993 has been updated. Project: python Category: XML Status: Accepted Submitted by: prescod Assigned to : fdrake Summary: Fix prepare_input_stream bug Follow-Ups: Date: 2000-Dec-12 14:13 By: gvanrossum Comment: Fred, can you check the status on this Accepted patch? It's been a long time! ------------------------------------------------------- Date: 2000-Nov-08 19:52 By: fdrake Comment: This was accepted by Lars but not assigned back to Paul. Paul, if this is still needed, please check it in and close the patch. Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101993&group_id=5470 From noreply@sourceforge.net Tue Dec 12 22:43:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Dec 2000 14:43:04 -0800 Subject: [Patches] [Patch #101993] Fix prepare_input_stream bug Message-ID: <200012122243.OAA23558@usw-sf-web1.sourceforge.net> Patch #101993 has been updated. Project: python Category: XML Status: Closed Submitted by: prescod Assigned to : fdrake Summary: Fix prepare_input_stream bug Follow-Ups: Date: 2000-Dec-12 14:43 By: fdrake Comment: Already incorporated -- closing the patch record. ------------------------------------------------------- Date: 2000-Dec-12 14:13 By: gvanrossum Comment: Fred, can you check the status on this Accepted patch? It's been a long time! ------------------------------------------------------- Date: 2000-Nov-08 19:52 By: fdrake Comment: This was accepted by Lars but not assigned back to Paul. Paul, if this is still needed, please check it in and close the patch. Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101993&group_id=5470 From noreply@sourceforge.net Tue Dec 12 22:56:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Dec 2000 14:56:08 -0800 Subject: [Patches] [Patch #102808] modules w/ vbl "__exports__" (lst of strs) have access ctrl. Message-ID: Patch #102808 has been updated. Project: python Category: core (C code) Status: Open Submitted by: rumjuggler Assigned to : nobody Summary: modules w/ vbl "__exports__" (lst of strs) have access ctrl. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102808&group_id=5470 From noreply@sourceforge.net Tue Dec 12 23:11:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Dec 2000 15:11:00 -0800 Subject: [Patches] [Patch #102208] Allow jython to use StringIO.py without an errno module. Message-ID: Patch #102208 has been updated. Project: python Category: library Status: Closed Submitted by: bckfnn Assigned to : bwarsaw Summary: Allow jython to use StringIO.py without an errno module. Follow-Ups: Date: 2000-Dec-12 15:11 By: bwarsaw Comment: Applied, StringIO.py 1.13 ------------------------------------------------------- Date: 2000-Nov-22 03:48 By: moshez Comment: This seems very reasonable -- it actually eliminates a dependancy which is problematic anyway -- it makes StringIO.py much more platform independant. +1! ------------------------------------------------------- Date: 2000-Nov-27 14:47 By: gvanrossum Comment: Please check it in or if you don't have time assign to me. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102208&group_id=5470 From noreply@sourceforge.net Wed Dec 13 03:51:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Dec 2000 19:51:54 -0800 Subject: [Patches] [Patch #102808] modules w/ vbl "__exports__" (lst of strs) have access ctrl. Message-ID: Patch #102808 has been updated. Project: python Category: core (C code) Status: Open Submitted by: rumjuggler Assigned to : nobody Summary: modules w/ vbl "__exports__" (lst of strs) have access ctrl. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102808&group_id=5470 From noreply@sourceforge.net Wed Dec 13 03:58:45 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Dec 2000 19:58:45 -0800 Subject: [Patches] [Patch #102813] _cursesmodule: Add panel support Message-ID: Patch #102813 has been updated. Project: python Category: Modules Status: Open Submitted by: akuchling Assigned to : nobody Summary: _cursesmodule: Add panel support ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102813&group_id=5470 From noreply@sourceforge.net Wed Dec 13 04:03:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Dec 2000 20:03:04 -0800 Subject: [Patches] [Patch #102813] _cursesmodule: Add panel support Message-ID: Patch #102813 has been updated. Project: python Category: Modules Status: Open Submitted by: akuchling Assigned to : akuchling Summary: _cursesmodule: Add panel support Follow-Ups: Date: 2000-Dec-12 20:03 By: akuchling Comment: Patch from Thomas Gellekum to add panel support. My comments: * Module-level panel_above and panel_below: how about naming them top_panel() and bottom_panel()? * In PyCurses_Panel_Below(), the text of an exception refers to panel_above (cut-and-paste error) * Maybe the panel functions should be in a separate file that gets #included; _cursesmodule.c is 2502 lines long, which is really cumbersome. The window functions should also be split out; I'll bring this up on python-dev. * set_panel_userptr() and panel_userptr(): why require that they be strings? They could simply be arbitrary Python objects that get INCREF'ed. (And I think saving a pointer output of PyArg_Parse() is incorrect; if the string is then deleted, this will become a dangling pointer). * PyCursesPanel_Replace_Panel(): you can parse arguments and require them to be of a certain class with PyArg_ParseTuple(args, "O!", &PyWhatever_Type, &arg, ...) * PyCursesPanel_Replace_Panel(): Can replace_panel() fail? If so, then the old and new window objects should only be DECREF/INCREF'ed if no error occurred. (There's also a panel_above reference in an exception here.) * panel_above/below(): what do they return when called on the top or bottom panel? (NULL would be a natural return value, so I'm wondering if NULL is really an error.) * I don't think Py_FatalError() should be used when a panel isn't on the linked list. (Perhaps some C code is creating panels.) Instead this should simply raise a regular exception, perhaps RuntimeError. These are my comments for now, but I'll keep looking at the code./ ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102813&group_id=5470 From noreply@sourceforge.net Wed Dec 13 06:08:37 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Dec 2000 22:08:37 -0800 Subject: [Patches] [Patch #102808] modules w/ vbl "__exports__" (lst of strs) have access ctrl. Message-ID: Patch #102808 has been updated. Project: python Category: core (C code) Status: Open Submitted by: rumjuggler Assigned to : nobody Summary: modules w/ vbl "__exports__" (lst of strs) have access ctrl. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102808&group_id=5470 From noreply@sourceforge.net Wed Dec 13 09:33:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Dec 2000 01:33:19 -0800 Subject: [Patches] [Patch #102802] Support new gdbm flags Message-ID: Patch #102802 has been updated. Project: python Category: Modules Status: Open Submitted by: nascheme Assigned to : moshez Summary: Support new gdbm flags Follow-Ups: Date: 2000-Dec-13 01:33 By: moshez Comment: OK, nascheme did what I wanted to do much faster. This code seems to be very future-proof and to do everything 102638 wanted to do better. There's one missing thing I want to add before I accept this: documentation (you knew this was coming, didn't you?). But since I'm going to keep the code, I'm rejecting 102638. ------------------------------------------------------- Date: 2000-Dec-12 08:49 By: nascheme Comment: Alternative to #102638. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102802&group_id=5470 From noreply@sourceforge.net Wed Dec 13 09:34:03 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Dec 2000 01:34:03 -0800 Subject: [Patches] [Patch #102638] A patch for gdbmmodule.c, by Damjan Message-ID: Patch #102638 has been updated. Project: python Category: Modules Status: Rejected Submitted by: nobody Assigned to : moshez Summary: A patch for gdbmmodule.c, by Damjan Follow-Ups: Date: 2000-Dec-13 01:34 By: moshez Comment: Rejected in favour of 102802. ------------------------------------------------------- Date: 2000-Dec-12 08:17 By: nascheme Comment: My version of gdbm (1.7.3) does not define GDBM_SYNC and GDBM_NOLOCK. If this patch is going to be applied then the code should be wrapped in ifdefs. Moshe, the reference to flags[2] should be okay although it is a strange way to write the code. I've uploaded an alternative patch (#102802). ------------------------------------------------------- Date: 2000-Dec-12 06:10 By: gvanrossum Comment: Thanks Moshe. I'm assigning the patch to you. Feel free to upload a new version! ------------------------------------------------------- Date: 2000-Dec-12 06:05 By: gvanrossum Comment: Thanks Moshe. I'm assigning the patch to you. Feel free to upload a new version! ------------------------------------------------------- Date: 2000-Dec-12 06:03 By: moshez Comment: Well, from the documentation I have installed on my system (RH 6.2), this patch seems to do the right thing -- for small enough values of the right thing. First of all, 'f' should still translate to GDBM_FAST: it's obsolete, but still supported for backwards compat. and so should we. Second, the string part seems a bit dodgy (isn't there an undefined reference of flags[2] if flags is only the string "r", say? ------------------------------------------------------- Date: 2000-Dec-12 05:44 By: gvanrossum Comment: Damjan replied via private mail: """ From the gdbm info page: ...The following may also be logically or'd into the database flags: GDBM_SYNC, which causes all database operations to be synchronized to the disk, and GDBM_NOLOCK, which prevents the library from performing any locking on the database file. The option GDBM_FAST is now obsolete, since `gdbm' defaults to no-sync mode... ^^^^^^^^ (1) My patch adds two options to the gdbm.open(..) function. These are 'u' for GDBM_NOLOCK, and 's' for GDBM_SYNC. (2) GDBM_FAST is obsolete because gdbm defaults to GDBM_FAST, so it's removed. I'm also thinking about adding a lock and unlock methods to the gdbm object, but it seems that a gdbm database can only be locked and not unlocked. """ Can amybody else who knows more about gdbm review the patch please? (Randomly asigned to Skip.) ------------------------------------------------------- Date: 2000-Dec-11 12:45 By: gvanrossum Comment: (1) What does the patch do? (2) Why does it remove the 'f' GDBM_FAST option? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102638&group_id=5470 From noreply@sourceforge.net Wed Dec 13 10:52:20 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Dec 2000 02:52:20 -0800 Subject: [Patches] [Patch #102802] Support new gdbm flags Message-ID: Patch #102802 has been updated. Project: python Category: Modules Status: Open Submitted by: nascheme Assigned to : fdrake Summary: Support new gdbm flags Follow-Ups: Date: 2000-Dec-13 02:52 By: moshez Comment: This patch includes both the code changes and documentation changes. I'm assigning this to Fred, so he can have a look at my doc changes. Fred, if this looks all right, either check it in yourself, or assign it to me so I can check it in. ------------------------------------------------------- Date: 2000-Dec-13 01:33 By: moshez Comment: OK, nascheme did what I wanted to do much faster. This code seems to be very future-proof and to do everything 102638 wanted to do better. There's one missing thing I want to add before I accept this: documentation (you knew this was coming, didn't you?). But since I'm going to keep the code, I'm rejecting 102638. ------------------------------------------------------- Date: 2000-Dec-12 08:49 By: nascheme Comment: Alternative to #102638. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102802&group_id=5470 From noreply@sourceforge.net Wed Dec 13 11:02:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Dec 2000 03:02:15 -0800 Subject: [Patches] [Patch #102678] Let SocketServer reuse addresses Message-ID: Patch #102678 has been updated. Project: python Category: library Status: Open Submitted by: moshez Assigned to : fdrake Summary: Let SocketServer reuse addresses Follow-Ups: Date: 2000-Dec-13 03:02 By: moshez Comment: I've changed it as per Guido's comment. I've also added documentation of this undocumented feature... Assigning to Fred, so he can have a look at the doco changes. Guido already approved the intent, so this is the only thing stopping it. ------------------------------------------------------- Date: 2000-Dec-06 01:24 By: moshez Comment: Following a discussion on #python, there was a consensus there that it's a pain SocketServer.py doesn't reuse addresses. ------------------------------------------------------- Date: 2000-Dec-06 09:59 By: gvanrossum Comment: Right idea, wrong implementation. Instead of this, set allow_reuse_address to 1; it's a class variable currently set to 0. Then server_bind() already does the setsockopt(). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102678&group_id=5470 From noreply@sourceforge.net Wed Dec 13 13:09:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Dec 2000 05:09:35 -0800 Subject: [Patches] [Patch #102802] Support new gdbm flags Message-ID: Patch #102802 has been updated. Project: python Category: Modules Status: Open Submitted by: nascheme Assigned to : fdrake Summary: Support new gdbm flags Follow-Ups: Date: 2000-Dec-13 05:09 By: gvanrossum Comment: Is it possible that someone ports Python to an environment that still has the old gdbm installed? Should we document the 'f' flag in that case? Apart from that, I'm happy with the code. Neil, please check in the patch (I prefer that the author of the code checks it in if at all possible). Fred will rule on the docs; they look fine to me. ------------------------------------------------------- Date: 2000-Dec-13 02:52 By: moshez Comment: This patch includes both the code changes and documentation changes. I'm assigning this to Fred, so he can have a look at my doc changes. Fred, if this looks all right, either check it in yourself, or assign it to me so I can check it in. ------------------------------------------------------- Date: 2000-Dec-13 01:33 By: moshez Comment: OK, nascheme did what I wanted to do much faster. This code seems to be very future-proof and to do everything 102638 wanted to do better. There's one missing thing I want to add before I accept this: documentation (you knew this was coming, didn't you?). But since I'm going to keep the code, I'm rejecting 102638. ------------------------------------------------------- Date: 2000-Dec-12 08:49 By: nascheme Comment: Alternative to #102638. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102802&group_id=5470 From noreply@sourceforge.net Wed Dec 13 13:55:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Dec 2000 05:55:53 -0800 Subject: [Patches] [Patch #102808] Export control for modules Message-ID: Patch #102808 has been updated. Project: python Category: core (C code) Status: Open Submitted by: rumjuggler Assigned to : nobody Summary: Export control for modules Follow-Ups: Date: 2000-Dec-13 05:55 By: gvanrossum Comment: Original title was: """modules w/ vbl "__exports__" (lst of strs) have access ctrl.""" This implements an interesting way of which names are visible outside the module that defines it: the __exports__ variable contains a list of exported names. If it is present, any name not in __exports__ is not accessible from outside the module (neither through import nor through direct access (getattr/setattr). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102808&group_id=5470 From noreply@sourceforge.net Wed Dec 13 13:56:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Dec 2000 05:56:16 -0800 Subject: [Patches] [Patch #102808] Export control for modules Message-ID: Patch #102808 has been updated. Project: python Category: core (C code) Status: Open Submitted by: rumjuggler Assigned to : gvanrossum Summary: Export control for modules Follow-Ups: Date: 2000-Dec-13 05:55 By: gvanrossum Comment: Original title was: """modules w/ vbl "__exports__" (lst of strs) have access ctrl.""" This implements an interesting way of which names are visible outside the module that defines it: the __exports__ variable contains a list of exported names. If it is present, any name not in __exports__ is not accessible from outside the module (neither through import nor through direct access (getattr/setattr). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102808&group_id=5470 From noreply@sourceforge.net Wed Dec 13 14:02:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Dec 2000 06:02:06 -0800 Subject: [Patches] [Patch #102678] Let SocketServer reuse addresses Message-ID: Patch #102678 has been updated. Project: python Category: library Status: Open Submitted by: moshez Assigned to : fdrake Summary: Let SocketServer reuse addresses Follow-Ups: Date: 2000-Dec-13 06:02 By: gvanrossum Comment: Moshe, you can go ahead and check in the code change. Fred will approve the doc change ASAP. ------------------------------------------------------- Date: 2000-Dec-13 03:02 By: moshez Comment: I've changed it as per Guido's comment. I've also added documentation of this undocumented feature... Assigning to Fred, so he can have a look at the doco changes. Guido already approved the intent, so this is the only thing stopping it. ------------------------------------------------------- Date: 2000-Dec-06 01:24 By: moshez Comment: Following a discussion on #python, there was a consensus there that it's a pain SocketServer.py doesn't reuse addresses. ------------------------------------------------------- Date: 2000-Dec-06 09:59 By: gvanrossum Comment: Right idea, wrong implementation. Instead of this, set allow_reuse_address to 1; it's a class variable currently set to 0. Then server_bind() already does the setsockopt(). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102678&group_id=5470 From noreply@sourceforge.net Wed Dec 13 14:21:41 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Dec 2000 06:21:41 -0800 Subject: [Patches] [Patch #102737] Add DOM exception classes Message-ID: Patch #102737 has been updated. Project: python Category: XML Status: Closed Submitted by: loewis Assigned to : loewis Summary: Add DOM exception classes Follow-Ups: Date: 2000-Dec-13 06:21 By: loewis Comment: Committed as 1.3 of __init__.py. ------------------------------------------------------- Date: 2000-Dec-11 13:02 By: fdrake Comment: Looks good to me! Go ahead and check it in. I should be able to look at the other DOM patches this week as well. ------------------------------------------------------- Date: 2000-Dec-08 13:45 By: loewis Comment: This patch adds DOMException and subclasses to xml.dom. It differs from the implementation in PyXML in the following ways: - DOMException is an abstract class, creating DOMException objects by giving a code is supported in PyXML only for backwards compatibility - Default exception message texts (from en_US.py) are not provided. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102737&group_id=5470 From noreply@sourceforge.net Wed Dec 13 15:23:03 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Dec 2000 07:23:03 -0800 Subject: [Patches] [Patch #102817] Fix for #124782:Always check for C++ compiler Message-ID: Patch #102817 has been updated. Project: python Category: Build Status: Open Submitted by: loewis Assigned to : nobody Summary: Fix for #124782:Always check for C++ compiler ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102817&group_id=5470 From noreply@sourceforge.net Wed Dec 13 15:53:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Dec 2000 07:53:46 -0800 Subject: [Patches] [Patch #102817] Fix for #124782:Always check for C++ compiler Message-ID: Patch #102817 has been updated. Project: python Category: Build Status: Accepted Submitted by: loewis Assigned to : loewis Summary: Fix for #124782:Always check for C++ compiler Follow-Ups: Date: 2000-Dec-13 07:53 By: gvanrossum Comment: Accepted -- please check it in. You may want to check the comment; there seem to be a few missing. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102817&group_id=5470 From noreply@sourceforge.net Wed Dec 13 15:59:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Dec 2000 07:59:33 -0800 Subject: [Patches] [Patch #102802] Support new gdbm flags Message-ID: Patch #102802 has been updated. Project: python Category: Modules Status: Open Submitted by: nascheme Assigned to : moshez Summary: Support new gdbm flags Follow-Ups: Date: 2000-Dec-13 07:59 By: fdrake Comment: I'd like to see a way to query the set of acceptable flags, so that a program has the option of adjusting the open() flags appropriately if (for example) "fast" mode isn't available -- without having to attempt to open the database and catch the exception. The documentation should also mention that not all flags may be available based on GDBM version, and tell that the exception may be raised by open(). It should not state that 'f' does nothing; it will cause an exception to be raised if not available in the underlying implementation (if GDBM defines GDBM_FAST but ignores it, then the correspoding #ifdef/#endif should be removed from the patch). ------------------------------------------------------- Date: 2000-Dec-13 05:09 By: gvanrossum Comment: Is it possible that someone ports Python to an environment that still has the old gdbm installed? Should we document the 'f' flag in that case? Apart from that, I'm happy with the code. Neil, please check in the patch (I prefer that the author of the code checks it in if at all possible). Fred will rule on the docs; they look fine to me. ------------------------------------------------------- Date: 2000-Dec-13 02:52 By: moshez Comment: This patch includes both the code changes and documentation changes. I'm assigning this to Fred, so he can have a look at my doc changes. Fred, if this looks all right, either check it in yourself, or assign it to me so I can check it in. ------------------------------------------------------- Date: 2000-Dec-13 01:33 By: moshez Comment: OK, nascheme did what I wanted to do much faster. This code seems to be very future-proof and to do everything 102638 wanted to do better. There's one missing thing I want to add before I accept this: documentation (you knew this was coming, didn't you?). But since I'm going to keep the code, I'm rejecting 102638. ------------------------------------------------------- Date: 2000-Dec-12 08:49 By: nascheme Comment: Alternative to #102638. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102802&group_id=5470 From noreply@sourceforge.net Wed Dec 13 16:20:14 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Dec 2000 08:20:14 -0800 Subject: [Patches] [Patch #102678] Let SocketServer reuse addresses Message-ID: Patch #102678 has been updated. Project: python Category: library Status: Accepted Submitted by: moshez Assigned to : moshez Summary: Let SocketServer reuse addresses Follow-Ups: Date: 2000-Dec-13 08:20 By: fdrake Comment: Minor change: instead of saying that allow_reuse_address defaults to \code{1}, just say that it defaults to true. That re-inforces that this is a boolean, not an integer which may be interpreted differently for, say, 2. Just make the change and check it in; no need to iterate here. ------------------------------------------------------- Date: 2000-Dec-13 06:02 By: gvanrossum Comment: Moshe, you can go ahead and check in the code change. Fred will approve the doc change ASAP. ------------------------------------------------------- Date: 2000-Dec-13 03:02 By: moshez Comment: I've changed it as per Guido's comment. I've also added documentation of this undocumented feature... Assigning to Fred, so he can have a look at the doco changes. Guido already approved the intent, so this is the only thing stopping it. ------------------------------------------------------- Date: 2000-Dec-06 01:24 By: moshez Comment: Following a discussion on #python, there was a consensus there that it's a pain SocketServer.py doesn't reuse addresses. ------------------------------------------------------- Date: 2000-Dec-06 09:59 By: gvanrossum Comment: Right idea, wrong implementation. Instead of this, set allow_reuse_address to 1; it's a class variable currently set to 0. Then server_bind() already does the setsockopt(). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102678&group_id=5470 From noreply@sourceforge.net Wed Dec 13 17:38:20 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Dec 2000 09:38:20 -0800 Subject: [Patches] [Patch #102817] Fix for #124782:Always check for C++ compiler Message-ID: Patch #102817 has been updated. Project: python Category: Build Status: Closed Submitted by: loewis Assigned to : loewis Summary: Fix for #124782:Always check for C++ compiler Follow-Ups: Date: 2000-Dec-13 09:38 By: loewis Comment: Committed as configure.in 1.181 ------------------------------------------------------- Date: 2000-Dec-13 07:53 By: gvanrossum Comment: Accepted -- please check it in. You may want to check the comment; there seem to be a few missing. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102817&group_id=5470 From noreply@sourceforge.net Wed Dec 13 22:29:11 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Dec 2000 14:29:11 -0800 Subject: [Patches] [Patch #102477] DOM enhancements Message-ID: Patch #102477 has been updated. Project: python Category: XML Status: Open Submitted by: fdrake Assigned to : loewis Summary: DOM enhancements Follow-Ups: Date: 2000-Dec-13 14:29 By: fdrake Comment: New version of the patch; I *think* I've addressed Martin's concerns. (I do not agree that AttributeError(name) is better than AttributeError, name though, and did not change that.) Outstanding problems/limitations: createDocumentNS() has not been implemented. createDocument() does not create the root element. This is related to a limitation in pulldom: it creates the document before the root element is seen, and operation of DOMEventStream.expandNode() seems to rely on this. This needs to be restructured somehow. pulldom.PullDOM & friends rely on using the parentNode attribute before nodes have been added to the tree, including write access to the attribute. This will not work with all DOM implementations and violates the DOM API. I think we can work around this, but that's yet another large chunk of changes. (And I think this is already a huge improvement over what's checked in, so I'd like to move on this.) ------------------------------------------------------- Date: 2000-Nov-22 13:39 By: fdrake Comment: This modifies PullDOM.__init__() to accept a Document object as a parameter, and changes PullDOM.startDocument() to use that object or create a one using minidom if necessary. This allows all existing client code to continue to work unchanged, while supporting use of alternate DOM implementations. ------------------------------------------------------- Date: 2000-Nov-22 22:24 By: fdrake Comment: Revised patch based on Greg Stein's note that the original would not create a new Document instance for each call to startDocument(); this version takes a document factory instead of a document object, and creates a new document with each call to startDocument(). ------------------------------------------------------- Date: 2000-Nov-27 13:38 By: gvanrossum Comment: Fred, please pick someone to review this and assign it to them. ------------------------------------------------------- Date: 2000-Nov-27 15:03 By: fdrake Comment: [Changed summary line to reflect updated patch. Assigning to Martin since he cares about this stuff. ;-) ] xml.dom.minidom changes: This improves the Node.normalize() method based on Martin's suggestions, but does not address all of his concerns (re-linking siblings in particular). Test suite is updated to test that empty Text nodes are removed. Minor improvement to an AttributeError that should not normally ever be seen by users. Adds minimal support for DocumentType and DOMImplementation. Partially fixes problem that documentElement was not properly supporting remove/replace; this should make it a little better, but sacrifices performance of using .documentElement to get it; the performance loss can be corrected by extending more methods in the Document class and removing the dynamic lookup of the documentElement attribute. xml.dom.pulldom changes: The PullDOM class now uses a DOMImplementation for the documentFactory object. It's not clear that the createDocument method is used correctly, but the DOM Level 2 documentation for DOMImplementation is seriously lacking. ------------------------------------------------------- Date: 2000-Nov-29 07:13 By: fdrake Comment: Uploading fixed patch, since something appearantly went wrong with the last upload. Removed attempted use of cStringIO; that doesn't work with Unicode that can't be encoded using the default encoding for strings (often 7-bit ASCII), so we always use the original StringIO module. ------------------------------------------------------- Date: 2000-Dec-03 03:32 By: loewis Comment: Comments in patch order: - AttributeError: Is it better style to write AttributeError(key)? - normalize: If the first text node is empty, I believe it won't be removed (unless the next node is also a text node) - Doctype.unlink is unnecessary; that is handled in Node (in general, each unlink should handle only the attributes introduced in this inheritance level) - hasFeature: I think we cannot claim conformance to "xml" yet; that would require CDATASection, Notation, Entity, EntityReference and ProcessingInstruction support. - Document: Shouldn't implementation point to the DOMImplementation instance that created the Document? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102477&group_id=5470 From noreply@sourceforge.net Thu Dec 14 02:07:39 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Dec 2000 18:07:39 -0800 Subject: [Patches] [Patch #102827] Fix for PR#119558: bsddb.c: check return from malloc Message-ID: Patch #102827 has been updated. Project: python Category: Modules Status: Open Submitted by: akuchling Assigned to : nobody Summary: Fix for PR#119558: bsddb.c: check return from malloc ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102827&group_id=5470 From noreply@sourceforge.net Thu Dec 14 04:48:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Dec 2000 20:48:52 -0800 Subject: [Patches] [Patch #102485] minidom.py: Check for legal children Message-ID: Patch #102485 has been updated. Project: python Category: XML Status: Out of date Submitted by: akuchling Assigned to : akuchling Summary: minidom.py: Check for legal children Follow-Ups: Date: 2000-Dec-13 20:48 By: fdrake Comment: Now that the exceptions have been added to xml.dom and documented in the development version of the docs, this patch needs to be updated to throw the right exceptions. ------------------------------------------------------- Date: 2000-Nov-23 08:24 By: akuchling Comment: Revised version of patch; the first version was generated against a really old version of minidom.py. ------------------------------------------------------- Date: 2000-Dec-03 03:37 By: loewis Comment: I'd prefer to postpone this patch somewhat, until the official DOM exceptions are available in xml.dom, and then to raise those instead. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102485&group_id=5470 From noreply@sourceforge.net Thu Dec 14 12:54:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Dec 2000 04:54:10 -0800 Subject: [Patches] [Patch #102477] DOM enhancements Message-ID: Patch #102477 has been updated. Project: python Category: XML Status: Accepted Submitted by: fdrake Assigned to : loewis Summary: DOM enhancements Follow-Ups: Date: 2000-Dec-14 04:54 By: loewis Comment: This patch looks ok now, please install it. One question still on normalize: Is it really necessary to copy self.childNodes before iterating over it? ------------------------------------------------------- Date: 2000-Dec-13 14:29 By: fdrake Comment: New version of the patch; I *think* I've addressed Martin's concerns. (I do not agree that AttributeError(name) is better than AttributeError, name though, and did not change that.) Outstanding problems/limitations: createDocumentNS() has not been implemented. createDocument() does not create the root element. This is related to a limitation in pulldom: it creates the document before the root element is seen, and operation of DOMEventStream.expandNode() seems to rely on this. This needs to be restructured somehow. pulldom.PullDOM & friends rely on using the parentNode attribute before nodes have been added to the tree, including write access to the attribute. This will not work with all DOM implementations and violates the DOM API. I think we can work around this, but that's yet another large chunk of changes. (And I think this is already a huge improvement over what's checked in, so I'd like to move on this.) ------------------------------------------------------- Date: 2000-Nov-22 13:39 By: fdrake Comment: This modifies PullDOM.__init__() to accept a Document object as a parameter, and changes PullDOM.startDocument() to use that object or create a one using minidom if necessary. This allows all existing client code to continue to work unchanged, while supporting use of alternate DOM implementations. ------------------------------------------------------- Date: 2000-Nov-22 22:24 By: fdrake Comment: Revised patch based on Greg Stein's note that the original would not create a new Document instance for each call to startDocument(); this version takes a document factory instead of a document object, and creates a new document with each call to startDocument(). ------------------------------------------------------- Date: 2000-Nov-27 13:38 By: gvanrossum Comment: Fred, please pick someone to review this and assign it to them. ------------------------------------------------------- Date: 2000-Nov-27 15:03 By: fdrake Comment: [Changed summary line to reflect updated patch. Assigning to Martin since he cares about this stuff. ;-) ] xml.dom.minidom changes: This improves the Node.normalize() method based on Martin's suggestions, but does not address all of his concerns (re-linking siblings in particular). Test suite is updated to test that empty Text nodes are removed. Minor improvement to an AttributeError that should not normally ever be seen by users. Adds minimal support for DocumentType and DOMImplementation. Partially fixes problem that documentElement was not properly supporting remove/replace; this should make it a little better, but sacrifices performance of using .documentElement to get it; the performance loss can be corrected by extending more methods in the Document class and removing the dynamic lookup of the documentElement attribute. xml.dom.pulldom changes: The PullDOM class now uses a DOMImplementation for the documentFactory object. It's not clear that the createDocument method is used correctly, but the DOM Level 2 documentation for DOMImplementation is seriously lacking. ------------------------------------------------------- Date: 2000-Nov-29 07:13 By: fdrake Comment: Uploading fixed patch, since something appearantly went wrong with the last upload. Removed attempted use of cStringIO; that doesn't work with Unicode that can't be encoded using the default encoding for strings (often 7-bit ASCII), so we always use the original StringIO module. ------------------------------------------------------- Date: 2000-Dec-03 03:32 By: loewis Comment: Comments in patch order: - AttributeError: Is it better style to write AttributeError(key)? - normalize: If the first text node is empty, I believe it won't be removed (unless the next node is also a text node) - Doctype.unlink is unnecessary; that is handled in Node (in general, each unlink should handle only the attributes introduced in this inheritance level) - hasFeature: I think we cannot claim conformance to "xml" yet; that would require CDATASection, Notation, Entity, EntityReference and ProcessingInstruction support. - Document: Shouldn't implementation point to the DOMImplementation instance that created the Document? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102477&group_id=5470 From noreply@sourceforge.net Thu Dec 14 14:23:22 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Dec 2000 06:23:22 -0800 Subject: [Patches] [Patch #102827] Fix for PR#119558: bsddb.c: check return from malloc Message-ID: Patch #102827 has been updated. Project: python Category: Modules Status: Accepted Submitted by: akuchling Assigned to : akuchling Summary: Fix for PR#119558: bsddb.c: check return from malloc Follow-Ups: Date: 2000-Dec-14 06:23 By: gvanrossum Comment: Looks fine -- check it in, unless you have specific qualms about it? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102827&group_id=5470 From noreply@sourceforge.net Thu Dec 14 16:16:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Dec 2000 08:16:06 -0800 Subject: [Patches] [Patch #102827] Fix for PR#119558: bsddb.c: check return from malloc Message-ID: Patch #102827 has been updated. Project: python Category: Modules Status: Accepted Submitted by: akuchling Assigned to : akuchling Summary: Fix for PR#119558: bsddb.c: check return from malloc Follow-Ups: Date: 2000-Dec-14 08:16 By: akuchling Comment: No; it averts dumping core, which is all I care about. The code will sometimes leak a bit of memory when a MemoryError is raised, and there may be other leaks in that case that I haven't noticed, but that seems too trivial to worry about. (I expect R.Dunn's BerkeleyDB module will eventually take over from this module anyway.) ------------------------------------------------------- Date: 2000-Dec-14 06:23 By: gvanrossum Comment: Looks fine -- check it in, unless you have specific qualms about it? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102827&group_id=5470 From noreply@sourceforge.net Thu Dec 14 18:22:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Dec 2000 10:22:07 -0800 Subject: [Patches] [Patch #102477] DOM enhancements Message-ID: Patch #102477 has been updated. Project: python Category: XML Status: Closed Submitted by: fdrake Assigned to : fdrake Summary: DOM enhancements Follow-Ups: Date: 2000-Dec-14 10:22 By: fdrake Comment: On Node.normalize(): Looking again, I don't think so. Removed in the checkin. Checked in as the following revisions: Lib/xml/dom/minidom.py 1.15 Lib/xml/dom/pulldom.py 1.12 Lib/test/test_minidom.py 1.16 Lib/test/output/test_minidom 1.11 ------------------------------------------------------- Date: 2000-Dec-14 04:54 By: loewis Comment: This patch looks ok now, please install it. One question still on normalize: Is it really necessary to copy self.childNodes before iterating over it? ------------------------------------------------------- Date: 2000-Dec-13 14:29 By: fdrake Comment: New version of the patch; I *think* I've addressed Martin's concerns. (I do not agree that AttributeError(name) is better than AttributeError, name though, and did not change that.) Outstanding problems/limitations: createDocumentNS() has not been implemented. createDocument() does not create the root element. This is related to a limitation in pulldom: it creates the document before the root element is seen, and operation of DOMEventStream.expandNode() seems to rely on this. This needs to be restructured somehow. pulldom.PullDOM & friends rely on using the parentNode attribute before nodes have been added to the tree, including write access to the attribute. This will not work with all DOM implementations and violates the DOM API. I think we can work around this, but that's yet another large chunk of changes. (And I think this is already a huge improvement over what's checked in, so I'd like to move on this.) ------------------------------------------------------- Date: 2000-Nov-22 13:39 By: fdrake Comment: This modifies PullDOM.__init__() to accept a Document object as a parameter, and changes PullDOM.startDocument() to use that object or create a one using minidom if necessary. This allows all existing client code to continue to work unchanged, while supporting use of alternate DOM implementations. ------------------------------------------------------- Date: 2000-Nov-22 22:24 By: fdrake Comment: Revised patch based on Greg Stein's note that the original would not create a new Document instance for each call to startDocument(); this version takes a document factory instead of a document object, and creates a new document with each call to startDocument(). ------------------------------------------------------- Date: 2000-Nov-27 13:38 By: gvanrossum Comment: Fred, please pick someone to review this and assign it to them. ------------------------------------------------------- Date: 2000-Nov-27 15:03 By: fdrake Comment: [Changed summary line to reflect updated patch. Assigning to Martin since he cares about this stuff. ;-) ] xml.dom.minidom changes: This improves the Node.normalize() method based on Martin's suggestions, but does not address all of his concerns (re-linking siblings in particular). Test suite is updated to test that empty Text nodes are removed. Minor improvement to an AttributeError that should not normally ever be seen by users. Adds minimal support for DocumentType and DOMImplementation. Partially fixes problem that documentElement was not properly supporting remove/replace; this should make it a little better, but sacrifices performance of using .documentElement to get it; the performance loss can be corrected by extending more methods in the Document class and removing the dynamic lookup of the documentElement attribute. xml.dom.pulldom changes: The PullDOM class now uses a DOMImplementation for the documentFactory object. It's not clear that the createDocument method is used correctly, but the DOM Level 2 documentation for DOMImplementation is seriously lacking. ------------------------------------------------------- Date: 2000-Nov-29 07:13 By: fdrake Comment: Uploading fixed patch, since something appearantly went wrong with the last upload. Removed attempted use of cStringIO; that doesn't work with Unicode that can't be encoded using the default encoding for strings (often 7-bit ASCII), so we always use the original StringIO module. ------------------------------------------------------- Date: 2000-Dec-03 03:32 By: loewis Comment: Comments in patch order: - AttributeError: Is it better style to write AttributeError(key)? - normalize: If the first text node is empty, I believe it won't be removed (unless the next node is also a text node) - Doctype.unlink is unnecessary; that is handled in Node (in general, each unlink should handle only the attributes introduced in this inheritance level) - hasFeature: I think we cannot claim conformance to "xml" yet; that would require CDATASection, Notation, Entity, EntityReference and ProcessingInstruction support. - Document: Shouldn't implementation point to the DOMImplementation instance that created the Document? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102477&group_id=5470 From noreply@sourceforge.net Thu Dec 14 19:16:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Dec 2000 11:16:21 -0800 Subject: [Patches] [Patch #102827] Fix for PR#119558: bsddb.c: check return from malloc Message-ID: Patch #102827 has been updated. Project: python Category: Modules Status: Accepted Submitted by: akuchling Assigned to : akuchling Summary: Fix for PR#119558: bsddb.c: check return from malloc Follow-Ups: Date: 2000-Dec-14 11:16 By: gvanrossum Comment: OK. Check it in. :-) ------------------------------------------------------- Date: 2000-Dec-14 08:16 By: akuchling Comment: No; it averts dumping core, which is all I care about. The code will sometimes leak a bit of memory when a MemoryError is raised, and there may be other leaks in that case that I haven't noticed, but that seems too trivial to worry about. (I expect R.Dunn's BerkeleyDB module will eventually take over from this module anyway.) ------------------------------------------------------- Date: 2000-Dec-14 06:23 By: gvanrossum Comment: Looks fine -- check it in, unless you have specific qualms about it? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102827&group_id=5470 From noreply@sourceforge.net Thu Dec 14 20:58:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Dec 2000 12:58:12 -0800 Subject: [Patches] [Patch #102847] fix a memory leak Message-ID: Patch #102847 has been updated. Project: python Category: None Status: Open Submitted by: cgw Assigned to : nobody Summary: fix a memory leak ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102847&group_id=5470 From noreply@sourceforge.net Thu Dec 14 21:16:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Dec 2000 13:16:16 -0800 Subject: [Patches] [Patch #102847] fix a memory leak Message-ID: Patch #102847 has been updated. Project: python Category: None Status: Open Submitted by: cgw Assigned to : jhylton Summary: fix a memory leak ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102847&group_id=5470 From noreply@sourceforge.net Thu Dec 14 21:18:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Dec 2000 13:18:10 -0800 Subject: [Patches] [Patch #102678] Let SocketServer reuse addresses Message-ID: Patch #102678 has been updated. Project: python Category: library Status: Closed Submitted by: moshez Assigned to : moshez Summary: Let SocketServer reuse addresses Follow-Ups: Date: 2000-Dec-13 08:20 By: fdrake Comment: Minor change: instead of saying that allow_reuse_address defaults to \code{1}, just say that it defaults to true. That re-inforces that this is a boolean, not an integer which may be interpreted differently for, say, 2. Just make the change and check it in; no need to iterate here. ------------------------------------------------------- Date: 2000-Dec-13 06:02 By: gvanrossum Comment: Moshe, you can go ahead and check in the code change. Fred will approve the doc change ASAP. ------------------------------------------------------- Date: 2000-Dec-13 03:02 By: moshez Comment: I've changed it as per Guido's comment. I've also added documentation of this undocumented feature... Assigning to Fred, so he can have a look at the doco changes. Guido already approved the intent, so this is the only thing stopping it. ------------------------------------------------------- Date: 2000-Dec-06 01:24 By: moshez Comment: Following a discussion on #python, there was a consensus there that it's a pain SocketServer.py doesn't reuse addresses. ------------------------------------------------------- Date: 2000-Dec-06 09:59 By: gvanrossum Comment: Right idea, wrong implementation. Instead of this, set allow_reuse_address to 1; it's a class variable currently set to 0. Then server_bind() already does the setsockopt(). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102678&group_id=5470 From noreply@sourceforge.net Thu Dec 14 21:20:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Dec 2000 13:20:21 -0800 Subject: [Patches] [Patch #102627] A Set class which *can* use the .firstkey() patch Message-ID: Patch #102627 has been updated. Project: python Category: library Status: Postponed Submitted by: moshez Assigned to : nobody Summary: A Set class which *can* use the .firstkey() patch Follow-Ups: Date: 2000-Dec-14 13:20 By: gvanrossum Comment: Moshe -- can you at least resubmit this using popitem()? Else I have to reject it outright. ------------------------------------------------------- Date: 2000-Dec-11 12:42 By: gvanrossum Comment: Changed status to Postponed -- this would need a lot of work. Also, there's a PEP on a Set addition (in the pie-in-the-sky category). All work on adding sets to Python should go through that PEP. (And note that there are several other competing set classes.) ------------------------------------------------------- Date: 2000-Dec-03 04:47 By: moshez Comment: OK, this patch implements a Set class with an added advantage that on 102626-patched interpreter it has a method called .element() which returns some element of the set. Short summary: * supports boolean operators, substraction * supports iteration semi-efficiently * supports checking for containment semi-efficiently * supports auto-freezing when hash() is called, so can be used as key in dictionaries, and so, as an element in sets. Greg Wilson: see if this doesn't solve 95% of the problem you're trying to solve with the Set built-in type PEP. ------------------------------------------------------- Date: 2000-Dec-06 10:04 By: gvanrossum Comment: I thought that instead of firstkey() we were going to implement popitem() instead? ------------------------------------------------------- Date: 2000-Dec-06 10:46 By: tim_one Comment: Changed Category to Library. Comments: Style: don't use hard tabs; add doc strings. Space efficiency: "_frozen = 0" is better at class level (most uses of sets never need it). __hash__: (1) you can cache the hash if the set is frozen, and in my experience that's important for efficiency. (2) it doesn't work correctly, although it may take some effort to provoke a failure. The problem is that you're deferring to hash(_make_elements()), _make_elements() returns a tuple, and the hash of a tuple depends on the order the keys happen to get materialized. But the hash of a set must be independent of the order the keys happen to get listed. See the code fragments I posted for a correct Set __hash__. __ior__: dict.update is much quicker than explicit iteration. The ability to apply set operators to raw sequences is unimportant, and not fully supported even if that is your intent (e.g., you don't have the "right-side" operators defined here). Confusing: most of the operators are defined in terms of add() and remove(). This will make the error msgs when they're applied to frozen sets confusing, because indirect. It's also much slower than doing the deed directly. In short, this looks like the first Set class someone writes off the top of their head in Python. That isn't bad, but something in the std distribution should be more than a finger exercise. ------------------------------------------------------- Date: 2000-Dec-06 10:55 By: tim_one Comment: Changed Category to Library. Comments: Style: don't use hard tabs; add doc strings. Space efficiency: "_frozen = 0" is better at class level (most uses of sets never need it). __hash__: (1) you can cache the hash if the set is frozen, and in my experience that's important for efficiency. (2) it doesn't work correctly, although it may take some effort to provoke a failure. The problem is that you're deferring to hash(_make_elements()), _make_elements() returns a tuple, and the hash of a tuple depends on the order the keys happen to get materialized. But the hash of a set must be independent of the order the keys happen to get listed. See the code fragments I posted for a correct Set __hash__. __ior__: dict.update is much quicker than explicit iteration. The ability to apply set operators to raw sequences is unimportant, and not fully supported even if that is your intent (e.g., you don't have the "right-side" operators defined here). Confusing: most of the operators are defined in terms of add() and remove(). This will make the error msgs when they're applied to frozen sets confusing, because indirect. It's also much slower than doing the deed directly. In short, this looks like the first Set class someone writes off the top of their head in Python. That isn't bad, but something in the std distribution should be more than a finger exercise. ------------------------------------------------------- Date: 2000-Dec-06 10:57 By: tim_one Comment: Sorry about the duplicate -- I have got to learn to reboot my machine (or does it need a full power cycle?) when a SourceForge page asks whether I want to repost data! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102627&group_id=5470 From noreply@sourceforge.net Thu Dec 14 23:19:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Dec 2000 15:19:40 -0800 Subject: [Patches] [Patch #102337] revised CALL_FUNCTION implementation Message-ID: Patch #102337 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jhylton Assigned to : gvanrossum Summary: revised CALL_FUNCTION implementation Follow-Ups: Date: 2000-Dec-14 15:19 By: jhylton Comment: The new version of the patch implements the new call dispatch approach suggested by lemburg. The basic idea is to have a separate function for each kind of callable object (function, method, C function, etc.) and a dispatch (call_object). The CALL_FUNCTION implementation optimizes for two common cases -- builtin C functions that use METH_OLDARGS (e.g. dict_keys, unicode_islower, etc.) and Python functions and builtin methods that don't need special argument handling. Both of these common cases can be handled without creating an argument tuple. The function call code is much clearer, particularly in eval_code2, where most of the complexity has been moved to separate functions. The performance is the same on the whole; calling builtins and bound methods is a bit faster. Also: the unused owner argument to eval_code2 was removed. ------------------------------------------------------- Date: 2000-Nov-08 16:08 By: jhylton Comment: This is a first draft patch that revises the CALL_FUNCTION implementation. The first part of the revision breaks the long inline implementation into a series of function calls. Each of the function calls has some small local optimizations (e.g. PyMethod_GET_SELF instead of PyMethod_GetSelf). One problem that needs to be figured out is how these functions can cleanly access the stack_pointer local var of eval_code2. The current approach is a bit messy. ------------------------------------------------------- Date: 2000-Nov-08 16:29 By: jhylton Comment: A trivial fix to the logic keeps keyword arguments fast. ------------------------------------------------------- Date: 2000-Nov-09 01:50 By: lemburg Comment: The patch looks ok, but I'm still missing the cleanup of the PyEval_CallXXX() APIs which the patch I sent you included. Some cosmetic issues: 1. your new APIs should be static and start with an underscore (e.g. _Py_CallFunctions) 2. you should add some "register" markers to the function call definitions -- this helps compilers such as gcc when inlining functions ------------------------------------------------------- Date: 2000-Nov-09 05:59 By: nobody Comment: Haven't seen the patch yet, but one remark on static functions: these should *not* have an underscore and *not* have a _Py_ prefix. The _Py_ prefix is for stuff that cannot be static, because it needs to be called from another file, but is not intended to be a public API (so it could disappear or change in a future version without breaking user code). There are a few exceptions (_Py_ functions that are part of the public API); these are either historical accidents or need to be used with great care only by wizards. --Guido ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102337&group_id=5470 From noreply@sourceforge.net Thu Dec 14 23:27:41 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Dec 2000 15:27:41 -0800 Subject: [Patches] [Patch #102337] revised CALL_FUNCTION implementation Message-ID: Patch #102337 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jhylton Assigned to : gvanrossum Summary: revised CALL_FUNCTION implementation Follow-Ups: Date: 2000-Dec-14 15:27 By: jhylton Comment: One more note: lemburg suggested using register declarations. I didn't add any because I don't know where they would help. To experiment, I removed all the register declarations from ceval.c and recompiled. The results on my function call benchmark were slightly better (difference was in the noise). ------------------------------------------------------- Date: 2000-Dec-14 15:19 By: jhylton Comment: The new version of the patch implements the new call dispatch approach suggested by lemburg. The basic idea is to have a separate function for each kind of callable object (function, method, C function, etc.) and a dispatch (call_object). The CALL_FUNCTION implementation optimizes for two common cases -- builtin C functions that use METH_OLDARGS (e.g. dict_keys, unicode_islower, etc.) and Python functions and builtin methods that don't need special argument handling. Both of these common cases can be handled without creating an argument tuple. The function call code is much clearer, particularly in eval_code2, where most of the complexity has been moved to separate functions. The performance is the same on the whole; calling builtins and bound methods is a bit faster. Also: the unused owner argument to eval_code2 was removed. ------------------------------------------------------- Date: 2000-Nov-08 16:08 By: jhylton Comment: This is a first draft patch that revises the CALL_FUNCTION implementation. The first part of the revision breaks the long inline implementation into a series of function calls. Each of the function calls has some small local optimizations (e.g. PyMethod_GET_SELF instead of PyMethod_GetSelf). One problem that needs to be figured out is how these functions can cleanly access the stack_pointer local var of eval_code2. The current approach is a bit messy. ------------------------------------------------------- Date: 2000-Nov-08 16:29 By: jhylton Comment: A trivial fix to the logic keeps keyword arguments fast. ------------------------------------------------------- Date: 2000-Nov-09 01:50 By: lemburg Comment: The patch looks ok, but I'm still missing the cleanup of the PyEval_CallXXX() APIs which the patch I sent you included. Some cosmetic issues: 1. your new APIs should be static and start with an underscore (e.g. _Py_CallFunctions) 2. you should add some "register" markers to the function call definitions -- this helps compilers such as gcc when inlining functions ------------------------------------------------------- Date: 2000-Nov-09 05:59 By: nobody Comment: Haven't seen the patch yet, but one remark on static functions: these should *not* have an underscore and *not* have a _Py_ prefix. The _Py_ prefix is for stuff that cannot be static, because it needs to be called from another file, but is not intended to be a public API (so it could disappear or change in a future version without breaking user code). There are a few exceptions (_Py_ functions that are part of the public API); these are either historical accidents or need to be used with great care only by wizards. --Guido ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102337&group_id=5470 From noreply@sourceforge.net Fri Dec 15 01:00:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Dec 2000 17:00:44 -0800 Subject: [Patches] [Patch #102827] Fix for PR#119558: bsddb.c: check return from malloc Message-ID: Patch #102827 has been updated. Project: python Category: Modules Status: Closed Submitted by: akuchling Assigned to : akuchling Summary: Fix for PR#119558: bsddb.c: check return from malloc Follow-Ups: Date: 2000-Dec-14 17:00 By: akuchling Comment: Applied. ------------------------------------------------------- Date: 2000-Dec-14 11:16 By: gvanrossum Comment: OK. Check it in. :-) ------------------------------------------------------- Date: 2000-Dec-14 08:16 By: akuchling Comment: No; it averts dumping core, which is all I care about. The code will sometimes leak a bit of memory when a MemoryError is raised, and there may be other leaks in that case that I haven't noticed, but that seems too trivial to worry about. (I expect R.Dunn's BerkeleyDB module will eventually take over from this module anyway.) ------------------------------------------------------- Date: 2000-Dec-14 06:23 By: gvanrossum Comment: Looks fine -- check it in, unless you have specific qualms about it? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102827&group_id=5470 From noreply@sourceforge.net Fri Dec 15 01:22:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Dec 2000 17:22:00 -0800 Subject: [Patches] [Patch #102852] Make % error a bit more informative Message-ID: Patch #102852 has been updated. Project: python Category: core (C code) Status: Open Submitted by: akuchling Assigned to : nobody Summary: Make % error a bit more informative ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102852&group_id=5470 From noreply@sourceforge.net Fri Dec 15 01:24:26 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Dec 2000 17:24:26 -0800 Subject: [Patches] [Patch #102852] Make % error a bit more informative Message-ID: Patch #102852 has been updated. Project: python Category: core (C code) Status: Open Submitted by: akuchling Assigned to : jhylton Summary: Make % error a bit more informative Follow-Ups: Date: 2000-Dec-14 17:24 By: akuchling Comment: This patch indicates the index at which an unknown %-escape was found... useful when using %(foo)... inside a string several kilobytes long, as can happen when doing HTML templating. Arbitrarily assigning to Jeremy. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102852&group_id=5470 From noreply@sourceforge.net Fri Dec 15 01:55:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Dec 2000 17:55:08 -0800 Subject: [Patches] [Patch #102852] Make % error a bit more informative Message-ID: Patch #102852 has been updated. Project: python Category: core (C code) Status: Accepted Submitted by: akuchling Assigned to : tim_one Summary: Make % error a bit more informative Follow-Ups: Date: 2000-Dec-14 17:55 By: tim_one Comment: Just as arbitrarily reassigned to me, and non-arbitrarily Accepted it. Check it in! It's a good idea. ------------------------------------------------------- Date: 2000-Dec-14 17:24 By: akuchling Comment: This patch indicates the index at which an unknown %-escape was found... useful when using %(foo)... inside a string several kilobytes long, as can happen when doing HTML templating. Arbitrarily assigning to Jeremy. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102852&group_id=5470 From noreply@sourceforge.net Fri Dec 15 13:16:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Dec 2000 05:16:29 -0800 Subject: [Patches] [Patch #102852] Make % error a bit more informative Message-ID: Patch #102852 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: akuchling Assigned to : tim_one Summary: Make % error a bit more informative Follow-Ups: Date: 2000-Dec-15 05:16 By: akuchling Comment: Checked in. ------------------------------------------------------- Date: 2000-Dec-14 17:55 By: tim_one Comment: Just as arbitrarily reassigned to me, and non-arbitrarily Accepted it. Check it in! It's a good idea. ------------------------------------------------------- Date: 2000-Dec-14 17:24 By: akuchling Comment: This patch indicates the index at which an unknown %-escape was found... useful when using %(foo)... inside a string several kilobytes long, as can happen when doing HTML templating. Arbitrarily assigning to Jeremy. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102852&group_id=5470 From noreply@sourceforge.net Fri Dec 15 13:20:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Dec 2000 05:20:38 -0800 Subject: [Patches] [Patch #102813] _cursesmodule: Add panel support Message-ID: Patch #102813 has been updated. Project: python Category: Modules Status: Open Submitted by: akuchling Assigned to : akuchling Summary: _cursesmodule: Add panel support Follow-Ups: Date: 2000-Dec-15 05:20 By: akuchling Comment: Updated version of the patch from Thomas, that fixes most of my previous comments. ------------------------------------------------------- Date: 2000-Dec-12 20:03 By: akuchling Comment: Patch from Thomas Gellekum to add panel support. My comments: * Module-level panel_above and panel_below: how about naming them top_panel() and bottom_panel()? * In PyCurses_Panel_Below(), the text of an exception refers to panel_above (cut-and-paste error) * Maybe the panel functions should be in a separate file that gets #included; _cursesmodule.c is 2502 lines long, which is really cumbersome. The window functions should also be split out; I'll bring this up on python-dev. * set_panel_userptr() and panel_userptr(): why require that they be strings? They could simply be arbitrary Python objects that get INCREF'ed. (And I think saving a pointer output of PyArg_Parse() is incorrect; if the string is then deleted, this will become a dangling pointer). * PyCursesPanel_Replace_Panel(): you can parse arguments and require them to be of a certain class with PyArg_ParseTuple(args, "O!", &PyWhatever_Type, &arg, ...) * PyCursesPanel_Replace_Panel(): Can replace_panel() fail? If so, then the old and new window objects should only be DECREF/INCREF'ed if no error occurred. (There's also a panel_above reference in an exception here.) * panel_above/below(): what do they return when called on the top or bottom panel? (NULL would be a natural return value, so I'm wondering if NULL is really an error.) * I don't think Py_FatalError() should be used when a panel isn't on the linked list. (Perhaps some C code is creating panels.) Instead this should simply raise a regular exception, perhaps RuntimeError. These are my comments for now, but I'll keep looking at the code./ ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102813&group_id=5470 From noreply@sourceforge.net Fri Dec 15 18:23:05 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Dec 2000 10:23:05 -0800 Subject: [Patches] [Patch #102860] Add PyDict_Update() function to C API. Message-ID: Patch #102860 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : nobody Summary: Add PyDict_Update() function to C API. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102860&group_id=5470 From noreply@sourceforge.net Fri Dec 15 18:24:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Dec 2000 10:24:23 -0800 Subject: [Patches] [Patch #102860] Add PyDict_Update() function to C API. Message-ID: Patch #102860 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : gvanrossum Summary: Add PyDict_Update() function to C API. Follow-Ups: Date: 2000-Dec-15 10:24 By: fdrake Comment: Assigned to Guido, since he still needs to be convinced. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102860&group_id=5470 From noreply@sourceforge.net Fri Dec 15 19:37:37 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Dec 2000 11:37:37 -0800 Subject: [Patches] [Patch #102860] Add PyDict_Update() function to C API. Message-ID: Patch #102860 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : gvanrossum Summary: Add PyDict_Update() function to C API. Follow-Ups: Date: 2000-Dec-15 11:37 By: gvanrossum Comment: I'm not convinced yet. Jeremy gave me a reason for why he needs it. I'd like to see his profile data showing that there's a performance reason why he can't use PyObject_CallMethod(). ------------------------------------------------------- Date: 2000-Dec-15 10:24 By: fdrake Comment: Assigned to Guido, since he still needs to be convinced. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102860&group_id=5470 From noreply@sourceforge.net Fri Dec 15 19:41:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Dec 2000 11:41:31 -0800 Subject: [Patches] [Patch #102860] Add PyDict_Update() function to C API. Message-ID: Patch #102860 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : jhylton Summary: Add PyDict_Update() function to C API. Follow-Ups: Date: 2000-Dec-15 11:41 By: jhylton Comment: I'll get some performance numbers when I get a chance, probably next week. ------------------------------------------------------- Date: 2000-Dec-15 11:37 By: gvanrossum Comment: I'm not convinced yet. Jeremy gave me a reason for why he needs it. I'd like to see his profile data showing that there's a performance reason why he can't use PyObject_CallMethod(). ------------------------------------------------------- Date: 2000-Dec-15 10:24 By: fdrake Comment: Assigned to Guido, since he still needs to be convinced. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102860&group_id=5470 From noreply@sourceforge.net Fri Dec 15 21:56:45 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Dec 2000 13:56:45 -0800 Subject: [Patches] [Patch #102715] Prototype for PEP 230 - warnings Message-ID: Patch #102715 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: gvanrossum Assigned to : gvanrossum Summary: Prototype for PEP 230 - warnings Follow-Ups: Date: 2000-Dec-15 13:56 By: gvanrossum Comment: Checking most of this in now, closing the patch. (We can tweak it and the PEP later.) ------------------------------------------------------- Date: 2000-Dec-11 10:36 By: gvanrossum Comment: Latest version uploaded (the SF glitch seems fixed). Just for fun, this adds warnings for raising string exceptions and raising class exception that aren't derived from Exception, and it also adds warnings to the functions in the string module and to the strop module. These need work, but give an indication that this is a useful feature: it caught lots of offenders in the test suite! (Patches to sre.py and sre_parse.py included.) Assigning to Barry if he wants to review it. ------------------------------------------------------- Date: 2000-Dec-11 07:02 By: gvanrossum Comment: I have a new version fof warnings.py that fixes a few nits, but there's a problem with SF that prevents me from uploading it. Mail me. ------------------------------------------------------- Date: 2000-Dec-10 20:11 By: gvanrossum Comment: Assigned to Tim since he's awake. ------------------------------------------------------- Date: 2000-Dec-10 20:09 By: gvanrossum Comment: All the C code is redone, to postpone the import of warnings.py until PyErr_Warn() is actually called. This should also be more robust in the light of multiple interpreters (no globals are used). The warning category exceptions are now created as standard exceptions. The Python code redone for the new situation, and with some of Paul Prescod's suggestions implemented. ------------------------------------------------------- Date: 2000-Dec-08 14:38 By: gvanrossum Comment: Here's a more elaborate version of the patch, that adds the C API. (The C API imports warnings.py though.) Note that in contradition to PEP 230, the C routine to issue a warning is called PyErr_Warn(category, message) rather than Py_Warn(message, category). This is open for discussion. Since the category is a kind of exception, it seems to make sense to be consistent with the other PyErr_*() functions rather than with the Python warn(message[, category]) function. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102715&group_id=5470 From noreply@sourceforge.net Fri Dec 15 23:05:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Dec 2000 15:05:43 -0800 Subject: [Patches] [Patch #102863] another memory leak Message-ID: Patch #102863 has been updated. Project: python Category: core (C code) Status: Open Submitted by: cgw Assigned to : nobody Summary: another memory leak ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102863&group_id=5470 From noreply@sourceforge.net Fri Dec 15 23:24:32 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Dec 2000 15:24:32 -0800 Subject: [Patches] [Patch #102864] prototype closure implementation Message-ID: Patch #102864 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jhylton Assigned to : nobody Summary: prototype closure implementation ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102864&group_id=5470 From noreply@sourceforge.net Fri Dec 15 23:29:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Dec 2000 15:29:48 -0800 Subject: [Patches] [Patch #102864] prototype closure implementation (PEP 227) Message-ID: Patch #102864 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jhylton Assigned to : gvanrossum Summary: prototype closure implementation (PEP 227) Follow-Ups: Date: 2000-Dec-15 15:29 By: jhylton Comment: Guido, Here's a very rough implementation of closures. It uses flat closures that do not track rebindings of names in its original namespace. This is discussed briefly in the PEP; it should be straightforward to add a level of indirection to fix this. I rushed to get something implemented today; it's not the cleanest code. The changes to compile.c are particularly hackish, because the new function find_names() does a lot of work that can simplify code generation for LOAD_NAME, etc. and probably eliminate the need for a separate optimize() pass. I haven't made any attempt to integrate the closure creation cleanly, though; it's just wedged in there. The patch deals with functions only. Ultimately, classes will have to grow closures, too. The simple examples using classes should work, e.g. def make_adder(x): def adder(y): return x + y return adder dec = make_adder(-1) dec(1) == 0 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102864&group_id=5470 From noreply@sourceforge.net Fri Dec 15 23:30:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Dec 2000 15:30:50 -0800 Subject: [Patches] [Patch #102863] another memory leak Message-ID: Patch #102863 has been updated. Project: python Category: core (C code) Status: Open Submitted by: cgw Assigned to : jhylton Summary: another memory leak Follow-Ups: Date: 2000-Dec-15 15:30 By: jhylton Comment: I'll look at this pending review of patch 102337 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102863&group_id=5470 From noreply@sourceforge.net Fri Dec 15 23:31:32 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Dec 2000 15:31:32 -0800 Subject: [Patches] [Patch #102847] fix a memory leak Message-ID: Patch #102847 has been updated. Project: python Category: None Status: Open Submitted by: cgw Assigned to : jhylton Summary: fix a memory leak Follow-Ups: Date: 2000-Dec-15 15:31 By: jhylton Comment: I'll look at this pending review of 102337 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102847&group_id=5470 From noreply@sourceforge.net Sat Dec 16 00:18:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Dec 2000 16:18:16 -0800 Subject: [Patches] [Patch #102868] fileobject.c:get_line leaks memory when hitting EOF Message-ID: Patch #102868 has been updated. Project: python Category: None Status: Open Submitted by: cgw Assigned to : nobody Summary: fileobject.c:get_line leaks memory when hitting EOF ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102868&group_id=5470 From noreply@sourceforge.net Sat Dec 16 00:22:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Dec 2000 16:22:40 -0800 Subject: [Patches] [Patch #102868] fileobject.c:get_line leaks memory when hitting EOF Message-ID: Patch #102868 has been updated. Project: python Category: None Status: Open Submitted by: cgw Assigned to : nobody Summary: fileobject.c:get_line leaks memory when hitting EOF Follow-Ups: Date: 2000-Dec-15 16:22 By: cgw Comment: The GNU library documentation says: If you set `*LINEPTR' to a null pointer, and `*N' to zero, before the call, then `getline' allocates the initial buffer for you by calling `malloc'. [...] when `getline' returns, `*LINEPTR' is a `char *' which points to the text of the line. It does not explicitly specify what happens if EOF is hit or some other error occurs and -1 is returned. But one can determine empirically that in this case the memory allocated by "getline" is not free'd. Thus, every time you call "readline" on a file object and hit EOF, you leak a little memory, as you will see if you run this little program and watch "top": while 1: file = open('/dev/null', 'r') line = file.readline() file.close() (I did this test on a system with GNU glibc version 2.1.3) The above patch guards against this memory leak. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102868&group_id=5470 From noreply@sourceforge.net Sat Dec 16 00:36:30 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Dec 2000 16:36:30 -0800 Subject: [Patches] [Patch #102868] fileobject.c:get_line leaks memory when hitting EOF Message-ID: Patch #102868 has been updated. Project: python Category: None Status: Open Submitted by: cgw Assigned to : akuchling Summary: fileobject.c:get_line leaks memory when hitting EOF Follow-Ups: Date: 2000-Dec-15 16:22 By: cgw Comment: The GNU library documentation says: If you set `*LINEPTR' to a null pointer, and `*N' to zero, before the call, then `getline' allocates the initial buffer for you by calling `malloc'. [...] when `getline' returns, `*LINEPTR' is a `char *' which points to the text of the line. It does not explicitly specify what happens if EOF is hit or some other error occurs and -1 is returned. But one can determine empirically that in this case the memory allocated by "getline" is not free'd. Thus, every time you call "readline" on a file object and hit EOF, you leak a little memory, as you will see if you run this little program and watch "top": while 1: file = open('/dev/null', 'r') line = file.readline() file.close() (I did this test on a system with GNU glibc version 2.1.3) The above patch guards against this memory leak. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102868&group_id=5470 From noreply@sourceforge.net Sat Dec 16 15:42:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Dec 2000 07:42:25 -0800 Subject: [Patches] [Patch #102875] Make socket close thread safe Message-ID: Patch #102875 has been updated. Project: python Category: Modules Status: Open Submitted by: barry-scott Assigned to : nobody Summary: Make socket close thread safe ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102875&group_id=5470 From noreply@sourceforge.net Sat Dec 16 16:48:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Dec 2000 08:48:12 -0800 Subject: [Patches] [Patch #102875] Make socket close thread safe Message-ID: Patch #102875 has been updated. Project: python Category: Modules Status: Open Submitted by: barry-scott Assigned to : gvanrossum Summary: Make socket close thread safe Follow-Ups: Date: 2000-Dec-16 08:48 By: gvanrossum Comment: Barry, I think the first half of this patch is unrelated to close(). Maybe you modified the 2.0 release version but diffed against the CVS repository? Also, please use diff -c. But I agree that there's a problem. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102875&group_id=5470 From noreply@sourceforge.net Sun Dec 17 00:17:26 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Dec 2000 16:17:26 -0800 Subject: [Patches] [Patch #102878] More tests for coercion and comparison Message-ID: Patch #102878 has been updated. Project: python Category: library Status: Open Submitted by: nascheme Assigned to : nobody Summary: More tests for coercion and comparison ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102878&group_id=5470 From noreply@sourceforge.net Sun Dec 17 00:22:51 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Dec 2000 16:22:51 -0800 Subject: [Patches] [Patch #102878] More tests for coercion and comparison Message-ID: Patch #102878 has been updated. Project: python Category: library Status: Open Submitted by: nascheme Assigned to : gvanrossum Summary: More tests for coercion and comparison Follow-Ups: Date: 2000-Dec-16 16:22 By: nascheme Comment: The tests are still not a through as they could be. For example, the ternary version of pow() should be tested ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102878&group_id=5470 From noreply@sourceforge.net Sun Dec 17 00:42:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Dec 2000 16:42:16 -0800 Subject: [Patches] [Patch #102652] Reference implementation for PEP 208 (coercion) Message-ID: Patch #102652 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nascheme Assigned to : gvanrossum Summary: Reference implementation for PEP 208 (coercion) Follow-Ups: Date: 2000-Dec-16 16:42 By: nascheme Comment: Rewrote PyObject_Compare yet again. I think it finally works now. Converted PyLongObject to use new style operations. Can someone check the reference counting in long_pow? Its pretty tricky and I'm not sure I got it right. Converting longs allowed PyNumber_Multiply to be changed to allow number types other than longs and ints to repeat sequences. PyNumber_InPlaceMultiply still needs to be fixed (easy). Fixed lots of small bugs and optimized things (eg. don't dispatch on the second operand if its type is the same as the first). Numbers no longer compare smaller than non-number types. ------------------------------------------------------- Date: 2000-Dec-11 12:39 By: gvanrossum Comment: I'm now actively reviewing Neil's code (while at the same time trying to figure out how to fit in rich comparisons). ------------------------------------------------------- Date: 2000-Dec-11 11:14 By: nascheme Comment: Operations on instances now call __coerce__ if it exists. I think the patch is now complete. Converting other builtin types to "new style numbers" can be done with a separate patch. ------------------------------------------------------- Date: 2000-Dec-04 18:45 By: nascheme Comment: This patch is a little rough yet but I guess its better here than on my website. The major source of ugliness PyObject_Compare. ------------------------------------------------------- Date: 2000-Dec-06 08:00 By: nascheme Comment: Cleaned up PyObject_Compare() (still needs to be optimized). __coerce__ on instances needs be to sorted out. It should probably be called if it exists for backwards compatibility. Longs and complex types still need to be converted to new style numbers. ------------------------------------------------------- Date: 2000-Dec-07 18:34 By: nascheme Comment: Fix some reference counts. Make use of macros to reduce duplicate code. Remove some unused code in classobject. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102652&group_id=5470 From noreply@sourceforge.net Sun Dec 17 07:16:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Dec 2000 23:16:25 -0800 Subject: [Patches] [Patch #102802] Support new gdbm flags Message-ID: Patch #102802 has been updated. Project: python Category: Modules Status: Closed Submitted by: nascheme Assigned to : moshez Summary: Support new gdbm flags Follow-Ups: Date: 2000-Dec-16 23:16 By: nascheme Comment: Checked in (libgdbm.tex 1.20 and gdbmmodule.c 2.28). ------------------------------------------------------- Date: 2000-Dec-13 07:59 By: fdrake Comment: I'd like to see a way to query the set of acceptable flags, so that a program has the option of adjusting the open() flags appropriately if (for example) "fast" mode isn't available -- without having to attempt to open the database and catch the exception. The documentation should also mention that not all flags may be available based on GDBM version, and tell that the exception may be raised by open(). It should not state that 'f' does nothing; it will cause an exception to be raised if not available in the underlying implementation (if GDBM defines GDBM_FAST but ignores it, then the correspoding #ifdef/#endif should be removed from the patch). ------------------------------------------------------- Date: 2000-Dec-13 05:09 By: gvanrossum Comment: Is it possible that someone ports Python to an environment that still has the old gdbm installed? Should we document the 'f' flag in that case? Apart from that, I'm happy with the code. Neil, please check in the patch (I prefer that the author of the code checks it in if at all possible). Fred will rule on the docs; they look fine to me. ------------------------------------------------------- Date: 2000-Dec-13 02:52 By: moshez Comment: This patch includes both the code changes and documentation changes. I'm assigning this to Fred, so he can have a look at my doc changes. Fred, if this looks all right, either check it in yourself, or assign it to me so I can check it in. ------------------------------------------------------- Date: 2000-Dec-13 01:33 By: moshez Comment: OK, nascheme did what I wanted to do much faster. This code seems to be very future-proof and to do everything 102638 wanted to do better. There's one missing thing I want to add before I accept this: documentation (you knew this was coming, didn't you?). But since I'm going to keep the code, I'm rejecting 102638. ------------------------------------------------------- Date: 2000-Dec-12 08:49 By: nascheme Comment: Alternative to #102638. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102802&group_id=5470 From noreply@sourceforge.net Sun Dec 17 22:22:37 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 17 Dec 2000 14:22:37 -0800 Subject: [Patches] [Patch #102891] Alternative readline module Message-ID: Patch #102891 has been updated. Project: python Category: Modules Status: Open Submitted by: nascheme Assigned to : nobody Summary: Alternative readline module ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102891&group_id=5470 From noreply@sourceforge.net Sun Dec 17 22:28:09 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 17 Dec 2000 14:28:09 -0800 Subject: [Patches] [Patch #102891] Alternative readline module Message-ID: Patch #102891 has been updated. Project: python Category: Modules Status: Open Submitted by: nascheme Assigned to : nobody Summary: Alternative readline module Follow-Ups: Date: 2000-Dec-17 14:28 By: nascheme Comment: I like Michael Hudson's idea of writing a readline replacement in Python using modules like _curses and termios better but I had this patch 90% complete before I recieved his email. I stripped the editline library down and updated it for modern Unix systems. I have no idea if it compiles on anything other than Linux however. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102891&group_id=5470 From noreply@sourceforge.net Mon Dec 18 16:29:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Dec 2000 08:29:15 -0800 Subject: [Patches] [Patch #102337] revised CALL_FUNCTION implementation Message-ID: Patch #102337 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jhylton Assigned to : gvanrossum Summary: revised CALL_FUNCTION implementation Follow-Ups: Date: 2000-Dec-18 08:29 By: jhylton Comment: Fixed bug in fast_cfunction (handling na > 1) ------------------------------------------------------- Date: 2000-Dec-14 15:27 By: jhylton Comment: One more note: lemburg suggested using register declarations. I didn't add any because I don't know where they would help. To experiment, I removed all the register declarations from ceval.c and recompiled. The results on my function call benchmark were slightly better (difference was in the noise). ------------------------------------------------------- Date: 2000-Dec-14 15:19 By: jhylton Comment: The new version of the patch implements the new call dispatch approach suggested by lemburg. The basic idea is to have a separate function for each kind of callable object (function, method, C function, etc.) and a dispatch (call_object). The CALL_FUNCTION implementation optimizes for two common cases -- builtin C functions that use METH_OLDARGS (e.g. dict_keys, unicode_islower, etc.) and Python functions and builtin methods that don't need special argument handling. Both of these common cases can be handled without creating an argument tuple. The function call code is much clearer, particularly in eval_code2, where most of the complexity has been moved to separate functions. The performance is the same on the whole; calling builtins and bound methods is a bit faster. Also: the unused owner argument to eval_code2 was removed. ------------------------------------------------------- Date: 2000-Nov-08 16:08 By: jhylton Comment: This is a first draft patch that revises the CALL_FUNCTION implementation. The first part of the revision breaks the long inline implementation into a series of function calls. Each of the function calls has some small local optimizations (e.g. PyMethod_GET_SELF instead of PyMethod_GetSelf). One problem that needs to be figured out is how these functions can cleanly access the stack_pointer local var of eval_code2. The current approach is a bit messy. ------------------------------------------------------- Date: 2000-Nov-08 16:29 By: jhylton Comment: A trivial fix to the logic keeps keyword arguments fast. ------------------------------------------------------- Date: 2000-Nov-09 01:50 By: lemburg Comment: The patch looks ok, but I'm still missing the cleanup of the PyEval_CallXXX() APIs which the patch I sent you included. Some cosmetic issues: 1. your new APIs should be static and start with an underscore (e.g. _Py_CallFunctions) 2. you should add some "register" markers to the function call definitions -- this helps compilers such as gcc when inlining functions ------------------------------------------------------- Date: 2000-Nov-09 05:59 By: nobody Comment: Haven't seen the patch yet, but one remark on static functions: these should *not* have an underscore and *not* have a _Py_ prefix. The _Py_ prefix is for stuff that cannot be static, because it needs to be called from another file, but is not intended to be a public API (so it could disappear or change in a future version without breaking user code). There are a few exceptions (_Py_ functions that are part of the public API); these are either historical accidents or need to be used with great care only by wizards. --Guido ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102337&group_id=5470 From noreply@sourceforge.net Mon Dec 18 22:17:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Dec 2000 14:17:23 -0800 Subject: [Patches] [Patch #102891] Alternative readline module Message-ID: Patch #102891 has been updated. Project: python Category: Modules Status: Accepted Submitted by: nascheme Assigned to : nascheme Summary: Alternative readline module Follow-Ups: Date: 2000-Dec-18 14:17 By: gvanrossum Comment: Neil, I propose that you check this in. The edline.c file would need a little work to compile without warnings, and you should add #HAVE_STRDUP to edline.h (Python makes sure strdup() is always present). The comment for Setup.dist "Neil Schemenauer's edline library" sounds a little strange given that most of the code is by others. Maybe "Neil Schemenauer's edline wrapper module"? ------------------------------------------------------- Date: 2000-Dec-17 14:28 By: nascheme Comment: I like Michael Hudson's idea of writing a readline replacement in Python using modules like _curses and termios better but I had this patch 90% complete before I recieved his email. I stripped the editline library down and updated it for modern Unix systems. I have no idea if it compiles on anything other than Linux however. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102891&group_id=5470 From noreply@sourceforge.net Mon Dec 18 22:17:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Dec 2000 14:17:58 -0800 Subject: [Patches] [Patch #102337] revised CALL_FUNCTION implementation Message-ID: Patch #102337 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jhylton Assigned to : jhylton Summary: revised CALL_FUNCTION implementation Follow-Ups: Date: 2000-Dec-18 14:17 By: gvanrossum Comment: Back to Jeremy. We had a code review session over the phone today. ------------------------------------------------------- Date: 2000-Dec-18 08:29 By: jhylton Comment: Fixed bug in fast_cfunction (handling na > 1) ------------------------------------------------------- Date: 2000-Dec-14 15:27 By: jhylton Comment: One more note: lemburg suggested using register declarations. I didn't add any because I don't know where they would help. To experiment, I removed all the register declarations from ceval.c and recompiled. The results on my function call benchmark were slightly better (difference was in the noise). ------------------------------------------------------- Date: 2000-Dec-14 15:19 By: jhylton Comment: The new version of the patch implements the new call dispatch approach suggested by lemburg. The basic idea is to have a separate function for each kind of callable object (function, method, C function, etc.) and a dispatch (call_object). The CALL_FUNCTION implementation optimizes for two common cases -- builtin C functions that use METH_OLDARGS (e.g. dict_keys, unicode_islower, etc.) and Python functions and builtin methods that don't need special argument handling. Both of these common cases can be handled without creating an argument tuple. The function call code is much clearer, particularly in eval_code2, where most of the complexity has been moved to separate functions. The performance is the same on the whole; calling builtins and bound methods is a bit faster. Also: the unused owner argument to eval_code2 was removed. ------------------------------------------------------- Date: 2000-Nov-08 16:08 By: jhylton Comment: This is a first draft patch that revises the CALL_FUNCTION implementation. The first part of the revision breaks the long inline implementation into a series of function calls. Each of the function calls has some small local optimizations (e.g. PyMethod_GET_SELF instead of PyMethod_GetSelf). One problem that needs to be figured out is how these functions can cleanly access the stack_pointer local var of eval_code2. The current approach is a bit messy. ------------------------------------------------------- Date: 2000-Nov-08 16:29 By: jhylton Comment: A trivial fix to the logic keeps keyword arguments fast. ------------------------------------------------------- Date: 2000-Nov-09 01:50 By: lemburg Comment: The patch looks ok, but I'm still missing the cleanup of the PyEval_CallXXX() APIs which the patch I sent you included. Some cosmetic issues: 1. your new APIs should be static and start with an underscore (e.g. _Py_CallFunctions) 2. you should add some "register" markers to the function call definitions -- this helps compilers such as gcc when inlining functions ------------------------------------------------------- Date: 2000-Nov-09 05:59 By: nobody Comment: Haven't seen the patch yet, but one remark on static functions: these should *not* have an underscore and *not* have a _Py_ prefix. The _Py_ prefix is for stuff that cannot be static, because it needs to be called from another file, but is not intended to be a public API (so it could disappear or change in a future version without breaking user code). There are a few exceptions (_Py_ functions that are part of the public API); these are either historical accidents or need to be used with great care only by wizards. --Guido ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102337&group_id=5470 From noreply@sourceforge.net Mon Dec 18 22:18:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Dec 2000 14:18:24 -0800 Subject: [Patches] [Patch #102864] prototype closure implementation (PEP 227) Message-ID: Patch #102864 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jhylton Assigned to : jhylton Summary: prototype closure implementation (PEP 227) Follow-Ups: Date: 2000-Dec-18 14:18 By: gvanrossum Comment: Back to Jeremy. We had a code review session today. ------------------------------------------------------- Date: 2000-Dec-15 15:29 By: jhylton Comment: Guido, Here's a very rough implementation of closures. It uses flat closures that do not track rebindings of names in its original namespace. This is discussed briefly in the PEP; it should be straightforward to add a level of indirection to fix this. I rushed to get something implemented today; it's not the cleanest code. The changes to compile.c are particularly hackish, because the new function find_names() does a lot of work that can simplify code generation for LOAD_NAME, etc. and probably eliminate the need for a separate optimize() pass. I haven't made any attempt to integrate the closure creation cleanly, though; it's just wedged in there. The patch deals with functions only. Ultimately, classes will have to grow closures, too. The simple examples using classes should work, e.g. def make_adder(x): def adder(y): return x + y return adder dec = make_adder(-1) dec(1) == 0 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102864&group_id=5470 From noreply@sourceforge.net Mon Dec 18 22:19:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Dec 2000 14:19:31 -0800 Subject: [Patches] [Patch #100998] experimental support for extended slicing on lists Message-ID: Patch #100998 has been updated. Project: python Category: core (C code) Status: Rejected Submitted by: mwh Assigned to : gvanrossum Summary: experimental support for extended slicing on lists Follow-Ups: Date: 2000-Dec-18 14:19 By: gvanrossum Comment: Rejected for lack of interest. Sorry, Michael! ------------------------------------------------------- Date: 2000-Jul-27 14:31 By: mwh Comment: this 10 minute hack adds support for "extended slicing" to lists, by which I mean things like: >>> range(100)[23:60:12] [23, 35, 47, 59] todo: find out if this is the approved approach add support for tuples write docs, testsuite (make test passes as is, but should be extended). ------------------------------------------------------- Date: 2000-Jul-27 14:39 By: mwh Comment: c'mon michael! at least get *some* of the boundary cases... ------------------------------------------------------- Date: 2000-Jul-27 23:47 By: mwh Comment: negative indices! for i in listvar[::-1]: pass now iterates over the list backwards (rather than coredumping...) ------------------------------------------------------- Date: 2000-Jul-29 03:36 By: mwh Comment: updated patch to support slice assignements, deletions (needs testing still) ------------------------------------------------------- Date: 2000-Jul-30 11:10 By: mwh Comment: bugfixes (refounting in assignment, logic in deletion) & a few tweaks. ------------------------------------------------------- Date: 2000-Jul-30 11:41 By: mwh Comment: meep! naughty Michael hadn't been running "make test" often enough. this update fixes that. ------------------------------------------------------- Date: 2000-Aug-15 11:53 By: tim_one Comment: Note that without doc and test patches too, and Real Soon, I'll have to Postpone this. Assigned to me to remind me of that. ------------------------------------------------------- Date: 2000-Aug-15 12:04 By: mwh Comment: OK, I'll get to that soon (ie. <24hours, hopefully <4). But bear in mind I'm now going to the pub... I may need some advice for the docs... ------------------------------------------------------- Date: 2000-Aug-16 12:30 By: mwh Comment: So, I missed my deadline by twenty five minutes. Sorry :-) This latest patch adds a fairly basic test suite, a stab at some docs, and jumps up and down on PySlice_GetIndices. Also (wrt. stringobject.c & unicodeobject.c) it's amazing what you can break, isn't it? Thank God for test suites... ------------------------------------------------------- Date: 2000-Aug-16 12:30 By: mwh Comment: So, I missed my deadline by twenty five minutes. Sorry :-) This latest patch adds a fairly basic test suite, a stab at some docs, and jumps up and down on PySlice_GetIndices. Also (wrt. stringobject.c & unicodeobject.c) it's amazing what you can break, isn't it? Thank God for test suites... ------------------------------------------------------- Date: 2000-Aug-31 19:10 By: gvanrossum Comment: Too late for the release, sorry. And Tim hates negative strides. We'll get back to this for 2.1. ------------------------------------------------------- Date: 2000-Nov-13 11:45 By: gvanrossum Comment: Is reviewing and applying this patch the best use of my time? I note that this is okay, but low priority -- I doubt that it will get used much. Plus, what about the array module, strings, UserList? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100998&group_id=5470 From noreply@sourceforge.net Mon Dec 18 22:25:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Dec 2000 14:25:35 -0800 Subject: [Patches] [Patch #102875] Make socket close thread safe Message-ID: Patch #102875 has been updated. Project: python Category: Modules Status: Closed Submitted by: barry-scott Assigned to : gvanrossum Summary: Make socket close thread safe Follow-Ups: Date: 2000-Dec-18 14:25 By: gvanrossum Comment: Thanks! Applied (only the second, relevant part of the patch) in slightly different form. socketmodule.c, rev. 1.130. ------------------------------------------------------- Date: 2000-Dec-16 08:48 By: gvanrossum Comment: Barry, I think the first half of this patch is unrelated to close(). Maybe you modified the 2.0 release version but diffed against the CVS repository? Also, please use diff -c. But I agree that there's a problem. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102875&group_id=5470 From noreply@sourceforge.net Mon Dec 18 22:25:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Dec 2000 14:25:12 -0800 Subject: [Patches] [Patch #102875] Make socket close thread safe Message-ID: Patch #102875 has been updated. Project: python Category: Modules Status: Open Submitted by: barry-scott Assigned to : gvanrossum Summary: Make socket close thread safe Follow-Ups: Date: 2000-Dec-18 14:25 By: gvanrossum Comment: Thanks! Applied (only the second, relevant part of the patch) in slightly different form. socketmodule.c, rev. 1.130. ------------------------------------------------------- Date: 2000-Dec-16 08:48 By: gvanrossum Comment: Barry, I think the first half of this patch is unrelated to close(). Maybe you modified the 2.0 release version but diffed against the CVS repository? Also, please use diff -c. But I agree that there's a problem. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102875&group_id=5470 From noreply@sourceforge.net Tue Dec 19 03:02:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Dec 2000 19:02:48 -0800 Subject: [Patches] [Patch #102813] _cursesmodule: Add panel support Message-ID: Patch #102813 has been updated. Project: python Category: Modules Status: Open Submitted by: akuchling Assigned to : akuchling Summary: _cursesmodule: Add panel support Follow-Ups: Date: 2000-Dec-18 19:02 By: akuchling Comment: Greatly revised version of this patch. Using a CObject, _cursesmodule.c now exports an API for other C extensions, and the panel extensions have been moved into a _curses_panel.c file. Not included in this patch: Lib/curses/panel.py, which just imports everything public from _curses_panel, documentation changes, and the modified Setup.in file. ------------------------------------------------------- Date: 2000-Dec-15 05:20 By: akuchling Comment: Updated version of the patch from Thomas, that fixes most of my previous comments. ------------------------------------------------------- Date: 2000-Dec-12 20:03 By: akuchling Comment: Patch from Thomas Gellekum to add panel support. My comments: * Module-level panel_above and panel_below: how about naming them top_panel() and bottom_panel()? * In PyCurses_Panel_Below(), the text of an exception refers to panel_above (cut-and-paste error) * Maybe the panel functions should be in a separate file that gets #included; _cursesmodule.c is 2502 lines long, which is really cumbersome. The window functions should also be split out; I'll bring this up on python-dev. * set_panel_userptr() and panel_userptr(): why require that they be strings? They could simply be arbitrary Python objects that get INCREF'ed. (And I think saving a pointer output of PyArg_Parse() is incorrect; if the string is then deleted, this will become a dangling pointer). * PyCursesPanel_Replace_Panel(): you can parse arguments and require them to be of a certain class with PyArg_ParseTuple(args, "O!", &PyWhatever_Type, &arg, ...) * PyCursesPanel_Replace_Panel(): Can replace_panel() fail? If so, then the old and new window objects should only be DECREF/INCREF'ed if no error occurred. (There's also a panel_above reference in an exception here.) * panel_above/below(): what do they return when called on the top or bottom panel? (NULL would be a natural return value, so I'm wondering if NULL is really an error.) * I don't think Py_FatalError() should be used when a panel isn't on the linked list. (Perhaps some C code is creating panels.) Instead this should simply raise a regular exception, perhaps RuntimeError. These are my comments for now, but I'll keep looking at the code./ ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102813&group_id=5470 From noreply@sourceforge.net Tue Dec 19 03:06:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Dec 2000 19:06:15 -0800 Subject: [Patches] [Patch #102868] fileobject.c:get_line leaks memory when hitting EOF Message-ID: Patch #102868 has been updated. Project: python Category: None Status: Accepted Submitted by: cgw Assigned to : akuchling Summary: fileobject.c:get_line leaks memory when hitting EOF Follow-Ups: Date: 2000-Dec-18 19:06 By: akuchling Comment: Patch accepted. Charles, please check it in. Thanks for catching this! ------------------------------------------------------- Date: 2000-Dec-15 16:22 By: cgw Comment: The GNU library documentation says: If you set `*LINEPTR' to a null pointer, and `*N' to zero, before the call, then `getline' allocates the initial buffer for you by calling `malloc'. [...] when `getline' returns, `*LINEPTR' is a `char *' which points to the text of the line. It does not explicitly specify what happens if EOF is hit or some other error occurs and -1 is returned. But one can determine empirically that in this case the memory allocated by "getline" is not free'd. Thus, every time you call "readline" on a file object and hit EOF, you leak a little memory, as you will see if you run this little program and watch "top": while 1: file = open('/dev/null', 'r') line = file.readline() file.close() (I did this test on a system with GNU glibc version 2.1.3) The above patch guards against this memory leak. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102868&group_id=5470 From noreply@sourceforge.net Tue Dec 19 03:27:34 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Dec 2000 19:27:34 -0800 Subject: [Patches] [Patch #102915] xreadlines : readlines :: xrange : range Message-ID: Patch #102915 has been updated. Project: python Category: Modules Status: Open Submitted by: jepler Assigned to : nobody Summary: xreadlines : readlines :: xrange : range ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102915&group_id=5470 From noreply@sourceforge.net Tue Dec 19 03:32:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Dec 2000 19:32:10 -0800 Subject: [Patches] [Patch #102915] xreadlines : readlines :: xrange : range Message-ID: Patch #102915 has been updated. Project: python Category: Modules Status: Open Submitted by: jepler Assigned to : nobody Summary: xreadlines : readlines :: xrange : range Follow-Ups: Date: 2000-Dec-18 19:32 By: jepler Comment: This patch implements an object 'xreadlines' in C, as well as a method on the file object to create one. xreadlines will let a 'for' loop iterate over the contents of a file without reading the whole file, yet at a speed almost equal to that of 'for line in f.readlines()'. Internally, it uses f.readlines(sizehint). Includes a test suite and a version of fileinput which uses it (approx. 50% speedup in fileinput as well). fileinput is not tested by test suite entry. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102915&group_id=5470 From noreply@sourceforge.net Tue Dec 19 13:49:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Dec 2000 05:49:00 -0800 Subject: [Patches] [Patch #102652] Reference implementation for PEP 208 (coercion) Message-ID: Patch #102652 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nascheme Assigned to : nascheme Summary: Reference implementation for PEP 208 (coercion) Follow-Ups: Date: 2000-Dec-19 05:49 By: gvanrossum Comment: Neil, I may not get to reviewing this again before January, 2nd. A quick scan suggests that you're definitely on the right way. If you feel brave, go check it in, warts and all (and also the coercion/comparison tests you submitted as a separate patch) -- the rest of the bleeding-edge developers will help you debug it then. ------------------------------------------------------- Date: 2000-Dec-16 16:42 By: nascheme Comment: Rewrote PyObject_Compare yet again. I think it finally works now. Converted PyLongObject to use new style operations. Can someone check the reference counting in long_pow? Its pretty tricky and I'm not sure I got it right. Converting longs allowed PyNumber_Multiply to be changed to allow number types other than longs and ints to repeat sequences. PyNumber_InPlaceMultiply still needs to be fixed (easy). Fixed lots of small bugs and optimized things (eg. don't dispatch on the second operand if its type is the same as the first). Numbers no longer compare smaller than non-number types. ------------------------------------------------------- Date: 2000-Dec-11 12:39 By: gvanrossum Comment: I'm now actively reviewing Neil's code (while at the same time trying to figure out how to fit in rich comparisons). ------------------------------------------------------- Date: 2000-Dec-11 11:14 By: nascheme Comment: Operations on instances now call __coerce__ if it exists. I think the patch is now complete. Converting other builtin types to "new style numbers" can be done with a separate patch. ------------------------------------------------------- Date: 2000-Dec-04 18:45 By: nascheme Comment: This patch is a little rough yet but I guess its better here than on my website. The major source of ugliness PyObject_Compare. ------------------------------------------------------- Date: 2000-Dec-06 08:00 By: nascheme Comment: Cleaned up PyObject_Compare() (still needs to be optimized). __coerce__ on instances needs be to sorted out. It should probably be called if it exists for backwards compatibility. Longs and complex types still need to be converted to new style numbers. ------------------------------------------------------- Date: 2000-Dec-07 18:34 By: nascheme Comment: Fix some reference counts. Make use of macros to reduce duplicate code. Remove some unused code in classobject. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102652&group_id=5470 From noreply@sourceforge.net Tue Dec 19 13:56:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Dec 2000 05:56:19 -0800 Subject: [Patches] [Patch #102878] More tests for coercion and comparison Message-ID: Patch #102878 has been updated. Project: python Category: library Status: Open Submitted by: nascheme Assigned to : nascheme Summary: More tests for coercion and comparison Follow-Ups: Date: 2000-Dec-19 05:56 By: gvanrossum Comment: My only nit with these: they fail "make test" because they mix tabs and spaces! Please untabify... ------------------------------------------------------- Date: 2000-Dec-16 16:22 By: nascheme Comment: The tests are still not a through as they could be. For example, the ternary version of pow() should be tested ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102878&group_id=5470 From noreply@sourceforge.net Tue Dec 19 15:08:09 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Dec 2000 07:08:09 -0800 Subject: [Patches] [Patch #102925] Add new function gc.getreferents Message-ID: Patch #102925 has been updated. Project: python Category: core (C code) Status: Open Submitted by: loewis Assigned to : nobody Summary: Add new function gc.getreferents ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102925&group_id=5470 From noreply@sourceforge.net Tue Dec 19 15:13:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Dec 2000 07:13:33 -0800 Subject: [Patches] [Patch #102925] Add new function gc.getreferents Message-ID: Patch #102925 has been updated. Project: python Category: core (C code) Status: Open Submitted by: loewis Assigned to : nobody Summary: Add new function gc.getreferents Follow-Ups: Date: 2000-Dec-19 07:13 By: loewis Comment: This patch adds a new function gc.getreferents which traverses all collectable objects and returns a list of objects that refer to any of the parameters of gc.getreferents. This will only find references visible to the gc; references in local variables of functions that are currently on the stack won't be found. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102925&group_id=5470 From noreply@sourceforge.net Tue Dec 19 19:25:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Dec 2000 11:25:57 -0800 Subject: [Patches] [Patch #102925] Add new function gc.getreferents Message-ID: Patch #102925 has been updated. Project: python Category: core (C code) Status: Open Submitted by: loewis Assigned to : nobody Summary: Add new function gc.getreferents Follow-Ups: Date: 2000-Dec-19 11:25 By: nascheme Comment: I'm -0 on this patch. The function is not as useful as it seems. The garbage collector does not and most likely never will be able to track down all references to an object (eg. an extension types could have a reference to it). If it could, we would be using a different collection scheme like mark and sweep. For debugging reference cycles like the RExec problem a pure Python tool (similar to Cyclops) would work. The tool just has to know how to chase references in different kinds of objects. Perhaps exposing the GC's knowledge of this would be more useful and general. ------------------------------------------------------- Date: 2000-Dec-19 07:13 By: loewis Comment: This patch adds a new function gc.getreferents which traverses all collectable objects and returns a list of objects that refer to any of the parameters of gc.getreferents. This will only find references visible to the gc; references in local variables of functions that are currently on the stack won't be found. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102925&group_id=5470 From noreply@sourceforge.net Tue Dec 19 20:50:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Dec 2000 12:50:31 -0800 Subject: [Patches] [Patch #102868] fileobject.c:get_line leaks memory when hitting EOF Message-ID: Patch #102868 has been updated. Project: python Category: None Status: Accepted Submitted by: cgw Assigned to : akuchling Summary: fileobject.c:get_line leaks memory when hitting EOF Follow-Ups: Date: 2000-Dec-19 12:50 By: bwarsaw Comment: Andrew, please check this in. ------------------------------------------------------- Date: 2000-Dec-18 19:06 By: akuchling Comment: Patch accepted. Charles, please check it in. Thanks for catching this! ------------------------------------------------------- Date: 2000-Dec-15 16:22 By: cgw Comment: The GNU library documentation says: If you set `*LINEPTR' to a null pointer, and `*N' to zero, before the call, then `getline' allocates the initial buffer for you by calling `malloc'. [...] when `getline' returns, `*LINEPTR' is a `char *' which points to the text of the line. It does not explicitly specify what happens if EOF is hit or some other error occurs and -1 is returned. But one can determine empirically that in this case the memory allocated by "getline" is not free'd. Thus, every time you call "readline" on a file object and hit EOF, you leak a little memory, as you will see if you run this little program and watch "top": while 1: file = open('/dev/null', 'r') line = file.readline() file.close() (I did this test on a system with GNU glibc version 2.1.3) The above patch guards against this memory leak. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102868&group_id=5470 From noreply@sourceforge.net Tue Dec 19 20:59:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Dec 2000 12:59:24 -0800 Subject: [Patches] [Patch #102868] fileobject.c:get_line leaks memory when hitting EOF Message-ID: Patch #102868 has been updated. Project: python Category: None Status: Closed Submitted by: cgw Assigned to : akuchling Summary: fileobject.c:get_line leaks memory when hitting EOF Follow-Ups: Date: 2000-Dec-19 12:59 By: akuchling Comment: Checked in and closed. ------------------------------------------------------- Date: 2000-Dec-19 12:50 By: bwarsaw Comment: Andrew, please check this in. ------------------------------------------------------- Date: 2000-Dec-18 19:06 By: akuchling Comment: Patch accepted. Charles, please check it in. Thanks for catching this! ------------------------------------------------------- Date: 2000-Dec-15 16:22 By: cgw Comment: The GNU library documentation says: If you set `*LINEPTR' to a null pointer, and `*N' to zero, before the call, then `getline' allocates the initial buffer for you by calling `malloc'. [...] when `getline' returns, `*LINEPTR' is a `char *' which points to the text of the line. It does not explicitly specify what happens if EOF is hit or some other error occurs and -1 is returned. But one can determine empirically that in this case the memory allocated by "getline" is not free'd. Thus, every time you call "readline" on a file object and hit EOF, you leak a little memory, as you will see if you run this little program and watch "top": while 1: file = open('/dev/null', 'r') line = file.readline() file.close() (I did this test on a system with GNU glibc version 2.1.3) The above patch guards against this memory leak. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102868&group_id=5470 From noreply@sourceforge.net Tue Dec 19 21:49:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Dec 2000 13:49:10 -0800 Subject: [Patches] [Patch #102939] Fix for 126345:Garbage collection for modules Message-ID: Patch #102939 has been updated. Project: python Category: core (C code) Status: Open Submitted by: loewis Assigned to : nobody Summary: Fix for 126345:Garbage collection for modules ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102939&group_id=5470 From noreply@sourceforge.net Tue Dec 19 22:08:42 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Dec 2000 14:08:42 -0800 Subject: [Patches] [Patch #102940] Use only printable Unicode chars in reporting % errors Message-ID: Patch #102940 has been updated. Project: python Category: core (C code) Status: Open Submitted by: akuchling Assigned to : nobody Summary: Use only printable Unicode chars in reporting % errors ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102940&group_id=5470 From noreply@sourceforge.net Tue Dec 19 22:09:42 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Dec 2000 14:09:42 -0800 Subject: [Patches] [Patch #102940] Use only printable Unicode chars in reporting % errors Message-ID: Patch #102940 has been updated. Project: python Category: core (C code) Status: Open Submitted by: akuchling Assigned to : tim_one Summary: Use only printable Unicode chars in reporting % errors Follow-Ups: Date: 2000-Dec-19 14:09 By: akuchling Comment: As discussed on python-dev... this uses ? for characters not between 32 and 127. Randomly assigning to... Tim! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102940&group_id=5470 From noreply@sourceforge.net Tue Dec 19 22:16:26 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Dec 2000 14:16:26 -0800 Subject: [Patches] [Patch #102940] Use only printable Unicode chars in reporting % errors Message-ID: Patch #102940 has been updated. Project: python Category: core (C code) Status: Open Submitted by: akuchling Assigned to : tim_one Summary: Use only printable Unicode chars in reporting % errors Follow-Ups: Date: 2000-Dec-19 14:16 By: tim_one Comment: Change 127 to 126 and we're golden (chr(127) isn't printable). ------------------------------------------------------- Date: 2000-Dec-19 14:09 By: akuchling Comment: As discussed on python-dev... this uses ? for characters not between 32 and 127. Randomly assigning to... Tim! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102940&group_id=5470 From noreply@sourceforge.net Tue Dec 19 22:50:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Dec 2000 14:50:25 -0800 Subject: [Patches] [Patch #102940] Use only printable Unicode chars in reporting % errors Message-ID: Patch #102940 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: akuchling Assigned to : tim_one Summary: Use only printable Unicode chars in reporting % errors Follow-Ups: Date: 2000-Dec-19 14:50 By: akuchling Comment: Checked in with Tim's modification and closed. ------------------------------------------------------- Date: 2000-Dec-19 14:16 By: tim_one Comment: Change 127 to 126 and we're golden (chr(127) isn't printable). ------------------------------------------------------- Date: 2000-Dec-19 14:09 By: akuchling Comment: As discussed on python-dev... this uses ? for characters not between 32 and 127. Randomly assigning to... Tim! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102940&group_id=5470 From noreply@sourceforge.net Tue Dec 19 22:52:22 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Dec 2000 14:52:22 -0800 Subject: [Patches] [Patch #102925] Add new function gc.getreferents Message-ID: Patch #102925 has been updated. Project: python Category: core (C code) Status: Open Submitted by: loewis Assigned to : nobody Summary: Add new function gc.getreferents Follow-Ups: Date: 2000-Dec-19 14:52 By: loewis Comment: Even though the function does not find all references to an object, it does find all objects that have references to some object - at least if all container types participate in garbage collection (I expect that most extension types will know about GC sooner or later). In particular, it finds containers that can't be found from pure Python, eg. containers that are stored only in a global variable of some C module. Even not being able to explain all references to some object gives a useful clue. I agree that exposing traversal to Python is a useful feature, but that is completely different from that function - you'd also need to expose the generations lists (which this patch does access, but pure Python can't). ------------------------------------------------------- Date: 2000-Dec-19 11:25 By: nascheme Comment: I'm -0 on this patch. The function is not as useful as it seems. The garbage collector does not and most likely never will be able to track down all references to an object (eg. an extension types could have a reference to it). If it could, we would be using a different collection scheme like mark and sweep. For debugging reference cycles like the RExec problem a pure Python tool (similar to Cyclops) would work. The tool just has to know how to chase references in different kinds of objects. Perhaps exposing the GC's knowledge of this would be more useful and general. ------------------------------------------------------- Date: 2000-Dec-19 07:13 By: loewis Comment: This patch adds a new function gc.getreferents which traverses all collectable objects and returns a list of objects that refer to any of the parameters of gc.getreferents. This will only find references visible to the gc; references in local variables of functions that are currently on the stack won't be found. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102925&group_id=5470 From noreply@sourceforge.net Wed Dec 20 00:56:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Dec 2000 16:56:49 -0800 Subject: [Patches] [Patch #102939] Fix for 126345:Garbage collection for modules Message-ID: Patch #102939 has been updated. Project: python Category: core (C code) Status: Open Submitted by: loewis Assigned to : nascheme Summary: Fix for 126345:Garbage collection for modules ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102939&group_id=5470 From noreply@sourceforge.net Wed Dec 20 00:56:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Dec 2000 16:56:49 -0800 Subject: [Patches] [Patch #102925] Add new function gc.getreferents Message-ID: Patch #102925 has been updated. Project: python Category: core (C code) Status: Open Submitted by: loewis Assigned to : nascheme Summary: Add new function gc.getreferents Follow-Ups: Date: 2000-Dec-19 14:52 By: loewis Comment: Even though the function does not find all references to an object, it does find all objects that have references to some object - at least if all container types participate in garbage collection (I expect that most extension types will know about GC sooner or later). In particular, it finds containers that can't be found from pure Python, eg. containers that are stored only in a global variable of some C module. Even not being able to explain all references to some object gives a useful clue. I agree that exposing traversal to Python is a useful feature, but that is completely different from that function - you'd also need to expose the generations lists (which this patch does access, but pure Python can't). ------------------------------------------------------- Date: 2000-Dec-19 11:25 By: nascheme Comment: I'm -0 on this patch. The function is not as useful as it seems. The garbage collector does not and most likely never will be able to track down all references to an object (eg. an extension types could have a reference to it). If it could, we would be using a different collection scheme like mark and sweep. For debugging reference cycles like the RExec problem a pure Python tool (similar to Cyclops) would work. The tool just has to know how to chase references in different kinds of objects. Perhaps exposing the GC's knowledge of this would be more useful and general. ------------------------------------------------------- Date: 2000-Dec-19 07:13 By: loewis Comment: This patch adds a new function gc.getreferents which traverses all collectable objects and returns a list of objects that refer to any of the parameters of gc.getreferents. This will only find references visible to the gc; references in local variables of functions that are currently on the stack won't be found. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102925&group_id=5470 From noreply@sourceforge.net Wed Dec 20 00:57:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Dec 2000 16:57:48 -0800 Subject: [Patches] [Patch #102953] [Bug #125452 ] shlex.shlex hangs Message-ID: Patch #102953 has been updated. Project: python Category: None Status: Open Submitted by: akuchling Assigned to : nobody Summary: [Bug #125452 ] shlex.shlex hangs ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102953&group_id=5470 From noreply@sourceforge.net Wed Dec 20 00:59:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Dec 2000 16:59:43 -0800 Subject: [Patches] [Patch #102953] [Bug #125452 ] shlex.shlex hangs Message-ID: Patch #102953 has been updated. Project: python Category: library Status: Open Submitted by: akuchling Assigned to : esr Summary: [Bug #125452 ] shlex.shlex hangs Follow-Ups: Date: 2000-Dec-19 16:59 By: akuchling Comment: A fix for bug #125452, shlex.shlex hanging when it encounters a string with an unmatched quote. I don't know how the error should be handled; the patch raises a ValueError, but do whatever you like. Assigning to ESR, who's now responsible for the shlex module. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102953&group_id=5470 From noreply@sourceforge.net Wed Dec 20 02:02:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Dec 2000 18:02:46 -0800 Subject: [Patches] [Patch #102492] minidom/pulldom: remove nodes already in the tree Message-ID: Patch #102492 has been updated. Project: python Category: XML Status: Open Submitted by: akuchling Assigned to : loewis Summary: minidom/pulldom: remove nodes already in the tree Follow-Ups: Date: 2000-Dec-19 18:02 By: akuchling Comment: Updated this patch to current CVS code. It probably still defaults the purpose of pulldom, but I don't see how to preserve it without making pulldom contain more of the guts of a DOM implementation. ------------------------------------------------------- Date: 2000-Nov-23 18:32 By: akuchling Comment: This patch attempts to fix bug #116677: "minidom:Node.appendChild() has wrong semantics". It changes the appendChild, insertBefore, etc. methods to remove the node being added if it's already in the tree. The patch also fixes some spots where the previousSibling/nextSibling pointers aren't being properly updated. Some changes to pulldom.py were required, and I'm unsure about them. Mostly they consist of using the published minidom interface instead of directly setting .parentNode. Judging by my debug printouts, pulldom ends up doing redundant work after this patch -- every node is added to the tree *twice*. However the resulting tree does seem to be correct. ------------------------------------------------------- Date: 2000-Dec-03 03:42 By: loewis Comment: I believe this patch defeats the purpose of pulldom. The intent is that processing SAX events does not create any hierarchy (and in particular no cyclic objects). Only when expandNode is called, a fully-connected hierarchy is created. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102492&group_id=5470 From noreply@sourceforge.net Wed Dec 20 02:11:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Dec 2000 18:11:28 -0800 Subject: [Patches] [Patch #102955] bltinmodule.c warning fix Message-ID: Patch #102955 has been updated. Project: python Category: None Status: Open Submitted by: akuchling Assigned to : nobody Summary: bltinmodule.c warning fix ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102955&group_id=5470 From noreply@sourceforge.net Wed Dec 20 02:13:27 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Dec 2000 18:13:27 -0800 Subject: [Patches] [Patch #102955] bltinmodule.c warning fix Message-ID: Patch #102955 has been updated. Project: python Category: core (C code) Status: Open Submitted by: akuchling Assigned to : tim_one Summary: bltinmodule.c warning fix Follow-Ups: Date: 2000-Dec-19 18:13 By: akuchling Comment: Fix for one of the warnings in bug #121479: bltinmodule.c: In function `builtin_ord': bltinmodule.c:1507: warning: `ord' might be used uninitialized in this function The patch simplifies ord()'s logic at the cost of some code duplication. Randomly assigning to Tim 'cause he's soooo cute. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102955&group_id=5470 From noreply@sourceforge.net Wed Dec 20 03:02:05 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Dec 2000 19:02:05 -0800 Subject: [Patches] [Patch #102955] bltinmodule.c warning fix Message-ID: Patch #102955 has been updated. Project: python Category: core (C code) Status: Accepted Submitted by: akuchling Assigned to : akuchling Summary: bltinmodule.c warning fix Follow-Ups: Date: 2000-Dec-19 19:02 By: tim_one Comment: I *am* damned cute, and glad someone finally appreciates that. Had to laugh at "simplifies ord()'s logic" -- you'd sure hope that a function as trivial as ord() had no logic to be simplified ... Unrelated to your patch but in the same area: the other msg, "ord() expected string or Unicode character", doesn't read right. The type names in question are "string" and "unicode": >>> type("") >>> type(u"") >>> "character" is out of place, or not in enough places. Just thought I'd mention that, since *you're* so cute! ------------------------------------------------------- Date: 2000-Dec-19 18:13 By: akuchling Comment: Fix for one of the warnings in bug #121479: bltinmodule.c: In function `builtin_ord': bltinmodule.c:1507: warning: `ord' might be used uninitialized in this function The patch simplifies ord()'s logic at the cost of some code duplication. Randomly assigning to Tim 'cause he's soooo cute. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102955&group_id=5470 From noreply@sourceforge.net Wed Dec 20 11:03:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 20 Dec 2000 03:03:06 -0800 Subject: [Patches] [Patch #102492] minidom/pulldom: remove nodes already in the tree Message-ID: Patch #102492 has been updated. Project: python Category: XML Status: Accepted Submitted by: akuchling Assigned to : akuchling Summary: minidom/pulldom: remove nodes already in the tree Follow-Ups: Date: 2000-Dec-20 03:03 By: loewis Comment: The patch is ok. I *think* pulldom would continue to work if it didn't attempt to set up parentNode attributes during parsing, but did all appendChild calls just in expandNode. However, we can look into that once the patch is installed. ------------------------------------------------------- Date: 2000-Dec-19 18:02 By: akuchling Comment: Updated this patch to current CVS code. It probably still defaults the purpose of pulldom, but I don't see how to preserve it without making pulldom contain more of the guts of a DOM implementation. ------------------------------------------------------- Date: 2000-Nov-23 18:32 By: akuchling Comment: This patch attempts to fix bug #116677: "minidom:Node.appendChild() has wrong semantics". It changes the appendChild, insertBefore, etc. methods to remove the node being added if it's already in the tree. The patch also fixes some spots where the previousSibling/nextSibling pointers aren't being properly updated. Some changes to pulldom.py were required, and I'm unsure about them. Mostly they consist of using the published minidom interface instead of directly setting .parentNode. Judging by my debug printouts, pulldom ends up doing redundant work after this patch -- every node is added to the tree *twice*. However the resulting tree does seem to be correct. ------------------------------------------------------- Date: 2000-Dec-03 03:42 By: loewis Comment: I believe this patch defeats the purpose of pulldom. The intent is that processing SAX events does not create any hierarchy (and in particular no cyclic objects). Only when expandNode is called, a fully-connected hierarchy is created. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102492&group_id=5470 From noreply@sourceforge.net Wed Dec 20 14:41:26 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 20 Dec 2000 06:41:26 -0800 Subject: [Patches] [Patch #102955] bltinmodule.c warning fix Message-ID: Patch #102955 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: akuchling Assigned to : akuchling Summary: bltinmodule.c warning fix Follow-Ups: Date: 2000-Dec-20 06:41 By: akuchling Comment: Checked in and closing. ------------------------------------------------------- Date: 2000-Dec-19 19:02 By: tim_one Comment: I *am* damned cute, and glad someone finally appreciates that. Had to laugh at "simplifies ord()'s logic" -- you'd sure hope that a function as trivial as ord() had no logic to be simplified ... Unrelated to your patch but in the same area: the other msg, "ord() expected string or Unicode character", doesn't read right. The type names in question are "string" and "unicode": >>> type("") >>> type(u"") >>> "character" is out of place, or not in enough places. Just thought I'd mention that, since *you're* so cute! ------------------------------------------------------- Date: 2000-Dec-19 18:13 By: akuchling Comment: Fix for one of the warnings in bug #121479: bltinmodule.c: In function `builtin_ord': bltinmodule.c:1507: warning: `ord' might be used uninitialized in this function The patch simplifies ord()'s logic at the cost of some code duplication. Randomly assigning to Tim 'cause he's soooo cute. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102955&group_id=5470 From noreply@sourceforge.net Wed Dec 20 14:47:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 20 Dec 2000 06:47:40 -0800 Subject: [Patches] [Patch #102492] minidom/pulldom: remove nodes already in the tree Message-ID: Patch #102492 has been updated. Project: python Category: XML Status: Closed Submitted by: akuchling Assigned to : akuchling Summary: minidom/pulldom: remove nodes already in the tree Follow-Ups: Date: 2000-Dec-20 06:47 By: akuchling Comment: Checked in. I have patches to the minidom test suite that exercise the new features, but they're in the source tree on my home machine. (Juggling 3 different source trees -- Solaris work, Linux work, Linux home -- is fun!) I'll check them in tonight. ------------------------------------------------------- Date: 2000-Dec-20 03:03 By: loewis Comment: The patch is ok. I *think* pulldom would continue to work if it didn't attempt to set up parentNode attributes during parsing, but did all appendChild calls just in expandNode. However, we can look into that once the patch is installed. ------------------------------------------------------- Date: 2000-Dec-19 18:02 By: akuchling Comment: Updated this patch to current CVS code. It probably still defaults the purpose of pulldom, but I don't see how to preserve it without making pulldom contain more of the guts of a DOM implementation. ------------------------------------------------------- Date: 2000-Nov-23 18:32 By: akuchling Comment: This patch attempts to fix bug #116677: "minidom:Node.appendChild() has wrong semantics". It changes the appendChild, insertBefore, etc. methods to remove the node being added if it's already in the tree. The patch also fixes some spots where the previousSibling/nextSibling pointers aren't being properly updated. Some changes to pulldom.py were required, and I'm unsure about them. Mostly they consist of using the published minidom interface instead of directly setting .parentNode. Judging by my debug printouts, pulldom ends up doing redundant work after this patch -- every node is added to the tree *twice*. However the resulting tree does seem to be correct. ------------------------------------------------------- Date: 2000-Dec-03 03:42 By: loewis Comment: I believe this patch defeats the purpose of pulldom. The intent is that processing SAX events does not create any hierarchy (and in particular no cyclic objects). Only when expandNode is called, a fully-connected hierarchy is created. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102492&group_id=5470 From noreply@sourceforge.net Wed Dec 20 21:51:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 20 Dec 2000 13:51:40 -0800 Subject: [Patches] [Patch #102971] build_ext -L tpye fix Message-ID: Patch #102971 has been updated. Project: python Category: distutils Status: Open Submitted by: calvin Assigned to : nobody Summary: build_ext -L tpye fix ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102971&group_id=5470 From noreply@sourceforge.net Wed Dec 20 23:05:20 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 20 Dec 2000 15:05:20 -0800 Subject: [Patches] [Patch #102485] minidom.py: Check for legal children Message-ID: Patch #102485 has been updated. Project: python Category: XML Status: Open Submitted by: akuchling Assigned to : fdrake Summary: minidom.py: Check for legal children Follow-Ups: Date: 2000-Dec-20 15:05 By: akuchling Comment: Revised the patch to match the current CVS tree, and to raise HierarchyRequestErr instead of ValueError. ------------------------------------------------------- Date: 2000-Dec-13 20:48 By: fdrake Comment: Now that the exceptions have been added to xml.dom and documented in the development version of the docs, this patch needs to be updated to throw the right exceptions. ------------------------------------------------------- Date: 2000-Nov-23 08:24 By: akuchling Comment: Revised version of patch; the first version was generated against a really old version of minidom.py. ------------------------------------------------------- Date: 2000-Dec-03 03:37 By: loewis Comment: I'd prefer to postpone this patch somewhat, until the official DOM exceptions are available in xml.dom, and then to raise those instead. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102485&group_id=5470 From noreply@sourceforge.net Wed Dec 20 23:07:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 20 Dec 2000 15:07:59 -0800 Subject: [Patches] [Patch #102971] build_ext -L tpye fix Message-ID: Patch #102971 has been updated. Project: python Category: distutils Status: Open Submitted by: calvin Assigned to : gward Summary: build_ext -L tpye fix ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102971&group_id=5470 From noreply@sourceforge.net Thu Dec 21 13:28:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 21 Dec 2000 05:28:49 -0800 Subject: [Patches] [Patch #102980] BaseServer class for SocketServer.py (inh. by TCPServer) Message-ID: Patch #102980 has been updated. Project: python Category: library Status: Open Submitted by: lkcl Assigned to : nobody Summary: BaseServer class for SocketServer.py (inh. by TCPServer) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102980&group_id=5470 From noreply@sourceforge.net Thu Dec 21 21:20:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 21 Dec 2000 13:20:55 -0800 Subject: [Patches] [Patch #102989] Allow 'continue' inside 'try' clause Message-ID: Patch #102989 has been updated. Project: python Category: core (C code) Status: Open Submitted by: twouters Assigned to : nobody Summary: Allow 'continue' inside 'try' clause ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102989&group_id=5470 From noreply@sourceforge.net Thu Dec 21 21:23:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 21 Dec 2000 13:23:31 -0800 Subject: [Patches] [Patch #102989] Allow 'continue' inside 'try' clause Message-ID: Patch #102989 has been updated. Project: python Category: core (C code) Status: Open Submitted by: twouters Assigned to : nobody Summary: Allow 'continue' inside 'try' clause Follow-Ups: Date: 2000-Dec-21 13:23 By: twouters Comment: This patch allows the use of 'continue' inside the 'try' part of try/except and try/finally. Allowing it inside the 'finally' clause requires more tricky juggling, however. (Suggestions welcome, of course :) The patch adds a new opcode, but does not update the bytecode magic. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102989&group_id=5470 From noreply@sourceforge.net Thu Dec 21 22:02:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 21 Dec 2000 14:02:00 -0800 Subject: [Patches] [Patch #102989] Allow 'continue' inside 'try' clause Message-ID: Patch #102989 has been updated. Project: python Category: core (C code) Status: Open Submitted by: twouters Assigned to : nobody Summary: Allow 'continue' inside 'try' clause Follow-Ups: Date: 2000-Dec-21 14:01 By: twouters Comment: Slightly better version, that actually compiles ;P Not done yet, though, the error for 'continue' inside 'finally' is still off. ------------------------------------------------------- Date: 2000-Dec-21 13:23 By: twouters Comment: This patch allows the use of 'continue' inside the 'try' part of try/except and try/finally. Allowing it inside the 'finally' clause requires more tricky juggling, however. (Suggestions welcome, of course :) The patch adds a new opcode, but does not update the bytecode magic. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102989&group_id=5470 From noreply@sourceforge.net Fri Dec 22 14:04:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 22 Dec 2000 06:04:54 -0800 Subject: [Patches] [Patch #103002] Fix for #116285: Properly raise UnicodeErrors Message-ID: Patch #103002 has been updated. Project: python Category: library Status: Open Submitted by: loewis Assigned to : nobody Summary: Fix for #116285: Properly raise UnicodeErrors ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103002&group_id=5470 From noreply@sourceforge.net Fri Dec 22 14:08:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 22 Dec 2000 06:08:44 -0800 Subject: [Patches] [Patch #103002] Fix for #116285: Properly raise UnicodeErrors Message-ID: Patch #103002 has been updated. Project: python Category: library Status: Open Submitted by: loewis Assigned to : lemburg Summary: Fix for #116285: Properly raise UnicodeErrors Follow-Ups: Date: 2000-Dec-22 06:08 By: loewis Comment: This patch corrects the error in PyUnicode_EncodeCharmap which would result in a to-latin1 mapping even if the target character include these characters. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103002&group_id=5470 From noreply@sourceforge.net Fri Dec 22 14:24:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 22 Dec 2000 06:24:38 -0800 Subject: [Patches] [Patch #102813] _cursesmodule: Add panel support Message-ID: Patch #102813 has been updated. Project: python Category: Modules Status: Open Submitted by: akuchling Assigned to : fdrake Summary: _cursesmodule: Add panel support Follow-Ups: Date: 2000-Dec-22 06:24 By: akuchling Comment: Reassigning to Fred for a quick proofreading. Feel free to reassign it to another of the Pythoneers if you like. ------------------------------------------------------- Date: 2000-Dec-18 19:02 By: akuchling Comment: Greatly revised version of this patch. Using a CObject, _cursesmodule.c now exports an API for other C extensions, and the panel extensions have been moved into a _curses_panel.c file. Not included in this patch: Lib/curses/panel.py, which just imports everything public from _curses_panel, documentation changes, and the modified Setup.in file. ------------------------------------------------------- Date: 2000-Dec-15 05:20 By: akuchling Comment: Updated version of the patch from Thomas, that fixes most of my previous comments. ------------------------------------------------------- Date: 2000-Dec-12 20:03 By: akuchling Comment: Patch from Thomas Gellekum to add panel support. My comments: * Module-level panel_above and panel_below: how about naming them top_panel() and bottom_panel()? * In PyCurses_Panel_Below(), the text of an exception refers to panel_above (cut-and-paste error) * Maybe the panel functions should be in a separate file that gets #included; _cursesmodule.c is 2502 lines long, which is really cumbersome. The window functions should also be split out; I'll bring this up on python-dev. * set_panel_userptr() and panel_userptr(): why require that they be strings? They could simply be arbitrary Python objects that get INCREF'ed. (And I think saving a pointer output of PyArg_Parse() is incorrect; if the string is then deleted, this will become a dangling pointer). * PyCursesPanel_Replace_Panel(): you can parse arguments and require them to be of a certain class with PyArg_ParseTuple(args, "O!", &PyWhatever_Type, &arg, ...) * PyCursesPanel_Replace_Panel(): Can replace_panel() fail? If so, then the old and new window objects should only be DECREF/INCREF'ed if no error occurred. (There's also a panel_above reference in an exception here.) * panel_above/below(): what do they return when called on the top or bottom panel? (NULL would be a natural return value, so I'm wondering if NULL is really an error.) * I don't think Py_FatalError() should be used when a panel isn't on the linked list. (Perhaps some C code is creating panels.) Instead this should simply raise a regular exception, perhaps RuntimeError. These are my comments for now, but I'll keep looking at the code./ ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102813&group_id=5470 From noreply@sourceforge.net Fri Dec 22 15:07:03 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 22 Dec 2000 07:07:03 -0800 Subject: [Patches] [Patch #102813] _cursesmodule: Add panel support Message-ID: Patch #102813 has been updated. Project: python Category: Modules Status: Open Submitted by: akuchling Assigned to : akuchling Summary: _cursesmodule: Add panel support Follow-Ups: Date: 2000-Dec-22 07:07 By: fdrake Comment: The indentation in the new module is different from the _curses implementation and from the "standard" Python conventions; can we bring it into line with *something* else in the distribution? Any of: * Guido-style: 8-column hard-tab indents. * New style: 4-column space-only indents. * _curses style: 2 column indents. I'd prefer "New style", myself. Otherwise it looks good from a very quick look. Documentation is required. Put that in a new file, Doc/lib/libcursespanel.tex. ------------------------------------------------------- Date: 2000-Dec-22 06:24 By: akuchling Comment: Reassigning to Fred for a quick proofreading. Feel free to reassign it to another of the Pythoneers if you like. ------------------------------------------------------- Date: 2000-Dec-18 19:02 By: akuchling Comment: Greatly revised version of this patch. Using a CObject, _cursesmodule.c now exports an API for other C extensions, and the panel extensions have been moved into a _curses_panel.c file. Not included in this patch: Lib/curses/panel.py, which just imports everything public from _curses_panel, documentation changes, and the modified Setup.in file. ------------------------------------------------------- Date: 2000-Dec-15 05:20 By: akuchling Comment: Updated version of the patch from Thomas, that fixes most of my previous comments. ------------------------------------------------------- Date: 2000-Dec-12 20:03 By: akuchling Comment: Patch from Thomas Gellekum to add panel support. My comments: * Module-level panel_above and panel_below: how about naming them top_panel() and bottom_panel()? * In PyCurses_Panel_Below(), the text of an exception refers to panel_above (cut-and-paste error) * Maybe the panel functions should be in a separate file that gets #included; _cursesmodule.c is 2502 lines long, which is really cumbersome. The window functions should also be split out; I'll bring this up on python-dev. * set_panel_userptr() and panel_userptr(): why require that they be strings? They could simply be arbitrary Python objects that get INCREF'ed. (And I think saving a pointer output of PyArg_Parse() is incorrect; if the string is then deleted, this will become a dangling pointer). * PyCursesPanel_Replace_Panel(): you can parse arguments and require them to be of a certain class with PyArg_ParseTuple(args, "O!", &PyWhatever_Type, &arg, ...) * PyCursesPanel_Replace_Panel(): Can replace_panel() fail? If so, then the old and new window objects should only be DECREF/INCREF'ed if no error occurred. (There's also a panel_above reference in an exception here.) * panel_above/below(): what do they return when called on the top or bottom panel? (NULL would be a natural return value, so I'm wondering if NULL is really an error.) * I don't think Py_FatalError() should be used when a panel isn't on the linked list. (Perhaps some C code is creating panels.) Instead this should simply raise a regular exception, perhaps RuntimeError. These are my comments for now, but I'll keep looking at the code./ ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102813&group_id=5470 From noreply@sourceforge.net Fri Dec 22 21:59:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 22 Dec 2000 13:59:35 -0800 Subject: [Patches] [Patch #102813] _cursesmodule: Add panel support Message-ID: Patch #102813 has been updated. Project: python Category: Modules Status: Closed Submitted by: akuchling Assigned to : akuchling Summary: _cursesmodule: Add panel support Follow-Ups: Date: 2000-Dec-22 13:59 By: akuchling Comment: Checked in. ------------------------------------------------------- Date: 2000-Dec-22 07:07 By: fdrake Comment: The indentation in the new module is different from the _curses implementation and from the "standard" Python conventions; can we bring it into line with *something* else in the distribution? Any of: * Guido-style: 8-column hard-tab indents. * New style: 4-column space-only indents. * _curses style: 2 column indents. I'd prefer "New style", myself. Otherwise it looks good from a very quick look. Documentation is required. Put that in a new file, Doc/lib/libcursespanel.tex. ------------------------------------------------------- Date: 2000-Dec-22 06:24 By: akuchling Comment: Reassigning to Fred for a quick proofreading. Feel free to reassign it to another of the Pythoneers if you like. ------------------------------------------------------- Date: 2000-Dec-18 19:02 By: akuchling Comment: Greatly revised version of this patch. Using a CObject, _cursesmodule.c now exports an API for other C extensions, and the panel extensions have been moved into a _curses_panel.c file. Not included in this patch: Lib/curses/panel.py, which just imports everything public from _curses_panel, documentation changes, and the modified Setup.in file. ------------------------------------------------------- Date: 2000-Dec-15 05:20 By: akuchling Comment: Updated version of the patch from Thomas, that fixes most of my previous comments. ------------------------------------------------------- Date: 2000-Dec-12 20:03 By: akuchling Comment: Patch from Thomas Gellekum to add panel support. My comments: * Module-level panel_above and panel_below: how about naming them top_panel() and bottom_panel()? * In PyCurses_Panel_Below(), the text of an exception refers to panel_above (cut-and-paste error) * Maybe the panel functions should be in a separate file that gets #included; _cursesmodule.c is 2502 lines long, which is really cumbersome. The window functions should also be split out; I'll bring this up on python-dev. * set_panel_userptr() and panel_userptr(): why require that they be strings? They could simply be arbitrary Python objects that get INCREF'ed. (And I think saving a pointer output of PyArg_Parse() is incorrect; if the string is then deleted, this will become a dangling pointer). * PyCursesPanel_Replace_Panel(): you can parse arguments and require them to be of a certain class with PyArg_ParseTuple(args, "O!", &PyWhatever_Type, &arg, ...) * PyCursesPanel_Replace_Panel(): Can replace_panel() fail? If so, then the old and new window objects should only be DECREF/INCREF'ed if no error occurred. (There's also a panel_above reference in an exception here.) * panel_above/below(): what do they return when called on the top or bottom panel? (NULL would be a natural return value, so I'm wondering if NULL is really an error.) * I don't think Py_FatalError() should be used when a panel isn't on the linked list. (Perhaps some C code is creating panels.) Instead this should simply raise a regular exception, perhaps RuntimeError. These are my comments for now, but I'll keep looking at the code./ ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102813&group_id=5470 From noreply@sourceforge.net Sat Dec 23 11:46:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 23 Dec 2000 03:46:01 -0800 Subject: [Patches] [Patch #103002] Fix for #116285: Properly raise UnicodeErrors Message-ID: Patch #103002 has been updated. Project: python Category: library Status: Open Submitted by: loewis Assigned to : lemburg Summary: Fix for #116285: Properly raise UnicodeErrors Follow-Ups: Date: 2000-Dec-23 03:46 By: lemburg Comment: Please upload the patch again in plain text format. The format you used seems to be uuencoded gzipped -- not exactly readable by human ;-) Thanks. ------------------------------------------------------- Date: 2000-Dec-22 06:08 By: loewis Comment: This patch corrects the error in PyUnicode_EncodeCharmap which would result in a to-latin1 mapping even if the target character include these characters. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103002&group_id=5470 From noreply@sourceforge.net Sun Dec 24 15:27:45 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Dec 2000 07:27:45 -0800 Subject: [Patches] [Patch #103012] Update fpectlmodule for current glibc Message-ID: Patch #103012 has been updated. Project: python Category: Modules Status: Open Submitted by: akuchling Assigned to : nobody Summary: Update fpectlmodule for current glibc ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103012&group_id=5470 From noreply@sourceforge.net Wed Dec 27 22:12:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 27 Dec 2000 14:12:12 -0800 Subject: [Patches] [Patch #102989] Allow 'continue' inside 'try' clause Message-ID: Patch #102989 has been updated. Project: python Category: core (C code) Status: Open Submitted by: twouters Assigned to : gvanrossum Summary: Allow 'continue' inside 'try' clause Follow-Ups: Date: 2000-Dec-21 14:01 By: twouters Comment: Slightly better version, that actually compiles ;P Not done yet, though, the error for 'continue' inside 'finally' is still off. ------------------------------------------------------- Date: 2000-Dec-21 13:23 By: twouters Comment: This patch allows the use of 'continue' inside the 'try' part of try/except and try/finally. Allowing it inside the 'finally' clause requires more tricky juggling, however. (Suggestions welcome, of course :) The patch adds a new opcode, but does not update the bytecode magic. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102989&group_id=5470 From loewis@informatik.hu-berlin.de Wed Dec 27 23:32:20 2000 From: loewis@informatik.hu-berlin.de (Martin von Loewis) Date: Thu, 28 Dec 2000 00:32:20 +0100 (MET) Subject: [Patches] Re: [Patch #103002] Fix for #116285: Properly raise UnicodeErrors In-Reply-To: (noreply@sourceforge.net) References: Message-ID: <200012272332.AAA23893@pandora.informatik.hu-berlin.de> > Please upload the patch again in plain text format. The format you > used seems to be uuencoded gzipped -- not exactly readable > by human ;-) I'm afraid this is not possible - the original upload was rejected by SF due to its size. Please advise an alternate procedure. Regards, Martin P.S. The patch is that large mainly because it touches all the codecs. If I remove parts of the patch, presenting the changes to only some codecs, I can probably get it into the patch manager. From noreply@sourceforge.net Wed Dec 27 23:46:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 27 Dec 2000 15:46:49 -0800 Subject: [Patches] [Patch #102989] Allow 'continue' inside 'try' clause Message-ID: Patch #102989 has been updated. Project: python Category: core (C code) Status: Open Submitted by: twouters Assigned to : gvanrossum Summary: Allow 'continue' inside 'try' clause Follow-Ups: Date: 2000-Dec-27 15:46 By: twouters Comment: New version, 'final' as far as I'm concerned, unless the Power that Is prefers a 'PyFrame_GetCurrentBlock()' function over the ugly 'pop-and-push' hack that the current patch uses. Finally figured out why 'try: pass; finally: continue' wasn't raising the proper error: it never did ! It's just a bug in the current implementation, not this patch :) Updated test suites, including a test for the newly functional syntax (in test_grammar.) Not yet updated docs, those will follow. (Found another bug in the docs: it says you can do 'continue' inside 'finally', but you never could.) ------------------------------------------------------- Date: 2000-Dec-21 14:01 By: twouters Comment: Slightly better version, that actually compiles ;P Not done yet, though, the error for 'continue' inside 'finally' is still off. ------------------------------------------------------- Date: 2000-Dec-21 13:23 By: twouters Comment: This patch allows the use of 'continue' inside the 'try' part of try/except and try/finally. Allowing it inside the 'finally' clause requires more tricky juggling, however. (Suggestions welcome, of course :) The patch adds a new opcode, but does not update the bytecode magic. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102989&group_id=5470 From noreply@sourceforge.net Thu Dec 28 00:01:47 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 27 Dec 2000 16:01:47 -0800 Subject: [Patches] [Patch #102989] Allow 'continue' inside 'try' clause Message-ID: Patch #102989 has been updated. Project: python Category: core (C code) Status: Open Submitted by: twouters Assigned to : gvanrossum Summary: Allow 'continue' inside 'try' clause Follow-Ups: Date: 2000-Dec-27 16:01 By: twouters Comment: Okay, really a new version now. (Forgot to click on 'Upload revised patch' last time.) Added documentation changes; the implementation-limitation of 'continue' inside 'try' was less extensively documented than I feared, and actually pretty incomplete. TeX code is untested, as I don't have network connectivity on my laptop right now, and that's the only place I got Fred's shakey LaTeX setup to work ;) ------------------------------------------------------- Date: 2000-Dec-27 15:46 By: twouters Comment: New version, 'final' as far as I'm concerned, unless the Power that Is prefers a 'PyFrame_GetCurrentBlock()' function over the ugly 'pop-and-push' hack that the current patch uses. Finally figured out why 'try: pass; finally: continue' wasn't raising the proper error: it never did ! It's just a bug in the current implementation, not this patch :) Updated test suites, including a test for the newly functional syntax (in test_grammar.) Not yet updated docs, those will follow. (Found another bug in the docs: it says you can do 'continue' inside 'finally', but you never could.) ------------------------------------------------------- Date: 2000-Dec-21 14:01 By: twouters Comment: Slightly better version, that actually compiles ;P Not done yet, though, the error for 'continue' inside 'finally' is still off. ------------------------------------------------------- Date: 2000-Dec-21 13:23 By: twouters Comment: This patch allows the use of 'continue' inside the 'try' part of try/except and try/finally. Allowing it inside the 'finally' clause requires more tricky juggling, however. (Suggestions welcome, of course :) The patch adds a new opcode, but does not update the bytecode magic. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102989&group_id=5470 From noreply@sourceforge.net Thu Dec 28 01:11:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 27 Dec 2000 17:11:49 -0800 Subject: [Patches] [Patch #103028] Make tempfile.mktemp threadsafe Message-ID: Patch #103028 has been updated. Project: python Category: library Status: Open Submitted by: nobody Assigned to : nobody Summary: Make tempfile.mktemp threadsafe ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103028&group_id=5470 From noreply@sourceforge.net Thu Dec 28 01:19:05 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 27 Dec 2000 17:19:05 -0800 Subject: [Patches] [Patch #103028] Make tempfile.mktemp threadsafe Message-ID: Patch #103028 has been updated. Project: python Category: library Status: Open Submitted by: nobody Assigned to : nobody Summary: Make tempfile.mktemp threadsafe Follow-Ups: Date: 2000-Dec-27 17:19 By: tseaver Comment: Doesn't need the 'global counter' in mktemp: [/usr/lib/python1.5] $ diff -u tempfile.py.org tempfile.py --- tempfile.py.org Wed Dec 27 19:44:29 2000 +++ tempfile.py Wed Dec 27 20:05:57 2000 @@ -84,15 +84,35 @@ counter = 0 +# +# In threaded Pythons, make this operation threadsafe. +# +try: + from threading import Lock + counterLock = Lock() +except: + def _bumpCounter(): + global counter + counter = counter + 1 + return counter +else: + def _bumpCounter(): + global counter, counterLock + counterLock.acquire() + try: + counter = counter + 1 + return counter + finally: + counterLock.release() + # User-callable function to return a unique temporary file name def mktemp(suffix=""): - global counter dir = gettempdir() pre = gettempprefix() while 1: - counter = counter + 1 + counter = _bumpCounter() file = os.path.join(dir, pre + `counter` + suffix) if not os.path.exists(file): return file ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103028&group_id=5470 From noreply@sourceforge.net Thu Dec 28 05:50:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 27 Dec 2000 21:50:24 -0800 Subject: [Patches] [Patch #103029] Implementation of chomp() on string objects. Message-ID: Patch #103029 has been updated. Project: python Category: core (C code) Status: Open Submitted by: bjorn_pettersen Assigned to : nobody Summary: Implementation of chomp() on string objects. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103029&group_id=5470 From mal@lemburg.com Thu Dec 28 09:40:08 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 28 Dec 2000 10:40:08 +0100 Subject: [Patches] Re: [Patch #103002] Fix for #116285: Properly raise UnicodeErrors References: <200012272332.AAA23893@pandora.informatik.hu-berlin.de> Message-ID: <3A4B0A77.B3EF209E@lemburg.com> Martin von Loewis wrote: > > > Please upload the patch again in plain text format. The format you > > used seems to be uuencoded gzipped -- not exactly readable > > by human ;-) > > I'm afraid this is not possible - the original upload was rejected by > SF due to its size. Please advise an alternate procedure. > > Regards, > Martin > > P.S. The patch is that large mainly because it touches all the > codecs. If I remove parts of the patch, presenting the changes to only > some codecs, I can probably get it into the patch manager. Since we want to discuss the changes, I think this would be the better solution. BTW, since this is a fairly generic change, wouldn't it make sense to patch the generator script and then regenerate the codecs ? -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas@xs4all.net Thu Dec 28 09:56:08 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 28 Dec 2000 10:56:08 +0100 Subject: [Patches] Re: [Patch #103002] Fix for #116285: Properly raise UnicodeErrors In-Reply-To: <200012272332.AAA23893@pandora.informatik.hu-berlin.de>; from loewis@informatik.hu-berlin.de on Thu, Dec 28, 2000 at 12:32:20AM +0100 References: <200012272332.AAA23893@pandora.informatik.hu-berlin.de> Message-ID: <20001228105608.B6042@xs4all.nl> On Thu, Dec 28, 2000 at 12:32:20AM +0100, Martin von Loewis wrote: > > Please upload the patch again in plain text format. The format you > > used seems to be uuencoded gzipped -- not exactly readable > > by human ;-) > I'm afraid this is not possible - the original upload was rejected by > SF due to its size. Please advise an alternate procedure. Put it on a webpage (the python.sourceforge.net one, for instance) and upload a reference to it, instead. Or perhaps include an example, and refer to the full patch for more info. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From noreply@sourceforge.net Thu Dec 28 14:52:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Dec 2000 06:52:13 -0800 Subject: [Patches] [Patch #103028] Make tempfile.mktemp threadsafe Message-ID: Patch #103028 has been updated. Project: python Category: library Status: Open Submitted by: nobody Assigned to : tim_one Summary: Make tempfile.mktemp threadsafe Follow-Ups: Date: 2000-Dec-28 06:52 By: gvanrossum Comment: Randomly assigned to Tim. I'd like mktemp to be thread-safe but I wish it wouldn't have to use a lock. Is there any other way? ------------------------------------------------------- Date: 2000-Dec-27 17:19 By: tseaver Comment: Doesn't need the 'global counter' in mktemp: [/usr/lib/python1.5] $ diff -u tempfile.py.org tempfile.py --- tempfile.py.org Wed Dec 27 19:44:29 2000 +++ tempfile.py Wed Dec 27 20:05:57 2000 @@ -84,15 +84,35 @@ counter = 0 +# +# In threaded Pythons, make this operation threadsafe. +# +try: + from threading import Lock + counterLock = Lock() +except: + def _bumpCounter(): + global counter + counter = counter + 1 + return counter +else: + def _bumpCounter(): + global counter, counterLock + counterLock.acquire() + try: + counter = counter + 1 + return counter + finally: + counterLock.release() + # User-callable function to return a unique temporary file name def mktemp(suffix=""): - global counter dir = gettempdir() pre = gettempprefix() while 1: - counter = counter + 1 + counter = _bumpCounter() file = os.path.join(dir, pre + `counter` + suffix) if not os.path.exists(file): return file ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103028&group_id=5470 From noreply@sourceforge.net Thu Dec 28 15:02:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Dec 2000 07:02:10 -0800 Subject: [Patches] [Patch #103029] Implementation of chomp() on string objects. Message-ID: Patch #103029 has been updated. Project: python Category: core (C code) Status: Open Submitted by: bjorn_pettersen Assigned to : nobody Summary: Implementation of chomp() on string objects. Follow-Ups: Date: 2000-Dec-28 07:02 By: gvanrossum Comment: Hm. s.rstrip() does the same thing (plus strips trailing whitespace, which is rarely a problem). Do you really need this function? If so, please don't call it chomp() -- that's a Perl-ism that makes no sense to anyone else. *If* (and I say *if*) this is accepted, we would require a Unicode version and documentation as well. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103029&group_id=5470 From noreply@sourceforge.net Thu Dec 28 15:09:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Dec 2000 07:09:33 -0800 Subject: [Patches] [Patch #102989] Allow 'continue' inside 'try' clause Message-ID: Patch #102989 has been updated. Project: python Category: core (C code) Status: Open Submitted by: twouters Assigned to : jhylton Summary: Allow 'continue' inside 'try' clause Follow-Ups: Date: 2000-Dec-28 07:09 By: gvanrossum Comment: I don't have time to review this myself for now, so I've assigned it to Jeremy, who is pretty familiar with the compiler and virtual machine. I do appreciate the effort very much! If it works, it should go in. (What's the JPython situation?) ------------------------------------------------------- Date: 2000-Dec-27 16:01 By: twouters Comment: Okay, really a new version now. (Forgot to click on 'Upload revised patch' last time.) Added documentation changes; the implementation-limitation of 'continue' inside 'try' was less extensively documented than I feared, and actually pretty incomplete. TeX code is untested, as I don't have network connectivity on my laptop right now, and that's the only place I got Fred's shakey LaTeX setup to work ;) ------------------------------------------------------- Date: 2000-Dec-27 15:46 By: twouters Comment: New version, 'final' as far as I'm concerned, unless the Power that Is prefers a 'PyFrame_GetCurrentBlock()' function over the ugly 'pop-and-push' hack that the current patch uses. Finally figured out why 'try: pass; finally: continue' wasn't raising the proper error: it never did ! It's just a bug in the current implementation, not this patch :) Updated test suites, including a test for the newly functional syntax (in test_grammar.) Not yet updated docs, those will follow. (Found another bug in the docs: it says you can do 'continue' inside 'finally', but you never could.) ------------------------------------------------------- Date: 2000-Dec-21 14:01 By: twouters Comment: Slightly better version, that actually compiles ;P Not done yet, though, the error for 'continue' inside 'finally' is still off. ------------------------------------------------------- Date: 2000-Dec-21 13:23 By: twouters Comment: This patch allows the use of 'continue' inside the 'try' part of try/except and try/finally. Allowing it inside the 'finally' clause requires more tricky juggling, however. (Suggestions welcome, of course :) The patch adds a new opcode, but does not update the bytecode magic. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102989&group_id=5470 From noreply@sourceforge.net Thu Dec 28 17:48:30 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Dec 2000 09:48:30 -0800 Subject: [Patches] [Patch #103002] Fix for #116285: Properly raise UnicodeErrors Message-ID: Patch #103002 has been updated. Project: python Category: library Status: Open Submitted by: loewis Assigned to : lemburg Summary: Fix for #116285: Properly raise UnicodeErrors Follow-Ups: Date: 2000-Dec-28 09:48 By: loewis Comment: This version of the patch only includes the changes to gencodec.py; not the changes to the generated files. ------------------------------------------------------- Date: 2000-Dec-23 03:46 By: lemburg Comment: Please upload the patch again in plain text format. The format you used seems to be uuencoded gzipped -- not exactly readable by human ;-) Thanks. ------------------------------------------------------- Date: 2000-Dec-22 06:08 By: loewis Comment: This patch corrects the error in PyUnicode_EncodeCharmap which would result in a to-latin1 mapping even if the target character include these characters. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103002&group_id=5470 From noreply@sourceforge.net Thu Dec 28 17:52:09 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Dec 2000 09:52:09 -0800 Subject: [Patches] [Patch #103029] Implementation of chomp() on string objects. Message-ID: Patch #103029 has been updated. Project: python Category: core (C code) Status: Rejected Submitted by: bjorn_pettersen Assigned to : nobody Summary: Implementation of chomp() on string objects. Follow-Ups: Date: 2000-Dec-28 09:52 By: gvanrossum Comment: Rejecting this now. Comments on python-dev are mostly negative. Note that there's also splitlines(). ------------------------------------------------------- Date: 2000-Dec-28 07:02 By: gvanrossum Comment: Hm. s.rstrip() does the same thing (plus strips trailing whitespace, which is rarely a problem). Do you really need this function? If so, please don't call it chomp() -- that's a Perl-ism that makes no sense to anyone else. *If* (and I say *if*) this is accepted, we would require a Unicode version and documentation as well. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103029&group_id=5470 From noreply@sourceforge.net Thu Dec 28 18:33:47 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Dec 2000 10:33:47 -0800 Subject: [Patches] [Patch #103002] Fix for #116285: Properly raise UnicodeErrors Message-ID: Patch #103002 has been updated. Project: python Category: library Status: Open Submitted by: loewis Assigned to : lemburg Summary: Fix for #116285: Properly raise UnicodeErrors Follow-Ups: Date: 2000-Dec-28 10:33 By: lemburg Comment: The patch looks OK (except for some minor cosmetic changes I would apply). My only problem with it is your copyright notice. AFAIK, patches to the Python core cannot contain copyright notices without proper license information. OTOH, I don't think that these minor changes really warrant adding a complete license paragraph. Wouldn't a line like "Additional changes to support decoding maps by Martin v. Loewis" suffice ? Which changes these are would be immediately clear by looking at the CVS history. ------------------------------------------------------- Date: 2000-Dec-28 09:48 By: loewis Comment: This version of the patch only includes the changes to gencodec.py; not the changes to the generated files. ------------------------------------------------------- Date: 2000-Dec-23 03:46 By: lemburg Comment: Please upload the patch again in plain text format. The format you used seems to be uuencoded gzipped -- not exactly readable by human ;-) Thanks. ------------------------------------------------------- Date: 2000-Dec-22 06:08 By: loewis Comment: This patch corrects the error in PyUnicode_EncodeCharmap which would result in a to-latin1 mapping even if the target character include these characters. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103002&group_id=5470 From noreply@sourceforge.net Fri Dec 29 17:08:27 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 29 Dec 2000 09:08:27 -0800 Subject: [Patches] [Patch #103029] Implementation of chomp() on string objects. Message-ID: Patch #103029 has been updated. Project: python Category: core (C code) Status: Rejected Submitted by: bjorn_pettersen Assigned to : nobody Summary: Implementation of chomp() on string objects. Follow-Ups: Date: 2000-Dec-29 09:08 By: bjorn_pettersen Comment: It was almost universally felt (on c.l.py) that a method doing this would be a good idea (since rstrip does too much, and splitlines() would be rather cryptic when used in the common "while 1:" idiom -- not to mention that the common "line = line[:-1]" is completely wrong). Naming was an issue. I don't do Perl, but even I know what chomp is after a dozen or so requests on c.l.py. Perhaps rmLineTerm() or some such would be better? If this is reconsidered, I'd be glad to implement a patch for both the unicode string and the documentation. ------------------------------------------------------- Date: 2000-Dec-28 09:52 By: gvanrossum Comment: Rejecting this now. Comments on python-dev are mostly negative. Note that there's also splitlines(). ------------------------------------------------------- Date: 2000-Dec-28 07:02 By: gvanrossum Comment: Hm. s.rstrip() does the same thing (plus strips trailing whitespace, which is rarely a problem). Do you really need this function? If so, please don't call it chomp() -- that's a Perl-ism that makes no sense to anyone else. *If* (and I say *if*) this is accepted, we would require a Unicode version and documentation as well. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103029&group_id=5470 From noreply@sourceforge.net Fri Dec 29 23:27:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 29 Dec 2000 15:27:04 -0800 Subject: [Patches] [Patch #103048] Generate simple JUMP_FORWARD for 'break' outside 'try' Message-ID: Patch #103048 has been updated. Project: python Category: core (C code) Status: Open Submitted by: twouters Assigned to : nobody Summary: Generate simple JUMP_FORWARD for 'break' outside 'try' ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103048&group_id=5470 From noreply@sourceforge.net Fri Dec 29 23:28:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 29 Dec 2000 15:28:12 -0800 Subject: [Patches] [Patch #103048] Generate simple JUMP_FORWARD for 'break' outside 'try' Message-ID: Patch #103048 has been updated. Project: python Category: core (C code) Status: Open Submitted by: twouters Assigned to : jhylton Summary: Generate simple JUMP_FORWARD for 'break' outside 'try' Follow-Ups: Date: 2000-Dec-29 15:28 By: twouters Comment: Assigned to Jeremy because he's also got the 'continue inside try' patch, and it's vaguely similar. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103048&group_id=5470 From noreply@sourceforge.net Sat Dec 30 01:22:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 29 Dec 2000 17:22:06 -0800 Subject: [Patches] [Patch #102980] BaseServer class for SocketServer.py (inh. by TCPServer) Message-ID: Patch #102980 has been updated. Project: python Category: library Status: Open Submitted by: lkcl Assigned to : nobody Summary: BaseServer class for SocketServer.py (inh. by TCPServer) Follow-Ups: Date: 2000-Dec-29 17:22 By: lkcl Comment: the socketserver code, with a little bit of tweaking, can be made sufficiently general to service "requests" of any kind, not just by sockets. the BaseServer class was created, for example, to poll a table in a MYSQL database every 2 seconds. each entry in the table can be allocated a Handler which deals with the entry. with this patch, using BaseServer and ThreadedServer classes, the creation of the server that reads and handles MySQL table entries instead of a socket was utterly trivial: about 50 lines of python code. you may consider this code to be utterly useless [why would anyone else want to do anything like this???] - you are entitled to your opinion. if you think so, then think of this: have you considered how to cleanly add SSL to the TCPSocketServer? what about using shared memory as the communications mechanism for a server, instead of sockets? what about communication using files? the SocketServer code is extremely good every useful. it's just that as it stands, it is tied to sockets, which is not as useful. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102980&group_id=5470 From noreply@sourceforge.net Sat Dec 30 09:06:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 30 Dec 2000 01:06:07 -0800 Subject: [Patches] [Patch #102485] minidom.py: Check for legal children Message-ID: Patch #102485 has been updated. Project: python Category: XML Status: Accepted Submitted by: akuchling Assigned to : akuchling Summary: minidom.py: Check for legal children Follow-Ups: Date: 2000-Dec-30 01:06 By: loewis Comment: The patch looks fine now. ------------------------------------------------------- Date: 2000-Dec-20 15:05 By: akuchling Comment: Revised the patch to match the current CVS tree, and to raise HierarchyRequestErr instead of ValueError. ------------------------------------------------------- Date: 2000-Dec-13 20:48 By: fdrake Comment: Now that the exceptions have been added to xml.dom and documented in the development version of the docs, this patch needs to be updated to throw the right exceptions. ------------------------------------------------------- Date: 2000-Nov-23 08:24 By: akuchling Comment: Revised version of patch; the first version was generated against a really old version of minidom.py. ------------------------------------------------------- Date: 2000-Dec-03 03:37 By: loewis Comment: I'd prefer to postpone this patch somewhat, until the official DOM exceptions are available in xml.dom, and then to raise those instead. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102485&group_id=5470 From noreply@sourceforge.net Sat Dec 30 10:26:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 30 Dec 2000 02:26:33 -0800 Subject: [Patches] [Patch #103052] Restore non-cyclic operation of pulldom.PullDOM Message-ID: Patch #103052 has been updated. Project: python Category: XML Status: Open Submitted by: loewis Assigned to : nobody Summary: Restore non-cyclic operation of pulldom.PullDOM ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103052&group_id=5470 From noreply@sourceforge.net Sat Dec 30 10:27:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 30 Dec 2000 02:27:19 -0800 Subject: [Patches] [Patch #103052] Restore non-cyclic operation of pulldom.PullDOM Message-ID: Patch #103052 has been updated. Project: python Category: XML Status: Open Submitted by: loewis Assigned to : akuchling Summary: Restore non-cyclic operation of pulldom.PullDOM ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103052&group_id=5470 From noreply@sourceforge.net Sat Dec 30 10:33:37 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 30 Dec 2000 02:33:37 -0800 Subject: [Patches] [Patch #102915] xreadlines : readlines :: xrange : range Message-ID: Patch #102915 has been updated. Project: python Category: Modules Status: Open Submitted by: jepler Assigned to : nobody Summary: xreadlines : readlines :: xrange : range Follow-Ups: Date: 2000-Dec-30 02:33 By: loewis Comment: This patch appears to be incomplete. There is no documentation of the feature, and no other file-like object is touched: StringIO, cStringIO, gzip, codecs. ------------------------------------------------------- Date: 2000-Dec-18 19:32 By: jepler Comment: This patch implements an object 'xreadlines' in C, as well as a method on the file object to create one. xreadlines will let a 'for' loop iterate over the contents of a file without reading the whole file, yet at a speed almost equal to that of 'for line in f.readlines()'. Internally, it uses f.readlines(sizehint). Includes a test suite and a version of fileinput which uses it (approx. 50% speedup in fileinput as well). fileinput is not tested by test suite entry. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102915&group_id=5470 From noreply@sourceforge.net Sat Dec 30 15:14:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 30 Dec 2000 07:14:06 -0800 Subject: [Patches] [Patch #101170] Prevent old extensions from crashing Message-ID: Patch #101170 has been updated. Project: python Category: Windows Status: Open Submitted by: chega Assigned to : mhammond Summary: Prevent old extensions from crashing Follow-Ups: Date: 2000-Dec-30 07:14 By: loewis Comment: I believe this patch is superceded with patch #101676, which is installed as 2.7 of dynload_win.c; so I propose to reject this patch. ------------------------------------------------------- Date: 2000-Aug-12 01:55 By: chega Comment: This patch will prevent old (1.5/1.6) extensions from crashing under Python 2.0 (Also changed pathbuf[260] to pathbuf[MAX_PATH]) ------------------------------------------------------- Date: 2000-Aug-15 15:26 By: tim_one Comment: Assigned to MarkH. Please review or pass on to someone else. ------------------------------------------------------- Date: 2000-Aug-15 16:26 By: mhammond Comment: I'm not sure this is worth adding. Note that we already have code to prevent a crash in place - however, rather than raising an exception it simply calls Py_FatalError. This patch is potentially better, except that: * It will require regressing the patch made to modsupport.c (Rev 2.50) to prevent the same problem; that code will prevent this code kicking in! * It hard-codes the Python DLL names. This makes long term maintenance a PITA, and yet another file that needs to be updated when a version bumps. Are there other alternatives? * Once the module has been loaded, it may be too late to save the process anyway. I realize that the module init hasnt been called yet, but the module has been loaded, and may be doing things in its DllMain() that will destabilize the process. The big killer is simply that this code will never be triggered, as the check in modsupport.c will kick in first. Setting to postponed until we can get a better handle on this. A big advantage is that this style of change is not dependent on _old_ versions having the patch, only one actually running. Hence we can revive this patch at any time, and have it start working immediately. ------------------------------------------------------- Date: 2000-Aug-15 16:49 By: tim_one Comment: I agree with Postponing it. Thanks for the quick response! Feel like reviewing 7 controversial getopt patches now ? ------------------------------------------------------- Date: 2000-Aug-15 17:10 By: chega Comment: * The patch to modsupport.c will NOT save us in the case when someone loads 1.5 extension. See Guido's checkin comment. And I think that Python 1.6 will never be widely spread anyways, so in 99.9% cases it'll be 1.5 vs 2.0. * I agree that the hard-coded dll-names are PITA, but only a small one :-). The version check #if will make sure that this list gets updated. Also, if we keep Guido's patch in modsupport.c the list won't need updating. * I'd rather have an ImportError that PyFatalError() * I find the argument about DllMain() screwing up the process somewhat err... artificial ;-))) I have never seen such a module. Have you? The only thing I am not sure about is whether there is any legitimate reason to have python15 loaded. AFAIR, python COM servers are alwaus out-of-process, aren't they? Can you think of something else? If such reasons do exist, we may want to put another check before loading the module and then bypass the post-check if python15 has been already loaded. ------------------------------------------------------- Date: 2000-Aug-21 05:38 By: mhammond Comment: Another alternative would be to create a Win32 event object, with name "Python-%d" % pid, and have DllMain() attempt to acquire it. This would prevent the "old" Python subsystem starting at all, nipping it right in the bud (and should return a clean ImportError back to the caller!) Does this sound worthwhile? ------------------------------------------------------- Date: 2000-Aug-21 05:43 By: mhammond Comment: Oops - I should have mentioned - Jack Jansen mailed me with the DllMain() idea :-) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101170&group_id=5470 From noreply@sourceforge.net Sat Dec 30 15:25:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 30 Dec 2000 07:25:18 -0800 Subject: [Patches] [Patch #101196] IPv6 patch against 2.0 CVS tree, as of 20000816 21:52 Message-ID: Patch #101196 has been updated. Project: python Category: core (C code) Status: Out of date Submitted by: itojun Assigned to : fdrake Summary: IPv6 patch against 2.0 CVS tree, as of 20000816 21:52 Follow-Ups: Date: 2000-Dec-30 07:25 By: loewis Comment: I got *many* rejects when trying to apply this patch to today's CVS tree. I recommend that patches for generated files (config.h.in, configure) are not included in the patch because they outdate too easily. A number of changes in this patch have already been done by somebody else; others just don't fit into the current code anymore (perhaps due to indentation changes?). Anyway, I'll mark the patch as out-of-date. Please let me know when you upload a new version. ------------------------------------------------------- Date: 2000-Aug-16 05:59 By: itojun Comment: this is revised version of patch #101186 (now with my SourceForge accout... i'm not familiar with the system here, so forgive my possible mistake). 1.6b1 patch applied mostly clean to 2.0. It is confirmed that: - 1.6b1 + IPv6 patch works fine on NetBSD 1.4.2 + KAME, and NetBSD 1.5 - 1.6b1 + IPv6 patch works fine on NetBSD 1.4.2 (NOT an IPv6 ready machine) - 2.0 CVS tree + IPv6 patch works fine on NetBSD + KAME forgot to attach the following into the diff - so i attach it (README.v6) here as comment. I have submitted the patch for 1.5.1, 1.5.2 and 1.6b1, all hit a bad timing - bad luck. contact: core@kame.net, or itojun@kame.net --- IPv6-ready python 1.6 KAME Project $KAME: README.v6,v 1.9 2000/08/15 02:40:38 itojun Exp $ This patchkit enables python 1.6 to perform AF_INET6 socket operations. The only affected module is Modules/socketmodule.c. Modules/socketmodule.c In most cases, IPv6 address can be placed where IPv4 address fits. sockaddr sockaddr tuple is formatted as follows: IPv4: (host, port) IPv6: socket class methods always generate (host, port, flowinfo, scopeid). socket class methods will accept 2, 3, or 4 tuple (for backward compatibility). Compatibility warning: Some of the scripts assume that the sockaddr structure is 2 tuple, like: host, port = sock.getpeername() this will fail if you are connected to IPv6 node. socket.getaddrinfo(host, port [, family, socktype, proto, flags]) host: String or None port: String, Int or None family, socktype, proto, flags: Int, can be omitted Perform getaddrinfo(3). Returns List of the following 5 tuple: (family, socktype, proto, canonname, sockaddr) family: Int socktype: Int proto: Int canonname: String sockaddr: sockaddr (see above) See Lib/httplib.py for typical usage on the client side. socket.getnameinfo(sockaddr, flags) sockaddr: sockaddr flags: Int Perform getnameinfo(3). Returns the following 2 tuple: host: String, numeric or hostname depending on flgags port: String, numeric or portname depending on flgags socket.gethostbyname2(host, af) host: String af: Int Performs gethostbyname2(3). Returns numeric address representation for "host". socket.gethostbyaddr(addr) (behavior change if IPv6 support is compiled in) addr: String Performs gethostbyaddr(3). Returns string address representation for "addr". The function can take IPv6 numeric address as well. This behavior is not problematical, because - if you pass numeric "addr" parameter, we can always identify address family for it - return value is string address reprsentation, where IPv6 and IPv4 are not distinguishable. socket.bind(sa), socket.connect(sa) and others. (No behavior change, but be careful) See above for sockaddr format change. With Python "addr" portion of sockaddr (first element) can be string hostname. When the string hostname resolved to numeric address, it will obey address family of the socket (which was specified when socket.socket() was called). If you give some string that does not give matching address family, you will get some error. s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) # this is okay, if 'localhost' resolves to both IPv4/v6 s.connect('localhost', 80) # this is not okay, of course s.connect('::1', 80) # this is not okay, as v6only.kame.net will not resolve to IPv4 s.connect('v6only.kame.net', 80) Lib/httplib.py IPv6 ready. "host" in HTTP(host) will accept the following 3 forms: [host]:port host:port there must be only single colon host This is to allow IPv6 numeric URL (http://[host]:port/) in documents. IMHO "host:port" parsing should be implemented in urllib.py, not here. Lib/ftplib.py IPv6 ready. This uses EPSV/EPRT on IPv6 ftp. See RFC2428 for protocol details. Lib/SocketServer.py IPv6 ready. Wildcard bind on TCPServer, i.e. TCPServer(('', port)), will bind to wildcard socket on TCPServer.address_family. TCPServer.addresss_family is set to AF_INET by default, so ('', port) will usually bind AF_INET. Lib/smtplib.py, Lib/telnetlib.py, Lib/poplib.py IPv6 ready. Not much to say about protocol details - they just use TCP over IPv6. configure Configure has extra option, --enable-ipv6 and --disable-ipv6. The option controls IPv6 support feature. dynamic link issues in Modules/socketmodule.c Modules/socketmodule.c can be dynamically loaded only in the following situations: - getaddrinfo(3) and getnameinfo(3) are supplied by OS vendor in libc, and libc is dynamic link library. - OS vendor is NOT supplying getaddrinfo(3) nor getnameinfo(3), and You are configuring this package with --disable-ipv6. In this case, you'll be using missing/get{addr,name}info.c and they will refer to gethostby{name,addr}. gethostnameby{name,addr} can usually be found in dynamic-linking libc. In other situations, such as the following, please link Modules/socketmodule.c into python itself. - getaddrinfo(3) and getnameinfo(3) are supplied by OS vendor, but they are in statically linked library like libinet6.a. (KAME falls into this category) python usually links Modules/socketmodule.c into python itself (due to its popularity) so there should be no problem. restrictions - The patched tree will not use gethostbyname_r and other thread-ready libraries. Instead, it will use getaddrinfo() and getnameinfo() throughout the operation. todo - Patch bunch of library files in Lib/*.py. compatibility issues with existing scripts If you disable IPv6 support (./configure --disable-ipv6), the patched code is mostly compatible with original Python (except files in "Lib" directory modified for dual stack support). User script may choke if: - IPv4/v6 dualstack libc is supplied, python is compiled for dual stack, and script assumes some of IPv4-only behavior (especially sockaddr) - IPv4/v6 dualstack libc is supplied, python is compiled for IPv4 only, and script assumes some of IPv4-only behavior. In this case, Python socket class itself does not support IPv6, however, name resolution functions can return IPv6 names since they use IPv6-ready libc functions! I do not recommend this configuration. - script assumes certain IPv4-only version behavior in Lib/*.py. compilation If you use IPv6 features, it is assumed that you have working getaddrinfo() and getnameinfo() library functions. We have noticed that some of IPv6 stack is shipped with broken getaddrinfo(). In such cases, use missing/get{addr,name}info.c instead (but then, you need to have working getipnodeby{name,addr}). If you compile this on IPv4-only machine without get{addr,name}info, missing/get{addr,name}info.c will be used. They are from KAME IPv6 distribution and is #ifdef'ed for IPv4 only support. They are fairly complete implementation and you don't need to bother with bind 8.2 (bind 8.2 get{addr,name}info() has bugs). When compiling this kit on IPv6 node, you may need to specify some additional library paths or cpp defs. (like -linet6 or -DINET6) --enable-ipv6 will give you some warning, if the IPv6 stack is unknown to the "configure" script. Currently, the following IPv6 stacks are officially supported (i.e. we've checked that the package works well): - KAME IPv6 stack, http://www.kame.net/ References RFC2553, for getaddrinfo(3) and getnameinfo(3). Author contacts http://www.kame.net/ mailto:core@kame.net ------------------------------------------------------- Date: 2000-Aug-16 06:07 By: moshez Comment: Assigned to Tim, since he's in charge of postponing new features. I'm to timid to postpone it myself. ------------------------------------------------------- Date: 2000-Aug-16 07:00 By: fdrake Comment: Postponed until Python 2.1 -- there's not enough time to review this and get it sufficiently tested on enough IPv6-connected platforms in time for 2.0, and we're already in feature freeze. This should go into the tree very quickly once Python 2.0 has been released. Assigned to myself to open it back up after Python 2.0. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101196&group_id=5470 From noreply@sourceforge.net Sat Dec 30 15:42:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 30 Dec 2000 07:42:44 -0800 Subject: [Patches] [Patch #101482] fix for Bug #114245 Message-ID: Patch #101482 has been updated. Project: python Category: core (C code) Status: Out of date Submitted by: gangli59 Assigned to : mhammond Summary: fix for Bug #114245 Follow-Ups: Date: 2000-Dec-30 07:42 By: loewis Comment: I had to mark this patch as out-of-date: when applying it to the current CVS, it would patch the function in the wrong place. Please resubmit as a context (-c) or unified (-u) diff. After you've updated the patch (preferably addressing Mark's concerns in the process), please let me know so I can reopen it. ------------------------------------------------------- Date: 2000-Sep-16 16:18 By: tim_one Comment: Mark, does this look reasonable to you? The thrust is to make utime work for directories under Win32 (as well as for files). THere's also an entry for this one in PEP 42 (Feature Requests). ------------------------------------------------------- Date: 2000-Sep-16 16:31 By: mhammond Comment: With a quick look and no decent analysis, I can't see a good reason why this wouldnt work. However, see http://support.microsoft.com/support/kb/articles/q167/2/96.asp for the official way of doing this - it is significantly different. I have the above KB code all Python-ready, as it was used in the Windows CE port. I am happy to send this to anyone and everyone, but I am afraid I don't have time to rework the patch. Also note that I would _love_ to see whatever conversion routine you add made public in the DLL (and hence named appropriately). Windows CE could use it, as could the Python Win32 extensions - keep the bloat size down by keeping it in Python, and the cost of making it public isnt too bad! ------------------------------------------------------- Date: 2000-Sep-16 19:40 By: nobody Comment: The time conversion function time2Time is modeled after MS C run time library code. It looks official way of doing this also ;). However UnixTimeToFileTime looks simpler. But I do not know if these two functions do the same thing. ------------------------------------------------------- Date: 2000-Sep-17 18:35 By: tim_one Comment: I changed this to Postponed: the scope is growing, and the bug this is related to was already changed to a Feature Request and added to PEP 42. Let's look at it again after 2.0final. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101482&group_id=5470 From noreply@sourceforge.net Sat Dec 30 16:38:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 30 Dec 2000 08:38:10 -0800 Subject: [Patches] [Patch #103055] IPv6 patch, against 2.0 CVS tree, Dec30-2000 Message-ID: Patch #103055 has been updated. Project: python Category: core (C code) Status: Open Submitted by: itojun Assigned to : nobody Summary: IPv6 patch, against 2.0 CVS tree, Dec30-2000 ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103055&group_id=5470 From noreply@sourceforge.net Sat Dec 30 16:39:32 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 30 Dec 2000 08:39:32 -0800 Subject: [Patches] [Patch #103055] IPv6 patch, against 2.0 CVS tree, Dec30-2000 Message-ID: Patch #103055 has been updated. Project: python Category: core (C code) Status: Open Submitted by: itojun Assigned to : nobody Summary: IPv6 patch, against 2.0 CVS tree, Dec30-2000 Follow-Ups: Date: 2000-Dec-30 08:39 By: itojun Comment: i uploaded gzipped patch, which was failed. i placed the patch into the following location: http://www.itojun.org/diary/20001230/python-2.0-v6-20001230.diff.gz ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103055&group_id=5470 From itojun@iijlab.net Sat Dec 30 16:40:06 2000 From: itojun@iijlab.net (itojun@iijlab.net) Date: Sun, 31 Dec 2000 01:40:06 +0900 Subject: [Patches] Re: [Patch #101196] IPv6 patch against 2.0 CVS tree, as of 20000816 21:52 In-Reply-To: noreply's message of Sat, 30 Dec 2000 07:25:18 PST. Message-ID: <710.978194406@coconut.itojun.org> >Patch #101196 has been updated. >Project: python >Category: core (C code) >Status: Out of date >Submitted by: itojun >Assigned to : fdrake >Summary: IPv6 patch against 2.0 CVS tree, as of 20000816 21:52 > >Follow-Ups: > >Date: 2000-Dec-30 07:25 >By: loewis > >Comment: >I got *many* rejects when trying to apply this patch to today's CVS tree. I >recommend that patches for generated files (config.h.in, configure) are not >included in the patch because they outdate too easily. >A number of changes in this patch have already been done by somebody else; >others just don't fit into the current code anymore (perhaps due to >indentation changes?). >Anyway, I'll mark the patch as out-of-date. Please let me know when you >upload a new version. see patch #103055, which has IPv6 patch against today's 2.0 tree. itojun From noreply@sourceforge.net Sat Dec 30 19:33:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 30 Dec 2000 11:33:57 -0800 Subject: [Patches] [Patch #101170] Prevent old extensions from crashing Message-ID: Patch #101170 has been updated. Project: python Category: Windows Status: Open Submitted by: chega Assigned to : mhammond Summary: Prevent old extensions from crashing Follow-Ups: Date: 2000-Dec-30 11:33 By: chega Comment: Agreed. ------------------------------------------------------- Date: 2000-Dec-30 07:14 By: loewis Comment: I believe this patch is superceded with patch #101676, which is installed as 2.7 of dynload_win.c; so I propose to reject this patch. ------------------------------------------------------- Date: 2000-Aug-12 01:55 By: chega Comment: This patch will prevent old (1.5/1.6) extensions from crashing under Python 2.0 (Also changed pathbuf[260] to pathbuf[MAX_PATH]) ------------------------------------------------------- Date: 2000-Aug-15 15:26 By: tim_one Comment: Assigned to MarkH. Please review or pass on to someone else. ------------------------------------------------------- Date: 2000-Aug-15 16:26 By: mhammond Comment: I'm not sure this is worth adding. Note that we already have code to prevent a crash in place - however, rather than raising an exception it simply calls Py_FatalError. This patch is potentially better, except that: * It will require regressing the patch made to modsupport.c (Rev 2.50) to prevent the same problem; that code will prevent this code kicking in! * It hard-codes the Python DLL names. This makes long term maintenance a PITA, and yet another file that needs to be updated when a version bumps. Are there other alternatives? * Once the module has been loaded, it may be too late to save the process anyway. I realize that the module init hasnt been called yet, but the module has been loaded, and may be doing things in its DllMain() that will destabilize the process. The big killer is simply that this code will never be triggered, as the check in modsupport.c will kick in first. Setting to postponed until we can get a better handle on this. A big advantage is that this style of change is not dependent on _old_ versions having the patch, only one actually running. Hence we can revive this patch at any time, and have it start working immediately. ------------------------------------------------------- Date: 2000-Aug-15 16:49 By: tim_one Comment: I agree with Postponing it. Thanks for the quick response! Feel like reviewing 7 controversial getopt patches now ? ------------------------------------------------------- Date: 2000-Aug-15 17:10 By: chega Comment: * The patch to modsupport.c will NOT save us in the case when someone loads 1.5 extension. See Guido's checkin comment. And I think that Python 1.6 will never be widely spread anyways, so in 99.9% cases it'll be 1.5 vs 2.0. * I agree that the hard-coded dll-names are PITA, but only a small one :-). The version check #if will make sure that this list gets updated. Also, if we keep Guido's patch in modsupport.c the list won't need updating. * I'd rather have an ImportError that PyFatalError() * I find the argument about DllMain() screwing up the process somewhat err... artificial ;-))) I have never seen such a module. Have you? The only thing I am not sure about is whether there is any legitimate reason to have python15 loaded. AFAIR, python COM servers are alwaus out-of-process, aren't they? Can you think of something else? If such reasons do exist, we may want to put another check before loading the module and then bypass the post-check if python15 has been already loaded. ------------------------------------------------------- Date: 2000-Aug-21 05:38 By: mhammond Comment: Another alternative would be to create a Win32 event object, with name "Python-%d" % pid, and have DllMain() attempt to acquire it. This would prevent the "old" Python subsystem starting at all, nipping it right in the bud (and should return a clean ImportError back to the caller!) Does this sound worthwhile? ------------------------------------------------------- Date: 2000-Aug-21 05:43 By: mhammond Comment: Oops - I should have mentioned - Jack Jansen mailed me with the DllMain() idea :-) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101170&group_id=5470 From noreply@sourceforge.net Sun Dec 31 02:11:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 30 Dec 2000 18:11:31 -0800 Subject: [Patches] [Patch #103055] IPv6 patch, against 2.0 CVS tree, Dec30-2000 Message-ID: Patch #103055 has been updated. Project: python Category: Modules Status: Open Submitted by: itojun Assigned to : fdrake Summary: IPv6 patch, against 2.0 CVS tree, Dec30-2000 Follow-Ups: Date: 2000-Dec-30 08:39 By: itojun Comment: i uploaded gzipped patch, which was failed. i placed the patch into the following location: http://www.itojun.org/diary/20001230/python-2.0-v6-20001230.diff.gz ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103055&group_id=5470 From noreply@sourceforge.net Sun Dec 31 04:03:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 30 Dec 2000 20:03:40 -0800 Subject: [Patches] [Patch #102485] minidom.py: Check for legal children Message-ID: Patch #102485 has been updated. Project: python Category: XML Status: Closed Submitted by: akuchling Assigned to : akuchling Summary: minidom.py: Check for legal children Follow-Ups: Date: 2000-Dec-30 20:03 By: akuchling Comment: Checked in. ------------------------------------------------------- Date: 2000-Dec-30 01:06 By: loewis Comment: The patch looks fine now. ------------------------------------------------------- Date: 2000-Dec-20 15:05 By: akuchling Comment: Revised the patch to match the current CVS tree, and to raise HierarchyRequestErr instead of ValueError. ------------------------------------------------------- Date: 2000-Dec-13 20:48 By: fdrake Comment: Now that the exceptions have been added to xml.dom and documented in the development version of the docs, this patch needs to be updated to throw the right exceptions. ------------------------------------------------------- Date: 2000-Nov-23 08:24 By: akuchling Comment: Revised version of patch; the first version was generated against a really old version of minidom.py. ------------------------------------------------------- Date: 2000-Dec-03 03:37 By: loewis Comment: I'd prefer to postpone this patch somewhat, until the official DOM exceptions are available in xml.dom, and then to raise those instead. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102485&group_id=5470 From noreply@sourceforge.net Sun Dec 31 01:26:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 30 Dec 2000 17:26:24 -0800 Subject: [Patches] [Patch #103061] turtle.py has a minor bug. Message-ID: Patch #103061 has been updated. Project: python Category: library Status: Open Submitted by: nobody Assigned to : nobody Summary: turtle.py has a minor bug. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103061&group_id=5470 From noreply@sourceforge.net Sun Dec 31 02:10:20 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 30 Dec 2000 18:10:20 -0800 Subject: [Patches] [Patch #103045] Tim's proposed new text for 'else' in try/except/else Message-ID: Patch #103045 has been updated. Project: python Category: documentation Status: Accepted Submitted by: twouters Assigned to : twouters Summary: Tim's proposed new text for 'else' in try/except/else Follow-Ups: Date: 2000-Dec-30 18:10 By: fdrake Comment: Looks good, please check it in, close any appropriate bugs, and delete related messages from my inbox. ;-) Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103045&group_id=5470 From noreply@sourceforge.net Sun Dec 31 23:35:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 31 Dec 2000 15:35:06 -0800 Subject: [Patches] [Patch #103045] Tim's proposed new text for 'else' in try/except/else Message-ID: Patch #103045 has been updated. Project: python Category: documentation Status: Closed Submitted by: twouters Assigned to : twouters Summary: Tim's proposed new text for 'else' in try/except/else Follow-Ups: Date: 2000-Dec-31 15:35 By: twouters Comment: Checked in, revision 1.21 of Doc/ref/ref7.tex. Bug closed, patch closed, and all possibly relevant emails deleted. It's against my BOFHic Oath to read other people's mail, though, so I was forced to just delete everything. Oh, and Fred, you should really change your password, using your father's maiden name just won't do in these Big Brotherly days! :-) [Oops, forgot to submit before going off to watch the fireworks. This must be the first trans-millenial check-in/patch-close ;-) Happy newyears, everyone!] ------------------------------------------------------- Date: 2000-Dec-30 18:10 By: fdrake Comment: Looks good, please check it in, close any appropriate bugs, and delete related messages from my inbox. ;-) Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103045&group_id=5470