; it shouldn't be used for tags that may be nested. Your example program is invalid. Your patch would cause all data to be saved all the time, even when no tag is interested in saving data. ------------------------------------------------------- Date: 2001-Jan-11 12:15 By: fbremmer Comment: <pre> #! /usr/bin/env python import htmllib, formatter class MyParser(htmllib.HTMLParser): def __init__(self, formatterObject): htmllib.HTMLParser.__init__(self, formatterObject) self.text = '' def start_tag(self, attributes): self.save_bgn() def end_tag(self): self.text = self.save_end() html = """<tag><tag></tag></tag>""" parser=MyParser(formatter.NullFormatter()) parser.nofill = 1 parser.feed(html) parser.close() print parser.text # prints None instead of nothing parser.nofill = 0 parser.feed(html) parser.close() print parser.text # raises exception trying to call None.split() </pre> ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103202&group_id=5470 From noreply@sourceforge.net Thu Jan 11 21:59:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 13:59:42 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: <E14Gpl0-00016l-00@usw-sf-web3.sourceforge.net> Patch #103154 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-11 13:59 By: gvanrossum Comment: Upload it as a new patch. But I believe the solution is that the TERMIOS module should be renamed. ------------------------------------------------------- Date: 2001-Jan-11 07:56 By: jlt63 Comment: Actually, this is not a bug in my original version. Cygwin Python is behaving identically to the Win32 one. Unfortunately, as you pointed out Win32 Python definitely does not handle the situation of two modules that only differ by case. Sigh... If one tries to import the second module that would be found in sys.path, then a NameError: Case mismatch ... exception will *always* be generated. I'm not sure that I agree with this behavior but I really a UNIX guy. Since Cygwin Python should support as many UNIX modules as possible, it needs to deal with modules that only differ by case. termios and TERMIOS used by getpass is a perfect example. I have created a (hacky) patch, that solves this problem for both Cygwin and Win32. I can redo it so that it only affects Cygwin and leaves the Win32 functionality alone. I would like to upload it for discussion but I am concerned about overwriting the old version. Should I upload it anyway? ------------------------------------------------------- Date: 2001-Jan-11 06:47 By: gvanrossum Comment: Reopened at request. Note that I believe that "import termios, TERMIOS" *should fail* -- not all filesystems used on Windows are case preserving. I've had this battle with Mark Hammond before. The case check is intended to prevent you from importing a moduleusing the wrong case (e.g. import String). It is *not* intended to let you have two modules that only differ in case. ------------------------------------------------------- Date: 2001-Jan-10 19:48 By: jlt63 Comment: I have already checked that this patch does not break the Windows VC build before I submitted it. However, Tim is welcome to reverify himself. Unfortunately, I have found a bug with this patch that (only) affects Cygwin. Although this patch handles the following: import String it does not handle the following: import termios, TERMIOS I will resubmit a new version shortly, please change the status back to open. ------------------------------------------------------- Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler <jt@dothill.com> * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Thu Jan 11 22:04:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 14:04:15 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14GppP-00018R-00@usw-sf-web3.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : nobody Summary: PEP 205: weak references implementation ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Thu Jan 11 22:05:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 14:05:53 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14Gpqz-000194-00@usw-sf-web3.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : loewis Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Thu Jan 11 23:27:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 15:27:53 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14Gr8L-0001e1-00@usw-sf-web3.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : loewis Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Fri Jan 12 03:08:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 19:08:08 -0800 Subject: [Patches] [Patch #103028] Make tempfile.mktemp threadsafe Message-ID: <E14GuZU-0007VY-00@usw-sf-web2.sourceforge.net> 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: 2001-Jan-11 19:08 By: tim_one Comment: Assigned back to me, cuz I got my question answered. I'll check in a related patch later tonight. ------------------------------------------------------- Date: 2001-Jan-11 01:08 By: tim_one Comment: Guido, I'm briefly assigning this to you just to get an answer to a question: if threads aren't supported on some platform, do we then get an ImportError upon an attempt to do import thread ? If not, then how to check? if "thread" in sys.builtin_module_names? BTW, Tres's test case has surprising behavior on Windows (he ran it on Linux): it reports no errors, but that's because all of them pop up in the os.unlink, after some other thread has already deleted the (same-named!) temp file used by this thread. Then the thread dies because the exception is unhandled. So there's a large burst of errors when the test starts, but that kills off an equally large number of threads, so the test *appears* <wink> to get better-behaved over time. Note too that while the Summary line complains about mktemp, the Linux failures are really in TemporaryFile: mktemp returns the same name there sometimes, and there's clearly a race between that and os.open() creating a file of that (shared) name (i.e., mktemp's os.path.exists() test is ineffective in such cases, and os.open() goes on to try to create that file multiple times in O_EXCL mode). I can't fix this without strong exclusion (i.e., a lock) -- or a collection of platform-specific OS services for generating guaranteed-unique temp files (e.g., on Windows there's FILE* tmpfile(void); which returns a unique stream opened in binary update mode). The latter is a lot more work than slopping in a lock, though (e.g., Windows tmpfile attempts to create a file in the current working directory, & that's got problems of its own). ------------------------------------------------------- Date: 2001-Jan-02 09:02 By: tseaver Comment: Here is a testcase for the bug: import threading, StringIO from time import sleep from traceback import print_exc startEvent = threading.Event() quitEvent = threading.Event() SLEEP_INTERVAL = 0.2 class TempFileGreedy( threading.Thread ): """ """ error_count = 0 ok_count = 0 def run( self ): """ """ self.errors = StringIO.StringIO() startEvent.wait() while not quitEvent.isSet(): try: f = tempfile.TemporaryFile( "w+b" ) except: self.error_count = self.error_count + 1 print_exc( file=self.errors ) else: f.close() self.ok_count = self.ok_count + 1 sleep( SLEEP_INTERVAL ) if __name__ == '__main__': import sys if len( sys.argv ) > 1: sys.path.insert( 0, '.' ) import tempfile tempfile.gettempdir() # Do this now, to avoid spurious races later NUM_THREADS = 100 threads = [] print "Creating" for i in range( NUM_THREADS ): t = TempFileGreedy() threads.append( t ) t.start() RUN_INTERVAL = 200.0 print "Starting" startEvent.set() sleep( RUN_INTERVAL ) quitEvent.set() print "Reaping" ok = errors = 0 for thread in threads: thread.join() ok = ok + thread.ok_count errors = errors + thread.error_count if thread.error_count: print '%s errors:\n%s' % ( thread.getName() , thread.errors.getvalue() ) print "Done" print 'OK: %d\nErrors: %d' % ( ok, errors ) ------------------------------------------------------- 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 Fri Jan 12 06:03:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 22:03:03 -0800 Subject: [Patches] [Patch #103200] from foo import * respects __all__ Message-ID: <E14GxIl-0002um-00@usw-sf-web3.sourceforge.net> Patch #103200 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nobody Assigned to : gvanrossum Summary: from foo import * respects __all__ Follow-Ups: Date: 2001-Jan-11 22:03 By: moshez Comment: Note: this patch also makes *any* Python object with an __all__ attribute valid for "from foo import *" (this comment is partially a test for whether I can post comments...) ------------------------------------------------------- Date: 2001-Jan-11 13:39 By: gvanrossum Comment: Thanks -- I'll merge this with the partial code I had for this myself. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103200&group_id=5470 From noreply@sourceforge.net Fri Jan 12 09:00:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 01:00:10 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14H04A-000650-00@usw-sf-web1.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : loewis Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Fri Jan 12 09:53:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 01:53:01 -0800 Subject: [Patches] [Patch #103211] webbrowser.py: fix spelling of "Konqueror" Message-ID: <E14H0tJ-0006MD-00@usw-sf-web1.sourceforge.net> Patch #103211 has been updated. Project: python Category: library Status: Open Submitted by: ping Assigned to : nobody Summary: webbrowser.py: fix spelling of "Konqueror" ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103211&group_id=5470 From noreply@sourceforge.net Fri Jan 12 10:08:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 02:08:38 -0800 Subject: [Patches] [Patch #103028] Make tempfile.mktemp threadsafe Message-ID: <E14H18Q-0006SW-00@usw-sf-web1.sourceforge.net> Patch #103028 has been updated. Project: python Category: library Status: Open Submitted by: nobody Assigned to : gvanrossum Summary: Make tempfile.mktemp threadsafe Follow-Ups: Date: 2001-Jan-12 02:08 By: tim_one Comment: I checked in a related patch, tempfile.py rev 1.23. Assigned to Guido hoping to shame him into testing this on Linux (if you don't want to, please assign to someone else -- whoever gives it a clean bill of Linux health should Close this). It's been tested brutally on Windows (my disk is still smoking <wink>). Also needs testing on a platform without threads. With mixed feelings, I did not check in the test case: it takes a long time to run. But a brief test that doesn't create lots of threads and run for a long time is too likely to pass by sheer luck even if the code is broken. ------------------------------------------------------- Date: 2001-Jan-11 19:08 By: tim_one Comment: Assigned back to me, cuz I got my question answered. I'll check in a related patch later tonight. ------------------------------------------------------- Date: 2001-Jan-11 01:08 By: tim_one Comment: Guido, I'm briefly assigning this to you just to get an answer to a question: if threads aren't supported on some platform, do we then get an ImportError upon an attempt to do import thread ? If not, then how to check? if "thread" in sys.builtin_module_names? BTW, Tres's test case has surprising behavior on Windows (he ran it on Linux): it reports no errors, but that's because all of them pop up in the os.unlink, after some other thread has already deleted the (same-named!) temp file used by this thread. Then the thread dies because the exception is unhandled. So there's a large burst of errors when the test starts, but that kills off an equally large number of threads, so the test *appears* <wink> to get better-behaved over time. Note too that while the Summary line complains about mktemp, the Linux failures are really in TemporaryFile: mktemp returns the same name there sometimes, and there's clearly a race between that and os.open() creating a file of that (shared) name (i.e., mktemp's os.path.exists() test is ineffective in such cases, and os.open() goes on to try to create that file multiple times in O_EXCL mode). I can't fix this without strong exclusion (i.e., a lock) -- or a collection of platform-specific OS services for generating guaranteed-unique temp files (e.g., on Windows there's FILE* tmpfile(void); which returns a unique stream opened in binary update mode). The latter is a lot more work than slopping in a lock, though (e.g., Windows tmpfile attempts to create a file in the current working directory, & that's got problems of its own). ------------------------------------------------------- Date: 2001-Jan-02 09:02 By: tseaver Comment: Here is a testcase for the bug: import threading, StringIO from time import sleep from traceback import print_exc startEvent = threading.Event() quitEvent = threading.Event() SLEEP_INTERVAL = 0.2 class TempFileGreedy( threading.Thread ): """ """ error_count = 0 ok_count = 0 def run( self ): """ """ self.errors = StringIO.StringIO() startEvent.wait() while not quitEvent.isSet(): try: f = tempfile.TemporaryFile( "w+b" ) except: self.error_count = self.error_count + 1 print_exc( file=self.errors ) else: f.close() self.ok_count = self.ok_count + 1 sleep( SLEEP_INTERVAL ) if __name__ == '__main__': import sys if len( sys.argv ) > 1: sys.path.insert( 0, '.' ) import tempfile tempfile.gettempdir() # Do this now, to avoid spurious races later NUM_THREADS = 100 threads = [] print "Creating" for i in range( NUM_THREADS ): t = TempFileGreedy() threads.append( t ) t.start() RUN_INTERVAL = 200.0 print "Starting" startEvent.set() sleep( RUN_INTERVAL ) quitEvent.set() print "Reaping" ok = errors = 0 for thread in threads: thread.join() ok = ok + thread.ok_count errors = errors + thread.error_count if thread.error_count: print '%s errors:\n%s' % ( thread.getName() , thread.errors.getvalue() ) print "Done" print 'OK: %d\nErrors: %d' % ( ok, errors ) ------------------------------------------------------- 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 Fri Jan 12 14:23:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 06:23:23 -0800 Subject: [Patches] [Patch #103211] webbrowser.py: fix spelling of "Konqueror" Message-ID: <E14H56x-0002da-00@usw-sf-web2.sourceforge.net> Patch #103211 has been updated. Project: python Category: library Status: Accepted Submitted by: ping Assigned to : ping Summary: webbrowser.py: fix spelling of "Konqueror" Follow-Ups: Date: 2001-Jan-12 06:23 By: gvanrossum Comment: Check it in, Ping! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103211&group_id=5470 From noreply@sourceforge.net Fri Jan 12 14:56:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 06:56:23 -0800 Subject: [Patches] [Patch #103028] Make tempfile.mktemp threadsafe Message-ID: <E14H5ct-0002v6-00@usw-sf-web2.sourceforge.net> Patch #103028 has been updated. Project: python Category: library Status: Closed Submitted by: nobody Assigned to : gvanrossum Summary: Make tempfile.mktemp threadsafe Follow-Ups: Date: 2001-Jan-12 06:56 By: gvanrossum Comment: Works for me on Linux -- both with threads enabled and disabled. Tres's test code gives me no errors. So closing this patch now. ------------------------------------------------------- Date: 2001-Jan-12 02:08 By: tim_one Comment: I checked in a related patch, tempfile.py rev 1.23. Assigned to Guido hoping to shame him into testing this on Linux (if you don't want to, please assign to someone else -- whoever gives it a clean bill of Linux health should Close this). It's been tested brutally on Windows (my disk is still smoking <wink>). Also needs testing on a platform without threads. With mixed feelings, I did not check in the test case: it takes a long time to run. But a brief test that doesn't create lots of threads and run for a long time is too likely to pass by sheer luck even if the code is broken. ------------------------------------------------------- Date: 2001-Jan-11 19:08 By: tim_one Comment: Assigned back to me, cuz I got my question answered. I'll check in a related patch later tonight. ------------------------------------------------------- Date: 2001-Jan-11 01:08 By: tim_one Comment: Guido, I'm briefly assigning this to you just to get an answer to a question: if threads aren't supported on some platform, do we then get an ImportError upon an attempt to do import thread ? If not, then how to check? if "thread" in sys.builtin_module_names? BTW, Tres's test case has surprising behavior on Windows (he ran it on Linux): it reports no errors, but that's because all of them pop up in the os.unlink, after some other thread has already deleted the (same-named!) temp file used by this thread. Then the thread dies because the exception is unhandled. So there's a large burst of errors when the test starts, but that kills off an equally large number of threads, so the test *appears* <wink> to get better-behaved over time. Note too that while the Summary line complains about mktemp, the Linux failures are really in TemporaryFile: mktemp returns the same name there sometimes, and there's clearly a race between that and os.open() creating a file of that (shared) name (i.e., mktemp's os.path.exists() test is ineffective in such cases, and os.open() goes on to try to create that file multiple times in O_EXCL mode). I can't fix this without strong exclusion (i.e., a lock) -- or a collection of platform-specific OS services for generating guaranteed-unique temp files (e.g., on Windows there's FILE* tmpfile(void); which returns a unique stream opened in binary update mode). The latter is a lot more work than slopping in a lock, though (e.g., Windows tmpfile attempts to create a file in the current working directory, & that's got problems of its own). ------------------------------------------------------- Date: 2001-Jan-02 09:02 By: tseaver Comment: Here is a testcase for the bug: import threading, StringIO from time import sleep from traceback import print_exc startEvent = threading.Event() quitEvent = threading.Event() SLEEP_INTERVAL = 0.2 class TempFileGreedy( threading.Thread ): """ """ error_count = 0 ok_count = 0 def run( self ): """ """ self.errors = StringIO.StringIO() startEvent.wait() while not quitEvent.isSet(): try: f = tempfile.TemporaryFile( "w+b" ) except: self.error_count = self.error_count + 1 print_exc( file=self.errors ) else: f.close() self.ok_count = self.ok_count + 1 sleep( SLEEP_INTERVAL ) if __name__ == '__main__': import sys if len( sys.argv ) > 1: sys.path.insert( 0, '.' ) import tempfile tempfile.gettempdir() # Do this now, to avoid spurious races later NUM_THREADS = 100 threads = [] print "Creating" for i in range( NUM_THREADS ): t = TempFileGreedy() threads.append( t ) t.start() RUN_INTERVAL = 200.0 print "Starting" startEvent.set() sleep( RUN_INTERVAL ) quitEvent.set() print "Reaping" ok = errors = 0 for thread in threads: thread.join() ok = ok + thread.ok_count errors = errors + thread.error_count if thread.error_count: print '%s errors:\n%s' % ( thread.getName() , thread.errors.getvalue() ) print "Done" print 'OK: %d\nErrors: %d' % ( ok, errors ) ------------------------------------------------------- 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 Fri Jan 12 14:57:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 06:57:25 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: <E14H5dt-0002vW-00@usw-sf-web2.sourceforge.net> Patch #103154 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-11 13:59 By: gvanrossum Comment: Upload it as a new patch. But I believe the solution is that the TERMIOS module should be renamed. ------------------------------------------------------- Date: 2001-Jan-11 07:56 By: jlt63 Comment: Actually, this is not a bug in my original version. Cygwin Python is behaving identically to the Win32 one. Unfortunately, as you pointed out Win32 Python definitely does not handle the situation of two modules that only differ by case. Sigh... If one tries to import the second module that would be found in sys.path, then a NameError: Case mismatch ... exception will *always* be generated. I'm not sure that I agree with this behavior but I really a UNIX guy. Since Cygwin Python should support as many UNIX modules as possible, it needs to deal with modules that only differ by case. termios and TERMIOS used by getpass is a perfect example. I have created a (hacky) patch, that solves this problem for both Cygwin and Win32. I can redo it so that it only affects Cygwin and leaves the Win32 functionality alone. I would like to upload it for discussion but I am concerned about overwriting the old version. Should I upload it anyway? ------------------------------------------------------- Date: 2001-Jan-11 06:47 By: gvanrossum Comment: Reopened at request. Note that I believe that "import termios, TERMIOS" *should fail* -- not all filesystems used on Windows are case preserving. I've had this battle with Mark Hammond before. The case check is intended to prevent you from importing a moduleusing the wrong case (e.g. import String). It is *not* intended to let you have two modules that only differ in case. ------------------------------------------------------- Date: 2001-Jan-10 19:48 By: jlt63 Comment: I have already checked that this patch does not break the Windows VC build before I submitted it. However, Tim is welcome to reverify himself. Unfortunately, I have found a bug with this patch that (only) affects Cygwin. Although this patch handles the following: import String it does not handle the following: import termios, TERMIOS I will resubmit a new version shortly, please change the status back to open. ------------------------------------------------------- Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler <jt@dothill.com> * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Fri Jan 12 16:06:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 08:06:17 -0800 Subject: [Patches] [Patch #102681] issubclass() and isinstance() error messages Message-ID: <E14H6iX-0008Ur-00@usw-sf-web1.sourceforge.net> Patch #102681 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: ping Assigned to : gvanrossum Summary: issubclass() and isinstance() error messages Follow-Ups: Date: 2001-Jan-12 08:06 By: gvanrossum Comment: I've checked in a slightly modified version of this. I fixed the errors in abstract_issubclass() to say that arg 1 or arg 2 must be a class, not mentioning the possibility that it could be a type -- in fact, a type isn't allowed (unless it has __bases__). I also changed builtin_isinstance() so that it doesn't override the error from abstract_issubclass() unless it' a TypeError (theoretically it could raise a MemoryError too). ------------------------------------------------------- Date: 2001-Jan-04 18:41 By: gvanrossum Comment: Ping, please answer my question! ------------------------------------------------------- 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 Fri Jan 12 16:24:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 08:24:57 -0800 Subject: [Patches] [Patch #103200] from foo import * respects __all__ Message-ID: <E14H70b-0003Se-00@usw-sf-web2.sourceforge.net> Patch #103200 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: nobody Assigned to : gvanrossum Summary: from foo import * respects __all__ Follow-Ups: Date: 2001-Jan-12 08:24 By: gvanrossum Comment: I've checked in something similar. (Note that your code leaks the value of __all__;-) ------------------------------------------------------- Date: 2001-Jan-11 22:03 By: moshez Comment: Note: this patch also makes *any* Python object with an __all__ attribute valid for "from foo import *" (this comment is partially a test for whether I can post comments...) ------------------------------------------------------- Date: 2001-Jan-11 13:39 By: gvanrossum Comment: Thanks -- I'll merge this with the partial code I had for this myself. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103200&group_id=5470 From noreply@sourceforge.net Fri Jan 12 16:28:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 08:28:17 -0800 Subject: [Patches] [Patch #103185] Some more standard modules cleanup for Cygwin Message-ID: <E14H73p-0003UK-00@usw-sf-web2.sourceforge.net> Patch #103185 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jlt63 Assigned to : gvanrossum Summary: Some more standard modules cleanup for Cygwin Follow-Ups: Date: 2001-Jan-10 21:19 By: jlt63 Comment: Use the following procedure to patch: $ cd Modules $ # save modules.patch to current directory $ patch <modules.patch ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103185&group_id=5470 From noreply@sourceforge.net Fri Jan 12 16:28:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 08:28:24 -0800 Subject: [Patches] [Patch #103188] BeOS/ar-fake support for extra libraries Message-ID: <E14H73w-0003US-00@usw-sf-web2.sourceforge.net> Patch #103188 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : gvanrossum Summary: BeOS/ar-fake support for extra libraries ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103188&group_id=5470 From noreply@sourceforge.net Fri Jan 12 17:44:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 09:44:51 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: <E14H8Fv-0003wZ-00@usw-sf-web2.sourceforge.net> Patch #103154 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-12 09:44 By: jlt63 Comment: I just uploaded a new patch. It fixes the case sensitive import problem for Cygwin without affecting Win32 (i.e., Win32 functions as before). Now Cygwin's import behavior is identical to other UNIX platforms. I'm not completely happy with the patch and would characterize it as hacky, but it is the best that I can do without fully grokking import.c. I think to do better would require major rework to find_module(). I guess by renaming TERMIOS you mean to change the module names generated by h2py.py. I have no issue with this -- will others? I thought all filesystems on Windows 95/NT 3.51 and later, were case preserving. To what filesystems and Windows versions are you referring? ------------------------------------------------------- Date: 2001-Jan-11 13:59 By: gvanrossum Comment: Upload it as a new patch. But I believe the solution is that the TERMIOS module should be renamed. ------------------------------------------------------- Date: 2001-Jan-11 07:56 By: jlt63 Comment: Actually, this is not a bug in my original version. Cygwin Python is behaving identically to the Win32 one. Unfortunately, as you pointed out Win32 Python definitely does not handle the situation of two modules that only differ by case. Sigh... If one tries to import the second module that would be found in sys.path, then a NameError: Case mismatch ... exception will *always* be generated. I'm not sure that I agree with this behavior but I really a UNIX guy. Since Cygwin Python should support as many UNIX modules as possible, it needs to deal with modules that only differ by case. termios and TERMIOS used by getpass is a perfect example. I have created a (hacky) patch, that solves this problem for both Cygwin and Win32. I can redo it so that it only affects Cygwin and leaves the Win32 functionality alone. I would like to upload it for discussion but I am concerned about overwriting the old version. Should I upload it anyway? ------------------------------------------------------- Date: 2001-Jan-11 06:47 By: gvanrossum Comment: Reopened at request. Note that I believe that "import termios, TERMIOS" *should fail* -- not all filesystems used on Windows are case preserving. I've had this battle with Mark Hammond before. The case check is intended to prevent you from importing a moduleusing the wrong case (e.g. import String). It is *not* intended to let you have two modules that only differ in case. ------------------------------------------------------- Date: 2001-Jan-10 19:48 By: jlt63 Comment: I have already checked that this patch does not break the Windows VC build before I submitted it. However, Tim is welcome to reverify himself. Unfortunately, I have found a bug with this patch that (only) affects Cygwin. Although this patch handles the following: import String it does not handle the following: import termios, TERMIOS I will resubmit a new version shortly, please change the status back to open. ------------------------------------------------------- Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler <jt@dothill.com> * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Fri Jan 12 17:50:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 09:50:05 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: <E14H8Kz-0003zQ-00@usw-sf-web2.sourceforge.net> Patch #103154 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-12 09:50 By: jlt63 Comment: Oops... Use the following procedure to patch: $ cd Python $ # save case.patch to current directory $ patch <case.patch ------------------------------------------------------- Date: 2001-Jan-12 09:44 By: jlt63 Comment: I just uploaded a new patch. It fixes the case sensitive import problem for Cygwin without affecting Win32 (i.e., Win32 functions as before). Now Cygwin's import behavior is identical to other UNIX platforms. I'm not completely happy with the patch and would characterize it as hacky, but it is the best that I can do without fully grokking import.c. I think to do better would require major rework to find_module(). I guess by renaming TERMIOS you mean to change the module names generated by h2py.py. I have no issue with this -- will others? I thought all filesystems on Windows 95/NT 3.51 and later, were case preserving. To what filesystems and Windows versions are you referring? ------------------------------------------------------- Date: 2001-Jan-11 13:59 By: gvanrossum Comment: Upload it as a new patch. But I believe the solution is that the TERMIOS module should be renamed. ------------------------------------------------------- Date: 2001-Jan-11 07:56 By: jlt63 Comment: Actually, this is not a bug in my original version. Cygwin Python is behaving identically to the Win32 one. Unfortunately, as you pointed out Win32 Python definitely does not handle the situation of two modules that only differ by case. Sigh... If one tries to import the second module that would be found in sys.path, then a NameError: Case mismatch ... exception will *always* be generated. I'm not sure that I agree with this behavior but I really a UNIX guy. Since Cygwin Python should support as many UNIX modules as possible, it needs to deal with modules that only differ by case. termios and TERMIOS used by getpass is a perfect example. I have created a (hacky) patch, that solves this problem for both Cygwin and Win32. I can redo it so that it only affects Cygwin and leaves the Win32 functionality alone. I would like to upload it for discussion but I am concerned about overwriting the old version. Should I upload it anyway? ------------------------------------------------------- Date: 2001-Jan-11 06:47 By: gvanrossum Comment: Reopened at request. Note that I believe that "import termios, TERMIOS" *should fail* -- not all filesystems used on Windows are case preserving. I've had this battle with Mark Hammond before. The case check is intended to prevent you from importing a moduleusing the wrong case (e.g. import String). It is *not* intended to let you have two modules that only differ in case. ------------------------------------------------------- Date: 2001-Jan-10 19:48 By: jlt63 Comment: I have already checked that this patch does not break the Windows VC build before I submitted it. However, Tim is welcome to reverify himself. Unfortunately, I have found a bug with this patch that (only) affects Cygwin. Although this patch handles the following: import String it does not handle the following: import termios, TERMIOS I will resubmit a new version shortly, please change the status back to open. ------------------------------------------------------- Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler <jt@dothill.com> * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Fri Jan 12 17:59:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 09:59:01 -0800 Subject: [Patches] [Patch #103216] Auto-detect dbmmodule and build dynamically Message-ID: <E14H8Td-00043Z-00@usw-sf-web2.sourceforge.net> Patch #103216 has been updated. Project: python Category: Build Status: Open Submitted by: bwarsaw Assigned to : nobody Summary: Auto-detect dbmmodule and build dynamically ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103216&group_id=5470 From noreply@sourceforge.net Fri Jan 12 18:00:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 10:00:46 -0800 Subject: [Patches] [Patch #103216] Auto-detect dbmmodule and build dynamically Message-ID: <E14H8VK-00044v-00@usw-sf-web2.sourceforge.net> Patch #103216 has been updated. Project: python Category: Build Status: Open Submitted by: bwarsaw Assigned to : gvanrossum Summary: Auto-detect dbmmodule and build dynamically Follow-Ups: Date: 2001-Jan-12 10:00 By: bwarsaw Comment: Note, I had to rip out the diff to configure because SF complained about the size of the patch. :( Since that can be generated from configure.in, I'm not worrying about it. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103216&group_id=5470 From noreply@sourceforge.net Fri Jan 12 18:26:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 10:26:40 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: <E14H8uO-0004FF-00@usw-sf-web2.sourceforge.net> Patch #103154 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-12 10:26 By: tim_one Comment: The filesystems do preserve the case of names. But all platform file *lookup* APIs are case-insensitive. ------------------------------------------------------- Date: 2001-Jan-12 09:50 By: jlt63 Comment: Oops... Use the following procedure to patch: $ cd Python $ # save case.patch to current directory $ patch <case.patch ------------------------------------------------------- Date: 2001-Jan-12 09:44 By: jlt63 Comment: I just uploaded a new patch. It fixes the case sensitive import problem for Cygwin without affecting Win32 (i.e., Win32 functions as before). Now Cygwin's import behavior is identical to other UNIX platforms. I'm not completely happy with the patch and would characterize it as hacky, but it is the best that I can do without fully grokking import.c. I think to do better would require major rework to find_module(). I guess by renaming TERMIOS you mean to change the module names generated by h2py.py. I have no issue with this -- will others? I thought all filesystems on Windows 95/NT 3.51 and later, were case preserving. To what filesystems and Windows versions are you referring? ------------------------------------------------------- Date: 2001-Jan-11 13:59 By: gvanrossum Comment: Upload it as a new patch. But I believe the solution is that the TERMIOS module should be renamed. ------------------------------------------------------- Date: 2001-Jan-11 07:56 By: jlt63 Comment: Actually, this is not a bug in my original version. Cygwin Python is behaving identically to the Win32 one. Unfortunately, as you pointed out Win32 Python definitely does not handle the situation of two modules that only differ by case. Sigh... If one tries to import the second module that would be found in sys.path, then a NameError: Case mismatch ... exception will *always* be generated. I'm not sure that I agree with this behavior but I really a UNIX guy. Since Cygwin Python should support as many UNIX modules as possible, it needs to deal with modules that only differ by case. termios and TERMIOS used by getpass is a perfect example. I have created a (hacky) patch, that solves this problem for both Cygwin and Win32. I can redo it so that it only affects Cygwin and leaves the Win32 functionality alone. I would like to upload it for discussion but I am concerned about overwriting the old version. Should I upload it anyway? ------------------------------------------------------- Date: 2001-Jan-11 06:47 By: gvanrossum Comment: Reopened at request. Note that I believe that "import termios, TERMIOS" *should fail* -- not all filesystems used on Windows are case preserving. I've had this battle with Mark Hammond before. The case check is intended to prevent you from importing a moduleusing the wrong case (e.g. import String). It is *not* intended to let you have two modules that only differ in case. ------------------------------------------------------- Date: 2001-Jan-10 19:48 By: jlt63 Comment: I have already checked that this patch does not break the Windows VC build before I submitted it. However, Tim is welcome to reverify himself. Unfortunately, I have found a bug with this patch that (only) affects Cygwin. Although this patch handles the following: import String it does not handle the following: import termios, TERMIOS I will resubmit a new version shortly, please change the status back to open. ------------------------------------------------------- Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler <jt@dothill.com> * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Fri Jan 12 18:32:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 10:32:25 -0800 Subject: [Patches] [Patch #103217] prevent htmllib from calling None.split() Message-ID: <E14H8zx-0004Hl-00@usw-sf-web2.sourceforge.net> Patch #103217 has been updated. Project: python Category: library Status: Open Submitted by: fbremmer Assigned to : nobody Summary: prevent htmllib from calling None.split() ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103217&group_id=5470 From noreply@sourceforge.net Fri Jan 12 18:47:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 10:47:08 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: <E14H9EC-0004Mr-00@usw-sf-web2.sourceforge.net> Patch #103154 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-12 10:47 By: jlt63 Comment: I know. I was just confused by the following On 2001-Jan-11 06:47, gvanrossum wrote: > Note that I believe that "import termios, TERMIOS" *should fail* -- not all > filesystems used on Windows are case preserving. ------------------------------------------------------- Date: 2001-Jan-12 10:26 By: tim_one Comment: The filesystems do preserve the case of names. But all platform file *lookup* APIs are case-insensitive. ------------------------------------------------------- Date: 2001-Jan-12 09:50 By: jlt63 Comment: Oops... Use the following procedure to patch: $ cd Python $ # save case.patch to current directory $ patch <case.patch ------------------------------------------------------- Date: 2001-Jan-12 09:44 By: jlt63 Comment: I just uploaded a new patch. It fixes the case sensitive import problem for Cygwin without affecting Win32 (i.e., Win32 functions as before). Now Cygwin's import behavior is identical to other UNIX platforms. I'm not completely happy with the patch and would characterize it as hacky, but it is the best that I can do without fully grokking import.c. I think to do better would require major rework to find_module(). I guess by renaming TERMIOS you mean to change the module names generated by h2py.py. I have no issue with this -- will others? I thought all filesystems on Windows 95/NT 3.51 and later, were case preserving. To what filesystems and Windows versions are you referring? ------------------------------------------------------- Date: 2001-Jan-11 13:59 By: gvanrossum Comment: Upload it as a new patch. But I believe the solution is that the TERMIOS module should be renamed. ------------------------------------------------------- Date: 2001-Jan-11 07:56 By: jlt63 Comment: Actually, this is not a bug in my original version. Cygwin Python is behaving identically to the Win32 one. Unfortunately, as you pointed out Win32 Python definitely does not handle the situation of two modules that only differ by case. Sigh... If one tries to import the second module that would be found in sys.path, then a NameError: Case mismatch ... exception will *always* be generated. I'm not sure that I agree with this behavior but I really a UNIX guy. Since Cygwin Python should support as many UNIX modules as possible, it needs to deal with modules that only differ by case. termios and TERMIOS used by getpass is a perfect example. I have created a (hacky) patch, that solves this problem for both Cygwin and Win32. I can redo it so that it only affects Cygwin and leaves the Win32 functionality alone. I would like to upload it for discussion but I am concerned about overwriting the old version. Should I upload it anyway? ------------------------------------------------------- Date: 2001-Jan-11 06:47 By: gvanrossum Comment: Reopened at request. Note that I believe that "import termios, TERMIOS" *should fail* -- not all filesystems used on Windows are case preserving. I've had this battle with Mark Hammond before. The case check is intended to prevent you from importing a moduleusing the wrong case (e.g. import String). It is *not* intended to let you have two modules that only differ in case. ------------------------------------------------------- Date: 2001-Jan-10 19:48 By: jlt63 Comment: I have already checked that this patch does not break the Windows VC build before I submitted it. However, Tim is welcome to reverify himself. Unfortunately, I have found a bug with this patch that (only) affects Cygwin. Although this patch handles the following: import String it does not handle the following: import termios, TERMIOS I will resubmit a new version shortly, please change the status back to open. ------------------------------------------------------- Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler <jt@dothill.com> * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Fri Jan 12 18:52:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 10:52:28 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: <E14H9JM-0007Uj-00@usw-sf-web3.sourceforge.net> Patch #103154 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-12 10:52 By: gvanrossum Comment: Maybe things are different now. But I definitely remember that when I introduced this test, Mark Hammond told me that there was a popular networking filesystem that didn't preserve case. This was either for Windows NT or Windows 95, so it's not a Windows 3.1 thing (although it's possible that the fileserver in question was a bad port from DOS or Windows 3.1 of course). ------------------------------------------------------- Date: 2001-Jan-12 10:47 By: jlt63 Comment: I know. I was just confused by the following On 2001-Jan-11 06:47, gvanrossum wrote: > Note that I believe that "import termios, TERMIOS" *should fail* -- not all > filesystems used on Windows are case preserving. ------------------------------------------------------- Date: 2001-Jan-12 10:26 By: tim_one Comment: The filesystems do preserve the case of names. But all platform file *lookup* APIs are case-insensitive. ------------------------------------------------------- Date: 2001-Jan-12 09:50 By: jlt63 Comment: Oops... Use the following procedure to patch: $ cd Python $ # save case.patch to current directory $ patch <case.patch ------------------------------------------------------- Date: 2001-Jan-12 09:44 By: jlt63 Comment: I just uploaded a new patch. It fixes the case sensitive import problem for Cygwin without affecting Win32 (i.e., Win32 functions as before). Now Cygwin's import behavior is identical to other UNIX platforms. I'm not completely happy with the patch and would characterize it as hacky, but it is the best that I can do without fully grokking import.c. I think to do better would require major rework to find_module(). I guess by renaming TERMIOS you mean to change the module names generated by h2py.py. I have no issue with this -- will others? I thought all filesystems on Windows 95/NT 3.51 and later, were case preserving. To what filesystems and Windows versions are you referring? ------------------------------------------------------- Date: 2001-Jan-11 13:59 By: gvanrossum Comment: Upload it as a new patch. But I believe the solution is that the TERMIOS module should be renamed. ------------------------------------------------------- Date: 2001-Jan-11 07:56 By: jlt63 Comment: Actually, this is not a bug in my original version. Cygwin Python is behaving identically to the Win32 one. Unfortunately, as you pointed out Win32 Python definitely does not handle the situation of two modules that only differ by case. Sigh... If one tries to import the second module that would be found in sys.path, then a NameError: Case mismatch ... exception will *always* be generated. I'm not sure that I agree with this behavior but I really a UNIX guy. Since Cygwin Python should support as many UNIX modules as possible, it needs to deal with modules that only differ by case. termios and TERMIOS used by getpass is a perfect example. I have created a (hacky) patch, that solves this problem for both Cygwin and Win32. I can redo it so that it only affects Cygwin and leaves the Win32 functionality alone. I would like to upload it for discussion but I am concerned about overwriting the old version. Should I upload it anyway? ------------------------------------------------------- Date: 2001-Jan-11 06:47 By: gvanrossum Comment: Reopened at request. Note that I believe that "import termios, TERMIOS" *should fail* -- not all filesystems used on Windows are case preserving. I've had this battle with Mark Hammond before. The case check is intended to prevent you from importing a moduleusing the wrong case (e.g. import String). It is *not* intended to let you have two modules that only differ in case. ------------------------------------------------------- Date: 2001-Jan-10 19:48 By: jlt63 Comment: I have already checked that this patch does not break the Windows VC build before I submitted it. However, Tim is welcome to reverify himself. Unfortunately, I have found a bug with this patch that (only) affects Cygwin. Although this patch handles the following: import String it does not handle the following: import termios, TERMIOS I will resubmit a new version shortly, please change the status back to open. ------------------------------------------------------- Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler <jt@dothill.com> * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Fri Jan 12 19:27:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 11:27:59 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14H9rj-0001NE-00@usw-sf-web1.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : loewis Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-12 11:27 By: fdrake Comment: Updated patch to also support proxy semantics using the same invalidation machinery as the basic weak reference type. The additional code is *heavily* borrowed from Neil Schemenauer. ------------------------------------------------------- Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Fri Jan 12 19:48:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 11:48:40 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: <E14HABk-0007sf-00@usw-sf-web3.sourceforge.net> Patch #103154 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-12 11:48 By: tim_one Comment: Ah, I see. There's a difference between Windows filesystems and filesystems used on Windows <wink/sigh>. Older Novell network fileservers for Windows do indeed destroy the case of file names, and newer ones are often configured in a compatability mode to keep on doing that. At my last employer, more than half the LAN servers were set up that way. Use of PYTHONCASEOK was universal as a result. We were also screwed in that one of the popular Windows source-control systems *also* destroyed case (I didn't use that, and have forgotten the name): check in OhNo.py, check out OHNO.PY. Brrrrrrrrr. ------------------------------------------------------- Date: 2001-Jan-12 10:52 By: gvanrossum Comment: Maybe things are different now. But I definitely remember that when I introduced this test, Mark Hammond told me that there was a popular networking filesystem that didn't preserve case. This was either for Windows NT or Windows 95, so it's not a Windows 3.1 thing (although it's possible that the fileserver in question was a bad port from DOS or Windows 3.1 of course). ------------------------------------------------------- Date: 2001-Jan-12 10:47 By: jlt63 Comment: I know. I was just confused by the following On 2001-Jan-11 06:47, gvanrossum wrote: > Note that I believe that "import termios, TERMIOS" *should fail* -- not all > filesystems used on Windows are case preserving. ------------------------------------------------------- Date: 2001-Jan-12 10:26 By: tim_one Comment: The filesystems do preserve the case of names. But all platform file *lookup* APIs are case-insensitive. ------------------------------------------------------- Date: 2001-Jan-12 09:50 By: jlt63 Comment: Oops... Use the following procedure to patch: $ cd Python $ # save case.patch to current directory $ patch <case.patch ------------------------------------------------------- Date: 2001-Jan-12 09:44 By: jlt63 Comment: I just uploaded a new patch. It fixes the case sensitive import problem for Cygwin without affecting Win32 (i.e., Win32 functions as before). Now Cygwin's import behavior is identical to other UNIX platforms. I'm not completely happy with the patch and would characterize it as hacky, but it is the best that I can do without fully grokking import.c. I think to do better would require major rework to find_module(). I guess by renaming TERMIOS you mean to change the module names generated by h2py.py. I have no issue with this -- will others? I thought all filesystems on Windows 95/NT 3.51 and later, were case preserving. To what filesystems and Windows versions are you referring? ------------------------------------------------------- Date: 2001-Jan-11 13:59 By: gvanrossum Comment: Upload it as a new patch. But I believe the solution is that the TERMIOS module should be renamed. ------------------------------------------------------- Date: 2001-Jan-11 07:56 By: jlt63 Comment: Actually, this is not a bug in my original version. Cygwin Python is behaving identically to the Win32 one. Unfortunately, as you pointed out Win32 Python definitely does not handle the situation of two modules that only differ by case. Sigh... If one tries to import the second module that would be found in sys.path, then a NameError: Case mismatch ... exception will *always* be generated. I'm not sure that I agree with this behavior but I really a UNIX guy. Since Cygwin Python should support as many UNIX modules as possible, it needs to deal with modules that only differ by case. termios and TERMIOS used by getpass is a perfect example. I have created a (hacky) patch, that solves this problem for both Cygwin and Win32. I can redo it so that it only affects Cygwin and leaves the Win32 functionality alone. I would like to upload it for discussion but I am concerned about overwriting the old version. Should I upload it anyway? ------------------------------------------------------- Date: 2001-Jan-11 06:47 By: gvanrossum Comment: Reopened at request. Note that I believe that "import termios, TERMIOS" *should fail* -- not all filesystems used on Windows are case preserving. I've had this battle with Mark Hammond before. The case check is intended to prevent you from importing a moduleusing the wrong case (e.g. import String). It is *not* intended to let you have two modules that only differ in case. ------------------------------------------------------- Date: 2001-Jan-10 19:48 By: jlt63 Comment: I have already checked that this patch does not break the Windows VC build before I submitted it. However, Tim is welcome to reverify himself. Unfortunately, I have found a bug with this patch that (only) affects Cygwin. Although this patch handles the following: import String it does not handle the following: import termios, TERMIOS I will resubmit a new version shortly, please change the status back to open. ------------------------------------------------------- Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler <jt@dothill.com> * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Fri Jan 12 20:11:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 12:11:23 -0800 Subject: [Patches] [Patch #103158] Don't do unsafe arithmetic in xrange object Message-ID: <E14HAXj-00081C-00@usw-sf-web3.sourceforge.net> Patch #103158 has been updated. Project: python Category: core (C code) Status: Open Submitted by: greg_ball Assigned to : gvanrossum Summary: Don't do unsafe arithmetic in xrange object Follow-Ups: Date: 2001-Jan-12 12:11 By: greg_ball Comment: The new version of the patch makes the code a bit less complicated. (Only error messages have changed in terms of behaviour; regression test run under linux and OSF1.) If it looks ok you can ignore the rest of this comment... I originally made totlen an int because it is the return value from range_length, and the argument to PyList_New(). The current patch makes totlen a long, but the ocde doesn't get hugely less complicated. The code would get simpler if it rejected objects whose length doesn't fit into a int, but that seemed too easy and there is a small chance someone's code might break. On the other hand by rejecting objects whose stop can't be correctly calculated, I _might_ have broken code already. Break just means "now raises exception" though, nothing insidious. ------------------------------------------------------- Date: 2001-Jan-10 10:28 By: gvanrossum Comment: I wonder why you made totlen an int. This seems to complicate the code quite a bit. I'd suggest making it a long. Then you have to test whether it's > INT_MAX only in tolist() -- in that case you should raise MemoryError. Other than that, it looks decent! ------------------------------------------------------- Date: 2001-Jan-09 06:31 By: greg_ball Comment: This is a replacement for patch 103129, as suggested by tim_one. Possibly interesting aspects of the patch: - xrange objects with overflowing lengths are not gratutiously rejected. An error is raised only if the length becomes relevant, under len() or negative indexing. Bad lengths are stored as -1. Objects with bad lengths allow any non-negative integer index. - On 64 bit platforms, sequence multiplication seems to cause an unsafe cast from long to int. This patch does not address that issue. Without my patch, on i686 Linux: Python 2.0 (#25, Jan 2 2001, 12:18:07) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> y = xrange(maxint/2)*3 >>> len(y) -1073741827 >>> y[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> y.tolist() Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: listobject.c:33: bad argument to internal function >>> m = maxint >> 16 >>> xrange(0,maxint,m) xrange(0, -2147450883, 32767) >>> (xrange(1)*maxint)*maxint xrange(1) >>> With my patch Python 2.0 (#35, Jan 6 2001, 12:54:41) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> y = xrange(maxint/2)*3 >>> len(y) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> y.tolist() Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> m = maxint >> 16 >>> xrange(0,maxint,m) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer addition >>> (xrange(1)*maxint) * maxint Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer multiplication >>> Without patch on Digital Unix Python 2.0 (#5, Jan 6 2001, 15:42:58) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> xrange(0,maxint,m) xrange(0, -9223372034707292163, 2147483647) >>> xrange(1)*maxint xrange(0) >>> With patch Python 2.0 (#7, Jan 6 2001, 15:52:21) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> xrange(0,maxint,m) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer addition >>> xrange(1)*maxint xrange(0) >>> ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103158&group_id=5470 From noreply@sourceforge.net Fri Jan 12 20:35:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 12:35:45 -0800 Subject: [Patches] [Patch #103158] Don't do unsafe arithmetic in xrange object Message-ID: <E14HAvJ-0008A9-00@usw-sf-web3.sourceforge.net> Patch #103158 has been updated. Project: python Category: core (C code) Status: Open Submitted by: greg_ball Assigned to : gvanrossum Summary: Don't do unsafe arithmetic in xrange object Follow-Ups: Date: 2001-Jan-12 12:35 By: tim_one Comment: Please do reject objects whose length doesn't fit into an int. I'll bet a dollar that no real code in the world will break as a result. I feel confident making that bet, because if someone's code *does* break as a result, it's worth a dollar to me to see Guido lecture them that their code was already broken <wink>. Really, it's very Pythonic to gripe about a problem just as soon as it crops up. It's not doing anyone a favor to delay griping until the object is used: at that point, it may be very difficult to figure out how the object *got* damaged. There's simply no payback in allowing creation of an unusable xrange object, and, as you say, life is simpler if you don't allow it. ------------------------------------------------------- Date: 2001-Jan-12 12:11 By: greg_ball Comment: The new version of the patch makes the code a bit less complicated. (Only error messages have changed in terms of behaviour; regression test run under linux and OSF1.) If it looks ok you can ignore the rest of this comment... I originally made totlen an int because it is the return value from range_length, and the argument to PyList_New(). The current patch makes totlen a long, but the ocde doesn't get hugely less complicated. The code would get simpler if it rejected objects whose length doesn't fit into a int, but that seemed too easy and there is a small chance someone's code might break. On the other hand by rejecting objects whose stop can't be correctly calculated, I _might_ have broken code already. Break just means "now raises exception" though, nothing insidious. ------------------------------------------------------- Date: 2001-Jan-10 10:28 By: gvanrossum Comment: I wonder why you made totlen an int. This seems to complicate the code quite a bit. I'd suggest making it a long. Then you have to test whether it's > INT_MAX only in tolist() -- in that case you should raise MemoryError. Other than that, it looks decent! ------------------------------------------------------- Date: 2001-Jan-09 06:31 By: greg_ball Comment: This is a replacement for patch 103129, as suggested by tim_one. Possibly interesting aspects of the patch: - xrange objects with overflowing lengths are not gratutiously rejected. An error is raised only if the length becomes relevant, under len() or negative indexing. Bad lengths are stored as -1. Objects with bad lengths allow any non-negative integer index. - On 64 bit platforms, sequence multiplication seems to cause an unsafe cast from long to int. This patch does not address that issue. Without my patch, on i686 Linux: Python 2.0 (#25, Jan 2 2001, 12:18:07) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> y = xrange(maxint/2)*3 >>> len(y) -1073741827 >>> y[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> y.tolist() Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: listobject.c:33: bad argument to internal function >>> m = maxint >> 16 >>> xrange(0,maxint,m) xrange(0, -2147450883, 32767) >>> (xrange(1)*maxint)*maxint xrange(1) >>> With my patch Python 2.0 (#35, Jan 6 2001, 12:54:41) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> y = xrange(maxint/2)*3 >>> len(y) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> y.tolist() Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> m = maxint >> 16 >>> xrange(0,maxint,m) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer addition >>> (xrange(1)*maxint) * maxint Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer multiplication >>> Without patch on Digital Unix Python 2.0 (#5, Jan 6 2001, 15:42:58) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> xrange(0,maxint,m) xrange(0, -9223372034707292163, 2147483647) >>> xrange(1)*maxint xrange(0) >>> With patch Python 2.0 (#7, Jan 6 2001, 15:52:21) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> xrange(0,maxint,m) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer addition >>> xrange(1)*maxint xrange(0) >>> ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103158&group_id=5470 From noreply@sourceforge.net Fri Jan 12 20:44:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 12:44:58 -0800 Subject: [Patches] [Patch #103158] Don't do unsafe arithmetic in xrange object Message-ID: <E14HB4E-0008Dv-00@usw-sf-web3.sourceforge.net> Patch #103158 has been updated. Project: python Category: core (C code) Status: Open Submitted by: greg_ball Assigned to : gvanrossum Summary: Don't do unsafe arithmetic in xrange object Follow-Ups: Date: 2001-Jan-12 12:44 By: gvanrossum Comment: In theory, there's a use for objects whose length doesn't fit in an int: for i in xrange(...) is routinely used for loops that expect to break well before the end but don't want to give an arbitrary upper bound. But I agree with Tim that this serves no real purpose. I think that if anything, the xrange() object should be scaled down. No repetition, no concationation, no slicing. the only real use ought to be "for i in xrange(...)". But of course, *that* is bound to break somebody's code somewhere. So let's not go there. But let's not complicate it any further. Prevent breakage, but don't stretch the functionality beyond what it currently does. ------------------------------------------------------- Date: 2001-Jan-12 12:35 By: tim_one Comment: Please do reject objects whose length doesn't fit into an int. I'll bet a dollar that no real code in the world will break as a result. I feel confident making that bet, because if someone's code *does* break as a result, it's worth a dollar to me to see Guido lecture them that their code was already broken <wink>. Really, it's very Pythonic to gripe about a problem just as soon as it crops up. It's not doing anyone a favor to delay griping until the object is used: at that point, it may be very difficult to figure out how the object *got* damaged. There's simply no payback in allowing creation of an unusable xrange object, and, as you say, life is simpler if you don't allow it. ------------------------------------------------------- Date: 2001-Jan-12 12:11 By: greg_ball Comment: The new version of the patch makes the code a bit less complicated. (Only error messages have changed in terms of behaviour; regression test run under linux and OSF1.) If it looks ok you can ignore the rest of this comment... I originally made totlen an int because it is the return value from range_length, and the argument to PyList_New(). The current patch makes totlen a long, but the ocde doesn't get hugely less complicated. The code would get simpler if it rejected objects whose length doesn't fit into a int, but that seemed too easy and there is a small chance someone's code might break. On the other hand by rejecting objects whose stop can't be correctly calculated, I _might_ have broken code already. Break just means "now raises exception" though, nothing insidious. ------------------------------------------------------- Date: 2001-Jan-10 10:28 By: gvanrossum Comment: I wonder why you made totlen an int. This seems to complicate the code quite a bit. I'd suggest making it a long. Then you have to test whether it's > INT_MAX only in tolist() -- in that case you should raise MemoryError. Other than that, it looks decent! ------------------------------------------------------- Date: 2001-Jan-09 06:31 By: greg_ball Comment: This is a replacement for patch 103129, as suggested by tim_one. Possibly interesting aspects of the patch: - xrange objects with overflowing lengths are not gratutiously rejected. An error is raised only if the length becomes relevant, under len() or negative indexing. Bad lengths are stored as -1. Objects with bad lengths allow any non-negative integer index. - On 64 bit platforms, sequence multiplication seems to cause an unsafe cast from long to int. This patch does not address that issue. Without my patch, on i686 Linux: Python 2.0 (#25, Jan 2 2001, 12:18:07) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> y = xrange(maxint/2)*3 >>> len(y) -1073741827 >>> y[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> y.tolist() Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: listobject.c:33: bad argument to internal function >>> m = maxint >> 16 >>> xrange(0,maxint,m) xrange(0, -2147450883, 32767) >>> (xrange(1)*maxint)*maxint xrange(1) >>> With my patch Python 2.0 (#35, Jan 6 2001, 12:54:41) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> y = xrange(maxint/2)*3 >>> len(y) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> y.tolist() Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> m = maxint >> 16 >>> xrange(0,maxint,m) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer addition >>> (xrange(1)*maxint) * maxint Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer multiplication >>> Without patch on Digital Unix Python 2.0 (#5, Jan 6 2001, 15:42:58) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> xrange(0,maxint,m) xrange(0, -9223372034707292163, 2147483647) >>> xrange(1)*maxint xrange(0) >>> With patch Python 2.0 (#7, Jan 6 2001, 15:52:21) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> xrange(0,maxint,m) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer addition >>> xrange(1)*maxint xrange(0) >>> ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103158&group_id=5470 From noreply@sourceforge.net Fri Jan 12 20:58:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 12:58:20 -0800 Subject: [Patches] [Patch #103158] Don't do unsafe arithmetic in xrange object Message-ID: <E14HBHA-0001xB-00@usw-sf-web1.sourceforge.net> Patch #103158 has been updated. Project: python Category: core (C code) Status: Open Submitted by: greg_ball Assigned to : gvanrossum Summary: Don't do unsafe arithmetic in xrange object Follow-Ups: Date: 2001-Jan-12 12:58 By: tim_one Comment: I'm aware of people who actually do x = xrange(sys.maxint) and that should continue to work. Python 2.0 already complains about more than that: >>> xrange(-1, sys.maxint) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange() has more than sys.maxint items >>> and I sure don't want to see that extended (unless it's part of a *sweeping* crusade to eradicate the visibile differences between ints and longs). ------------------------------------------------------- Date: 2001-Jan-12 12:44 By: gvanrossum Comment: In theory, there's a use for objects whose length doesn't fit in an int: for i in xrange(...) is routinely used for loops that expect to break well before the end but don't want to give an arbitrary upper bound. But I agree with Tim that this serves no real purpose. I think that if anything, the xrange() object should be scaled down. No repetition, no concationation, no slicing. the only real use ought to be "for i in xrange(...)". But of course, *that* is bound to break somebody's code somewhere. So let's not go there. But let's not complicate it any further. Prevent breakage, but don't stretch the functionality beyond what it currently does. ------------------------------------------------------- Date: 2001-Jan-12 12:35 By: tim_one Comment: Please do reject objects whose length doesn't fit into an int. I'll bet a dollar that no real code in the world will break as a result. I feel confident making that bet, because if someone's code *does* break as a result, it's worth a dollar to me to see Guido lecture them that their code was already broken <wink>. Really, it's very Pythonic to gripe about a problem just as soon as it crops up. It's not doing anyone a favor to delay griping until the object is used: at that point, it may be very difficult to figure out how the object *got* damaged. There's simply no payback in allowing creation of an unusable xrange object, and, as you say, life is simpler if you don't allow it. ------------------------------------------------------- Date: 2001-Jan-12 12:11 By: greg_ball Comment: The new version of the patch makes the code a bit less complicated. (Only error messages have changed in terms of behaviour; regression test run under linux and OSF1.) If it looks ok you can ignore the rest of this comment... I originally made totlen an int because it is the return value from range_length, and the argument to PyList_New(). The current patch makes totlen a long, but the ocde doesn't get hugely less complicated. The code would get simpler if it rejected objects whose length doesn't fit into a int, but that seemed too easy and there is a small chance someone's code might break. On the other hand by rejecting objects whose stop can't be correctly calculated, I _might_ have broken code already. Break just means "now raises exception" though, nothing insidious. ------------------------------------------------------- Date: 2001-Jan-10 10:28 By: gvanrossum Comment: I wonder why you made totlen an int. This seems to complicate the code quite a bit. I'd suggest making it a long. Then you have to test whether it's > INT_MAX only in tolist() -- in that case you should raise MemoryError. Other than that, it looks decent! ------------------------------------------------------- Date: 2001-Jan-09 06:31 By: greg_ball Comment: This is a replacement for patch 103129, as suggested by tim_one. Possibly interesting aspects of the patch: - xrange objects with overflowing lengths are not gratutiously rejected. An error is raised only if the length becomes relevant, under len() or negative indexing. Bad lengths are stored as -1. Objects with bad lengths allow any non-negative integer index. - On 64 bit platforms, sequence multiplication seems to cause an unsafe cast from long to int. This patch does not address that issue. Without my patch, on i686 Linux: Python 2.0 (#25, Jan 2 2001, 12:18:07) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> y = xrange(maxint/2)*3 >>> len(y) -1073741827 >>> y[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> y.tolist() Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: listobject.c:33: bad argument to internal function >>> m = maxint >> 16 >>> xrange(0,maxint,m) xrange(0, -2147450883, 32767) >>> (xrange(1)*maxint)*maxint xrange(1) >>> With my patch Python 2.0 (#35, Jan 6 2001, 12:54:41) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> y = xrange(maxint/2)*3 >>> len(y) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> y.tolist() Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> m = maxint >> 16 >>> xrange(0,maxint,m) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer addition >>> (xrange(1)*maxint) * maxint Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer multiplication >>> Without patch on Digital Unix Python 2.0 (#5, Jan 6 2001, 15:42:58) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> xrange(0,maxint,m) xrange(0, -9223372034707292163, 2147483647) >>> xrange(1)*maxint xrange(0) >>> With patch Python 2.0 (#7, Jan 6 2001, 15:52:21) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> xrange(0,maxint,m) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer addition >>> xrange(1)*maxint xrange(0) >>> ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103158&group_id=5470 From noreply@sourceforge.net Fri Jan 12 22:36:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 14:36:50 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14HCoU-0000TP-00@usw-sf-web3.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : loewis Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-12 14:36 By: loewis Comment: The weak dictionary data type needs more clarification in documentation and implementation. In java.util.WeakHashMap, they keys are weak, not the values (i.e. once the key is forgotten, the entry is cleared). In http://www.handshake.de/~dieter/weakdict.html, the values are weak, but it raises KeyErrors for entries that are collected. The initializer of a weak dict does not check the invariant (all values are weak). get() of a weakdict does not support an optional second parameter. weakref and friends need to participate in garbage collection, as the reference to the callback can create a cycle. ------------------------------------------------------- Date: 2001-Jan-12 11:27 By: fdrake Comment: Updated patch to also support proxy semantics using the same invalidation machinery as the basic weak reference type. The additional code is *heavily* borrowed from Neil Schemenauer. ------------------------------------------------------- Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Sat Jan 13 02:31:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 18:31:27 -0800 Subject: [Patches] [Patch #103220] Cygwin util.get_platform() fix Message-ID: <E14HGTX-0006yp-00@usw-sf-web2.sourceforge.net> Patch #103220 has been updated. Project: python Category: distutils Status: Open Submitted by: jlt63 Assigned to : nobody Summary: Cygwin util.get_platform() fix ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103220&group_id=5470 From noreply@sourceforge.net Sat Jan 13 02:32:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 18:32:17 -0800 Subject: [Patches] [Patch #103220] Cygwin util.get_platform() fix Message-ID: <E14HGUL-0006zG-00@usw-sf-web2.sourceforge.net> Patch #103220 has been updated. Project: python Category: distutils Status: Open Submitted by: jlt63 Assigned to : nobody Summary: Cygwin util.get_platform() fix Follow-Ups: Date: 2001-Jan-12 18:32 By: jlt63 Comment: This patch adds support for Cygwin to util.get_platform(). A Cygwin specific case is needed due to the format of Cygwin's uname command: $ uname -r 1.1.7(0.31/3/2) Since the release field contains slashes, a path component name that is based on this information becomes multiple path components instead of a single one. This patch corrects this problem by only using the leading part of the release field that matches the regular expression "[\d.]+". The procedure to apply the patch is as follows: $ cd Lib/distutils $ # save util.patch to the current directory $ patch <util.patch ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103220&group_id=5470 From noreply@sourceforge.net Sat Jan 13 05:01:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 21:01:54 -0800 Subject: [Patches] [Patch #103222] Remove case insensitive problem with "Python" directory Message-ID: <E14HIp8-0004XY-00@usw-sf-web1.sourceforge.net> Patch #103222 has been updated. Project: python Category: None Status: Open Submitted by: dkwolfe Assigned to : nobody Summary: Remove case insensitive problem with "Python" directory ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103222&group_id=5470 From noreply@sourceforge.net Sat Jan 13 07:00:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 23:00:20 -0800 Subject: [Patches] [Patch #103217] prevent htmllib from calling None.split() Message-ID: <E14HKfk-000550-00@usw-sf-web1.sourceforge.net> Patch #103217 has been updated. Project: python Category: library Status: Open Submitted by: fbremmer Assigned to : nobody Summary: prevent htmllib from calling None.split() Follow-Ups: Date: 2001-Jan-12 23:00 By: moshez Comment: Big +1! This also makes save_end's return type reliably a string, which probably would fix other people's bugs without them noticing... (IOW, user code that would get the return data from save_end and treat it as a string). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103217&group_id=5470 From noreply@sourceforge.net Sat Jan 13 07:02:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 23:02:17 -0800 Subject: [Patches] [Patch #103139] Autconfigure curses and readline into the default build Message-ID: <E14HKhd-00055c-00@usw-sf-web1.sourceforge.net> Patch #103139 has been updated. Project: python Category: Build Status: Open Submitted by: esr Assigned to : esr Summary: Autconfigure curses and readline into the default build Follow-Ups: Date: 2001-Jan-12 23:02 By: moshez Comment: Guido, didn't you just check in something like that? ------------------------------------------------------- Date: 2001-Jan-08 18:17 By: gvanrossum Comment: Eric, there seems to be a discrepancy in the patch: the configure script tests for ncurses but the Setup.config.in file links with -lcurses. What gives? ------------------------------------------------------- Date: 2001-Jan-07 21:43 By: nascheme Comment: On Linux I think you should link to ncurses instead of curses and leave termcap out. Debian doesn't have termcap development libraries. Also, this patch only works on Linux. I think Andrew's distutil approach is a much better long term solution. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103139&group_id=5470 From noreply@sourceforge.net Sat Jan 13 07:10:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 23:10:36 -0800 Subject: [Patches] [Patch #103222] Remove case insensitive problem with "Python" directory Message-ID: <E14HKpg-00058L-00@usw-sf-web1.sourceforge.net> Patch #103222 has been updated. Project: python Category: None Status: Open Submitted by: dkwolfe Assigned to : nobody Summary: Remove case insensitive problem with "Python" directory Follow-Ups: Date: 2001-Jan-12 23:10 By: moshez Comment: <pre> I'll summarize the changes: mv Python PyCore I don't think I like it at all....while the directory structure could use some restructuring, that's not the reason nor the time to do this...maybe it's better to have a "build" directory in dist/src, and build to that? I think I'd like that. </PRE> ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103222&group_id=5470 From noreply@sourceforge.net Sat Jan 13 07:15:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 23:15:31 -0800 Subject: [Patches] [Patch #103220] Cygwin util.get_platform() fix Message-ID: <E14HKuR-00059k-00@usw-sf-web1.sourceforge.net> Patch #103220 has been updated. Project: python Category: distutils Status: Open Submitted by: jlt63 Assigned to : nobody Summary: Cygwin util.get_platform() fix Follow-Ups: Date: 2001-Jan-12 23:15 By: moshez Comment: Hmmmmm...only one question, since I don't have Cygwin to play with: how is the "machine" in cygwin determined? You seem to go with the "os-release-machine" format, so I assume cygwin does distinguish the machines, but I have no idea wht the possibilities are. ------------------------------------------------------- Date: 2001-Jan-12 18:32 By: jlt63 Comment: This patch adds support for Cygwin to util.get_platform(). A Cygwin specific case is needed due to the format of Cygwin's uname command: $ uname -r 1.1.7(0.31/3/2) Since the release field contains slashes, a path component name that is based on this information becomes multiple path components instead of a single one. This patch corrects this problem by only using the leading part of the release field that matches the regular expression "[\d.]+". The procedure to apply the patch is as follows: $ cd Lib/distutils $ # save util.patch to the current directory $ patch <util.patch ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103220&group_id=5470 From noreply@sourceforge.net Sat Jan 13 15:28:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 07:28:35 -0800 Subject: [Patches] [Patch #103225] httplib: smallest Python patch ever Message-ID: <E14HSbb-0007T9-00@usw-sf-web1.sourceforge.net> Patch #103225 has been updated. Project: python Category: library Status: Open Submitted by: ping Assigned to : nobody Summary: httplib: smallest Python patch ever ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103225&group_id=5470 From noreply@sourceforge.net Sat Jan 13 16:55:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 08:55:59 -0800 Subject: [Patches] [Patch #103225] httplib: smallest Python patch ever Message-ID: <E14HTyB-0002eo-00@usw-sf-web2.sourceforge.net> Patch #103225 has been updated. Project: python Category: library Status: Closed Submitted by: ping Assigned to : nobody Summary: httplib: smallest Python patch ever Follow-Ups: Date: 2001-Jan-13 08:55 By: gvanrossum Comment: Yes, that's a nit if ever there was one. Good find! :-) Applied it already. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103225&group_id=5470 From noreply@sourceforge.net Sat Jan 13 17:07:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 09:07:50 -0800 Subject: [Patches] [Patch #103222] Remove case insensitive problem with "Python" directory Message-ID: <E14HU9e-0005po-00@usw-sf-web3.sourceforge.net> Patch #103222 has been updated. Project: python Category: None Status: Rejected Submitted by: dkwolfe Assigned to : nobody Summary: Remove case insensitive problem with "Python" directory Follow-Ups: Date: 2001-Jan-13 09:07 By: gvanrossum Comment: Rejected. Renaming a directory is too much of a hassle. ------------------------------------------------------- Date: 2001-Jan-12 23:10 By: moshez Comment: <pre> I'll summarize the changes: mv Python PyCore I don't think I like it at all....while the directory structure could use some restructuring, that's not the reason nor the time to do this...maybe it's better to have a "build" directory in dist/src, and build to that? I think I'd like that. </PRE> ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103222&group_id=5470 From noreply@sourceforge.net Sat Jan 13 17:08:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 09:08:18 -0800 Subject: [Patches] [Patch #103220] Cygwin util.get_platform() fix Message-ID: <E14HUA6-0005py-00@usw-sf-web3.sourceforge.net> Patch #103220 has been updated. Project: python Category: distutils Status: Open Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin util.get_platform() fix Follow-Ups: Date: 2001-Jan-12 23:15 By: moshez Comment: Hmmmmm...only one question, since I don't have Cygwin to play with: how is the "machine" in cygwin determined? You seem to go with the "os-release-machine" format, so I assume cygwin does distinguish the machines, but I have no idea wht the possibilities are. ------------------------------------------------------- Date: 2001-Jan-12 18:32 By: jlt63 Comment: This patch adds support for Cygwin to util.get_platform(). A Cygwin specific case is needed due to the format of Cygwin's uname command: $ uname -r 1.1.7(0.31/3/2) Since the release field contains slashes, a path component name that is based on this information becomes multiple path components instead of a single one. This patch corrects this problem by only using the leading part of the release field that matches the regular expression "[\d.]+". The procedure to apply the patch is as follows: $ cd Lib/distutils $ # save util.patch to the current directory $ patch <util.patch ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103220&group_id=5470 From noreply@sourceforge.net Sat Jan 13 17:11:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 09:11:37 -0800 Subject: [Patches] [Patch #103217] prevent htmllib from calling None.split() Message-ID: <E14HUDJ-0005rD-00@usw-sf-web3.sourceforge.net> Patch #103217 has been updated. Project: python Category: library Status: Rejected Submitted by: fbremmer Assigned to : gvanrossum Summary: prevent htmllib from calling None.split() Follow-Ups: Date: 2001-Jan-13 09:11 By: gvanrossum Comment: You don't understand. You're not supposed to call save_begin() and save_end() in a tag that can be nested. If the problem is that you can't trust your input, you should insert a check in your handler for <tag> that rejects recursive use. ------------------------------------------------------- Date: 2001-Jan-12 23:00 By: moshez Comment: Big +1! This also makes save_end's return type reliably a string, which probably would fix other people's bugs without them noticing... (IOW, user code that would get the return data from save_end and treat it as a string). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103217&group_id=5470 From noreply@sourceforge.net Sat Jan 13 17:12:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 09:12:24 -0800 Subject: [Patches] [Patch #103139] Autconfigure curses and readline into the default build Message-ID: <E14HUE4-0005rY-00@usw-sf-web3.sourceforge.net> Patch #103139 has been updated. Project: python Category: Build Status: Closed Submitted by: esr Assigned to : gvanrossum Summary: Autconfigure curses and readline into the default build Follow-Ups: Date: 2001-Jan-13 09:12 By: gvanrossum Comment: Closed. I already checked this in. ------------------------------------------------------- Date: 2001-Jan-12 23:02 By: moshez Comment: Guido, didn't you just check in something like that? ------------------------------------------------------- Date: 2001-Jan-08 18:17 By: gvanrossum Comment: Eric, there seems to be a discrepancy in the patch: the configure script tests for ncurses but the Setup.config.in file links with -lcurses. What gives? ------------------------------------------------------- Date: 2001-Jan-07 21:43 By: nascheme Comment: On Linux I think you should link to ncurses instead of curses and leave termcap out. Debian doesn't have termcap development libraries. Also, this patch only works on Linux. I think Andrew's distutil approach is a much better long term solution. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103139&group_id=5470 From noreply@sourceforge.net Sat Jan 13 18:40:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 10:40:17 -0800 Subject: [Patches] [Patch #102847] fix a memory leak Message-ID: <E14HVb7-0006Kx-00@usw-sf-web3.sourceforge.net> Patch #102847 has been updated. Project: python Category: core (C code) Status: Open Submitted by: cgw Assigned to : jhylton Summary: fix a memory leak Follow-Ups: Date: 2001-Jan-13 10:40 By: moshez Comment: 102337 is now closed. ------------------------------------------------------- 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 Jan 13 20:00:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 12:00:10 -0800 Subject: [Patches] [Patch #103227] make code.py appreciate softspace. Message-ID: <E14HWqQ-0000Td-00@usw-sf-web1.sourceforge.net> Patch #103227 has been updated. Project: python Category: library Status: Open Submitted by: mwh Assigned to : nobody Summary: make code.py appreciate softspace. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103227&group_id=5470 From noreply@sourceforge.net Sat Jan 13 20:01:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 12:01:50 -0800 Subject: [Patches] [Patch #103228] traceback.py nit. Message-ID: <E14HWs2-0000Uu-00@usw-sf-web1.sourceforge.net> Patch #103228 has been updated. Project: python Category: library Status: Open Submitted by: mwh Assigned to : nobody Summary: traceback.py nit. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103228&group_id=5470 From noreply@sourceforge.net Sat Jan 13 22:10:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 14:10:56 -0800 Subject: [Patches] [Patch #103227] make code.py appreciate softspace. Message-ID: <E14HYsy-0007Nz-00@usw-sf-web3.sourceforge.net> Patch #103227 has been updated. Project: python Category: library Status: Closed Submitted by: mwh Assigned to : gvanrossum Summary: make code.py appreciate softspace. Follow-Ups: Date: 2001-Jan-13 14:10 By: gvanrossum Comment: Thanks -- applied! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103227&group_id=5470 From noreply@sourceforge.net Sat Jan 13 22:14:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 14:14:50 -0800 Subject: [Patches] [Patch #103228] traceback.py nit. Message-ID: <E14HYwk-0007Pd-00@usw-sf-web3.sourceforge.net> Patch #103228 has been updated. Project: python Category: library Status: Closed Submitted by: mwh Assigned to : gvanrossum Summary: traceback.py nit. Follow-Ups: Date: 2001-Jan-13 14:14 By: gvanrossum Comment: Thanks! Applied. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103228&group_id=5470 From noreply@sourceforge.net Sun Jan 14 04:01:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 20:01:15 -0800 Subject: [Patches] [Patch #103220] Cygwin util.get_platform() fix Message-ID: <E14HeLz-0004cd-00@usw-sf-web3.sourceforge.net> Patch #103220 has been updated. Project: python Category: distutils Status: Open Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin util.get_platform() fix Follow-Ups: Date: 2001-Jan-13 20:01 By: jlt63 Comment: > how is the "machine" in cygwin determined? It is derived from Window's GetSystemInfo(). See the following, if interested: http://msdn.microsoft.com/library/psdk/sysmgmt/sysinfo_3t67.htm > You seem to go with the "os-release-machine" format Not for any good reason, I was just trying to get rid of the "(0.31/3/2)" cruft. I'm willing to go with "os-release", if that is deemed more appropriate. Let me know and I will upload a revised patch. > so I assume cygwin does distinguish the machines I don't think it does -- it just reports the machine type. > but I have no idea wht the possibilities are The current list is: i[3-6]86, alpha, mips, and unknown. ------------------------------------------------------- Date: 2001-Jan-12 23:15 By: moshez Comment: Hmmmmm...only one question, since I don't have Cygwin to play with: how is the "machine" in cygwin determined? You seem to go with the "os-release-machine" format, so I assume cygwin does distinguish the machines, but I have no idea wht the possibilities are. ------------------------------------------------------- Date: 2001-Jan-12 18:32 By: jlt63 Comment: This patch adds support for Cygwin to util.get_platform(). A Cygwin specific case is needed due to the format of Cygwin's uname command: $ uname -r 1.1.7(0.31/3/2) Since the release field contains slashes, a path component name that is based on this information becomes multiple path components instead of a single one. This patch corrects this problem by only using the leading part of the release field that matches the regular expression "[\d.]+". The procedure to apply the patch is as follows: $ cd Lib/distutils $ # save util.patch to the current directory $ patch <util.patch ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103220&group_id=5470 From noreply@sourceforge.net Sun Jan 14 18:12:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 10:12:44 -0800 Subject: [Patches] [Patch #103232] Preserve Nonstandard Port Number in Host Header Message-ID: <E14Hre0-0001b8-00@usw-sf-web3.sourceforge.net> Patch #103232 has been updated. Project: python Category: library Status: Open Submitted by: dougfort Assigned to : nobody Summary: Preserve Nonstandard Port Number in Host Header ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103232&group_id=5470 From noreply@sourceforge.net Sun Jan 14 21:03:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 13:03:43 -0800 Subject: [Patches] [Patch #103232] Preserve Nonstandard Port Number in Host Header Message-ID: <E14HuJT-0000og-00@usw-sf-web1.sourceforge.net> Patch #103232 has been updated. Project: python Category: library Status: Closed Submitted by: dougfort Assigned to : gvanrossum Summary: Preserve Nonstandard Port Number in Host Header Follow-Ups: Date: 2001-Jan-14 13:03 By: gvanrossum Comment: Thanks! Checked in. I believe the same should be added to urllib which sometimes generates its own Host: header. Can you submit a patch for that too? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103232&group_id=5470 From noreply@sourceforge.net Sun Jan 14 21:49:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 13:49:40 -0800 Subject: [Patches] [Patch #103232] Preserve Nonstandard Port Number in Host Header Message-ID: <E14Hv1w-00014F-00@usw-sf-web1.sourceforge.net> Patch #103232 has been updated. Project: python Category: library Status: Closed Submitted by: dougfort Assigned to : gvanrossum Summary: Preserve Nonstandard Port Number in Host Header Follow-Ups: Date: 2001-Jan-14 13:49 By: dougfort Comment: urllib handles :port correctly, no patch required. ------------------------------------------------------- Date: 2001-Jan-14 13:03 By: gvanrossum Comment: Thanks! Checked in. I believe the same should be added to urllib which sometimes generates its own Host: header. Can you submit a patch for that too? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103232&group_id=5470 From noreply@sourceforge.net Sun Jan 14 22:44:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 14:44:57 -0800 Subject: [Patches] [Patch #103232] Preserve Nonstandard Port Number in Host Header Message-ID: <E14HvtR-00036u-00@usw-sf-web3.sourceforge.net> Patch #103232 has been updated. Project: python Category: library Status: Closed Submitted by: dougfort Assigned to : gvanrossum Summary: Preserve Nonstandard Port Number in Host Header Follow-Ups: Date: 2001-Jan-14 14:44 By: gvanrossum Comment: Ah, I see. I learn something new every day. :-) Thanks! ------------------------------------------------------- Date: 2001-Jan-14 13:49 By: dougfort Comment: urllib handles :port correctly, no patch required. ------------------------------------------------------- Date: 2001-Jan-14 13:03 By: gvanrossum Comment: Thanks! Checked in. I believe the same should be added to urllib which sometimes generates its own Host: header. Can you submit a patch for that too? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103232&group_id=5470 From noreply@sourceforge.net Sun Jan 14 23:09:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 15:09:47 -0800 Subject: [Patches] [Patch #103211] webbrowser.py: fix spelling of "Konqueror" Message-ID: <E14HwHT-0004Yk-00@usw-sf-web2.sourceforge.net> Patch #103211 has been updated. Project: python Category: library Status: Closed Submitted by: ping Assigned to : gvanrossum Summary: webbrowser.py: fix spelling of "Konqueror" Follow-Ups: Date: 2001-Jan-14 15:09 By: gvanrossum Comment: Ah, I'm checking this in myself. ------------------------------------------------------- Date: 2001-Jan-12 06:23 By: gvanrossum Comment: Check it in, Ping! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103211&group_id=5470 From noreply@sourceforge.net Sun Jan 14 23:11:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 15:11:01 -0800 Subject: [Patches] [Patch #103234] tokenize.py: add support for u"", U'', etc. Message-ID: <E14HwIf-0003FT-00@usw-sf-web3.sourceforge.net> Patch #103234 has been updated. Project: python Category: None Status: Open Submitted by: ping Assigned to : nobody Summary: tokenize.py: add support for u"", U'', etc. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103234&group_id=5470 From noreply@sourceforge.net Sun Jan 14 23:20:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 15:20:45 -0800 Subject: [Patches] [Patch #101612] Prevent recursion limit when using ".*?xxx" Message-ID: <E14HwS5-0003J3-00@usw-sf-web3.sourceforge.net> Patch #101612 has been updated. Project: python Category: Modules Status: Closed Submitted by: dgallion Assigned to : effbot Summary: Prevent recursion limit when using ".*?xxx" Follow-Ups: Date: 2001-Jan-14 15:20 By: effbot Comment: I've adapted a variant of this patch. Not 100% sure this approach works in all cases, but it has survived all tests I've thrown at it. ------------------------------------------------------- Date: 2000-Sep-22 21:12 By: dgallion Comment: This pattern fails with sre: >>> re.match("(?s){.*?}","{"+' '*17000+"}") Traceback (most recent call last): File "<stdin>", line 1, in ? File "E:\pythonWinCVS\python\dist\src\lib\sre.py", line 44, in match return _compile(pattern, flags).match(string) RuntimeError: maximum recursion limit exceeded The same pattern with even a much larger search buffer works fine on 1.52 This patch optimizes the case ".*?" and avoids the recursion limit. After the patch: >>> import re >>> re.findall('ab.*?bc', 'abababbc') ['abababbc'] >>> re.findall('ab??bc', 'abababbc') ['abbc'] >>> re.sub("(?s){.*?}","","{"+' '*19047+"}") '' >>> re.match("(?s){.*?}","{"+' '*16048+"}") <SRE_Match object at 007E4490> >>> import test.test_re Running tests on re.search and re.match Running tests on re.sub Running tests on symbolic references Running tests on re.subn Running tests on re.split Running tests on re.findall Running tests on re.match Running tests on re.escape Pickling a RegexObject instance Test engine limitations maximum recursion limit exceeded Running re_tests test suite >>> ------------------------------------------------------- Date: 2000-Sep-22 21:23 By: tim_one Comment: Assigned to Fredrik. dgallion, please resubmit a context diff. Straight diffs aren't accepted (they're too brittle). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101612&group_id=5470 From noreply@sourceforge.net Mon Jan 15 00:05:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 16:05:31 -0800 Subject: [Patches] [Patch #103235] getargs: better error messages for wrong # of args Message-ID: <E14Hx9P-0004pN-00@usw-sf-web2.sourceforge.net> Patch #103235 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : nobody Summary: getargs: better error messages for wrong # of args ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103235&group_id=5470 From noreply@sourceforge.net Mon Jan 15 00:37:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 16:37:23 -0800 Subject: [Patches] [Patch #103236] urllib: Encode special characters in user and password Message-ID: <E14HxeF-0003gR-00@usw-sf-web3.sourceforge.net> Patch #103236 has been updated. Project: python Category: library Status: Open Submitted by: dougfort Assigned to : nobody Summary: urllib: Encode special characters in user and password ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103236&group_id=5470 From noreply@sourceforge.net Mon Jan 15 07:02:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 23:02:39 -0800 Subject: [Patches] [Patch #101416] coax _sre.c into using Py_GetRecursionLimit() Message-ID: <E14I3f5-0005ZO-00@usw-sf-web3.sourceforge.net> Patch #101416 has been updated. Project: python Category: Modules Status: Postponed Submitted by: montanaro Assigned to : effbot Summary: coax _sre.c into using Py_GetRecursionLimit() Follow-Ups: Date: 2001-Jan-14 23:02 By: effbot Comment: A few months later, I'm still sceptical: an SRE stackframe isn't the same thing as a ceval stackframe, and I'm not sure using the same value for both makes much sense. I'll postpone it for now. ------------------------------------------------------- Date: 2000-Sep-04 09:02 By: montanaro Comment: seems obvious that Fredrik should be the one to handle this... ------------------------------------------------------- Date: 2000-Sep-15 07:21 By: fdrake Comment: The declaration of rlimit should be wrapped in #ifdef USE_RECURSION_LIMIT / #endif, since it isn't used otherwise. ------------------------------------------------------- Date: 2000-Sep-15 08:26 By: montanaro Comment: thanks - new version adds the appropriate ifdef ------------------------------------------------------- Date: 2000-Sep-22 05:54 By: fdrake Comment: Fredrik, are there problems with this patch? Does it not make sense? Please take action on this. ------------------------------------------------------- Date: 2000-Sep-25 09:50 By: montanaro Comment: Postponing this is okay with me, but I am almost certain the new _sre module is going to cause problems for nasty regular expressions that the 1.5.2 re module could handle. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101416&group_id=5470 From noreply@sourceforge.net Mon Jan 15 17:06:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 09:06:19 -0800 Subject: [Patches] [Patch #103243] another code.py fix - compiling can lead to UnicodeError Message-ID: <E14ID5H-0007gz-00@usw-sf-web1.sourceforge.net> Patch #103243 has been updated. Project: python Category: library Status: Open Submitted by: mwh Assigned to : nobody Summary: another code.py fix - compiling can lead to UnicodeError ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103243&group_id=5470 From noreply@sourceforge.net Mon Jan 15 17:07:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 09:07:24 -0800 Subject: [Patches] [Patch #103216] Auto-detect dbmmodule and build dynamically Message-ID: <E14ID6K-0000lr-00@usw-sf-web3.sourceforge.net> Patch #103216 has been updated. Project: python Category: Build Status: Closed Submitted by: bwarsaw Assigned to : gvanrossum Summary: Auto-detect dbmmodule and build dynamically Follow-Ups: Date: 2001-Jan-15 09:07 By: bwarsaw Comment: Patch approved by Guido, applied by Barry. ------------------------------------------------------- Date: 2001-Jan-12 10:00 By: bwarsaw Comment: Note, I had to rip out the diff to configure because SF complained about the size of the patch. :( Since that can be generated from configure.in, I'm not worrying about it. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103216&group_id=5470 From noreply@sourceforge.net Mon Jan 15 17:09:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 09:09:44 -0800 Subject: [Patches] [Patch #103243] another code.py fix - compiling can lead to UnicodeError Message-ID: <E14ID8a-0007iQ-00@usw-sf-web1.sourceforge.net> Patch #103243 has been updated. Project: python Category: library Status: Open Submitted by: mwh Assigned to : nobody Summary: another code.py fix - compiling can lead to UnicodeError Follow-Ups: Date: 2001-Jan-15 09:09 By: mwh Comment: <sigh> upload version that doesn't also have my last patch in it... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103243&group_id=5470 From noreply@sourceforge.net Mon Jan 15 17:10:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 09:10:47 -0800 Subject: [Patches] [Patch #103158] Don't do unsafe arithmetic in xrange object Message-ID: <E14ID9b-0007io-00@usw-sf-web1.sourceforge.net> Patch #103158 has been updated. Project: python Category: core (C code) Status: Open Submitted by: greg_ball Assigned to : gvanrossum Summary: Don't do unsafe arithmetic in xrange object Follow-Ups: Date: 2001-Jan-15 09:10 By: greg_ball Comment: If we only allow lengths that will fit into a C int, x = xrange(sys.maxint) would fail on 64-bit platforms. (and that code is always going to get written by people on 32-bit platforms.) Making some sort of special case for this particular idiom would not make the code simpler, I'm guessing. One obvious simple way to support it is by truncating the length to INT_MAX as is done in _PyEval_SliceIndex. Then len() and negative indexing can produce consistent non-garbage results, if not what the user might naively expect. In Python 2.0, you get garbage. Using my patch, you get an exception. But nobody actually uses those features, in all probability. Of course the natural extension of this approach is to allow any python integer arguments at all to xrange() (which Tim doesn't want to do) and truncate as necessary. But there is no need to go there; we can just leave bltin_xrange alone. As an aside, how important for performance is the use of C ints rather than C longs in the Python internals on 64 bit machines? 16 bit machines? ------------------------------------------------------- Date: 2001-Jan-12 12:11 By: greg_ball Comment: The new version of the patch makes the code a bit less complicated. (Only error messages have changed in terms of behaviour; regression test run under linux and OSF1.) If it looks ok you can ignore the rest of this comment... I originally made totlen an int because it is the return value from range_length, and the argument to PyList_New(). The current patch makes totlen a long, but the ocde doesn't get hugely less complicated. The code would get simpler if it rejected objects whose length doesn't fit into a int, but that seemed too easy and there is a small chance someone's code might break. On the other hand by rejecting objects whose stop can't be correctly calculated, I _might_ have broken code already. Break just means "now raises exception" though, nothing insidious. ------------------------------------------------------- Date: 2001-Jan-12 12:58 By: tim_one Comment: I'm aware of people who actually do x = xrange(sys.maxint) and that should continue to work. Python 2.0 already complains about more than that: >>> xrange(-1, sys.maxint) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange() has more than sys.maxint items >>> and I sure don't want to see that extended (unless it's part of a *sweeping* crusade to eradicate the visibile differences between ints and longs). ------------------------------------------------------- Date: 2001-Jan-12 12:44 By: gvanrossum Comment: In theory, there's a use for objects whose length doesn't fit in an int: for i in xrange(...) is routinely used for loops that expect to break well before the end but don't want to give an arbitrary upper bound. But I agree with Tim that this serves no real purpose. I think that if anything, the xrange() object should be scaled down. No repetition, no concationation, no slicing. the only real use ought to be "for i in xrange(...)". But of course, *that* is bound to break somebody's code somewhere. So let's not go there. But let's not complicate it any further. Prevent breakage, but don't stretch the functionality beyond what it currently does. ------------------------------------------------------- Date: 2001-Jan-12 12:35 By: tim_one Comment: Please do reject objects whose length doesn't fit into an int. I'll bet a dollar that no real code in the world will break as a result. I feel confident making that bet, because if someone's code *does* break as a result, it's worth a dollar to me to see Guido lecture them that their code was already broken <wink>. Really, it's very Pythonic to gripe about a problem just as soon as it crops up. It's not doing anyone a favor to delay griping until the object is used: at that point, it may be very difficult to figure out how the object *got* damaged. There's simply no payback in allowing creation of an unusable xrange object, and, as you say, life is simpler if you don't allow it. ------------------------------------------------------- Date: 2001-Jan-10 10:28 By: gvanrossum Comment: I wonder why you made totlen an int. This seems to complicate the code quite a bit. I'd suggest making it a long. Then you have to test whether it's > INT_MAX only in tolist() -- in that case you should raise MemoryError. Other than that, it looks decent! ------------------------------------------------------- Date: 2001-Jan-09 06:31 By: greg_ball Comment: This is a replacement for patch 103129, as suggested by tim_one. Possibly interesting aspects of the patch: - xrange objects with overflowing lengths are not gratutiously rejected. An error is raised only if the length becomes relevant, under len() or negative indexing. Bad lengths are stored as -1. Objects with bad lengths allow any non-negative integer index. - On 64 bit platforms, sequence multiplication seems to cause an unsafe cast from long to int. This patch does not address that issue. Without my patch, on i686 Linux: Python 2.0 (#25, Jan 2 2001, 12:18:07) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> y = xrange(maxint/2)*3 >>> len(y) -1073741827 >>> y[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> y.tolist() Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: listobject.c:33: bad argument to internal function >>> m = maxint >> 16 >>> xrange(0,maxint,m) xrange(0, -2147450883, 32767) >>> (xrange(1)*maxint)*maxint xrange(1) >>> With my patch Python 2.0 (#35, Jan 6 2001, 12:54:41) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> y = xrange(maxint/2)*3 >>> len(y) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> y.tolist() Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> m = maxint >> 16 >>> xrange(0,maxint,m) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer addition >>> (xrange(1)*maxint) * maxint Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer multiplication >>> Without patch on Digital Unix Python 2.0 (#5, Jan 6 2001, 15:42:58) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> xrange(0,maxint,m) xrange(0, -9223372034707292163, 2147483647) >>> xrange(1)*maxint xrange(0) >>> With patch Python 2.0 (#7, Jan 6 2001, 15:52:21) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> xrange(0,maxint,m) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer addition >>> xrange(1)*maxint xrange(0) >>> ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103158&group_id=5470 From noreply@sourceforge.net Mon Jan 15 18:14:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 10:14:17 -0800 Subject: [Patches] [Patch #103243] another code.py fix - compiling can lead to UnicodeError Message-ID: <E14IE93-0001Ba-00@usw-sf-web3.sourceforge.net> Patch #103243 has been updated. Project: python Category: library Status: Closed Submitted by: mwh Assigned to : gvanrossum Summary: another code.py fix - compiling can lead to UnicodeError Follow-Ups: Date: 2001-Jan-15 10:14 By: gvanrossum Comment: I'll do you one better -- ValueError can be raised too (try '\x'). Checked something in that catches both (UnicodeError is derived from ValueError). ------------------------------------------------------- Date: 2001-Jan-15 09:09 By: mwh Comment: <sigh> upload version that doesn't also have my last patch in it... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103243&group_id=5470 From noreply@sourceforge.net Mon Jan 15 18:16:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 10:16:03 -0800 Subject: [Patches] [Patch #103234] tokenize.py: add support for u"", U'', etc. Message-ID: <E14IEAl-0001CP-00@usw-sf-web3.sourceforge.net> Patch #103234 has been updated. Project: python Category: None Status: Open Submitted by: ping Assigned to : ping Summary: tokenize.py: add support for u"", U'', etc. Follow-Ups: Date: 2001-Jan-15 10:16 By: gvanrossum Comment: Check it in, ping! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103234&group_id=5470 From noreply@sourceforge.net Mon Jan 15 18:21:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 10:21:14 -0800 Subject: [Patches] [Patch #103235] getargs: better error messages for wrong # of args Message-ID: <E14IEFm-0001ED-00@usw-sf-web3.sourceforge.net> Patch #103235 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : ping Summary: getargs: better error messages for wrong # of args Follow-Ups: Date: 2001-Jan-15 10:21 By: gvanrossum Comment: Cool patch, Ping. Please check it in! Note that this breaks test_pyexpat; since the breakage seems to be just that the text of the error message has changed, I suggest that you can fix that, too! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103235&group_id=5470 From noreply@sourceforge.net Mon Jan 15 18:31:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 10:31:57 -0800 Subject: [Patches] [Patch #103236] urllib: Encode special characters in user and password Message-ID: <E14IEQ9-0008DZ-00@usw-sf-web1.sourceforge.net> Patch #103236 has been updated. Project: python Category: library Status: Closed Submitted by: dougfort Assigned to : gvanrossum Summary: urllib: Encode special characters in user and password Follow-Ups: Date: 2001-Jan-15 10:31 By: gvanrossum Comment: Done! Please next time send in a context diff, and please let it be a diff of (oldfile, newfile) rather than reversed. :-) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103236&group_id=5470 From noreply@sourceforge.net Mon Jan 15 18:59:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 10:59:24 -0800 Subject: [Patches] [Patch #103158] Don't do unsafe arithmetic in xrange object Message-ID: <E14IEqi-0008Nn-00@usw-sf-web1.sourceforge.net> Patch #103158 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: greg_ball Assigned to : gvanrossum Summary: Don't do unsafe arithmetic in xrange object Follow-Ups: Date: 2001-Jan-15 10:59 By: gvanrossum Comment: I've checked in this version of the patch -- having looked and thought it over for a bit, I agree that this is about as good as we can expect it to do without changing certain internal APIs. Your question about the wisdom of using ints is a good one! In particular it is stupid that PyIntObject holds a long but that the return value from the sq_length function is constrained to be an int. This is from way back when I thought that size_t would never be larger than int. Boy was I wrong. In an ideal world, the int size used for Python ints would be a configuration option, and the configure script would work hard to make it a 64-bit int whenever supported (even on 32-bit platforms). A simpler change would be to simply change the specification for sq_length to return a long, but that's not without problems: existing extensions would have to be recompiled for platforms where int and long aren't the same size (64-bit platforms except Win64). ------------------------------------------------------- Date: 2001-Jan-15 09:10 By: greg_ball Comment: If we only allow lengths that will fit into a C int, x = xrange(sys.maxint) would fail on 64-bit platforms. (and that code is always going to get written by people on 32-bit platforms.) Making some sort of special case for this particular idiom would not make the code simpler, I'm guessing. One obvious simple way to support it is by truncating the length to INT_MAX as is done in _PyEval_SliceIndex. Then len() and negative indexing can produce consistent non-garbage results, if not what the user might naively expect. In Python 2.0, you get garbage. Using my patch, you get an exception. But nobody actually uses those features, in all probability. Of course the natural extension of this approach is to allow any python integer arguments at all to xrange() (which Tim doesn't want to do) and truncate as necessary. But there is no need to go there; we can just leave bltin_xrange alone. As an aside, how important for performance is the use of C ints rather than C longs in the Python internals on 64 bit machines? 16 bit machines? ------------------------------------------------------- Date: 2001-Jan-12 12:11 By: greg_ball Comment: The new version of the patch makes the code a bit less complicated. (Only error messages have changed in terms of behaviour; regression test run under linux and OSF1.) If it looks ok you can ignore the rest of this comment... I originally made totlen an int because it is the return value from range_length, and the argument to PyList_New(). The current patch makes totlen a long, but the ocde doesn't get hugely less complicated. The code would get simpler if it rejected objects whose length doesn't fit into a int, but that seemed too easy and there is a small chance someone's code might break. On the other hand by rejecting objects whose stop can't be correctly calculated, I _might_ have broken code already. Break just means "now raises exception" though, nothing insidious. ------------------------------------------------------- Date: 2001-Jan-12 12:58 By: tim_one Comment: I'm aware of people who actually do x = xrange(sys.maxint) and that should continue to work. Python 2.0 already complains about more than that: >>> xrange(-1, sys.maxint) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange() has more than sys.maxint items >>> and I sure don't want to see that extended (unless it's part of a *sweeping* crusade to eradicate the visibile differences between ints and longs). ------------------------------------------------------- Date: 2001-Jan-12 12:44 By: gvanrossum Comment: In theory, there's a use for objects whose length doesn't fit in an int: for i in xrange(...) is routinely used for loops that expect to break well before the end but don't want to give an arbitrary upper bound. But I agree with Tim that this serves no real purpose. I think that if anything, the xrange() object should be scaled down. No repetition, no concationation, no slicing. the only real use ought to be "for i in xrange(...)". But of course, *that* is bound to break somebody's code somewhere. So let's not go there. But let's not complicate it any further. Prevent breakage, but don't stretch the functionality beyond what it currently does. ------------------------------------------------------- Date: 2001-Jan-12 12:35 By: tim_one Comment: Please do reject objects whose length doesn't fit into an int. I'll bet a dollar that no real code in the world will break as a result. I feel confident making that bet, because if someone's code *does* break as a result, it's worth a dollar to me to see Guido lecture them that their code was already broken <wink>. Really, it's very Pythonic to gripe about a problem just as soon as it crops up. It's not doing anyone a favor to delay griping until the object is used: at that point, it may be very difficult to figure out how the object *got* damaged. There's simply no payback in allowing creation of an unusable xrange object, and, as you say, life is simpler if you don't allow it. ------------------------------------------------------- Date: 2001-Jan-10 10:28 By: gvanrossum Comment: I wonder why you made totlen an int. This seems to complicate the code quite a bit. I'd suggest making it a long. Then you have to test whether it's > INT_MAX only in tolist() -- in that case you should raise MemoryError. Other than that, it looks decent! ------------------------------------------------------- Date: 2001-Jan-09 06:31 By: greg_ball Comment: This is a replacement for patch 103129, as suggested by tim_one. Possibly interesting aspects of the patch: - xrange objects with overflowing lengths are not gratutiously rejected. An error is raised only if the length becomes relevant, under len() or negative indexing. Bad lengths are stored as -1. Objects with bad lengths allow any non-negative integer index. - On 64 bit platforms, sequence multiplication seems to cause an unsafe cast from long to int. This patch does not address that issue. Without my patch, on i686 Linux: Python 2.0 (#25, Jan 2 2001, 12:18:07) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> y = xrange(maxint/2)*3 >>> len(y) -1073741827 >>> y[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> y.tolist() Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: listobject.c:33: bad argument to internal function >>> m = maxint >> 16 >>> xrange(0,maxint,m) xrange(0, -2147450883, 32767) >>> (xrange(1)*maxint)*maxint xrange(1) >>> With my patch Python 2.0 (#35, Jan 6 2001, 12:54:41) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> y = xrange(maxint/2)*3 >>> len(y) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> y.tolist() Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> m = maxint >> 16 >>> xrange(0,maxint,m) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer addition >>> (xrange(1)*maxint) * maxint Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer multiplication >>> Without patch on Digital Unix Python 2.0 (#5, Jan 6 2001, 15:42:58) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> xrange(0,maxint,m) xrange(0, -9223372034707292163, 2147483647) >>> xrange(1)*maxint xrange(0) >>> With patch Python 2.0 (#7, Jan 6 2001, 15:52:21) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> xrange(0,maxint,m) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer addition >>> xrange(1)*maxint xrange(0) >>> ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103158&group_id=5470 From noreply@sourceforge.net Mon Jan 15 19:08:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 11:08:29 -0800 Subject: [Patches] [Patch #103123] PEP 232 implementation (function attributes) Message-ID: <E14IEzV-0008RT-00@usw-sf-web1.sourceforge.net> Patch #103123 has been updated. Project: python Category: core (C code) Status: Open Submitted by: bwarsaw Assigned to : gvanrossum Summary: PEP 232 implementation (function attributes) Follow-Ups: Date: 2001-Jan-15 11:08 By: gvanrossum Comment: Looks good, Barry. Check it in. Please also add an item to the NEWS file! ------------------------------------------------------- Date: 2001-Jan-06 07:34 By: montanaro Comment: Quick nit in the doc: How about "functions written in Python" instead of "non-built-in functions"? - right at the start of the patch. Also, how about an example of what you are trying to avoid when you don't allow setting bound methods' attributes (besides the obvious fact that classes and instances already have their own attributes) class C: def meth(self): print "hi!" c = C() d = C() c.meth.attr = "my name is 'c'" d.meth.attr = "my name is 'd'" If bound method attribute setting was allowed, c.meth.attr return "my name is 'd'"... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103123&group_id=5470 From noreply@sourceforge.net Mon Jan 15 19:50:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 11:50:35 -0800 Subject: [Patches] [Patch #103123] PEP 232 implementation (function attributes) Message-ID: <E14IFeF-0000Fb-00@usw-sf-web1.sourceforge.net> Patch #103123 has been updated. Project: python Category: core (C code) Status: Open Submitted by: bwarsaw Assigned to : bwarsaw Summary: PEP 232 implementation (function attributes) Follow-Ups: Date: 2001-Jan-15 11:08 By: gvanrossum Comment: Looks good, Barry. Check it in. Please also add an item to the NEWS file! ------------------------------------------------------- Date: 2001-Jan-06 07:34 By: montanaro Comment: Quick nit in the doc: How about "functions written in Python" instead of "non-built-in functions"? - right at the start of the patch. Also, how about an example of what you are trying to avoid when you don't allow setting bound methods' attributes (besides the obvious fact that classes and instances already have their own attributes) class C: def meth(self): print "hi!" c = C() d = C() c.meth.attr = "my name is 'c'" d.meth.attr = "my name is 'd'" If bound method attribute setting was allowed, c.meth.attr return "my name is 'd'"... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103123&group_id=5470 From noreply@sourceforge.net Mon Jan 15 20:49:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 12:49:51 -0800 Subject: [Patches] [Patch #103123] PEP 232 implementation (function attributes) Message-ID: <E14IGZb-00028K-00@usw-sf-web3.sourceforge.net> Patch #103123 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: bwarsaw Assigned to : bwarsaw Summary: PEP 232 implementation (function attributes) Follow-Ups: Date: 2001-Jan-15 12:49 By: bwarsaw Comment: Patch has been applied. ------------------------------------------------------- Date: 2001-Jan-15 11:08 By: gvanrossum Comment: Looks good, Barry. Check it in. Please also add an item to the NEWS file! ------------------------------------------------------- Date: 2001-Jan-06 07:34 By: montanaro Comment: Quick nit in the doc: How about "functions written in Python" instead of "non-built-in functions"? - right at the start of the patch. Also, how about an example of what you are trying to avoid when you don't allow setting bound methods' attributes (besides the obvious fact that classes and instances already have their own attributes) class C: def meth(self): print "hi!" c = C() d = C() c.meth.attr = "my name is 'c'" d.meth.attr = "my name is 'd'" If bound method attribute setting was allowed, c.meth.attr return "my name is 'd'"... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103123&group_id=5470 From noreply@sourceforge.net Mon Jan 15 22:06:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 14:06:44 -0800 Subject: [Patches] [Patch #103234] tokenize.py: add support for u"", U'', etc. Message-ID: <E14IHm0-000196-00@usw-sf-web1.sourceforge.net> Patch #103234 has been updated. Project: python Category: None Status: Closed Submitted by: ping Assigned to : ping Summary: tokenize.py: add support for u"", U'', etc. Follow-Ups: Date: 2001-Jan-15 14:06 By: ping Comment: Okay, done. ------------------------------------------------------- Date: 2001-Jan-15 10:16 By: gvanrossum Comment: Check it in, ping! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103234&group_id=5470 From noreply@sourceforge.net Mon Jan 15 22:18:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 14:18:57 -0800 Subject: [Patches] [Patch #103235] getargs: better error messages for wrong # of args Message-ID: <E14IHxp-0002i6-00@usw-sf-web3.sourceforge.net> Patch #103235 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: ping Assigned to : ping Summary: getargs: better error messages for wrong # of args Follow-Ups: Date: 2001-Jan-15 14:18 By: ping Comment: Sorry, i didn't have XML libraries installed, so regrtest skipped py_expat. I updated test/output/test_pyexpat; it should be right now. Checked in; thanks! ------------------------------------------------------- Date: 2001-Jan-15 10:21 By: gvanrossum Comment: Cool patch, Ping. Please check it in! Note that this breaks test_pyexpat; since the breakage seems to be just that the text of the error message has changed, I suggest that you can fix that, too! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103235&group_id=5470 From noreply@sourceforge.net Mon Jan 15 22:21:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 14:21:54 -0800 Subject: [Patches] [Patch #102679] linuxaudiodev: better format names (and error messages) Message-ID: <E14II0g-0002j2-00@usw-sf-web3.sourceforge.net> Patch #102679 has been updated. Project: python Category: Modules Status: Closed Submitted by: ping Assigned to : ping Summary: linuxaudiodev: better format names (and error messages) Follow-Ups: Date: 2001-Jan-15 14:21 By: ping Comment: Checked in. ------------------------------------------------------- Date: 2001-Jan-04 11:31 By: fdrake Comment: Looks good; please check this in. ------------------------------------------------------- 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 Mon Jan 15 22:34:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 14:34:23 -0800 Subject: [Patches] [Patch #103246] Remove unneeded string exception compat from Queue Message-ID: <E14IICl-0001JJ-00@usw-sf-web1.sourceforge.net> Patch #103246 has been updated. Project: python Category: None Status: Open Submitted by: montanaro Assigned to : nobody Summary: Remove unneeded string exception compat from Queue ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103246&group_id=5470 From noreply@sourceforge.net Mon Jan 15 22:43:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 14:43:15 -0800 Subject: [Patches] [Patch #103246] Remove unneeded string exception compat from Queue Message-ID: <E14IILL-0001Mi-00@usw-sf-web1.sourceforge.net> Patch #103246 has been updated. Project: python Category: None Status: Open Submitted by: montanaro Assigned to : tim_one Summary: Remove unneeded string exception compat from Queue Follow-Ups: Date: 2001-Jan-15 14:43 By: tim_one Comment: Assigned to me. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103246&group_id=5470 From noreply@sourceforge.net Mon Jan 15 22:44:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 14:44:13 -0800 Subject: [Patches] [Patch #103247] Strings: '\012' -> '\n' Message-ID: <E14IIMH-00047X-00@usw-sf-web2.sourceforge.net> Patch #103247 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : nobody Summary: Strings: '\012' -> '\n' ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103247&group_id=5470 From noreply@sourceforge.net Mon Jan 15 22:55:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 14:55:07 -0800 Subject: [Patches] [Patch #103246] Remove unneeded string exception compat from Queue Message-ID: <E14IIWp-0001Qw-00@usw-sf-web1.sourceforge.net> Patch #103246 has been updated. Project: python Category: library Status: Closed Submitted by: montanaro Assigned to : tim_one Summary: Remove unneeded string exception compat from Queue Follow-Ups: Date: 2001-Jan-15 14:55 By: tim_one Comment: Thanks, Skip! I checked in a minor variant in Queue.py rev 1.12. I sure hope you don't get another job <wink>. ------------------------------------------------------- Date: 2001-Jan-15 14:43 By: tim_one Comment: Assigned to me. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103246&group_id=5470 From noreply@sourceforge.net Mon Jan 15 23:35:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 15:35:12 -0800 Subject: [Patches] [Patch #103248] Fix a memory leak in _sre.c Message-ID: <E14IJ9c-00038X-00@usw-sf-web3.sourceforge.net> Patch #103248 has been updated. Project: python Category: core (C code) Status: Open Submitted by: cgw Assigned to : nobody Summary: Fix a memory leak in _sre.c ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103248&group_id=5470 From noreply@sourceforge.net Tue Jan 16 00:32:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 16:32:33 -0800 Subject: [Patches] [Patch #103249] fix for bug # 128921 Message-ID: <E14IK37-0003RW-00@usw-sf-web3.sourceforge.net> Patch #103249 has been updated. Project: python Category: core (C code) Status: Open Submitted by: mwh Assigned to : nobody Summary: fix for bug # 128921 ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103249&group_id=5470 From noreply@sourceforge.net Tue Jan 16 00:42:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 16:42:26 -0800 Subject: [Patches] [Patch #103250] Optimize a strspn() out of startup Message-ID: <E14IKCg-00023I-00@usw-sf-web1.sourceforge.net> Patch #103250 has been updated. Project: python Category: None Status: Open Submitted by: pj99 Assigned to : nobody Summary: Optimize a strspn() out of startup ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103250&group_id=5470 From noreply@sourceforge.net Tue Jan 16 01:55:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 17:55:51 -0800 Subject: [Patches] [Patch #103252] Startup optimize: read *.pyc as string, not with getc() Message-ID: <E14ILLj-0002Qe-00@usw-sf-web1.sourceforge.net> Patch #103252 has been updated. Project: python Category: core (C code) Status: Open Submitted by: pj99 Assigned to : nobody Summary: Startup optimize: read *.pyc as string, not with getc() ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103252&group_id=5470 From noreply@sourceforge.net Tue Jan 16 02:16:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 18:16:20 -0800 Subject: [Patches] [Patch #103253] Plug memory leak in posixmodule.c Message-ID: <E14ILfY-0003za-00@usw-sf-web3.sourceforge.net> Patch #103253 has been updated. Project: python Category: None Status: Open Submitted by: nascheme Assigned to : nobody Summary: Plug memory leak in posixmodule.c ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103253&group_id=5470 From noreply@sourceforge.net Tue Jan 16 02:18:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 18:18:54 -0800 Subject: [Patches] [Patch #103253] Plug memory leak in posixmodule.c Message-ID: <E14ILi2-00040F-00@usw-sf-web3.sourceforge.net> Patch #103253 has been updated. Project: python Category: None Status: Open Submitted by: nascheme Assigned to : gvanrossum Summary: Plug memory leak in posixmodule.c Follow-Ups: Date: 2001-Jan-15 18:18 By: nascheme Comment: Assigned to Guido because I think he last touched the posix_putenv_garbage code. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103253&group_id=5470 From noreply@sourceforge.net Tue Jan 16 03:30:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 19:30:34 -0800 Subject: [Patches] [Patch #103248] Fix a memory leak in _sre.c Message-ID: <E14IMpO-0002wt-00@usw-sf-web1.sourceforge.net> Patch #103248 has been updated. Project: python Category: core (C code) Status: Open Submitted by: cgw Assigned to : effbot Summary: Fix a memory leak in _sre.c ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103248&group_id=5470 From noreply@sourceforge.net Tue Jan 16 03:35:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 19:35:03 -0800 Subject: [Patches] [Patch #103250] Optimize a strspn() out of startup Message-ID: <E14IMtj-0002yg-00@usw-sf-web1.sourceforge.net> Patch #103250 has been updated. Project: python Category: None Status: Open Submitted by: pj99 Assigned to : nobody Summary: Optimize a strspn() out of startup Follow-Ups: Date: 2001-Jan-15 19:35 By: gvanrossum Comment: Looks cool to me. Do you have an idea what to do about the other 98.5%? :) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103250&group_id=5470 From noreply@sourceforge.net Tue Jan 16 03:39:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 19:39:45 -0800 Subject: [Patches] [Patch #103252] Startup optimize: read *.pyc as string, not with getc() Message-ID: <E14IMyH-00030K-00@usw-sf-web1.sourceforge.net> Patch #103252 has been updated. Project: python Category: core (C code) Status: Open Submitted by: pj99 Assigned to : nobody Summary: Startup optimize: read *.pyc as string, not with getc() Follow-Ups: Date: 2001-Jan-15 19:39 By: gvanrossum Comment: Not a bad idea. I'd up the limit to 256K so Tkinter.pyc (comfortably) fits. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103252&group_id=5470 From noreply@sourceforge.net Tue Jan 16 03:41:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 19:41:11 -0800 Subject: [Patches] [Patch #103253] Plug memory leak in posixmodule.c Message-ID: <E14IMzf-00030o-00@usw-sf-web1.sourceforge.net> Patch #103253 has been updated. Project: python Category: None Status: Open Submitted by: nascheme Assigned to : nascheme Summary: Plug memory leak in posixmodule.c Follow-Ups: Date: 2001-Jan-15 19:41 By: gvanrossum Comment: Excellent, please check in and close the patch! ------------------------------------------------------- Date: 2001-Jan-15 18:18 By: nascheme Comment: Assigned to Guido because I think he last touched the posix_putenv_garbage code. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103253&group_id=5470 From noreply@sourceforge.net Tue Jan 16 04:05:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 20:05:42 -0800 Subject: [Patches] [Patch #103252] Startup optimize: read *.pyc as string, not with getc() Message-ID: <E14INNO-0004Wm-00@usw-sf-web3.sourceforge.net> Patch #103252 has been updated. Project: python Category: core (C code) Status: Open Submitted by: pj99 Assigned to : nobody Summary: Startup optimize: read *.pyc as string, not with getc() Follow-Ups: Date: 2001-Jan-15 20:05 By: tim_one Comment: I like the idea, but gimmicks like this make porting to tiny platforms harder when pushed "too far". People concerned about startup time seem mostly to deal with apps that e.g. fire up Python 1000s of times from shell scripts or cgi. They're not going to care about monster modules (like Tkinter and grail). So I think Paul's original 64K is a good compromise. ------------------------------------------------------- Date: 2001-Jan-15 19:39 By: gvanrossum Comment: Not a bad idea. I'd up the limit to 256K so Tkinter.pyc (comfortably) fits. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103252&group_id=5470 From noreply@sourceforge.net Tue Jan 16 04:18:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 20:18:51 -0800 Subject: [Patches] [Patch #103252] Startup optimize: read *.pyc as string, not with getc() Message-ID: <E14INa7-0004b1-00@usw-sf-web3.sourceforge.net> Patch #103252 has been updated. Project: python Category: core (C code) Status: Open Submitted by: pj99 Assigned to : nobody Summary: Startup optimize: read *.pyc as string, not with getc() Follow-Ups: Date: 2001-Jan-15 20:18 By: gvanrossum Comment: Oh, but I do care about the load time of Tkinter. :-) Anything to keep IDLE ahead of Komodo in the race. :-) ------------------------------------------------------- Date: 2001-Jan-15 20:05 By: tim_one Comment: I like the idea, but gimmicks like this make porting to tiny platforms harder when pushed "too far". People concerned about startup time seem mostly to deal with apps that e.g. fire up Python 1000s of times from shell scripts or cgi. They're not going to care about monster modules (like Tkinter and grail). So I think Paul's original 64K is a good compromise. ------------------------------------------------------- Date: 2001-Jan-15 19:39 By: gvanrossum Comment: Not a bad idea. I'd up the limit to 256K so Tkinter.pyc (comfortably) fits. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103252&group_id=5470 From noreply@sourceforge.net Tue Jan 16 04:21:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 20:21:08 -0800 Subject: [Patches] [Patch #103247] Strings: '\012' -> '\n' Message-ID: <E14INcK-0004bp-00@usw-sf-web3.sourceforge.net> Patch #103247 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : nobody Summary: Strings: '\012' -> '\n' Follow-Ups: Date: 2001-Jan-15 20:21 By: gvanrossum Comment: Nice. Style nit: I don't care for the fputc(), fputc(); form. Can you resubmit (and retest!) a version that uses \x%02x too? I'd expect that this would require updates to some docs and the tutorial, too. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103247&group_id=5470 From noreply@sourceforge.net Tue Jan 16 04:21:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 20:21:18 -0800 Subject: [Patches] [Patch #103247] Strings: '\012' -> '\n' Message-ID: <E14INcU-0004bx-00@usw-sf-web3.sourceforge.net> Patch #103247 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : ping Summary: Strings: '\012' -> '\n' Follow-Ups: Date: 2001-Jan-15 20:21 By: gvanrossum Comment: Nice. Style nit: I don't care for the fputc(), fputc(); form. Can you resubmit (and retest!) a version that uses \x%02x too? I'd expect that this would require updates to some docs and the tutorial, too. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103247&group_id=5470 From noreply@sourceforge.net Tue Jan 16 04:26:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 20:26:06 -0800 Subject: [Patches] [Patch #103252] Startup optimize: read *.pyc as string, not with getc() Message-ID: <E14INh8-0003GC-00@usw-sf-web1.sourceforge.net> Patch #103252 has been updated. Project: python Category: core (C code) Status: Open Submitted by: pj99 Assigned to : tim_one Summary: Startup optimize: read *.pyc as string, not with getc() Follow-Ups: Date: 2001-Jan-15 20:26 By: tim_one Comment: Indeed, IDLE takes more than a full second to come up on my box, *much* longer than Notepad. Now that we have a clear goal, I assigned this patch to me <wink>. (OK, it's really that I was abrupt with Paul when this came up on c.l.py, and left him hanging there -- I owe him on this one). ------------------------------------------------------- Date: 2001-Jan-15 20:18 By: gvanrossum Comment: Oh, but I do care about the load time of Tkinter. :-) Anything to keep IDLE ahead of Komodo in the race. :-) ------------------------------------------------------- Date: 2001-Jan-15 20:05 By: tim_one Comment: I like the idea, but gimmicks like this make porting to tiny platforms harder when pushed "too far". People concerned about startup time seem mostly to deal with apps that e.g. fire up Python 1000s of times from shell scripts or cgi. They're not going to care about monster modules (like Tkinter and grail). So I think Paul's original 64K is a good compromise. ------------------------------------------------------- Date: 2001-Jan-15 19:39 By: gvanrossum Comment: Not a bad idea. I'd up the limit to 256K so Tkinter.pyc (comfortably) fits. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103252&group_id=5470 From noreply@sourceforge.net Tue Jan 16 04:28:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 20:28:23 -0800 Subject: [Patches] [Patch #103253] Plug memory leak in posixmodule.c Message-ID: <E14INjL-0005wx-00@usw-sf-web2.sourceforge.net> Patch #103253 has been updated. Project: python Category: None Status: Closed Submitted by: nascheme Assigned to : nascheme Summary: Plug memory leak in posixmodule.c Follow-Ups: Date: 2001-Jan-15 20:28 By: nascheme Comment: Checked in (posixmodule.c 2.181). ------------------------------------------------------- Date: 2001-Jan-15 19:41 By: gvanrossum Comment: Excellent, please check in and close the patch! ------------------------------------------------------- Date: 2001-Jan-15 18:18 By: nascheme Comment: Assigned to Guido because I think he last touched the posix_putenv_garbage code. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103253&group_id=5470 From noreply@sourceforge.net Tue Jan 16 05:30:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 21:30:23 -0800 Subject: [Patches] [Patch #102891] Alternative readline module Message-ID: <E14IOhL-0003cS-00@usw-sf-web1.sourceforge.net> Patch #102891 has been updated. Project: python Category: Modules Status: Accepted Submitted by: nascheme Assigned to : esr Summary: Alternative readline module Follow-Ups: Date: 2001-Jan-15 21:30 By: nascheme Comment: Hmm, I still like pyrl better. What to do about GNU readline now that its in Setup.conf? You can't enable them both and I don't feel comfortable enough with autoconf to fix things. ESR, if you could add the magic to test for termios that would be cool. configure should use readline if its there and fall back to edline if termios is available. Feel free to bounce it back to me if you don't have time. ------------------------------------------------------- Date: 2001-Jan-03 06:10 By: gvanrossum Comment: Neil, this has now status Accepted. Go ahead and check it in! ------------------------------------------------------- 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 Tue Jan 16 05:42:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 21:42:27 -0800 Subject: [Patches] [Patch #103247] Strings: '\012' -> '\n' Message-ID: <E14IOt1-0006Km-00@usw-sf-web2.sourceforge.net> Patch #103247 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : ping Summary: Strings: '\012' -> '\n' Follow-Ups: Date: 2001-Jan-15 21:42 By: ping Comment: Yes, the docs will take some work. I'll resubmit when i've gone through all the documentation. ------------------------------------------------------- Date: 2001-Jan-15 20:21 By: gvanrossum Comment: Nice. Style nit: I don't care for the fputc(), fputc(); form. Can you resubmit (and retest!) a version that uses \x%02x too? I'd expect that this would require updates to some docs and the tutorial, too. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103247&group_id=5470 From noreply@sourceforge.net Tue Jan 16 06:50:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 22:50:10 -0800 Subject: [Patches] [Patch #103248] Fix a memory leak in _sre.c Message-ID: <E14IPwY-00042i-00@usw-sf-web1.sourceforge.net> Patch #103248 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: cgw Assigned to : effbot Summary: Fix a memory leak in _sre.c ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103248&group_id=5470 From noreply@sourceforge.net Tue Jan 16 07:25:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 23:25:40 -0800 Subject: [Patches] [Patch #103250] Optimize a strspn() out of startup Message-ID: <E14IQUu-0005YB-00@usw-sf-web3.sourceforge.net> Patch #103250 has been updated. Project: python Category: None Status: Open Submitted by: pj99 Assigned to : nobody Summary: Optimize a strspn() out of startup Follow-Ups: Date: 2001-Jan-15 23:25 By: nobody Comment: Why not (isalpha(c) || isdigit(c) || c=='_') ? ------------------------------------------------------- Date: 2001-Jan-15 19:35 By: gvanrossum Comment: Looks cool to me. Do you have an idea what to do about the other 98.5%? :) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103250&group_id=5470 From noreply@sourceforge.net Tue Jan 16 10:25:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 02:25:05 -0800 Subject: [Patches] [Patch #102891] Alternative readline module Message-ID: <E14ITIX-0007Re-00@usw-sf-web2.sourceforge.net> Patch #102891 has been updated. Project: python Category: Modules Status: Accepted Submitted by: nascheme Assigned to : esr Summary: Alternative readline module Follow-Ups: Date: 2001-Jan-16 02:23 By: mwh Comment: You could defer the decision between readline and edline until runtime, as in: (will sf mangle this? we'll see) Index: Modules/main.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/main.c,v retrieving revision 1.47 diff -c -r1.47 main.c *** Modules/main.c 2000/12/15 22:00:54 1.47 --- Modules/main.c 2001/01/16 10:19:45 *************** *** 267,274 **** isatty(fileno(stdin))) { PyObject *v; v = PyImport_ImportModule("readline"); ! if (v == NULL) PyErr_Clear(); else Py_DECREF(v); } --- 267,280 ---- isatty(fileno(stdin))) { PyObject *v; v = PyImport_ImportModule("readline"); ! if (v == NULL) { PyErr_Clear(); + v = PyImport_ImportModule("edline"); + if (v == NULL) + PyErr_Clear(); + else + Py_DECREF(v); + } else Py_DECREF(v); } (and pyrl's not going to be ready for 2.1, by a country mile...) ------------------------------------------------------- Date: 2001-Jan-15 21:30 By: nascheme Comment: Hmm, I still like pyrl better. What to do about GNU readline now that its in Setup.conf? You can't enable them both and I don't feel comfortable enough with autoconf to fix things. ESR, if you could add the magic to test for termios that would be cool. configure should use readline if its there and fall back to edline if termios is available. Feel free to bounce it back to me if you don't have time. ------------------------------------------------------- Date: 2001-Jan-03 06:10 By: gvanrossum Comment: Neil, this has now status Accepted. Go ahead and check it in! ------------------------------------------------------- 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 Tue Jan 16 10:26:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 02:26:47 -0800 Subject: [Patches] [Patch #103258] Cookie.py docs: example incorrect Message-ID: <E14ITKB-0005K9-00@usw-sf-web1.sourceforge.net> Patch #103258 has been updated. Project: python Category: documentation Status: Open Submitted by: ping Assigned to : nobody Summary: Cookie.py docs: example incorrect ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103258&group_id=5470 From noreply@sourceforge.net Tue Jan 16 10:29:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 02:29:17 -0800 Subject: [Patches] [Patch #103259] Tutorial: Unicode section says UTF-8 is default Message-ID: <E14ITMb-0005LP-00@usw-sf-web1.sourceforge.net> Patch #103259 has been updated. Project: python Category: documentation Status: Open Submitted by: ping Assigned to : nobody Summary: Tutorial: Unicode section says UTF-8 is default ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103259&group_id=5470 From esr@thyrsus.com Tue Jan 16 10:51:46 2001 From: esr@thyrsus.com (Eric S. Raymond) Date: Tue, 16 Jan 2001 05:51:46 -0500 Subject: [Patches] Re: [Patch #102891] Alternative readline module In-Reply-To: <E14ITIX-0007Re-00@usw-sf-web2.sourceforge.net>; from noreply@sourceforge.net on Tue, Jan 16, 2001 at 02:25:05AM -0800 References: <E14ITIX-0007Re-00@usw-sf-web2.sourceforge.net> Message-ID: <20010116055146.B12847@thyrsus.com> noreply@sourceforge.net <noreply@sourceforge.net>: > ESR, if you could add the magic > to test for termios that would be cool. configure should > use readline if its there and fall back to edline if > termios is available. > > Feel free to bounce it back to me if you don't have time. I'm on it. Gotta ship my PC9 paper first, though. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> The right of self-defense is the first law of nature: in most governments it has been the study of rulers to confine this right within the narrowest limits possible. Wherever standing armies are kept up, and when the right of the people to keep and bear arms is, under any color or pretext whatsoever, prohibited, liberty, if not already annihilated, is on the brink of destruction." -- Henry St. George Tucker (in Blackstone's Commentaries) From noreply@sourceforge.net Tue Jan 16 13:41:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 05:41:25 -0800 Subject: [Patches] [Patch #102891] Alternative readline module Message-ID: <E14IWMX-0006UZ-00@usw-sf-web1.sourceforge.net> Patch #102891 has been updated. Project: python Category: Modules Status: Accepted Submitted by: nascheme Assigned to : esr Summary: Alternative readline module Follow-Ups: Date: 2001-Jan-16 05:41 By: gvanrossum Comment: What's pyrl in this context? A Google search turns up a bunch of references to a Perl preprocessor that takes Pythonic syntax and translates it into Perl. :-) [ESR replied Neil via email: "I'm on it. Gotta ship my PC9 paper first, though."] ------------------------------------------------------- Date: 2001-Jan-16 02:23 By: mwh Comment: You could defer the decision between readline and edline until runtime, as in: (will sf mangle this? we'll see) Index: Modules/main.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/main.c,v retrieving revision 1.47 diff -c -r1.47 main.c *** Modules/main.c 2000/12/15 22:00:54 1.47 --- Modules/main.c 2001/01/16 10:19:45 *************** *** 267,274 **** isatty(fileno(stdin))) { PyObject *v; v = PyImport_ImportModule("readline"); ! if (v == NULL) PyErr_Clear(); else Py_DECREF(v); } --- 267,280 ---- isatty(fileno(stdin))) { PyObject *v; v = PyImport_ImportModule("readline"); ! if (v == NULL) { PyErr_Clear(); + v = PyImport_ImportModule("edline"); + if (v == NULL) + PyErr_Clear(); + else + Py_DECREF(v); + } else Py_DECREF(v); } (and pyrl's not going to be ready for 2.1, by a country mile...) ------------------------------------------------------- Date: 2001-Jan-15 21:30 By: nascheme Comment: Hmm, I still like pyrl better. What to do about GNU readline now that its in Setup.conf? You can't enable them both and I don't feel comfortable enough with autoconf to fix things. ESR, if you could add the magic to test for termios that would be cool. configure should use readline if its there and fall back to edline if termios is available. Feel free to bounce it back to me if you don't have time. ------------------------------------------------------- Date: 2001-Jan-03 06:10 By: gvanrossum Comment: Neil, this has now status Accepted. Go ahead and check it in! ------------------------------------------------------- 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 Tue Jan 16 14:21:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 06:21:41 -0800 Subject: [Patches] [Patch #103258] Cookie.py docs: example incorrect Message-ID: <E14IWzV-0000Rz-00@usw-sf-web2.sourceforge.net> Patch #103258 has been updated. Project: python Category: documentation Status: Open Submitted by: ping Assigned to : fdrake Summary: Cookie.py docs: example incorrect ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103258&group_id=5470 From noreply@sourceforge.net Tue Jan 16 14:21:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 06:21:53 -0800 Subject: [Patches] [Patch #103250] Optimize a strspn() out of startup Message-ID: <E14IWzh-0000ST-00@usw-sf-web2.sourceforge.net> Patch #103250 has been updated. Project: python Category: None Status: Open Submitted by: pj99 Assigned to : gvanrossum Summary: Optimize a strspn() out of startup Follow-Ups: Date: 2001-Jan-15 23:25 By: nobody Comment: Why not (isalpha(c) || isdigit(c) || c=='_') ? ------------------------------------------------------- Date: 2001-Jan-15 19:35 By: gvanrossum Comment: Looks cool to me. Do you have an idea what to do about the other 98.5%? :) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103250&group_id=5470 From noreply@sourceforge.net Tue Jan 16 14:22:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 06:22:02 -0800 Subject: [Patches] [Patch #103259] Tutorial: Unicode section says UTF-8 is default Message-ID: <E14IWzq-0000Sb-00@usw-sf-web2.sourceforge.net> Patch #103259 has been updated. Project: python Category: documentation Status: Open Submitted by: ping Assigned to : fdrake Summary: Tutorial: Unicode section says UTF-8 is default ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103259&group_id=5470 From noreply@sourceforge.net Tue Jan 16 14:23:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 06:23:53 -0800 Subject: [Patches] [Patch #103249] fix for bug # 128921 Message-ID: <E14IX1d-0000T5-00@usw-sf-web2.sourceforge.net> Patch #103249 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: mwh Assigned to : lemburg Summary: fix for bug # 128921 Follow-Ups: Date: 2001-Jan-16 06:23 By: gvanrossum Comment: Marc-Andre checked in an extended version of this patch. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103249&group_id=5470 From noreply@sourceforge.net Tue Jan 16 14:34:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 06:34:02 -0800 Subject: [Patches] [Patch #102891] Alternative readline module Message-ID: <E14IXBS-000713-00@usw-sf-web1.sourceforge.net> Patch #102891 has been updated. Project: python Category: Modules Status: Accepted Submitted by: nascheme Assigned to : esr Summary: Alternative readline module Follow-Ups: Date: 2001-Jan-16 06:34 By: mwh Comment: pyrl is my line reader written in Python that I've been intermittently blathering about on python-dev: http://www-jcsu.jesus.cam.ac.uk/~mwh21/hacks/pyrl-0.2.0.tar.gz it's still very experimental, though. ------------------------------------------------------- Date: 2001-Jan-16 05:41 By: gvanrossum Comment: What's pyrl in this context? A Google search turns up a bunch of references to a Perl preprocessor that takes Pythonic syntax and translates it into Perl. :-) [ESR replied Neil via email: "I'm on it. Gotta ship my PC9 paper first, though."] ------------------------------------------------------- Date: 2001-Jan-16 02:23 By: mwh Comment: You could defer the decision between readline and edline until runtime, as in: (will sf mangle this? we'll see) Index: Modules/main.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/main.c,v retrieving revision 1.47 diff -c -r1.47 main.c *** Modules/main.c 2000/12/15 22:00:54 1.47 --- Modules/main.c 2001/01/16 10:19:45 *************** *** 267,274 **** isatty(fileno(stdin))) { PyObject *v; v = PyImport_ImportModule("readline"); ! if (v == NULL) PyErr_Clear(); else Py_DECREF(v); } --- 267,280 ---- isatty(fileno(stdin))) { PyObject *v; v = PyImport_ImportModule("readline"); ! if (v == NULL) { PyErr_Clear(); + v = PyImport_ImportModule("edline"); + if (v == NULL) + PyErr_Clear(); + else + Py_DECREF(v); + } else Py_DECREF(v); } (and pyrl's not going to be ready for 2.1, by a country mile...) ------------------------------------------------------- Date: 2001-Jan-15 21:30 By: nascheme Comment: Hmm, I still like pyrl better. What to do about GNU readline now that its in Setup.conf? You can't enable them both and I don't feel comfortable enough with autoconf to fix things. ESR, if you could add the magic to test for termios that would be cool. configure should use readline if its there and fall back to edline if termios is available. Feel free to bounce it back to me if you don't have time. ------------------------------------------------------- Date: 2001-Jan-03 06:10 By: gvanrossum Comment: Neil, this has now status Accepted. Go ahead and check it in! ------------------------------------------------------- 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 Tue Jan 16 14:59:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 06:59:07 -0800 Subject: [Patches] [Patch #102891] Alternative readline module Message-ID: <E14IXZj-0007Cc-00@usw-sf-web1.sourceforge.net> Patch #102891 has been updated. Project: python Category: Modules Status: Accepted Submitted by: nascheme Assigned to : esr Summary: Alternative readline module Follow-Ups: Date: 2001-Jan-16 06:59 By: gvanrossum Comment: Ah, of course. I saw that, even played with it a bit. Looks cool, but I don't know about using it to replace readline. But you might want to change the name given that pyrl is already taken. ;-) ------------------------------------------------------- Date: 2001-Jan-16 06:34 By: mwh Comment: pyrl is my line reader written in Python that I've been intermittently blathering about on python-dev: http://www-jcsu.jesus.cam.ac.uk/~mwh21/hacks/pyrl-0.2.0.tar.gz it's still very experimental, though. ------------------------------------------------------- Date: 2001-Jan-16 05:41 By: gvanrossum Comment: What's pyrl in this context? A Google search turns up a bunch of references to a Perl preprocessor that takes Pythonic syntax and translates it into Perl. :-) [ESR replied Neil via email: "I'm on it. Gotta ship my PC9 paper first, though."] ------------------------------------------------------- Date: 2001-Jan-16 02:23 By: mwh Comment: You could defer the decision between readline and edline until runtime, as in: (will sf mangle this? we'll see) Index: Modules/main.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/main.c,v retrieving revision 1.47 diff -c -r1.47 main.c *** Modules/main.c 2000/12/15 22:00:54 1.47 --- Modules/main.c 2001/01/16 10:19:45 *************** *** 267,274 **** isatty(fileno(stdin))) { PyObject *v; v = PyImport_ImportModule("readline"); ! if (v == NULL) PyErr_Clear(); else Py_DECREF(v); } --- 267,280 ---- isatty(fileno(stdin))) { PyObject *v; v = PyImport_ImportModule("readline"); ! if (v == NULL) { PyErr_Clear(); + v = PyImport_ImportModule("edline"); + if (v == NULL) + PyErr_Clear(); + else + Py_DECREF(v); + } else Py_DECREF(v); } (and pyrl's not going to be ready for 2.1, by a country mile...) ------------------------------------------------------- Date: 2001-Jan-15 21:30 By: nascheme Comment: Hmm, I still like pyrl better. What to do about GNU readline now that its in Setup.conf? You can't enable them both and I don't feel comfortable enough with autoconf to fix things. ESR, if you could add the magic to test for termios that would be cool. configure should use readline if its there and fall back to edline if termios is available. Feel free to bounce it back to me if you don't have time. ------------------------------------------------------- Date: 2001-Jan-03 06:10 By: gvanrossum Comment: Neil, this has now status Accepted. Go ahead and check it in! ------------------------------------------------------- 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 esr@thyrsus.com Tue Jan 16 15:39:14 2001 From: esr@thyrsus.com (Eric S. Raymond) Date: Tue, 16 Jan 2001 10:39:14 -0500 Subject: [Patches] Re: [Patch #102891] Alternative readline module In-Reply-To: <E14IXBS-000713-00@usw-sf-web1.sourceforge.net>; from noreply@sourceforge.net on Tue, Jan 16, 2001 at 06:34:02AM -0800 References: <E14IXBS-000713-00@usw-sf-web1.sourceforge.net> Message-ID: <20010116103914.A2556@thyrsus.com> > [ESR replied Neil via email: "I'm on it. Gotta ship my PC9 paper first, > though."] It's done. At least the back half, the autoconf/autoheader machinery to test for termios, is now in place. I don't really grok how edline fits into the build, so I haven't tried to write the front half -- but the magic you wanted is there, you can check the value of ac_cv_header_termios_h to see if termios is present. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> What is a magician but a practicing theorist? -- Obi-Wan Kenobi, 'Return of the Jedi' From noreply@sourceforge.net Tue Jan 16 16:01:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 08:01:50 -0800 Subject: [Patches] [Patch #103158] Don't do unsafe arithmetic in xrange object Message-ID: <E14IYYQ-0007bx-00@usw-sf-web1.sourceforge.net> Patch #103158 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: greg_ball Assigned to : gvanrossum Summary: Don't do unsafe arithmetic in xrange object Follow-Ups: Date: 2001-Jan-16 08:01 By: greg_ball Comment: Something for Py3K maybe. Cheers. ------------------------------------------------------- Date: 2001-Jan-15 10:59 By: gvanrossum Comment: I've checked in this version of the patch -- having looked and thought it over for a bit, I agree that this is about as good as we can expect it to do without changing certain internal APIs. Your question about the wisdom of using ints is a good one! In particular it is stupid that PyIntObject holds a long but that the return value from the sq_length function is constrained to be an int. This is from way back when I thought that size_t would never be larger than int. Boy was I wrong. In an ideal world, the int size used for Python ints would be a configuration option, and the configure script would work hard to make it a 64-bit int whenever supported (even on 32-bit platforms). A simpler change would be to simply change the specification for sq_length to return a long, but that's not without problems: existing extensions would have to be recompiled for platforms where int and long aren't the same size (64-bit platforms except Win64). ------------------------------------------------------- Date: 2001-Jan-15 09:10 By: greg_ball Comment: If we only allow lengths that will fit into a C int, x = xrange(sys.maxint) would fail on 64-bit platforms. (and that code is always going to get written by people on 32-bit platforms.) Making some sort of special case for this particular idiom would not make the code simpler, I'm guessing. One obvious simple way to support it is by truncating the length to INT_MAX as is done in _PyEval_SliceIndex. Then len() and negative indexing can produce consistent non-garbage results, if not what the user might naively expect. In Python 2.0, you get garbage. Using my patch, you get an exception. But nobody actually uses those features, in all probability. Of course the natural extension of this approach is to allow any python integer arguments at all to xrange() (which Tim doesn't want to do) and truncate as necessary. But there is no need to go there; we can just leave bltin_xrange alone. As an aside, how important for performance is the use of C ints rather than C longs in the Python internals on 64 bit machines? 16 bit machines? ------------------------------------------------------- Date: 2001-Jan-12 12:11 By: greg_ball Comment: The new version of the patch makes the code a bit less complicated. (Only error messages have changed in terms of behaviour; regression test run under linux and OSF1.) If it looks ok you can ignore the rest of this comment... I originally made totlen an int because it is the return value from range_length, and the argument to PyList_New(). The current patch makes totlen a long, but the ocde doesn't get hugely less complicated. The code would get simpler if it rejected objects whose length doesn't fit into a int, but that seemed too easy and there is a small chance someone's code might break. On the other hand by rejecting objects whose stop can't be correctly calculated, I _might_ have broken code already. Break just means "now raises exception" though, nothing insidious. ------------------------------------------------------- Date: 2001-Jan-12 12:58 By: tim_one Comment: I'm aware of people who actually do x = xrange(sys.maxint) and that should continue to work. Python 2.0 already complains about more than that: >>> xrange(-1, sys.maxint) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange() has more than sys.maxint items >>> and I sure don't want to see that extended (unless it's part of a *sweeping* crusade to eradicate the visibile differences between ints and longs). ------------------------------------------------------- Date: 2001-Jan-12 12:44 By: gvanrossum Comment: In theory, there's a use for objects whose length doesn't fit in an int: for i in xrange(...) is routinely used for loops that expect to break well before the end but don't want to give an arbitrary upper bound. But I agree with Tim that this serves no real purpose. I think that if anything, the xrange() object should be scaled down. No repetition, no concationation, no slicing. the only real use ought to be "for i in xrange(...)". But of course, *that* is bound to break somebody's code somewhere. So let's not go there. But let's not complicate it any further. Prevent breakage, but don't stretch the functionality beyond what it currently does. ------------------------------------------------------- Date: 2001-Jan-12 12:35 By: tim_one Comment: Please do reject objects whose length doesn't fit into an int. I'll bet a dollar that no real code in the world will break as a result. I feel confident making that bet, because if someone's code *does* break as a result, it's worth a dollar to me to see Guido lecture them that their code was already broken <wink>. Really, it's very Pythonic to gripe about a problem just as soon as it crops up. It's not doing anyone a favor to delay griping until the object is used: at that point, it may be very difficult to figure out how the object *got* damaged. There's simply no payback in allowing creation of an unusable xrange object, and, as you say, life is simpler if you don't allow it. ------------------------------------------------------- Date: 2001-Jan-10 10:28 By: gvanrossum Comment: I wonder why you made totlen an int. This seems to complicate the code quite a bit. I'd suggest making it a long. Then you have to test whether it's > INT_MAX only in tolist() -- in that case you should raise MemoryError. Other than that, it looks decent! ------------------------------------------------------- Date: 2001-Jan-09 06:31 By: greg_ball Comment: This is a replacement for patch 103129, as suggested by tim_one. Possibly interesting aspects of the patch: - xrange objects with overflowing lengths are not gratutiously rejected. An error is raised only if the length becomes relevant, under len() or negative indexing. Bad lengths are stored as -1. Objects with bad lengths allow any non-negative integer index. - On 64 bit platforms, sequence multiplication seems to cause an unsafe cast from long to int. This patch does not address that issue. Without my patch, on i686 Linux: Python 2.0 (#25, Jan 2 2001, 12:18:07) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> y = xrange(maxint/2)*3 >>> len(y) -1073741827 >>> y[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> y.tolist() Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: listobject.c:33: bad argument to internal function >>> m = maxint >> 16 >>> xrange(0,maxint,m) xrange(0, -2147450883, 32767) >>> (xrange(1)*maxint)*maxint xrange(1) >>> With my patch Python 2.0 (#35, Jan 6 2001, 12:54:41) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> y = xrange(maxint/2)*3 >>> len(y) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> y.tolist() Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> m = maxint >> 16 >>> xrange(0,maxint,m) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer addition >>> (xrange(1)*maxint) * maxint Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer multiplication >>> Without patch on Digital Unix Python 2.0 (#5, Jan 6 2001, 15:42:58) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> xrange(0,maxint,m) xrange(0, -9223372034707292163, 2147483647) >>> xrange(1)*maxint xrange(0) >>> With patch Python 2.0 (#7, Jan 6 2001, 15:52:21) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> xrange(0,maxint,m) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer addition >>> xrange(1)*maxint xrange(0) >>> ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103158&group_id=5470 From mwh21@cam.ac.uk Tue Jan 16 16:55:43 2001 From: mwh21@cam.ac.uk (Michael Hudson) Date: 16 Jan 2001 16:55:43 +0000 Subject: [Patches] [Patch #102891] Alternative readline module In-Reply-To: noreply@sourceforge.net's message of "Tue, 16 Jan 2001 06:59:07 -0800" References: <E14IXZj-0007Cc-00@usw-sf-web1.sourceforge.net> Message-ID: <m366jf4esw.fsf@atrus.jesus.cam.ac.uk> noreply@sourceforge.net writes: > Ah, of course. I saw that, even played with it a bit. I saw that *someone* had downloaded it from a *.reston1.va.home.com address... > Looks cool, but I don't know about using it to replace readline. No, neither do I. But it might be nice to have sufficient hooks in the core to allow a sufficiently enterprising user to replace readline with it. > But you might want to change the name given that pyrl is already > taken. ;-) >From http://www.amk.ca/quotations/python-quotes.html: I would recommend not wasting any more time on the naming issue. (This is a recurring theme in my posts -- remember, I spent about 0.3 microseconds thinking about whether "Python" would be a good name for a programming language, and I've never regretted it.) Guido van Rossum, 25 Nov 1998 I'll give you 0.2 microseconds :-) But, yes. Anyone have any ideas? (or I'll just call it pyttyinput) Cheers, M. From noreply@sourceforge.net Tue Jan 16 18:51:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 10:51:02 -0800 Subject: [Patches] [Patch #103265] Let time functions default to 'now' (where it makes sense) Message-ID: <E14IbCA-0002ID-00@usw-sf-web2.sourceforge.net> Patch #103265 has been updated. Project: python Category: Modules Status: Open Submitted by: twouters Assigned to : nobody Summary: Let time functions default to 'now' (where it makes sense) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103265&group_id=5470 From guido@python.org Tue Jan 16 20:37:44 2001 From: guido@python.org (Guido van Rossum) Date: Tue, 16 Jan 2001 15:37:44 -0500 Subject: [Patches] [Patch #102891] Alternative readline module In-Reply-To: Your message of "16 Jan 2001 16:55:43 GMT." <m366jf4esw.fsf@atrus.jesus.cam.ac.uk> References: <E14IXZj-0007Cc-00@usw-sf-web1.sourceforge.net> <m366jf4esw.fsf@atrus.jesus.cam.ac.uk> Message-ID: <200101162037.PAA10721@cj20424-a.reston1.va.home.com> > > Ah, of course. I saw that, even played with it a bit. > > I saw that *someone* had downloaded it from a *.reston1.va.home.com > address... Could've been Fred or Tim... > > Looks cool, but I don't know about using it to replace readline. > > No, neither do I. But it might be nice to have sufficient hooks in > the core to allow a sufficiently enterprising user to replace readline > with it. A hook exists: you can assign a readline-ish function to PyOS_ReadlineFunctionPointer. > > But you might want to change the name given that pyrl is already > > taken. ;-) > > >From http://www.amk.ca/quotations/python-quotes.html: > > I would recommend not wasting any more time on the naming > issue. (This is a recurring theme in my posts -- remember, I spent > about 0.3 microseconds thinking about whether "Python" would be a > good name for a programming language, and I've never regretted it.) > Guido van Rossum, 25 Nov 1998 > > I'll give you 0.2 microseconds :-) > > But, yes. Anyone have any ideas? (or I'll just call it pyttyinput) Not me, I wasted my 0.2 usec on Python :-). Note that the patches list doesn't have much of a readership. --Guido van Rossum (home page: http://www.python.org/~guido/) From nas@arctrix.com Tue Jan 16 14:09:45 2001 From: nas@arctrix.com (Neil Schemenauer) Date: Tue, 16 Jan 2001 06:09:45 -0800 Subject: [Patches] [Patch #102891] Alternative readline module In-Reply-To: <200101162037.PAA10721@cj20424-a.reston1.va.home.com>; from guido@python.org on Tue, Jan 16, 2001 at 03:37:44PM -0500 References: <E14IXZj-0007Cc-00@usw-sf-web1.sourceforge.net> <m366jf4esw.fsf@atrus.jesus.cam.ac.uk> <200101162037.PAA10721@cj20424-a.reston1.va.home.com> Message-ID: <20010116060945.A8505@glacier.fnational.com> On Tue, Jan 16, 2001 at 03:37:44PM -0500, Guido van Rossum wrote: > A hook exists: you can assign a readline-ish function to > PyOS_ReadlineFunctionPointer. You can't do that from within Python code though, can you? Although pyrl is not nearly ready for the prime time, I think the general approach is a good one long term. Command line editing is not a performance critical task. Python code is fast enough. Moving this task to Python should allow the editor to be made cross platform more easily. Also, it should be easier to add more advanced features. I would like the editor to work like the Z shell editor in that you can edit whole blocks. For example, if I enter: for i in range(10): print i and press up arrow I would be able to edit the whole for loop as a block. > Note that the patches list doesn't have much of a readership. I'm still here. :-) Neil From noreply@sourceforge.net Tue Jan 16 21:28:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 13:28:24 -0800 Subject: [Patches] [Patch #103276] zipfile.py - file header size calculation fixed Message-ID: <E14IdeS-0001Ao-00@usw-sf-web1.sourceforge.net> Patch #103276 has been updated. Project: python Category: None Status: Open Submitted by: snejsource Assigned to : nobody Summary: zipfile.py - file header size calculation fixed ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103276&group_id=5470 From noreply@sourceforge.net Tue Jan 16 21:36:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 13:36:24 -0800 Subject: [Patches] [Patch #103252] Startup optimize: read *.pyc as string, not with getc() Message-ID: <E14IdmC-0003JI-00@usw-sf-web2.sourceforge.net> Patch #103252 has been updated. Project: python Category: core (C code) Status: Open Submitted by: pj99 Assigned to : tim_one Summary: Startup optimize: read *.pyc as string, not with getc() Follow-Ups: Date: 2001-Jan-16 13:36 By: pj99 Comment: No problem, Tim (on the alledged abruptness). In any case, it was useful - in that it helped motivate /f into proposing a fix, me into coding it, and you to consider applying it. All in all a useful result. Most thanks, Tim. ------------------------------------------------------- Date: 2001-Jan-15 20:26 By: tim_one Comment: Indeed, IDLE takes more than a full second to come up on my box, *much* longer than Notepad. Now that we have a clear goal, I assigned this patch to me <wink>. (OK, it's really that I was abrupt with Paul when this came up on c.l.py, and left him hanging there -- I owe him on this one). ------------------------------------------------------- Date: 2001-Jan-15 20:18 By: gvanrossum Comment: Oh, but I do care about the load time of Tkinter. :-) Anything to keep IDLE ahead of Komodo in the race. :-) ------------------------------------------------------- Date: 2001-Jan-15 20:05 By: tim_one Comment: I like the idea, but gimmicks like this make porting to tiny platforms harder when pushed "too far". People concerned about startup time seem mostly to deal with apps that e.g. fire up Python 1000s of times from shell scripts or cgi. They're not going to care about monster modules (like Tkinter and grail). So I think Paul's original 64K is a good compromise. ------------------------------------------------------- Date: 2001-Jan-15 19:39 By: gvanrossum Comment: Not a bad idea. I'd up the limit to 256K so Tkinter.pyc (comfortably) fits. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103252&group_id=5470 From noreply@sourceforge.net Tue Jan 16 22:28:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 14:28:28 -0800 Subject: [Patches] [Patch #103250] Optimize a strspn() out of startup Message-ID: <E14Ieaa-0001WU-00@usw-sf-web1.sourceforge.net> Patch #103250 has been updated. Project: python Category: None Status: Open Submitted by: pj99 Assigned to : gvanrossum Summary: Optimize a strspn() out of startup Follow-Ups: Date: 2001-Jan-16 14:28 By: pj99 Comment: The (isalpha(c) || isdigit(c) || c=='_') suggestion seems to me to be the better idea. However, how does this interact with localization and unicode and such? Do we want exactly the list of specified NAME_CHARS allowed here, or do we want a localized set of alpha/digit/'_' chars allowed here? As for the other 98.5%, I have a nice table from my profiler, showing where the time is, but I don't know how to put that table here, without mangling the format. It shows about 19% of the time in malloc/free, about 15% of the time in pthread code, about 14% in dictobject.c code, and about 6% in acceler.c code (esp. fixstate()). And of course the getc() savings that come from loading an entire *.pyc file in a single fread(), as being persued in patch 103252, saves perhaps 24% of what's left. (Note, the 19,15,14 and 6 percents above are based on what's left, _after_ the 24% getc() optimization is applied). *If* much of the malloc/free use is for lots of small chunks, coming and going, as tends to happen with object based code, then I could imagine a custom allocator (based on top of malloc/free, so quite portable). This might save much of the pthread cost as well, if the custom allocator kept separate pools of small chunks of malloc'd memory, per thread, avoiding locks (if that can be done ?). I have done work in the past in a C++/mmap environment that reduced the costs of many small dynamic allocations to near zero, both space and time. But that relied on the second argument to C++ delete(), which is the size of the object being deleted, as well as on an AUTOGROW mmap region. This is not applicable to C, nor is it particularly portable. Still, something like this, perhaps requiring recoding of some critical free() calls to use an optional method that passed in a second sizeof argument, might be the next most useful optimization. Someone else in the news thread that was parent to this patch suggested emacs-like dump facility, to capture the state of the Python interpreter after it has loaded the usual suspects. But I can't imagine that this would be sufficiently portable or maintainable to be relevant. As someone who has had to maintain O.S./library support for and compatibility with this emacs dump facility, I have grown to dislike it strongly. ------------------------------------------------------- Date: 2001-Jan-15 23:25 By: nobody Comment: Why not (isalpha(c) || isdigit(c) || c=='_') ? ------------------------------------------------------- Date: 2001-Jan-15 19:35 By: gvanrossum Comment: Looks cool to me. Do you have an idea what to do about the other 98.5%? :) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103250&group_id=5470 From noreply@sourceforge.net Tue Jan 16 22:53:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 14:53:31 -0800 Subject: [Patches] [Patch #102588] PEP 229: Use Distutils to build Message-ID: <E14Ieyp-00038V-00@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: 2001-Jan-16 14:53 By: akuchling Comment: I've made an updated version of the patch; because it's 55K, SF won't accept it, so I've put it at http://www.mems-exchange.org/software/files/python/pep229.patch. There are only a very few things left to fix at this point: * setup.cfg hard-wires the installation directory because it has no access to a variable holding the installation prefix * installs in subdirectories don't work because setup.cfg is only found in the current directory. I think those are the only two remaining issues before this can be checked in (doubtless causing the sun to explode). ------------------------------------------------------- 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 Tue Jan 16 23:06:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 15:06:26 -0800 Subject: [Patches] [Patch #103277] Enables a package to have more than one source dir Message-ID: <E14IfBK-0003DI-00@usw-sf-web3.sourceforge.net> Patch #103277 has been updated. Project: python Category: distutils Status: Open Submitted by: nobody Assigned to : nobody Summary: Enables a package to have more than one source dir ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103277&group_id=5470 From guido@python.org Tue Jan 16 23:35:20 2001 From: guido@python.org (Guido van Rossum) Date: Tue, 16 Jan 2001 18:35:20 -0500 Subject: [Patches] [Patch #102891] Alternative readline module In-Reply-To: Your message of "Tue, 16 Jan 2001 06:09:45 PST." <20010116060945.A8505@glacier.fnational.com> References: <E14IXZj-0007Cc-00@usw-sf-web1.sourceforge.net> <m366jf4esw.fsf@atrus.jesus.cam.ac.uk> <200101162037.PAA10721@cj20424-a.reston1.va.home.com> <20010116060945.A8505@glacier.fnational.com> Message-ID: <200101162335.SAA16622@cj20424-a.reston1.va.home.com> > On Tue, Jan 16, 2001 at 03:37:44PM -0500, Guido van Rossum wrote: > > A hook exists: you can assign a readline-ish function to > > PyOS_ReadlineFunctionPointer. > > You can't do that from within Python code though, can you? No, but you could easily write a little extension that sets it to a C function that can call an arbitrary Python code. (Just realize that it's called without the Python global interpreter lock held.) > Although pyrl is not nearly ready for the prime time, I think the > general approach is a good one long term. Command line editing > is not a performance critical task. Python code is fast enough. > Moving this task to Python should allow the editor to be made > cross platform more easily. Sadly, this isn't the case -- pyrl uses curses and/or termios calls that are highly Unix specific. :-) > Also, it should be easier to add > more advanced features. I would like the editor to work like the > Z shell editor in that you can edit whole blocks. For example, > if I enter: > > for i in range(10): > print i > > and press up arrow I would be able to edit the whole for loop as > a block. Just use IDLE -- it has all that. Character cell interfaces aren't worth the effort of keeping up. --Guido van Rossum (home page: http://www.python.org/~guido/) From skip@mojam.com (Skip Montanaro) Wed Jan 17 00:06:52 2001 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 16 Jan 2001 18:06:52 -0600 (CST) Subject: [Patches] [Patch #102891] Alternative readline module In-Reply-To: <200101162335.SAA16622@cj20424-a.reston1.va.home.com> References: <E14IXZj-0007Cc-00@usw-sf-web1.sourceforge.net> <m366jf4esw.fsf@atrus.jesus.cam.ac.uk> <200101162037.PAA10721@cj20424-a.reston1.va.home.com> <20010116060945.A8505@glacier.fnational.com> <200101162335.SAA16622@cj20424-a.reston1.va.home.com> Message-ID: <14948.57884.434679.220050@beluga.mojam.com> >> and press up arrow I would be able to edit the whole for loop as a >> block. Guido> Just use IDLE -- it has all that. Character cell interfaces Guido> aren't worth the effort of keeping up. Hey! I resemble that remark! I still just use the bare interpreter for all my interactive twiddlings and wouldn't turn my nose up at more sophisticated history recall/editing. Starts up a heckuva lot faster than IDLE. Skip From mwh21@cam.ac.uk Wed Jan 17 00:09:58 2001 From: mwh21@cam.ac.uk (Michael Hudson) Date: 17 Jan 2001 00:09:58 +0000 Subject: [Patches] [Patch #102891] Alternative readline module In-Reply-To: Guido van Rossum's message of "Tue, 16 Jan 2001 18:35:20 -0500" References: <E14IXZj-0007Cc-00@usw-sf-web1.sourceforge.net> <m366jf4esw.fsf@atrus.jesus.cam.ac.uk> <200101162037.PAA10721@cj20424-a.reston1.va.home.com> <20010116060945.A8505@glacier.fnational.com> <200101162335.SAA16622@cj20424-a.reston1.va.home.com> Message-ID: <m3snmj2g4p.fsf@atrus.jesus.cam.ac.uk> This is a really silly place to be having this discussion, isn't it? Oh well. I might create an sf project when sf isn't broken any more... Guido van Rossum <guido@python.org> writes: > > Although pyrl is not nearly ready for the prime time, I think the > > general approach is a good one long term. Command line editing > > is not a performance critical task. Python code is fast enough. > > Moving this task to Python should allow the editor to be made > > cross platform more easily. > > Sadly, this isn't the case -- pyrl uses curses and/or termios calls > that are highly Unix specific. :-) Actually one could probably rewrite the bottom layer to use /F's Console library without too much sweat. Currently my code is also highly tty dependent - it dies horribly if you try to use it inside emacs, for example. > > Also, it should be easier to add > > more advanced features. I would like the editor to work like the > > Z shell editor in that you can edit whole blocks. For example, > > if I enter: > > > > for i in range(10): > > print i > > > > and press up arrow I would be able to edit the whole for loop as > > a block. This works in pyrl today! It was, in fact, one of my main motivations for writing pyrl. > Just use IDLE -- it has all that. Character cell interfaces aren't > worth the effort of keeping up. Well, I like them, and if I'm prepared to put the effort into writing one, that's all it takes, isn't it? I don't necessarily expect people to understand me... Cheers, M. From guido@python.org Wed Jan 17 00:17:02 2001 From: guido@python.org (Guido van Rossum) Date: Tue, 16 Jan 2001 19:17:02 -0500 Subject: [Patches] [Patch #102891] Alternative readline module In-Reply-To: Your message of "Tue, 16 Jan 2001 18:06:52 CST." <14948.57884.434679.220050@beluga.mojam.com> References: <E14IXZj-0007Cc-00@usw-sf-web1.sourceforge.net> <m366jf4esw.fsf@atrus.jesus.cam.ac.uk> <200101162037.PAA10721@cj20424-a.reston1.va.home.com> <20010116060945.A8505@glacier.fnational.com> <200101162335.SAA16622@cj20424-a.reston1.va.home.com> <14948.57884.434679.220050@beluga.mojam.com> Message-ID: <200101170017.TAA17059@cj20424-a.reston1.va.home.com> > Hey! I resemble that remark! I still just use the bare interpreter for all > my interactive twiddlings and wouldn't turn my nose up at more sophisticated > history recall/editing. Starts up a heckuva lot faster than IDLE. Me too (on Unix). But GNU readline does everything I need, and the price is right. (The GPL license worries will soon be resolved -- CNRI and the FSF have reached an agreement on changes to the 1.6 license.) --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Wed Jan 17 00:27:41 2001 From: guido@python.org (Guido van Rossum) Date: Tue, 16 Jan 2001 19:27:41 -0500 Subject: [Patches] [Patch #102891] Alternative readline module In-Reply-To: Your message of "17 Jan 2001 00:09:58 GMT." <m3snmj2g4p.fsf@atrus.jesus.cam.ac.uk> References: <E14IXZj-0007Cc-00@usw-sf-web1.sourceforge.net> <m366jf4esw.fsf@atrus.jesus.cam.ac.uk> <200101162037.PAA10721@cj20424-a.reston1.va.home.com> <20010116060945.A8505@glacier.fnational.com> <200101162335.SAA16622@cj20424-a.reston1.va.home.com> <m3snmj2g4p.fsf@atrus.jesus.cam.ac.uk> Message-ID: <200101170027.TAA17107@cj20424-a.reston1.va.home.com> > > Sadly, this isn't the case -- pyrl uses curses and/or termios calls > > that are highly Unix specific. :-) > > Actually one could probably rewrite the bottom layer to use /F's > Console library without too much sweat. Currently my code is also > highly tty dependent - it dies horribly if you try to use it inside > emacs, for example. I believe that everything /F's console library does is also done by the classes in the standard code module! Check it out... (Even IDLE uses that, and it's future-proof.) > > Just use IDLE -- it has all that. Character cell interfaces aren't > > worth the effort of keeping up. > > Well, I like them, and if I'm prepared to put the effort into writing > one, that's all it takes, isn't it? I don't necessarily expect people > to understand me... Of course. I don't want to discourage you. But I also don't want to be pressured into adopting your code into the core. --Guido van Rossum (home page: http://www.python.org/~guido/) From tim.one@home.com Wed Jan 17 00:42:51 2001 From: tim.one@home.com (Tim Peters) Date: Tue, 16 Jan 2001 19:42:51 -0500 Subject: [Patches] [Patch #102891] Alternative readline module In-Reply-To: <m3snmj2g4p.fsf@atrus.jesus.cam.ac.uk> Message-ID: <LNBBLJKPBEHFEDALKOLCIEBMIJAA.tim.one@home.com> [Michael Hudson] > This is a really silly place to be having this discussion, isn't it? That's because we just turned off the patches reply-to to python-dev. It was predicted that people would be careful to type in python-dev themselves when it was warranted <snort>. but-better-in-one-wrong-forum-than-in-random-xposting-among-three-ly y'rs - tim From guido@python.org Wed Jan 17 00:50:40 2001 From: guido@python.org (Guido van Rossum) Date: Tue, 16 Jan 2001 19:50:40 -0500 Subject: [Patches] [Patch #102891] Alternative readline module In-Reply-To: Your message of "Tue, 16 Jan 2001 19:42:51 EST." <LNBBLJKPBEHFEDALKOLCIEBMIJAA.tim.one@home.com> References: <LNBBLJKPBEHFEDALKOLCIEBMIJAA.tim.one@home.com> Message-ID: <200101170050.TAA17404@cj20424-a.reston1.va.home.com> > [Michael Hudson] > > This is a really silly place to be having this discussion, isn't it? [Tim] > That's because we just turned off the patches reply-to to python-dev. It > was predicted that people would be careful to type in python-dev themselves > when it was warranted <snort>. Not so quick! That's not the origin of *this* thread. AFAICT it started when Eric Raymond followed up to a message from SourceForge in the patches list. The patches list wasn't affected by the reply-to change, AFAIK -- only the python-checkin list was. --Guido van Rossum (home page: http://www.python.org/~guido/) From tim.one@home.com Wed Jan 17 01:05:25 2001 From: tim.one@home.com (Tim Peters) Date: Tue, 16 Jan 2001 20:05:25 -0500 Subject: [Patches] [Patch #102891] Alternative readline module In-Reply-To: <200101170050.TAA17404@cj20424-a.reston1.va.home.com> Message-ID: <LNBBLJKPBEHFEDALKOLCAEBOIJAA.tim.one@home.com> [Tim] > That's because we just turned off the patches reply-to to python-dev ... [Guido] > Not so quick! ...[and explains]... OK, I'll save it and repost it when the first reply gets made to the checkin list <wink>. From noreply@sourceforge.net Wed Jan 17 01:51:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 17:51:34 -0800 Subject: [Patches] [Patch #103279] Flag for making sysconfig assume build directories Message-ID: <E14Ihl8-00040x-00@usw-sf-web3.sourceforge.net> Patch #103279 has been updated. Project: python Category: distutils Status: Open Submitted by: akuchling Assigned to : nobody Summary: Flag for making sysconfig assume build directories ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103279&group_id=5470 From noreply@sourceforge.net Wed Jan 17 01:54:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 17:54:02 -0800 Subject: [Patches] [Patch #103279] Flag for making sysconfig assume build directories Message-ID: <E14IhnW-000420-00@usw-sf-web3.sourceforge.net> Patch #103279 has been updated. Project: python Category: distutils Status: Open Submitted by: akuchling Assigned to : gward Summary: Flag for making sysconfig assume build directories ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103279&group_id=5470 From noreply@sourceforge.net Wed Jan 17 03:14:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 19:14:32 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14Ij3Q-000561-00@usw-sf-web2.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : loewis Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-16 19:14 By: fdrake Comment: I'm not entirely sure why one would want weak keys rather than weak values, but I suspect it has to do with expectations of how the dict will be used in applications. I don't think it would be hard to support both flavors of dictionaries using the primitive reference objects. The constructor does not check that all incoming values are weak because that isn't required. It uses self.update() rather than self.data.update() to perform the inclusion, so any mapping that supports .keys() and .__getitem__() is sufficient. Some additional checking could be done to make sure that all added entries can be created before inserting any of them, offering more atomicity. .get() will be fixed in the next version of the patch; thanks! I've added GC support, but don't have it working quite right. I'm trying to isolate the failure now. ------------------------------------------------------- Date: 2001-Jan-12 14:36 By: loewis Comment: The weak dictionary data type needs more clarification in documentation and implementation. In java.util.WeakHashMap, they keys are weak, not the values (i.e. once the key is forgotten, the entry is cleared). In http://www.handshake.de/~dieter/weakdict.html, the values are weak, but it raises KeyErrors for entries that are collected. The initializer of a weak dict does not check the invariant (all values are weak). get() of a weakdict does not support an optional second parameter. weakref and friends need to participate in garbage collection, as the reference to the callback can create a cycle. ------------------------------------------------------- Date: 2001-Jan-12 11:27 By: fdrake Comment: Updated patch to also support proxy semantics using the same invalidation machinery as the basic weak reference type. The additional code is *heavily* borrowed from Neil Schemenauer. ------------------------------------------------------- Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Wed Jan 17 03:39:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 19:39:59 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14IjS3-00035k-00@usw-sf-web1.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : loewis Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-16 19:39 By: tim_one Comment: Just mentioning a general scenario in which weak keys are the bee's knees: sometimes you want to add attributes to objects dynamically, in ways the original class author(s -- may cut across many classes! even non-instance objects; or objects from extension modules that don't support setattr) never anticipated. Like maybe a German translation of the object's docstrings; or a list of JPEG contents referenced by a URLish object; or a table of usage statistics on methods and functions; etc. Then it's natural to use the conceptual attr name as the name of a dict instead, and write attr[object] = whatever instead of object.attr = whatever There's no point keeping the "whatever" around when the object goes away, but a regular dict makes the object and its "whatever" immortal. A dict with weak keys is exactly on-target. ------------------------------------------------------- Date: 2001-Jan-16 19:14 By: fdrake Comment: I'm not entirely sure why one would want weak keys rather than weak values, but I suspect it has to do with expectations of how the dict will be used in applications. I don't think it would be hard to support both flavors of dictionaries using the primitive reference objects. The constructor does not check that all incoming values are weak because that isn't required. It uses self.update() rather than self.data.update() to perform the inclusion, so any mapping that supports .keys() and .__getitem__() is sufficient. Some additional checking could be done to make sure that all added entries can be created before inserting any of them, offering more atomicity. .get() will be fixed in the next version of the patch; thanks! I've added GC support, but don't have it working quite right. I'm trying to isolate the failure now. ------------------------------------------------------- Date: 2001-Jan-12 14:36 By: loewis Comment: The weak dictionary data type needs more clarification in documentation and implementation. In java.util.WeakHashMap, they keys are weak, not the values (i.e. once the key is forgotten, the entry is cleared). In http://www.handshake.de/~dieter/weakdict.html, the values are weak, but it raises KeyErrors for entries that are collected. The initializer of a weak dict does not check the invariant (all values are weak). get() of a weakdict does not support an optional second parameter. weakref and friends need to participate in garbage collection, as the reference to the callback can create a cycle. ------------------------------------------------------- Date: 2001-Jan-12 11:27 By: fdrake Comment: Updated patch to also support proxy semantics using the same invalidation machinery as the basic weak reference type. The additional code is *heavily* borrowed from Neil Schemenauer. ------------------------------------------------------- Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Wed Jan 17 04:20:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 20:20:46 -0800 Subject: [Patches] [Patch #103283] Rich comparisons technical preview Message-ID: <E14Ik5W-0004ht-00@usw-sf-web3.sourceforge.net> Patch #103283 has been updated. Project: python Category: core (C code) Status: Open Submitted by: gvanrossum Assigned to : nobody Summary: Rich comparisons technical preview ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103283&group_id=5470 From noreply@sourceforge.net Wed Jan 17 04:24:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 20:24:25 -0800 Subject: [Patches] [Patch #103283] Rich comparisons technical preview Message-ID: <E14Ik93-0003IH-00@usw-sf-web1.sourceforge.net> Patch #103283 has been updated. Project: python Category: core (C code) Status: Open Submitted by: gvanrossum Assigned to : gvanrossum Summary: Rich comparisons technical preview ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103283&group_id=5470 From noreply@sourceforge.net Wed Jan 17 04:24:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 20:24:59 -0800 Subject: [Patches] [Patch #103277] Enables a package to have more than one source dir Message-ID: <E14Ik9b-0003IV-00@usw-sf-web1.sourceforge.net> Patch #103277 has been updated. Project: python Category: distutils Status: Open Submitted by: nobody Assigned to : akuchling Summary: Enables a package to have more than one source dir ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103277&group_id=5470 From noreply@sourceforge.net Wed Jan 17 04:29:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 20:29:42 -0800 Subject: [Patches] [Patch #103265] Let time functions default to 'now' (where it makes sense) Message-ID: <E14IkEA-0005SW-00@usw-sf-web2.sourceforge.net> Patch #103265 has been updated. Project: python Category: Modules Status: Open Submitted by: twouters Assigned to : twouters Summary: Let time functions default to 'now' (where it makes sense) Follow-Ups: Date: 2001-Jan-16 20:29 By: gvanrossum Comment: How hard would it be to avoid calling floattime() when an argument is present (in gmtime() and localtime())? Missing: docs, NEWS item. Otherwise, great -- ready to check in if you fix the above things! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103265&group_id=5470 From noreply@sourceforge.net Wed Jan 17 04:31:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 20:31:06 -0800 Subject: [Patches] [Patch #103276] zipfile.py - file header size calculation fixed Message-ID: <E14IkFW-0005TE-00@usw-sf-web2.sourceforge.net> Patch #103276 has been updated. Project: python Category: library Status: Open Submitted by: snejsource Assigned to : fdrake Summary: zipfile.py - file header size calculation fixed Follow-Ups: Date: 2001-Jan-16 20:31 By: gvanrossum Comment: Assigned to Fred. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103276&group_id=5470 From noreply@sourceforge.net Wed Jan 17 05:33:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 21:33:06 -0800 Subject: [Patches] [Patch #103250] Optimize a strspn() out of startup Message-ID: <E14IlDW-0005ln-00@usw-sf-web2.sourceforge.net> Patch #103250 has been updated. Project: python Category: None Status: Open Submitted by: pj99 Assigned to : gvanrossum Summary: Optimize a strspn() out of startup Follow-Ups: Date: 2001-Jan-16 21:33 By: nobody Comment: At least the Python tokenizer uses (isalnum(c) || c == '_') ... ------------------------------------------------------- Date: 2001-Jan-16 14:28 By: pj99 Comment: The (isalpha(c) || isdigit(c) || c=='_') suggestion seems to me to be the better idea. However, how does this interact with localization and unicode and such? Do we want exactly the list of specified NAME_CHARS allowed here, or do we want a localized set of alpha/digit/'_' chars allowed here? As for the other 98.5%, I have a nice table from my profiler, showing where the time is, but I don't know how to put that table here, without mangling the format. It shows about 19% of the time in malloc/free, about 15% of the time in pthread code, about 14% in dictobject.c code, and about 6% in acceler.c code (esp. fixstate()). And of course the getc() savings that come from loading an entire *.pyc file in a single fread(), as being persued in patch 103252, saves perhaps 24% of what's left. (Note, the 19,15,14 and 6 percents above are based on what's left, _after_ the 24% getc() optimization is applied). *If* much of the malloc/free use is for lots of small chunks, coming and going, as tends to happen with object based code, then I could imagine a custom allocator (based on top of malloc/free, so quite portable). This might save much of the pthread cost as well, if the custom allocator kept separate pools of small chunks of malloc'd memory, per thread, avoiding locks (if that can be done ?). I have done work in the past in a C++/mmap environment that reduced the costs of many small dynamic allocations to near zero, both space and time. But that relied on the second argument to C++ delete(), which is the size of the object being deleted, as well as on an AUTOGROW mmap region. This is not applicable to C, nor is it particularly portable. Still, something like this, perhaps requiring recoding of some critical free() calls to use an optional method that passed in a second sizeof argument, might be the next most useful optimization. Someone else in the news thread that was parent to this patch suggested emacs-like dump facility, to capture the state of the Python interpreter after it has loaded the usual suspects. But I can't imagine that this would be sufficiently portable or maintainable to be relevant. As someone who has had to maintain O.S./library support for and compatibility with this emacs dump facility, I have grown to dislike it strongly. ------------------------------------------------------- Date: 2001-Jan-15 23:25 By: nobody Comment: Why not (isalpha(c) || isdigit(c) || c=='_') ? ------------------------------------------------------- Date: 2001-Jan-15 19:35 By: gvanrossum Comment: Looks cool to me. Do you have an idea what to do about the other 98.5%? :) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103250&group_id=5470 From noreply@sourceforge.net Wed Jan 17 05:35:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 21:35:07 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14IlFT-0005mP-00@usw-sf-web2.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : nascheme Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-16 21:35 By: fdrake Comment: Added a new (but broken!) version of the patch that fixes WeakDictionary.get() but doesn't interact properly with GC (appearantly) -- not usable as is: http://starship.python.net/crew/fdrake/patches/weakref.patch-3 Neil made the mistake of volunteering to look at the current problem, so assigning to him. (Thanks!) ------------------------------------------------------- Date: 2001-Jan-16 19:39 By: tim_one Comment: Just mentioning a general scenario in which weak keys are the bee's knees: sometimes you want to add attributes to objects dynamically, in ways the original class author(s -- may cut across many classes! even non-instance objects; or objects from extension modules that don't support setattr) never anticipated. Like maybe a German translation of the object's docstrings; or a list of JPEG contents referenced by a URLish object; or a table of usage statistics on methods and functions; etc. Then it's natural to use the conceptual attr name as the name of a dict instead, and write attr[object] = whatever instead of object.attr = whatever There's no point keeping the "whatever" around when the object goes away, but a regular dict makes the object and its "whatever" immortal. A dict with weak keys is exactly on-target. ------------------------------------------------------- Date: 2001-Jan-16 19:14 By: fdrake Comment: I'm not entirely sure why one would want weak keys rather than weak values, but I suspect it has to do with expectations of how the dict will be used in applications. I don't think it would be hard to support both flavors of dictionaries using the primitive reference objects. The constructor does not check that all incoming values are weak because that isn't required. It uses self.update() rather than self.data.update() to perform the inclusion, so any mapping that supports .keys() and .__getitem__() is sufficient. Some additional checking could be done to make sure that all added entries can be created before inserting any of them, offering more atomicity. .get() will be fixed in the next version of the patch; thanks! I've added GC support, but don't have it working quite right. I'm trying to isolate the failure now. ------------------------------------------------------- Date: 2001-Jan-12 14:36 By: loewis Comment: The weak dictionary data type needs more clarification in documentation and implementation. In java.util.WeakHashMap, they keys are weak, not the values (i.e. once the key is forgotten, the entry is cleared). In http://www.handshake.de/~dieter/weakdict.html, the values are weak, but it raises KeyErrors for entries that are collected. The initializer of a weak dict does not check the invariant (all values are weak). get() of a weakdict does not support an optional second parameter. weakref and friends need to participate in garbage collection, as the reference to the callback can create a cycle. ------------------------------------------------------- Date: 2001-Jan-12 11:27 By: fdrake Comment: Updated patch to also support proxy semantics using the same invalidation machinery as the basic weak reference type. The additional code is *heavily* borrowed from Neil Schemenauer. ------------------------------------------------------- Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Wed Jan 17 06:15:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 22:15:11 -0800 Subject: [Patches] [Patch #103252] Startup optimize: read *.pyc as string, not with getc() Message-ID: <E14IlsF-0005DW-00@usw-sf-web3.sourceforge.net> Patch #103252 has been updated. Project: python Category: core (C code) Status: Open Submitted by: pj99 Assigned to : tim_one Summary: Startup optimize: read *.pyc as string, not with getc() Follow-Ups: Date: 2001-Jan-16 22:15 By: tim_one Comment: I'm afraid this patch needs major work before we could use it. The big thing is that stat isn't std C, and as far as I can tell we don't even define a config symbol saying whether it's available. Even when it is available, on at least one oddball platform it apparently needs oddball declarations (see the STAT/FSTAT/etc macros in posixfile.c). And the Macintosh code isn't in the CVS tree (Jack Jansen owns it), so no telling how it's done there. *Standard* C doesn't have a good way to determine the size of a file, either. While Python's os.path.getsize() is supported on all platforms, that's done in platform-dependent ways in platform-dependent files, and there's no Python C API for it. So the first step would be to define and implement a PyOS_GetFileSize() C API, akin to the existing PyOS_GetLastModificationTime() (in getmtime.c). Beyond that, there are small things that need fixing. Like: + malloc's return should be cast to char* + but malloc shouldn't be called directly to begin with (see pymem.h) + ditto free() + the pointer test (buf > 0) doesn't make sense (buf != NULL was intended) Once we get beyond all that <wink>, I think a three-tiered strategy would be worth implementing: also declare a 16K stack buffer. If a file is small enough, read into that; else if less than 256K (as Guido asked) malloc a buffer as is done now; else give up. 75% of the .pyc files on my box are under 16K (90% of IDLE's), so that would save the bulk of the malloc/free calls due to this. ------------------------------------------------------- Date: 2001-Jan-16 13:36 By: pj99 Comment: No problem, Tim (on the alledged abruptness). In any case, it was useful - in that it helped motivate /f into proposing a fix, me into coding it, and you to consider applying it. All in all a useful result. Most thanks, Tim. ------------------------------------------------------- Date: 2001-Jan-15 20:26 By: tim_one Comment: Indeed, IDLE takes more than a full second to come up on my box, *much* longer than Notepad. Now that we have a clear goal, I assigned this patch to me <wink>. (OK, it's really that I was abrupt with Paul when this came up on c.l.py, and left him hanging there -- I owe him on this one). ------------------------------------------------------- Date: 2001-Jan-15 20:18 By: gvanrossum Comment: Oh, but I do care about the load time of Tkinter. :-) Anything to keep IDLE ahead of Komodo in the race. :-) ------------------------------------------------------- Date: 2001-Jan-15 20:05 By: tim_one Comment: I like the idea, but gimmicks like this make porting to tiny platforms harder when pushed "too far". People concerned about startup time seem mostly to deal with apps that e.g. fire up Python 1000s of times from shell scripts or cgi. They're not going to care about monster modules (like Tkinter and grail). So I think Paul's original 64K is a good compromise. ------------------------------------------------------- Date: 2001-Jan-15 19:39 By: gvanrossum Comment: Not a bad idea. I'd up the limit to 256K so Tkinter.pyc (comfortably) fits. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103252&group_id=5470 From thomas@xs4all.net Wed Jan 17 09:02:19 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 17 Jan 2001 10:02:19 +0100 Subject: [Patches] [Patch #102891] Alternative readline module In-Reply-To: <LNBBLJKPBEHFEDALKOLCIEBMIJAA.tim.one@home.com>; from tim.one@home.com on Tue, Jan 16, 2001 at 07:42:51PM -0500 References: <m3snmj2g4p.fsf@atrus.jesus.cam.ac.uk> <LNBBLJKPBEHFEDALKOLCIEBMIJAA.tim.one@home.com> Message-ID: <20010117100206.D2776@xs4all.nl> On Tue, Jan 16, 2001 at 07:42:51PM -0500, Tim Peters wrote: > [Michael Hudson] > > This is a really silly place to be having this discussion, isn't it? > That's because we just turned off the patches reply-to to python-dev. It > was predicted that people would be careful to type in python-dev themselves > when it was warranted <snort>. Actually, it's party Guido's (or maybe Michael's) fault too... Neil sneakily put in a 'Mail-Followup-To' header to python-dev, but either noone replied to him, or their mailers ignored the header :-) -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From noreply@sourceforge.net Wed Jan 17 09:24:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 01:24:20 -0800 Subject: [Patches] [Patch #103265] Let time functions default to 'now' (where it makes sense) Message-ID: <E14IopI-00065t-00@usw-sf-web3.sourceforge.net> Patch #103265 has been updated. Project: python Category: Modules Status: Open Submitted by: twouters Assigned to : twouters Summary: Let time functions default to 'now' (where it makes sense) Follow-Ups: Date: 2001-Jan-17 01:24 By: twouters Comment: Calling floattime() only when necessary would be nice, but isn't possible without a value that reads as 'empty'. There is no way to see whether optional values of a ParseTuple call were filled or not, except by comparing the old value with the new one, and that means making a token float value that means 'no argument'. We could check the length of 'args' to see howmany arguments it contains, but that is a very fragile way, and breaks the wonderful transparentness of argument-passing and PyArg_Parse*. The alternative to this approach is not reading a double from the arglist, but a Python object (initialized as NULL,) and converting that to a float. That would have my preference over the other two options, above, but I still prefer the current way -- much less code, not that much slower (if slower at all, I didn't time it.) (Unless of course there is a way to see howmany optional arguments were used ? Like a separate format character that fills an int with that information, or a separate PyArg API call that returns not success/failure, but the number of optional arguments used, and -1 on failure.) I'll add news + docs, too, sometime before friday if work permits :P ------------------------------------------------------- Date: 2001-Jan-16 20:29 By: gvanrossum Comment: How hard would it be to avoid calling floattime() when an argument is present (in gmtime() and localtime())? Missing: docs, NEWS item. Otherwise, great -- ready to check in if you fix the above things! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103265&group_id=5470 From noreply@sourceforge.net Wed Jan 17 13:56:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 05:56:05 -0800 Subject: [Patches] [Patch #103252] Startup optimize: read *.pyc as string, not with getc() Message-ID: <E14It4H-0007mV-00@usw-sf-web2.sourceforge.net> Patch #103252 has been updated. Project: python Category: core (C code) Status: Open Submitted by: pj99 Assigned to : tim_one Summary: Startup optimize: read *.pyc as string, not with getc() Follow-Ups: Date: 2001-Jan-17 05:56 By: gvanrossum Comment: Re the stat syscall: you seem to be using fstat(), and HAVE_FSTAT *does* exist. (It is used in fileobject.c.) And if you need stat(): HAVE_STAT is also defined (used in import.c). So I think you're in good shape there. I agree with Tim's other recommendations! ------------------------------------------------------- Date: 2001-Jan-16 22:15 By: tim_one Comment: I'm afraid this patch needs major work before we could use it. The big thing is that stat isn't std C, and as far as I can tell we don't even define a config symbol saying whether it's available. Even when it is available, on at least one oddball platform it apparently needs oddball declarations (see the STAT/FSTAT/etc macros in posixfile.c). And the Macintosh code isn't in the CVS tree (Jack Jansen owns it), so no telling how it's done there. *Standard* C doesn't have a good way to determine the size of a file, either. While Python's os.path.getsize() is supported on all platforms, that's done in platform-dependent ways in platform-dependent files, and there's no Python C API for it. So the first step would be to define and implement a PyOS_GetFileSize() C API, akin to the existing PyOS_GetLastModificationTime() (in getmtime.c). Beyond that, there are small things that need fixing. Like: + malloc's return should be cast to char* + but malloc shouldn't be called directly to begin with (see pymem.h) + ditto free() + the pointer test (buf > 0) doesn't make sense (buf != NULL was intended) Once we get beyond all that <wink>, I think a three-tiered strategy would be worth implementing: also declare a 16K stack buffer. If a file is small enough, read into that; else if less than 256K (as Guido asked) malloc a buffer as is done now; else give up. 75% of the .pyc files on my box are under 16K (90% of IDLE's), so that would save the bulk of the malloc/free calls due to this. ------------------------------------------------------- Date: 2001-Jan-16 13:36 By: pj99 Comment: No problem, Tim (on the alledged abruptness). In any case, it was useful - in that it helped motivate /f into proposing a fix, me into coding it, and you to consider applying it. All in all a useful result. Most thanks, Tim. ------------------------------------------------------- Date: 2001-Jan-15 20:26 By: tim_one Comment: Indeed, IDLE takes more than a full second to come up on my box, *much* longer than Notepad. Now that we have a clear goal, I assigned this patch to me <wink>. (OK, it's really that I was abrupt with Paul when this came up on c.l.py, and left him hanging there -- I owe him on this one). ------------------------------------------------------- Date: 2001-Jan-15 20:18 By: gvanrossum Comment: Oh, but I do care about the load time of Tkinter. :-) Anything to keep IDLE ahead of Komodo in the race. :-) ------------------------------------------------------- Date: 2001-Jan-15 20:05 By: tim_one Comment: I like the idea, but gimmicks like this make porting to tiny platforms harder when pushed "too far". People concerned about startup time seem mostly to deal with apps that e.g. fire up Python 1000s of times from shell scripts or cgi. They're not going to care about monster modules (like Tkinter and grail). So I think Paul's original 64K is a good compromise. ------------------------------------------------------- Date: 2001-Jan-15 19:39 By: gvanrossum Comment: Not a bad idea. I'd up the limit to 256K so Tkinter.pyc (comfortably) fits. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103252&group_id=5470 From noreply@sourceforge.net Wed Jan 17 14:01:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 06:01:21 -0800 Subject: [Patches] [Patch #103265] Let time functions default to 'now' (where it makes sense) Message-ID: <E14It9N-0005a1-00@usw-sf-web1.sourceforge.net> Patch #103265 has been updated. Project: python Category: Modules Status: Open Submitted by: twouters Assigned to : twouters Summary: Let time functions default to 'now' (where it makes sense) Follow-Ups: Date: 2001-Jan-17 06:01 By: gvanrossum Comment: With METH_VARARGS, args is guaranteed to be a tuple, so you can simply use PyTuple_Size(). ------------------------------------------------------- Date: 2001-Jan-17 01:24 By: twouters Comment: Calling floattime() only when necessary would be nice, but isn't possible without a value that reads as 'empty'. There is no way to see whether optional values of a ParseTuple call were filled or not, except by comparing the old value with the new one, and that means making a token float value that means 'no argument'. We could check the length of 'args' to see howmany arguments it contains, but that is a very fragile way, and breaks the wonderful transparentness of argument-passing and PyArg_Parse*. The alternative to this approach is not reading a double from the arglist, but a Python object (initialized as NULL,) and converting that to a float. That would have my preference over the other two options, above, but I still prefer the current way -- much less code, not that much slower (if slower at all, I didn't time it.) (Unless of course there is a way to see howmany optional arguments were used ? Like a separate format character that fills an int with that information, or a separate PyArg API call that returns not success/failure, but the number of optional arguments used, and -1 on failure.) I'll add news + docs, too, sometime before friday if work permits :P ------------------------------------------------------- Date: 2001-Jan-16 20:29 By: gvanrossum Comment: How hard would it be to avoid calling floattime() when an argument is present (in gmtime() and localtime())? Missing: docs, NEWS item. Otherwise, great -- ready to check in if you fix the above things! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103265&group_id=5470 From noreply@sourceforge.net Wed Jan 17 14:55:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 06:55:40 -0800 Subject: [Patches] [Patch #103265] Let time functions default to 'now' (where it makes sense) Message-ID: <E14Itzw-0007DE-00@usw-sf-web3.sourceforge.net> Patch #103265 has been updated. Project: python Category: Modules Status: Open Submitted by: twouters Assigned to : fdrake Summary: Let time functions default to 'now' (where it makes sense) Follow-Ups: Date: 2001-Jan-17 06:55 By: twouters Comment: That's what I meant with 'check the size', but I still think it kind of breaks the abstraction of 'args'. Not in a terribly scary way, but the difference between calling floattime() always and doing a check whether or not to call floattime() isn't that big either. But you is BDFL, boss, so here's a patch that does it your way :) It also adds a NEWS entry and fixes the docs for timemodule (including docstrings.) Assigned to Fred so he can take a quick look at the docs. Don't need to check the TeX code though, Fred, I successfully built ps files on my laptop :) ------------------------------------------------------- Date: 2001-Jan-17 06:01 By: gvanrossum Comment: With METH_VARARGS, args is guaranteed to be a tuple, so you can simply use PyTuple_Size(). ------------------------------------------------------- Date: 2001-Jan-17 01:24 By: twouters Comment: Calling floattime() only when necessary would be nice, but isn't possible without a value that reads as 'empty'. There is no way to see whether optional values of a ParseTuple call were filled or not, except by comparing the old value with the new one, and that means making a token float value that means 'no argument'. We could check the length of 'args' to see howmany arguments it contains, but that is a very fragile way, and breaks the wonderful transparentness of argument-passing and PyArg_Parse*. The alternative to this approach is not reading a double from the arglist, but a Python object (initialized as NULL,) and converting that to a float. That would have my preference over the other two options, above, but I still prefer the current way -- much less code, not that much slower (if slower at all, I didn't time it.) (Unless of course there is a way to see howmany optional arguments were used ? Like a separate format character that fills an int with that information, or a separate PyArg API call that returns not success/failure, but the number of optional arguments used, and -1 on failure.) I'll add news + docs, too, sometime before friday if work permits :P ------------------------------------------------------- Date: 2001-Jan-16 20:29 By: gvanrossum Comment: How hard would it be to avoid calling floattime() when an argument is present (in gmtime() and localtime())? Missing: docs, NEWS item. Otherwise, great -- ready to check in if you fix the above things! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103265&group_id=5470 From noreply@sourceforge.net Wed Jan 17 15:17:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 07:17:02 -0800 Subject: [Patches] [Patch #103279] Flag for making sysconfig assume build directories Message-ID: <E14IuKc-0007Hn-00@usw-sf-web3.sourceforge.net> Patch #103279 has been updated. Project: python Category: distutils Status: Accepted Submitted by: akuchling Assigned to : gward Summary: Flag for making sysconfig assume build directories Follow-Ups: Date: 2001-Jan-17 07:17 By: akuchling Comment: Checked in and moved to 'Accepted' status, so gward can look at it later. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103279&group_id=5470 From noreply@sourceforge.net Wed Jan 17 15:18:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 07:18:03 -0800 Subject: [Patches] [Patch #103258] Cookie.py docs: example incorrect Message-ID: <E14IuLb-0007Hw-00@usw-sf-web3.sourceforge.net> Patch #103258 has been updated. Project: python Category: documentation Status: Accepted Submitted by: ping Assigned to : ping Summary: Cookie.py docs: example incorrect Follow-Ups: Date: 2001-Jan-17 07:18 By: fdrake Comment: Thanks; please check it in! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103258&group_id=5470 From noreply@sourceforge.net Wed Jan 17 15:43:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 07:43:27 -0800 Subject: [Patches] [Patch #101664] Add new unistr() builtin + PyObject_Unicode() C API Message-ID: <E14IukB-0008CG-00@usw-sf-web2.sourceforge.net> Patch #101664 has been updated. Project: python Category: core (C code) Status: Open Submitted by: lemburg Assigned to : lemburg Summary: Add new unistr() builtin + PyObject_Unicode() C API Follow-Ups: Date: 2001-Jan-17 07:43 By: gvanrossum Comment: Go ahead and check it in, Marc! ------------------------------------------------------- Date: 2000-Sep-26 04:14 By: lemburg Comment: This patch adds a utility function unistr() which works just like the standard builtin str() -- only that the return value will always be a Unicode object. The patch also adds a new object level C API PyObject_Unicode() which complements PyObject_Str(). Since this is a new feature, I have postponed the patch to be reopened in the 2.1 cycle. ------------------------------------------------------- Date: 2000-Oct-30 06:44 By: moshez Comment: There is no documentation for unistr() and PyObject_Unicode(), which is usually considered a show stopper by the powers that be. Here's some draft docos Insert into Doc/libfuncs.tex, after \begin{funcdesc}{str}....\end{funcdesc}: \begin{funcdesc}{unistr}{object} Return a Unicode representation of an object. It returns the result of converting the str(object) to unicode if the object can be converted into a string. It returns unicode objects as is. \end{funcdesc} Insert the following in Doc/api/api.tex after \begin{cfuncdesc}{PyObject*}{PyObject_Str}{PyObject *o}...\end{cfuncdesc} \begin{cfuncdesc}{PyObject *}{PyObject_Unicode}{PyObject *O} Compute a unicode representation of \var{o}. Returns the unicode representation on success \NULL{} on failure. This is the equivalent of the Python expression \samp{unistr(\var{o})}. Called by the \function{unistr()}\bifuncindex{unistr} built-in function. \end{cfuncdesc} Oh, and please don't use PyObject_GetAttrString: It's slow.... ------------------------------------------------------- Date: 2000-Oct-30 07:19 By: nobody Comment: Thanks. I'll add the docs to the patch. About PyObject_GetAttrString() ... I'll add an optimization somewhat like in classobject.c to PyObject_Unicode() which should help boost the performance somewhat. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101664&group_id=5470 From noreply@sourceforge.net Wed Jan 17 15:50:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 07:50:20 -0800 Subject: [Patches] [Patch #103265] Let time functions default to 'now' (where it makes sense) Message-ID: <E14Iuqq-0005zB-00@usw-sf-web1.sourceforge.net> Patch #103265 has been updated. Project: python Category: Modules Status: Open Submitted by: twouters Assigned to : fdrake Summary: Let time functions default to 'now' (where it makes sense) Follow-Ups: Date: 2001-Jan-17 07:50 By: gvanrossum Comment: Thomas, go for it. I'd say "the current time" instead of "now" in the NEWS item. I'll defer to Fred for the docs. ------------------------------------------------------- Date: 2001-Jan-17 06:55 By: twouters Comment: That's what I meant with 'check the size', but I still think it kind of breaks the abstraction of 'args'. Not in a terribly scary way, but the difference between calling floattime() always and doing a check whether or not to call floattime() isn't that big either. But you is BDFL, boss, so here's a patch that does it your way :) It also adds a NEWS entry and fixes the docs for timemodule (including docstrings.) Assigned to Fred so he can take a quick look at the docs. Don't need to check the TeX code though, Fred, I successfully built ps files on my laptop :) ------------------------------------------------------- Date: 2001-Jan-17 06:01 By: gvanrossum Comment: With METH_VARARGS, args is guaranteed to be a tuple, so you can simply use PyTuple_Size(). ------------------------------------------------------- Date: 2001-Jan-17 01:24 By: twouters Comment: Calling floattime() only when necessary would be nice, but isn't possible without a value that reads as 'empty'. There is no way to see whether optional values of a ParseTuple call were filled or not, except by comparing the old value with the new one, and that means making a token float value that means 'no argument'. We could check the length of 'args' to see howmany arguments it contains, but that is a very fragile way, and breaks the wonderful transparentness of argument-passing and PyArg_Parse*. The alternative to this approach is not reading a double from the arglist, but a Python object (initialized as NULL,) and converting that to a float. That would have my preference over the other two options, above, but I still prefer the current way -- much less code, not that much slower (if slower at all, I didn't time it.) (Unless of course there is a way to see howmany optional arguments were used ? Like a separate format character that fills an int with that information, or a separate PyArg API call that returns not success/failure, but the number of optional arguments used, and -1 on failure.) I'll add news + docs, too, sometime before friday if work permits :P ------------------------------------------------------- Date: 2001-Jan-16 20:29 By: gvanrossum Comment: How hard would it be to avoid calling floattime() when an argument is present (in gmtime() and localtime())? Missing: docs, NEWS item. Otherwise, great -- ready to check in if you fix the above things! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103265&group_id=5470 From noreply@sourceforge.net Wed Jan 17 15:51:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 07:51:47 -0800 Subject: [Patches] [Patch #103297] __all__ values for a handful of modules Message-ID: <E14IusF-0008E3-00@usw-sf-web2.sourceforge.net> Patch #103297 has been updated. Project: python Category: None Status: Open Submitted by: montanaro Assigned to : nobody Summary: __all__ values for a handful of modules ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103297&group_id=5470 From noreply@sourceforge.net Wed Jan 17 16:04:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 08:04:59 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14Iv51-0008Gz-00@usw-sf-web2.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : nascheme Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-17 08:04 By: fdrake Comment: New version of the patch that's still broken but doesn't conflict with the rich comparisons changes: http://starship.python.net/crew/fdrake/patches/weakref.patch-4 ------------------------------------------------------- Date: 2001-Jan-16 21:35 By: fdrake Comment: Added a new (but broken!) version of the patch that fixes WeakDictionary.get() but doesn't interact properly with GC (appearantly) -- not usable as is: http://starship.python.net/crew/fdrake/patches/weakref.patch-3 Neil made the mistake of volunteering to look at the current problem, so assigning to him. (Thanks!) ------------------------------------------------------- Date: 2001-Jan-16 19:39 By: tim_one Comment: Just mentioning a general scenario in which weak keys are the bee's knees: sometimes you want to add attributes to objects dynamically, in ways the original class author(s -- may cut across many classes! even non-instance objects; or objects from extension modules that don't support setattr) never anticipated. Like maybe a German translation of the object's docstrings; or a list of JPEG contents referenced by a URLish object; or a table of usage statistics on methods and functions; etc. Then it's natural to use the conceptual attr name as the name of a dict instead, and write attr[object] = whatever instead of object.attr = whatever There's no point keeping the "whatever" around when the object goes away, but a regular dict makes the object and its "whatever" immortal. A dict with weak keys is exactly on-target. ------------------------------------------------------- Date: 2001-Jan-16 19:14 By: fdrake Comment: I'm not entirely sure why one would want weak keys rather than weak values, but I suspect it has to do with expectations of how the dict will be used in applications. I don't think it would be hard to support both flavors of dictionaries using the primitive reference objects. The constructor does not check that all incoming values are weak because that isn't required. It uses self.update() rather than self.data.update() to perform the inclusion, so any mapping that supports .keys() and .__getitem__() is sufficient. Some additional checking could be done to make sure that all added entries can be created before inserting any of them, offering more atomicity. .get() will be fixed in the next version of the patch; thanks! I've added GC support, but don't have it working quite right. I'm trying to isolate the failure now. ------------------------------------------------------- Date: 2001-Jan-12 14:36 By: loewis Comment: The weak dictionary data type needs more clarification in documentation and implementation. In java.util.WeakHashMap, they keys are weak, not the values (i.e. once the key is forgotten, the entry is cleared). In http://www.handshake.de/~dieter/weakdict.html, the values are weak, but it raises KeyErrors for entries that are collected. The initializer of a weak dict does not check the invariant (all values are weak). get() of a weakdict does not support an optional second parameter. weakref and friends need to participate in garbage collection, as the reference to the callback can create a cycle. ------------------------------------------------------- Date: 2001-Jan-12 11:27 By: fdrake Comment: Updated patch to also support proxy semantics using the same invalidation machinery as the basic weak reference type. The additional code is *heavily* borrowed from Neil Schemenauer. ------------------------------------------------------- Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Wed Jan 17 17:09:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 09:09:16 -0800 Subject: [Patches] [Patch #101664] Add new unistr() builtin + PyObject_Unicode() C API Message-ID: <E14Iw5E-0006DU-00@usw-sf-web1.sourceforge.net> Patch #101664 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: lemburg Assigned to : lemburg Summary: Add new unistr() builtin + PyObject_Unicode() C API Follow-Ups: Date: 2001-Jan-17 09:09 By: lemburg Comment: Checked in. ------------------------------------------------------- Date: 2001-Jan-17 07:43 By: gvanrossum Comment: Go ahead and check it in, Marc! ------------------------------------------------------- Date: 2000-Sep-26 04:14 By: lemburg Comment: This patch adds a utility function unistr() which works just like the standard builtin str() -- only that the return value will always be a Unicode object. The patch also adds a new object level C API PyObject_Unicode() which complements PyObject_Str(). Since this is a new feature, I have postponed the patch to be reopened in the 2.1 cycle. ------------------------------------------------------- Date: 2000-Oct-30 06:44 By: moshez Comment: There is no documentation for unistr() and PyObject_Unicode(), which is usually considered a show stopper by the powers that be. Here's some draft docos Insert into Doc/libfuncs.tex, after \begin{funcdesc}{str}....\end{funcdesc}: \begin{funcdesc}{unistr}{object} Return a Unicode representation of an object. It returns the result of converting the str(object) to unicode if the object can be converted into a string. It returns unicode objects as is. \end{funcdesc} Insert the following in Doc/api/api.tex after \begin{cfuncdesc}{PyObject*}{PyObject_Str}{PyObject *o}...\end{cfuncdesc} \begin{cfuncdesc}{PyObject *}{PyObject_Unicode}{PyObject *O} Compute a unicode representation of \var{o}. Returns the unicode representation on success \NULL{} on failure. This is the equivalent of the Python expression \samp{unistr(\var{o})}. Called by the \function{unistr()}\bifuncindex{unistr} built-in function. \end{cfuncdesc} Oh, and please don't use PyObject_GetAttrString: It's slow.... ------------------------------------------------------- Date: 2000-Oct-30 07:19 By: nobody Comment: Thanks. I'll add the docs to the patch. About PyObject_GetAttrString() ... I'll add an optimization somewhat like in classobject.c to PyObject_Unicode() which should help boost the performance somewhat. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101664&group_id=5470 From noreply@sourceforge.net Wed Jan 17 19:07:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 11:07:58 -0800 Subject: [Patches] [Patch #101843] Remove all uses of "assert" from the test suite Message-ID: <E14Ixw6-0000Ol-00@usw-sf-web2.sourceforge.net> Patch #101843 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: lemburg Assigned to : lemburg Summary: Remove all uses of "assert" from the test suite Follow-Ups: Date: 2001-Jan-17 11:07 By: lemburg Comment: Checked in. The alpha tests will hopefully catch any bugs which this patch introduced -- I can't check all tests on my platform. ------------------------------------------------------- Date: 2001-Jan-04 11:11 By: lemburg Comment: I can't promise much because as always in the last few months, I'm way too busy with other tasks... ------------------------------------------------------- Date: 2001-Jan-04 07:56 By: gvanrossum Comment: Marc-Andre, do you have time to rework this for the current CVS tree? I still like the idea a lot! Once you have a current patch it can be checked in within days. ------------------------------------------------------- Date: 2000-Oct-09 07:25 By: lemburg Comment: This patch removes all uses of the assert statement from the regression test suite. Use of assert in the suite is depreciated due to asserts being removed from the byte code when Python is run in optimized mode. The patch adds a new function to test_support (verify) which handles the asserts in a more customizable way. It does not rely on the assert statement. I have tested this patch lightly (meaning that the suite runs through just fine). Not all execution paths are testable due to the nature of the patch, though. Please review. ------------------------------------------------------- Date: 2000-Oct-09 12:26 By: gvanrossum Comment: Great! But let's do this post-2.0 final release. I'm really getting worried about patches that touch every file in a particular corner of the universe... :-( ------------------------------------------------------- Date: 2000-Oct-24 13:57 By: gvanrossum Comment: Would you mind resubmitting this? Some of the patches fail, probably because there were a lot of changes to the whitespace. The idea is still as valid as it was before. A style nit: please don't include spaces inside parentheses: please write verify(cond, reason) rather than verify( cond, reason ). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101843&group_id=5470 From noreply@sourceforge.net Wed Jan 17 19:48:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 11:48:35 -0800 Subject: [Patches] [Patch #103303] patch to fix dis.py in the face of function attributes Message-ID: <E14IyZP-00089h-00@usw-sf-web3.sourceforge.net> Patch #103303 has been updated. Project: python Category: library Status: Open Submitted by: bwarsaw Assigned to : nobody Summary: patch to fix dis.py in the face of function attributes ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103303&group_id=5470 From noreply@sourceforge.net Wed Jan 17 19:58:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 11:58:51 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14IyjL-0000Yf-00@usw-sf-web2.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : fdrake Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-17 11:58 By: nascheme Comment: The magic test is: ./python Lib/test/regrtest.py test_weakref test_new Try adding this patch: --- Modules/newmodule.c 2000/11/13 20:29:20 2.29 +++ Modules/newmodule.c 2001/01/17 19:55:46 @@ -24,6 +24,7 @@ Py_INCREF(dict); inst->in_class = (PyClassObject *)klass; inst->in_dict = dict; + inst->in_weakreflist = NULL; PyObject_GC_Init(inst); return (PyObject *)inst; } ------------------------------------------------------- Date: 2001-Jan-17 08:04 By: fdrake Comment: New version of the patch that's still broken but doesn't conflict with the rich comparisons changes: http://starship.python.net/crew/fdrake/patches/weakref.patch-4 ------------------------------------------------------- Date: 2001-Jan-16 21:35 By: fdrake Comment: Added a new (but broken!) version of the patch that fixes WeakDictionary.get() but doesn't interact properly with GC (appearantly) -- not usable as is: http://starship.python.net/crew/fdrake/patches/weakref.patch-3 Neil made the mistake of volunteering to look at the current problem, so assigning to him. (Thanks!) ------------------------------------------------------- Date: 2001-Jan-16 19:39 By: tim_one Comment: Just mentioning a general scenario in which weak keys are the bee's knees: sometimes you want to add attributes to objects dynamically, in ways the original class author(s -- may cut across many classes! even non-instance objects; or objects from extension modules that don't support setattr) never anticipated. Like maybe a German translation of the object's docstrings; or a list of JPEG contents referenced by a URLish object; or a table of usage statistics on methods and functions; etc. Then it's natural to use the conceptual attr name as the name of a dict instead, and write attr[object] = whatever instead of object.attr = whatever There's no point keeping the "whatever" around when the object goes away, but a regular dict makes the object and its "whatever" immortal. A dict with weak keys is exactly on-target. ------------------------------------------------------- Date: 2001-Jan-16 19:14 By: fdrake Comment: I'm not entirely sure why one would want weak keys rather than weak values, but I suspect it has to do with expectations of how the dict will be used in applications. I don't think it would be hard to support both flavors of dictionaries using the primitive reference objects. The constructor does not check that all incoming values are weak because that isn't required. It uses self.update() rather than self.data.update() to perform the inclusion, so any mapping that supports .keys() and .__getitem__() is sufficient. Some additional checking could be done to make sure that all added entries can be created before inserting any of them, offering more atomicity. .get() will be fixed in the next version of the patch; thanks! I've added GC support, but don't have it working quite right. I'm trying to isolate the failure now. ------------------------------------------------------- Date: 2001-Jan-12 14:36 By: loewis Comment: The weak dictionary data type needs more clarification in documentation and implementation. In java.util.WeakHashMap, they keys are weak, not the values (i.e. once the key is forgotten, the entry is cleared). In http://www.handshake.de/~dieter/weakdict.html, the values are weak, but it raises KeyErrors for entries that are collected. The initializer of a weak dict does not check the invariant (all values are weak). get() of a weakdict does not support an optional second parameter. weakref and friends need to participate in garbage collection, as the reference to the callback can create a cycle. ------------------------------------------------------- Date: 2001-Jan-12 11:27 By: fdrake Comment: Updated patch to also support proxy semantics using the same invalidation machinery as the basic weak reference type. The additional code is *heavily* borrowed from Neil Schemenauer. ------------------------------------------------------- Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Wed Jan 17 21:06:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 13:06:49 -0800 Subject: [Patches] [Patch #103252] Startup optimize: read *.pyc as string, not with getc() Message-ID: <E14Izn7-0008WK-00@usw-sf-web3.sourceforge.net> Patch #103252 has been updated. Project: python Category: core (C code) Status: Open Submitted by: pj99 Assigned to : tim_one Summary: Startup optimize: read *.pyc as string, not with getc() Follow-Ups: Date: 2001-Jan-17 13:06 By: tim_one Comment: Brrrr. HAVE_STAT and HAVE_FSTAT aren't defined in a usable way -- they're defined *by* (and local to) the files in question, if symbols like DONT_HAVE_STAT are *not* defined. So I'll rip that stuff out, get rid of the duplication, and move the HAVE_[F]STAT stuff into pyport.h first. Assuming that doesn't break the build for anyone else, and since we agree on what ought to be done next, I'll then rework the patch accordingly and check it in. ------------------------------------------------------- Date: 2001-Jan-17 05:56 By: gvanrossum Comment: Re the stat syscall: you seem to be using fstat(), and HAVE_FSTAT *does* exist. (It is used in fileobject.c.) And if you need stat(): HAVE_STAT is also defined (used in import.c). So I think you're in good shape there. I agree with Tim's other recommendations! ------------------------------------------------------- Date: 2001-Jan-16 22:15 By: tim_one Comment: I'm afraid this patch needs major work before we could use it. The big thing is that stat isn't std C, and as far as I can tell we don't even define a config symbol saying whether it's available. Even when it is available, on at least one oddball platform it apparently needs oddball declarations (see the STAT/FSTAT/etc macros in posixfile.c). And the Macintosh code isn't in the CVS tree (Jack Jansen owns it), so no telling how it's done there. *Standard* C doesn't have a good way to determine the size of a file, either. While Python's os.path.getsize() is supported on all platforms, that's done in platform-dependent ways in platform-dependent files, and there's no Python C API for it. So the first step would be to define and implement a PyOS_GetFileSize() C API, akin to the existing PyOS_GetLastModificationTime() (in getmtime.c). Beyond that, there are small things that need fixing. Like: + malloc's return should be cast to char* + but malloc shouldn't be called directly to begin with (see pymem.h) + ditto free() + the pointer test (buf > 0) doesn't make sense (buf != NULL was intended) Once we get beyond all that <wink>, I think a three-tiered strategy would be worth implementing: also declare a 16K stack buffer. If a file is small enough, read into that; else if less than 256K (as Guido asked) malloc a buffer as is done now; else give up. 75% of the .pyc files on my box are under 16K (90% of IDLE's), so that would save the bulk of the malloc/free calls due to this. ------------------------------------------------------- Date: 2001-Jan-16 13:36 By: pj99 Comment: No problem, Tim (on the alledged abruptness). In any case, it was useful - in that it helped motivate /f into proposing a fix, me into coding it, and you to consider applying it. All in all a useful result. Most thanks, Tim. ------------------------------------------------------- Date: 2001-Jan-15 20:26 By: tim_one Comment: Indeed, IDLE takes more than a full second to come up on my box, *much* longer than Notepad. Now that we have a clear goal, I assigned this patch to me <wink>. (OK, it's really that I was abrupt with Paul when this came up on c.l.py, and left him hanging there -- I owe him on this one). ------------------------------------------------------- Date: 2001-Jan-15 20:18 By: gvanrossum Comment: Oh, but I do care about the load time of Tkinter. :-) Anything to keep IDLE ahead of Komodo in the race. :-) ------------------------------------------------------- Date: 2001-Jan-15 20:05 By: tim_one Comment: I like the idea, but gimmicks like this make porting to tiny platforms harder when pushed "too far". People concerned about startup time seem mostly to deal with apps that e.g. fire up Python 1000s of times from shell scripts or cgi. They're not going to care about monster modules (like Tkinter and grail). So I think Paul's original 64K is a good compromise. ------------------------------------------------------- Date: 2001-Jan-15 19:39 By: gvanrossum Comment: Not a bad idea. I'd up the limit to 256K so Tkinter.pyc (comfortably) fits. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103252&group_id=5470 From noreply@sourceforge.net Wed Jan 17 21:53:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 13:53:55 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14J0Wh-0000RW-00@usw-sf-web3.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : nascheme Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-17 13:53 By: fdrake Comment: Ok, I tihnk this is it! http://starship.python.net/crew/fdrake/patches/weakref.patch-5 This patch fixes the compilation problems from the previoous patch related to the introduction of rich comparisons, and makes a change in the way new objects are initialized by PyObject_New() and PyObject_NEW() (and all their friends!) -- those functions now know to initialize the weak reference list to NULL for objects which support weak references. Without this change, more places in the code (especially extension modules) need to know more about initialization of weakly-referencable objects. For instance, the "cPickle" and "new" modules both can create instances without calling the code in classobject.c (using PyObject_New()), causing core dumps when such instances are deallocated if the weak-reference list for instances was not properly initialized. Since these modules (properly) tried to avoid call PyInstance_New(), core dumps ensued and the world fell apart. By moving the initialization of the weak reference list into the core object allocators, this problem is averted and extension code to construct new weakly referencable types is simplified. The documentation still needs work, and there are a few new entries for the Python/C API manual as well. A new constructor for instances, PyInstance_NewRaw(), will be added in a separate patch. ------------------------------------------------------- Date: 2001-Jan-17 11:58 By: nascheme Comment: The magic test is: ./python Lib/test/regrtest.py test_weakref test_new Try adding this patch: --- Modules/newmodule.c 2000/11/13 20:29:20 2.29 +++ Modules/newmodule.c 2001/01/17 19:55:46 @@ -24,6 +24,7 @@ Py_INCREF(dict); inst->in_class = (PyClassObject *)klass; inst->in_dict = dict; + inst->in_weakreflist = NULL; PyObject_GC_Init(inst); return (PyObject *)inst; } ------------------------------------------------------- Date: 2001-Jan-17 08:04 By: fdrake Comment: New version of the patch that's still broken but doesn't conflict with the rich comparisons changes: http://starship.python.net/crew/fdrake/patches/weakref.patch-4 ------------------------------------------------------- Date: 2001-Jan-16 21:35 By: fdrake Comment: Added a new (but broken!) version of the patch that fixes WeakDictionary.get() but doesn't interact properly with GC (appearantly) -- not usable as is: http://starship.python.net/crew/fdrake/patches/weakref.patch-3 Neil made the mistake of volunteering to look at the current problem, so assigning to him. (Thanks!) ------------------------------------------------------- Date: 2001-Jan-16 19:39 By: tim_one Comment: Just mentioning a general scenario in which weak keys are the bee's knees: sometimes you want to add attributes to objects dynamically, in ways the original class author(s -- may cut across many classes! even non-instance objects; or objects from extension modules that don't support setattr) never anticipated. Like maybe a German translation of the object's docstrings; or a list of JPEG contents referenced by a URLish object; or a table of usage statistics on methods and functions; etc. Then it's natural to use the conceptual attr name as the name of a dict instead, and write attr[object] = whatever instead of object.attr = whatever There's no point keeping the "whatever" around when the object goes away, but a regular dict makes the object and its "whatever" immortal. A dict with weak keys is exactly on-target. ------------------------------------------------------- Date: 2001-Jan-16 19:14 By: fdrake Comment: I'm not entirely sure why one would want weak keys rather than weak values, but I suspect it has to do with expectations of how the dict will be used in applications. I don't think it would be hard to support both flavors of dictionaries using the primitive reference objects. The constructor does not check that all incoming values are weak because that isn't required. It uses self.update() rather than self.data.update() to perform the inclusion, so any mapping that supports .keys() and .__getitem__() is sufficient. Some additional checking could be done to make sure that all added entries can be created before inserting any of them, offering more atomicity. .get() will be fixed in the next version of the patch; thanks! I've added GC support, but don't have it working quite right. I'm trying to isolate the failure now. ------------------------------------------------------- Date: 2001-Jan-12 14:36 By: loewis Comment: The weak dictionary data type needs more clarification in documentation and implementation. In java.util.WeakHashMap, they keys are weak, not the values (i.e. once the key is forgotten, the entry is cleared). In http://www.handshake.de/~dieter/weakdict.html, the values are weak, but it raises KeyErrors for entries that are collected. The initializer of a weak dict does not check the invariant (all values are weak). get() of a weakdict does not support an optional second parameter. weakref and friends need to participate in garbage collection, as the reference to the callback can create a cycle. ------------------------------------------------------- Date: 2001-Jan-12 11:27 By: fdrake Comment: Updated patch to also support proxy semantics using the same invalidation machinery as the basic weak reference type. The additional code is *heavily* borrowed from Neil Schemenauer. ------------------------------------------------------- Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Wed Jan 17 22:01:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 14:01:47 -0800 Subject: [Patches] [Patch #103305] function attribute segfault Message-ID: <E14J0eJ-0000U5-00@usw-sf-web3.sourceforge.net> Patch #103305 has been updated. Project: python Category: core (C code) Status: Open Submitted by: greg_ball Assigned to : nobody Summary: function attribute segfault ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103305&group_id=5470 From noreply@sourceforge.net Wed Jan 17 22:03:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 14:03:45 -0800 Subject: [Patches] [Patch #103305] function attribute segfault Message-ID: <E14J0gD-0000Uy-00@usw-sf-web3.sourceforge.net> Patch #103305 has been updated. Project: python Category: core (C code) Status: Open Submitted by: greg_ball Assigned to : nobody Summary: function attribute segfault Follow-Ups: Date: 2001-Jan-17 14:03 By: greg_ball Comment: At two points, the code did not check for NULL, leading to segmentation fault soon after. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103305&group_id=5470 From noreply@sourceforge.net Wed Jan 17 22:46:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 14:46:03 -0800 Subject: [Patches] [Patch #100938] [Draft] libpython as shared library (.so) on Linux Message-ID: <E14J1L9-0001Ve-00@usw-sf-web2.sourceforge.net> Patch #100938 has been updated. Project: python Category: None Status: Open Submitted by: flight Assigned to : jhylton Summary: [Draft] libpython as shared library (.so) on Linux Follow-Ups: Date: 2001-Jan-17 14:46 By: nobody Comment: Getting this patch into the next version of Python would be "A Good Thing"(tm) in my opinion. We use libpython as a .so at ILM and end up having to make changes like this by hand every time we get a new version... ------------------------------------------------------- Date: 2000-Jul-19 14:10 By: flight Comment: This is what it used in product to build libpython as shared library(.so) for Debian. Note: This patch is not ready for inclusion in the upstream Python distribution. Anyway, I think this might be a start. The Python 1.5 executable in Debian GNU/Linux is built against a shared libpython1.5.so since April 1999, and I haven't yet heard about any problems. Using a shared library should have an advantage if you're running multiple instances of Python (be it standalone interpreter or embedded applications). ------------------------------------------------------- Date: 2000-Aug-15 10:52 By: tim_one Comment: Assigned to Barry because he's a Linux weenie. Barry, if you think there's something here that should go into 2.0, please pursue it now, else change the status to Postponed. ------------------------------------------------------- Date: 2000-Aug-16 00:40 By: moshez Comment: I suggest we postpone it. It isn't really complete (only works on real distributions <wink>), and the complete solution should work on all unices. If Tcl/Perl can do it, there is no reason Python can't -- and a half hearted solution isn't that good. flight, you should use this for the Python in woody in the mean time -- I doubt woody will be stable before Python 2.1 comes out, so 2.1 sounds like a good timeframe to do it. ------------------------------------------------------- Date: 2000-Aug-23 09:26 By: jhylton Comment: In the absence of anyone arguing for inclusion of this patch and a one-week idle period, it is postponed. ------------------------------------------------------- Date: 2000-Oct-26 14:13 By: gvanrossum Comment: Let's give this to Jeremy instead, because he seems to know more about build issues. Jeremy, it would be good to look into getting this to work with your RPM suite. Flight's argument (has been used without complaints in Debian Python 1.5.2 since 1999) is good. ------------------------------------------------------- Date: 2000-Nov-01 03:32 By: moshez Comment: I've had a look at the patch, and it seems it has two orthogonal parts. One is adding the infrastructure for compiling another version for the Python library, which can be more or less integrated as-is, and one is hard-coding the particular way, in Linux, of building shared objects. Since we discover how to build shared objects in the configure script anyway (otherwise we could not have built modules as shared objects), we should embed that information there, not the Linux flags. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100938&group_id=5470 From noreply@sourceforge.net Wed Jan 17 22:51:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 14:51:54 -0800 Subject: [Patches] [Patch #103305] function attribute segfault Message-ID: <E14J1Qo-0001Xq-00@usw-sf-web2.sourceforge.net> Patch #103305 has been updated. Project: python Category: core (C code) Status: Open Submitted by: greg_ball Assigned to : nobody Summary: function attribute segfault Follow-Ups: Date: 2001-Jan-17 14:51 By: greg_ball Comment: I have ready a new version of the patch (I won't upload it yet in case it's not welcome) which does the following: reference to f.__dict__ or f.func_dict returns a new dictionary if f did not previously have one. (Similar to what happens on first assignent to arbitrary attribute.) Then the following code works: >>> def f(): pass ... >>> d=f.__dict__ >>> f.a=1 >>> d['a'] 1 instead of d being an unsubscriptable object. To me it seems nasty if somethings __dict__ attribute might not be a dictionary. Since f.__dict__ never now _appears_ to be None, I also removed the feature of assigning it to None to get rid of it. del f.__dict__ can now be used for this purpose. (previously only for creating sig11 =) ) One other thought: as it stands, function attributes are strangely behaving in restricted mode. You can't set any attributes directly. You can't directly get attributes that don't start with an underscore. However, you can get __dict__ and then do anything you like to it... ------------------------------------------------------- Date: 2001-Jan-17 14:03 By: greg_ball Comment: At two points, the code did not check for NULL, leading to segmentation fault soon after. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103305&group_id=5470 From noreply@sourceforge.net Wed Jan 17 23:09:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 15:09:14 -0800 Subject: [Patches] [Patch #100938] [Draft] libpython as shared library (.so) on Linux Message-ID: <E14J1ha-0007k8-00@usw-sf-web1.sourceforge.net> Patch #100938 has been updated. Project: python Category: None Status: Open Submitted by: flight Assigned to : akuchling Summary: [Draft] libpython as shared library (.so) on Linux Follow-Ups: Date: 2001-Jan-17 15:09 By: gvanrossum Comment: Andrew, I'm tentatively reassigning this to you, since you're taking charge of the build process at the moment (setup.py). I suspect that the patch no longer works as is -- would it make sense to mark it postponed and get the author to submit a new version before we release 2.1a1? ------------------------------------------------------- Date: 2001-Jan-17 14:46 By: nobody Comment: Getting this patch into the next version of Python would be "A Good Thing"(tm) in my opinion. We use libpython as a .so at ILM and end up having to make changes like this by hand every time we get a new version... ------------------------------------------------------- Date: 2000-Jul-19 14:10 By: flight Comment: This is what it used in product to build libpython as shared library(.so) for Debian. Note: This patch is not ready for inclusion in the upstream Python distribution. Anyway, I think this might be a start. The Python 1.5 executable in Debian GNU/Linux is built against a shared libpython1.5.so since April 1999, and I haven't yet heard about any problems. Using a shared library should have an advantage if you're running multiple instances of Python (be it standalone interpreter or embedded applications). ------------------------------------------------------- Date: 2000-Aug-15 10:52 By: tim_one Comment: Assigned to Barry because he's a Linux weenie. Barry, if you think there's something here that should go into 2.0, please pursue it now, else change the status to Postponed. ------------------------------------------------------- Date: 2000-Aug-16 00:40 By: moshez Comment: I suggest we postpone it. It isn't really complete (only works on real distributions <wink>), and the complete solution should work on all unices. If Tcl/Perl can do it, there is no reason Python can't -- and a half hearted solution isn't that good. flight, you should use this for the Python in woody in the mean time -- I doubt woody will be stable before Python 2.1 comes out, so 2.1 sounds like a good timeframe to do it. ------------------------------------------------------- Date: 2000-Aug-23 09:26 By: jhylton Comment: In the absence of anyone arguing for inclusion of this patch and a one-week idle period, it is postponed. ------------------------------------------------------- Date: 2000-Oct-26 14:13 By: gvanrossum Comment: Let's give this to Jeremy instead, because he seems to know more about build issues. Jeremy, it would be good to look into getting this to work with your RPM suite. Flight's argument (has been used without complaints in Debian Python 1.5.2 since 1999) is good. ------------------------------------------------------- Date: 2000-Nov-01 03:32 By: moshez Comment: I've had a look at the patch, and it seems it has two orthogonal parts. One is adding the infrastructure for compiling another version for the Python library, which can be more or less integrated as-is, and one is hard-coding the particular way, in Linux, of building shared objects. Since we discover how to build shared objects in the configure script anyway (otherwise we could not have built modules as shared objects), we should embed that information there, not the Linux flags. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100938&group_id=5470 From noreply@sourceforge.net Thu Jan 18 04:41:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 20:41:43 -0800 Subject: [Patches] [Patch #103252] Startup optimize: read *.pyc as string, not with getc() Message-ID: <E14J6tL-0002XB-00@usw-sf-web3.sourceforge.net> Patch #103252 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: pj99 Assigned to : tim_one Summary: Startup optimize: read *.pyc as string, not with getc() Follow-Ups: Date: 2001-Jan-17 20:41 By: tim_one Comment: Thanks for pushing this, Paul! Checked in a variant as discussed here, marshal.c ver 1.59 and ACKS ver 1.71. The stat/fstat fiddling was done in a previous checkin. ------------------------------------------------------- Date: 2001-Jan-17 13:06 By: tim_one Comment: Brrrr. HAVE_STAT and HAVE_FSTAT aren't defined in a usable way -- they're defined *by* (and local to) the files in question, if symbols like DONT_HAVE_STAT are *not* defined. So I'll rip that stuff out, get rid of the duplication, and move the HAVE_[F]STAT stuff into pyport.h first. Assuming that doesn't break the build for anyone else, and since we agree on what ought to be done next, I'll then rework the patch accordingly and check it in. ------------------------------------------------------- Date: 2001-Jan-17 05:56 By: gvanrossum Comment: Re the stat syscall: you seem to be using fstat(), and HAVE_FSTAT *does* exist. (It is used in fileobject.c.) And if you need stat(): HAVE_STAT is also defined (used in import.c). So I think you're in good shape there. I agree with Tim's other recommendations! ------------------------------------------------------- Date: 2001-Jan-16 22:15 By: tim_one Comment: I'm afraid this patch needs major work before we could use it. The big thing is that stat isn't std C, and as far as I can tell we don't even define a config symbol saying whether it's available. Even when it is available, on at least one oddball platform it apparently needs oddball declarations (see the STAT/FSTAT/etc macros in posixfile.c). And the Macintosh code isn't in the CVS tree (Jack Jansen owns it), so no telling how it's done there. *Standard* C doesn't have a good way to determine the size of a file, either. While Python's os.path.getsize() is supported on all platforms, that's done in platform-dependent ways in platform-dependent files, and there's no Python C API for it. So the first step would be to define and implement a PyOS_GetFileSize() C API, akin to the existing PyOS_GetLastModificationTime() (in getmtime.c). Beyond that, there are small things that need fixing. Like: + malloc's return should be cast to char* + but malloc shouldn't be called directly to begin with (see pymem.h) + ditto free() + the pointer test (buf > 0) doesn't make sense (buf != NULL was intended) Once we get beyond all that <wink>, I think a three-tiered strategy would be worth implementing: also declare a 16K stack buffer. If a file is small enough, read into that; else if less than 256K (as Guido asked) malloc a buffer as is done now; else give up. 75% of the .pyc files on my box are under 16K (90% of IDLE's), so that would save the bulk of the malloc/free calls due to this. ------------------------------------------------------- Date: 2001-Jan-16 13:36 By: pj99 Comment: No problem, Tim (on the alledged abruptness). In any case, it was useful - in that it helped motivate /f into proposing a fix, me into coding it, and you to consider applying it. All in all a useful result. Most thanks, Tim. ------------------------------------------------------- Date: 2001-Jan-15 20:26 By: tim_one Comment: Indeed, IDLE takes more than a full second to come up on my box, *much* longer than Notepad. Now that we have a clear goal, I assigned this patch to me <wink>. (OK, it's really that I was abrupt with Paul when this came up on c.l.py, and left him hanging there -- I owe him on this one). ------------------------------------------------------- Date: 2001-Jan-15 20:18 By: gvanrossum Comment: Oh, but I do care about the load time of Tkinter. :-) Anything to keep IDLE ahead of Komodo in the race. :-) ------------------------------------------------------- Date: 2001-Jan-15 20:05 By: tim_one Comment: I like the idea, but gimmicks like this make porting to tiny platforms harder when pushed "too far". People concerned about startup time seem mostly to deal with apps that e.g. fire up Python 1000s of times from shell scripts or cgi. They're not going to care about monster modules (like Tkinter and grail). So I think Paul's original 64K is a good compromise. ------------------------------------------------------- Date: 2001-Jan-15 19:39 By: gvanrossum Comment: Not a bad idea. I'd up the limit to 256K so Tkinter.pyc (comfortably) fits. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103252&group_id=5470 From noreply@sourceforge.net Thu Jan 18 05:23:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 21:23:48 -0800 Subject: [Patches] [Patch #103252] Startup optimize: read *.pyc as string, not with getc() Message-ID: <E14J7Y4-00018N-00@usw-sf-web1.sourceforge.net> Patch #103252 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: pj99 Assigned to : tim_one Summary: Startup optimize: read *.pyc as string, not with getc() Follow-Ups: Date: 2001-Jan-17 21:23 By: pj99 Comment: You're welcome, Tim. Thanks for finishing it off! I was about to post saying that I was skeptical of the 16 Kb stack array, but since that's done (and since it was Guido himself suggesting it, and you agreeing to it), I won't go into that. Lets just say that I spent a past life working in a 4 Kb fixed length kernel stack. Good work. ------------------------------------------------------- Date: 2001-Jan-17 20:41 By: tim_one Comment: Thanks for pushing this, Paul! Checked in a variant as discussed here, marshal.c ver 1.59 and ACKS ver 1.71. The stat/fstat fiddling was done in a previous checkin. ------------------------------------------------------- Date: 2001-Jan-17 13:06 By: tim_one Comment: Brrrr. HAVE_STAT and HAVE_FSTAT aren't defined in a usable way -- they're defined *by* (and local to) the files in question, if symbols like DONT_HAVE_STAT are *not* defined. So I'll rip that stuff out, get rid of the duplication, and move the HAVE_[F]STAT stuff into pyport.h first. Assuming that doesn't break the build for anyone else, and since we agree on what ought to be done next, I'll then rework the patch accordingly and check it in. ------------------------------------------------------- Date: 2001-Jan-17 05:56 By: gvanrossum Comment: Re the stat syscall: you seem to be using fstat(), and HAVE_FSTAT *does* exist. (It is used in fileobject.c.) And if you need stat(): HAVE_STAT is also defined (used in import.c). So I think you're in good shape there. I agree with Tim's other recommendations! ------------------------------------------------------- Date: 2001-Jan-16 22:15 By: tim_one Comment: I'm afraid this patch needs major work before we could use it. The big thing is that stat isn't std C, and as far as I can tell we don't even define a config symbol saying whether it's available. Even when it is available, on at least one oddball platform it apparently needs oddball declarations (see the STAT/FSTAT/etc macros in posixfile.c). And the Macintosh code isn't in the CVS tree (Jack Jansen owns it), so no telling how it's done there. *Standard* C doesn't have a good way to determine the size of a file, either. While Python's os.path.getsize() is supported on all platforms, that's done in platform-dependent ways in platform-dependent files, and there's no Python C API for it. So the first step would be to define and implement a PyOS_GetFileSize() C API, akin to the existing PyOS_GetLastModificationTime() (in getmtime.c). Beyond that, there are small things that need fixing. Like: + malloc's return should be cast to char* + but malloc shouldn't be called directly to begin with (see pymem.h) + ditto free() + the pointer test (buf > 0) doesn't make sense (buf != NULL was intended) Once we get beyond all that <wink>, I think a three-tiered strategy would be worth implementing: also declare a 16K stack buffer. If a file is small enough, read into that; else if less than 256K (as Guido asked) malloc a buffer as is done now; else give up. 75% of the .pyc files on my box are under 16K (90% of IDLE's), so that would save the bulk of the malloc/free calls due to this. ------------------------------------------------------- Date: 2001-Jan-16 13:36 By: pj99 Comment: No problem, Tim (on the alledged abruptness). In any case, it was useful - in that it helped motivate /f into proposing a fix, me into coding it, and you to consider applying it. All in all a useful result. Most thanks, Tim. ------------------------------------------------------- Date: 2001-Jan-15 20:26 By: tim_one Comment: Indeed, IDLE takes more than a full second to come up on my box, *much* longer than Notepad. Now that we have a clear goal, I assigned this patch to me <wink>. (OK, it's really that I was abrupt with Paul when this came up on c.l.py, and left him hanging there -- I owe him on this one). ------------------------------------------------------- Date: 2001-Jan-15 20:18 By: gvanrossum Comment: Oh, but I do care about the load time of Tkinter. :-) Anything to keep IDLE ahead of Komodo in the race. :-) ------------------------------------------------------- Date: 2001-Jan-15 20:05 By: tim_one Comment: I like the idea, but gimmicks like this make porting to tiny platforms harder when pushed "too far". People concerned about startup time seem mostly to deal with apps that e.g. fire up Python 1000s of times from shell scripts or cgi. They're not going to care about monster modules (like Tkinter and grail). So I think Paul's original 64K is a good compromise. ------------------------------------------------------- Date: 2001-Jan-15 19:39 By: gvanrossum Comment: Not a bad idea. I'd up the limit to 256K so Tkinter.pyc (comfortably) fits. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103252&group_id=5470 From noreply@sourceforge.net Thu Jan 18 05:39:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 21:39:24 -0800 Subject: [Patches] [Patch #103252] Startup optimize: read *.pyc as string, not with getc() Message-ID: <E14J7nA-0001Df-00@usw-sf-web1.sourceforge.net> Patch #103252 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: pj99 Assigned to : tim_one Summary: Startup optimize: read *.pyc as string, not with getc() Follow-Ups: Date: 2001-Jan-17 21:39 By: tim_one Comment: file.readlines() already uses a stack buffer at least 8Kb, so I wasn't worried much about that. But worried enough to make sure this got into the alpha release. We get away with it or we don't; not a big deal either way. ------------------------------------------------------- Date: 2001-Jan-17 21:23 By: pj99 Comment: You're welcome, Tim. Thanks for finishing it off! I was about to post saying that I was skeptical of the 16 Kb stack array, but since that's done (and since it was Guido himself suggesting it, and you agreeing to it), I won't go into that. Lets just say that I spent a past life working in a 4 Kb fixed length kernel stack. Good work. ------------------------------------------------------- Date: 2001-Jan-17 20:41 By: tim_one Comment: Thanks for pushing this, Paul! Checked in a variant as discussed here, marshal.c ver 1.59 and ACKS ver 1.71. The stat/fstat fiddling was done in a previous checkin. ------------------------------------------------------- Date: 2001-Jan-17 13:06 By: tim_one Comment: Brrrr. HAVE_STAT and HAVE_FSTAT aren't defined in a usable way -- they're defined *by* (and local to) the files in question, if symbols like DONT_HAVE_STAT are *not* defined. So I'll rip that stuff out, get rid of the duplication, and move the HAVE_[F]STAT stuff into pyport.h first. Assuming that doesn't break the build for anyone else, and since we agree on what ought to be done next, I'll then rework the patch accordingly and check it in. ------------------------------------------------------- Date: 2001-Jan-17 05:56 By: gvanrossum Comment: Re the stat syscall: you seem to be using fstat(), and HAVE_FSTAT *does* exist. (It is used in fileobject.c.) And if you need stat(): HAVE_STAT is also defined (used in import.c). So I think you're in good shape there. I agree with Tim's other recommendations! ------------------------------------------------------- Date: 2001-Jan-16 22:15 By: tim_one Comment: I'm afraid this patch needs major work before we could use it. The big thing is that stat isn't std C, and as far as I can tell we don't even define a config symbol saying whether it's available. Even when it is available, on at least one oddball platform it apparently needs oddball declarations (see the STAT/FSTAT/etc macros in posixfile.c). And the Macintosh code isn't in the CVS tree (Jack Jansen owns it), so no telling how it's done there. *Standard* C doesn't have a good way to determine the size of a file, either. While Python's os.path.getsize() is supported on all platforms, that's done in platform-dependent ways in platform-dependent files, and there's no Python C API for it. So the first step would be to define and implement a PyOS_GetFileSize() C API, akin to the existing PyOS_GetLastModificationTime() (in getmtime.c). Beyond that, there are small things that need fixing. Like: + malloc's return should be cast to char* + but malloc shouldn't be called directly to begin with (see pymem.h) + ditto free() + the pointer test (buf > 0) doesn't make sense (buf != NULL was intended) Once we get beyond all that <wink>, I think a three-tiered strategy would be worth implementing: also declare a 16K stack buffer. If a file is small enough, read into that; else if less than 256K (as Guido asked) malloc a buffer as is done now; else give up. 75% of the .pyc files on my box are under 16K (90% of IDLE's), so that would save the bulk of the malloc/free calls due to this. ------------------------------------------------------- Date: 2001-Jan-16 13:36 By: pj99 Comment: No problem, Tim (on the alledged abruptness). In any case, it was useful - in that it helped motivate /f into proposing a fix, me into coding it, and you to consider applying it. All in all a useful result. Most thanks, Tim. ------------------------------------------------------- Date: 2001-Jan-15 20:26 By: tim_one Comment: Indeed, IDLE takes more than a full second to come up on my box, *much* longer than Notepad. Now that we have a clear goal, I assigned this patch to me <wink>. (OK, it's really that I was abrupt with Paul when this came up on c.l.py, and left him hanging there -- I owe him on this one). ------------------------------------------------------- Date: 2001-Jan-15 20:18 By: gvanrossum Comment: Oh, but I do care about the load time of Tkinter. :-) Anything to keep IDLE ahead of Komodo in the race. :-) ------------------------------------------------------- Date: 2001-Jan-15 20:05 By: tim_one Comment: I like the idea, but gimmicks like this make porting to tiny platforms harder when pushed "too far". People concerned about startup time seem mostly to deal with apps that e.g. fire up Python 1000s of times from shell scripts or cgi. They're not going to care about monster modules (like Tkinter and grail). So I think Paul's original 64K is a good compromise. ------------------------------------------------------- Date: 2001-Jan-15 19:39 By: gvanrossum Comment: Not a bad idea. I'd up the limit to 256K so Tkinter.pyc (comfortably) fits. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103252&group_id=5470 From ping@lfw.org Thu Jan 18 07:51:48 2001 From: ping@lfw.org (Ka-Ping Yee) Date: Wed, 17 Jan 2001 23:51:48 -0800 (PST) Subject: [Patches] [Patch #101664] Add new unistr() builtin + PyObject_Unicode() C API In-Reply-To: <E14IukB-0008CG-00@usw-sf-web2.sourceforge.net> Message-ID: <Pine.LNX.4.10.10101172348060.1568-100000@skuld.kingmanhall.org> On Wed, 17 Jan 2001 noreply@sourceforge.net wrote: > Comment: > This patch adds a utility function unistr() which works just like > the standard builtin str() -- only that the return value will > always be a Unicode object. Sorry for barging in, but i have an issue/question: Why are unistr() and unicode() two separate functions? str() performs one task: convert to string. It can convert anything, including strings or Unicode strings, numbers, instances, etc. The other type-named functions e.g. int(), long(), float(), list(), tuple() are similar in intent. Why have unicode() just for converting strings to Unicode strings, and unistr() for converting everything else to a Unicode string? What does unistr(x) do differently from unicode(x) if x is a string? -- ?!ng From noreply@sourceforge.net Thu Jan 18 07:58:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 23:58:01 -0800 Subject: [Patches] [Patch #103258] Cookie.py docs: example incorrect Message-ID: <E14J9xJ-0003na-00@usw-sf-web3.sourceforge.net> Patch #103258 has been updated. Project: python Category: documentation Status: Closed Submitted by: ping Assigned to : ping Summary: Cookie.py docs: example incorrect Follow-Ups: Date: 2001-Jan-17 23:58 By: ping Comment: Checked in. ------------------------------------------------------- Date: 2001-Jan-17 07:18 By: fdrake Comment: Thanks; please check it in! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103258&group_id=5470 From mal@lemburg.com Thu Jan 18 09:52:12 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 18 Jan 2001 10:52:12 +0100 Subject: [Patches] [Patch #101664] Add new unistr() builtin + PyObject_Unicode()C API References: <Pine.LNX.4.10.10101172348060.1568-100000@skuld.kingmanhall.org> Message-ID: <3A66BCCC.14997FE3@lemburg.com> Ka-Ping Yee wrote: > > On Wed, 17 Jan 2001 noreply@sourceforge.net wrote: > > Comment: > > This patch adds a utility function unistr() which works just like > > the standard builtin str() -- only that the return value will > > always be a Unicode object. > > Sorry for barging in, but i have an issue/question: > > Why are unistr() and unicode() two separate functions? > > str() performs one task: convert to string. It can convert anything, > including strings or Unicode strings, numbers, instances, etc. > > The other type-named functions e.g. int(), long(), float(), list(), > tuple() are similar in intent. > > Why have unicode() just for converting strings to Unicode strings, > and unistr() for converting everything else to a Unicode string? > What does unistr(x) do differently from unicode(x) if x is a string? unistr() is meant to complement str() very closely. unicode() works as constructor for Unicode objects which can also take care of decoding encoded data. str() and unistr() don't provide this capability but instead always assume the default encoding. There's also a subtle difference in that str() and unistr() try the tp_str slot which unicode() doesn't. unicode() supports any character buffer which str() and unistr() don't. Perhaps you are right though in that we should make all three APIs behave in the same way with respect to coercing their arguments. This could hide some errors... still in the long run, I agree that the existing setup probably causes more confusion than good. Guido ? -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From noreply@sourceforge.net Thu Jan 18 16:02:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 08:02:45 -0800 Subject: [Patches] [Patch #103313] Include build directory when running "make test" Message-ID: <E14JHWP-0007NN-00@usw-sf-web2.sourceforge.net> Patch #103313 has been updated. Project: python Category: Build Status: Open Submitted by: akuchling Assigned to : nobody Summary: Include build directory when running "make test" ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103313&group_id=5470 From noreply@sourceforge.net Thu Jan 18 16:35:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 08:35:10 -0800 Subject: [Patches] [Patch #102989] Allow 'continue' inside 'try' clause Message-ID: <E14JI1m-0007bc-00@usw-sf-web2.sourceforge.net> 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: 2001-Jan-18 08:35 By: twouters Comment: It seems Jeremy doesn't have time to review it right now, either. Which is not suprising, looking at the number of tasks assigned to him ;) Maybe someone else can take a look at this ? It shouldn't be that hard, the patch isn't *that* controversial, and it would be nice to have this in alpha1, I do think. The patch still applies fine, though it gives some harmless offset/fuzz warnings. Also, you need either to bump the bytecode magic or remove all .pyc files for it to actually matter (or run 'make distclean'.) ------------------------------------------------------- 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 Jan 18 16:37:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 08:37:38 -0800 Subject: [Patches] [Patch #103048] Generate simple JUMP_FORWARD for 'break' outside 'try' Message-ID: <E14JI4A-0007cO-00@usw-sf-web2.sourceforge.net> 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: 2001-Jan-18 08:37 By: twouters Comment: I'm going to suggest postponing this patch until 2.2, unless someone comes up and disagrees :) This is not a terribly useful feature, it's not visible from the 'outside' to start with, and the benifits are unclear. I'm also not sure if it works properly yet. I mostly submitted this patch to get rid of the 'TODO' entry at the top of compile.c. ------------------------------------------------------- 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 Thu Jan 18 17:32:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 09:32:13 -0800 Subject: [Patches] [Patch #102989] Allow 'continue' inside 'try' clause Message-ID: <E14JIuz-0007wb-00@usw-sf-web2.sourceforge.net> 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: 2001-Jan-18 09:32 By: jhylton Comment: I will take a look at this patch before 2.1a1. I am trying to finish up some fairly major compiler changes, so it seems natural to review this patch next. ------------------------------------------------------- Date: 2001-Jan-18 08:35 By: twouters Comment: It seems Jeremy doesn't have time to review it right now, either. Which is not suprising, looking at the number of tasks assigned to him ;) Maybe someone else can take a look at this ? It shouldn't be that hard, the patch isn't *that* controversial, and it would be nice to have this in alpha1, I do think. The patch still applies fine, though it gives some harmless offset/fuzz warnings. Also, you need either to bump the bytecode magic or remove all .pyc files for it to actually matter (or run 'make distclean'.) ------------------------------------------------------- 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 Jan 18 17:38:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 09:38:51 -0800 Subject: [Patches] [Patch #103314] allow urllib.urlencode to work with multivalued parameters Message-ID: <E14JJ1P-0007zK-00@usw-sf-web2.sourceforge.net> Patch #103314 has been updated. Project: python Category: library Status: Open Submitted by: montanaro Assigned to : nobody Summary: allow urllib.urlencode to work with multivalued parameters ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103314&group_id=5470 From noreply@sourceforge.net Thu Jan 18 17:39:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 09:39:58 -0800 Subject: [Patches] [Patch #101137] Add raw packet support to socketmodule.c Message-ID: <E14JJ2U-0007zk-00@usw-sf-web2.sourceforge.net> Patch #101137 has been updated. Project: python Category: Modules Status: Open Submitted by: grante Assigned to : jhylton Summary: Add raw packet support to socketmodule.c Follow-Ups: Date: 2001-Jan-18 09:39 By: jhylton Comment: Is Grant still interested in this patch? I don't have time to fix it myself, but I would be happy to look at it again if we comments and questions are addressed. ------------------------------------------------------- Date: 2000-Aug-09 14:49 By: grante Comment: Patch has only been tested on Linux: RH6.2 (Intel). Patch is against 1.6b1 ------------------------------------------------------- Date: 2000-Aug-15 15:15 By: tim_one Comment: Assigned to Barry, since he just volunteered to rewrite all of Python's socket code anyway <wink>. ------------------------------------------------------- Date: 2000-Aug-24 14:27 By: jhylton Comment: Not sure about this patch. It needs to be tested on more platforms than just Linux, but I don't see that we'll have time before 2.0. There are several other issues that must be resolved, too. Thus, this patch falls subject to the feature freeze. Style points: Indention is wrong. The opening curly brace of an if belongs on the same line as the test. Whitespace is required around = and after commas in argument lists. The strncpy in makesockaddr does not check the size of the source string. It could overflow the buffer. In makesockaddr, a new socket is created just to look up the interface name associated with a particular interface. This seems wasteful, particularly in cases where few file descriptors are available. I'm not sure what the solution is, although it might be to change the makesockaddr function so that it takes the socket itself. Perhaps that socket address for AF_PACKET should also accept and/or produce interface numbers which the client can convert to names manually. The sockaddr_ll has members ssl_hatype and ssl_pkttype, which are not made accessible by this patch. It seems like they should be, but I am not sure. Can you use SOCK_DGRAM without specifying the packet type? getsockaddrarg is handled, but getsockaddrlen is not. Question: Are there any other constants that should be added? This relates to the packet type question. * ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101137&group_id=5470 From noreply@sourceforge.net Thu Jan 18 17:42:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 09:42:16 -0800 Subject: [Patches] [Patch #103314] allow urllib.urlencode to work with multivalued parameters Message-ID: <E14JJ4i-00080s-00@usw-sf-web2.sourceforge.net> Patch #103314 has been updated. Project: python Category: library Status: Open Submitted by: montanaro Assigned to : fdrake Summary: allow urllib.urlencode to work with multivalued parameters Follow-Ups: Date: 2001-Jan-18 09:42 By: montanaro Comment: Assigned to Fred for starters because it does have a doc change. Fred, Guido probably wants to look at it next, but you're a better judge of who might have more free time... S ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103314&group_id=5470 From noreply@sourceforge.net Thu Jan 18 18:01:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 10:01:32 -0800 Subject: [Patches] [Patch #101137] Add raw packet support to socketmodule.c Message-ID: <E14JJNM-0005gt-00@usw-sf-web1.sourceforge.net> Patch #101137 has been updated. Project: python Category: Modules Status: Open Submitted by: grante Assigned to : jhylton Summary: Add raw packet support to socketmodule.c Follow-Ups: Date: 2001-Jan-18 10:01 By: nobody Comment: Yes, I'm still interested in this patch. Winthin the next week or two I'll try to get a revised patch submitted that addresses some of the comments. Two things I can't do much about are: 1) I only have Linux systems for testing: I don't have root privledges on any other type of system. 2) Unless it is agreed to change parameters for makesockaddr, I can't do anything except create a temporary socket in order to look up the interface name. I suppose I could require user code to provide an interface index, but I don't really like that option since it diverges quite a bit from the "C" usage. ------------------------------------------------------- Date: 2001-Jan-18 09:39 By: jhylton Comment: Is Grant still interested in this patch? I don't have time to fix it myself, but I would be happy to look at it again if we comments and questions are addressed. ------------------------------------------------------- Date: 2000-Aug-09 14:49 By: grante Comment: Patch has only been tested on Linux: RH6.2 (Intel). Patch is against 1.6b1 ------------------------------------------------------- Date: 2000-Aug-15 15:15 By: tim_one Comment: Assigned to Barry, since he just volunteered to rewrite all of Python's socket code anyway <wink>. ------------------------------------------------------- Date: 2000-Aug-24 14:27 By: jhylton Comment: Not sure about this patch. It needs to be tested on more platforms than just Linux, but I don't see that we'll have time before 2.0. There are several other issues that must be resolved, too. Thus, this patch falls subject to the feature freeze. Style points: Indention is wrong. The opening curly brace of an if belongs on the same line as the test. Whitespace is required around = and after commas in argument lists. The strncpy in makesockaddr does not check the size of the source string. It could overflow the buffer. In makesockaddr, a new socket is created just to look up the interface name associated with a particular interface. This seems wasteful, particularly in cases where few file descriptors are available. I'm not sure what the solution is, although it might be to change the makesockaddr function so that it takes the socket itself. Perhaps that socket address for AF_PACKET should also accept and/or produce interface numbers which the client can convert to names manually. The sockaddr_ll has members ssl_hatype and ssl_pkttype, which are not made accessible by this patch. It seems like they should be, but I am not sure. Can you use SOCK_DGRAM without specifying the packet type? getsockaddrarg is handled, but getsockaddrlen is not. Question: Are there any other constants that should be added? This relates to the packet type question. * ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101137&group_id=5470 From noreply@sourceforge.net Thu Jan 18 18:09:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 10:09:55 -0800 Subject: [Patches] [Patch #103314] allow urllib.urlencode to work with multivalued parameters Message-ID: <E14JJVT-0005jZ-00@usw-sf-web1.sourceforge.net> Patch #103314 has been updated. Project: python Category: library Status: Open Submitted by: montanaro Assigned to : fdrake Summary: allow urllib.urlencode to work with multivalued parameters Follow-Ups: Date: 2001-Jan-18 10:09 By: gvanrossum Comment: Comment: I would test for doseq once, and then have two loops: one with the old behavior and one with the new. Also, you might want to catch Unicode and explicitly force it into ASCII (rather than committing to a conversion without knowing what's the right thing). ------------------------------------------------------- Date: 2001-Jan-18 09:42 By: montanaro Comment: Assigned to Fred for starters because it does have a doc change. Fred, Guido probably wants to look at it next, but you're a better judge of who might have more free time... S ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103314&group_id=5470 From guido@digicool.com Thu Jan 18 18:09:24 2001 From: guido@digicool.com (Guido van Rossum) Date: Thu, 18 Jan 2001 13:09:24 -0500 Subject: [Patches] [Patch #101664] Add new unistr() builtin + PyObject_Unicode()C API In-Reply-To: Your message of "Thu, 18 Jan 2001 10:52:12 +0100." <3A66BCCC.14997FE3@lemburg.com> References: <Pine.LNX.4.10.10101172348060.1568-100000@skuld.kingmanhall.org> <3A66BCCC.14997FE3@lemburg.com> Message-ID: <200101181809.NAA08231@cj20424-a.reston1.va.home.com> Let's redirect this to python-dev, please! --Guido van Rossum (home page: http://www.python.org/~guido/) From noreply@sourceforge.net Thu Jan 18 21:23:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 13:23:26 -0800 Subject: [Patches] [Patch #103313] Include build directory when running "make test" Message-ID: <E14JMWk-0000nG-00@usw-sf-web2.sourceforge.net> Patch #103313 has been updated. Project: python Category: Build Status: Closed Submitted by: akuchling Assigned to : akuchling Summary: Include build directory when running "make test" Follow-Ups: Date: 2001-Jan-18 13:23 By: akuchling Comment: Checked in on Barry's urging. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103313&group_id=5470 From noreply@sourceforge.net Thu Jan 18 21:30:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 13:30:58 -0800 Subject: [Patches] [Patch #103305] function attribute segfault Message-ID: <E14JMe2-0004JE-00@usw-sf-web1.sourceforge.net> Patch #103305 has been updated. Project: python Category: core (C code) Status: Open Submitted by: greg_ball Assigned to : bwarsaw Summary: function attribute segfault Follow-Ups: Date: 2001-Jan-18 13:30 By: bwarsaw Comment: Assigning this to me to look at later. ------------------------------------------------------- Date: 2001-Jan-17 14:51 By: greg_ball Comment: I have ready a new version of the patch (I won't upload it yet in case it's not welcome) which does the following: reference to f.__dict__ or f.func_dict returns a new dictionary if f did not previously have one. (Similar to what happens on first assignent to arbitrary attribute.) Then the following code works: >>> def f(): pass ... >>> d=f.__dict__ >>> f.a=1 >>> d['a'] 1 instead of d being an unsubscriptable object. To me it seems nasty if somethings __dict__ attribute might not be a dictionary. Since f.__dict__ never now _appears_ to be None, I also removed the feature of assigning it to None to get rid of it. del f.__dict__ can now be used for this purpose. (previously only for creating sig11 =) ) One other thought: as it stands, function attributes are strangely behaving in restricted mode. You can't set any attributes directly. You can't directly get attributes that don't start with an underscore. However, you can get __dict__ and then do anything you like to it... ------------------------------------------------------- Date: 2001-Jan-17 14:03 By: greg_ball Comment: At two points, the code did not check for NULL, leading to segmentation fault soon after. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103305&group_id=5470 From noreply@sourceforge.net Fri Jan 19 01:57:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 17:57:26 -0800 Subject: [Patches] [Patch #103305] function attribute segfault Message-ID: <E14JQnu-0005cm-00@usw-sf-web1.sourceforge.net> Patch #103305 has been updated. Project: python Category: core (C code) Status: Open Submitted by: greg_ball Assigned to : bwarsaw Summary: function attribute segfault Follow-Ups: Date: 2001-Jan-18 17:57 By: gvanrossum Comment: This is a high priority patch -- needs to be deal with before 2.1a1 can go out. ------------------------------------------------------- Date: 2001-Jan-18 13:30 By: bwarsaw Comment: Assigning this to me to look at later. ------------------------------------------------------- Date: 2001-Jan-17 14:51 By: greg_ball Comment: I have ready a new version of the patch (I won't upload it yet in case it's not welcome) which does the following: reference to f.__dict__ or f.func_dict returns a new dictionary if f did not previously have one. (Similar to what happens on first assignent to arbitrary attribute.) Then the following code works: >>> def f(): pass ... >>> d=f.__dict__ >>> f.a=1 >>> d['a'] 1 instead of d being an unsubscriptable object. To me it seems nasty if somethings __dict__ attribute might not be a dictionary. Since f.__dict__ never now _appears_ to be None, I also removed the feature of assigning it to None to get rid of it. del f.__dict__ can now be used for this purpose. (previously only for creating sig11 =) ) One other thought: as it stands, function attributes are strangely behaving in restricted mode. You can't set any attributes directly. You can't directly get attributes that don't start with an underscore. However, you can get __dict__ and then do anything you like to it... ------------------------------------------------------- Date: 2001-Jan-17 14:03 By: greg_ball Comment: At two points, the code did not check for NULL, leading to segmentation fault soon after. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103305&group_id=5470 From noreply@sourceforge.net Fri Jan 19 02:32:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 18:32:03 -0800 Subject: [Patches] [Patch #103297] __all__ values for a handful of modules Message-ID: <E14JRLP-0001Ol-00@usw-sf-web3.sourceforge.net> Patch #103297 has been updated. Project: python Category: library Status: Open Submitted by: montanaro Assigned to : nobody Summary: __all__ values for a handful of modules Follow-Ups: Date: 2001-Jan-18 18:32 By: gvanrossum Comment: Nice, Skip! I wonder if the "test" functions should really be included in __all__? Especially StringIO's test isn't generally needed. I'd be happy if I had to import it explicitly using "from StringIO import test" if I really wanted it. Ditto for the HTTP server classes. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103297&group_id=5470 From noreply@sourceforge.net Fri Jan 19 02:41:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 18:41:16 -0800 Subject: [Patches] [Patch #103303] patch to fix dis.py in the face of function attributes Message-ID: <E14JRUK-0001RW-00@usw-sf-web3.sourceforge.net> Patch #103303 has been updated. Project: python Category: library Status: Closed Submitted by: bwarsaw Assigned to : gvanrossum Summary: patch to fix dis.py in the face of function attributes Follow-Ups: Date: 2001-Jan-18 18:41 By: gvanrossum Comment: Checked in, with one change: test for im_func first and for func_code second, like it did before. I was surprised that with the test for func_code first it worked for (un)bound methods, but it really did! The reason is that if C.f is an unbound method, the expression C.f.func_code (which previously was not defined) now passes the func_code attribute to the function! Still, it's more logical to test for im_func first so we don't rely on this dubious behavior. Closed. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103303&group_id=5470 From noreply@sourceforge.net Fri Jan 19 03:04:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 19:04:01 -0800 Subject: [Patches] [Patch #102549] simpler, faster(!) implementation of string.join Message-ID: <E14JRqL-0005vk-00@usw-sf-web1.sourceforge.net> Patch #102549 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: mwh Assigned to : tim_one Summary: simpler, faster(!) implementation of string.join Follow-Ups: Date: 2001-Jan-18 19:04 By: tim_one Comment: Agree the rewrite was a good idea. Thanks! Checked in a derived patch, in stringobject.c rev 2.98. That also fixes two join bugs that have been around at least since 2.0 was released (see checkin comment). ------------------------------------------------------- Date: 2000-Nov-27 12:40 By: mwh Comment: attempting to fix a but in string.join, I realised that I didn't understand the current implementation. So I rewrote it. In doing so, I found the bug, but as my rewrite seems to be a little faster I thought I'd submit it. The additional clarity is the main point though. ------------------------------------------------------- Date: 2000-Nov-27 13:32 By: gvanrossum Comment: Tim -- can you review this? ------------------------------------------------------- Date: 2000-Nov-27 13:54 By: gvanrossum Comment: In Python-dev, /F says: your patch changes the behaviour of join on non-standard sequences. if you use join on a long synthetic sequence, your new version may run out of memory where the old one worked just fine. not sure that's a good idea. -0 ------------------------------------------------------- Date: 2000-Nov-27 13:57 By: gvanrossum Comment: And then later: looking again, this was obviously only true for the unicode version (which uses PySequence_GetItem), not for the 8-bit string version (which uses the PySequence_Fast API). maybe we should change the 8-bit implementation instead? if not, +1. </F> ------------------------------------------------------- Date: 2000-Nov-28 00:26 By: mwh Comment: oops - my code had a bug. 'sep'.join(['a','b']) would return 'asepbsep'. ------------------------------------------------------- Date: 2000-Nov-28 09:42 By: mwh Comment: oops again - this now doesn't dump core with empty sequences... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102549&group_id=5470 From noreply@sourceforge.net Fri Jan 19 02:56:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 18:56:04 -0800 Subject: [Patches] [Patch #103318] non-recursive makefile Message-ID: <E14JRie-0001WC-00@usw-sf-web3.sourceforge.net> Patch #103318 has been updated. Project: python Category: Build Status: Open Submitted by: nascheme Assigned to : nobody Summary: non-recursive makefile Follow-Ups: Date: 2001-Jan-18 18:56 By: gvanrossum Comment: I'm in a quandary. This is really awesone! But a bit too rough to add to the 2.1a1 release. You don't seem to deal with buildno properly -- what's the problem there? Also, I seem to recall that the "-o file.o" option is not universal amongst C compilers. Could someone who uses a non-GCC compiler (e.g. SunPro, or HP, or AIX) check the portability of this Makefile? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103318&group_id=5470 From noreply@sourceforge.net Fri Jan 19 03:09:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 19:09:57 -0800 Subject: [Patches] [Patch #103297] __all__ values for a handful of modules Message-ID: <E14JRw5-0001aG-00@usw-sf-web3.sourceforge.net> Patch #103297 has been updated. Project: python Category: library Status: Open Submitted by: montanaro Assigned to : nobody Summary: __all__ values for a handful of modules Follow-Ups: Date: 2001-Jan-18 19:09 By: montanaro Comment: Yeah, I wondered about including "test". I included it only because I thought I remembered someone mentioning that in a previous thread. I'll remove "test" from __all__ in my next update. Assuming everything else is okay, I will keep adding to the number of modified modules. ------------------------------------------------------- Date: 2001-Jan-18 18:32 By: gvanrossum Comment: Nice, Skip! I wonder if the "test" functions should really be included in __all__? Especially StringIO's test isn't generally needed. I'd be happy if I had to import it explicitly using "from StringIO import test" if I really wanted it. Ditto for the HTTP server classes. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103297&group_id=5470 From noreply@sourceforge.net Fri Jan 19 03:18:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 19:18:11 -0800 Subject: [Patches] [Patch #103323] trivial tests of all untested modules Message-ID: <E14JS43-0005zZ-00@usw-sf-web1.sourceforge.net> Patch #103323 has been updated. Project: python Category: None Status: Open Submitted by: jhylton Assigned to : nobody Summary: trivial tests of all untested modules ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103323&group_id=5470 From noreply@sourceforge.net Thu Jan 18 23:14:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 15:14:47 -0800 Subject: [Patches] [Patch #103318] non-recursive makefile Message-ID: <E14JOGV-0000U7-00@usw-sf-web3.sourceforge.net> Patch #103318 has been updated. Project: python Category: Build Status: Open Submitted by: nascheme Assigned to : nobody Summary: non-recursive makefile ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103318&group_id=5470 From noreply@sourceforge.net Thu Jan 18 23:56:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 15:56:32 -0800 Subject: [Patches] [Patch #102847] fix a memory leak Message-ID: <E14JOuu-0001cS-00@usw-sf-web2.sourceforge.net> Patch #102847 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: cgw Assigned to : jhylton Summary: fix a memory leak Follow-Ups: Date: 2001-Jan-18 15:56 By: jhylton Comment: no longer relevant; the mainloop is different ------------------------------------------------------- Date: 2001-Jan-13 10:40 By: moshez Comment: 102337 is now closed. ------------------------------------------------------- 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 Thu Jan 18 23:57:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 15:57:53 -0800 Subject: [Patches] [Patch #101702] Modify co_filename in frozen programs Message-ID: <E14JOwD-0001cx-00@usw-sf-web2.sourceforge.net> Patch #101702 has been updated. Project: python Category: demos and tools Status: Open Submitted by: lhudson Assigned to : mhammond Summary: Modify co_filename in frozen programs Follow-Ups: Date: 2001-Jan-18 15:57 By: jhylton Comment: (somewhat) randomly reassigned; don't have time to look at this ------------------------------------------------------- Date: 2000-Sep-29 04:39 By: lhudson Comment: A new feature for freeze. This patch was developed primarily to reduce the size of the frozen binary. It is particularly useful when freezing for 'small' platforms, such as Palm OS, where you really want to save that last miserable byte. A limitation of this patch is that it does not provide any feedback about the replacements being made. As the path matching is case-sensitive this may lead to unexpected behaviour for DOS and Windows people, eg > freeze.py -r C:\Python\Lib\=py\ goats.py should probably be: > freeze.py -r c:\python\lib\=py\ goats.py ------------------------------------------------------- Date: 2000-Sep-29 07:28 By: jhylton Comment: This sounds like a reasonable enough feature, but we are in feature freeze for Python 2.0. ------------------------------------------------------- Date: 2000-Oct-23 12:33 By: gvanrossum Comment: I like the idea, but I have a few suggestions. - To avoid the case sensitivity issue you mention, you could use os.path.normpath() before the string comparisons. - Rather than writing to a real temporary file, you could marshal to a string and than unmarshal from a StringIO file. - And the big whopper: rather than using a modified version of unmarshal, I suggest writing a recursive code object transformer. It takes a code object and a replace_paths list, and returns a similar code object with the co_filename attribute changed according to the list. The trick is that it should also do this, recursively, to any code object found in the co_consts tuple. (That's the only place where code objects can occur recursively.) While this is probably not much less code than the marshaller you wrote, it has the advantage of not being dependent on the details of the marshal format. Please upload a new patch -- I'm interested in getting this into Python 2.1. ------------------------------------------------------- Date: 2000-Oct-25 01:36 By: lhudson Comment: A recursive code object transformer has been implemented as a member of the ModuleFinder. Case sensitivity issue: normpath strips trailing '/' or '\\' which reduces the flexibility of the path replacement. It also does not seem to solve the case-sensitivity problem: D:\>python Python 2.0 (#8, Oct 17 2000, 15:27:24) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import os >>> os.path.normpath("c:\\python\\lib\\") 'c:\\python\\lib' >>> os.path.normpath("c:\\python\\Lib\\") 'c:\\python\\Lib' >>> ModuleFinder's debugging system is used to report the status of each unique path encountered. Temporary file: marshal.dump() and marshal.load() only work with file objects, not file-like objects. Now that new code objects are being created there is no longer any reason to re-marshal so this problem disappears. ------------------------------------------------------- Date: 2000-Oct-25 04:19 By: gvanrossum Comment: Thanks for the new patch! I'll assign this to Jeremy for further review and to carry it to completion. (Jeremy, if you're swamped, please find someone else to do it.) Re normpath: my mistake -- I meant normcase. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101702&group_id=5470 From noreply@sourceforge.net Fri Jan 19 00:03:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 16:03:42 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14JP1q-000573-00@usw-sf-web1.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : nascheme Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-18 16:03 By: loewis Comment: The patch looks ok in general, pending resolution of the issues on the PEP itself. Some nits: Integration with GC is still fuzzy. If an instance is GC collected and had a weak ref to it and the weak ref had a callback and the callback choses to resurrect the object, semantics is unclear. This is equivalent to the object having an __del__; the GC would normally *not* collect such objects, but put them into gc.garbage. Proposed resolution: it is a fatal error to resurrect an object in a weakref callback. Hashing: it appears that the hash of a weakref can change when the underlying object goes away. If the weakref is used as key in a dictionary, it appears to be impossible to get the key out of the dictionary after the underlying object is gone. Proposed resolution: a proxy weak ref should cache the hash of the underlying object after its hash function was called for the first time. Comparing: why is the return value of tp_compare -1 when try_3way_compare expects -2 on error? Shouldn't there be some exception set when the underlying object goes away? ------------------------------------------------------- Date: 2001-Jan-17 13:53 By: fdrake Comment: Ok, I tihnk this is it! http://starship.python.net/crew/fdrake/patches/weakref.patch-5 This patch fixes the compilation problems from the previoous patch related to the introduction of rich comparisons, and makes a change in the way new objects are initialized by PyObject_New() and PyObject_NEW() (and all their friends!) -- those functions now know to initialize the weak reference list to NULL for objects which support weak references. Without this change, more places in the code (especially extension modules) need to know more about initialization of weakly-referencable objects. For instance, the "cPickle" and "new" modules both can create instances without calling the code in classobject.c (using PyObject_New()), causing core dumps when such instances are deallocated if the weak-reference list for instances was not properly initialized. Since these modules (properly) tried to avoid call PyInstance_New(), core dumps ensued and the world fell apart. By moving the initialization of the weak reference list into the core object allocators, this problem is averted and extension code to construct new weakly referencable types is simplified. The documentation still needs work, and there are a few new entries for the Python/C API manual as well. A new constructor for instances, PyInstance_NewRaw(), will be added in a separate patch. ------------------------------------------------------- Date: 2001-Jan-17 11:58 By: nascheme Comment: The magic test is: ./python Lib/test/regrtest.py test_weakref test_new Try adding this patch: --- Modules/newmodule.c 2000/11/13 20:29:20 2.29 +++ Modules/newmodule.c 2001/01/17 19:55:46 @@ -24,6 +24,7 @@ Py_INCREF(dict); inst->in_class = (PyClassObject *)klass; inst->in_dict = dict; + inst->in_weakreflist = NULL; PyObject_GC_Init(inst); return (PyObject *)inst; } ------------------------------------------------------- Date: 2001-Jan-17 08:04 By: fdrake Comment: New version of the patch that's still broken but doesn't conflict with the rich comparisons changes: http://starship.python.net/crew/fdrake/patches/weakref.patch-4 ------------------------------------------------------- Date: 2001-Jan-16 21:35 By: fdrake Comment: Added a new (but broken!) version of the patch that fixes WeakDictionary.get() but doesn't interact properly with GC (appearantly) -- not usable as is: http://starship.python.net/crew/fdrake/patches/weakref.patch-3 Neil made the mistake of volunteering to look at the current problem, so assigning to him. (Thanks!) ------------------------------------------------------- Date: 2001-Jan-16 19:39 By: tim_one Comment: Just mentioning a general scenario in which weak keys are the bee's knees: sometimes you want to add attributes to objects dynamically, in ways the original class author(s -- may cut across many classes! even non-instance objects; or objects from extension modules that don't support setattr) never anticipated. Like maybe a German translation of the object's docstrings; or a list of JPEG contents referenced by a URLish object; or a table of usage statistics on methods and functions; etc. Then it's natural to use the conceptual attr name as the name of a dict instead, and write attr[object] = whatever instead of object.attr = whatever There's no point keeping the "whatever" around when the object goes away, but a regular dict makes the object and its "whatever" immortal. A dict with weak keys is exactly on-target. ------------------------------------------------------- Date: 2001-Jan-16 19:14 By: fdrake Comment: I'm not entirely sure why one would want weak keys rather than weak values, but I suspect it has to do with expectations of how the dict will be used in applications. I don't think it would be hard to support both flavors of dictionaries using the primitive reference objects. The constructor does not check that all incoming values are weak because that isn't required. It uses self.update() rather than self.data.update() to perform the inclusion, so any mapping that supports .keys() and .__getitem__() is sufficient. Some additional checking could be done to make sure that all added entries can be created before inserting any of them, offering more atomicity. .get() will be fixed in the next version of the patch; thanks! I've added GC support, but don't have it working quite right. I'm trying to isolate the failure now. ------------------------------------------------------- Date: 2001-Jan-12 14:36 By: loewis Comment: The weak dictionary data type needs more clarification in documentation and implementation. In java.util.WeakHashMap, they keys are weak, not the values (i.e. once the key is forgotten, the entry is cleared). In http://www.handshake.de/~dieter/weakdict.html, the values are weak, but it raises KeyErrors for entries that are collected. The initializer of a weak dict does not check the invariant (all values are weak). get() of a weakdict does not support an optional second parameter. weakref and friends need to participate in garbage collection, as the reference to the callback can create a cycle. ------------------------------------------------------- Date: 2001-Jan-12 11:27 By: fdrake Comment: Updated patch to also support proxy semantics using the same invalidation machinery as the basic weak reference type. The additional code is *heavily* borrowed from Neil Schemenauer. ------------------------------------------------------- Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Fri Jan 19 00:04:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 16:04:00 -0800 Subject: [Patches] [Patch #102891] Alternative readline module Message-ID: <E14JP28-0001ev-00@usw-sf-web2.sourceforge.net> Patch #102891 has been updated. Project: python Category: Modules Status: Open Submitted by: nascheme Assigned to : nascheme Summary: Alternative readline module Follow-Ups: Date: 2001-Jan-18 16:04 By: gvanrossum Comment: Neil, I'm assigning this back to you and reopening it (from Accepted). It seems patches with status Accepted frequently get lost -- probably because "My Patches" doesn't show them. In any case, I think you should just check this in ASAP and close the patch! ------------------------------------------------------- Date: 2001-Jan-16 06:59 By: gvanrossum Comment: Ah, of course. I saw that, even played with it a bit. Looks cool, but I don't know about using it to replace readline. But you might want to change the name given that pyrl is already taken. ;-) ------------------------------------------------------- Date: 2001-Jan-16 06:34 By: mwh Comment: pyrl is my line reader written in Python that I've been intermittently blathering about on python-dev: http://www-jcsu.jesus.cam.ac.uk/~mwh21/hacks/pyrl-0.2.0.tar.gz it's still very experimental, though. ------------------------------------------------------- Date: 2001-Jan-16 05:41 By: gvanrossum Comment: What's pyrl in this context? A Google search turns up a bunch of references to a Perl preprocessor that takes Pythonic syntax and translates it into Perl. :-) [ESR replied Neil via email: "I'm on it. Gotta ship my PC9 paper first, though."] ------------------------------------------------------- Date: 2001-Jan-16 02:23 By: mwh Comment: You could defer the decision between readline and edline until runtime, as in: (will sf mangle this? we'll see) Index: Modules/main.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/main.c,v retrieving revision 1.47 diff -c -r1.47 main.c *** Modules/main.c 2000/12/15 22:00:54 1.47 --- Modules/main.c 2001/01/16 10:19:45 *************** *** 267,274 **** isatty(fileno(stdin))) { PyObject *v; v = PyImport_ImportModule("readline"); ! if (v == NULL) PyErr_Clear(); else Py_DECREF(v); } --- 267,280 ---- isatty(fileno(stdin))) { PyObject *v; v = PyImport_ImportModule("readline"); ! if (v == NULL) { PyErr_Clear(); + v = PyImport_ImportModule("edline"); + if (v == NULL) + PyErr_Clear(); + else + Py_DECREF(v); + } else Py_DECREF(v); } (and pyrl's not going to be ready for 2.1, by a country mile...) ------------------------------------------------------- Date: 2001-Jan-15 21:30 By: nascheme Comment: Hmm, I still like pyrl better. What to do about GNU readline now that its in Setup.conf? You can't enable them both and I don't feel comfortable enough with autoconf to fix things. ESR, if you could add the magic to test for termios that would be cool. configure should use readline if its there and fall back to edline if termios is available. Feel free to bounce it back to me if you don't have time. ------------------------------------------------------- Date: 2001-Jan-03 06:10 By: gvanrossum Comment: Neil, this has now status Accepted. Go ahead and check it in! ------------------------------------------------------- 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 Fri Jan 19 00:05:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 16:05:25 -0800 Subject: [Patches] [Patch #102971] build_ext -L typo fix Message-ID: <E14JP3V-0000jg-00@usw-sf-web3.sourceforge.net> Patch #102971 has been updated. Project: python Category: distutils Status: Closed Submitted by: calvin Assigned to : akuchling Summary: build_ext -L typo fix Follow-Ups: Date: 2001-Jan-18 16:05 By: gvanrossum Comment: This was checked in alrady. ------------------------------------------------------- Date: 2001-Jan-08 19:16 By: akuchling Comment: Checked in; leaving it in "Accepted" so Greg can review it (and possibly back it out) when he gets back. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102971&group_id=5470 From noreply@sourceforge.net Fri Jan 19 00:05:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 16:05:19 -0800 Subject: [Patches] [Patch #102860] Add PyDict_Update() function to C API. Message-ID: <E14JP3P-0001fE-00@usw-sf-web2.sourceforge.net> Patch #102860 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: fdrake Assigned to : jhylton Summary: Add PyDict_Update() function to C API. Follow-Ups: Date: 2001-Jan-18 16:05 By: jhylton Comment: Oh, well. The latest version of compile.c doesn't need the subtraction, so I can't provide any motivation for this feature. ------------------------------------------------------- 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 Jan 19 00:05:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 16:05:56 -0800 Subject: [Patches] [Patch #102971] build_ext -L typo fix Message-ID: <E14JP40-0000k7-00@usw-sf-web3.sourceforge.net> Patch #102971 has been updated. Project: python Category: distutils Status: Accepted Submitted by: calvin Assigned to : akuchling Summary: build_ext -L typo fix Follow-Ups: Date: 2001-Jan-18 16:05 By: gvanrossum Comment: This was checked in alrady. ------------------------------------------------------- Date: 2001-Jan-18 16:05 By: gvanrossum Comment: This was checked in alrady. ------------------------------------------------------- Date: 2001-Jan-08 19:16 By: akuchling Comment: Checked in; leaving it in "Accepted" so Greg can review it (and possibly back it out) when he gets back. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102971&group_id=5470 From noreply@sourceforge.net Fri Jan 19 00:07:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 16:07:21 -0800 Subject: [Patches] [Patch #102863] another memory leak Message-ID: <E14JP5N-0001fk-00@usw-sf-web2.sourceforge.net> Patch #102863 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: cgw Assigned to : jhylton Summary: another memory leak Follow-Ups: Date: 2001-Jan-18 16:07 By: jhylton Comment: not relevant any longer ------------------------------------------------------- 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 Jan 19 00:07:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 16:07:54 -0800 Subject: [Patches] [Patch #103140] Minor fixes and enhancements for 2.0 docs. Message-ID: <E14JP5u-0001g9-00@usw-sf-web2.sourceforge.net> Patch #103140 has been updated. Project: python Category: documentation Status: Closed Submitted by: esr Assigned to : esr Summary: Minor fixes and enhancements for 2.0 docs. Follow-Ups: Date: 2001-Jan-18 16:07 By: gvanrossum Comment: This was checked in by Fred. ------------------------------------------------------- Date: 2001-Jan-09 14:06 By: fdrake Comment: Please check this in. Note that I will be making a couple of markup adjustments in libstat.tex after you've checked it in -- it's easier to make the changes than to describe them. ;-) Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103140&group_id=5470 From noreply@sourceforge.net Fri Jan 19 00:08:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 16:08:34 -0800 Subject: [Patches] [Patch #102971] build_ext -L typo fix Message-ID: <E14JP6Y-0000kq-00@usw-sf-web3.sourceforge.net> Patch #102971 has been updated. Project: python Category: distutils Status: Accepted Submitted by: calvin Assigned to : gward Summary: build_ext -L typo fix Follow-Ups: Date: 2001-Jan-18 16:08 By: gvanrossum Comment: Sorry. I didn't realize why Andrew left it Accepted. ------------------------------------------------------- Date: 2001-Jan-18 16:05 By: gvanrossum Comment: This was checked in alrady. ------------------------------------------------------- Date: 2001-Jan-18 16:05 By: gvanrossum Comment: This was checked in alrady. ------------------------------------------------------- Date: 2001-Jan-08 19:16 By: akuchling Comment: Checked in; leaving it in "Accepted" so Greg can review it (and possibly back it out) when he gets back. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102971&group_id=5470 From noreply@sourceforge.net Fri Jan 19 00:16:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 16:16:04 -0800 Subject: [Patches] [Patch #103283] Rich comparisons technical preview Message-ID: <E14JPDo-0005AY-00@usw-sf-web1.sourceforge.net> Patch #103283 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: gvanrossum Assigned to : gvanrossum Summary: Rich comparisons technical preview Follow-Ups: Date: 2001-Jan-18 16:16 By: gvanrossum Comment: This is all checked in. There are still loose ends, but no need to keep the patch open. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103283&group_id=5470 From noreply@sourceforge.net Fri Jan 19 00:24:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 16:24:58 -0800 Subject: [Patches] [Patch #103250] Optimize a strspn() out of startup Message-ID: <E14JPMQ-0001lT-00@usw-sf-web2.sourceforge.net> Patch #103250 has been updated. Project: python Category: None Status: Closed Submitted by: pj99 Assigned to : gvanrossum Summary: Optimize a strspn() out of startup Follow-Ups: Date: 2001-Jan-18 16:24 By: gvanrossum Comment: OK, I've applied this, and am closing the patch. It's actually disturbing that the parser uses isalnum() -- the language is not *supposed* to accept non-ASCII letters in the Latin-1 character set, but under certain circumstances, that may be the effect! ------------------------------------------------------- Date: 2001-Jan-16 21:33 By: nobody Comment: At least the Python tokenizer uses (isalnum(c) || c == '_') ... ------------------------------------------------------- Date: 2001-Jan-16 14:28 By: pj99 Comment: The (isalpha(c) || isdigit(c) || c=='_') suggestion seems to me to be the better idea. However, how does this interact with localization and unicode and such? Do we want exactly the list of specified NAME_CHARS allowed here, or do we want a localized set of alpha/digit/'_' chars allowed here? As for the other 98.5%, I have a nice table from my profiler, showing where the time is, but I don't know how to put that table here, without mangling the format. It shows about 19% of the time in malloc/free, about 15% of the time in pthread code, about 14% in dictobject.c code, and about 6% in acceler.c code (esp. fixstate()). And of course the getc() savings that come from loading an entire *.pyc file in a single fread(), as being persued in patch 103252, saves perhaps 24% of what's left. (Note, the 19,15,14 and 6 percents above are based on what's left, _after_ the 24% getc() optimization is applied). *If* much of the malloc/free use is for lots of small chunks, coming and going, as tends to happen with object based code, then I could imagine a custom allocator (based on top of malloc/free, so quite portable). This might save much of the pthread cost as well, if the custom allocator kept separate pools of small chunks of malloc'd memory, per thread, avoiding locks (if that can be done ?). I have done work in the past in a C++/mmap environment that reduced the costs of many small dynamic allocations to near zero, both space and time. But that relied on the second argument to C++ delete(), which is the size of the object being deleted, as well as on an AUTOGROW mmap region. This is not applicable to C, nor is it particularly portable. Still, something like this, perhaps requiring recoding of some critical free() calls to use an optional method that passed in a second sizeof argument, might be the next most useful optimization. Someone else in the news thread that was parent to this patch suggested emacs-like dump facility, to capture the state of the Python interpreter after it has loaded the usual suspects. But I can't imagine that this would be sufficiently portable or maintainable to be relevant. As someone who has had to maintain O.S./library support for and compatibility with this emacs dump facility, I have grown to dislike it strongly. ------------------------------------------------------- Date: 2001-Jan-15 23:25 By: nobody Comment: Why not (isalpha(c) || isdigit(c) || c=='_') ? ------------------------------------------------------- Date: 2001-Jan-15 19:35 By: gvanrossum Comment: Looks cool to me. Do you have an idea what to do about the other 98.5%? :) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103250&group_id=5470 From noreply@sourceforge.net Fri Jan 19 00:25:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 16:25:43 -0800 Subject: [Patches] [Patch #103220] Cygwin util.get_platform() fix Message-ID: <E14JPN9-0005Dh-00@usw-sf-web1.sourceforge.net> Patch #103220 has been updated. Project: python Category: distutils Status: Open Submitted by: jlt63 Assigned to : akuchling Summary: Cygwin util.get_platform() fix Follow-Ups: Date: 2001-Jan-18 16:25 By: gvanrossum Comment: Oops, this should have been assigned to Andrew. Andrew, does it look OK? Please check it in then! ------------------------------------------------------- Date: 2001-Jan-13 20:01 By: jlt63 Comment: > how is the "machine" in cygwin determined? It is derived from Window's GetSystemInfo(). See the following, if interested: http://msdn.microsoft.com/library/psdk/sysmgmt/sysinfo_3t67.htm > You seem to go with the "os-release-machine" format Not for any good reason, I was just trying to get rid of the "(0.31/3/2)" cruft. I'm willing to go with "os-release", if that is deemed more appropriate. Let me know and I will upload a revised patch. > so I assume cygwin does distinguish the machines I don't think it does -- it just reports the machine type. > but I have no idea wht the possibilities are The current list is: i[3-6]86, alpha, mips, and unknown. ------------------------------------------------------- Date: 2001-Jan-12 23:15 By: moshez Comment: Hmmmmm...only one question, since I don't have Cygwin to play with: how is the "machine" in cygwin determined? You seem to go with the "os-release-machine" format, so I assume cygwin does distinguish the machines, but I have no idea wht the possibilities are. ------------------------------------------------------- Date: 2001-Jan-12 18:32 By: jlt63 Comment: This patch adds support for Cygwin to util.get_platform(). A Cygwin specific case is needed due to the format of Cygwin's uname command: $ uname -r 1.1.7(0.31/3/2) Since the release field contains slashes, a path component name that is based on this information becomes multiple path components instead of a single one. This patch corrects this problem by only using the leading part of the release field that matches the regular expression "[\d.]+". The procedure to apply the patch is as follows: $ cd Lib/distutils $ # save util.patch to the current directory $ patch <util.patch ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103220&group_id=5470 From noreply@sourceforge.net Fri Jan 19 00:29:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 16:29:19 -0800 Subject: [Patches] [Patch #103185] Some more standard modules cleanup for Cygwin Message-ID: <E14JPQd-0005Ek-00@usw-sf-web1.sourceforge.net> Patch #103185 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Some more standard modules cleanup for Cygwin Follow-Ups: Date: 2001-Jan-18 16:29 By: gvanrossum Comment: Applied, and closed. ------------------------------------------------------- Date: 2001-Jan-10 21:19 By: jlt63 Comment: Use the following procedure to patch: $ cd Modules $ # save modules.patch to current directory $ patch <modules.patch ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103185&group_id=5470 From noreply@sourceforge.net Fri Jan 19 00:31:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 16:31:17 -0800 Subject: [Patches] [Patch #103188] BeOS/ar-fake support for extra libraries Message-ID: <E14JPSX-0001nd-00@usw-sf-web2.sourceforge.net> Patch #103188 has been updated. Project: python Category: Build Status: Closed Submitted by: donnc Assigned to : gvanrossum Summary: BeOS/ar-fake support for extra libraries Follow-Ups: Date: 2001-Jan-18 16:31 By: gvanrossum Comment: Checked in, closed. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103188&group_id=5470 From noreply@sourceforge.net Fri Jan 19 00:45:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 16:45:36 -0800 Subject: [Patches] [Patch #102980] BaseServer class for SocketServer.py (inh. by TCPServer) Message-ID: <E14JPgO-0005Jn-00@usw-sf-web1.sourceforge.net> Patch #102980 has been updated. Project: python Category: library Status: Closed Submitted by: lkcl Assigned to : gvanrossum Summary: BaseServer class for SocketServer.py (inh. by TCPServer) Follow-Ups: Date: 2001-Jan-18 16:45 By: gvanrossum Comment: Thanks, checked in, and closing this patch now. (There were a few weirdnesses with the patch, possibly caused by lost whitespace -- I think I've got it all now though.) ------------------------------------------------------- Date: 2001-Jan-03 06:14 By: gvanrossum Comment: I like this idea. I noticed that you added a copyright statement to the file. Referring to http://mail.python.org/pipermail/python-dev/2001-January/011250.html I believe that it's better not to add explicit copyright statements, because the licensing conditions are unclear in that case. I'd be happy if you included an "Author:" statement instead. ------------------------------------------------------- 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 Fri Jan 19 03:23:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 19:23:35 -0800 Subject: [Patches] [Patch #103323] trivial tests of all untested modules Message-ID: <E14JS9H-000610-00@usw-sf-web1.sourceforge.net> Patch #103323 has been updated. Project: python Category: None Status: Open Submitted by: jhylton Assigned to : tim_one Summary: trivial tests of all untested modules ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103323&group_id=5470 From noreply@sourceforge.net Fri Jan 19 04:43:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 20:43:30 -0800 Subject: [Patches] [Patch #103318] non-recursive makefile Message-ID: <E14JTOc-00033s-00@usw-sf-web2.sourceforge.net> Patch #103318 has been updated. Project: python Category: Build Status: Open Submitted by: nascheme Assigned to : nobody Summary: non-recursive makefile Follow-Ups: Date: 2001-Jan-18 20:43 By: nascheme Comment: New patch. I think makesetup works as it should. There is one issue with MAKE_LDLIBRARY on cygwin but it should be easy to fix. Object files for threads and dynamic loading show be okay now. I might be missing a few "clean" targets. I removed a bunch of "foo.o: $(srcdir)/foo.c" lines. As far as I can tell they are useless. Any make that supports VPATH should be able to figure out where to get the source. Other makes can look in the same dir as the source file. Surely they are not that broken. Guido, do you know if there was a good reason for these lines? Building with GNU make works great for any situation I can think of. pmake is not smart enough to re-read the makefile if it got updated. I don't know of any way around that. Building in a separate dir works fine. I didn't do buildno because I like to type "make" and see the prompt come back right away. What is buildno for and when should it be incremented? ------------------------------------------------------- Date: 2001-Jan-18 18:56 By: gvanrossum Comment: I'm in a quandary. This is really awesone! But a bit too rough to add to the 2.1a1 release. You don't seem to deal with buildno properly -- what's the problem there? Also, I seem to recall that the "-o file.o" option is not universal amongst C compilers. Could someone who uses a non-GCC compiler (e.g. SunPro, or HP, or AIX) check the portability of this Makefile? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103318&group_id=5470 From noreply@sourceforge.net Fri Jan 19 04:52:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 20:52:53 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: <E14JTXh-0006Wt-00@usw-sf-web1.sourceforge.net> Patch #102409 has been updated. Project: python Category: Build Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-18 20:52 By: jlt63 Comment: Please reopen because I need to redo the Cygwin build to handle the use of distutils to build the standard extension modules instead of Modules/Makefile.pre.in. How much time (if any) do I have to resolve these issues before 2.1a is released. I heard that the release date is tomorrow. Sigh... ------------------------------------------------------- Date: 2001-Jan-10 19:39 By: jlt63 Comment: Your welcome -- thanks for considering and accepting this patch. If the patch proves to reek havoc on other platforms (most likely only on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out. ------------------------------------------------------- Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 <Cygwin-1.1.5-Python-2.0.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Fri Jan 19 05:41:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 21:41:56 -0800 Subject: [Patches] [Patch #103323] trivial tests of all untested modules Message-ID: <E14JUJA-0006pO-00@usw-sf-web1.sourceforge.net> Patch #103323 has been updated. Project: python Category: library Status: Closed Submitted by: jhylton Assigned to : tim_one Summary: trivial tests of all untested modules Follow-Ups: Date: 2001-Jan-18 21:41 By: tim_one Comment: Clearly this is an excellent idea! Unsure why you didn't just check it in. So I did. Note that I commented out the imports of "curses" and "rlcompleter", because those can't be imported on Windows (relying on _curses and readline, respectively). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103323&group_id=5470 From noreply@sourceforge.net Fri Jan 19 09:41:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 01:41:19 -0800 Subject: [Patches] [Patch #103329] Update poplib to use re Message-ID: <E14JY2p-0007yz-00@usw-sf-web1.sourceforge.net> Patch #103329 has been updated. Project: python Category: library Status: Open Submitted by: moshez Assigned to : nobody Summary: Update poplib to use re ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103329&group_id=5470 From noreply@sourceforge.net Fri Jan 19 09:43:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 01:43:43 -0800 Subject: [Patches] [Patch #103329] Update poplib to use re Message-ID: <E14JY59-0007zr-00@usw-sf-web1.sourceforge.net> Patch #103329 has been updated. Project: python Category: library Status: Open Submitted by: moshez Assigned to : jhylton Summary: Update poplib to use re ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103329&group_id=5470 From lkcl@samba.org Fri Jan 19 10:12:04 2001 From: lkcl@samba.org (Luke Kenneth Casson Leighton) Date: Fri, 19 Jan 2001 21:12:04 +1100 Subject: [Patches] Re: [Patch #102980] BaseServer class for SocketServer.py (inh. by TCPServer) In-Reply-To: <E14JPgO-0005Jn-00@usw-sf-web1.sourceforge.net> Message-ID: <Pine.SGI.4.05.10101192110050.24116-100000@samba.org> On Thu, 18 Jan 2001 noreply@sourceforge.net wrote: > Patch #102980 has been updated. > > Project: python > Category: library > Status: Closed > Submitted by: lkcl > Assigned to : gvanrossum > Summary: BaseServer class for SocketServer.py (inh. by TCPServer) > > Follow-Ups: > > Date: 2001-Jan-18 16:45 > By: gvanrossum > > Comment: > Thanks, checked in, and closing this patch now. great. you got my message about hi, yes you can have copyright for the patch and authorship remains me, neh? > (There were a few weirdnesses with the patch, possibly caused by lost > whitespace -- I think I've got it all now though.) yes, i had to hand-paste it into the dialog box on sourceforge. > ------------------------------------------------------- > > Date: 2001-Jan-03 06:14 > By: gvanrossum > > Comment: > I like this idea. > > I noticed that you added a copyright statement to the file. Referring to > > http://mail.python.org/pipermail/python-dev/2001-January/011250.html > > I believe that it's better not to add explicit copyright statements, > because the licensing conditions are unclear in that case. I'd be happy if > you included an "Author:" statement instead. > ------------------------------------------------------- From noreply@sourceforge.net Fri Jan 19 15:53:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 07:53:42 -0800 Subject: [Patches] [Patch #101702] Modify co_filename in frozen programs Message-ID: <E14JdrC-0001cB-00@usw-sf-web1.sourceforge.net> Patch #101702 has been updated. Project: python Category: demos and tools Status: Open Submitted by: lhudson Assigned to : gvanrossum Summary: Modify co_filename in frozen programs Follow-Ups: Date: 2001-Jan-19 07:53 By: gvanrossum Comment: I'm taking this, on the assumption that Mark's too busy and freeze is our shared responsibility. ------------------------------------------------------- Date: 2001-Jan-18 15:57 By: jhylton Comment: (somewhat) randomly reassigned; don't have time to look at this ------------------------------------------------------- Date: 2000-Sep-29 04:39 By: lhudson Comment: A new feature for freeze. This patch was developed primarily to reduce the size of the frozen binary. It is particularly useful when freezing for 'small' platforms, such as Palm OS, where you really want to save that last miserable byte. A limitation of this patch is that it does not provide any feedback about the replacements being made. As the path matching is case-sensitive this may lead to unexpected behaviour for DOS and Windows people, eg > freeze.py -r C:\Python\Lib\=py\ goats.py should probably be: > freeze.py -r c:\python\lib\=py\ goats.py ------------------------------------------------------- Date: 2000-Sep-29 07:28 By: jhylton Comment: This sounds like a reasonable enough feature, but we are in feature freeze for Python 2.0. ------------------------------------------------------- Date: 2000-Oct-23 12:33 By: gvanrossum Comment: I like the idea, but I have a few suggestions. - To avoid the case sensitivity issue you mention, you could use os.path.normpath() before the string comparisons. - Rather than writing to a real temporary file, you could marshal to a string and than unmarshal from a StringIO file. - And the big whopper: rather than using a modified version of unmarshal, I suggest writing a recursive code object transformer. It takes a code object and a replace_paths list, and returns a similar code object with the co_filename attribute changed according to the list. The trick is that it should also do this, recursively, to any code object found in the co_consts tuple. (That's the only place where code objects can occur recursively.) While this is probably not much less code than the marshaller you wrote, it has the advantage of not being dependent on the details of the marshal format. Please upload a new patch -- I'm interested in getting this into Python 2.1. ------------------------------------------------------- Date: 2000-Oct-25 01:36 By: lhudson Comment: A recursive code object transformer has been implemented as a member of the ModuleFinder. Case sensitivity issue: normpath strips trailing '/' or '\\' which reduces the flexibility of the path replacement. It also does not seem to solve the case-sensitivity problem: D:\>python Python 2.0 (#8, Oct 17 2000, 15:27:24) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import os >>> os.path.normpath("c:\\python\\lib\\") 'c:\\python\\lib' >>> os.path.normpath("c:\\python\\Lib\\") 'c:\\python\\Lib' >>> ModuleFinder's debugging system is used to report the status of each unique path encountered. Temporary file: marshal.dump() and marshal.load() only work with file objects, not file-like objects. Now that new code objects are being created there is no longer any reason to re-marshal so this problem disappears. ------------------------------------------------------- Date: 2000-Oct-25 04:19 By: gvanrossum Comment: Thanks for the new patch! I'll assign this to Jeremy for further review and to carry it to completion. (Jeremy, if you're swamped, please find someone else to do it.) Re normpath: my mistake -- I meant normcase. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101702&group_id=5470 From noreply@sourceforge.net Fri Jan 19 16:19:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 08:19:31 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: <E14JeGB-0001mE-00@usw-sf-web1.sourceforge.net> Patch #102409 has been updated. Project: python Category: Build Status: Open Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-19 08:19 By: gvanrossum Comment: Reopened at request. Don't sweat the release date -- t's only the first alpha release. I have a feeling it'll be put off till Monday. ------------------------------------------------------- Date: 2001-Jan-18 20:52 By: jlt63 Comment: Please reopen because I need to redo the Cygwin build to handle the use of distutils to build the standard extension modules instead of Modules/Makefile.pre.in. How much time (if any) do I have to resolve these issues before 2.1a is released. I heard that the release date is tomorrow. Sigh... ------------------------------------------------------- Date: 2001-Jan-10 19:39 By: jlt63 Comment: Your welcome -- thanks for considering and accepting this patch. If the patch proves to reek havoc on other platforms (most likely only on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out. ------------------------------------------------------- Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 <Cygwin-1.1.5-Python-2.0.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Fri Jan 19 16:26:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 08:26:36 -0800 Subject: [Patches] [Patch #103220] Cygwin util.get_platform() fix Message-ID: <E14JeN2-0005vH-00@usw-sf-web3.sourceforge.net> Patch #103220 has been updated. Project: python Category: distutils Status: Closed Submitted by: jlt63 Assigned to : akuchling Summary: Cygwin util.get_platform() fix Follow-Ups: Date: 2001-Jan-19 08:26 By: akuchling Comment: Since it only affects the results on the Cygwin platform and have no way of testing it, I'll assume it's correct for that platform. Checked in. ------------------------------------------------------- Date: 2001-Jan-18 16:25 By: gvanrossum Comment: Oops, this should have been assigned to Andrew. Andrew, does it look OK? Please check it in then! ------------------------------------------------------- Date: 2001-Jan-13 20:01 By: jlt63 Comment: > how is the "machine" in cygwin determined? It is derived from Window's GetSystemInfo(). See the following, if interested: http://msdn.microsoft.com/library/psdk/sysmgmt/sysinfo_3t67.htm > You seem to go with the "os-release-machine" format Not for any good reason, I was just trying to get rid of the "(0.31/3/2)" cruft. I'm willing to go with "os-release", if that is deemed more appropriate. Let me know and I will upload a revised patch. > so I assume cygwin does distinguish the machines I don't think it does -- it just reports the machine type. > but I have no idea wht the possibilities are The current list is: i[3-6]86, alpha, mips, and unknown. ------------------------------------------------------- Date: 2001-Jan-12 23:15 By: moshez Comment: Hmmmmm...only one question, since I don't have Cygwin to play with: how is the "machine" in cygwin determined? You seem to go with the "os-release-machine" format, so I assume cygwin does distinguish the machines, but I have no idea wht the possibilities are. ------------------------------------------------------- Date: 2001-Jan-12 18:32 By: jlt63 Comment: This patch adds support for Cygwin to util.get_platform(). A Cygwin specific case is needed due to the format of Cygwin's uname command: $ uname -r 1.1.7(0.31/3/2) Since the release field contains slashes, a path component name that is based on this information becomes multiple path components instead of a single one. This patch corrects this problem by only using the leading part of the release field that matches the regular expression "[\d.]+". The procedure to apply the patch is as follows: $ cd Lib/distutils $ # save util.patch to the current directory $ patch <util.patch ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103220&group_id=5470 From noreply@sourceforge.net Fri Jan 19 16:34:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 08:34:30 -0800 Subject: [Patches] [Patch #103329] Update poplib to use re Message-ID: <E14JeUg-0006p7-00@usw-sf-web2.sourceforge.net> Patch #103329 has been updated. Project: python Category: library Status: Accepted Submitted by: moshez Assigned to : jhylton Summary: Update poplib to use re Follow-Ups: Date: 2001-Jan-19 08:34 By: akuchling Comment: The patch looks correct after a quick reading. Moshe, go ahead and check it in. (Bonus points if you can actually test it against a POP server.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103329&group_id=5470 From guido@digicool.com Fri Jan 19 16:45:04 2001 From: guido@digicool.com (Guido van Rossum) Date: Fri, 19 Jan 2001 11:45:04 -0500 Subject: [Patches] Re: [Patch #102980] BaseServer class for SocketServer.py (inh. by TCPServer) In-Reply-To: Your message of "Fri, 19 Jan 2001 21:12:04 +1100." <Pine.SGI.4.05.10101192110050.24116-100000@samba.org> References: <Pine.SGI.4.05.10101192110050.24116-100000@samba.org> Message-ID: <200101191645.LAA29383@cj20424-a.reston1.va.home.com> > > Thanks, checked in, and closing this patch now. > > great. you got my message about hi, yes you can have copyright for the > patch and authorship remains me, neh? Yes, got it. I've added a note about your authorship of the patch to the source file now. > > (There were a few weirdnesses with the patch, possibly caused by lost > > whitespace -- I think I've got it all now though.) > > yes, i had to hand-paste it into the dialog box on sourceforge. Ah, that explains. --Guido van Rossum (home page: http://www.python.org/~guido/) From lkcl@samba.org Fri Jan 19 17:42:01 2001 From: lkcl@samba.org (Luke Kenneth Casson Leighton) Date: Sat, 20 Jan 2001 04:42:01 +1100 Subject: [Patches] Re: [Patch #102980] BaseServer class for SocketServer.py (inh. by TCPServer) In-Reply-To: <200101191645.LAA29383@cj20424-a.reston1.va.home.com> Message-ID: <Pine.SGI.4.05.10101200440180.7983-100000@samba.org> On Fri, 19 Jan 2001, Guido van Rossum wrote: > > > Thanks, checked in, and closing this patch now. > > > > great. you got my message about hi, yes you can have copyright for the > > patch and authorship remains me, neh? > > Yes, got it. I've added a note about your authorship of the patch to > the source file now. you want me to create a BaseServer.py? with: import SocketServer class ThreadedMixIn(SocketServer.ThreadedMixIn): """ legacy redirection """ pass etc. ? and have BaseServer class in BaseServer.py? From noreply@sourceforge.net Fri Jan 19 18:11:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 10:11:39 -0800 Subject: [Patches] [Patch #103329] Update poplib to use re Message-ID: <E14Jg0h-0007Nz-00@usw-sf-web2.sourceforge.net> Patch #103329 has been updated. Project: python Category: library Status: Accepted Submitted by: moshez Assigned to : moshez Summary: Update poplib to use re Follow-Ups: Date: 2001-Jan-19 10:11 By: gvanrossum Comment: Assigned to Moshe. Thanks! Please check in ASAP! ------------------------------------------------------- Date: 2001-Jan-19 08:34 By: akuchling Comment: The patch looks correct after a quick reading. Moshe, go ahead and check it in. (Bonus points if you can actually test it against a POP server.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103329&group_id=5470 From noreply@sourceforge.net Fri Jan 19 18:13:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 10:13:03 -0800 Subject: [Patches] [Patch #103318] non-recursive makefile Message-ID: <E14Jg23-0002Qd-00@usw-sf-web1.sourceforge.net> Patch #103318 has been updated. Project: python Category: Build Status: Open Submitted by: nascheme Assigned to : nobody Summary: non-recursive makefile Follow-Ups: Date: 2001-Jan-19 10:13 By: nascheme Comment: Fix silly bug ("! test -f" instead of "test ! -f" in configure.in). ------------------------------------------------------- Date: 2001-Jan-18 20:43 By: nascheme Comment: New patch. I think makesetup works as it should. There is one issue with MAKE_LDLIBRARY on cygwin but it should be easy to fix. Object files for threads and dynamic loading show be okay now. I might be missing a few "clean" targets. I removed a bunch of "foo.o: $(srcdir)/foo.c" lines. As far as I can tell they are useless. Any make that supports VPATH should be able to figure out where to get the source. Other makes can look in the same dir as the source file. Surely they are not that broken. Guido, do you know if there was a good reason for these lines? Building with GNU make works great for any situation I can think of. pmake is not smart enough to re-read the makefile if it got updated. I don't know of any way around that. Building in a separate dir works fine. I didn't do buildno because I like to type "make" and see the prompt come back right away. What is buildno for and when should it be incremented? ------------------------------------------------------- Date: 2001-Jan-18 18:56 By: gvanrossum Comment: I'm in a quandary. This is really awesone! But a bit too rough to add to the 2.1a1 release. You don't seem to deal with buildno properly -- what's the problem there? Also, I seem to recall that the "-o file.o" option is not universal amongst C compilers. Could someone who uses a non-GCC compiler (e.g. SunPro, or HP, or AIX) check the portability of this Makefile? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103318&group_id=5470 From guido@digicool.com Fri Jan 19 18:19:39 2001 From: guido@digicool.com (Guido van Rossum) Date: Fri, 19 Jan 2001 13:19:39 -0500 Subject: [Patches] Re: [Patch #102980] BaseServer class for SocketServer.py (inh. by TCPServer) In-Reply-To: Your message of "Sat, 20 Jan 2001 04:42:01 +1100." <Pine.SGI.4.05.10101200440180.7983-100000@samba.org> References: <Pine.SGI.4.05.10101200440180.7983-100000@samba.org> Message-ID: <200101191819.NAA02148@cj20424-a.reston1.va.home.com> > you want me to create a BaseServer.py? > > with: > > import SocketServer > > class ThreadedMixIn(SocketServer.ThreadedMixIn): > """ legacy redirection """ > pass > > etc. > > ? > > and have BaseServer class in BaseServer.py? Hm, I think it's fine the way it is. Anyway, don't want to think about it until after the 2.1a1 release. :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From noreply@sourceforge.net Fri Jan 19 19:43:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 11:43:38 -0800 Subject: [Patches] [Patch #103305] function attribute segfault Message-ID: <E14JhRi-0006yM-00@usw-sf-web3.sourceforge.net> Patch #103305 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: greg_ball Assigned to : bwarsaw Summary: function attribute segfault Follow-Ups: Date: 2001-Jan-19 11:43 By: bwarsaw Comment: Attached is a new version of this patch, which I'm about to check in. greg_ball's patch and discovery of the bug was excellent, but there were a few other things to clean up in the file too (crashing on del f.func_defaults, raising the wrong exception when del'ing a non-existant attribute). Applying and closing. ------------------------------------------------------- Date: 2001-Jan-18 17:57 By: gvanrossum Comment: This is a high priority patch -- needs to be deal with before 2.1a1 can go out. ------------------------------------------------------- Date: 2001-Jan-18 13:30 By: bwarsaw Comment: Assigning this to me to look at later. ------------------------------------------------------- Date: 2001-Jan-17 14:51 By: greg_ball Comment: I have ready a new version of the patch (I won't upload it yet in case it's not welcome) which does the following: reference to f.__dict__ or f.func_dict returns a new dictionary if f did not previously have one. (Similar to what happens on first assignent to arbitrary attribute.) Then the following code works: >>> def f(): pass ... >>> d=f.__dict__ >>> f.a=1 >>> d['a'] 1 instead of d being an unsubscriptable object. To me it seems nasty if somethings __dict__ attribute might not be a dictionary. Since f.__dict__ never now _appears_ to be None, I also removed the feature of assigning it to None to get rid of it. del f.__dict__ can now be used for this purpose. (previously only for creating sig11 =) ) One other thought: as it stands, function attributes are strangely behaving in restricted mode. You can't set any attributes directly. You can't directly get attributes that don't start with an underscore. However, you can get __dict__ and then do anything you like to it... ------------------------------------------------------- Date: 2001-Jan-17 14:03 By: greg_ball Comment: At two points, the code did not check for NULL, leading to segmentation fault soon after. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103305&group_id=5470 From noreply@sourceforge.net Fri Jan 19 19:45:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 11:45:07 -0800 Subject: [Patches] [Patch #103305] function attribute segfault Message-ID: <E14JhT9-0006yo-00@usw-sf-web3.sourceforge.net> Patch #103305 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: greg_ball Assigned to : bwarsaw Summary: function attribute segfault Follow-Ups: Date: 2001-Jan-19 11:45 By: bwarsaw Comment: Oops, I forgot to write out the new patch. Here 'tis for the historical record. ------------------------------------------------------- Date: 2001-Jan-19 11:43 By: bwarsaw Comment: Attached is a new version of this patch, which I'm about to check in. greg_ball's patch and discovery of the bug was excellent, but there were a few other things to clean up in the file too (crashing on del f.func_defaults, raising the wrong exception when del'ing a non-existant attribute). Applying and closing. ------------------------------------------------------- Date: 2001-Jan-18 17:57 By: gvanrossum Comment: This is a high priority patch -- needs to be deal with before 2.1a1 can go out. ------------------------------------------------------- Date: 2001-Jan-18 13:30 By: bwarsaw Comment: Assigning this to me to look at later. ------------------------------------------------------- Date: 2001-Jan-17 14:51 By: greg_ball Comment: I have ready a new version of the patch (I won't upload it yet in case it's not welcome) which does the following: reference to f.__dict__ or f.func_dict returns a new dictionary if f did not previously have one. (Similar to what happens on first assignent to arbitrary attribute.) Then the following code works: >>> def f(): pass ... >>> d=f.__dict__ >>> f.a=1 >>> d['a'] 1 instead of d being an unsubscriptable object. To me it seems nasty if somethings __dict__ attribute might not be a dictionary. Since f.__dict__ never now _appears_ to be None, I also removed the feature of assigning it to None to get rid of it. del f.__dict__ can now be used for this purpose. (previously only for creating sig11 =) ) One other thought: as it stands, function attributes are strangely behaving in restricted mode. You can't set any attributes directly. You can't directly get attributes that don't start with an underscore. However, you can get __dict__ and then do anything you like to it... ------------------------------------------------------- Date: 2001-Jan-17 14:03 By: greg_ball Comment: At two points, the code did not check for NULL, leading to segmentation fault soon after. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103305&group_id=5470 From noreply@sourceforge.net Fri Jan 19 19:46:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 11:46:15 -0800 Subject: [Patches] [Patch #103305] function attribute segfault Message-ID: <E14JhUF-0006zU-00@usw-sf-web3.sourceforge.net> Patch #103305 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: greg_ball Assigned to : bwarsaw Summary: function attribute segfault Follow-Ups: Date: 2001-Jan-19 11:46 By: bwarsaw Comment: Sorry, one more try. ------------------------------------------------------- Date: 2001-Jan-19 11:45 By: bwarsaw Comment: Oops, I forgot to write out the new patch. Here 'tis for the historical record. ------------------------------------------------------- Date: 2001-Jan-19 11:43 By: bwarsaw Comment: Attached is a new version of this patch, which I'm about to check in. greg_ball's patch and discovery of the bug was excellent, but there were a few other things to clean up in the file too (crashing on del f.func_defaults, raising the wrong exception when del'ing a non-existant attribute). Applying and closing. ------------------------------------------------------- Date: 2001-Jan-18 17:57 By: gvanrossum Comment: This is a high priority patch -- needs to be deal with before 2.1a1 can go out. ------------------------------------------------------- Date: 2001-Jan-18 13:30 By: bwarsaw Comment: Assigning this to me to look at later. ------------------------------------------------------- Date: 2001-Jan-17 14:51 By: greg_ball Comment: I have ready a new version of the patch (I won't upload it yet in case it's not welcome) which does the following: reference to f.__dict__ or f.func_dict returns a new dictionary if f did not previously have one. (Similar to what happens on first assignent to arbitrary attribute.) Then the following code works: >>> def f(): pass ... >>> d=f.__dict__ >>> f.a=1 >>> d['a'] 1 instead of d being an unsubscriptable object. To me it seems nasty if somethings __dict__ attribute might not be a dictionary. Since f.__dict__ never now _appears_ to be None, I also removed the feature of assigning it to None to get rid of it. del f.__dict__ can now be used for this purpose. (previously only for creating sig11 =) ) One other thought: as it stands, function attributes are strangely behaving in restricted mode. You can't set any attributes directly. You can't directly get attributes that don't start with an underscore. However, you can get __dict__ and then do anything you like to it... ------------------------------------------------------- Date: 2001-Jan-17 14:03 By: greg_ball Comment: At two points, the code did not check for NULL, leading to segmentation fault soon after. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103305&group_id=5470 From noreply@sourceforge.net Fri Jan 19 20:00:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 12:00:34 -0800 Subject: [Patches] [Patch #103329] Update poplib to use re Message-ID: <E14Jhi6-0007xa-00@usw-sf-web2.sourceforge.net> Patch #103329 has been updated. Project: python Category: library Status: Accepted Submitted by: moshez Assigned to : moshez Summary: Update poplib to use re Follow-Ups: Date: 2001-Jan-19 12:00 By: moshez Comment: Checked in as version 1.12, beating the 3pm on Friday rule by 3 minutes. Unfortunately, my POP server doesn't support APOP, so please give it good testing. ------------------------------------------------------- Date: 2001-Jan-19 10:11 By: gvanrossum Comment: Assigned to Moshe. Thanks! Please check in ASAP! ------------------------------------------------------- Date: 2001-Jan-19 08:34 By: akuchling Comment: The patch looks correct after a quick reading. Moshe, go ahead and check it in. (Bonus points if you can actually test it against a POP server.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103329&group_id=5470 From noreply@sourceforge.net Fri Jan 19 20:16:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 12:16:39 -0800 Subject: [Patches] [Patch #101485] Patch to test sendmail virtual domain gid's for bug #114235 Message-ID: <E14Jhxf-00082W-00@usw-sf-web2.sourceforge.net> Patch #101485 has been updated. Project: python Category: None Status: Closed Submitted by: bwarsaw Assigned to : bwarsaw Summary: Patch to test sendmail virtual domain gid's for bug #114235 Follow-Ups: Date: 2001-Jan-19 12:16 By: bwarsaw Comment: This patch has nothing to do with Python. ------------------------------------------------------- Date: 2000-Sep-12 15:22 By: bwarsaw Comment: See SF bug #114235 for what this program tests. This patch (and the bug) really have nothing to do with Python, I believe. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101485&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:44:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:44:21 -0800 Subject: [Patches] [Patch #103318] non-recursive makefile Message-ID: <E14JkGb-0003pf-00@usw-sf-web1.sourceforge.net> Patch #103318 has been updated. Project: python Category: Build Status: Open Submitted by: nascheme Assigned to : nascheme Summary: non-recursive makefile Follow-Ups: Date: 2001-Jan-19 14:44 By: gvanrossum Comment: Let's put this off until after the 2.1a1 release. It should go into 2.1a2 though, and probably should be checked in soon after 2.1a1 is released. ------------------------------------------------------- Date: 2001-Jan-19 10:13 By: nascheme Comment: Fix silly bug ("! test -f" instead of "test ! -f" in configure.in). ------------------------------------------------------- Date: 2001-Jan-18 20:43 By: nascheme Comment: New patch. I think makesetup works as it should. There is one issue with MAKE_LDLIBRARY on cygwin but it should be easy to fix. Object files for threads and dynamic loading show be okay now. I might be missing a few "clean" targets. I removed a bunch of "foo.o: $(srcdir)/foo.c" lines. As far as I can tell they are useless. Any make that supports VPATH should be able to figure out where to get the source. Other makes can look in the same dir as the source file. Surely they are not that broken. Guido, do you know if there was a good reason for these lines? Building with GNU make works great for any situation I can think of. pmake is not smart enough to re-read the makefile if it got updated. I don't know of any way around that. Building in a separate dir works fine. I didn't do buildno because I like to type "make" and see the prompt come back right away. What is buildno for and when should it be incremented? ------------------------------------------------------- Date: 2001-Jan-18 18:56 By: gvanrossum Comment: I'm in a quandary. This is really awesone! But a bit too rough to add to the 2.1a1 release. You don't seem to deal with buildno properly -- what's the problem there? Also, I seem to recall that the "-o file.o" option is not universal amongst C compilers. Could someone who uses a non-GCC compiler (e.g. SunPro, or HP, or AIX) check the portability of this Makefile? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103318&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:45:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:45:39 -0800 Subject: [Patches] [Patch #101702] Modify co_filename in frozen programs Message-ID: <E14JkHr-0007yE-00@usw-sf-web3.sourceforge.net> Patch #101702 has been updated. Project: python Category: demos and tools Status: Open Submitted by: lhudson Assigned to : gvanrossum Summary: Modify co_filename in frozen programs Follow-Ups: Date: 2001-Jan-19 14:45 By: gvanrossum Comment: No time to review this before the 2.1a1 release; I'll do this for 2.1a2. ------------------------------------------------------- Date: 2001-Jan-19 07:53 By: gvanrossum Comment: I'm taking this, on the assumption that Mark's too busy and freeze is our shared responsibility. ------------------------------------------------------- Date: 2001-Jan-18 15:57 By: jhylton Comment: (somewhat) randomly reassigned; don't have time to look at this ------------------------------------------------------- Date: 2000-Sep-29 04:39 By: lhudson Comment: A new feature for freeze. This patch was developed primarily to reduce the size of the frozen binary. It is particularly useful when freezing for 'small' platforms, such as Palm OS, where you really want to save that last miserable byte. A limitation of this patch is that it does not provide any feedback about the replacements being made. As the path matching is case-sensitive this may lead to unexpected behaviour for DOS and Windows people, eg > freeze.py -r C:\Python\Lib\=py\ goats.py should probably be: > freeze.py -r c:\python\lib\=py\ goats.py ------------------------------------------------------- Date: 2000-Sep-29 07:28 By: jhylton Comment: This sounds like a reasonable enough feature, but we are in feature freeze for Python 2.0. ------------------------------------------------------- Date: 2000-Oct-23 12:33 By: gvanrossum Comment: I like the idea, but I have a few suggestions. - To avoid the case sensitivity issue you mention, you could use os.path.normpath() before the string comparisons. - Rather than writing to a real temporary file, you could marshal to a string and than unmarshal from a StringIO file. - And the big whopper: rather than using a modified version of unmarshal, I suggest writing a recursive code object transformer. It takes a code object and a replace_paths list, and returns a similar code object with the co_filename attribute changed according to the list. The trick is that it should also do this, recursively, to any code object found in the co_consts tuple. (That's the only place where code objects can occur recursively.) While this is probably not much less code than the marshaller you wrote, it has the advantage of not being dependent on the details of the marshal format. Please upload a new patch -- I'm interested in getting this into Python 2.1. ------------------------------------------------------- Date: 2000-Oct-25 01:36 By: lhudson Comment: A recursive code object transformer has been implemented as a member of the ModuleFinder. Case sensitivity issue: normpath strips trailing '/' or '\\' which reduces the flexibility of the path replacement. It also does not seem to solve the case-sensitivity problem: D:\>python Python 2.0 (#8, Oct 17 2000, 15:27:24) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import os >>> os.path.normpath("c:\\python\\lib\\") 'c:\\python\\lib' >>> os.path.normpath("c:\\python\\Lib\\") 'c:\\python\\Lib' >>> ModuleFinder's debugging system is used to report the status of each unique path encountered. Temporary file: marshal.dump() and marshal.load() only work with file objects, not file-like objects. Now that new code objects are being created there is no longer any reason to re-marshal so this problem disappears. ------------------------------------------------------- Date: 2000-Oct-25 04:19 By: gvanrossum Comment: Thanks for the new patch! I'll assign this to Jeremy for further review and to carry it to completion. (Jeremy, if you're swamped, please find someone else to do it.) Re normpath: my mistake -- I meant normcase. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101702&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:46:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:46:37 -0800 Subject: [Patches] [Patch #100938] [Draft] libpython as shared library (.so) on Linux Message-ID: <E14JkIn-0003qH-00@usw-sf-web1.sourceforge.net> Patch #100938 has been updated. Project: python Category: None Status: Open Submitted by: flight Assigned to : nascheme Summary: [Draft] libpython as shared library (.so) on Linux Follow-Ups: Date: 2001-Jan-19 14:46 By: gvanrossum Comment: I'm reassigning this to Neil. Neil, can you see if you can integrate this into your flat Makefile? ------------------------------------------------------- Date: 2001-Jan-17 15:09 By: gvanrossum Comment: Andrew, I'm tentatively reassigning this to you, since you're taking charge of the build process at the moment (setup.py). I suspect that the patch no longer works as is -- would it make sense to mark it postponed and get the author to submit a new version before we release 2.1a1? ------------------------------------------------------- Date: 2001-Jan-17 14:46 By: nobody Comment: Getting this patch into the next version of Python would be "A Good Thing"(tm) in my opinion. We use libpython as a .so at ILM and end up having to make changes like this by hand every time we get a new version... ------------------------------------------------------- Date: 2000-Jul-19 14:10 By: flight Comment: This is what it used in product to build libpython as shared library(.so) for Debian. Note: This patch is not ready for inclusion in the upstream Python distribution. Anyway, I think this might be a start. The Python 1.5 executable in Debian GNU/Linux is built against a shared libpython1.5.so since April 1999, and I haven't yet heard about any problems. Using a shared library should have an advantage if you're running multiple instances of Python (be it standalone interpreter or embedded applications). ------------------------------------------------------- Date: 2000-Aug-15 10:52 By: tim_one Comment: Assigned to Barry because he's a Linux weenie. Barry, if you think there's something here that should go into 2.0, please pursue it now, else change the status to Postponed. ------------------------------------------------------- Date: 2000-Aug-16 00:40 By: moshez Comment: I suggest we postpone it. It isn't really complete (only works on real distributions <wink>), and the complete solution should work on all unices. If Tcl/Perl can do it, there is no reason Python can't -- and a half hearted solution isn't that good. flight, you should use this for the Python in woody in the mean time -- I doubt woody will be stable before Python 2.1 comes out, so 2.1 sounds like a good timeframe to do it. ------------------------------------------------------- Date: 2000-Aug-23 09:26 By: jhylton Comment: In the absence of anyone arguing for inclusion of this patch and a one-week idle period, it is postponed. ------------------------------------------------------- Date: 2000-Oct-26 14:13 By: gvanrossum Comment: Let's give this to Jeremy instead, because he seems to know more about build issues. Jeremy, it would be good to look into getting this to work with your RPM suite. Flight's argument (has been used without complaints in Debian Python 1.5.2 since 1999) is good. ------------------------------------------------------- Date: 2000-Nov-01 03:32 By: moshez Comment: I've had a look at the patch, and it seems it has two orthogonal parts. One is adding the infrastructure for compiling another version for the Python library, which can be more or less integrated as-is, and one is hard-coding the particular way, in Linux, of building shared objects. Since we discover how to build shared objects in the configure script anyway (otherwise we could not have built modules as shared objects), we should embed that information there, not the Linux flags. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100938&group_id=5470 From noreply@sourceforge.net Fri Jan 19 23:18:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 15:18:54 -0800 Subject: [Patches] [Patch #103265] Let time functions default to 'now' (where it makes sense) Message-ID: <E14Jko2-0000aF-00@usw-sf-web2.sourceforge.net> Patch #103265 has been updated. Project: python Category: Modules Status: Closed Submitted by: twouters Assigned to : twouters Summary: Let time functions default to 'now' (where it makes sense) Follow-Ups: Date: 2001-Jan-19 15:18 By: twouters Comment: Checked in, revision 2.105 of Modules/timemodule.c, 1.35 of Doc/lib/libtime.tex and 1.102 of Misc/NEWS. ------------------------------------------------------- Date: 2001-Jan-19 14:53 By: fdrake Comment: The docs look good -- please include them in the checkin. ------------------------------------------------------- Date: 2001-Jan-19 14:48 By: gvanrossum Comment: Thomas, please check this in -- there's still time to get it into 2.1a1. Then reassign to Fred for the docs! ------------------------------------------------------- Date: 2001-Jan-17 07:50 By: gvanrossum Comment: Thomas, go for it. I'd say "the current time" instead of "now" in the NEWS item. I'll defer to Fred for the docs. ------------------------------------------------------- Date: 2001-Jan-17 06:55 By: twouters Comment: That's what I meant with 'check the size', but I still think it kind of breaks the abstraction of 'args'. Not in a terribly scary way, but the difference between calling floattime() always and doing a check whether or not to call floattime() isn't that big either. But you is BDFL, boss, so here's a patch that does it your way :) It also adds a NEWS entry and fixes the docs for timemodule (including docstrings.) Assigned to Fred so he can take a quick look at the docs. Don't need to check the TeX code though, Fred, I successfully built ps files on my laptop :) ------------------------------------------------------- Date: 2001-Jan-17 06:01 By: gvanrossum Comment: With METH_VARARGS, args is guaranteed to be a tuple, so you can simply use PyTuple_Size(). ------------------------------------------------------- Date: 2001-Jan-17 01:24 By: twouters Comment: Calling floattime() only when necessary would be nice, but isn't possible without a value that reads as 'empty'. There is no way to see whether optional values of a ParseTuple call were filled or not, except by comparing the old value with the new one, and that means making a token float value that means 'no argument'. We could check the length of 'args' to see howmany arguments it contains, but that is a very fragile way, and breaks the wonderful transparentness of argument-passing and PyArg_Parse*. The alternative to this approach is not reading a double from the arglist, but a Python object (initialized as NULL,) and converting that to a float. That would have my preference over the other two options, above, but I still prefer the current way -- much less code, not that much slower (if slower at all, I didn't time it.) (Unless of course there is a way to see howmany optional arguments were used ? Like a separate format character that fills an int with that information, or a separate PyArg API call that returns not success/failure, but the number of optional arguments used, and -1 on failure.) I'll add news + docs, too, sometime before friday if work permits :P ------------------------------------------------------- Date: 2001-Jan-16 20:29 By: gvanrossum Comment: How hard would it be to avoid calling floattime() when an argument is present (in gmtime() and localtime())? Missing: docs, NEWS item. Otherwise, great -- ready to check in if you fix the above things! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103265&group_id=5470 From noreply@sourceforge.net Fri Jan 19 23:42:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 15:42:39 -0800 Subject: [Patches] [Patch #103336] Missing cast Message-ID: <E14JlB1-0008GQ-00@usw-sf-web3.sourceforge.net> Patch #103336 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jackjansen Assigned to : nobody Summary: Missing cast ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103336&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:31:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:31:40 -0800 Subject: [Patches] [Patch #103333] install_data does not do pathname conversion Message-ID: <E14Jk4K-0007tO-00@usw-sf-web3.sourceforge.net> Patch #103333 has been updated. Project: python Category: distutils Status: Open Submitted by: jackjansen Assigned to : nobody Summary: install_data does not do pathname conversion ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103333&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:35:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:35:15 -0800 Subject: [Patches] [Patch #103334] Strip "." pathname components Message-ID: <E14Jk7n-0007ut-00@usw-sf-web3.sourceforge.net> Patch #103334 has been updated. Project: python Category: distutils Status: Open Submitted by: jackjansen Assigned to : nobody Summary: Strip "." pathname components ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103334&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:41:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:41:31 -0800 Subject: [Patches] [Patch #103334] Strip "." pathname components Message-ID: <E14JkDr-0000Nk-00@usw-sf-web2.sourceforge.net> Patch #103334 has been updated. Project: python Category: distutils Status: Open Submitted by: jackjansen Assigned to : akuchling Summary: Strip "." pathname components Follow-Ups: Date: 2001-Jan-19 14:41 By: gvanrossum Comment: Looks decent to me. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103334&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:42:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:42:10 -0800 Subject: [Patches] [Patch #103333] install_data does not do pathname conversion Message-ID: <E14JkEU-0007wu-00@usw-sf-web3.sourceforge.net> Patch #103333 has been updated. Project: python Category: distutils Status: Open Submitted by: jackjansen Assigned to : akuchling Summary: install_data does not do pathname conversion Follow-Ups: Date: 2001-Jan-19 14:42 By: gvanrossum Comment: For Andrew. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103333&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:43:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:43:11 -0800 Subject: [Patches] [Patch #103297] __all__ values for a handful of modules Message-ID: <E14JkFT-0007xQ-00@usw-sf-web3.sourceforge.net> Patch #103297 has been updated. Project: python Category: library Status: Open Submitted by: montanaro Assigned to : montanaro Summary: __all__ values for a handful of modules Follow-Ups: Date: 2001-Jan-19 14:43 By: gvanrossum Comment: So where's the next update? I would approve of adding this to the alpha1 release. ------------------------------------------------------- Date: 2001-Jan-18 18:32 By: gvanrossum Comment: Nice, Skip! I wonder if the "test" functions should really be included in __all__? Especially StringIO's test isn't generally needed. I'd be happy if I had to import it explicitly using "from StringIO import test" if I really wanted it. Ditto for the HTTP server classes. ------------------------------------------------------- Date: 2001-Jan-18 19:09 By: montanaro Comment: Yeah, I wondered about including "test". I included it only because I thought I remembered someone mentioning that in a previous thread. I'll remove "test" from __all__ in my next update. Assuming everything else is okay, I will keep adding to the number of modified modules. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103297&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:48:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:48:41 -0800 Subject: [Patches] [Patch #103265] Let time functions default to 'now' (where it makes sense) Message-ID: <E14JkKn-0003rE-00@usw-sf-web1.sourceforge.net> Patch #103265 has been updated. Project: python Category: Modules Status: Open Submitted by: twouters Assigned to : twouters Summary: Let time functions default to 'now' (where it makes sense) Follow-Ups: Date: 2001-Jan-19 14:48 By: gvanrossum Comment: Thomas, please check this in -- there's still time to get it into 2.1a1. Then reassign to Fred for the docs! ------------------------------------------------------- Date: 2001-Jan-17 07:50 By: gvanrossum Comment: Thomas, go for it. I'd say "the current time" instead of "now" in the NEWS item. I'll defer to Fred for the docs. ------------------------------------------------------- Date: 2001-Jan-17 06:55 By: twouters Comment: That's what I meant with 'check the size', but I still think it kind of breaks the abstraction of 'args'. Not in a terribly scary way, but the difference between calling floattime() always and doing a check whether or not to call floattime() isn't that big either. But you is BDFL, boss, so here's a patch that does it your way :) It also adds a NEWS entry and fixes the docs for timemodule (including docstrings.) Assigned to Fred so he can take a quick look at the docs. Don't need to check the TeX code though, Fred, I successfully built ps files on my laptop :) ------------------------------------------------------- Date: 2001-Jan-17 06:01 By: gvanrossum Comment: With METH_VARARGS, args is guaranteed to be a tuple, so you can simply use PyTuple_Size(). ------------------------------------------------------- Date: 2001-Jan-17 01:24 By: twouters Comment: Calling floattime() only when necessary would be nice, but isn't possible without a value that reads as 'empty'. There is no way to see whether optional values of a ParseTuple call were filled or not, except by comparing the old value with the new one, and that means making a token float value that means 'no argument'. We could check the length of 'args' to see howmany arguments it contains, but that is a very fragile way, and breaks the wonderful transparentness of argument-passing and PyArg_Parse*. The alternative to this approach is not reading a double from the arglist, but a Python object (initialized as NULL,) and converting that to a float. That would have my preference over the other two options, above, but I still prefer the current way -- much less code, not that much slower (if slower at all, I didn't time it.) (Unless of course there is a way to see howmany optional arguments were used ? Like a separate format character that fills an int with that information, or a separate PyArg API call that returns not success/failure, but the number of optional arguments used, and -1 on failure.) I'll add news + docs, too, sometime before friday if work permits :P ------------------------------------------------------- Date: 2001-Jan-16 20:29 By: gvanrossum Comment: How hard would it be to avoid calling floattime() when an argument is present (in gmtime() and localtime())? Missing: docs, NEWS item. Otherwise, great -- ready to check in if you fix the above things! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103265&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:51:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:51:21 -0800 Subject: [Patches] [Patch #101782] Enhances 1.6 compiler to raise 'proper' SyntaxErrors Message-ID: <E14JkNN-0000Qe-00@usw-sf-web2.sourceforge.net> Patch #101782 has been updated. Project: python Category: Parser/Compiler Status: Open Submitted by: roman_sulzhyk Assigned to : jhylton Summary: Enhances 1.6 compiler to raise 'proper' SyntaxErrors Follow-Ups: Date: 2001-Jan-19 14:51 By: gvanrossum Comment: This is better for Jeremy to review, since he has done a major refactoring on the compiler code. Jeremy, I don't want this in 2.1a1, but could you see if you can get it either approved or rejected in time for 2.1a2? ------------------------------------------------------- Date: 2000-Oct-04 12:29 By: roman_sulzhyk Comment: Hello: There's a problem with the compiler.c (which persists in 2.0 also) which means it raises 'old style' SyntaxErrors, which could not be formatted properly. I mentioned this to Guido during the last conference, and he said it can best be done by moving parts of the 'linecache' functionality to core python, or something along those lines. Well, I've put together something which is not so far-fetching, but plugs this hole. The only time it reverts to the 'old style' compile error is when the input file is not a regular file (like stdin), since the line information is lost at that point - don't think parser.c saves it anywhere. Tell me what you think - should I port it to 2.0, or just drop it altogether if it's not needed. Thanks, Roman ------------------------------------------------------- Date: 2000-Oct-04 23:40 By: fdrake Comment: This needs to be ported to the latest CVS version before being considered for implementation (but discussion of the feature is welcome!). This cannot be considered for inclusion in 2.0 since we're in feature freeze already, and are only fixing bugs at this point. This can be considered for 2.1. Marking as postponed. ------------------------------------------------------- Date: 2000-Oct-09 10:59 By: roman_sulzhyk Comment: I've ported it to the latest CVS version - check it out, Roman ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101782&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:53:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:53:19 -0800 Subject: [Patches] [Patch #103265] Let time functions default to 'now' (where it makes sense) Message-ID: <E14JkPH-0003t0-00@usw-sf-web1.sourceforge.net> Patch #103265 has been updated. Project: python Category: Modules Status: Accepted Submitted by: twouters Assigned to : twouters Summary: Let time functions default to 'now' (where it makes sense) Follow-Ups: Date: 2001-Jan-19 14:53 By: fdrake Comment: The docs look good -- please include them in the checkin. ------------------------------------------------------- Date: 2001-Jan-19 14:48 By: gvanrossum Comment: Thomas, please check this in -- there's still time to get it into 2.1a1. Then reassign to Fred for the docs! ------------------------------------------------------- Date: 2001-Jan-17 07:50 By: gvanrossum Comment: Thomas, go for it. I'd say "the current time" instead of "now" in the NEWS item. I'll defer to Fred for the docs. ------------------------------------------------------- Date: 2001-Jan-17 06:55 By: twouters Comment: That's what I meant with 'check the size', but I still think it kind of breaks the abstraction of 'args'. Not in a terribly scary way, but the difference between calling floattime() always and doing a check whether or not to call floattime() isn't that big either. But you is BDFL, boss, so here's a patch that does it your way :) It also adds a NEWS entry and fixes the docs for timemodule (including docstrings.) Assigned to Fred so he can take a quick look at the docs. Don't need to check the TeX code though, Fred, I successfully built ps files on my laptop :) ------------------------------------------------------- Date: 2001-Jan-17 06:01 By: gvanrossum Comment: With METH_VARARGS, args is guaranteed to be a tuple, so you can simply use PyTuple_Size(). ------------------------------------------------------- Date: 2001-Jan-17 01:24 By: twouters Comment: Calling floattime() only when necessary would be nice, but isn't possible without a value that reads as 'empty'. There is no way to see whether optional values of a ParseTuple call were filled or not, except by comparing the old value with the new one, and that means making a token float value that means 'no argument'. We could check the length of 'args' to see howmany arguments it contains, but that is a very fragile way, and breaks the wonderful transparentness of argument-passing and PyArg_Parse*. The alternative to this approach is not reading a double from the arglist, but a Python object (initialized as NULL,) and converting that to a float. That would have my preference over the other two options, above, but I still prefer the current way -- much less code, not that much slower (if slower at all, I didn't time it.) (Unless of course there is a way to see howmany optional arguments were used ? Like a separate format character that fills an int with that information, or a separate PyArg API call that returns not success/failure, but the number of optional arguments used, and -1 on failure.) I'll add news + docs, too, sometime before friday if work permits :P ------------------------------------------------------- Date: 2001-Jan-16 20:29 By: gvanrossum Comment: How hard would it be to avoid calling floattime() when an argument is present (in gmtime() and localtime())? Missing: docs, NEWS item. Otherwise, great -- ready to check in if you fix the above things! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103265&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:54:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:54:24 -0800 Subject: [Patches] [Patch #103314] allow urllib.urlencode to work with multivalued parameters Message-ID: <E14JkQK-0003tM-00@usw-sf-web1.sourceforge.net> Patch #103314 has been updated. Project: python Category: library Status: Open Submitted by: montanaro Assigned to : fdrake Summary: allow urllib.urlencode to work with multivalued parameters Follow-Ups: Date: 2001-Jan-19 14:54 By: gvanrossum Comment: Skip, please check the code in, leave the docs until Fred approves. ------------------------------------------------------- Date: 2001-Jan-18 10:09 By: gvanrossum Comment: Comment: I would test for doseq once, and then have two loops: one with the old behavior and one with the new. Also, you might want to catch Unicode and explicitly force it into ASCII (rather than committing to a conversion without knowing what's the right thing). ------------------------------------------------------- Date: 2001-Jan-18 09:42 By: montanaro Comment: Assigned to Fred for starters because it does have a doc change. Fred, Guido probably wants to look at it next, but you're a better judge of who might have more free time... S ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103314&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:57:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:57:07 -0800 Subject: [Patches] [Patch #102229] a better robotparser.py module Message-ID: <E14JkSx-00082B-00@usw-sf-web3.sourceforge.net> Patch #102229 has been updated. Project: python Category: Modules Status: Open Submitted by: calvin Assigned to : montanaro Summary: a better robotparser.py module Follow-Ups: Date: 2001-Jan-19 14:57 By: gvanrossum Comment: Skip, if this is ok with you, can you check it in? (Unless you feel you don't want to check it in because you still feel your module is better -- in that case we should probably drop it or reassign it...) ------------------------------------------------------- Date: 2001-Jan-06 04:31 By: calvin Comment: Ok, some new changes: - allow parsing of user-agent: lines without preceding blank line - two licenses available: Python 2.0 license or GPL license - add some doc string for the classes Bastian ------------------------------------------------------- Date: 2001-Jan-04 18:31 By: gvanrossum Comment: Skip, back to you. Please work with the author on an acceptable version. You can check it in once you two agree. ------------------------------------------------------- Date: 2001-Jan-04 17:43 By: montanaro Comment: I fixed the robots.txt file, but I think you should parse files without the requisite blank lines (be lenient in what you accept and strict in what you generate). The user-agent line can serve as an implicit separator between one record and the next. Skip ------------------------------------------------------- Date: 2001-Jan-04 15:51 By: calvin Comment: Changes: - global debug variable in the test function - redirection now works - accidently printed "Allow" when I meant "Disallow". This has been fixed. It parses the Musi-Cal robots.txt file correctly, but the robots.txt file has syntax errors: before each user-agent: line there has to be one or more empty lines. ------------------------------------------------------- Date: 2001-Jan-04 13:05 By: montanaro Comment: I apologize for taking so long to take a look at this. I was reminded of it when I saw the switch from me to Guido. I spent a little time fiddling with this module today. I'm not satisfied that it works as advertised. Here are a number of problems I found: * in the test function, the debug variable is not declared global, so setting it to 1 has no effect * it never seemed to properly handle redirections, so it never got from http://www.musi-cal.com/robots.txt to http://musi-cal.mojam.com/robots.txt * once I worked around the redirection problem it seemed to parse the Musi-Cal robots.txt file incorrectly. I replaced httplib with urllib in the read method and got erroneous results. If you look at the above robots.txt file you'll see that a bunch of email address harvesters are explicitly forbidden (not that they pay attention to robots.txt!). The following should print 0, but prints 1: print rp.can_fetch('ExtractorPro', 'http://musi-cal.mojam.com/') This is (at least in part) due to the fact that the redirection never works. In the version I modified to use urllib, it displays incorrect permissions for things like ExtractorPro: User-agent: ExtractorPro Allow: / Note that the lines in the robot.txt file for ExtractorPro are actually User-agent: ExtractorPro Disallow: / Skip ------------------------------------------------------- Date: 2000-Nov-02 09:40 By: calvin Comment: I have written a new RobotParser module 'robotparser2.py'. This module is o backward compatible with the old one o makes correct useragent matching (is buggy in robotparser.py) o strips comments correctly (is buggy in robotparser.py) o uses httplib instead of urllib.urlopen() to catch HTTP connect errors correctly (is buggy in robotparser.py) o implements not only the draft at http://info.webcrawler.com/mak/projects/robots/norobots.html but also the new one at http://info.webcrawler.com/mak/projects/robots/norobots-rfc.html Bastian Kleineidam ------------------------------------------------------- Date: 2000-Nov-02 11:14 By: gvanrossum Comment: Skip, can you comment on this? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102229&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:59:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:59:35 -0800 Subject: [Patches] [Patch #101970] Allow urllib to support http: Message-ID: <E14JkVL-0003vF-00@usw-sf-web1.sourceforge.net> Patch #101970 has been updated. Project: python Category: library Status: Open Submitted by: prescod Assigned to : prescod Summary: Allow urllib to support http: Follow-Ups: Date: 2001-Jan-19 14:59 By: gvanrossum Comment: Paul, if you're not interested in this any more, I'll just reject it, OK? ------------------------------------------------------- Date: 2001-Jan-04 07:46 By: gvanrossum Comment: This patch should be rejected based on form. Paul, you can do better than sending in a diff without context! Also, the subject makes no sense. If you still want this, please fix the subject and submit a new patch and we'll lookj at it again. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101970&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:58:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:58:36 -0800 Subject: [Patches] [Patch #103247] Strings: '\012' -> '\n' Message-ID: <E14JkUO-0000Sv-00@usw-sf-web2.sourceforge.net> Patch #103247 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : ping Summary: Strings: '\012' -> '\n' Follow-Ups: Date: 2001-Jan-19 14:58 By: gvanrossum Comment: Ping, please check this in before Monday, so it can go into the alpha1. The docs can come later. ------------------------------------------------------- Date: 2001-Jan-15 21:42 By: ping Comment: Yes, the docs will take some work. I'll resubmit when i've gone through all the documentation. ------------------------------------------------------- Date: 2001-Jan-15 20:21 By: gvanrossum Comment: Nice. Style nit: I don't care for the fputc(), fputc(); form. Can you resubmit (and retest!) a version that uses \x%02x too? I'd expect that this would require updates to some docs and the tutorial, too. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103247&group_id=5470 From noreply@sourceforge.net Sat Jan 20 01:49:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 17:49:28 -0800 Subject: [Patches] [Patch #103297] __all__ values for a handful of modules Message-ID: <E14Jn9k-0001IF-00@usw-sf-web2.sourceforge.net> Patch #103297 has been updated. Project: python Category: library Status: Open Submitted by: montanaro Assigned to : montanaro Summary: __all__ values for a handful of modules Follow-Ups: Date: 2001-Jan-19 17:49 By: tim_one Comment: I had wondered out loud whether test functions would get included in the context of the __exports__ patch, which was an unbreachable wall: I didn't want to be left with *no* way to execute a module's test function from within a different module. I agree that test functions should not be included in the context of __all__, though -- I can get at them whether or not they're in __all__, and they're not what an "import *" abuser wants to see anyway. ------------------------------------------------------- Date: 2001-Jan-19 14:43 By: gvanrossum Comment: So where's the next update? I would approve of adding this to the alpha1 release. ------------------------------------------------------- Date: 2001-Jan-18 18:32 By: gvanrossum Comment: Nice, Skip! I wonder if the "test" functions should really be included in __all__? Especially StringIO's test isn't generally needed. I'd be happy if I had to import it explicitly using "from StringIO import test" if I really wanted it. Ditto for the HTTP server classes. ------------------------------------------------------- Date: 2001-Jan-18 19:09 By: montanaro Comment: Yeah, I wondered about including "test". I included it only because I thought I remembered someone mentioning that in a previous thread. I'll remove "test" from __all__ in my next update. Assuming everything else is okay, I will keep adding to the number of modified modules. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103297&group_id=5470 From noreply@sourceforge.net Sat Jan 20 05:13:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 21:13:44 -0800 Subject: [Patches] [Patch #103336] Missing cast Message-ID: <E14JqLQ-0005YJ-00@usw-sf-web1.sourceforge.net> Patch #103336 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jackjansen Assigned to : tim_one Summary: Missing cast ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103336&group_id=5470 From noreply@sourceforge.net Sat Jan 20 05:16:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 21:16:11 -0800 Subject: [Patches] [Patch #103336] Missing cast Message-ID: <E14JqNn-0005Zc-00@usw-sf-web1.sourceforge.net> Patch #103336 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jackjansen Assigned to : tim_one Summary: Missing cast Follow-Ups: Date: 2001-Jan-19 21:16 By: tim_one Comment: Checked in to compile.c rev 2.147. Jack is my hero! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103336&group_id=5470 From noreply@sourceforge.net Sat Jan 20 06:31:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 22:31:19 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: <E14JrYV-0005u3-00@usw-sf-web1.sourceforge.net> Patch #102409 has been updated. Project: python Category: Build Status: Open Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-19 22:31 By: jlt63 Comment: This patch enables Cygwin Python to build using the new Distutils style Python build. Please note that the build_ext.py part is from Jorge Sousa <jsousa@cfn.ist.utl.pt>. To patch, change directory to the top of the CVS tree and use $ patch -p0 <dist.patch The following is the ChangeLog: Sat Jan 20 01:05:18 2001 Jason Tishler <jt@dothill.com> * Makefile.in($(srcdir)/Lib/$(PLATDIR)): Add Distutils build library directory to PYTHONPATH so regen works again. (sharedinstall): Add --install-platlib option so shared extensions follow $(exec_prefix). * setup.py: Add checks for Cygwin so unsupported modules (i.e., dbm and resource) are not built. * Lib/distutils/command/build_ext.py(build_ext.finalize_options): Add Cygwin specific code to append Python's library directory to the extension's list of library directories. (build_ext.get_libraries): Add Cygwin specific code to append Python's (import) library to the extension's list of libraries. ------------------------------------------------------- Date: 2001-Jan-19 08:19 By: gvanrossum Comment: Reopened at request. Don't sweat the release date -- t's only the first alpha release. I have a feeling it'll be put off till Monday. ------------------------------------------------------- Date: 2001-Jan-18 20:52 By: jlt63 Comment: Please reopen because I need to redo the Cygwin build to handle the use of distutils to build the standard extension modules instead of Modules/Makefile.pre.in. How much time (if any) do I have to resolve these issues before 2.1a is released. I heard that the release date is tomorrow. Sigh... ------------------------------------------------------- Date: 2001-Jan-10 19:39 By: jlt63 Comment: Your welcome -- thanks for considering and accepting this patch. If the patch proves to reek havoc on other platforms (most likely only on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out. ------------------------------------------------------- Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 <Cygwin-1.1.5-Python-2.0.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Sat Jan 20 06:38:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 22:38:14 -0800 Subject: [Patches] [Patch #103185] Some more standard modules cleanup for Cygwin Message-ID: <E14JrfC-0005w6-00@usw-sf-web1.sourceforge.net> Patch #103185 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Some more standard modules cleanup for Cygwin Follow-Ups: Date: 2001-Jan-19 22:38 By: jlt63 Comment: A few more courtesy of the Distutils style Python build. Note that Modules/syslogmodule.c will *not* build cleanly until I submit a minor patch to Cygwin to resolve this issue. To patch, change directory to the top of the CVS tree and use $ patch -p0 <mods.patch ------------------------------------------------------- Date: 2001-Jan-18 16:29 By: gvanrossum Comment: Applied, and closed. ------------------------------------------------------- Date: 2001-Jan-10 21:19 By: jlt63 Comment: Use the following procedure to patch: $ cd Modules $ # save modules.patch to current directory $ patch <modules.patch ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103185&group_id=5470 From noreply@sourceforge.net Sat Jan 20 06:59:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 22:59:56 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: <E14Js0C-00061P-00@usw-sf-web1.sourceforge.net> Patch #103154 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-19 22:59 By: jlt63 Comment: Please reopen so that this issue is not accidentally overlooked. At least, until the case sensitive import problem is resolved. I still have a pending patch submitted for consideration. Sorry, to be a pest... ------------------------------------------------------- Date: 2001-Jan-12 11:48 By: tim_one Comment: Ah, I see. There's a difference between Windows filesystems and filesystems used on Windows <wink/sigh>. Older Novell network fileservers for Windows do indeed destroy the case of file names, and newer ones are often configured in a compatability mode to keep on doing that. At my last employer, more than half the LAN servers were set up that way. Use of PYTHONCASEOK was universal as a result. We were also screwed in that one of the popular Windows source-control systems *also* destroyed case (I didn't use that, and have forgotten the name): check in OhNo.py, check out OHNO.PY. Brrrrrrrrr. ------------------------------------------------------- Date: 2001-Jan-12 10:52 By: gvanrossum Comment: Maybe things are different now. But I definitely remember that when I introduced this test, Mark Hammond told me that there was a popular networking filesystem that didn't preserve case. This was either for Windows NT or Windows 95, so it's not a Windows 3.1 thing (although it's possible that the fileserver in question was a bad port from DOS or Windows 3.1 of course). ------------------------------------------------------- Date: 2001-Jan-12 10:47 By: jlt63 Comment: I know. I was just confused by the following On 2001-Jan-11 06:47, gvanrossum wrote: > Note that I believe that "import termios, TERMIOS" *should fail* -- not all > filesystems used on Windows are case preserving. ------------------------------------------------------- Date: 2001-Jan-12 10:26 By: tim_one Comment: The filesystems do preserve the case of names. But all platform file *lookup* APIs are case-insensitive. ------------------------------------------------------- Date: 2001-Jan-12 09:50 By: jlt63 Comment: Oops... Use the following procedure to patch: $ cd Python $ # save case.patch to current directory $ patch <case.patch ------------------------------------------------------- Date: 2001-Jan-12 09:44 By: jlt63 Comment: I just uploaded a new patch. It fixes the case sensitive import problem for Cygwin without affecting Win32 (i.e., Win32 functions as before). Now Cygwin's import behavior is identical to other UNIX platforms. I'm not completely happy with the patch and would characterize it as hacky, but it is the best that I can do without fully grokking import.c. I think to do better would require major rework to find_module(). I guess by renaming TERMIOS you mean to change the module names generated by h2py.py. I have no issue with this -- will others? I thought all filesystems on Windows 95/NT 3.51 and later, were case preserving. To what filesystems and Windows versions are you referring? ------------------------------------------------------- Date: 2001-Jan-11 13:59 By: gvanrossum Comment: Upload it as a new patch. But I believe the solution is that the TERMIOS module should be renamed. ------------------------------------------------------- Date: 2001-Jan-11 07:56 By: jlt63 Comment: Actually, this is not a bug in my original version. Cygwin Python is behaving identically to the Win32 one. Unfortunately, as you pointed out Win32 Python definitely does not handle the situation of two modules that only differ by case. Sigh... If one tries to import the second module that would be found in sys.path, then a NameError: Case mismatch ... exception will *always* be generated. I'm not sure that I agree with this behavior but I really a UNIX guy. Since Cygwin Python should support as many UNIX modules as possible, it needs to deal with modules that only differ by case. termios and TERMIOS used by getpass is a perfect example. I have created a (hacky) patch, that solves this problem for both Cygwin and Win32. I can redo it so that it only affects Cygwin and leaves the Win32 functionality alone. I would like to upload it for discussion but I am concerned about overwriting the old version. Should I upload it anyway? ------------------------------------------------------- Date: 2001-Jan-11 06:47 By: gvanrossum Comment: Reopened at request. Note that I believe that "import termios, TERMIOS" *should fail* -- not all filesystems used on Windows are case preserving. I've had this battle with Mark Hammond before. The case check is intended to prevent you from importing a moduleusing the wrong case (e.g. import String). It is *not* intended to let you have two modules that only differ in case. ------------------------------------------------------- Date: 2001-Jan-10 19:48 By: jlt63 Comment: I have already checked that this patch does not break the Windows VC build before I submitted it. However, Tim is welcome to reverify himself. Unfortunately, I have found a bug with this patch that (only) affects Cygwin. Although this patch handles the following: import String it does not handle the following: import termios, TERMIOS I will resubmit a new version shortly, please change the status back to open. ------------------------------------------------------- Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler <jt@dothill.com> * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Sat Jan 20 16:03:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 20 Jan 2001 08:03:56 -0800 Subject: [Patches] [Patch #102229] a better robotparser.py module Message-ID: <E14K0Ue-00053k-00@usw-sf-web2.sourceforge.net> Patch #102229 has been updated. Project: python Category: library Status: Closed Submitted by: calvin Assigned to : montanaro Summary: a better robotparser.py module Follow-Ups: Date: 2001-Jan-20 08:03 By: montanaro Comment: Checked in and closed. Thanks Bastian! ------------------------------------------------------- Date: 2001-Jan-19 14:57 By: gvanrossum Comment: Skip, if this is ok with you, can you check it in? (Unless you feel you don't want to check it in because you still feel your module is better -- in that case we should probably drop it or reassign it...) ------------------------------------------------------- Date: 2001-Jan-06 04:31 By: calvin Comment: Ok, some new changes: - allow parsing of user-agent: lines without preceding blank line - two licenses available: Python 2.0 license or GPL license - add some doc string for the classes Bastian ------------------------------------------------------- Date: 2001-Jan-04 18:31 By: gvanrossum Comment: Skip, back to you. Please work with the author on an acceptable version. You can check it in once you two agree. ------------------------------------------------------- Date: 2001-Jan-04 17:43 By: montanaro Comment: I fixed the robots.txt file, but I think you should parse files without the requisite blank lines (be lenient in what you accept and strict in what you generate). The user-agent line can serve as an implicit separator between one record and the next. Skip ------------------------------------------------------- Date: 2001-Jan-04 15:51 By: calvin Comment: Changes: - global debug variable in the test function - redirection now works - accidently printed "Allow" when I meant "Disallow". This has been fixed. It parses the Musi-Cal robots.txt file correctly, but the robots.txt file has syntax errors: before each user-agent: line there has to be one or more empty lines. ------------------------------------------------------- Date: 2001-Jan-04 13:05 By: montanaro Comment: I apologize for taking so long to take a look at this. I was reminded of it when I saw the switch from me to Guido. I spent a little time fiddling with this module today. I'm not satisfied that it works as advertised. Here are a number of problems I found: * in the test function, the debug variable is not declared global, so setting it to 1 has no effect * it never seemed to properly handle redirections, so it never got from http://www.musi-cal.com/robots.txt to http://musi-cal.mojam.com/robots.txt * once I worked around the redirection problem it seemed to parse the Musi-Cal robots.txt file incorrectly. I replaced httplib with urllib in the read method and got erroneous results. If you look at the above robots.txt file you'll see that a bunch of email address harvesters are explicitly forbidden (not that they pay attention to robots.txt!). The following should print 0, but prints 1: print rp.can_fetch('ExtractorPro', 'http://musi-cal.mojam.com/') This is (at least in part) due to the fact that the redirection never works. In the version I modified to use urllib, it displays incorrect permissions for things like ExtractorPro: User-agent: ExtractorPro Allow: / Note that the lines in the robot.txt file for ExtractorPro are actually User-agent: ExtractorPro Disallow: / Skip ------------------------------------------------------- Date: 2000-Nov-02 09:40 By: calvin Comment: I have written a new RobotParser module 'robotparser2.py'. This module is o backward compatible with the old one o makes correct useragent matching (is buggy in robotparser.py) o strips comments correctly (is buggy in robotparser.py) o uses httplib instead of urllib.urlopen() to catch HTTP connect errors correctly (is buggy in robotparser.py) o implements not only the draft at http://info.webcrawler.com/mak/projects/robots/norobots.html but also the new one at http://info.webcrawler.com/mak/projects/robots/norobots-rfc.html Bastian Kleineidam ------------------------------------------------------- Date: 2000-Nov-02 11:14 By: gvanrossum Comment: Skip, can you comment on this? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102229&group_id=5470 From noreply@sourceforge.net Sat Jan 20 16:47:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 20 Jan 2001 08:47:17 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: <E14K1Ab-0000JN-00@usw-sf-web1.sourceforge.net> Patch #103154 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-20 08:47 By: gvanrossum Comment: Reopened at request. But I won't *do* anything about this until I've heard the arguments one more time. ------------------------------------------------------- Date: 2001-Jan-19 22:59 By: jlt63 Comment: Please reopen so that this issue is not accidentally overlooked. At least, until the case sensitive import problem is resolved. I still have a pending patch submitted for consideration. Sorry, to be a pest... ------------------------------------------------------- Date: 2001-Jan-12 11:48 By: tim_one Comment: Ah, I see. There's a difference between Windows filesystems and filesystems used on Windows <wink/sigh>. Older Novell network fileservers for Windows do indeed destroy the case of file names, and newer ones are often configured in a compatability mode to keep on doing that. At my last employer, more than half the LAN servers were set up that way. Use of PYTHONCASEOK was universal as a result. We were also screwed in that one of the popular Windows source-control systems *also* destroyed case (I didn't use that, and have forgotten the name): check in OhNo.py, check out OHNO.PY. Brrrrrrrrr. ------------------------------------------------------- Date: 2001-Jan-12 10:52 By: gvanrossum Comment: Maybe things are different now. But I definitely remember that when I introduced this test, Mark Hammond told me that there was a popular networking filesystem that didn't preserve case. This was either for Windows NT or Windows 95, so it's not a Windows 3.1 thing (although it's possible that the fileserver in question was a bad port from DOS or Windows 3.1 of course). ------------------------------------------------------- Date: 2001-Jan-12 10:47 By: jlt63 Comment: I know. I was just confused by the following On 2001-Jan-11 06:47, gvanrossum wrote: > Note that I believe that "import termios, TERMIOS" *should fail* -- not all > filesystems used on Windows are case preserving. ------------------------------------------------------- Date: 2001-Jan-12 10:26 By: tim_one Comment: The filesystems do preserve the case of names. But all platform file *lookup* APIs are case-insensitive. ------------------------------------------------------- Date: 2001-Jan-12 09:50 By: jlt63 Comment: Oops... Use the following procedure to patch: $ cd Python $ # save case.patch to current directory $ patch <case.patch ------------------------------------------------------- Date: 2001-Jan-12 09:44 By: jlt63 Comment: I just uploaded a new patch. It fixes the case sensitive import problem for Cygwin without affecting Win32 (i.e., Win32 functions as before). Now Cygwin's import behavior is identical to other UNIX platforms. I'm not completely happy with the patch and would characterize it as hacky, but it is the best that I can do without fully grokking import.c. I think to do better would require major rework to find_module(). I guess by renaming TERMIOS you mean to change the module names generated by h2py.py. I have no issue with this -- will others? I thought all filesystems on Windows 95/NT 3.51 and later, were case preserving. To what filesystems and Windows versions are you referring? ------------------------------------------------------- Date: 2001-Jan-11 13:59 By: gvanrossum Comment: Upload it as a new patch. But I believe the solution is that the TERMIOS module should be renamed. ------------------------------------------------------- Date: 2001-Jan-11 07:56 By: jlt63 Comment: Actually, this is not a bug in my original version. Cygwin Python is behaving identically to the Win32 one. Unfortunately, as you pointed out Win32 Python definitely does not handle the situation of two modules that only differ by case. Sigh... If one tries to import the second module that would be found in sys.path, then a NameError: Case mismatch ... exception will *always* be generated. I'm not sure that I agree with this behavior but I really a UNIX guy. Since Cygwin Python should support as many UNIX modules as possible, it needs to deal with modules that only differ by case. termios and TERMIOS used by getpass is a perfect example. I have created a (hacky) patch, that solves this problem for both Cygwin and Win32. I can redo it so that it only affects Cygwin and leaves the Win32 functionality alone. I would like to upload it for discussion but I am concerned about overwriting the old version. Should I upload it anyway? ------------------------------------------------------- Date: 2001-Jan-11 06:47 By: gvanrossum Comment: Reopened at request. Note that I believe that "import termios, TERMIOS" *should fail* -- not all filesystems used on Windows are case preserving. I've had this battle with Mark Hammond before. The case check is intended to prevent you from importing a moduleusing the wrong case (e.g. import String). It is *not* intended to let you have two modules that only differ in case. ------------------------------------------------------- Date: 2001-Jan-10 19:48 By: jlt63 Comment: I have already checked that this patch does not break the Windows VC build before I submitted it. However, Tim is welcome to reverify himself. Unfortunately, I have found a bug with this patch that (only) affects Cygwin. Although this patch handles the following: import String it does not handle the following: import termios, TERMIOS I will resubmit a new version shortly, please change the status back to open. ------------------------------------------------------- Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler <jt@dothill.com> * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Sat Jan 20 17:12:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 20 Jan 2001 09:12:47 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14K1ZH-0005O8-00@usw-sf-web2.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : nascheme Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-20 09:12 By: nascheme Comment: Why do weak references need callbacks? I see nothing in the PEP to justify this feature. If there is no good reason for them, I propose that the feature be removed for 2.1. Allowing callbacks may make it harder to implement weak references more efficiently later. ------------------------------------------------------- Date: 2001-Jan-18 16:03 By: loewis Comment: The patch looks ok in general, pending resolution of the issues on the PEP itself. Some nits: Integration with GC is still fuzzy. If an instance is GC collected and had a weak ref to it and the weak ref had a callback and the callback choses to resurrect the object, semantics is unclear. This is equivalent to the object having an __del__; the GC would normally *not* collect such objects, but put them into gc.garbage. Proposed resolution: it is a fatal error to resurrect an object in a weakref callback. Hashing: it appears that the hash of a weakref can change when the underlying object goes away. If the weakref is used as key in a dictionary, it appears to be impossible to get the key out of the dictionary after the underlying object is gone. Proposed resolution: a proxy weak ref should cache the hash of the underlying object after its hash function was called for the first time. Comparing: why is the return value of tp_compare -1 when try_3way_compare expects -2 on error? Shouldn't there be some exception set when the underlying object goes away? ------------------------------------------------------- Date: 2001-Jan-17 13:53 By: fdrake Comment: Ok, I tihnk this is it! http://starship.python.net/crew/fdrake/patches/weakref.patch-5 This patch fixes the compilation problems from the previoous patch related to the introduction of rich comparisons, and makes a change in the way new objects are initialized by PyObject_New() and PyObject_NEW() (and all their friends!) -- those functions now know to initialize the weak reference list to NULL for objects which support weak references. Without this change, more places in the code (especially extension modules) need to know more about initialization of weakly-referencable objects. For instance, the "cPickle" and "new" modules both can create instances without calling the code in classobject.c (using PyObject_New()), causing core dumps when such instances are deallocated if the weak-reference list for instances was not properly initialized. Since these modules (properly) tried to avoid call PyInstance_New(), core dumps ensued and the world fell apart. By moving the initialization of the weak reference list into the core object allocators, this problem is averted and extension code to construct new weakly referencable types is simplified. The documentation still needs work, and there are a few new entries for the Python/C API manual as well. A new constructor for instances, PyInstance_NewRaw(), will be added in a separate patch. ------------------------------------------------------- Date: 2001-Jan-17 11:58 By: nascheme Comment: The magic test is: ./python Lib/test/regrtest.py test_weakref test_new Try adding this patch: --- Modules/newmodule.c 2000/11/13 20:29:20 2.29 +++ Modules/newmodule.c 2001/01/17 19:55:46 @@ -24,6 +24,7 @@ Py_INCREF(dict); inst->in_class = (PyClassObject *)klass; inst->in_dict = dict; + inst->in_weakreflist = NULL; PyObject_GC_Init(inst); return (PyObject *)inst; } ------------------------------------------------------- Date: 2001-Jan-17 08:04 By: fdrake Comment: New version of the patch that's still broken but doesn't conflict with the rich comparisons changes: http://starship.python.net/crew/fdrake/patches/weakref.patch-4 ------------------------------------------------------- Date: 2001-Jan-16 21:35 By: fdrake Comment: Added a new (but broken!) version of the patch that fixes WeakDictionary.get() but doesn't interact properly with GC (appearantly) -- not usable as is: http://starship.python.net/crew/fdrake/patches/weakref.patch-3 Neil made the mistake of volunteering to look at the current problem, so assigning to him. (Thanks!) ------------------------------------------------------- Date: 2001-Jan-16 19:39 By: tim_one Comment: Just mentioning a general scenario in which weak keys are the bee's knees: sometimes you want to add attributes to objects dynamically, in ways the original class author(s -- may cut across many classes! even non-instance objects; or objects from extension modules that don't support setattr) never anticipated. Like maybe a German translation of the object's docstrings; or a list of JPEG contents referenced by a URLish object; or a table of usage statistics on methods and functions; etc. Then it's natural to use the conceptual attr name as the name of a dict instead, and write attr[object] = whatever instead of object.attr = whatever There's no point keeping the "whatever" around when the object goes away, but a regular dict makes the object and its "whatever" immortal. A dict with weak keys is exactly on-target. ------------------------------------------------------- Date: 2001-Jan-16 19:14 By: fdrake Comment: I'm not entirely sure why one would want weak keys rather than weak values, but I suspect it has to do with expectations of how the dict will be used in applications. I don't think it would be hard to support both flavors of dictionaries using the primitive reference objects. The constructor does not check that all incoming values are weak because that isn't required. It uses self.update() rather than self.data.update() to perform the inclusion, so any mapping that supports .keys() and .__getitem__() is sufficient. Some additional checking could be done to make sure that all added entries can be created before inserting any of them, offering more atomicity. .get() will be fixed in the next version of the patch; thanks! I've added GC support, but don't have it working quite right. I'm trying to isolate the failure now. ------------------------------------------------------- Date: 2001-Jan-12 14:36 By: loewis Comment: The weak dictionary data type needs more clarification in documentation and implementation. In java.util.WeakHashMap, they keys are weak, not the values (i.e. once the key is forgotten, the entry is cleared). In http://www.handshake.de/~dieter/weakdict.html, the values are weak, but it raises KeyErrors for entries that are collected. The initializer of a weak dict does not check the invariant (all values are weak). get() of a weakdict does not support an optional second parameter. weakref and friends need to participate in garbage collection, as the reference to the callback can create a cycle. ------------------------------------------------------- Date: 2001-Jan-12 11:27 By: fdrake Comment: Updated patch to also support proxy semantics using the same invalidation machinery as the basic weak reference type. The additional code is *heavily* borrowed from Neil Schemenauer. ------------------------------------------------------- Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Sat Jan 20 17:42:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 20 Jan 2001 09:42:16 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14K21o-0000Zv-00@usw-sf-web1.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : nascheme Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-20 09:42 By: gvanrossum Comment: I think callbacks are needed to implement various forms of weak dicts: when the object is deleted, whatever's in the weak dict for it should be deleted as well. Even though we may not provide weak dicts in 2.1a1, we should still support writing them using what we *do* provide. IMHO (I still haven't had the time to read the PEP or Fred's code. :-( ) ------------------------------------------------------- Date: 2001-Jan-20 09:12 By: nascheme Comment: Why do weak references need callbacks? I see nothing in the PEP to justify this feature. If there is no good reason for them, I propose that the feature be removed for 2.1. Allowing callbacks may make it harder to implement weak references more efficiently later. ------------------------------------------------------- Date: 2001-Jan-18 16:03 By: loewis Comment: The patch looks ok in general, pending resolution of the issues on the PEP itself. Some nits: Integration with GC is still fuzzy. If an instance is GC collected and had a weak ref to it and the weak ref had a callback and the callback choses to resurrect the object, semantics is unclear. This is equivalent to the object having an __del__; the GC would normally *not* collect such objects, but put them into gc.garbage. Proposed resolution: it is a fatal error to resurrect an object in a weakref callback. Hashing: it appears that the hash of a weakref can change when the underlying object goes away. If the weakref is used as key in a dictionary, it appears to be impossible to get the key out of the dictionary after the underlying object is gone. Proposed resolution: a proxy weak ref should cache the hash of the underlying object after its hash function was called for the first time. Comparing: why is the return value of tp_compare -1 when try_3way_compare expects -2 on error? Shouldn't there be some exception set when the underlying object goes away? ------------------------------------------------------- Date: 2001-Jan-17 13:53 By: fdrake Comment: Ok, I tihnk this is it! http://starship.python.net/crew/fdrake/patches/weakref.patch-5 This patch fixes the compilation problems from the previoous patch related to the introduction of rich comparisons, and makes a change in the way new objects are initialized by PyObject_New() and PyObject_NEW() (and all their friends!) -- those functions now know to initialize the weak reference list to NULL for objects which support weak references. Without this change, more places in the code (especially extension modules) need to know more about initialization of weakly-referencable objects. For instance, the "cPickle" and "new" modules both can create instances without calling the code in classobject.c (using PyObject_New()), causing core dumps when such instances are deallocated if the weak-reference list for instances was not properly initialized. Since these modules (properly) tried to avoid call PyInstance_New(), core dumps ensued and the world fell apart. By moving the initialization of the weak reference list into the core object allocators, this problem is averted and extension code to construct new weakly referencable types is simplified. The documentation still needs work, and there are a few new entries for the Python/C API manual as well. A new constructor for instances, PyInstance_NewRaw(), will be added in a separate patch. ------------------------------------------------------- Date: 2001-Jan-17 11:58 By: nascheme Comment: The magic test is: ./python Lib/test/regrtest.py test_weakref test_new Try adding this patch: --- Modules/newmodule.c 2000/11/13 20:29:20 2.29 +++ Modules/newmodule.c 2001/01/17 19:55:46 @@ -24,6 +24,7 @@ Py_INCREF(dict); inst->in_class = (PyClassObject *)klass; inst->in_dict = dict; + inst->in_weakreflist = NULL; PyObject_GC_Init(inst); return (PyObject *)inst; } ------------------------------------------------------- Date: 2001-Jan-17 08:04 By: fdrake Comment: New version of the patch that's still broken but doesn't conflict with the rich comparisons changes: http://starship.python.net/crew/fdrake/patches/weakref.patch-4 ------------------------------------------------------- Date: 2001-Jan-16 21:35 By: fdrake Comment: Added a new (but broken!) version of the patch that fixes WeakDictionary.get() but doesn't interact properly with GC (appearantly) -- not usable as is: http://starship.python.net/crew/fdrake/patches/weakref.patch-3 Neil made the mistake of volunteering to look at the current problem, so assigning to him. (Thanks!) ------------------------------------------------------- Date: 2001-Jan-16 19:39 By: tim_one Comment: Just mentioning a general scenario in which weak keys are the bee's knees: sometimes you want to add attributes to objects dynamically, in ways the original class author(s -- may cut across many classes! even non-instance objects; or objects from extension modules that don't support setattr) never anticipated. Like maybe a German translation of the object's docstrings; or a list of JPEG contents referenced by a URLish object; or a table of usage statistics on methods and functions; etc. Then it's natural to use the conceptual attr name as the name of a dict instead, and write attr[object] = whatever instead of object.attr = whatever There's no point keeping the "whatever" around when the object goes away, but a regular dict makes the object and its "whatever" immortal. A dict with weak keys is exactly on-target. ------------------------------------------------------- Date: 2001-Jan-16 19:14 By: fdrake Comment: I'm not entirely sure why one would want weak keys rather than weak values, but I suspect it has to do with expectations of how the dict will be used in applications. I don't think it would be hard to support both flavors of dictionaries using the primitive reference objects. The constructor does not check that all incoming values are weak because that isn't required. It uses self.update() rather than self.data.update() to perform the inclusion, so any mapping that supports .keys() and .__getitem__() is sufficient. Some additional checking could be done to make sure that all added entries can be created before inserting any of them, offering more atomicity. .get() will be fixed in the next version of the patch; thanks! I've added GC support, but don't have it working quite right. I'm trying to isolate the failure now. ------------------------------------------------------- Date: 2001-Jan-12 14:36 By: loewis Comment: The weak dictionary data type needs more clarification in documentation and implementation. In java.util.WeakHashMap, they keys are weak, not the values (i.e. once the key is forgotten, the entry is cleared). In http://www.handshake.de/~dieter/weakdict.html, the values are weak, but it raises KeyErrors for entries that are collected. The initializer of a weak dict does not check the invariant (all values are weak). get() of a weakdict does not support an optional second parameter. weakref and friends need to participate in garbage collection, as the reference to the callback can create a cycle. ------------------------------------------------------- Date: 2001-Jan-12 11:27 By: fdrake Comment: Updated patch to also support proxy semantics using the same invalidation machinery as the basic weak reference type. The additional code is *heavily* borrowed from Neil Schemenauer. ------------------------------------------------------- Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Sat Jan 20 19:07:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 20 Jan 2001 11:07:25 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: <E14K3MD-00054s-00@usw-sf-web3.sourceforge.net> Patch #103154 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-20 11:07 By: jlt63 Comment: Skip Montanaro and yourself (at least initially) suggested that this problem should be solved by renaming the modules in question (e.g., TERMIOS) so that they are unique regardless of case. As a following up, you suggested that "An even better solution is to get rid of those generated headers and incorporate the desired symbols directly in the C extension modules." If neither of the two solutions will make it into 2.1a, then I will lobby for the acceptance of my (albeit hacky) patch. It will only affect Cygwin Python and makes it behave identical to other UNIX versions. When a better solution is finally implemented, then the Cygwin cruft can be ripped out. ------------------------------------------------------- Date: 2001-Jan-20 08:47 By: gvanrossum Comment: Reopened at request. But I won't *do* anything about this until I've heard the arguments one more time. ------------------------------------------------------- Date: 2001-Jan-19 22:59 By: jlt63 Comment: Please reopen so that this issue is not accidentally overlooked. At least, until the case sensitive import problem is resolved. I still have a pending patch submitted for consideration. Sorry, to be a pest... ------------------------------------------------------- Date: 2001-Jan-12 11:48 By: tim_one Comment: Ah, I see. There's a difference between Windows filesystems and filesystems used on Windows <wink/sigh>. Older Novell network fileservers for Windows do indeed destroy the case of file names, and newer ones are often configured in a compatability mode to keep on doing that. At my last employer, more than half the LAN servers were set up that way. Use of PYTHONCASEOK was universal as a result. We were also screwed in that one of the popular Windows source-control systems *also* destroyed case (I didn't use that, and have forgotten the name): check in OhNo.py, check out OHNO.PY. Brrrrrrrrr. ------------------------------------------------------- Date: 2001-Jan-12 10:52 By: gvanrossum Comment: Maybe things are different now. But I definitely remember that when I introduced this test, Mark Hammond told me that there was a popular networking filesystem that didn't preserve case. This was either for Windows NT or Windows 95, so it's not a Windows 3.1 thing (although it's possible that the fileserver in question was a bad port from DOS or Windows 3.1 of course). ------------------------------------------------------- Date: 2001-Jan-12 10:47 By: jlt63 Comment: I know. I was just confused by the following On 2001-Jan-11 06:47, gvanrossum wrote: > Note that I believe that "import termios, TERMIOS" *should fail* -- not all > filesystems used on Windows are case preserving. ------------------------------------------------------- Date: 2001-Jan-12 10:26 By: tim_one Comment: The filesystems do preserve the case of names. But all platform file *lookup* APIs are case-insensitive. ------------------------------------------------------- Date: 2001-Jan-12 09:50 By: jlt63 Comment: Oops... Use the following procedure to patch: $ cd Python $ # save case.patch to current directory $ patch <case.patch ------------------------------------------------------- Date: 2001-Jan-12 09:44 By: jlt63 Comment: I just uploaded a new patch. It fixes the case sensitive import problem for Cygwin without affecting Win32 (i.e., Win32 functions as before). Now Cygwin's import behavior is identical to other UNIX platforms. I'm not completely happy with the patch and would characterize it as hacky, but it is the best that I can do without fully grokking import.c. I think to do better would require major rework to find_module(). I guess by renaming TERMIOS you mean to change the module names generated by h2py.py. I have no issue with this -- will others? I thought all filesystems on Windows 95/NT 3.51 and later, were case preserving. To what filesystems and Windows versions are you referring? ------------------------------------------------------- Date: 2001-Jan-11 13:59 By: gvanrossum Comment: Upload it as a new patch. But I believe the solution is that the TERMIOS module should be renamed. ------------------------------------------------------- Date: 2001-Jan-11 07:56 By: jlt63 Comment: Actually, this is not a bug in my original version. Cygwin Python is behaving identically to the Win32 one. Unfortunately, as you pointed out Win32 Python definitely does not handle the situation of two modules that only differ by case. Sigh... If one tries to import the second module that would be found in sys.path, then a NameError: Case mismatch ... exception will *always* be generated. I'm not sure that I agree with this behavior but I really a UNIX guy. Since Cygwin Python should support as many UNIX modules as possible, it needs to deal with modules that only differ by case. termios and TERMIOS used by getpass is a perfect example. I have created a (hacky) patch, that solves this problem for both Cygwin and Win32. I can redo it so that it only affects Cygwin and leaves the Win32 functionality alone. I would like to upload it for discussion but I am concerned about overwriting the old version. Should I upload it anyway? ------------------------------------------------------- Date: 2001-Jan-11 06:47 By: gvanrossum Comment: Reopened at request. Note that I believe that "import termios, TERMIOS" *should fail* -- not all filesystems used on Windows are case preserving. I've had this battle with Mark Hammond before. The case check is intended to prevent you from importing a moduleusing the wrong case (e.g. import String). It is *not* intended to let you have two modules that only differ in case. ------------------------------------------------------- Date: 2001-Jan-10 19:48 By: jlt63 Comment: I have already checked that this patch does not break the Windows VC build before I submitted it. However, Tim is welcome to reverify himself. Unfortunately, I have found a bug with this patch that (only) affects Cygwin. Although this patch handles the following: import String it does not handle the following: import termios, TERMIOS I will resubmit a new version shortly, please change the status back to open. ------------------------------------------------------- Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler <jt@dothill.com> * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Sat Jan 20 19:08:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 20 Jan 2001 11:08:34 -0800 Subject: [Patches] [Patch #103297] __all__ values for a handful of modules Message-ID: <E14K3NK-00012y-00@usw-sf-web1.sourceforge.net> Patch #103297 has been updated. Project: python Category: library Status: Open Submitted by: montanaro Assigned to : montanaro Summary: __all__ values for a handful of modules Follow-Ups: Date: 2001-Jan-20 11:08 By: montanaro Comment: Latest version - this takes me through dis.py, and throws in robotparser.py for good measure. ------------------------------------------------------- Date: 2001-Jan-19 17:49 By: tim_one Comment: I had wondered out loud whether test functions would get included in the context of the __exports__ patch, which was an unbreachable wall: I didn't want to be left with *no* way to execute a module's test function from within a different module. I agree that test functions should not be included in the context of __all__, though -- I can get at them whether or not they're in __all__, and they're not what an "import *" abuser wants to see anyway. ------------------------------------------------------- Date: 2001-Jan-19 14:43 By: gvanrossum Comment: So where's the next update? I would approve of adding this to the alpha1 release. ------------------------------------------------------- Date: 2001-Jan-18 18:32 By: gvanrossum Comment: Nice, Skip! I wonder if the "test" functions should really be included in __all__? Especially StringIO's test isn't generally needed. I'd be happy if I had to import it explicitly using "from StringIO import test" if I really wanted it. Ditto for the HTTP server classes. ------------------------------------------------------- Date: 2001-Jan-18 19:09 By: montanaro Comment: Yeah, I wondered about including "test". I included it only because I thought I remembered someone mentioning that in a previous thread. I'll remove "test" from __all__ in my next update. Assuming everything else is okay, I will keep adding to the number of modified modules. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103297&group_id=5470 From noreply@sourceforge.net Sat Jan 20 19:50:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 20 Jan 2001 11:50:29 -0800 Subject: [Patches] [Patch #103297] __all__ values for a handful of modules Message-ID: <E14K41t-0005J1-00@usw-sf-web3.sourceforge.net> Patch #103297 has been updated. Project: python Category: library Status: Open Submitted by: montanaro Assigned to : montanaro Summary: __all__ values for a handful of modules Follow-Ups: Date: 2001-Jan-20 11:50 By: montanaro Comment: whoops... (maybe SF should warn about this mistake?) okay, here it is for real. Includes a test___all__.py script and output as well. Please have a look at the test script and see if it seems suitable. In the meantime, I will check these things in and close the patch. ------------------------------------------------------- Date: 2001-Jan-20 11:35 By: gvanrossum Comment: Skip, I think your upload failed. Make sure that you click the "Upload Revised Patch" checkbox as well as specifying a file... (You can also just check this in, it all seems pretty harmless to me.) ------------------------------------------------------- Date: 2001-Jan-20 11:08 By: montanaro Comment: Latest version - this takes me through dis.py, and throws in robotparser.py for good measure. ------------------------------------------------------- Date: 2001-Jan-19 17:49 By: tim_one Comment: I had wondered out loud whether test functions would get included in the context of the __exports__ patch, which was an unbreachable wall: I didn't want to be left with *no* way to execute a module's test function from within a different module. I agree that test functions should not be included in the context of __all__, though -- I can get at them whether or not they're in __all__, and they're not what an "import *" abuser wants to see anyway. ------------------------------------------------------- Date: 2001-Jan-19 14:43 By: gvanrossum Comment: So where's the next update? I would approve of adding this to the alpha1 release. ------------------------------------------------------- Date: 2001-Jan-18 18:32 By: gvanrossum Comment: Nice, Skip! I wonder if the "test" functions should really be included in __all__? Especially StringIO's test isn't generally needed. I'd be happy if I had to import it explicitly using "from StringIO import test" if I really wanted it. Ditto for the HTTP server classes. ------------------------------------------------------- Date: 2001-Jan-18 19:09 By: montanaro Comment: Yeah, I wondered about including "test". I included it only because I thought I remembered someone mentioning that in a previous thread. I'll remove "test" from __all__ in my next update. Assuming everything else is okay, I will keep adding to the number of modified modules. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103297&group_id=5470 From noreply@sourceforge.net Sat Jan 20 19:33:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 20 Jan 2001 11:33:41 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: <E14K3ld-0001BH-00@usw-sf-web1.sourceforge.net> Patch #103154 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-20 11:33 By: gvanrossum Comment: Indeed, it's too late for 2.1a1 (now planned for Monday 1/22), but not for 2.1a2. It would be much more productive if you spent your time on adding the termios constants to that module, than lobbying for a hack that I oppose. ------------------------------------------------------- Date: 2001-Jan-20 11:07 By: jlt63 Comment: Skip Montanaro and yourself (at least initially) suggested that this problem should be solved by renaming the modules in question (e.g., TERMIOS) so that they are unique regardless of case. As a following up, you suggested that "An even better solution is to get rid of those generated headers and incorporate the desired symbols directly in the C extension modules." If neither of the two solutions will make it into 2.1a, then I will lobby for the acceptance of my (albeit hacky) patch. It will only affect Cygwin Python and makes it behave identical to other UNIX versions. When a better solution is finally implemented, then the Cygwin cruft can be ripped out. ------------------------------------------------------- Date: 2001-Jan-20 08:47 By: gvanrossum Comment: Reopened at request. But I won't *do* anything about this until I've heard the arguments one more time. ------------------------------------------------------- Date: 2001-Jan-19 22:59 By: jlt63 Comment: Please reopen so that this issue is not accidentally overlooked. At least, until the case sensitive import problem is resolved. I still have a pending patch submitted for consideration. Sorry, to be a pest... ------------------------------------------------------- Date: 2001-Jan-12 11:48 By: tim_one Comment: Ah, I see. There's a difference between Windows filesystems and filesystems used on Windows <wink/sigh>. Older Novell network fileservers for Windows do indeed destroy the case of file names, and newer ones are often configured in a compatability mode to keep on doing that. At my last employer, more than half the LAN servers were set up that way. Use of PYTHONCASEOK was universal as a result. We were also screwed in that one of the popular Windows source-control systems *also* destroyed case (I didn't use that, and have forgotten the name): check in OhNo.py, check out OHNO.PY. Brrrrrrrrr. ------------------------------------------------------- Date: 2001-Jan-12 10:52 By: gvanrossum Comment: Maybe things are different now. But I definitely remember that when I introduced this test, Mark Hammond told me that there was a popular networking filesystem that didn't preserve case. This was either for Windows NT or Windows 95, so it's not a Windows 3.1 thing (although it's possible that the fileserver in question was a bad port from DOS or Windows 3.1 of course). ------------------------------------------------------- Date: 2001-Jan-12 10:47 By: jlt63 Comment: I know. I was just confused by the following On 2001-Jan-11 06:47, gvanrossum wrote: > Note that I believe that "import termios, TERMIOS" *should fail* -- not all > filesystems used on Windows are case preserving. ------------------------------------------------------- Date: 2001-Jan-12 10:26 By: tim_one Comment: The filesystems do preserve the case of names. But all platform file *lookup* APIs are case-insensitive. ------------------------------------------------------- Date: 2001-Jan-12 09:50 By: jlt63 Comment: Oops... Use the following procedure to patch: $ cd Python $ # save case.patch to current directory $ patch <case.patch ------------------------------------------------------- Date: 2001-Jan-12 09:44 By: jlt63 Comment: I just uploaded a new patch. It fixes the case sensitive import problem for Cygwin without affecting Win32 (i.e., Win32 functions as before). Now Cygwin's import behavior is identical to other UNIX platforms. I'm not completely happy with the patch and would characterize it as hacky, but it is the best that I can do without fully grokking import.c. I think to do better would require major rework to find_module(). I guess by renaming TERMIOS you mean to change the module names generated by h2py.py. I have no issue with this -- will others? I thought all filesystems on Windows 95/NT 3.51 and later, were case preserving. To what filesystems and Windows versions are you referring? ------------------------------------------------------- Date: 2001-Jan-11 13:59 By: gvanrossum Comment: Upload it as a new patch. But I believe the solution is that the TERMIOS module should be renamed. ------------------------------------------------------- Date: 2001-Jan-11 07:56 By: jlt63 Comment: Actually, this is not a bug in my original version. Cygwin Python is behaving identically to the Win32 one. Unfortunately, as you pointed out Win32 Python definitely does not handle the situation of two modules that only differ by case. Sigh... If one tries to import the second module that would be found in sys.path, then a NameError: Case mismatch ... exception will *always* be generated. I'm not sure that I agree with this behavior but I really a UNIX guy. Since Cygwin Python should support as many UNIX modules as possible, it needs to deal with modules that only differ by case. termios and TERMIOS used by getpass is a perfect example. I have created a (hacky) patch, that solves this problem for both Cygwin and Win32. I can redo it so that it only affects Cygwin and leaves the Win32 functionality alone. I would like to upload it for discussion but I am concerned about overwriting the old version. Should I upload it anyway? ------------------------------------------------------- Date: 2001-Jan-11 06:47 By: gvanrossum Comment: Reopened at request. Note that I believe that "import termios, TERMIOS" *should fail* -- not all filesystems used on Windows are case preserving. I've had this battle with Mark Hammond before. The case check is intended to prevent you from importing a moduleusing the wrong case (e.g. import String). It is *not* intended to let you have two modules that only differ in case. ------------------------------------------------------- Date: 2001-Jan-10 19:48 By: jlt63 Comment: I have already checked that this patch does not break the Windows VC build before I submitted it. However, Tim is welcome to reverify himself. Unfortunately, I have found a bug with this patch that (only) affects Cygwin. Although this patch handles the following: import String it does not handle the following: import termios, TERMIOS I will resubmit a new version shortly, please change the status back to open. ------------------------------------------------------- Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler <jt@dothill.com> * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Sat Jan 20 19:41:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 20 Jan 2001 11:41:11 -0800 Subject: [Patches] [Patch #103329] Update poplib to use re Message-ID: <E14K3st-0001Da-00@usw-sf-web1.sourceforge.net> Patch #103329 has been updated. Project: python Category: library Status: Closed Submitted by: moshez Assigned to : moshez Summary: Update poplib to use re Follow-Ups: Date: 2001-Jan-19 12:00 By: moshez Comment: Checked in as version 1.12, beating the 3pm on Friday rule by 3 minutes. Unfortunately, my POP server doesn't support APOP, so please give it good testing. ------------------------------------------------------- Date: 2001-Jan-19 10:11 By: gvanrossum Comment: Assigned to Moshe. Thanks! Please check in ASAP! ------------------------------------------------------- Date: 2001-Jan-19 08:34 By: akuchling Comment: The patch looks correct after a quick reading. Moshe, go ahead and check it in. (Bonus points if you can actually test it against a POP server.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103329&group_id=5470 From noreply@sourceforge.net Sat Jan 20 19:35:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 20 Jan 2001 11:35:15 -0800 Subject: [Patches] [Patch #103297] __all__ values for a handful of modules Message-ID: <E14K3n9-0005EU-00@usw-sf-web3.sourceforge.net> Patch #103297 has been updated. Project: python Category: library Status: Open Submitted by: montanaro Assigned to : montanaro Summary: __all__ values for a handful of modules Follow-Ups: Date: 2001-Jan-20 11:35 By: gvanrossum Comment: Skip, I think your upload failed. Make sure that you click the "Upload Revised Patch" checkbox as well as specifying a file... (You can also just check this in, it all seems pretty harmless to me.) ------------------------------------------------------- Date: 2001-Jan-20 11:08 By: montanaro Comment: Latest version - this takes me through dis.py, and throws in robotparser.py for good measure. ------------------------------------------------------- Date: 2001-Jan-19 17:49 By: tim_one Comment: I had wondered out loud whether test functions would get included in the context of the __exports__ patch, which was an unbreachable wall: I didn't want to be left with *no* way to execute a module's test function from within a different module. I agree that test functions should not be included in the context of __all__, though -- I can get at them whether or not they're in __all__, and they're not what an "import *" abuser wants to see anyway. ------------------------------------------------------- Date: 2001-Jan-19 14:43 By: gvanrossum Comment: So where's the next update? I would approve of adding this to the alpha1 release. ------------------------------------------------------- Date: 2001-Jan-18 18:32 By: gvanrossum Comment: Nice, Skip! I wonder if the "test" functions should really be included in __all__? Especially StringIO's test isn't generally needed. I'd be happy if I had to import it explicitly using "from StringIO import test" if I really wanted it. Ditto for the HTTP server classes. ------------------------------------------------------- Date: 2001-Jan-18 19:09 By: montanaro Comment: Yeah, I wondered about including "test". I included it only because I thought I remembered someone mentioning that in a previous thread. I'll remove "test" from __all__ in my next update. Assuming everything else is okay, I will keep adding to the number of modified modules. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103297&group_id=5470 From noreply@sourceforge.net Sat Jan 20 19:55:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 20 Jan 2001 11:55:06 -0800 Subject: [Patches] [Patch #103297] __all__ values for a handful of modules Message-ID: <E14K46M-0001Hq-00@usw-sf-web1.sourceforge.net> Patch #103297 has been updated. Project: python Category: library Status: Closed Submitted by: montanaro Assigned to : montanaro Summary: __all__ values for a handful of modules Follow-Ups: Date: 2001-Jan-20 11:55 By: montanaro Comment: files checked in and patch closed. further addition of __all__ seems not to warrant patch submission. will get to them as I have time. ------------------------------------------------------- Date: 2001-Jan-20 11:50 By: montanaro Comment: whoops... (maybe SF should warn about this mistake?) okay, here it is for real. Includes a test___all__.py script and output as well. Please have a look at the test script and see if it seems suitable. In the meantime, I will check these things in and close the patch. ------------------------------------------------------- Date: 2001-Jan-20 11:35 By: gvanrossum Comment: Skip, I think your upload failed. Make sure that you click the "Upload Revised Patch" checkbox as well as specifying a file... (You can also just check this in, it all seems pretty harmless to me.) ------------------------------------------------------- Date: 2001-Jan-20 11:08 By: montanaro Comment: Latest version - this takes me through dis.py, and throws in robotparser.py for good measure. ------------------------------------------------------- Date: 2001-Jan-19 17:49 By: tim_one Comment: I had wondered out loud whether test functions would get included in the context of the __exports__ patch, which was an unbreachable wall: I didn't want to be left with *no* way to execute a module's test function from within a different module. I agree that test functions should not be included in the context of __all__, though -- I can get at them whether or not they're in __all__, and they're not what an "import *" abuser wants to see anyway. ------------------------------------------------------- Date: 2001-Jan-19 14:43 By: gvanrossum Comment: So where's the next update? I would approve of adding this to the alpha1 release. ------------------------------------------------------- Date: 2001-Jan-18 18:32 By: gvanrossum Comment: Nice, Skip! I wonder if the "test" functions should really be included in __all__? Especially StringIO's test isn't generally needed. I'd be happy if I had to import it explicitly using "from StringIO import test" if I really wanted it. Ditto for the HTTP server classes. ------------------------------------------------------- Date: 2001-Jan-18 19:09 By: montanaro Comment: Yeah, I wondered about including "test". I included it only because I thought I remembered someone mentioning that in a previous thread. I'll remove "test" from __all__ in my next update. Assuming everything else is okay, I will keep adding to the number of modified modules. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103297&group_id=5470 From noreply@sourceforge.net Sun Jan 21 13:20:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 05:20:50 -0800 Subject: [Patches] [Patch #103342] Make shutil.copytree more useful under Jython Message-ID: <E14KKQM-0005ou-00@usw-sf-web1.sourceforge.net> Patch #103342 has been updated. Project: python Category: library Status: Open Submitted by: bckfnn Assigned to : nobody Summary: Make shutil.copytree more useful under Jython ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103342&group_id=5470 From noreply@sourceforge.net Sun Jan 21 13:25:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 05:25:17 -0800 Subject: [Patches] [Patch #103343] Allow the important test_pkg to succeed under Jython Message-ID: <E14KKUf-0001Pr-00@usw-sf-web3.sourceforge.net> Patch #103343 has been updated. Project: python Category: library Status: Open Submitted by: bckfnn Assigned to : nobody Summary: Allow the important test_pkg to succeed under Jython ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103343&group_id=5470 From noreply@sourceforge.net Sun Jan 21 13:31:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 05:31:54 -0800 Subject: [Patches] [Patch #103344] Sort dicts from extcall for easier comparison with Jython Message-ID: <E14KKb4-0001RU-00@usw-sf-web3.sourceforge.net> Patch #103344 has been updated. Project: python Category: None Status: Open Submitted by: bckfnn Assigned to : nobody Summary: Sort dicts from extcall for easier comparison with Jython ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103344&group_id=5470 From noreply@sourceforge.net Sun Jan 21 13:39:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 05:39:55 -0800 Subject: [Patches] [Patch #103345] Avoid outdated exec form in test_class.py. Message-ID: <E14KKip-0005uB-00@usw-sf-web1.sourceforge.net> Patch #103345 has been updated. Project: python Category: library Status: Open Submitted by: bckfnn Assigned to : nobody Summary: Avoid outdated exec form in test_class.py. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103345&group_id=5470 From noreply@sourceforge.net Sun Jan 21 16:11:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 08:11:23 -0800 Subject: [Patches] [Patch #103349] Allow pickle.py to be using with Jython unicode strings Message-ID: <E14KN5P-0003Jn-00@usw-sf-web3.sourceforge.net> Patch #103349 has been updated. Project: python Category: library Status: Open Submitted by: bckfnn Assigned to : nobody Summary: Allow pickle.py to be using with Jython unicode strings ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103349&group_id=5470 From noreply@sourceforge.net Sun Jan 21 18:29:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 10:29:03 -0800 Subject: [Patches] [Patch #103344] Sort dicts from extcall for easier comparison with Jython Message-ID: <E14KPEd-0004lh-00@usw-sf-web2.sourceforge.net> Patch #103344 has been updated. Project: python Category: library Status: Open Submitted by: bckfnn Assigned to : tim_one Summary: Sort dicts from extcall for easier comparison with Jython ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103344&group_id=5470 From noreply@sourceforge.net Sun Jan 21 18:54:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 10:54:12 -0800 Subject: [Patches] [Patch #103344] Sort dicts from extcall for easier comparison with Jython Message-ID: <E14KPcy-0004tX-00@usw-sf-web2.sourceforge.net> Patch #103344 has been updated. Project: python Category: library Status: Closed Submitted by: bckfnn Assigned to : tim_one Summary: Sort dicts from extcall for easier comparison with Jython Follow-Ups: Date: 2001-Jan-21 10:54 By: tim_one Comment: Checked in, test_extcall.py rev 1.12, output/test_extcall rev 1.7. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103344&group_id=5470 From noreply@sourceforge.net Sun Jan 21 19:53:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 11:53:21 -0800 Subject: [Patches] [Patch #103343] Allow the important test_pkg to succeed under Jython Message-ID: <E14KQYD-0004SI-00@usw-sf-web3.sourceforge.net> Patch #103343 has been updated. Project: python Category: library Status: Closed Submitted by: bckfnn Assigned to : tim_one Summary: Allow the important test_pkg to succeed under Jython Follow-Ups: Date: 2001-Jan-21 11:53 By: tim_one Comment: Checked in, test_pkg.py rev 1.12, output/test_pkg rev 1.6 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103343&group_id=5470 From noreply@sourceforge.net Sun Jan 21 20:00:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 12:00:40 -0800 Subject: [Patches] [Patch #103342] Make shutil.copytree more useful under Jython Message-ID: <E14KQfI-0004VI-00@usw-sf-web3.sourceforge.net> Patch #103342 has been updated. Project: python Category: library Status: Closed Submitted by: bckfnn Assigned to : tim_one Summary: Make shutil.copytree more useful under Jython Follow-Ups: Date: 2001-Jan-21 12:00 By: tim_one Comment: Checked in, shutil.py rev 1.19. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103342&group_id=5470 From noreply@sourceforge.net Mon Jan 22 03:00:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 19:00:24 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: <E14KXDU-0002cM-00@usw-sf-web1.sourceforge.net> Patch #103154 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-21 19:00 By: jlt63 Comment: My intentions when I asked you to reopen this patch were to determine whether consensus was reached on how to resolve this issue, not to provoke you in any way. If I did, then I apologize. From your previous comments, it was not clear that you opposed this patch. Now that I know, I will desist with this approach. I'm willing to do as you suggest, but I have the following concerns: 1. At least two more modules that will need this conversion too (i.e., FCNTL and SOCKET). Are there more? 2. Unless there is some (enforceable) policy that module names cannot differ only in case, then Cygwin Python will behave differently than other UNIX versions in this regard. Can you allay my concerns before I set out on this endeavor. BTW, when is 2.1a2 scheduled so I know how much time that I have? ------------------------------------------------------- Date: 2001-Jan-20 11:33 By: gvanrossum Comment: Indeed, it's too late for 2.1a1 (now planned for Monday 1/22), but not for 2.1a2. It would be much more productive if you spent your time on adding the termios constants to that module, than lobbying for a hack that I oppose. ------------------------------------------------------- Date: 2001-Jan-20 11:07 By: jlt63 Comment: Skip Montanaro and yourself (at least initially) suggested that this problem should be solved by renaming the modules in question (e.g., TERMIOS) so that they are unique regardless of case. As a following up, you suggested that "An even better solution is to get rid of those generated headers and incorporate the desired symbols directly in the C extension modules." If neither of the two solutions will make it into 2.1a, then I will lobby for the acceptance of my (albeit hacky) patch. It will only affect Cygwin Python and makes it behave identical to other UNIX versions. When a better solution is finally implemented, then the Cygwin cruft can be ripped out. ------------------------------------------------------- Date: 2001-Jan-20 08:47 By: gvanrossum Comment: Reopened at request. But I won't *do* anything about this until I've heard the arguments one more time. ------------------------------------------------------- Date: 2001-Jan-19 22:59 By: jlt63 Comment: Please reopen so that this issue is not accidentally overlooked. At least, until the case sensitive import problem is resolved. I still have a pending patch submitted for consideration. Sorry, to be a pest... ------------------------------------------------------- Date: 2001-Jan-12 11:48 By: tim_one Comment: Ah, I see. There's a difference between Windows filesystems and filesystems used on Windows <wink/sigh>. Older Novell network fileservers for Windows do indeed destroy the case of file names, and newer ones are often configured in a compatability mode to keep on doing that. At my last employer, more than half the LAN servers were set up that way. Use of PYTHONCASEOK was universal as a result. We were also screwed in that one of the popular Windows source-control systems *also* destroyed case (I didn't use that, and have forgotten the name): check in OhNo.py, check out OHNO.PY. Brrrrrrrrr. ------------------------------------------------------- Date: 2001-Jan-12 10:52 By: gvanrossum Comment: Maybe things are different now. But I definitely remember that when I introduced this test, Mark Hammond told me that there was a popular networking filesystem that didn't preserve case. This was either for Windows NT or Windows 95, so it's not a Windows 3.1 thing (although it's possible that the fileserver in question was a bad port from DOS or Windows 3.1 of course). ------------------------------------------------------- Date: 2001-Jan-12 10:47 By: jlt63 Comment: I know. I was just confused by the following On 2001-Jan-11 06:47, gvanrossum wrote: > Note that I believe that "import termios, TERMIOS" *should fail* -- not all > filesystems used on Windows are case preserving. ------------------------------------------------------- Date: 2001-Jan-12 10:26 By: tim_one Comment: The filesystems do preserve the case of names. But all platform file *lookup* APIs are case-insensitive. ------------------------------------------------------- Date: 2001-Jan-12 09:50 By: jlt63 Comment: Oops... Use the following procedure to patch: $ cd Python $ # save case.patch to current directory $ patch <case.patch ------------------------------------------------------- Date: 2001-Jan-12 09:44 By: jlt63 Comment: I just uploaded a new patch. It fixes the case sensitive import problem for Cygwin without affecting Win32 (i.e., Win32 functions as before). Now Cygwin's import behavior is identical to other UNIX platforms. I'm not completely happy with the patch and would characterize it as hacky, but it is the best that I can do without fully grokking import.c. I think to do better would require major rework to find_module(). I guess by renaming TERMIOS you mean to change the module names generated by h2py.py. I have no issue with this -- will others? I thought all filesystems on Windows 95/NT 3.51 and later, were case preserving. To what filesystems and Windows versions are you referring? ------------------------------------------------------- Date: 2001-Jan-11 13:59 By: gvanrossum Comment: Upload it as a new patch. But I believe the solution is that the TERMIOS module should be renamed. ------------------------------------------------------- Date: 2001-Jan-11 07:56 By: jlt63 Comment: Actually, this is not a bug in my original version. Cygwin Python is behaving identically to the Win32 one. Unfortunately, as you pointed out Win32 Python definitely does not handle the situation of two modules that only differ by case. Sigh... If one tries to import the second module that would be found in sys.path, then a NameError: Case mismatch ... exception will *always* be generated. I'm not sure that I agree with this behavior but I really a UNIX guy. Since Cygwin Python should support as many UNIX modules as possible, it needs to deal with modules that only differ by case. termios and TERMIOS used by getpass is a perfect example. I have created a (hacky) patch, that solves this problem for both Cygwin and Win32. I can redo it so that it only affects Cygwin and leaves the Win32 functionality alone. I would like to upload it for discussion but I am concerned about overwriting the old version. Should I upload it anyway? ------------------------------------------------------- Date: 2001-Jan-11 06:47 By: gvanrossum Comment: Reopened at request. Note that I believe that "import termios, TERMIOS" *should fail* -- not all filesystems used on Windows are case preserving. I've had this battle with Mark Hammond before. The case check is intended to prevent you from importing a moduleusing the wrong case (e.g. import String). It is *not* intended to let you have two modules that only differ in case. ------------------------------------------------------- Date: 2001-Jan-10 19:48 By: jlt63 Comment: I have already checked that this patch does not break the Windows VC build before I submitted it. However, Tim is welcome to reverify himself. Unfortunately, I have found a bug with this patch that (only) affects Cygwin. Although this patch handles the following: import String it does not handle the following: import termios, TERMIOS I will resubmit a new version shortly, please change the status back to open. ------------------------------------------------------- Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler <jt@dothill.com> * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Mon Jan 22 03:04:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 19:04:37 -0800 Subject: [Patches] [Patch #103185] Some more standard modules cleanup for Cygwin Message-ID: <E14KXHZ-0002dT-00@usw-sf-web1.sourceforge.net> Patch #103185 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Some more standard modules cleanup for Cygwin Follow-Ups: Date: 2001-Jan-21 19:04 By: jlt63 Comment: Please reopen to facilitate the inclusion of this patch into alpha 2. ------------------------------------------------------- Date: 2001-Jan-19 22:38 By: jlt63 Comment: A few more courtesy of the Distutils style Python build. Note that Modules/syslogmodule.c will *not* build cleanly until I submit a minor patch to Cygwin to resolve this issue. To patch, change directory to the top of the CVS tree and use $ patch -p0 <mods.patch ------------------------------------------------------- Date: 2001-Jan-18 16:29 By: gvanrossum Comment: Applied, and closed. ------------------------------------------------------- Date: 2001-Jan-10 21:19 By: jlt63 Comment: Use the following procedure to patch: $ cd Modules $ # save modules.patch to current directory $ patch <modules.patch ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103185&group_id=5470 From noreply@sourceforge.net Mon Jan 22 04:25:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 20:25:01 -0800 Subject: [Patches] [Patch #102588] PEP 229: Use Distutils to build Message-ID: <E14KYXN-00030R-00@usw-sf-web1.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: 2001-Jan-21 20:25 By: jlt63 Comment: While working on the build so that Cygwin Python builds OOTB again, I found the following issues now that Python is using Distutils intrinsically: 1. setup.py needs to improve its ability to select only platform appropriate modules. I believe that this has already been discussed on python-dev. 2. make install is not passing $(prefix) to setup.py so the standard extension modules are always installed in the configured location and cannot be overridden at install time. 3. make install fails during the regen step for platforms that do not have a Lib/platform-foo in CVS. This is due to PYTHONPATH no longer being set correctly. 4. Most of the standard extension modules have different filenames (i.e., missing "module") than they had in 2.0. For example on Linux, the socket module was called _socketmodule.so -- now it is called _socket.so. FYI, I have submitted the following patch: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 which has a Cygwin specific solution for 1 and platform independent solutions for 2 and 3. I just noticed your comment regarding setup.cfg, but maybe my "solution" to 2 will prove useful anyway. ------------------------------------------------------- Date: 2001-Jan-16 14:53 By: akuchling Comment: I've made an updated version of the patch; because it's 55K, SF won't accept it, so I've put it at http://www.mems-exchange.org/software/files/python/pep229.patch. There are only a very few things left to fix at this point: * setup.cfg hard-wires the installation directory because it has no access to a variable holding the installation prefix * installs in subdirectories don't work because setup.cfg is only found in the current directory. I think those are the only two remaining issues before this can be checked in (doubtless causing the sun to explode). ------------------------------------------------------- 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 Jan 22 14:51:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 06:51:48 -0800 Subject: [Patches] [Patch #103345] Avoid outdated exec form in test_class.py. Message-ID: <E14KiJw-000297-00@usw-sf-web3.sourceforge.net> Patch #103345 has been updated. Project: python Category: library Status: Closed Submitted by: bckfnn Assigned to : nobody Summary: Avoid outdated exec form in test_class.py. Follow-Ups: Date: 2001-Jan-22 06:51 By: gvanrossum Comment: Done! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103345&group_id=5470 From noreply@sourceforge.net Mon Jan 22 14:53:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 06:53:38 -0800 Subject: [Patches] [Patch #103349] Allow pickle.py to be using with Jython unicode strings Message-ID: <E14KiLi-0002AL-00@usw-sf-web3.sourceforge.net> Patch #103349 has been updated. Project: python Category: library Status: Closed Submitted by: bckfnn Assigned to : nobody Summary: Allow pickle.py to be using with Jython unicode strings Follow-Ups: Date: 2001-Jan-22 06:53 By: gvanrossum Comment: Done. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103349&group_id=5470 From noreply@sourceforge.net Mon Jan 22 15:27:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 07:27:58 -0800 Subject: [Patches] [Patch #103318] non-recursive makefile Message-ID: <E14Kisw-0002NZ-00@usw-sf-web3.sourceforge.net> Patch #103318 has been updated. Project: python Category: Build Status: Open Submitted by: nascheme Assigned to : nascheme Summary: non-recursive makefile Follow-Ups: Date: 2001-Jan-22 07:27 By: nascheme Comment: Cleaned up Cygwin build. Tested with lastest Cygwin on Win98. Added (some?) header file dependencies. Partially merged Linux .so patch. Signal module is now enabled by configure. Things are looking good. I only have access to Linux, Cygwin, and Solaris. Please test on other platforms. ------------------------------------------------------- Date: 2001-Jan-19 14:44 By: gvanrossum Comment: Let's put this off until after the 2.1a1 release. It should go into 2.1a2 though, and probably should be checked in soon after 2.1a1 is released. ------------------------------------------------------- Date: 2001-Jan-19 10:13 By: nascheme Comment: Fix silly bug ("! test -f" instead of "test ! -f" in configure.in). ------------------------------------------------------- Date: 2001-Jan-18 20:43 By: nascheme Comment: New patch. I think makesetup works as it should. There is one issue with MAKE_LDLIBRARY on cygwin but it should be easy to fix. Object files for threads and dynamic loading show be okay now. I might be missing a few "clean" targets. I removed a bunch of "foo.o: $(srcdir)/foo.c" lines. As far as I can tell they are useless. Any make that supports VPATH should be able to figure out where to get the source. Other makes can look in the same dir as the source file. Surely they are not that broken. Guido, do you know if there was a good reason for these lines? Building with GNU make works great for any situation I can think of. pmake is not smart enough to re-read the makefile if it got updated. I don't know of any way around that. Building in a separate dir works fine. I didn't do buildno because I like to type "make" and see the prompt come back right away. What is buildno for and when should it be incremented? ------------------------------------------------------- Date: 2001-Jan-18 18:56 By: gvanrossum Comment: I'm in a quandary. This is really awesone! But a bit too rough to add to the 2.1a1 release. You don't seem to deal with buildno properly -- what's the problem there? Also, I seem to recall that the "-o file.o" option is not universal amongst C compilers. Could someone who uses a non-GCC compiler (e.g. SunPro, or HP, or AIX) check the portability of this Makefile? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103318&group_id=5470 From noreply@sourceforge.net Mon Jan 22 15:38:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 07:38:24 -0800 Subject: [Patches] [Patch #103185] Some more standard modules cleanup for Cygwin Message-ID: <E14Kj32-0003M9-00@usw-sf-web2.sourceforge.net> Patch #103185 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Some more standard modules cleanup for Cygwin Follow-Ups: Date: 2001-Jan-22 07:38 By: gvanrossum Comment: Done, still in 2.1a1. Note that the socket patch had to be fixed, the SSL struct only exists whn USE_SSL is defined. ------------------------------------------------------- Date: 2001-Jan-21 19:04 By: jlt63 Comment: Please reopen to facilitate the inclusion of this patch into alpha 2. ------------------------------------------------------- Date: 2001-Jan-19 22:38 By: jlt63 Comment: A few more courtesy of the Distutils style Python build. Note that Modules/syslogmodule.c will *not* build cleanly until I submit a minor patch to Cygwin to resolve this issue. To patch, change directory to the top of the CVS tree and use $ patch -p0 <mods.patch ------------------------------------------------------- Date: 2001-Jan-18 16:29 By: gvanrossum Comment: Applied, and closed. ------------------------------------------------------- Date: 2001-Jan-10 21:19 By: jlt63 Comment: Use the following procedure to patch: $ cd Modules $ # save modules.patch to current directory $ patch <modules.patch ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103185&group_id=5470 From noreply@sourceforge.net Mon Jan 22 15:40:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 07:40:38 -0800 Subject: [Patches] [Patch #103185] Some more standard modules cleanup for Cygwin Message-ID: <E14Kj5C-0003NG-00@usw-sf-web2.sourceforge.net> Patch #103185 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Some more standard modules cleanup for Cygwin Follow-Ups: Date: 2001-Jan-22 07:40 By: gvanrossum Comment: PS please submit new patches as a new patch entry, reopening closed patches is not the right procedure (and is likely to be lost, as nobody scans old patches for new comments, and the mail notifications are prone to being drupped during times of heavy email :-). ------------------------------------------------------- Date: 2001-Jan-22 07:38 By: gvanrossum Comment: Done, still in 2.1a1. Note that the socket patch had to be fixed, the SSL struct only exists whn USE_SSL is defined. ------------------------------------------------------- Date: 2001-Jan-21 19:04 By: jlt63 Comment: Please reopen to facilitate the inclusion of this patch into alpha 2. ------------------------------------------------------- Date: 2001-Jan-19 22:38 By: jlt63 Comment: A few more courtesy of the Distutils style Python build. Note that Modules/syslogmodule.c will *not* build cleanly until I submit a minor patch to Cygwin to resolve this issue. To patch, change directory to the top of the CVS tree and use $ patch -p0 <mods.patch ------------------------------------------------------- Date: 2001-Jan-18 16:29 By: gvanrossum Comment: Applied, and closed. ------------------------------------------------------- Date: 2001-Jan-10 21:19 By: jlt63 Comment: Use the following procedure to patch: $ cd Modules $ # save modules.patch to current directory $ patch <modules.patch ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103185&group_id=5470 From noreply@sourceforge.net Mon Jan 22 16:11:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 08:11:44 -0800 Subject: [Patches] [Patch #103185] Some more standard modules cleanup for Cygwin Message-ID: <E14KjZI-0002en-00@usw-sf-web3.sourceforge.net> Patch #103185 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Some more standard modules cleanup for Cygwin Follow-Ups: Date: 2001-Jan-22 08:11 By: jlt63 Comment: > Done, still in 2.1a1. Thanks. > Note that the socket patch had to be fixed, ... Oops, thanks for cleaning up after me. > PS please submit new patches as a new patch entry, ... Will do. ------------------------------------------------------- Date: 2001-Jan-22 07:40 By: gvanrossum Comment: PS please submit new patches as a new patch entry, reopening closed patches is not the right procedure (and is likely to be lost, as nobody scans old patches for new comments, and the mail notifications are prone to being drupped during times of heavy email :-). ------------------------------------------------------- Date: 2001-Jan-22 07:38 By: gvanrossum Comment: Done, still in 2.1a1. Note that the socket patch had to be fixed, the SSL struct only exists whn USE_SSL is defined. ------------------------------------------------------- Date: 2001-Jan-21 19:04 By: jlt63 Comment: Please reopen to facilitate the inclusion of this patch into alpha 2. ------------------------------------------------------- Date: 2001-Jan-19 22:38 By: jlt63 Comment: A few more courtesy of the Distutils style Python build. Note that Modules/syslogmodule.c will *not* build cleanly until I submit a minor patch to Cygwin to resolve this issue. To patch, change directory to the top of the CVS tree and use $ patch -p0 <mods.patch ------------------------------------------------------- Date: 2001-Jan-18 16:29 By: gvanrossum Comment: Applied, and closed. ------------------------------------------------------- Date: 2001-Jan-10 21:19 By: jlt63 Comment: Use the following procedure to patch: $ cd Modules $ # save modules.patch to current directory $ patch <modules.patch ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103185&group_id=5470 From noreply@sourceforge.net Mon Jan 22 22:01:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 14:01:03 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14Kp1L-0004xf-00@usw-sf-web3.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : nascheme Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-22 14:01 By: fdrake Comment: Removed the .clear() method from reference objects. Made proxy objects unhashable -- the semantics of hashing something that can mutate in fundamental ways is pretty painful; just don't use these as dictionary keys! Added strong warnings to the documentation that proxy semantics may change a bit before the final release that the weak dictionaries are unclear -- additional feedback is requested. These are not thread-safe. ------------------------------------------------------- Date: 2001-Jan-20 09:42 By: gvanrossum Comment: I think callbacks are needed to implement various forms of weak dicts: when the object is deleted, whatever's in the weak dict for it should be deleted as well. Even though we may not provide weak dicts in 2.1a1, we should still support writing them using what we *do* provide. IMHO (I still haven't had the time to read the PEP or Fred's code. :-( ) ------------------------------------------------------- Date: 2001-Jan-20 09:12 By: nascheme Comment: Why do weak references need callbacks? I see nothing in the PEP to justify this feature. If there is no good reason for them, I propose that the feature be removed for 2.1. Allowing callbacks may make it harder to implement weak references more efficiently later. ------------------------------------------------------- Date: 2001-Jan-18 16:03 By: loewis Comment: The patch looks ok in general, pending resolution of the issues on the PEP itself. Some nits: Integration with GC is still fuzzy. If an instance is GC collected and had a weak ref to it and the weak ref had a callback and the callback choses to resurrect the object, semantics is unclear. This is equivalent to the object having an __del__; the GC would normally *not* collect such objects, but put them into gc.garbage. Proposed resolution: it is a fatal error to resurrect an object in a weakref callback. Hashing: it appears that the hash of a weakref can change when the underlying object goes away. If the weakref is used as key in a dictionary, it appears to be impossible to get the key out of the dictionary after the underlying object is gone. Proposed resolution: a proxy weak ref should cache the hash of the underlying object after its hash function was called for the first time. Comparing: why is the return value of tp_compare -1 when try_3way_compare expects -2 on error? Shouldn't there be some exception set when the underlying object goes away? ------------------------------------------------------- Date: 2001-Jan-17 13:53 By: fdrake Comment: Ok, I tihnk this is it! http://starship.python.net/crew/fdrake/patches/weakref.patch-5 This patch fixes the compilation problems from the previoous patch related to the introduction of rich comparisons, and makes a change in the way new objects are initialized by PyObject_New() and PyObject_NEW() (and all their friends!) -- those functions now know to initialize the weak reference list to NULL for objects which support weak references. Without this change, more places in the code (especially extension modules) need to know more about initialization of weakly-referencable objects. For instance, the "cPickle" and "new" modules both can create instances without calling the code in classobject.c (using PyObject_New()), causing core dumps when such instances are deallocated if the weak-reference list for instances was not properly initialized. Since these modules (properly) tried to avoid call PyInstance_New(), core dumps ensued and the world fell apart. By moving the initialization of the weak reference list into the core object allocators, this problem is averted and extension code to construct new weakly referencable types is simplified. The documentation still needs work, and there are a few new entries for the Python/C API manual as well. A new constructor for instances, PyInstance_NewRaw(), will be added in a separate patch. ------------------------------------------------------- Date: 2001-Jan-17 11:58 By: nascheme Comment: The magic test is: ./python Lib/test/regrtest.py test_weakref test_new Try adding this patch: --- Modules/newmodule.c 2000/11/13 20:29:20 2.29 +++ Modules/newmodule.c 2001/01/17 19:55:46 @@ -24,6 +24,7 @@ Py_INCREF(dict); inst->in_class = (PyClassObject *)klass; inst->in_dict = dict; + inst->in_weakreflist = NULL; PyObject_GC_Init(inst); return (PyObject *)inst; } ------------------------------------------------------- Date: 2001-Jan-17 08:04 By: fdrake Comment: New version of the patch that's still broken but doesn't conflict with the rich comparisons changes: http://starship.python.net/crew/fdrake/patches/weakref.patch-4 ------------------------------------------------------- Date: 2001-Jan-16 21:35 By: fdrake Comment: Added a new (but broken!) version of the patch that fixes WeakDictionary.get() but doesn't interact properly with GC (appearantly) -- not usable as is: http://starship.python.net/crew/fdrake/patches/weakref.patch-3 Neil made the mistake of volunteering to look at the current problem, so assigning to him. (Thanks!) ------------------------------------------------------- Date: 2001-Jan-16 19:39 By: tim_one Comment: Just mentioning a general scenario in which weak keys are the bee's knees: sometimes you want to add attributes to objects dynamically, in ways the original class author(s -- may cut across many classes! even non-instance objects; or objects from extension modules that don't support setattr) never anticipated. Like maybe a German translation of the object's docstrings; or a list of JPEG contents referenced by a URLish object; or a table of usage statistics on methods and functions; etc. Then it's natural to use the conceptual attr name as the name of a dict instead, and write attr[object] = whatever instead of object.attr = whatever There's no point keeping the "whatever" around when the object goes away, but a regular dict makes the object and its "whatever" immortal. A dict with weak keys is exactly on-target. ------------------------------------------------------- Date: 2001-Jan-16 19:14 By: fdrake Comment: I'm not entirely sure why one would want weak keys rather than weak values, but I suspect it has to do with expectations of how the dict will be used in applications. I don't think it would be hard to support both flavors of dictionaries using the primitive reference objects. The constructor does not check that all incoming values are weak because that isn't required. It uses self.update() rather than self.data.update() to perform the inclusion, so any mapping that supports .keys() and .__getitem__() is sufficient. Some additional checking could be done to make sure that all added entries can be created before inserting any of them, offering more atomicity. .get() will be fixed in the next version of the patch; thanks! I've added GC support, but don't have it working quite right. I'm trying to isolate the failure now. ------------------------------------------------------- Date: 2001-Jan-12 14:36 By: loewis Comment: The weak dictionary data type needs more clarification in documentation and implementation. In java.util.WeakHashMap, they keys are weak, not the values (i.e. once the key is forgotten, the entry is cleared). In http://www.handshake.de/~dieter/weakdict.html, the values are weak, but it raises KeyErrors for entries that are collected. The initializer of a weak dict does not check the invariant (all values are weak). get() of a weakdict does not support an optional second parameter. weakref and friends need to participate in garbage collection, as the reference to the callback can create a cycle. ------------------------------------------------------- Date: 2001-Jan-12 11:27 By: fdrake Comment: Updated patch to also support proxy semantics using the same invalidation machinery as the basic weak reference type. The additional code is *heavily* borrowed from Neil Schemenauer. ------------------------------------------------------- Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Tue Jan 23 16:15:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 08:15:54 -0800 Subject: [Patches] [Patch #103373] zlib sync-flush fix Message-ID: <E14L66s-0000ZA-00@usw-sf-web1.sourceforge.net> Patch #103373 has been updated. Project: python Category: Modules Status: Open Submitted by: abo Assigned to : nobody Summary: zlib sync-flush fix ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103373&group_id=5470 From noreply@sourceforge.net Tue Jan 23 16:26:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 08:26:37 -0800 Subject: [Patches] [Patch #103373] zlib sync-flush fix Message-ID: <E14L6HF-0005Et-00@usw-sf-web2.sourceforge.net> Patch #103373 has been updated. Project: python Category: Modules Status: Open Submitted by: abo Assigned to : nobody Summary: zlib sync-flush fix Follow-Ups: Date: 2001-Jan-23 08:26 By: nobody Comment: Argh... my line by line fix list got munged. You'll have to apply imaginary comments to delimit each fix. The bug this fixes is 124981 "zlib decompress of sync-flushed data fails" A lot of the patch changes are simply whitespace changes to clean up the formating. The patch can probably be edited to only include the changes to the PyZlib_objdecompress routine to fix the most important bug, but this would leave the code even more inconsistant than it is. Most of the rest of the fixes are to make the other routines cleaner, though they do also fix the minor bugs mentioned. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103373&group_id=5470 From noreply@sourceforge.net Tue Jan 23 23:07:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 15:07:08 -0800 Subject: [Patches] [Patch #103373] zlib sync-flush fix Message-ID: <E14LCWq-0006p4-00@usw-sf-web3.sourceforge.net> Patch #103373 has been updated. Project: python Category: Modules Status: Open Submitted by: abo Assigned to : akuchling Summary: zlib sync-flush fix Follow-Ups: Date: 2001-Jan-23 08:26 By: nobody Comment: Argh... my line by line fix list got munged. You'll have to apply imaginary comments to delimit each fix. The bug this fixes is 124981 "zlib decompress of sync-flushed data fails" A lot of the patch changes are simply whitespace changes to clean up the formating. The patch can probably be edited to only include the changes to the PyZlib_objdecompress routine to fix the most important bug, but this would leave the code even more inconsistant than it is. Most of the rest of the fixes are to make the other routines cleaner, though they do also fix the minor bugs mentioned. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103373&group_id=5470 From noreply@sourceforge.net Wed Jan 24 02:26:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 18:26:45 -0800 Subject: [Patches] [Patch #103052] Restore non-cyclic operation of pulldom.PullDOM Message-ID: <E14LFe1-0004aK-00@usw-sf-web1.sourceforge.net> Patch #103052 has been updated. Project: python Category: XML Status: Accepted Submitted by: loewis Assigned to : prescod Summary: Restore non-cyclic operation of pulldom.PullDOM Follow-Ups: Date: 2001-Jan-23 18:26 By: akuchling Comment: The patch appears correct as far as I can tell. Note that I'm not that familiar with pulldom; marking as accepted and also assigning to Paul Prescod, in case he can find time to look at it before Martin checks it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103052&group_id=5470 From noreply@sourceforge.net Wed Jan 24 02:55:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 18:55:02 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: <E14LG5O-0001IP-00@usw-sf-web2.sourceforge.net> Patch #102409 has been updated. Project: python Category: Build Status: Open Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-23 18:55 By: akuchling Comment: Looking at the Makefile.in part of this patch, why is the --install-platlib argument needed. The setup.cfg file should be handling this... or does it do the wrong thing somehow? ------------------------------------------------------- Date: 2001-Jan-19 22:31 By: jlt63 Comment: This patch enables Cygwin Python to build using the new Distutils style Python build. Please note that the build_ext.py part is from Jorge Sousa <jsousa@cfn.ist.utl.pt>. To patch, change directory to the top of the CVS tree and use $ patch -p0 <dist.patch The following is the ChangeLog: Sat Jan 20 01:05:18 2001 Jason Tishler <jt@dothill.com> * Makefile.in($(srcdir)/Lib/$(PLATDIR)): Add Distutils build library directory to PYTHONPATH so regen works again. (sharedinstall): Add --install-platlib option so shared extensions follow $(exec_prefix). * setup.py: Add checks for Cygwin so unsupported modules (i.e., dbm and resource) are not built. * Lib/distutils/command/build_ext.py(build_ext.finalize_options): Add Cygwin specific code to append Python's library directory to the extension's list of library directories. (build_ext.get_libraries): Add Cygwin specific code to append Python's (import) library to the extension's list of libraries. ------------------------------------------------------- Date: 2001-Jan-19 08:19 By: gvanrossum Comment: Reopened at request. Don't sweat the release date -- t's only the first alpha release. I have a feeling it'll be put off till Monday. ------------------------------------------------------- Date: 2001-Jan-18 20:52 By: jlt63 Comment: Please reopen because I need to redo the Cygwin build to handle the use of distutils to build the standard extension modules instead of Modules/Makefile.pre.in. How much time (if any) do I have to resolve these issues before 2.1a is released. I heard that the release date is tomorrow. Sigh... ------------------------------------------------------- Date: 2001-Jan-10 19:39 By: jlt63 Comment: Your welcome -- thanks for considering and accepting this patch. If the patch proves to reek havoc on other platforms (most likely only on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out. ------------------------------------------------------- Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 <Cygwin-1.1.5-Python-2.0.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Wed Jan 24 03:05:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 19:05:40 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: <E14LGFg-0004ql-00@usw-sf-web1.sourceforge.net> Patch #102409 has been updated. Project: python Category: Build Status: Open Submitted by: jlt63 Assigned to : akuchling Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-23 18:55 By: akuchling Comment: Looking at the Makefile.in part of this patch, why is the --install-platlib argument needed. The setup.cfg file should be handling this... or does it do the wrong thing somehow? ------------------------------------------------------- Date: 2001-Jan-19 22:31 By: jlt63 Comment: This patch enables Cygwin Python to build using the new Distutils style Python build. Please note that the build_ext.py part is from Jorge Sousa <jsousa@cfn.ist.utl.pt>. To patch, change directory to the top of the CVS tree and use $ patch -p0 <dist.patch The following is the ChangeLog: Sat Jan 20 01:05:18 2001 Jason Tishler <jt@dothill.com> * Makefile.in($(srcdir)/Lib/$(PLATDIR)): Add Distutils build library directory to PYTHONPATH so regen works again. (sharedinstall): Add --install-platlib option so shared extensions follow $(exec_prefix). * setup.py: Add checks for Cygwin so unsupported modules (i.e., dbm and resource) are not built. * Lib/distutils/command/build_ext.py(build_ext.finalize_options): Add Cygwin specific code to append Python's library directory to the extension's list of library directories. (build_ext.get_libraries): Add Cygwin specific code to append Python's (import) library to the extension's list of libraries. ------------------------------------------------------- Date: 2001-Jan-19 08:19 By: gvanrossum Comment: Reopened at request. Don't sweat the release date -- t's only the first alpha release. I have a feeling it'll be put off till Monday. ------------------------------------------------------- Date: 2001-Jan-18 20:52 By: jlt63 Comment: Please reopen because I need to redo the Cygwin build to handle the use of distutils to build the standard extension modules instead of Modules/Makefile.pre.in. How much time (if any) do I have to resolve these issues before 2.1a is released. I heard that the release date is tomorrow. Sigh... ------------------------------------------------------- Date: 2001-Jan-10 19:39 By: jlt63 Comment: Your welcome -- thanks for considering and accepting this patch. If the patch proves to reek havoc on other platforms (most likely only on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out. ------------------------------------------------------- Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 <Cygwin-1.1.5-Python-2.0.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Wed Jan 24 03:31:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 19:31:45 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: <E14LGev-0001Wy-00@usw-sf-web2.sourceforge.net> Patch #102409 has been updated. Project: python Category: Build Status: Open Submitted by: jlt63 Assigned to : akuchling Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-23 19:31 By: akuchling Comment: Checked in the setup.py portion of this patch, modified to factor out the getting of a platform value into a get_platform() method. ------------------------------------------------------- Date: 2001-Jan-23 18:55 By: akuchling Comment: Looking at the Makefile.in part of this patch, why is the --install-platlib argument needed. The setup.cfg file should be handling this... or does it do the wrong thing somehow? ------------------------------------------------------- Date: 2001-Jan-19 22:31 By: jlt63 Comment: This patch enables Cygwin Python to build using the new Distutils style Python build. Please note that the build_ext.py part is from Jorge Sousa <jsousa@cfn.ist.utl.pt>. To patch, change directory to the top of the CVS tree and use $ patch -p0 <dist.patch The following is the ChangeLog: Sat Jan 20 01:05:18 2001 Jason Tishler <jt@dothill.com> * Makefile.in($(srcdir)/Lib/$(PLATDIR)): Add Distutils build library directory to PYTHONPATH so regen works again. (sharedinstall): Add --install-platlib option so shared extensions follow $(exec_prefix). * setup.py: Add checks for Cygwin so unsupported modules (i.e., dbm and resource) are not built. * Lib/distutils/command/build_ext.py(build_ext.finalize_options): Add Cygwin specific code to append Python's library directory to the extension's list of library directories. (build_ext.get_libraries): Add Cygwin specific code to append Python's (import) library to the extension's list of libraries. ------------------------------------------------------- Date: 2001-Jan-19 08:19 By: gvanrossum Comment: Reopened at request. Don't sweat the release date -- t's only the first alpha release. I have a feeling it'll be put off till Monday. ------------------------------------------------------- Date: 2001-Jan-18 20:52 By: jlt63 Comment: Please reopen because I need to redo the Cygwin build to handle the use of distutils to build the standard extension modules instead of Modules/Makefile.pre.in. How much time (if any) do I have to resolve these issues before 2.1a is released. I heard that the release date is tomorrow. Sigh... ------------------------------------------------------- Date: 2001-Jan-10 19:39 By: jlt63 Comment: Your welcome -- thanks for considering and accepting this patch. If the patch proves to reek havoc on other platforms (most likely only on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out. ------------------------------------------------------- Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 <Cygwin-1.1.5-Python-2.0.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Wed Jan 24 04:00:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 20:00:06 -0800 Subject: [Patches] [Patch #103391] Add support for lists in urlencode Message-ID: <E14LH6M-0005D5-00@usw-sf-web1.sourceforge.net> Patch #103391 has been updated. Project: python Category: library Status: Open Submitted by: bquinlan Assigned to : nobody Summary: Add support for lists in urlencode ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103391&group_id=5470 From noreply@sourceforge.net Wed Jan 24 04:01:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 20:01:20 -0800 Subject: [Patches] [Patch #103392] Add support for lists in urlencode Message-ID: <E14LH7Y-0005De-00@usw-sf-web1.sourceforge.net> Patch #103392 has been updated. Project: python Category: library Status: Open Submitted by: bquinlan Assigned to : nobody Summary: Add support for lists in urlencode ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103392&group_id=5470 From noreply@sourceforge.net Wed Jan 24 04:28:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 20:28:57 -0800 Subject: [Patches] [Patch #103314] allow urllib.urlencode to work with multivalued parameters Message-ID: <E14LHYH-0005Lx-00@usw-sf-web1.sourceforge.net> Patch #103314 has been updated. Project: python Category: library Status: Closed Submitted by: montanaro Assigned to : montanaro Summary: allow urllib.urlencode to work with multivalued parameters Follow-Ups: Date: 2001-Jan-23 20:28 By: fdrake Comment: The docs look ok to me; please check in. ------------------------------------------------------- Date: 2001-Jan-19 14:54 By: gvanrossum Comment: Skip, please check the code in, leave the docs until Fred approves. ------------------------------------------------------- Date: 2001-Jan-18 10:09 By: gvanrossum Comment: Comment: I would test for doseq once, and then have two loops: one with the old behavior and one with the new. Also, you might want to catch Unicode and explicitly force it into ASCII (rather than committing to a conversion without knowing what's the right thing). ------------------------------------------------------- Date: 2001-Jan-18 09:42 By: montanaro Comment: Assigned to Fred for starters because it does have a doc change. Fred, Guido probably wants to look at it next, but you're a better judge of who might have more free time... S ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103314&group_id=5470 From noreply@sourceforge.net Wed Jan 24 06:34:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 22:34:35 -0800 Subject: [Patches] [Patch #103391] Add support for lists in urlencode Message-ID: <E14LJVr-000104-00@usw-sf-web3.sourceforge.net> Patch #103391 has been updated. Project: python Category: library Status: Open Submitted by: bquinlan Assigned to : nobody Summary: Add support for lists in urlencode Follow-Ups: Date: 2001-Jan-23 22:34 By: montanaro Comment: Seems like a reasonable extension to me. needs a Doc/lib/liburllib.tex update though. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103391&group_id=5470 From noreply@sourceforge.net Wed Jan 24 06:35:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 22:35:20 -0800 Subject: [Patches] [Patch #103394] check for libtermcap as well as libreadline Message-ID: <E14LJWa-00010E-00@usw-sf-web3.sourceforge.net> Patch #103394 has been updated. Project: python Category: Build Status: Open Submitted by: sdm7g Assigned to : nobody Summary: check for libtermcap as well as libreadline ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103394&group_id=5470 From noreply@sourceforge.net Wed Jan 24 06:53:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 22:53:37 -0800 Subject: [Patches] [Patch #103395] Guido changed his mind! Quickly, add 'if key in dict'! Message-ID: <E14LJoH-0002Yo-00@usw-sf-web2.sourceforge.net> Patch #103395 has been updated. Project: python Category: core (C code) Status: Open Submitted by: twouters Assigned to : nobody Summary: Guido changed his mind! Quickly, add 'if key in dict'! ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103395&group_id=5470 From noreply@sourceforge.net Wed Jan 24 06:57:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 22:57:23 -0800 Subject: [Patches] [Patch #103395] Guido changed his mind! Quickly, add 'if key in dict'! Message-ID: <E14LJrv-0002Zk-00@usw-sf-web2.sourceforge.net> Patch #103395 has been updated. Project: python Category: core (C code) Status: Open Submitted by: twouters Assigned to : gvanrossum Summary: Guido changed his mind! Quickly, add 'if key in dict'! Follow-Ups: Date: 2001-Jan-23 22:57 By: twouters Comment: There yah go, Guido. Does my being awakened by my loud and malicious partner (who needs to head to her office 4 hours before me) earn me yet another free and legally useless 2.1 alpha ? :-) Note: it's missing docs. Will add then once I figure out where to add them. Also haven't updated the std-lib yet, will do that next. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103395&group_id=5470 From noreply@sourceforge.net Wed Jan 24 07:20:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 23:20:48 -0800 Subject: [Patches] [Patch #103395] Guido changed his mind! Quickly, add 'if key in dict'! Message-ID: <E14LKEa-0002hL-00@usw-sf-web2.sourceforge.net> Patch #103395 has been updated. Project: python Category: core (C code) Status: Open Submitted by: twouters Assigned to : gvanrossum Summary: Guido changed his mind! Quickly, add 'if key in dict'! Follow-Ups: Date: 2001-Jan-23 23:20 By: twouters Comment: Add some docs (not guarded by a 'new in 2.1' statement, I don't know how to do that), NEWS item and support in UserDict.UserDict. Docs of has_key should probably also mention that 'if key in dict' does the same, but I'm not sure how to say that's new in Python 2.1. ------------------------------------------------------- Date: 2001-Jan-23 22:57 By: twouters Comment: There yah go, Guido. Does my being awakened by my loud and malicious partner (who needs to head to her office 4 hours before me) earn me yet another free and legally useless 2.1 alpha ? :-) Note: it's missing docs. Will add then once I figure out where to add them. Also haven't updated the std-lib yet, will do that next. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103395&group_id=5470 From noreply@sourceforge.net Wed Jan 24 07:39:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 23:39:04 -0800 Subject: [Patches] [Patch #103395] Guido changed his mind! Quickly, add 'if key in dict'! Message-ID: <E14LKWG-0001Jo-00@usw-sf-web3.sourceforge.net> Patch #103395 has been updated. Project: python Category: core (C code) Status: Open Submitted by: twouters Assigned to : gvanrossum Summary: Guido changed his mind! Quickly, add 'if key in dict'! Follow-Ups: Date: 2001-Jan-23 23:39 By: twouters Comment: Added testcases for dict and UserDict. ------------------------------------------------------- Date: 2001-Jan-23 23:20 By: twouters Comment: Add some docs (not guarded by a 'new in 2.1' statement, I don't know how to do that), NEWS item and support in UserDict.UserDict. Docs of has_key should probably also mention that 'if key in dict' does the same, but I'm not sure how to say that's new in Python 2.1. ------------------------------------------------------- Date: 2001-Jan-23 22:57 By: twouters Comment: There yah go, Guido. Does my being awakened by my loud and malicious partner (who needs to head to her office 4 hours before me) earn me yet another free and legally useless 2.1 alpha ? :-) Note: it's missing docs. Will add then once I figure out where to add them. Also haven't updated the std-lib yet, will do that next. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103395&group_id=5470 From noreply@sourceforge.net Wed Jan 24 09:05:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 01:05:31 -0800 Subject: [Patches] [Patch #103395] Guido changed his mind! Quickly, add 'if key in dict'! Message-ID: <E14LLrv-0003Ht-00@usw-sf-web2.sourceforge.net> Patch #103395 has been updated. Project: python Category: core (C code) Status: Open Submitted by: twouters Assigned to : gvanrossum Summary: Guido changed his mind! Quickly, add 'if key in dict'! Follow-Ups: Date: 2001-Jan-24 01:05 By: tim_one Comment: There must be something in the air, besides email delays. I'll take your word for it that Guido changed his mind, but I was about to say +1 anyway! Now all we have to do is trick xreadlines into iterating over dicts <wink>. ------------------------------------------------------- Date: 2001-Jan-23 23:39 By: twouters Comment: Added testcases for dict and UserDict. ------------------------------------------------------- Date: 2001-Jan-23 23:20 By: twouters Comment: Add some docs (not guarded by a 'new in 2.1' statement, I don't know how to do that), NEWS item and support in UserDict.UserDict. Docs of has_key should probably also mention that 'if key in dict' does the same, but I'm not sure how to say that's new in Python 2.1. ------------------------------------------------------- Date: 2001-Jan-23 22:57 By: twouters Comment: There yah go, Guido. Does my being awakened by my loud and malicious partner (who needs to head to her office 4 hours before me) earn me yet another free and legally useless 2.1 alpha ? :-) Note: it's missing docs. Will add then once I figure out where to add them. Also haven't updated the std-lib yet, will do that next. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103395&group_id=5470 From noreply@sourceforge.net Wed Jan 24 14:46:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 06:46:36 -0800 Subject: [Patches] [Patch #103318] non-recursive makefile Message-ID: <E14LRC0-0003rx-00@usw-sf-web3.sourceforge.net> Patch #103318 has been updated. Project: python Category: Build Status: Open Submitted by: nascheme Assigned to : gvanrossum Summary: non-recursive makefile Follow-Ups: Date: 2001-Jan-24 06:46 By: nascheme Comment: Should I check this in now? ------------------------------------------------------- Date: 2001-Jan-22 07:27 By: nascheme Comment: Cleaned up Cygwin build. Tested with lastest Cygwin on Win98. Added (some?) header file dependencies. Partially merged Linux .so patch. Signal module is now enabled by configure. Things are looking good. I only have access to Linux, Cygwin, and Solaris. Please test on other platforms. ------------------------------------------------------- Date: 2001-Jan-19 14:44 By: gvanrossum Comment: Let's put this off until after the 2.1a1 release. It should go into 2.1a2 though, and probably should be checked in soon after 2.1a1 is released. ------------------------------------------------------- Date: 2001-Jan-19 10:13 By: nascheme Comment: Fix silly bug ("! test -f" instead of "test ! -f" in configure.in). ------------------------------------------------------- Date: 2001-Jan-18 20:43 By: nascheme Comment: New patch. I think makesetup works as it should. There is one issue with MAKE_LDLIBRARY on cygwin but it should be easy to fix. Object files for threads and dynamic loading show be okay now. I might be missing a few "clean" targets. I removed a bunch of "foo.o: $(srcdir)/foo.c" lines. As far as I can tell they are useless. Any make that supports VPATH should be able to figure out where to get the source. Other makes can look in the same dir as the source file. Surely they are not that broken. Guido, do you know if there was a good reason for these lines? Building with GNU make works great for any situation I can think of. pmake is not smart enough to re-read the makefile if it got updated. I don't know of any way around that. Building in a separate dir works fine. I didn't do buildno because I like to type "make" and see the prompt come back right away. What is buildno for and when should it be incremented? ------------------------------------------------------- Date: 2001-Jan-18 18:56 By: gvanrossum Comment: I'm in a quandary. This is really awesone! But a bit too rough to add to the 2.1a1 release. You don't seem to deal with buildno properly -- what's the problem there? Also, I seem to recall that the "-o file.o" option is not universal amongst C compilers. Could someone who uses a non-GCC compiler (e.g. SunPro, or HP, or AIX) check the portability of this Makefile? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103318&group_id=5470 From noreply@sourceforge.net Wed Jan 24 14:58:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 06:58:38 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: <E14LRNe-0005Ug-00@usw-sf-web2.sourceforge.net> Patch #102409 has been updated. Project: python Category: Build Status: Open Submitted by: jlt63 Assigned to : akuchling Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-24 06:58 By: jlt63 Comment: > The setup.cfg file should be handling this... or does it do the wrong thing somehow? As you mentioned in a comment for the PEP 229 patch, setup.cfg is hard-coding the installation directory at configure time to "@prefix@/lib/python@VERSION@/lib-dynload". Which means that "make prefix=/tmp/python/usr/local install" does not work as expected. That is, everything except for the standard modules install in "/tmp/python/usr/local" but the standard modules still end up in "/usr/local/lib/python2.1/lib-dynload". This makes it difficult to create a pre-built distribution. Are you the right person to commit the Lib/distutils/command/build_ext.py part? This is crucial to getting the Cygwin build working again. It appears that the regen hunk of the Makefile.in part is no longer necessary since python seems to be setting sys.path correctly to find the standard modules when running out of the build directory now. BTW, setup.cfg.in is missed a NL at the end of the file. ------------------------------------------------------- Date: 2001-Jan-23 19:31 By: akuchling Comment: Checked in the setup.py portion of this patch, modified to factor out the getting of a platform value into a get_platform() method. ------------------------------------------------------- Date: 2001-Jan-23 18:55 By: akuchling Comment: Looking at the Makefile.in part of this patch, why is the --install-platlib argument needed. The setup.cfg file should be handling this... or does it do the wrong thing somehow? ------------------------------------------------------- Date: 2001-Jan-19 22:31 By: jlt63 Comment: This patch enables Cygwin Python to build using the new Distutils style Python build. Please note that the build_ext.py part is from Jorge Sousa <jsousa@cfn.ist.utl.pt>. To patch, change directory to the top of the CVS tree and use $ patch -p0 <dist.patch The following is the ChangeLog: Sat Jan 20 01:05:18 2001 Jason Tishler <jt@dothill.com> * Makefile.in($(srcdir)/Lib/$(PLATDIR)): Add Distutils build library directory to PYTHONPATH so regen works again. (sharedinstall): Add --install-platlib option so shared extensions follow $(exec_prefix). * setup.py: Add checks for Cygwin so unsupported modules (i.e., dbm and resource) are not built. * Lib/distutils/command/build_ext.py(build_ext.finalize_options): Add Cygwin specific code to append Python's library directory to the extension's list of library directories. (build_ext.get_libraries): Add Cygwin specific code to append Python's (import) library to the extension's list of libraries. ------------------------------------------------------- Date: 2001-Jan-19 08:19 By: gvanrossum Comment: Reopened at request. Don't sweat the release date -- t's only the first alpha release. I have a feeling it'll be put off till Monday. ------------------------------------------------------- Date: 2001-Jan-18 20:52 By: jlt63 Comment: Please reopen because I need to redo the Cygwin build to handle the use of distutils to build the standard extension modules instead of Modules/Makefile.pre.in. How much time (if any) do I have to resolve these issues before 2.1a is released. I heard that the release date is tomorrow. Sigh... ------------------------------------------------------- Date: 2001-Jan-10 19:39 By: jlt63 Comment: Your welcome -- thanks for considering and accepting this patch. If the patch proves to reek havoc on other platforms (most likely only on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out. ------------------------------------------------------- Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 <Cygwin-1.1.5-Python-2.0.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Wed Jan 24 15:26:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 07:26:16 -0800 Subject: [Patches] [Patch #103318] non-recursive makefile Message-ID: <E14LRoO-00047R-00@usw-sf-web3.sourceforge.net> Patch #103318 has been updated. Project: python Category: Build Status: Open Submitted by: nascheme Assigned to : nascheme Summary: non-recursive makefile Follow-Ups: Date: 2001-Jan-24 07:26 By: gvanrossum Comment: Check it in, as long as you have time to deal with the complaints you expect in a timely manner. ;-) ------------------------------------------------------- Date: 2001-Jan-24 06:46 By: nascheme Comment: Should I check this in now? ------------------------------------------------------- Date: 2001-Jan-22 07:27 By: nascheme Comment: Cleaned up Cygwin build. Tested with lastest Cygwin on Win98. Added (some?) header file dependencies. Partially merged Linux .so patch. Signal module is now enabled by configure. Things are looking good. I only have access to Linux, Cygwin, and Solaris. Please test on other platforms. ------------------------------------------------------- Date: 2001-Jan-19 14:44 By: gvanrossum Comment: Let's put this off until after the 2.1a1 release. It should go into 2.1a2 though, and probably should be checked in soon after 2.1a1 is released. ------------------------------------------------------- Date: 2001-Jan-19 10:13 By: nascheme Comment: Fix silly bug ("! test -f" instead of "test ! -f" in configure.in). ------------------------------------------------------- Date: 2001-Jan-18 20:43 By: nascheme Comment: New patch. I think makesetup works as it should. There is one issue with MAKE_LDLIBRARY on cygwin but it should be easy to fix. Object files for threads and dynamic loading show be okay now. I might be missing a few "clean" targets. I removed a bunch of "foo.o: $(srcdir)/foo.c" lines. As far as I can tell they are useless. Any make that supports VPATH should be able to figure out where to get the source. Other makes can look in the same dir as the source file. Surely they are not that broken. Guido, do you know if there was a good reason for these lines? Building with GNU make works great for any situation I can think of. pmake is not smart enough to re-read the makefile if it got updated. I don't know of any way around that. Building in a separate dir works fine. I didn't do buildno because I like to type "make" and see the prompt come back right away. What is buildno for and when should it be incremented? ------------------------------------------------------- Date: 2001-Jan-18 18:56 By: gvanrossum Comment: I'm in a quandary. This is really awesone! But a bit too rough to add to the 2.1a1 release. You don't seem to deal with buildno properly -- what's the problem there? Also, I seem to recall that the "-o file.o" option is not universal amongst C compilers. Could someone who uses a non-GCC compiler (e.g. SunPro, or HP, or AIX) check the portability of this Makefile? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103318&group_id=5470 From noreply@sourceforge.net Wed Jan 24 15:34:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 07:34:36 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: <E14LRwS-0004Aa-00@usw-sf-web3.sourceforge.net> Patch #102409 has been updated. Project: python Category: Build Status: Open Submitted by: jlt63 Assigned to : akuchling Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-24 07:34 By: akuchling Comment: OK. Then the right thing is probably to lose the setup.cfg file completely, and rely on the command-line declaration of install_platlib. This means that just running './python setup.py install' from the command line won't install in the right place, but oh well... And yes, I'm responsible for built_ext at the moment. ------------------------------------------------------- Date: 2001-Jan-24 06:58 By: jlt63 Comment: > The setup.cfg file should be handling this... or does it do the wrong thing somehow? As you mentioned in a comment for the PEP 229 patch, setup.cfg is hard-coding the installation directory at configure time to "@prefix@/lib/python@VERSION@/lib-dynload". Which means that "make prefix=/tmp/python/usr/local install" does not work as expected. That is, everything except for the standard modules install in "/tmp/python/usr/local" but the standard modules still end up in "/usr/local/lib/python2.1/lib-dynload". This makes it difficult to create a pre-built distribution. Are you the right person to commit the Lib/distutils/command/build_ext.py part? This is crucial to getting the Cygwin build working again. It appears that the regen hunk of the Makefile.in part is no longer necessary since python seems to be setting sys.path correctly to find the standard modules when running out of the build directory now. BTW, setup.cfg.in is missed a NL at the end of the file. ------------------------------------------------------- Date: 2001-Jan-23 19:31 By: akuchling Comment: Checked in the setup.py portion of this patch, modified to factor out the getting of a platform value into a get_platform() method. ------------------------------------------------------- Date: 2001-Jan-23 18:55 By: akuchling Comment: Looking at the Makefile.in part of this patch, why is the --install-platlib argument needed. The setup.cfg file should be handling this... or does it do the wrong thing somehow? ------------------------------------------------------- Date: 2001-Jan-19 22:31 By: jlt63 Comment: This patch enables Cygwin Python to build using the new Distutils style Python build. Please note that the build_ext.py part is from Jorge Sousa <jsousa@cfn.ist.utl.pt>. To patch, change directory to the top of the CVS tree and use $ patch -p0 <dist.patch The following is the ChangeLog: Sat Jan 20 01:05:18 2001 Jason Tishler <jt@dothill.com> * Makefile.in($(srcdir)/Lib/$(PLATDIR)): Add Distutils build library directory to PYTHONPATH so regen works again. (sharedinstall): Add --install-platlib option so shared extensions follow $(exec_prefix). * setup.py: Add checks for Cygwin so unsupported modules (i.e., dbm and resource) are not built. * Lib/distutils/command/build_ext.py(build_ext.finalize_options): Add Cygwin specific code to append Python's library directory to the extension's list of library directories. (build_ext.get_libraries): Add Cygwin specific code to append Python's (import) library to the extension's list of libraries. ------------------------------------------------------- Date: 2001-Jan-19 08:19 By: gvanrossum Comment: Reopened at request. Don't sweat the release date -- t's only the first alpha release. I have a feeling it'll be put off till Monday. ------------------------------------------------------- Date: 2001-Jan-18 20:52 By: jlt63 Comment: Please reopen because I need to redo the Cygwin build to handle the use of distutils to build the standard extension modules instead of Modules/Makefile.pre.in. How much time (if any) do I have to resolve these issues before 2.1a is released. I heard that the release date is tomorrow. Sigh... ------------------------------------------------------- Date: 2001-Jan-10 19:39 By: jlt63 Comment: Your welcome -- thanks for considering and accepting this patch. If the patch proves to reek havoc on other platforms (most likely only on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out. ------------------------------------------------------- Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 <Cygwin-1.1.5-Python-2.0.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Wed Jan 24 15:43:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 07:43:24 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: <E14LS4y-0004E0-00@usw-sf-web3.sourceforge.net> Patch #102409 has been updated. Project: python Category: Build Status: Open Submitted by: jlt63 Assigned to : akuchling Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-24 07:43 By: akuchling Comment: Checked in the build_ext.py portion of this patch. ------------------------------------------------------- Date: 2001-Jan-24 07:34 By: akuchling Comment: OK. Then the right thing is probably to lose the setup.cfg file completely, and rely on the command-line declaration of install_platlib. This means that just running './python setup.py install' from the command line won't install in the right place, but oh well... And yes, I'm responsible for built_ext at the moment. ------------------------------------------------------- Date: 2001-Jan-24 06:58 By: jlt63 Comment: > The setup.cfg file should be handling this... or does it do the wrong thing somehow? As you mentioned in a comment for the PEP 229 patch, setup.cfg is hard-coding the installation directory at configure time to "@prefix@/lib/python@VERSION@/lib-dynload". Which means that "make prefix=/tmp/python/usr/local install" does not work as expected. That is, everything except for the standard modules install in "/tmp/python/usr/local" but the standard modules still end up in "/usr/local/lib/python2.1/lib-dynload". This makes it difficult to create a pre-built distribution. Are you the right person to commit the Lib/distutils/command/build_ext.py part? This is crucial to getting the Cygwin build working again. It appears that the regen hunk of the Makefile.in part is no longer necessary since python seems to be setting sys.path correctly to find the standard modules when running out of the build directory now. BTW, setup.cfg.in is missed a NL at the end of the file. ------------------------------------------------------- Date: 2001-Jan-23 19:31 By: akuchling Comment: Checked in the setup.py portion of this patch, modified to factor out the getting of a platform value into a get_platform() method. ------------------------------------------------------- Date: 2001-Jan-23 18:55 By: akuchling Comment: Looking at the Makefile.in part of this patch, why is the --install-platlib argument needed. The setup.cfg file should be handling this... or does it do the wrong thing somehow? ------------------------------------------------------- Date: 2001-Jan-19 22:31 By: jlt63 Comment: This patch enables Cygwin Python to build using the new Distutils style Python build. Please note that the build_ext.py part is from Jorge Sousa <jsousa@cfn.ist.utl.pt>. To patch, change directory to the top of the CVS tree and use $ patch -p0 <dist.patch The following is the ChangeLog: Sat Jan 20 01:05:18 2001 Jason Tishler <jt@dothill.com> * Makefile.in($(srcdir)/Lib/$(PLATDIR)): Add Distutils build library directory to PYTHONPATH so regen works again. (sharedinstall): Add --install-platlib option so shared extensions follow $(exec_prefix). * setup.py: Add checks for Cygwin so unsupported modules (i.e., dbm and resource) are not built. * Lib/distutils/command/build_ext.py(build_ext.finalize_options): Add Cygwin specific code to append Python's library directory to the extension's list of library directories. (build_ext.get_libraries): Add Cygwin specific code to append Python's (import) library to the extension's list of libraries. ------------------------------------------------------- Date: 2001-Jan-19 08:19 By: gvanrossum Comment: Reopened at request. Don't sweat the release date -- t's only the first alpha release. I have a feeling it'll be put off till Monday. ------------------------------------------------------- Date: 2001-Jan-18 20:52 By: jlt63 Comment: Please reopen because I need to redo the Cygwin build to handle the use of distutils to build the standard extension modules instead of Modules/Makefile.pre.in. How much time (if any) do I have to resolve these issues before 2.1a is released. I heard that the release date is tomorrow. Sigh... ------------------------------------------------------- Date: 2001-Jan-10 19:39 By: jlt63 Comment: Your welcome -- thanks for considering and accepting this patch. If the patch proves to reek havoc on other platforms (most likely only on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out. ------------------------------------------------------- Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 <Cygwin-1.1.5-Python-2.0.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Wed Jan 24 17:16:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 09:16:14 -0800 Subject: [Patches] [Patch #103259] Tutorial: Unicode section says UTF-8 is default Message-ID: <E14LTWo-0004na-00@usw-sf-web3.sourceforge.net> Patch #103259 has been updated. Project: python Category: documentation Status: Closed Submitted by: ping Assigned to : fdrake Summary: Tutorial: Unicode section says UTF-8 is default Follow-Ups: Date: 2001-Jan-24 09:16 By: ping Comment: Checked this in. (Guido approved.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103259&group_id=5470 From noreply@sourceforge.net Wed Jan 24 17:20:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 09:20:37 -0800 Subject: [Patches] [Patch #103247] Strings: '\012' -> '\n' Message-ID: <E14LTb3-0004pU-00@usw-sf-web3.sourceforge.net> Patch #103247 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: ping Assigned to : ping Summary: Strings: '\012' -> '\n' Follow-Ups: Date: 2001-Jan-24 09:20 By: ping Comment: Checked in. (Escapes are also now hex instead of octal.) ------------------------------------------------------- Date: 2001-Jan-19 14:58 By: gvanrossum Comment: Ping, please check this in before Monday, so it can go into the alpha1. The docs can come later. ------------------------------------------------------- Date: 2001-Jan-15 21:42 By: ping Comment: Yes, the docs will take some work. I'll resubmit when i've gone through all the documentation. ------------------------------------------------------- Date: 2001-Jan-15 20:21 By: gvanrossum Comment: Nice. Style nit: I don't care for the fputc(), fputc(); form. Can you resubmit (and retest!) a version that uses \x%02x too? I'd expect that this would require updates to some docs and the tutorial, too. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103247&group_id=5470 From noreply@sourceforge.net Wed Jan 24 17:29:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 09:29:34 -0800 Subject: [Patches] [Patch #103318] non-recursive makefile Message-ID: <E14LTji-0001YT-00@usw-sf-web1.sourceforge.net> Patch #103318 has been updated. Project: python Category: Build Status: Closed Submitted by: nascheme Assigned to : nobody Summary: non-recursive makefile Follow-Ups: Date: 2001-Jan-24 09:29 By: nascheme Comment: Updated version applied. The old makefiles are still around for now. ------------------------------------------------------- Date: 2001-Jan-24 07:26 By: gvanrossum Comment: Check it in, as long as you have time to deal with the complaints you expect in a timely manner. ;-) ------------------------------------------------------- Date: 2001-Jan-24 06:46 By: nascheme Comment: Should I check this in now? ------------------------------------------------------- Date: 2001-Jan-22 07:27 By: nascheme Comment: Cleaned up Cygwin build. Tested with lastest Cygwin on Win98. Added (some?) header file dependencies. Partially merged Linux .so patch. Signal module is now enabled by configure. Things are looking good. I only have access to Linux, Cygwin, and Solaris. Please test on other platforms. ------------------------------------------------------- Date: 2001-Jan-19 14:44 By: gvanrossum Comment: Let's put this off until after the 2.1a1 release. It should go into 2.1a2 though, and probably should be checked in soon after 2.1a1 is released. ------------------------------------------------------- Date: 2001-Jan-19 10:13 By: nascheme Comment: Fix silly bug ("! test -f" instead of "test ! -f" in configure.in). ------------------------------------------------------- Date: 2001-Jan-18 20:43 By: nascheme Comment: New patch. I think makesetup works as it should. There is one issue with MAKE_LDLIBRARY on cygwin but it should be easy to fix. Object files for threads and dynamic loading show be okay now. I might be missing a few "clean" targets. I removed a bunch of "foo.o: $(srcdir)/foo.c" lines. As far as I can tell they are useless. Any make that supports VPATH should be able to figure out where to get the source. Other makes can look in the same dir as the source file. Surely they are not that broken. Guido, do you know if there was a good reason for these lines? Building with GNU make works great for any situation I can think of. pmake is not smart enough to re-read the makefile if it got updated. I don't know of any way around that. Building in a separate dir works fine. I didn't do buildno because I like to type "make" and see the prompt come back right away. What is buildno for and when should it be incremented? ------------------------------------------------------- Date: 2001-Jan-18 18:56 By: gvanrossum Comment: I'm in a quandary. This is really awesone! But a bit too rough to add to the 2.1a1 release. You don't seem to deal with buildno properly -- what's the problem there? Also, I seem to recall that the "-o file.o" option is not universal amongst C compilers. Could someone who uses a non-GCC compiler (e.g. SunPro, or HP, or AIX) check the portability of this Makefile? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103318&group_id=5470 From noreply@sourceforge.net Wed Jan 24 19:06:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 11:06:00 -0800 Subject: [Patches] [Patch #101647] adds SSL server socket support to socketmodule.c Message-ID: <E14LVF2-00076Y-00@usw-sf-web2.sourceforge.net> Patch #101647 has been updated. Project: python Category: Modules Status: Rejected Submitted by: drew_csillag Assigned to : gvanrossum Summary: adds SSL server socket support to socketmodule.c Follow-Ups: Date: 2001-Jan-24 11:06 By: drew_csillag Comment: Sorry for the no-reply... Anyhoo, the ssl stuff currently in the socket module only allows ssl on client connections (i.e. where you connect to somebody else) as opposed to server connections (i.e. where somebody connects to you). For example, you have a cheesy SSL socket client: from socket import * s = socket(AF_INET, SOCK_STREAM) s.connect(('',9999)) ss = ssl(s,None,None) ss.write("foo!\n") The patch is required in order to be able to write the corresponding server, as such: from socket import * s = socket(AF_INET, SOCK_STREAM) s.bind(('',9999)) s.listen(5) f,a = s.accept() ss = sslserv(f, "keyfilename", "certfilename") print ss.read(5) If you try to just use the ssl function on both sides and it doesn't work. ------------------------------------------------------- Date: 2000-Sep-25 09:41 By: jhylton Comment: too late for 2.0 ------------------------------------------------------- Date: 2000-Sep-27 03:51 By: naris Comment: too late ? this patch solves world hunger and brings world peace! such a valuable patch, but i guess deadlines are deadlines :-( ------------------------------------------------------- Date: 2000-Oct-25 13:54 By: gvanrossum Comment: Drew, could you provide an example of how this is used? If I can't test it I can't add it. It doesn't have to be a test module (although a test module for all the SSL support is sorely needed) but I would like to see a little motivation for why this is useful. Also note that the SSL support in the socket module is controversial; there are some who believe that a different approach is needed, e.g. based on M2crypto. ------------------------------------------------------- Date: 2000-Nov-13 11:41 By: gvanrossum Comment: Still no reply. I'll reject the patch now, for lack of sufficient motivation. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101647&group_id=5470 From noreply@sourceforge.net Wed Jan 24 19:20:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 11:20:53 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: <E14LVTR-0005b1-00@usw-sf-web3.sourceforge.net> Patch #102409 has been updated. Project: python Category: Build Status: Open Submitted by: jlt63 Assigned to : akuchling Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-24 11:20 By: akuchling Comment: Neil's checkin of the non-recursive affects Makefile.in, the only portion of this patch that isn't checked in. jlt, should I try to port the Makefile.in changes, or do you want to port them and submit a revised patch? ------------------------------------------------------- Date: 2001-Jan-24 07:43 By: akuchling Comment: Checked in the build_ext.py portion of this patch. ------------------------------------------------------- Date: 2001-Jan-24 07:34 By: akuchling Comment: OK. Then the right thing is probably to lose the setup.cfg file completely, and rely on the command-line declaration of install_platlib. This means that just running './python setup.py install' from the command line won't install in the right place, but oh well... And yes, I'm responsible for built_ext at the moment. ------------------------------------------------------- Date: 2001-Jan-24 06:58 By: jlt63 Comment: > The setup.cfg file should be handling this... or does it do the wrong thing somehow? As you mentioned in a comment for the PEP 229 patch, setup.cfg is hard-coding the installation directory at configure time to "@prefix@/lib/python@VERSION@/lib-dynload". Which means that "make prefix=/tmp/python/usr/local install" does not work as expected. That is, everything except for the standard modules install in "/tmp/python/usr/local" but the standard modules still end up in "/usr/local/lib/python2.1/lib-dynload". This makes it difficult to create a pre-built distribution. Are you the right person to commit the Lib/distutils/command/build_ext.py part? This is crucial to getting the Cygwin build working again. It appears that the regen hunk of the Makefile.in part is no longer necessary since python seems to be setting sys.path correctly to find the standard modules when running out of the build directory now. BTW, setup.cfg.in is missed a NL at the end of the file. ------------------------------------------------------- Date: 2001-Jan-23 19:31 By: akuchling Comment: Checked in the setup.py portion of this patch, modified to factor out the getting of a platform value into a get_platform() method. ------------------------------------------------------- Date: 2001-Jan-23 18:55 By: akuchling Comment: Looking at the Makefile.in part of this patch, why is the --install-platlib argument needed. The setup.cfg file should be handling this... or does it do the wrong thing somehow? ------------------------------------------------------- Date: 2001-Jan-19 22:31 By: jlt63 Comment: This patch enables Cygwin Python to build using the new Distutils style Python build. Please note that the build_ext.py part is from Jorge Sousa <jsousa@cfn.ist.utl.pt>. To patch, change directory to the top of the CVS tree and use $ patch -p0 <dist.patch The following is the ChangeLog: Sat Jan 20 01:05:18 2001 Jason Tishler <jt@dothill.com> * Makefile.in($(srcdir)/Lib/$(PLATDIR)): Add Distutils build library directory to PYTHONPATH so regen works again. (sharedinstall): Add --install-platlib option so shared extensions follow $(exec_prefix). * setup.py: Add checks for Cygwin so unsupported modules (i.e., dbm and resource) are not built. * Lib/distutils/command/build_ext.py(build_ext.finalize_options): Add Cygwin specific code to append Python's library directory to the extension's list of library directories. (build_ext.get_libraries): Add Cygwin specific code to append Python's (import) library to the extension's list of libraries. ------------------------------------------------------- Date: 2001-Jan-19 08:19 By: gvanrossum Comment: Reopened at request. Don't sweat the release date -- t's only the first alpha release. I have a feeling it'll be put off till Monday. ------------------------------------------------------- Date: 2001-Jan-18 20:52 By: jlt63 Comment: Please reopen because I need to redo the Cygwin build to handle the use of distutils to build the standard extension modules instead of Modules/Makefile.pre.in. How much time (if any) do I have to resolve these issues before 2.1a is released. I heard that the release date is tomorrow. Sigh... ------------------------------------------------------- Date: 2001-Jan-10 19:39 By: jlt63 Comment: Your welcome -- thanks for considering and accepting this patch. If the patch proves to reek havoc on other platforms (most likely only on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out. ------------------------------------------------------- Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 <Cygwin-1.1.5-Python-2.0.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Wed Jan 24 19:24:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 11:24:33 -0800 Subject: [Patches] [Patch #101647] adds SSL server socket support to socketmodule.c Message-ID: <E14LVWz-0005cl-00@usw-sf-web3.sourceforge.net> Patch #101647 has been updated. Project: python Category: Modules Status: Rejected Submitted by: drew_csillag Assigned to : gvanrossum Summary: adds SSL server socket support to socketmodule.c Follow-Ups: Date: 2001-Jan-24 11:24 By: akuchling Comment: Guido, want me to re-open this patch and take it over? IMHO, if the SSL support is left in, then this patch should be added; no point in having only half-working support. ------------------------------------------------------- Date: 2001-Jan-24 11:06 By: drew_csillag Comment: Sorry for the no-reply... Anyhoo, the ssl stuff currently in the socket module only allows ssl on client connections (i.e. where you connect to somebody else) as opposed to server connections (i.e. where somebody connects to you). For example, you have a cheesy SSL socket client: from socket import * s = socket(AF_INET, SOCK_STREAM) s.connect(('',9999)) ss = ssl(s,None,None) ss.write("foo!\n") The patch is required in order to be able to write the corresponding server, as such: from socket import * s = socket(AF_INET, SOCK_STREAM) s.bind(('',9999)) s.listen(5) f,a = s.accept() ss = sslserv(f, "keyfilename", "certfilename") print ss.read(5) If you try to just use the ssl function on both sides and it doesn't work. ------------------------------------------------------- Date: 2000-Sep-25 09:41 By: jhylton Comment: too late for 2.0 ------------------------------------------------------- Date: 2000-Sep-27 03:51 By: naris Comment: too late ? this patch solves world hunger and brings world peace! such a valuable patch, but i guess deadlines are deadlines :-( ------------------------------------------------------- Date: 2000-Oct-25 13:54 By: gvanrossum Comment: Drew, could you provide an example of how this is used? If I can't test it I can't add it. It doesn't have to be a test module (although a test module for all the SSL support is sorely needed) but I would like to see a little motivation for why this is useful. Also note that the SSL support in the socket module is controversial; there are some who believe that a different approach is needed, e.g. based on M2crypto. ------------------------------------------------------- Date: 2000-Nov-13 11:41 By: gvanrossum Comment: Still no reply. I'll reject the patch now, for lack of sufficient motivation. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101647&group_id=5470 From noreply@sourceforge.net Wed Jan 24 20:05:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 12:05:32 -0800 Subject: [Patches] [Patch #101647] adds SSL server socket support to socketmodule.c Message-ID: <E14LWAe-0002cE-00@usw-sf-web1.sourceforge.net> Patch #101647 has been updated. Project: python Category: Modules Status: Open Submitted by: drew_csillag Assigned to : akuchling Summary: adds SSL server socket support to socketmodule.c Follow-Ups: Date: 2001-Jan-24 12:05 By: gvanrossum Comment: OK, Andrew, it's all yours. (But I disagree with your last point: client-only SSL support is still a lot better than no SSL support! :-) ------------------------------------------------------- Date: 2001-Jan-24 11:24 By: akuchling Comment: Guido, want me to re-open this patch and take it over? IMHO, if the SSL support is left in, then this patch should be added; no point in having only half-working support. ------------------------------------------------------- Date: 2001-Jan-24 11:06 By: drew_csillag Comment: Sorry for the no-reply... Anyhoo, the ssl stuff currently in the socket module only allows ssl on client connections (i.e. where you connect to somebody else) as opposed to server connections (i.e. where somebody connects to you). For example, you have a cheesy SSL socket client: from socket import * s = socket(AF_INET, SOCK_STREAM) s.connect(('',9999)) ss = ssl(s,None,None) ss.write("foo!\n") The patch is required in order to be able to write the corresponding server, as such: from socket import * s = socket(AF_INET, SOCK_STREAM) s.bind(('',9999)) s.listen(5) f,a = s.accept() ss = sslserv(f, "keyfilename", "certfilename") print ss.read(5) If you try to just use the ssl function on both sides and it doesn't work. ------------------------------------------------------- Date: 2000-Sep-25 09:41 By: jhylton Comment: too late for 2.0 ------------------------------------------------------- Date: 2000-Sep-27 03:51 By: naris Comment: too late ? this patch solves world hunger and brings world peace! such a valuable patch, but i guess deadlines are deadlines :-( ------------------------------------------------------- Date: 2000-Oct-25 13:54 By: gvanrossum Comment: Drew, could you provide an example of how this is used? If I can't test it I can't add it. It doesn't have to be a test module (although a test module for all the SSL support is sorely needed) but I would like to see a little motivation for why this is useful. Also note that the SSL support in the socket module is controversial; there are some who believe that a different approach is needed, e.g. based on M2crypto. ------------------------------------------------------- Date: 2000-Nov-13 11:41 By: gvanrossum Comment: Still no reply. I'll reject the patch now, for lack of sufficient motivation. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101647&group_id=5470 From noreply@sourceforge.net Wed Jan 24 22:32:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 14:32:41 -0800 Subject: [Patches] [Patch #103409] install: setup.py 'dbm' header file searching Message-ID: <E14LYT3-0003b6-00@usw-sf-web1.sourceforge.net> Patch #103409 has been updated. Project: python Category: Build Status: Open Submitted by: calvin Assigned to : nobody Summary: install: setup.py 'dbm' header file searching ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103409&group_id=5470 From noreply@sourceforge.net Wed Jan 24 22:46:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 14:46:14 -0800 Subject: [Patches] [Patch #103409] install: setup.py 'dbm' header file searching Message-ID: <E14LYgA-0003hn-00@usw-sf-web1.sourceforge.net> Patch #103409 has been updated. Project: python Category: Build Status: Open Submitted by: calvin Assigned to : nobody Summary: install: setup.py 'dbm' header file searching Follow-Ups: Date: 2001-Jan-24 14:46 By: calvin Comment: Argh, thats not my problem: the configure program does not find the db1/ndbm.h file. Hmm, will look further into this. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103409&group_id=5470 From noreply@sourceforge.net Wed Jan 24 22:53:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 14:53:02 -0800 Subject: [Patches] [Patch #103409] install: setup.py 'dbm' header file searching Message-ID: <E14LYmk-0008TW-00@usw-sf-web2.sourceforge.net> Patch #103409 has been updated. Project: python Category: Build Status: Open Submitted by: calvin Assigned to : nobody Summary: install: setup.py 'dbm' header file searching Follow-Ups: Date: 2001-Jan-24 14:53 By: calvin Comment: Ok, its a Debian bug, never mind. ------------------------------------------------------- Date: 2001-Jan-24 14:46 By: calvin Comment: Argh, thats not my problem: the configure program does not find the db1/ndbm.h file. Hmm, will look further into this. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103409&group_id=5470 From noreply@sourceforge.net Thu Jan 25 00:57:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 16:57:42 -0800 Subject: [Patches] [Patch #102588] PEP 229: Use Distutils to build Message-ID: <E14LajO-0000nA-00@usw-sf-web2.sourceforge.net> Patch #102588 has been updated. Project: python Category: Build Status: Closed Submitted by: akuchling Assigned to : akuchling Summary: PEP 229: Use Distutils to build Follow-Ups: Date: 2001-Jan-24 16:57 By: akuchling Comment: Checked in, so I'm going to close this patch. Further discussion and development will occur in different patches/bug reports. ------------------------------------------------------- Date: 2001-Jan-21 20:25 By: jlt63 Comment: While working on the build so that Cygwin Python builds OOTB again, I found the following issues now that Python is using Distutils intrinsically: 1. setup.py needs to improve its ability to select only platform appropriate modules. I believe that this has already been discussed on python-dev. 2. make install is not passing $(prefix) to setup.py so the standard extension modules are always installed in the configured location and cannot be overridden at install time. 3. make install fails during the regen step for platforms that do not have a Lib/platform-foo in CVS. This is due to PYTHONPATH no longer being set correctly. 4. Most of the standard extension modules have different filenames (i.e., missing "module") than they had in 2.0. For example on Linux, the socket module was called _socketmodule.so -- now it is called _socket.so. FYI, I have submitted the following patch: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 which has a Cygwin specific solution for 1 and platform independent solutions for 2 and 3. I just noticed your comment regarding setup.cfg, but maybe my "solution" to 2 will prove useful anyway. ------------------------------------------------------- Date: 2001-Jan-16 14:53 By: akuchling Comment: I've made an updated version of the patch; because it's 55K, SF won't accept it, so I've put it at http://www.mems-exchange.org/software/files/python/pep229.patch. There are only a very few things left to fix at this point: * setup.cfg hard-wires the installation directory because it has no access to a variable holding the installation prefix * installs in subdirectories don't work because setup.cfg is only found in the current directory. I think those are the only two remaining issues before this can be checked in (doubtless causing the sun to explode). ------------------------------------------------------- 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 Thu Jan 25 01:00:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 17:00:21 -0800 Subject: [Patches] [Patch #103334] Strip "." pathname components Message-ID: <E14Lalx-0000oz-00@usw-sf-web2.sourceforge.net> Patch #103334 has been updated. Project: python Category: distutils Status: Accepted Submitted by: jackjansen Assigned to : akuchling Summary: Strip "." pathname components Follow-Ups: Date: 2001-Jan-24 17:00 By: akuchling Comment: Seems reasonable; please go ahead and check it in. ------------------------------------------------------- Date: 2001-Jan-19 14:41 By: gvanrossum Comment: Looks decent to me. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103334&group_id=5470 From noreply@sourceforge.net Thu Jan 25 01:01:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 17:01:28 -0800 Subject: [Patches] [Patch #103333] install_data does not do pathname conversion Message-ID: <E14Lan2-0000pS-00@usw-sf-web2.sourceforge.net> Patch #103333 has been updated. Project: python Category: distutils Status: Accepted Submitted by: jackjansen Assigned to : akuchling Summary: install_data does not do pathname conversion Follow-Ups: Date: 2001-Jan-24 17:01 By: akuchling Comment: Looks good; please check it in. ------------------------------------------------------- Date: 2001-Jan-19 14:42 By: gvanrossum Comment: For Andrew. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103333&group_id=5470 From noreply@sourceforge.net Thu Jan 25 02:45:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 18:45:38 -0800 Subject: [Patches] [Patch #103412] Complete description of percent formatting in libstdtypes Message-ID: <E14LcPq-0008Ux-00@usw-sf-web3.sourceforge.net> Patch #103412 has been updated. Project: python Category: documentation Status: Open Submitted by: efm Assigned to : nobody Summary: Complete description of percent formatting in libstdtypes ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103412&group_id=5470 From noreply@sourceforge.net Thu Jan 25 03:04:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 19:04:12 -0800 Subject: [Patches] [Patch #101647] adds SSL server socket support to socketmodule.c Message-ID: <E14Lcho-0001VH-00@usw-sf-web2.sourceforge.net> Patch #101647 has been updated. Project: python Category: Modules Status: Open Submitted by: drew_csillag Assigned to : akuchling Summary: adds SSL server socket support to socketmodule.c Follow-Ups: Date: 2001-Jan-24 19:04 By: akuchling Comment: newServerSSLObject() is a near-duplicate of newSSLobject(). Rather than just cut-and-paste the code into a new function, newSSLobject() should take a fourth argument, and perform either the client or server initialization. I've already modified the patch to do this. Before uploading the modified version, I'd like to test it, but can't figure out what it wants for the key and cert arguments. Drew, do you have a test program you used to test the code? Can you please e-mail it to me, or add it as a comment to this patch? ------------------------------------------------------- Date: 2001-Jan-24 12:05 By: gvanrossum Comment: OK, Andrew, it's all yours. (But I disagree with your last point: client-only SSL support is still a lot better than no SSL support! :-) ------------------------------------------------------- Date: 2001-Jan-24 11:24 By: akuchling Comment: Guido, want me to re-open this patch and take it over? IMHO, if the SSL support is left in, then this patch should be added; no point in having only half-working support. ------------------------------------------------------- Date: 2001-Jan-24 11:06 By: drew_csillag Comment: Sorry for the no-reply... Anyhoo, the ssl stuff currently in the socket module only allows ssl on client connections (i.e. where you connect to somebody else) as opposed to server connections (i.e. where somebody connects to you). For example, you have a cheesy SSL socket client: from socket import * s = socket(AF_INET, SOCK_STREAM) s.connect(('',9999)) ss = ssl(s,None,None) ss.write("foo!\n") The patch is required in order to be able to write the corresponding server, as such: from socket import * s = socket(AF_INET, SOCK_STREAM) s.bind(('',9999)) s.listen(5) f,a = s.accept() ss = sslserv(f, "keyfilename", "certfilename") print ss.read(5) If you try to just use the ssl function on both sides and it doesn't work. ------------------------------------------------------- Date: 2000-Sep-25 09:41 By: jhylton Comment: too late for 2.0 ------------------------------------------------------- Date: 2000-Sep-27 03:51 By: naris Comment: too late ? this patch solves world hunger and brings world peace! such a valuable patch, but i guess deadlines are deadlines :-( ------------------------------------------------------- Date: 2000-Oct-25 13:54 By: gvanrossum Comment: Drew, could you provide an example of how this is used? If I can't test it I can't add it. It doesn't have to be a test module (although a test module for all the SSL support is sorely needed) but I would like to see a little motivation for why this is useful. Also note that the SSL support in the socket module is controversial; there are some who believe that a different approach is needed, e.g. based on M2crypto. ------------------------------------------------------- Date: 2000-Nov-13 11:41 By: gvanrossum Comment: Still no reply. I'll reject the patch now, for lack of sufficient motivation. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101647&group_id=5470 From noreply@sourceforge.net Thu Jan 25 05:38:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 21:38:44 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: <E14Lf7M-0000xv-00@usw-sf-web3.sourceforge.net> Patch #102409 has been updated. Project: python Category: Build Status: Open Submitted by: jlt63 Assigned to : akuchling Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-24 21:38 By: jlt63 Comment: There were two sections to my original Makefile.in patch, fixes for: 1. regen 2. make install I indicated that #1 was already fixed in my comment on 2001-Jan-24 05:58: > It appears that the regen hunk of the Makefile.in part is no longer necessary > since python seems to be setting sys.path correctly to find the standard > modules when running out of the build directory now. Hence, that only leave #2. Do you mind doing that part? ------------------------------------------------------- Date: 2001-Jan-24 11:20 By: akuchling Comment: Neil's checkin of the non-recursive affects Makefile.in, the only portion of this patch that isn't checked in. jlt, should I try to port the Makefile.in changes, or do you want to port them and submit a revised patch? ------------------------------------------------------- Date: 2001-Jan-24 07:43 By: akuchling Comment: Checked in the build_ext.py portion of this patch. ------------------------------------------------------- Date: 2001-Jan-24 07:34 By: akuchling Comment: OK. Then the right thing is probably to lose the setup.cfg file completely, and rely on the command-line declaration of install_platlib. This means that just running './python setup.py install' from the command line won't install in the right place, but oh well... And yes, I'm responsible for built_ext at the moment. ------------------------------------------------------- Date: 2001-Jan-24 06:58 By: jlt63 Comment: > The setup.cfg file should be handling this... or does it do the wrong thing somehow? As you mentioned in a comment for the PEP 229 patch, setup.cfg is hard-coding the installation directory at configure time to "@prefix@/lib/python@VERSION@/lib-dynload". Which means that "make prefix=/tmp/python/usr/local install" does not work as expected. That is, everything except for the standard modules install in "/tmp/python/usr/local" but the standard modules still end up in "/usr/local/lib/python2.1/lib-dynload". This makes it difficult to create a pre-built distribution. Are you the right person to commit the Lib/distutils/command/build_ext.py part? This is crucial to getting the Cygwin build working again. It appears that the regen hunk of the Makefile.in part is no longer necessary since python seems to be setting sys.path correctly to find the standard modules when running out of the build directory now. BTW, setup.cfg.in is missed a NL at the end of the file. ------------------------------------------------------- Date: 2001-Jan-23 19:31 By: akuchling Comment: Checked in the setup.py portion of this patch, modified to factor out the getting of a platform value into a get_platform() method. ------------------------------------------------------- Date: 2001-Jan-23 18:55 By: akuchling Comment: Looking at the Makefile.in part of this patch, why is the --install-platlib argument needed. The setup.cfg file should be handling this... or does it do the wrong thing somehow? ------------------------------------------------------- Date: 2001-Jan-19 22:31 By: jlt63 Comment: This patch enables Cygwin Python to build using the new Distutils style Python build. Please note that the build_ext.py part is from Jorge Sousa <jsousa@cfn.ist.utl.pt>. To patch, change directory to the top of the CVS tree and use $ patch -p0 <dist.patch The following is the ChangeLog: Sat Jan 20 01:05:18 2001 Jason Tishler <jt@dothill.com> * Makefile.in($(srcdir)/Lib/$(PLATDIR)): Add Distutils build library directory to PYTHONPATH so regen works again. (sharedinstall): Add --install-platlib option so shared extensions follow $(exec_prefix). * setup.py: Add checks for Cygwin so unsupported modules (i.e., dbm and resource) are not built. * Lib/distutils/command/build_ext.py(build_ext.finalize_options): Add Cygwin specific code to append Python's library directory to the extension's list of library directories. (build_ext.get_libraries): Add Cygwin specific code to append Python's (import) library to the extension's list of libraries. ------------------------------------------------------- Date: 2001-Jan-19 08:19 By: gvanrossum Comment: Reopened at request. Don't sweat the release date -- t's only the first alpha release. I have a feeling it'll be put off till Monday. ------------------------------------------------------- Date: 2001-Jan-18 20:52 By: jlt63 Comment: Please reopen because I need to redo the Cygwin build to handle the use of distutils to build the standard extension modules instead of Modules/Makefile.pre.in. How much time (if any) do I have to resolve these issues before 2.1a is released. I heard that the release date is tomorrow. Sigh... ------------------------------------------------------- Date: 2001-Jan-10 19:39 By: jlt63 Comment: Your welcome -- thanks for considering and accepting this patch. If the patch proves to reek havoc on other platforms (most likely only on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out. ------------------------------------------------------- Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 <Cygwin-1.1.5-Python-2.0.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Thu Jan 25 06:54:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 22:54:12 -0800 Subject: [Patches] [Patch #101970] Generate more modern file:///C:/foo/bar syntax Message-ID: <E14LgIO-0002nv-00@usw-sf-web2.sourceforge.net> Patch #101970 has been updated. Project: python Category: library Status: Open Submitted by: prescod Assigned to : gvanrossum Summary: Generate more modern file:///C:/foo/bar syntax Follow-Ups: Date: 2001-Jan-24 22:54 By: prescod Comment: Sorry. I must have been drunk when I submitted the first time. :( This patch is better and has an updated docstring. Here's the intent: Newer Windows browsers use the colon to represent the colon instead of the pipe symbol. Therefore, the colon replacement character is an optional argument. If you care about the colon replacement then you should specify it explicitly because the default may change in the future. --- Teaching urllib to accept various forms of Windows file URLs for conversion to (instead of from) pathnames is a whole other science project...but being able to generate URLs suitable for a browser is a good first step. (I'll be on vacation after sending this so discussion will have to wait until I return) ------------------------------------------------------- Date: 2001-Jan-19 14:59 By: gvanrossum Comment: Paul, if you're not interested in this any more, I'll just reject it, OK? ------------------------------------------------------- Date: 2001-Jan-04 07:46 By: gvanrossum Comment: This patch should be rejected based on form. Paul, you can do better than sending in a diff without context! Also, the subject makes no sense. If you still want this, please fix the subject and submit a new patch and we'll lookj at it again. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101970&group_id=5470 From noreply@sourceforge.net Thu Jan 25 08:09:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 00:09:15 -0800 Subject: [Patches] [Patch #103409] install: setup.py 'dbm' header file searching Message-ID: <E14LhT1-0006gf-00@usw-sf-web1.sourceforge.net> Patch #103409 has been updated. Project: python Category: Build Status: Deleted Submitted by: calvin Assigned to : nobody Summary: install: setup.py 'dbm' header file searching Follow-Ups: Date: 2001-Jan-25 00:09 By: moshez Comment: Calvin decided the patch is irrelevant ------------------------------------------------------- Date: 2001-Jan-24 14:53 By: calvin Comment: Ok, its a Debian bug, never mind. ------------------------------------------------------- Date: 2001-Jan-24 14:46 By: calvin Comment: Argh, thats not my problem: the configure program does not find the db1/ndbm.h file. Hmm, will look further into this. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103409&group_id=5470 From noreply@sourceforge.net Thu Jan 25 08:10:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 00:10:31 -0800 Subject: [Patches] [Patch #103392] Add support for lists in urlencode Message-ID: <E14LhUF-0006h5-00@usw-sf-web1.sourceforge.net> Patch #103392 has been updated. Project: python Category: library Status: Open Submitted by: bquinlan Assigned to : nobody Summary: Add support for lists in urlencode Follow-Ups: Date: 2001-Jan-25 00:10 By: moshez Comment: Duplicate 0f 103391 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103392&group_id=5470 From noreply@sourceforge.net Thu Jan 25 08:10:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 00:10:38 -0800 Subject: [Patches] [Patch #103392] Add support for lists in urlencode Message-ID: <E14LhUM-0006h8-00@usw-sf-web1.sourceforge.net> Patch #103392 has been updated. Project: python Category: library Status: Deleted Submitted by: bquinlan Assigned to : nobody Summary: Add support for lists in urlencode Follow-Ups: Date: 2001-Jan-25 00:10 By: moshez Comment: Duplicate 0f 103391 ------------------------------------------------------- Date: 2001-Jan-25 00:10 By: moshez Comment: Duplicate 0f 103391 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103392&group_id=5470 From noreply@sourceforge.net Thu Jan 25 08:14:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 00:14:05 -0800 Subject: [Patches] [Patch #103412] Complete description of percent formatting in libstdtypes Message-ID: <E14LhXh-0006iJ-00@usw-sf-web1.sourceforge.net> Patch #103412 has been updated. Project: python Category: documentation Status: Open Submitted by: efm Assigned to : fdrake Summary: Complete description of percent formatting in libstdtypes Follow-Ups: Date: 2001-Jan-25 00:14 By: moshez Comment: This patch is supposed to close bug 121207 Fred, there are some TeX problems, so I'm assigning this to you. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103412&group_id=5470 From noreply@sourceforge.net Thu Jan 25 13:37:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 05:37:45 -0800 Subject: [Patches] [Patch #101162] a Python/C API testing framework (simple simple) Message-ID: <E14Lmav-0003gz-00@usw-sf-web3.sourceforge.net> Patch #101162 has been updated. Project: python Category: Build Status: Open Submitted by: tmick Assigned to : tim_one Summary: a Python/C API testing framework (simple simple) Follow-Ups: Date: 2001-Jan-25 05:37 By: nobody Comment: This patch needs to be modified to use setup.py rather then Makefile.pre.in ------------------------------------------------------- Date: 2000-Aug-11 13:37 By: tmick Comment: Here is a proposed patch for a Python/C API testing framework. Simple simple. Basic Overview: - add a _test C extension module that exports test functions beginning with 'test_'; NULL and a TestError exception indicates a test failure and Py_None indicate a test pass - add a test_capi.py test module that calls each of the 'test_' exported functions in the '_test' module - changes to the build system files for Win32 and Unix are includes to build _testmodule.c as a shared extension - new files: Lib/test/test_capi.py, Lib/test/output/test_capi, Modules/_testmodule.c, and PCbuild/_test.dsp ------------------------------------------------------- Date: 2000-Aug-11 13:48 By: tmick Comment: don't use C++ style comments ------------------------------------------------------- Date: 2000-Aug-12 13:46 By: tmick Comment: Skip, You seemed to have some interest in this the couple of times it came up on python-dev. I wonder if you might want to review this. No rush, I don't expect this to go in anytime soon. Unless, of course, people just *have* to have it. <wink> ------------------------------------------------------- Date: 2000-Aug-15 15:23 By: tim_one Comment: Sorry, but there is a rush! Since Python 2.0 is scheduled to have only 1 beta cycle, if this doesn't make it into the beta (< 2 weeks, according to the schedule), it's for 2.1 at best. It would be very good to have a start at this (no matter how simple) in place for 2.0. ------------------------------------------------------- Date: 2000-Aug-16 12:05 By: tmick Comment: re: delaying to 2.1: doesn't bother me much Should it now be "postponed", Tim? ------------------------------------------------------- Date: 2000-Aug-21 19:54 By: montanaro Comment: postponed until 2.1 ------------------------------------------------------- Date: 2000-Nov-27 07:47 By: gvanrossum Comment: Randomly reassigned for review now that 2.1 is open and Skip seems to be too busy to look at this. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101162&group_id=5470 From noreply@sourceforge.net Fri Jan 26 15:12:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 07:12:25 -0800 Subject: [Patches] [Patch #103391] Add support for lists in urlencode Message-ID: <E14MAY5-0006rR-00@usw-sf-web2.sourceforge.net> Patch #103391 has been updated. Project: python Category: library Status: Postponed Submitted by: bquinlan Assigned to : montanaro Summary: Add support for lists in urlencode Follow-Ups: Date: 2001-Jan-26 07:12 By: fdrake Comment: This sounds to me like those CGI scripts are buggy. Postponed pending documentation and test suite updates. Assigned to Skip since he thought the idea was reasonable & I can't assign to the submittor. ------------------------------------------------------- Date: 2001-Jan-23 22:34 By: montanaro Comment: Seems like a reasonable extension to me. needs a Doc/lib/liburllib.tex update though. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103391&group_id=5470 From noreply@sourceforge.net Fri Jan 26 15:18:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 07:18:04 -0800 Subject: [Patches] [Patch #103394] check for libtermcap as well as libreadline Message-ID: <E14MAdY-0006uv-00@usw-sf-web2.sourceforge.net> Patch #103394 has been updated. Project: python Category: Build Status: Open Submitted by: sdm7g Assigned to : lemburg Summary: check for libtermcap as well as libreadline Follow-Ups: Date: 2001-Jan-26 07:18 By: fdrake Comment: Assigned to Marc-Andre since he said he'd be working on a patch for this. He can accept this or propose an alternate patch if needed. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103394&group_id=5470 From noreply@sourceforge.net Fri Jan 26 16:22:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 08:22:06 -0800 Subject: [Patches] [Patch #103441] an inline syntax for function attributes Message-ID: <E14MBdW-0005qQ-00@usw-sf-web3.sourceforge.net> Patch #103441 has been updated. Project: python Category: core (C code) Status: Open Submitted by: mwh Assigned to : nobody Summary: an inline syntax for function attributes ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103441&group_id=5470 From noreply@sourceforge.net Fri Jan 26 17:56:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 09:56:12 -0800 Subject: [Patches] [Patch #103391] Add support for lists in urlencode Message-ID: <E14MD6a-0006a6-00@usw-sf-web3.sourceforge.net> Patch #103391 has been updated. Project: python Category: library Status: Postponed Submitted by: bquinlan Assigned to : montanaro Summary: Add support for lists in urlencode Follow-Ups: Date: 2001-Jan-26 09:56 By: bquinlan Comment: Unfortunately, we must sometimes interoperate with scripts that we did not write. Therefore their (buggy) behavior must be accomodated. I did update the test suite. I'll provide a diff for the .tex file sometime today. ------------------------------------------------------- Date: 2001-Jan-26 07:12 By: fdrake Comment: This sounds to me like those CGI scripts are buggy. Postponed pending documentation and test suite updates. Assigned to Skip since he thought the idea was reasonable & I can't assign to the submittor. ------------------------------------------------------- Date: 2001-Jan-23 22:34 By: montanaro Comment: Seems like a reasonable extension to me. needs a Doc/lib/liburllib.tex update though. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103391&group_id=5470 From noreply@sourceforge.net Fri Jan 26 18:23:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 10:23:21 -0800 Subject: [Patches] [Patch #103394] check for libtermcap as well as libreadline Message-ID: <E14MDWr-0006lI-00@usw-sf-web3.sourceforge.net> Patch #103394 has been updated. Project: python Category: Build Status: Closed Submitted by: sdm7g Assigned to : lemburg Summary: check for libtermcap as well as libreadline Follow-Ups: Date: 2001-Jan-26 10:23 By: lemburg Comment: Checked in a slightly different fix. Please verify. ------------------------------------------------------- Date: 2001-Jan-26 07:18 By: fdrake Comment: Assigned to Marc-Andre since he said he'd be working on a patch for this. He can accept this or propose an alternate patch if needed. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103394&group_id=5470 From noreply@sourceforge.net Fri Jan 26 18:34:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 10:34:40 -0800 Subject: [Patches] [Patch #103445] Fixed DB_RECNO support in bsddb module Message-ID: <E14MDho-0008So-00@usw-sf-web2.sourceforge.net> Patch #103445 has been updated. Project: python Category: Modules Status: Open Submitted by: niemeyer Assigned to : nobody Summary: Fixed DB_RECNO support in bsddb module ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103445&group_id=5470 From noreply@sourceforge.net Fri Jan 26 18:54:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 10:54:36 -0800 Subject: [Patches] [Patch #103052] Restore non-cyclic operation of pulldom.PullDOM Message-ID: <E14ME16-000705-00@usw-sf-web3.sourceforge.net> Patch #103052 has been updated. Project: python Category: XML Status: Closed Submitted by: loewis Assigned to : nobody Summary: Restore non-cyclic operation of pulldom.PullDOM Follow-Ups: Date: 2001-Jan-26 10:54 By: loewis Comment: Checked in as 1.15 of pulldom.py ------------------------------------------------------- Date: 2001-Jan-23 18:26 By: akuchling Comment: The patch appears correct as far as I can tell. Note that I'm not that familiar with pulldom; marking as accepted and also assigning to Paul Prescod, in case he can find time to look at it before Martin checks it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103052&group_id=5470 From noreply@sourceforge.net Fri Jan 26 20:01:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 12:01:18 -0800 Subject: [Patches] [Patch #103391] Add support for lists in urlencode Message-ID: <E14MF3e-0000lA-00@usw-sf-web2.sourceforge.net> Patch #103391 has been updated. Project: python Category: library Status: Postponed Submitted by: bquinlan Assigned to : montanaro Summary: Add support for lists in urlencode Follow-Ups: Date: 2001-Jan-26 12:01 By: montanaro Comment: I'll take a closer look at this. It's actually not a bug in the CGI scripts. CGI parameters are supposed to be returned in the order they appear in the form. This allows you to, for instance, ask for two lines of addresses in a mailing label form and name both parameters "address" without losing the user's input order. Kind of fragile though, so I don't recommend it as a standard form programming practice. Skip ------------------------------------------------------- Date: 2001-Jan-26 09:56 By: bquinlan Comment: Unfortunately, we must sometimes interoperate with scripts that we did not write. Therefore their (buggy) behavior must be accomodated. I did update the test suite. I'll provide a diff for the .tex file sometime today. ------------------------------------------------------- Date: 2001-Jan-26 07:12 By: fdrake Comment: This sounds to me like those CGI scripts are buggy. Postponed pending documentation and test suite updates. Assigned to Skip since he thought the idea was reasonable & I can't assign to the submittor. ------------------------------------------------------- Date: 2001-Jan-23 22:34 By: montanaro Comment: Seems like a reasonable extension to me. needs a Doc/lib/liburllib.tex update though. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103391&group_id=5470 From noreply@sourceforge.net Fri Jan 26 20:49:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 12:49:28 -0800 Subject: [Patches] [Patch #103412] Complete description of percent formatting in libstdtypes Message-ID: <E14MFoG-00017n-00@usw-sf-web2.sourceforge.net> Patch #103412 has been updated. Project: python Category: documentation Status: Closed Submitted by: efm Assigned to : fdrake Summary: Complete description of percent formatting in libstdtypes Follow-Ups: Date: 2001-Jan-26 12:49 By: fdrake Comment: Checked in a modified version of this patch as Doc/lib/libstdtypes.tex revision 1.51. Thanks, Evelyn! ------------------------------------------------------- Date: 2001-Jan-25 00:14 By: moshez Comment: This patch is supposed to close bug 121207 Fred, there are some TeX problems, so I'm assigning this to you. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103412&group_id=5470 From noreply@sourceforge.net Fri Jan 26 22:55:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 14:55:25 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: <E14MHm9-0000KQ-00@usw-sf-web3.sourceforge.net> Patch #102409 has been updated. Project: python Category: Build Status: Open Submitted by: jlt63 Assigned to : akuchling Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-26 14:55 By: akuchling Comment: Checked in the change to the sharedinstall target in Makefile.in, which should be the last part of this patch. Jason, when you get time, can you please check whether everything works out of the box now? ------------------------------------------------------- Date: 2001-Jan-24 21:38 By: jlt63 Comment: There were two sections to my original Makefile.in patch, fixes for: 1. regen 2. make install I indicated that #1 was already fixed in my comment on 2001-Jan-24 05:58: > It appears that the regen hunk of the Makefile.in part is no longer necessary > since python seems to be setting sys.path correctly to find the standard > modules when running out of the build directory now. Hence, that only leave #2. Do you mind doing that part? ------------------------------------------------------- Date: 2001-Jan-24 11:20 By: akuchling Comment: Neil's checkin of the non-recursive affects Makefile.in, the only portion of this patch that isn't checked in. jlt, should I try to port the Makefile.in changes, or do you want to port them and submit a revised patch? ------------------------------------------------------- Date: 2001-Jan-24 07:43 By: akuchling Comment: Checked in the build_ext.py portion of this patch. ------------------------------------------------------- Date: 2001-Jan-24 07:34 By: akuchling Comment: OK. Then the right thing is probably to lose the setup.cfg file completely, and rely on the command-line declaration of install_platlib. This means that just running './python setup.py install' from the command line won't install in the right place, but oh well... And yes, I'm responsible for built_ext at the moment. ------------------------------------------------------- Date: 2001-Jan-24 06:58 By: jlt63 Comment: > The setup.cfg file should be handling this... or does it do the wrong thing somehow? As you mentioned in a comment for the PEP 229 patch, setup.cfg is hard-coding the installation directory at configure time to "@prefix@/lib/python@VERSION@/lib-dynload". Which means that "make prefix=/tmp/python/usr/local install" does not work as expected. That is, everything except for the standard modules install in "/tmp/python/usr/local" but the standard modules still end up in "/usr/local/lib/python2.1/lib-dynload". This makes it difficult to create a pre-built distribution. Are you the right person to commit the Lib/distutils/command/build_ext.py part? This is crucial to getting the Cygwin build working again. It appears that the regen hunk of the Makefile.in part is no longer necessary since python seems to be setting sys.path correctly to find the standard modules when running out of the build directory now. BTW, setup.cfg.in is missed a NL at the end of the file. ------------------------------------------------------- Date: 2001-Jan-23 19:31 By: akuchling Comment: Checked in the setup.py portion of this patch, modified to factor out the getting of a platform value into a get_platform() method. ------------------------------------------------------- Date: 2001-Jan-23 18:55 By: akuchling Comment: Looking at the Makefile.in part of this patch, why is the --install-platlib argument needed. The setup.cfg file should be handling this... or does it do the wrong thing somehow? ------------------------------------------------------- Date: 2001-Jan-19 22:31 By: jlt63 Comment: This patch enables Cygwin Python to build using the new Distutils style Python build. Please note that the build_ext.py part is from Jorge Sousa <jsousa@cfn.ist.utl.pt>. To patch, change directory to the top of the CVS tree and use $ patch -p0 <dist.patch The following is the ChangeLog: Sat Jan 20 01:05:18 2001 Jason Tishler <jt@dothill.com> * Makefile.in($(srcdir)/Lib/$(PLATDIR)): Add Distutils build library directory to PYTHONPATH so regen works again. (sharedinstall): Add --install-platlib option so shared extensions follow $(exec_prefix). * setup.py: Add checks for Cygwin so unsupported modules (i.e., dbm and resource) are not built. * Lib/distutils/command/build_ext.py(build_ext.finalize_options): Add Cygwin specific code to append Python's library directory to the extension's list of library directories. (build_ext.get_libraries): Add Cygwin specific code to append Python's (import) library to the extension's list of libraries. ------------------------------------------------------- Date: 2001-Jan-19 08:19 By: gvanrossum Comment: Reopened at request. Don't sweat the release date -- t's only the first alpha release. I have a feeling it'll be put off till Monday. ------------------------------------------------------- Date: 2001-Jan-18 20:52 By: jlt63 Comment: Please reopen because I need to redo the Cygwin build to handle the use of distutils to build the standard extension modules instead of Modules/Makefile.pre.in. How much time (if any) do I have to resolve these issues before 2.1a is released. I heard that the release date is tomorrow. Sigh... ------------------------------------------------------- Date: 2001-Jan-10 19:39 By: jlt63 Comment: Your welcome -- thanks for considering and accepting this patch. If the patch proves to reek havoc on other platforms (most likely only on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out. ------------------------------------------------------- Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 <Cygwin-1.1.5-Python-2.0.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Fri Jan 26 23:11:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 15:11:35 -0800 Subject: [Patches] [Patch #103138] Install IDLE via distutils Message-ID: <E14MI1n-0002AW-00@usw-sf-web2.sourceforge.net> Patch #103138 has been updated. Project: python Category: IDLE Status: Accepted Submitted by: loewis Assigned to : akuchling Summary: Install IDLE via distutils Follow-Ups: Date: 2001-Jan-26 15:11 By: akuchling Comment: Looks good. Go ahead and check it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103138&group_id=5470 From noreply@sourceforge.net Sat Jan 27 04:04:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 20:04:02 -0800 Subject: [Patches] [Patch #103453] PyMember_Set of T_CHAR always raises exception Message-ID: <E14MMao-0002BW-00@usw-sf-web3.sourceforge.net> Patch #103453 has been updated. Project: python Category: core (C code) Status: Open Submitted by: davecole Assigned to : nobody Summary: PyMember_Set of T_CHAR always raises exception ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103453&group_id=5470 From noreply@sourceforge.net Sat Jan 27 04:57:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 20:57:18 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: <E14MNQM-0002TT-00@usw-sf-web3.sourceforge.net> Patch #102409 has been updated. Project: python Category: Build Status: Open Submitted by: jlt63 Assigned to : akuchling Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-26 20:57 By: jlt63 Comment: Thanks for checking in your changes -- they were all fine. Unfortunately, the changes added for "flattening" the makefiles by nascheme broke the Cygwin build. The attached patch allows Cygwin to build OOTB again. Please reassign to nascheme or check in yourself, if appropriate. ------------------------------------------------------- Date: 2001-Jan-26 14:55 By: akuchling Comment: Checked in the change to the sharedinstall target in Makefile.in, which should be the last part of this patch. Jason, when you get time, can you please check whether everything works out of the box now? ------------------------------------------------------- Date: 2001-Jan-24 21:38 By: jlt63 Comment: There were two sections to my original Makefile.in patch, fixes for: 1. regen 2. make install I indicated that #1 was already fixed in my comment on 2001-Jan-24 05:58: > It appears that the regen hunk of the Makefile.in part is no longer necessary > since python seems to be setting sys.path correctly to find the standard > modules when running out of the build directory now. Hence, that only leave #2. Do you mind doing that part? ------------------------------------------------------- Date: 2001-Jan-24 11:20 By: akuchling Comment: Neil's checkin of the non-recursive affects Makefile.in, the only portion of this patch that isn't checked in. jlt, should I try to port the Makefile.in changes, or do you want to port them and submit a revised patch? ------------------------------------------------------- Date: 2001-Jan-24 07:43 By: akuchling Comment: Checked in the build_ext.py portion of this patch. ------------------------------------------------------- Date: 2001-Jan-24 07:34 By: akuchling Comment: OK. Then the right thing is probably to lose the setup.cfg file completely, and rely on the command-line declaration of install_platlib. This means that just running './python setup.py install' from the command line won't install in the right place, but oh well... And yes, I'm responsible for built_ext at the moment. ------------------------------------------------------- Date: 2001-Jan-24 06:58 By: jlt63 Comment: > The setup.cfg file should be handling this... or does it do the wrong thing somehow? As you mentioned in a comment for the PEP 229 patch, setup.cfg is hard-coding the installation directory at configure time to "@prefix@/lib/python@VERSION@/lib-dynload". Which means that "make prefix=/tmp/python/usr/local install" does not work as expected. That is, everything except for the standard modules install in "/tmp/python/usr/local" but the standard modules still end up in "/usr/local/lib/python2.1/lib-dynload". This makes it difficult to create a pre-built distribution. Are you the right person to commit the Lib/distutils/command/build_ext.py part? This is crucial to getting the Cygwin build working again. It appears that the regen hunk of the Makefile.in part is no longer necessary since python seems to be setting sys.path correctly to find the standard modules when running out of the build directory now. BTW, setup.cfg.in is missed a NL at the end of the file. ------------------------------------------------------- Date: 2001-Jan-23 19:31 By: akuchling Comment: Checked in the setup.py portion of this patch, modified to factor out the getting of a platform value into a get_platform() method. ------------------------------------------------------- Date: 2001-Jan-23 18:55 By: akuchling Comment: Looking at the Makefile.in part of this patch, why is the --install-platlib argument needed. The setup.cfg file should be handling this... or does it do the wrong thing somehow? ------------------------------------------------------- Date: 2001-Jan-19 22:31 By: jlt63 Comment: This patch enables Cygwin Python to build using the new Distutils style Python build. Please note that the build_ext.py part is from Jorge Sousa <jsousa@cfn.ist.utl.pt>. To patch, change directory to the top of the CVS tree and use $ patch -p0 <dist.patch The following is the ChangeLog: Sat Jan 20 01:05:18 2001 Jason Tishler <jt@dothill.com> * Makefile.in($(srcdir)/Lib/$(PLATDIR)): Add Distutils build library directory to PYTHONPATH so regen works again. (sharedinstall): Add --install-platlib option so shared extensions follow $(exec_prefix). * setup.py: Add checks for Cygwin so unsupported modules (i.e., dbm and resource) are not built. * Lib/distutils/command/build_ext.py(build_ext.finalize_options): Add Cygwin specific code to append Python's library directory to the extension's list of library directories. (build_ext.get_libraries): Add Cygwin specific code to append Python's (import) library to the extension's list of libraries. ------------------------------------------------------- Date: 2001-Jan-19 08:19 By: gvanrossum Comment: Reopened at request. Don't sweat the release date -- t's only the first alpha release. I have a feeling it'll be put off till Monday. ------------------------------------------------------- Date: 2001-Jan-18 20:52 By: jlt63 Comment: Please reopen because I need to redo the Cygwin build to handle the use of distutils to build the standard extension modules instead of Modules/Makefile.pre.in. How much time (if any) do I have to resolve these issues before 2.1a is released. I heard that the release date is tomorrow. Sigh... ------------------------------------------------------- Date: 2001-Jan-10 19:39 By: jlt63 Comment: Your welcome -- thanks for considering and accepting this patch. If the patch proves to reek havoc on other platforms (most likely only on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out. ------------------------------------------------------- Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 <Cygwin-1.1.5-Python-2.0.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Sat Jan 27 05:30:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 21:30:57 -0800 Subject: [Patches] [Patch #103391] Add support for lists in urlencode Message-ID: <E14MNwv-0004Ub-00@usw-sf-web2.sourceforge.net> Patch #103391 has been updated. Project: python Category: library Status: Postponed Submitted by: bquinlan Assigned to : montanaro Summary: Add support for lists in urlencode Follow-Ups: Date: 2001-Jan-26 21:30 By: bquinlan Comment: Not sure how to post this... Here is a mod to liburllib.tex, change the section for urlencode at 146: \begin{funcdesc}{urlencode}{query\optional{, doseq}} Convert a list of 2-tuples or a dictionary to a ``url-encoded'' string, suitable to pass to \function{urlopen()} above as the optional \var{data} argument. This is useful to pass form fields to a \code{POST} request. The resulting string is a series of \code{\var{key}=\var{value}} pairs separated by \character{\&} characters, where both \var{key} and \var{value} are quoted using \function{quote_plus()} above. If the optional parameter \var{doseq} is present and evaluates to true, individual \code{\var{key}=\var{value}} pairs are generated for each element of the sequence. \end{funcdesc} ------------------------------------------------------- Date: 2001-Jan-26 12:01 By: montanaro Comment: I'll take a closer look at this. It's actually not a bug in the CGI scripts. CGI parameters are supposed to be returned in the order they appear in the form. This allows you to, for instance, ask for two lines of addresses in a mailing label form and name both parameters "address" without losing the user's input order. Kind of fragile though, so I don't recommend it as a standard form programming practice. Skip ------------------------------------------------------- Date: 2001-Jan-26 09:56 By: bquinlan Comment: Unfortunately, we must sometimes interoperate with scripts that we did not write. Therefore their (buggy) behavior must be accomodated. I did update the test suite. I'll provide a diff for the .tex file sometime today. ------------------------------------------------------- Date: 2001-Jan-26 07:12 By: fdrake Comment: This sounds to me like those CGI scripts are buggy. Postponed pending documentation and test suite updates. Assigned to Skip since he thought the idea was reasonable & I can't assign to the submittor. ------------------------------------------------------- Date: 2001-Jan-23 22:34 By: montanaro Comment: Seems like a reasonable extension to me. needs a Doc/lib/liburllib.tex update though. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103391&group_id=5470 From noreply@sourceforge.net Sat Jan 27 06:05:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 22:05:45 -0800 Subject: [Patches] [Patch #103453] PyMember_Set of T_CHAR always raises exception Message-ID: <E14MOUb-0002r0-00@usw-sf-web3.sourceforge.net> Patch #103453 has been updated. Project: python Category: core (C code) Status: Open Submitted by: davecole Assigned to : tim_one Summary: PyMember_Set of T_CHAR always raises exception Follow-Ups: Date: 2001-Jan-26 22:05 By: tim_one Comment: Assigned to me. This also related to some recent bug report. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103453&group_id=5470 From noreply@sourceforge.net Sat Jan 27 06:06:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 22:06:15 -0800 Subject: [Patches] [Patch #103445] Fixed DB_RECNO support in bsddb module Message-ID: <E14MOV5-0002rM-00@usw-sf-web3.sourceforge.net> Patch #103445 has been updated. Project: python Category: Modules Status: Open Submitted by: niemeyer Assigned to : montanaro Summary: Fixed DB_RECNO support in bsddb module Follow-Ups: Date: 2001-Jan-26 22:06 By: fdrake Comment: I think this is fine from a quick eyeballing of the code, but would add the di_type declaration before the WITH_THREAD conditional section so that the optional part is at the end. Assigned to Skip since he's dealt a lot with this module recently. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103445&group_id=5470 From noreply@sourceforge.net Sat Jan 27 06:21:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 22:21:44 -0800 Subject: [Patches] [Patch #103453] PyMember_Set of T_CHAR always raises exception Message-ID: <E14MOk4-0002wc-00@usw-sf-web3.sourceforge.net> Patch #103453 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: davecole Assigned to : tim_one Summary: PyMember_Set of T_CHAR always raises exception Follow-Ups: Date: 2001-Jan-26 22:21 By: tim_one Comment: Applied and closed, structmember.c rev 2.19, ACKS rev 1.75. Checkin comment: SF bug http://sourceforge.net/bugs/?func=detailbug&bug_id=130242&group_id=5470 SF patch http://sourceforge.net/patch/?func=detailpatch&patch_id=103453&group_id=5470 PyMember_Set of T_CHAR always raises exception. Unfortunately, this is a use of a C API function that Python itself never makes, so there's no .py test I can check in to verify this stays fixed. But the fault in the code is obvious, and Dave Cole's patch just as obviously fixes it. ------------------------------------------------------- Date: 2001-Jan-26 22:05 By: tim_one Comment: Assigned to me. This also related to some recent bug report. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103453&group_id=5470 From noreply@sourceforge.net Sat Jan 27 20:28:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 27 Jan 2001 12:28:26 -0800 Subject: [Patches] [Patch #103457] Fixed shadowing problem with cmpfunc in Mac OS X Message-ID: <E14MbxS-0001bd-00@usw-sf-web2.sourceforge.net> Patch #103457 has been updated. Project: python Category: core (C code) Status: Open Submitted by: bquinlan Assigned to : nobody Summary: Fixed shadowing problem with cmpfunc in Mac OS X ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103457&group_id=5470 From noreply@sourceforge.net Sat Jan 27 21:10:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 27 Jan 2001 13:10:53 -0800 Subject: [Patches] [Patch #103457] Fixed shadowing problem with cmpfunc in Mac OS X Message-ID: <E14MccX-0001rh-00@usw-sf-web2.sourceforge.net> Patch #103457 has been updated. Project: python Category: core (C code) Status: Open Submitted by: bquinlan Assigned to : nobody Summary: Fixed shadowing problem with cmpfunc in Mac OS X Follow-Ups: Date: 2001-Jan-27 13:10 By: bquinlan Comment: See bug #129827 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103457&group_id=5470 From noreply@sourceforge.net Sat Jan 27 21:48:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 27 Jan 2001 13:48:54 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: <E14MdDK-00026f-00@usw-sf-web2.sourceforge.net> Patch #102409 has been updated. Project: python Category: Build Status: Closed Submitted by: jlt63 Assigned to : nobody Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-27 13:48 By: nascheme Comment: Checked in. Thanks Jason. ------------------------------------------------------- Date: 2001-Jan-26 20:57 By: jlt63 Comment: Thanks for checking in your changes -- they were all fine. Unfortunately, the changes added for "flattening" the makefiles by nascheme broke the Cygwin build. The attached patch allows Cygwin to build OOTB again. Please reassign to nascheme or check in yourself, if appropriate. ------------------------------------------------------- Date: 2001-Jan-26 14:55 By: akuchling Comment: Checked in the change to the sharedinstall target in Makefile.in, which should be the last part of this patch. Jason, when you get time, can you please check whether everything works out of the box now? ------------------------------------------------------- Date: 2001-Jan-24 21:38 By: jlt63 Comment: There were two sections to my original Makefile.in patch, fixes for: 1. regen 2. make install I indicated that #1 was already fixed in my comment on 2001-Jan-24 05:58: > It appears that the regen hunk of the Makefile.in part is no longer necessary > since python seems to be setting sys.path correctly to find the standard > modules when running out of the build directory now. Hence, that only leave #2. Do you mind doing that part? ------------------------------------------------------- Date: 2001-Jan-24 11:20 By: akuchling Comment: Neil's checkin of the non-recursive affects Makefile.in, the only portion of this patch that isn't checked in. jlt, should I try to port the Makefile.in changes, or do you want to port them and submit a revised patch? ------------------------------------------------------- Date: 2001-Jan-24 07:43 By: akuchling Comment: Checked in the build_ext.py portion of this patch. ------------------------------------------------------- Date: 2001-Jan-24 07:34 By: akuchling Comment: OK. Then the right thing is probably to lose the setup.cfg file completely, and rely on the command-line declaration of install_platlib. This means that just running './python setup.py install' from the command line won't install in the right place, but oh well... And yes, I'm responsible for built_ext at the moment. ------------------------------------------------------- Date: 2001-Jan-24 06:58 By: jlt63 Comment: > The setup.cfg file should be handling this... or does it do the wrong thing somehow? As you mentioned in a comment for the PEP 229 patch, setup.cfg is hard-coding the installation directory at configure time to "@prefix@/lib/python@VERSION@/lib-dynload". Which means that "make prefix=/tmp/python/usr/local install" does not work as expected. That is, everything except for the standard modules install in "/tmp/python/usr/local" but the standard modules still end up in "/usr/local/lib/python2.1/lib-dynload". This makes it difficult to create a pre-built distribution. Are you the right person to commit the Lib/distutils/command/build_ext.py part? This is crucial to getting the Cygwin build working again. It appears that the regen hunk of the Makefile.in part is no longer necessary since python seems to be setting sys.path correctly to find the standard modules when running out of the build directory now. BTW, setup.cfg.in is missed a NL at the end of the file. ------------------------------------------------------- Date: 2001-Jan-23 19:31 By: akuchling Comment: Checked in the setup.py portion of this patch, modified to factor out the getting of a platform value into a get_platform() method. ------------------------------------------------------- Date: 2001-Jan-23 18:55 By: akuchling Comment: Looking at the Makefile.in part of this patch, why is the --install-platlib argument needed. The setup.cfg file should be handling this... or does it do the wrong thing somehow? ------------------------------------------------------- Date: 2001-Jan-19 22:31 By: jlt63 Comment: This patch enables Cygwin Python to build using the new Distutils style Python build. Please note that the build_ext.py part is from Jorge Sousa <jsousa@cfn.ist.utl.pt>. To patch, change directory to the top of the CVS tree and use $ patch -p0 <dist.patch The following is the ChangeLog: Sat Jan 20 01:05:18 2001 Jason Tishler <jt@dothill.com> * Makefile.in($(srcdir)/Lib/$(PLATDIR)): Add Distutils build library directory to PYTHONPATH so regen works again. (sharedinstall): Add --install-platlib option so shared extensions follow $(exec_prefix). * setup.py: Add checks for Cygwin so unsupported modules (i.e., dbm and resource) are not built. * Lib/distutils/command/build_ext.py(build_ext.finalize_options): Add Cygwin specific code to append Python's library directory to the extension's list of library directories. (build_ext.get_libraries): Add Cygwin specific code to append Python's (import) library to the extension's list of libraries. ------------------------------------------------------- Date: 2001-Jan-19 08:19 By: gvanrossum Comment: Reopened at request. Don't sweat the release date -- t's only the first alpha release. I have a feeling it'll be put off till Monday. ------------------------------------------------------- Date: 2001-Jan-18 20:52 By: jlt63 Comment: Please reopen because I need to redo the Cygwin build to handle the use of distutils to build the standard extension modules instead of Modules/Makefile.pre.in. How much time (if any) do I have to resolve these issues before 2.1a is released. I heard that the release date is tomorrow. Sigh... ------------------------------------------------------- Date: 2001-Jan-10 19:39 By: jlt63 Comment: Your welcome -- thanks for considering and accepting this patch. If the patch proves to reek havoc on other platforms (most likely only on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out. ------------------------------------------------------- Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 <Cygwin-1.1.5-Python-2.0.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Sun Jan 28 01:02:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 27 Jan 2001 17:02:30 -0800 Subject: [Patches] [Patch #101137] Add raw packet support to socketmodule.c Message-ID: <E14MgEg-0003Hg-00@usw-sf-web2.sourceforge.net> Patch #101137 has been updated. Project: python Category: Modules Status: Open Submitted by: grante Assigned to : jhylton Summary: Add raw packet support to socketmodule.c Follow-Ups: Date: 2001-Jan-27 17:02 By: grante Comment: Revised patch: 1) fixed indentation style. 2) fixed possible strncpy buffer overrun. 3) fixed bug in getsockname. 4) exposed sll_pkttype and sll_hatype fields of sockaddr_ll struct (AFAICT, they're not useful). 5) changed conditional compilation so AF_PACKET stuff is only built under Linux. (patch is against 2.0) ------------------------------------------------------- Date: 2001-Jan-18 10:01 By: nobody Comment: Yes, I'm still interested in this patch. Winthin the next week or two I'll try to get a revised patch submitted that addresses some of the comments. Two things I can't do much about are: 1) I only have Linux systems for testing: I don't have root privledges on any other type of system. 2) Unless it is agreed to change parameters for makesockaddr, I can't do anything except create a temporary socket in order to look up the interface name. I suppose I could require user code to provide an interface index, but I don't really like that option since it diverges quite a bit from the "C" usage. ------------------------------------------------------- Date: 2001-Jan-18 09:39 By: jhylton Comment: Is Grant still interested in this patch? I don't have time to fix it myself, but I would be happy to look at it again if we comments and questions are addressed. ------------------------------------------------------- Date: 2000-Aug-09 14:49 By: grante Comment: Patch has only been tested on Linux: RH6.2 (Intel). Patch is against 1.6b1 ------------------------------------------------------- Date: 2000-Aug-15 15:15 By: tim_one Comment: Assigned to Barry, since he just volunteered to rewrite all of Python's socket code anyway <wink>. ------------------------------------------------------- Date: 2000-Aug-24 14:27 By: jhylton Comment: Not sure about this patch. It needs to be tested on more platforms than just Linux, but I don't see that we'll have time before 2.0. There are several other issues that must be resolved, too. Thus, this patch falls subject to the feature freeze. Style points: Indention is wrong. The opening curly brace of an if belongs on the same line as the test. Whitespace is required around = and after commas in argument lists. The strncpy in makesockaddr does not check the size of the source string. It could overflow the buffer. In makesockaddr, a new socket is created just to look up the interface name associated with a particular interface. This seems wasteful, particularly in cases where few file descriptors are available. I'm not sure what the solution is, although it might be to change the makesockaddr function so that it takes the socket itself. Perhaps that socket address for AF_PACKET should also accept and/or produce interface numbers which the client can convert to names manually. The sockaddr_ll has members ssl_hatype and ssl_pkttype, which are not made accessible by this patch. It seems like they should be, but I am not sure. Can you use SOCK_DGRAM without specifying the packet type? getsockaddrarg is handled, but getsockaddrlen is not. Question: Are there any other constants that should be added? This relates to the packet type question. * ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101137&group_id=5470 From noreply@sourceforge.net Sun Jan 28 01:26:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 27 Jan 2001 17:26:34 -0800 Subject: [Patches] [Patch #103395] Guido changed his mind! Quickly, add 'if key in dict'! Message-ID: <E14Mgby-000577-00@usw-sf-web1.sourceforge.net> Patch #103395 has been updated. Project: python Category: core (C code) Status: Open Submitted by: twouters Assigned to : gvanrossum Summary: Guido changed his mind! Quickly, add 'if key in dict'! Follow-Ups: Date: 2001-Jan-27 17:26 By: twouters Comment: Newer patch, avoids Misc/NEWS conflict, fixes oversight in dict_contains. ------------------------------------------------------- Date: 2001-Jan-24 01:05 By: tim_one Comment: There must be something in the air, besides email delays. I'll take your word for it that Guido changed his mind, but I was about to say +1 anyway! Now all we have to do is trick xreadlines into iterating over dicts <wink>. ------------------------------------------------------- Date: 2001-Jan-23 23:39 By: twouters Comment: Added testcases for dict and UserDict. ------------------------------------------------------- Date: 2001-Jan-23 23:20 By: twouters Comment: Add some docs (not guarded by a 'new in 2.1' statement, I don't know how to do that), NEWS item and support in UserDict.UserDict. Docs of has_key should probably also mention that 'if key in dict' does the same, but I'm not sure how to say that's new in Python 2.1. ------------------------------------------------------- Date: 2001-Jan-23 22:57 By: twouters Comment: There yah go, Guido. Does my being awakened by my loud and malicious partner (who needs to head to her office 4 hours before me) earn me yet another free and legally useless 2.1 alpha ? :-) Note: it's missing docs. Will add then once I figure out where to add them. Also haven't updated the std-lib yet, will do that next. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103395&group_id=5470 From noreply@sourceforge.net Sun Jan 28 05:53:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 27 Jan 2001 21:53:02 -0800 Subject: [Patches] [Patch #103395] Guido changed his mind! Quickly, add 'if key in dict'! Message-ID: <E14Mklq-0003EJ-00@usw-sf-web3.sourceforge.net> Patch #103395 has been updated. Project: python Category: core (C code) Status: Open Submitted by: twouters Assigned to : tim_one Summary: Guido changed his mind! Quickly, add 'if key in dict'! Follow-Ups: Date: 2001-Jan-27 21:53 By: tim_one Comment: Assigned to me while Guido is sleeping so he doesn't get a chance to change his mind. ------------------------------------------------------- Date: 2001-Jan-27 17:26 By: twouters Comment: Newer patch, avoids Misc/NEWS conflict, fixes oversight in dict_contains. ------------------------------------------------------- Date: 2001-Jan-24 01:05 By: tim_one Comment: There must be something in the air, besides email delays. I'll take your word for it that Guido changed his mind, but I was about to say +1 anyway! Now all we have to do is trick xreadlines into iterating over dicts <wink>. ------------------------------------------------------- Date: 2001-Jan-23 23:39 By: twouters Comment: Added testcases for dict and UserDict. ------------------------------------------------------- Date: 2001-Jan-23 23:20 By: twouters Comment: Add some docs (not guarded by a 'new in 2.1' statement, I don't know how to do that), NEWS item and support in UserDict.UserDict. Docs of has_key should probably also mention that 'if key in dict' does the same, but I'm not sure how to say that's new in Python 2.1. ------------------------------------------------------- Date: 2001-Jan-23 22:57 By: twouters Comment: There yah go, Guido. Does my being awakened by my loud and malicious partner (who needs to head to her office 4 hours before me) earn me yet another free and legally useless 2.1 alpha ? :-) Note: it's missing docs. Will add then once I figure out where to add them. Also haven't updated the std-lib yet, will do that next. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103395&group_id=5470 From noreply@sourceforge.net Sun Jan 28 07:11:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 27 Jan 2001 23:11:02 -0800 Subject: [Patches] [Patch #103445] Fixed DB_RECNO support in bsddb module Message-ID: <E14MlzK-0003cO-00@usw-sf-web3.sourceforge.net> Patch #103445 has been updated. Project: python Category: Modules Status: Open Submitted by: niemeyer Assigned to : fdrake Summary: Fixed DB_RECNO support in bsddb module Follow-Ups: Date: 2001-Jan-27 23:11 By: fdrake Comment: Re-assigned to me; Skip only worked on the build process for this, not the module code. ------------------------------------------------------- Date: 2001-Jan-26 22:06 By: fdrake Comment: I think this is fine from a quick eyeballing of the code, but would add the di_type declaration before the WITH_THREAD conditional section so that the optional part is at the end. Assigned to Skip since he's dealt a lot with this module recently. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103445&group_id=5470 From noreply@sourceforge.net Sun Jan 28 07:18:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 27 Jan 2001 23:18:11 -0800 Subject: [Patches] [Patch #103395] Guido changed his mind! Quickly, add 'if key in dict'! Message-ID: <E14Mm6F-0003ew-00@usw-sf-web3.sourceforge.net> Patch #103395 has been updated. Project: python Category: core (C code) Status: Open Submitted by: twouters Assigned to : fdrake Summary: Guido changed his mind! Quickly, add 'if key in dict'! Follow-Ups: Date: 2001-Jan-27 23:18 By: tim_one Comment: Reviewed the code and tried it out. Boffo! It's Accepted as far as I'm concerned. Cute: the Cygwin "patch" program core dumped consistently when trying to apply the NEWS patch, so I didn't test that part <wink>. Assigned to Fred for final disposition, since Thomas noted doc questions in his comments. I'll add that, since the docs already explain has_key, nothing good can come of trying to explain "in" via different words; would be shorter and better to just say x in dict == dict.has_key(x) x not in dict == not dict.has_key(x) everywhere it comes up. ------------------------------------------------------- Date: 2001-Jan-27 21:53 By: tim_one Comment: Assigned to me while Guido is sleeping so he doesn't get a chance to change his mind. ------------------------------------------------------- Date: 2001-Jan-27 17:26 By: twouters Comment: Newer patch, avoids Misc/NEWS conflict, fixes oversight in dict_contains. ------------------------------------------------------- Date: 2001-Jan-24 01:05 By: tim_one Comment: There must be something in the air, besides email delays. I'll take your word for it that Guido changed his mind, but I was about to say +1 anyway! Now all we have to do is trick xreadlines into iterating over dicts <wink>. ------------------------------------------------------- Date: 2001-Jan-23 23:39 By: twouters Comment: Added testcases for dict and UserDict. ------------------------------------------------------- Date: 2001-Jan-23 23:20 By: twouters Comment: Add some docs (not guarded by a 'new in 2.1' statement, I don't know how to do that), NEWS item and support in UserDict.UserDict. Docs of has_key should probably also mention that 'if key in dict' does the same, but I'm not sure how to say that's new in Python 2.1. ------------------------------------------------------- Date: 2001-Jan-23 22:57 By: twouters Comment: There yah go, Guido. Does my being awakened by my loud and malicious partner (who needs to head to her office 4 hours before me) earn me yet another free and legally useless 2.1 alpha ? :-) Note: it's missing docs. Will add then once I figure out where to add them. Also haven't updated the std-lib yet, will do that next. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103395&group_id=5470 From noreply@sourceforge.net Sun Jan 28 11:02:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 28 Jan 2001 03:02:41 -0800 Subject: [Patches] [Patch #103138] Install IDLE via distutils Message-ID: <E14MpbV-0004rd-00@usw-sf-web3.sourceforge.net> Patch #103138 has been updated. Project: python Category: IDLE Status: Closed Submitted by: loewis Assigned to : nobody Summary: Install IDLE via distutils Follow-Ups: Date: 2001-Jan-26 15:11 By: akuchling Comment: Looks good. Go ahead and check it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103138&group_id=5470 From noreply@sourceforge.net Sun Jan 28 11:03:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 28 Jan 2001 03:03:20 -0800 Subject: [Patches] [Patch #103138] Install IDLE via distutils Message-ID: <E14Mpc8-0004rq-00@usw-sf-web3.sourceforge.net> Patch #103138 has been updated. Project: python Category: IDLE Status: Closed Submitted by: loewis Assigned to : nobody Summary: Install IDLE via distutils Follow-Ups: Date: 2001-Jan-28 03:03 By: loewis Comment: Committed as 1.3 of idle and 1.1 of setup.py ------------------------------------------------------- Date: 2001-Jan-26 15:11 By: akuchling Comment: Looks good. Go ahead and check it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103138&group_id=5470 From noreply@sourceforge.net Sun Jan 28 17:44:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 28 Jan 2001 09:44:30 -0800 Subject: [Patches] [Patch #103471] xml pretty-printing in minidom Message-ID: <E14MvsM-0001UB-00@usw-sf-web2.sourceforge.net> Patch #103471 has been updated. Project: python Category: library Status: Open Submitted by: isk Assigned to : nobody Summary: xml pretty-printing in minidom ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103471&group_id=5470 From noreply@sourceforge.net Sun Jan 28 18:19:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 28 Jan 2001 10:19:25 -0800 Subject: [Patches] [Patch #103277] Enables a package to have more than one source dir Message-ID: <E14MwQ9-0001io-00@usw-sf-web2.sourceforge.net> Patch #103277 has been updated. Project: python Category: distutils Status: Open Submitted by: nobody Assigned to : akuchling Summary: Enables a package to have more than one source dir Follow-Ups: Date: 2001-Jan-28 10:19 By: akuchling Comment: I'm doubtful of the usefulness of this patch; can you please explain the motivation? Why do you want to have multiple directories containing the Python files for a single package? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103277&group_id=5470 From noreply@sourceforge.net Sun Jan 28 20:32:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 28 Jan 2001 12:32:17 -0800 Subject: [Patches] [Patch #103473] Cookie.py: Allow values containing '=' Message-ID: <E14MyUj-0002b3-00@usw-sf-web2.sourceforge.net> Patch #103473 has been updated. Project: python Category: library Status: Open Submitted by: dougfort Assigned to : nobody Summary: Cookie.py: Allow values containing '=' ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103473&group_id=5470 From noreply@sourceforge.net Sun Jan 28 21:19:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 28 Jan 2001 13:19:43 -0800 Subject: [Patches] [Patch #103391] Add support for lists in urlencode Message-ID: <E14MzEd-0004oQ-00@usw-sf-web1.sourceforge.net> Patch #103391 has been updated. Project: python Category: library Status: Accepted Submitted by: bquinlan Assigned to : fdrake Summary: Add support for lists in urlencode Follow-Ups: Date: 2001-Jan-28 13:19 By: montanaro Comment: accepted with modifications and closed the major modification was to expand the acceptable input types beyond dictionaries and lists. Anything that has an items method should work as a stand-in for a real dictionary, and anything that is a non-empty sequence of two-element tuples should workk as a stand-in for lists. test cases suitably extended & documentation adjusted. Marked as accepted and reassigned to Fred so he can sign off on the urlencode documentation. (Fred, close it out when you're happy...) ------------------------------------------------------- Date: 2001-Jan-26 21:30 By: bquinlan Comment: Not sure how to post this... Here is a mod to liburllib.tex, change the section for urlencode at 146: \begin{funcdesc}{urlencode}{query\optional{, doseq}} Convert a list of 2-tuples or a dictionary to a ``url-encoded'' string, suitable to pass to \function{urlopen()} above as the optional \var{data} argument. This is useful to pass form fields to a \code{POST} request. The resulting string is a series of \code{\var{key}=\var{value}} pairs separated by \character{\&} characters, where both \var{key} and \var{value} are quoted using \function{quote_plus()} above. If the optional parameter \var{doseq} is present and evaluates to true, individual \code{\var{key}=\var{value}} pairs are generated for each element of the sequence. \end{funcdesc} ------------------------------------------------------- Date: 2001-Jan-26 12:01 By: montanaro Comment: I'll take a closer look at this. It's actually not a bug in the CGI scripts. CGI parameters are supposed to be returned in the order they appear in the form. This allows you to, for instance, ask for two lines of addresses in a mailing label form and name both parameters "address" without losing the user's input order. Kind of fragile though, so I don't recommend it as a standard form programming practice. Skip ------------------------------------------------------- Date: 2001-Jan-26 09:56 By: bquinlan Comment: Unfortunately, we must sometimes interoperate with scripts that we did not write. Therefore their (buggy) behavior must be accomodated. I did update the test suite. I'll provide a diff for the .tex file sometime today. ------------------------------------------------------- Date: 2001-Jan-26 07:12 By: fdrake Comment: This sounds to me like those CGI scripts are buggy. Postponed pending documentation and test suite updates. Assigned to Skip since he thought the idea was reasonable & I can't assign to the submittor. ------------------------------------------------------- Date: 2001-Jan-23 22:34 By: montanaro Comment: Seems like a reasonable extension to me. needs a Doc/lib/liburllib.tex update though. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103391&group_id=5470 From noreply@sourceforge.net Mon Jan 29 05:47:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 28 Jan 2001 21:47:06 -0800 Subject: [Patches] [Patch #103476] Two Lib/mailbox.py fixes Message-ID: <E14N79e-000897-00@usw-sf-web1.sourceforge.net> Patch #103476 has been updated. Project: python Category: library Status: Open Submitted by: bwarsaw Assigned to : nobody Summary: Two Lib/mailbox.py fixes ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103476&group_id=5470 From noreply@sourceforge.net Mon Jan 29 05:48:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 28 Jan 2001 21:48:13 -0800 Subject: [Patches] [Patch #103476] Two Lib/mailbox.py fixes Message-ID: <E14N7Aj-00089c-00@usw-sf-web1.sourceforge.net> Patch #103476 has been updated. Project: python Category: library Status: Open Submitted by: bwarsaw Assigned to : twouters Summary: Two Lib/mailbox.py fixes Follow-Ups: Date: 2001-Jan-28 21:48 By: bwarsaw Comment: Assigned to Thomas for sanity checking. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103476&group_id=5470 From noreply@sourceforge.net Mon Jan 29 07:37:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 28 Jan 2001 23:37:47 -0800 Subject: [Patches] [Patch #103476] Two Lib/mailbox.py fixes Message-ID: <E14N8sl-0005SV-00@usw-sf-web3.sourceforge.net> Patch #103476 has been updated. Project: python Category: library Status: Open Submitted by: bwarsaw Assigned to : bwarsaw Summary: Two Lib/mailbox.py fixes Follow-Ups: Date: 2001-Jan-28 23:37 By: twouters Comment: Looks okay to me. I'm not sure if I'm "fine" with the idea of matching from_lines without a preceding blank line, but I also don't want to invest the time to rewrite the module to even allow that, so I can't expect anyone else to :) From-lineiness and the quoting of such differs greatly between mailers :P I *think* this will work for 99.9% of the mailboxes out there (since I know it works for Pine, Mutt, Nutscape and Eudorka (which uses an aditional file for message state, though)) but I'm still a bit wary of forcing people in the last promille to subclass and fiddle with internals themselves. Why not provide a StrictMailbox class that does it for them ? Don't forget Misc/NEWS, Barry. If I was supposed to mark it Accepted, consider it marked Accepted :) ------------------------------------------------------- Date: 2001-Jan-28 21:48 By: bwarsaw Comment: Assigned to Thomas for sanity checking. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103476&group_id=5470 From noreply@sourceforge.net Mon Jan 29 07:53:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 28 Jan 2001 23:53:18 -0800 Subject: [Patches] [Patch #103477] BeOS build scripts, setup.py Message-ID: <E14N97m-0000ii-00@usw-sf-web1.sourceforge.net> Patch #103477 has been updated. Project: python Category: None Status: Open Submitted by: donnc Assigned to : nobody Summary: BeOS build scripts, setup.py ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103477&group_id=5470 From noreply@sourceforge.net Mon Jan 29 07:58:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 28 Jan 2001 23:58:31 -0800 Subject: [Patches] [Patch #103478] Lib/test for BeOS Message-ID: <E14N9Cp-0000kv-00@usw-sf-web1.sourceforge.net> Patch #103478 has been updated. Project: python Category: library Status: Open Submitted by: donnc Assigned to : nobody Summary: Lib/test for BeOS ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103478&group_id=5470 From noreply@sourceforge.net Mon Jan 29 19:29:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 11:29:44 -0800 Subject: [Patches] [Patch #103485] _cursesmodule.c, AIX and NetBSD Message-ID: <E14NJzk-0002OL-00@usw-sf-web3.sourceforge.net> Patch #103485 has been updated. Project: python Category: Modules Status: Open Submitted by: donnc Assigned to : nobody Summary: _cursesmodule.c, AIX and NetBSD ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103485&group_id=5470 From noreply@sourceforge.net Mon Jan 29 20:47:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 12:47:19 -0800 Subject: [Patches] [Patch #103485] _cursesmodule.c, AIX and NetBSD Message-ID: <E14NLCp-00084f-00@usw-sf-web1.sourceforge.net> Patch #103485 has been updated. Project: python Category: Modules Status: Open Submitted by: donnc Assigned to : akuchling Summary: _cursesmodule.c, AIX and NetBSD Follow-Ups: Date: 2001-Jan-29 12:47 By: akuchling Comment: Checked in, with one modification. I removed the use of 'lines' as a variable name, so the #undef lines should now be unnecessary. Donn, please let me know if the current CVS now compiles cleanly for you on AIX and NetBSD. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103485&group_id=5470 From noreply@sourceforge.net Mon Jan 29 20:51:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 12:51:33 -0800 Subject: [Patches] [Patch #101162] a Python/C API testing framework (simple simple) Message-ID: <E14NLGv-00087h-00@usw-sf-web1.sourceforge.net> Patch #101162 has been updated. Project: python Category: Build Status: Open Submitted by: tmick Assigned to : tim_one Summary: a Python/C API testing framework (simple simple) Follow-Ups: Date: 2001-Jan-29 12:51 By: akuchling Comment: Assuming that the _test module doesn't need anything special to compile (and why should it?), the change to setup.py is simple, adding the following line: exts.append( Extension('_test', ['_testmodule.c']) ) ------------------------------------------------------- Date: 2001-Jan-25 05:37 By: nobody Comment: This patch needs to be modified to use setup.py rather then Makefile.pre.in ------------------------------------------------------- Date: 2000-Aug-11 13:37 By: tmick Comment: Here is a proposed patch for a Python/C API testing framework. Simple simple. Basic Overview: - add a _test C extension module that exports test functions beginning with 'test_'; NULL and a TestError exception indicates a test failure and Py_None indicate a test pass - add a test_capi.py test module that calls each of the 'test_' exported functions in the '_test' module - changes to the build system files for Win32 and Unix are includes to build _testmodule.c as a shared extension - new files: Lib/test/test_capi.py, Lib/test/output/test_capi, Modules/_testmodule.c, and PCbuild/_test.dsp ------------------------------------------------------- Date: 2000-Aug-11 13:48 By: tmick Comment: don't use C++ style comments ------------------------------------------------------- Date: 2000-Aug-12 13:46 By: tmick Comment: Skip, You seemed to have some interest in this the couple of times it came up on python-dev. I wonder if you might want to review this. No rush, I don't expect this to go in anytime soon. Unless, of course, people just *have* to have it. <wink> ------------------------------------------------------- Date: 2000-Aug-15 15:23 By: tim_one Comment: Sorry, but there is a rush! Since Python 2.0 is scheduled to have only 1 beta cycle, if this doesn't make it into the beta (< 2 weeks, according to the schedule), it's for 2.1 at best. It would be very good to have a start at this (no matter how simple) in place for 2.0. ------------------------------------------------------- Date: 2000-Aug-16 12:05 By: tmick Comment: re: delaying to 2.1: doesn't bother me much Should it now be "postponed", Tim? ------------------------------------------------------- Date: 2000-Aug-21 19:54 By: montanaro Comment: postponed until 2.1 ------------------------------------------------------- Date: 2000-Nov-27 07:47 By: gvanrossum Comment: Randomly reassigned for review now that 2.1 is open and Skip seems to be too busy to look at this. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101162&group_id=5470 From noreply@sourceforge.net Mon Jan 29 21:33:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 13:33:08 -0800 Subject: [Patches] [Patch #103485] _cursesmodule.c, AIX and NetBSD Message-ID: <E14NLvA-00005C-00@usw-sf-web1.sourceforge.net> Patch #103485 has been updated. Project: python Category: Modules Status: Open Submitted by: donnc Assigned to : akuchling Summary: _cursesmodule.c, AIX and NetBSD Follow-Ups: Date: 2001-Jan-29 13:33 By: donnc Comment: Checked out _cursesmodule.c compiles, links, and loads on NetBSD 1.5 and AIX 4.3.3. ------------------------------------------------------- Date: 2001-Jan-29 12:47 By: akuchling Comment: Checked in, with one modification. I removed the use of 'lines' as a variable name, so the #undef lines should now be unnecessary. Donn, please let me know if the current CVS now compiles cleanly for you on AIX and NetBSD. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103485&group_id=5470 From noreply@sourceforge.net Mon Jan 29 21:42:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 13:42:28 -0800 Subject: [Patches] [Patch #103485] _cursesmodule.c, AIX and NetBSD Message-ID: <E14NM4C-0004hO-00@usw-sf-web2.sourceforge.net> Patch #103485 has been updated. Project: python Category: Modules Status: Closed Submitted by: donnc Assigned to : akuchling Summary: _cursesmodule.c, AIX and NetBSD Follow-Ups: Date: 2001-Jan-29 13:42 By: akuchling Comment: Marking as closed. ------------------------------------------------------- Date: 2001-Jan-29 13:33 By: donnc Comment: Checked out _cursesmodule.c compiles, links, and loads on NetBSD 1.5 and AIX 4.3.3. ------------------------------------------------------- Date: 2001-Jan-29 12:47 By: akuchling Comment: Checked in, with one modification. I removed the use of 'lines' as a variable name, so the #undef lines should now be unnecessary. Donn, please let me know if the current CVS now compiles cleanly for you on AIX and NetBSD. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103485&group_id=5470 From noreply@sourceforge.net Mon Jan 29 22:19:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 14:19:21 -0800 Subject: [Patches] [Patch #103487] BeOS build scripts, setup.py Message-ID: <E14NMdt-0000cC-00@usw-sf-web1.sourceforge.net> Patch #103487 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : nobody Summary: BeOS build scripts, setup.py ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103487&group_id=5470 From noreply@sourceforge.net Mon Jan 29 22:23:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 14:23:56 -0800 Subject: [Patches] [Patch #103477] BeOS build scripts, setup.py Message-ID: <E14NMiK-0000f5-00@usw-sf-web1.sourceforge.net> Patch #103477 has been updated. Project: python Category: None Status: Open Submitted by: donnc Assigned to : nobody Summary: BeOS build scripts, setup.py Follow-Ups: Date: 2001-Jan-29 14:23 By: donnc Comment: Please close this one and use 103487 instead, which has a couple of bug fixes discovered when I built it on AIX. (Tried "upload revised patch" here, couldn't make it work.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103477&group_id=5470 From noreply@sourceforge.net Mon Jan 29 22:26:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 14:26:08 -0800 Subject: [Patches] [Patch #103477] BeOS build scripts, setup.py Message-ID: <E14NMkS-00053t-00@usw-sf-web2.sourceforge.net> Patch #103477 has been updated. Project: python Category: None Status: Closed Submitted by: donnc Assigned to : nobody Summary: BeOS build scripts, setup.py Follow-Ups: Date: 2001-Jan-29 14:23 By: donnc Comment: Please close this one and use 103487 instead, which has a couple of bug fixes discovered when I built it on AIX. (Tried "upload revised patch" here, couldn't make it work.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103477&group_id=5470 From noreply@sourceforge.net Mon Jan 29 23:47:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 15:47:30 -0800 Subject: [Patches] [Patch #103441] an inline syntax for function attributes Message-ID: <E14NO1C-0001SM-00@usw-sf-web1.sourceforge.net> Patch #103441 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: mwh Assigned to : gvanrossum Summary: an inline syntax for function attributes Follow-Ups: Date: 2001-Jan-29 15:47 By: gvanrossum Comment: Cute, but I think this s too much innovation. :-) Let's stick to attribute assignment. I'll reject the patch. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103441&group_id=5470 From noreply@sourceforge.net Mon Jan 29 23:51:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 15:51:25 -0800 Subject: [Patches] [Patch #103457] Fixed shadowing problem with cmpfunc in Mac OS X Message-ID: <E14NO4z-0001Uk-00@usw-sf-web1.sourceforge.net> Patch #103457 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: bquinlan Assigned to : gvanrossum Summary: Fixed shadowing problem with cmpfunc in Mac OS X Follow-Ups: Date: 2001-Jan-29 15:51 By: gvanrossum Comment: It's simple: cmpfunc is already a typedef, so that local was unfortunately named. I've fixed it. (Note; it's classobject.c, not complexobject.c! And please use diff -c, not ndiff to submit diffs next time.) ------------------------------------------------------- Date: 2001-Jan-27 13:10 By: bquinlan Comment: See bug #129827 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103457&group_id=5470 From noreply@sourceforge.net Mon Jan 29 23:52:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 15:52:01 -0800 Subject: [Patches] [Patch #103471] xml pretty-printing in minidom Message-ID: <E14NO5Z-0001Ux-00@usw-sf-web1.sourceforge.net> Patch #103471 has been updated. Project: python Category: library Status: Open Submitted by: isk Assigned to : loewis Summary: xml pretty-printing in minidom Follow-Ups: Date: 2001-Jan-29 15:52 By: gvanrossum Comment: Martin, are you taking care of minidom these days? If not, who is? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103471&group_id=5470 From noreply@sourceforge.net Mon Jan 29 23:53:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 15:53:17 -0800 Subject: [Patches] [Patch #103473] Cookie.py: Allow values containing '=' Message-ID: <E14NO6n-0001Vk-00@usw-sf-web1.sourceforge.net> Patch #103473 has been updated. Project: python Category: library Status: Open Submitted by: dougfort Assigned to : akuchling Summary: Cookie.py: Allow values containing '=' Follow-Ups: Date: 2001-Jan-29 15:53 By: gvanrossum Comment: Andrew, can you check this? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103473&group_id=5470 From noreply@sourceforge.net Mon Jan 29 23:53:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 15:53:32 -0800 Subject: [Patches] [Patch #103495] case sensitive import for case insensitive FileSystem Message-ID: <E14NO72-0004ee-00@usw-sf-web3.sourceforge.net> Patch #103495 has been updated. Project: python Category: core (C code) Status: Open Submitted by: sdm7g Assigned to : nobody Summary: case sensitive import for case insensitive FileSystem ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103495&group_id=5470 From noreply@sourceforge.net Mon Jan 29 23:53:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 15:53:38 -0800 Subject: [Patches] [Patch #103487] BeOS build scripts, setup.py Message-ID: <E14NO78-0001W1-00@usw-sf-web1.sourceforge.net> Patch #103487 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : akuchling Summary: BeOS build scripts, setup.py ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103487&group_id=5470 From noreply@sourceforge.net Mon Jan 29 23:53:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 15:53:48 -0800 Subject: [Patches] [Patch #103487] BeOS build scripts, setup.py Message-ID: <E14NO7I-0001W9-00@usw-sf-web1.sourceforge.net> Patch #103487 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : akuchling Summary: BeOS build scripts, setup.py ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103487&group_id=5470 From noreply@sourceforge.net Mon Jan 29 23:54:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 15:54:49 -0800 Subject: [Patches] [Patch #103478] Lib/test for BeOS Message-ID: <E14NO8H-0001We-00@usw-sf-web1.sourceforge.net> Patch #103478 has been updated. Project: python Category: library Status: Open Submitted by: donnc Assigned to : moshez Summary: Lib/test for BeOS Follow-Ups: Date: 2001-Jan-29 15:54 By: gvanrossum Comment: Randomly assigned to Moshe. (Nobody here has BeOS, so your only task is to ensure that thsi doesn't break on Linux.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103478&group_id=5470 From noreply@sourceforge.net Tue Jan 30 00:02:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 16:02:54 -0800 Subject: [Patches] [Patch #103457] Fixed shadowing problem with cmpfunc in Mac OS X Message-ID: <E14NOG6-0005qb-00@usw-sf-web2.sourceforge.net> Patch #103457 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: bquinlan Assigned to : gvanrossum Summary: Fixed shadowing problem with cmpfunc in Mac OS X Follow-Ups: Date: 2001-Jan-29 16:02 By: nobody Comment: OK, thanks. I would have thought giving a variable the same name as a typedef with global scope would have masked the typedef, not resulted in a syntax error (with a cryptic error message). I guess old versions of C didn't allow this? That is why I assumed that it was a preprocessor directive... ------------------------------------------------------- Date: 2001-Jan-29 15:51 By: gvanrossum Comment: It's simple: cmpfunc is already a typedef, so that local was unfortunately named. I've fixed it. (Note; it's classobject.c, not complexobject.c! And please use diff -c, not ndiff to submit diffs next time.) ------------------------------------------------------- Date: 2001-Jan-27 13:10 By: bquinlan Comment: See bug #129827 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103457&group_id=5470 From noreply@sourceforge.net Tue Jan 30 03:22:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 19:22:34 -0800 Subject: [Patches] [Patch #103395] Guido changed his mind! Quickly, add 'if key in dict'! Message-ID: <E14NRNK-0007KZ-00@usw-sf-web2.sourceforge.net> Patch #103395 has been updated. Project: python Category: core (C code) Status: Postponed Submitted by: twouters Assigned to : tim_one Summary: Guido changed his mind! Quickly, add 'if key in dict'! Follow-Ups: Date: 2001-Jan-29 19:22 By: tim_one Comment: Changed to Postponed since the issues blossomed, and there's no hope of resolving them before 2.1a2 (hence also before 2.2). Reassigned to me. ------------------------------------------------------- Date: 2001-Jan-27 23:18 By: tim_one Comment: Reviewed the code and tried it out. Boffo! It's Accepted as far as I'm concerned. Cute: the Cygwin "patch" program core dumped consistently when trying to apply the NEWS patch, so I didn't test that part <wink>. Assigned to Fred for final disposition, since Thomas noted doc questions in his comments. I'll add that, since the docs already explain has_key, nothing good can come of trying to explain "in" via different words; would be shorter and better to just say x in dict == dict.has_key(x) x not in dict == not dict.has_key(x) everywhere it comes up. ------------------------------------------------------- Date: 2001-Jan-27 21:53 By: tim_one Comment: Assigned to me while Guido is sleeping so he doesn't get a chance to change his mind. ------------------------------------------------------- Date: 2001-Jan-27 17:26 By: twouters Comment: Newer patch, avoids Misc/NEWS conflict, fixes oversight in dict_contains. ------------------------------------------------------- Date: 2001-Jan-24 01:05 By: tim_one Comment: There must be something in the air, besides email delays. I'll take your word for it that Guido changed his mind, but I was about to say +1 anyway! Now all we have to do is trick xreadlines into iterating over dicts <wink>. ------------------------------------------------------- Date: 2001-Jan-23 23:39 By: twouters Comment: Added testcases for dict and UserDict. ------------------------------------------------------- Date: 2001-Jan-23 23:20 By: twouters Comment: Add some docs (not guarded by a 'new in 2.1' statement, I don't know how to do that), NEWS item and support in UserDict.UserDict. Docs of has_key should probably also mention that 'if key in dict' does the same, but I'm not sure how to say that's new in Python 2.1. ------------------------------------------------------- Date: 2001-Jan-23 22:57 By: twouters Comment: There yah go, Guido. Does my being awakened by my loud and malicious partner (who needs to head to her office 4 hours before me) earn me yet another free and legally useless 2.1 alpha ? :-) Note: it's missing docs. Will add then once I figure out where to add them. Also haven't updated the std-lib yet, will do that next. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103395&group_id=5470 From noreply@sourceforge.net Tue Jan 30 03:23:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 19:23:37 -0800 Subject: [Patches] [Patch #103495] case sensitive import for case insensitive FileSystem Message-ID: <E14NROL-0007Kt-00@usw-sf-web2.sourceforge.net> Patch #103495 has been updated. Project: python Category: core (C code) Status: Open Submitted by: sdm7g Assigned to : gvanrossum Summary: case sensitive import for case insensitive FileSystem ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103495&group_id=5470 From noreply@sourceforge.net Tue Jan 30 03:37:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 19:37:11 -0800 Subject: [Patches] [Patch #103441] an inline syntax for function attributes Message-ID: <E14NRbT-0007RH-00@usw-sf-web2.sourceforge.net> Patch #103441 has been updated. Project: python Category: core (C code) Status: Rejected Submitted by: mwh Assigned to : nobody Summary: an inline syntax for function attributes Follow-Ups: Date: 2001-Jan-29 19:37 By: tim_one Comment: Guido said "rejected" but didn't. Fiddled fields accordingly. ------------------------------------------------------- Date: 2001-Jan-29 15:47 By: gvanrossum Comment: Cute, but I think this s too much innovation. :-) Let's stick to attribute assignment. I'll reject the patch. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103441&group_id=5470 From noreply@sourceforge.net Tue Jan 30 04:27:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 20:27:39 -0800 Subject: [Patches] [Patch #103495] case sensitive import for case insensitive FileSystem Message-ID: <E14NSOJ-0006jV-00@usw-sf-web3.sourceforge.net> Patch #103495 has been updated. Project: python Category: core (C code) Status: Open Submitted by: sdm7g Assigned to : gvanrossum Summary: case sensitive import for case insensitive FileSystem Follow-Ups: Date: 2001-Jan-29 20:27 By: sdm7g Comment: Oops! The previous patch crashes if the path is empty, which is the case for the current directory. Added a line to check for that and use "." instead on diropen. -- Steve M. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103495&group_id=5470 From noreply@sourceforge.net Tue Jan 30 04:30:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 20:30:19 -0800 Subject: [Patches] [Patch #103495] case sensitive import for case insensitive FileSystem Message-ID: <E14NSQt-0006kh-00@usw-sf-web3.sourceforge.net> Patch #103495 has been updated. Project: python Category: core (C code) Status: Open Submitted by: sdm7g Assigned to : gvanrossum Summary: case sensitive import for case insensitive FileSystem Follow-Ups: Date: 2001-Jan-29 20:30 By: sdm7g Comment: Oops! The previous patch crashes if the path is empty, which is the case for the current directory. Added a line to check for that and use "." instead on diropen. -- Steve M. ------------------------------------------------------- Date: 2001-Jan-29 20:27 By: sdm7g Comment: Oops! The previous patch crashes if the path is empty, which is the case for the current directory. Added a line to check for that and use "." instead on diropen. -- Steve M. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103495&group_id=5470 From noreply@sourceforge.net Tue Jan 30 06:29:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 22:29:24 -0800 Subject: [Patches] [Patch #103478] Lib/test for BeOS Message-ID: <E14NUI8-0007Zv-00@usw-sf-web3.sourceforge.net> Patch #103478 has been updated. Project: python Category: library Status: Accepted Submitted by: donnc Assigned to : gvanrossum Summary: Lib/test for BeOS Follow-Ups: Date: 2001-Jan-29 22:29 By: moshez Comment: I've never seen BeOS at a distance <wink>, but it doesn't break my Debian GNU/Linux (sid) build. Assigned to Guido, marked accepted. Guido, reassign to me if you want me to actually check it in. ------------------------------------------------------- Date: 2001-Jan-29 15:54 By: gvanrossum Comment: Randomly assigned to Moshe. (Nobody here has BeOS, so your only task is to ensure that thsi doesn't break on Linux.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103478&group_id=5470 From noreply@sourceforge.net Tue Jan 30 15:10:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 07:10:20 -0800 Subject: [Patches] [Patch #103478] Lib/test for BeOS Message-ID: <E14NcQG-0001Ss-00@usw-sf-web1.sourceforge.net> Patch #103478 has been updated. Project: python Category: library Status: Accepted Submitted by: donnc Assigned to : moshez Summary: Lib/test for BeOS Follow-Ups: Date: 2001-Jan-30 07:10 By: gvanrossum Comment: OK, check it in already! ------------------------------------------------------- Date: 2001-Jan-29 22:29 By: moshez Comment: I've never seen BeOS at a distance <wink>, but it doesn't break my Debian GNU/Linux (sid) build. Assigned to Guido, marked accepted. Guido, reassign to me if you want me to actually check it in. ------------------------------------------------------- Date: 2001-Jan-29 15:54 By: gvanrossum Comment: Randomly assigned to Moshe. (Nobody here has BeOS, so your only task is to ensure that thsi doesn't break on Linux.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103478&group_id=5470 From noreply@sourceforge.net Tue Jan 30 15:34:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 07:34:02 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14NcnC-0003C8-00@usw-sf-web3.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : gvanrossum Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-30 07:34 By: gvanrossum Comment: Grabbing this for code review (finally!) ------------------------------------------------------- Date: 2001-Jan-22 14:01 By: fdrake Comment: Removed the .clear() method from reference objects. Made proxy objects unhashable -- the semantics of hashing something that can mutate in fundamental ways is pretty painful; just don't use these as dictionary keys! Added strong warnings to the documentation that proxy semantics may change a bit before the final release that the weak dictionaries are unclear -- additional feedback is requested. These are not thread-safe. ------------------------------------------------------- Date: 2001-Jan-20 09:42 By: gvanrossum Comment: I think callbacks are needed to implement various forms of weak dicts: when the object is deleted, whatever's in the weak dict for it should be deleted as well. Even though we may not provide weak dicts in 2.1a1, we should still support writing them using what we *do* provide. IMHO (I still haven't had the time to read the PEP or Fred's code. :-( ) ------------------------------------------------------- Date: 2001-Jan-20 09:12 By: nascheme Comment: Why do weak references need callbacks? I see nothing in the PEP to justify this feature. If there is no good reason for them, I propose that the feature be removed for 2.1. Allowing callbacks may make it harder to implement weak references more efficiently later. ------------------------------------------------------- Date: 2001-Jan-18 16:03 By: loewis Comment: The patch looks ok in general, pending resolution of the issues on the PEP itself. Some nits: Integration with GC is still fuzzy. If an instance is GC collected and had a weak ref to it and the weak ref had a callback and the callback choses to resurrect the object, semantics is unclear. This is equivalent to the object having an __del__; the GC would normally *not* collect such objects, but put them into gc.garbage. Proposed resolution: it is a fatal error to resurrect an object in a weakref callback. Hashing: it appears that the hash of a weakref can change when the underlying object goes away. If the weakref is used as key in a dictionary, it appears to be impossible to get the key out of the dictionary after the underlying object is gone. Proposed resolution: a proxy weak ref should cache the hash of the underlying object after its hash function was called for the first time. Comparing: why is the return value of tp_compare -1 when try_3way_compare expects -2 on error? Shouldn't there be some exception set when the underlying object goes away? ------------------------------------------------------- Date: 2001-Jan-17 13:53 By: fdrake Comment: Ok, I tihnk this is it! http://starship.python.net/crew/fdrake/patches/weakref.patch-5 This patch fixes the compilation problems from the previoous patch related to the introduction of rich comparisons, and makes a change in the way new objects are initialized by PyObject_New() and PyObject_NEW() (and all their friends!) -- those functions now know to initialize the weak reference list to NULL for objects which support weak references. Without this change, more places in the code (especially extension modules) need to know more about initialization of weakly-referencable objects. For instance, the "cPickle" and "new" modules both can create instances without calling the code in classobject.c (using PyObject_New()), causing core dumps when such instances are deallocated if the weak-reference list for instances was not properly initialized. Since these modules (properly) tried to avoid call PyInstance_New(), core dumps ensued and the world fell apart. By moving the initialization of the weak reference list into the core object allocators, this problem is averted and extension code to construct new weakly referencable types is simplified. The documentation still needs work, and there are a few new entries for the Python/C API manual as well. A new constructor for instances, PyInstance_NewRaw(), will be added in a separate patch. ------------------------------------------------------- Date: 2001-Jan-17 11:58 By: nascheme Comment: The magic test is: ./python Lib/test/regrtest.py test_weakref test_new Try adding this patch: --- Modules/newmodule.c 2000/11/13 20:29:20 2.29 +++ Modules/newmodule.c 2001/01/17 19:55:46 @@ -24,6 +24,7 @@ Py_INCREF(dict); inst->in_class = (PyClassObject *)klass; inst->in_dict = dict; + inst->in_weakreflist = NULL; PyObject_GC_Init(inst); return (PyObject *)inst; } ------------------------------------------------------- Date: 2001-Jan-17 08:04 By: fdrake Comment: New version of the patch that's still broken but doesn't conflict with the rich comparisons changes: http://starship.python.net/crew/fdrake/patches/weakref.patch-4 ------------------------------------------------------- Date: 2001-Jan-16 21:35 By: fdrake Comment: Added a new (but broken!) version of the patch that fixes WeakDictionary.get() but doesn't interact properly with GC (appearantly) -- not usable as is: http://starship.python.net/crew/fdrake/patches/weakref.patch-3 Neil made the mistake of volunteering to look at the current problem, so assigning to him. (Thanks!) ------------------------------------------------------- Date: 2001-Jan-16 19:39 By: tim_one Comment: Just mentioning a general scenario in which weak keys are the bee's knees: sometimes you want to add attributes to objects dynamically, in ways the original class author(s -- may cut across many classes! even non-instance objects; or objects from extension modules that don't support setattr) never anticipated. Like maybe a German translation of the object's docstrings; or a list of JPEG contents referenced by a URLish object; or a table of usage statistics on methods and functions; etc. Then it's natural to use the conceptual attr name as the name of a dict instead, and write attr[object] = whatever instead of object.attr = whatever There's no point keeping the "whatever" around when the object goes away, but a regular dict makes the object and its "whatever" immortal. A dict with weak keys is exactly on-target. ------------------------------------------------------- Date: 2001-Jan-16 19:14 By: fdrake Comment: I'm not entirely sure why one would want weak keys rather than weak values, but I suspect it has to do with expectations of how the dict will be used in applications. I don't think it would be hard to support both flavors of dictionaries using the primitive reference objects. The constructor does not check that all incoming values are weak because that isn't required. It uses self.update() rather than self.data.update() to perform the inclusion, so any mapping that supports .keys() and .__getitem__() is sufficient. Some additional checking could be done to make sure that all added entries can be created before inserting any of them, offering more atomicity. .get() will be fixed in the next version of the patch; thanks! I've added GC support, but don't have it working quite right. I'm trying to isolate the failure now. ------------------------------------------------------- Date: 2001-Jan-12 14:36 By: loewis Comment: The weak dictionary data type needs more clarification in documentation and implementation. In java.util.WeakHashMap, they keys are weak, not the values (i.e. once the key is forgotten, the entry is cleared). In http://www.handshake.de/~dieter/weakdict.html, the values are weak, but it raises KeyErrors for entries that are collected. The initializer of a weak dict does not check the invariant (all values are weak). get() of a weakdict does not support an optional second parameter. weakref and friends need to participate in garbage collection, as the reference to the callback can create a cycle. ------------------------------------------------------- Date: 2001-Jan-12 11:27 By: fdrake Comment: Updated patch to also support proxy semantics using the same invalidation machinery as the basic weak reference type. The additional code is *heavily* borrowed from Neil Schemenauer. ------------------------------------------------------- Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Tue Jan 30 18:40:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 10:40:48 -0800 Subject: [Patches] [Patch #103478] Lib/test for BeOS Message-ID: <E14Nfhw-0005je-00@usw-sf-web2.sourceforge.net> Patch #103478 has been updated. Project: python Category: library Status: Accepted Submitted by: donnc Assigned to : moshez Summary: Lib/test for BeOS Follow-Ups: Date: 2001-Jan-30 10:40 By: moshez Comment: Checked in as test_fork1 1.8, test_popen 1.5 Or should I say, "checked it in already?" ------------------------------------------------------- Date: 2001-Jan-30 07:10 By: gvanrossum Comment: OK, check it in already! ------------------------------------------------------- Date: 2001-Jan-29 22:29 By: moshez Comment: I've never seen BeOS at a distance <wink>, but it doesn't break my Debian GNU/Linux (sid) build. Assigned to Guido, marked accepted. Guido, reassign to me if you want me to actually check it in. ------------------------------------------------------- Date: 2001-Jan-29 15:54 By: gvanrossum Comment: Randomly assigned to Moshe. (Nobody here has BeOS, so your only task is to ensure that thsi doesn't break on Linux.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103478&group_id=5470 From noreply@sourceforge.net Tue Jan 30 18:41:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 10:41:27 -0800 Subject: [Patches] [Patch #103478] Lib/test for BeOS Message-ID: <E14NfiZ-0005k3-00@usw-sf-web2.sourceforge.net> Patch #103478 has been updated. Project: python Category: library Status: Closed Submitted by: donnc Assigned to : moshez Summary: Lib/test for BeOS Follow-Ups: Date: 2001-Jan-30 10:40 By: moshez Comment: Checked in as test_fork1 1.8, test_popen 1.5 Or should I say, "checked it in already?" ------------------------------------------------------- Date: 2001-Jan-30 07:10 By: gvanrossum Comment: OK, check it in already! ------------------------------------------------------- Date: 2001-Jan-29 22:29 By: moshez Comment: I've never seen BeOS at a distance <wink>, but it doesn't break my Debian GNU/Linux (sid) build. Assigned to Guido, marked accepted. Guido, reassign to me if you want me to actually check it in. ------------------------------------------------------- Date: 2001-Jan-29 15:54 By: gvanrossum Comment: Randomly assigned to Moshe. (Nobody here has BeOS, so your only task is to ensure that thsi doesn't break on Linux.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103478&group_id=5470 From noreply@sourceforge.net Tue Jan 30 18:43:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 10:43:57 -0800 Subject: [Patches] [Patch #103511] robotparser.py: fix for top-level web names Message-ID: <E14Nfkz-0003sX-00@usw-sf-web1.sourceforge.net> Patch #103511 has been updated. Project: python Category: library Status: Open Submitted by: dcohen Assigned to : nobody Summary: robotparser.py: fix for top-level web names ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103511&group_id=5470 From noreply@sourceforge.net Tue Jan 30 18:59:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 10:59:33 -0800 Subject: [Patches] [Patch #103512] symtable['.noopt'] = None, should be = 0 Message-ID: <E14Ng05-00042p-00@usw-sf-web1.sourceforge.net> Patch #103512 has been updated. Project: python Category: core (C code) Status: Open Submitted by: donnc Assigned to : nobody Summary: symtable['.noopt'] = None, should be = 0 ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103512&group_id=5470 From noreply@sourceforge.net Tue Jan 30 20:00:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 12:00:48 -0800 Subject: [Patches] [Patch #103513] Canvas.py fixes Message-ID: <E14NgxM-0004mZ-00@usw-sf-web1.sourceforge.net> Patch #103513 has been updated. Project: python Category: Tkinter Status: Open Submitted by: mfx Assigned to : nobody Summary: Canvas.py fixes ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103513&group_id=5470 From noreply@sourceforge.net Tue Jan 30 20:21:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 12:21:45 -0800 Subject: [Patches] [Patch #103514] small speedup in Tkinter.Misc._bind Message-ID: <E14NhHd-00050G-00@usw-sf-web1.sourceforge.net> Patch #103514 has been updated. Project: python Category: Tkinter Status: Open Submitted by: mfx Assigned to : nobody Summary: small speedup in Tkinter.Misc._bind ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103514&group_id=5470 From noreply@sourceforge.net Tue Jan 30 20:46:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 12:46:07 -0800 Subject: [Patches] [Patch #103516] zipfile.py: use hex constants for magic numbers Message-ID: <E14NhfD-0005ls-00@usw-sf-web3.sourceforge.net> Patch #103516 has been updated. Project: python Category: library Status: Open Submitted by: mfx Assigned to : nobody Summary: zipfile.py: use hex constants for magic numbers ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103516&group_id=5470 From noreply@sourceforge.net Tue Jan 30 21:01:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 13:01:38 -0800 Subject: [Patches] [Patch #103517] ftplib.py: provide a default blocksize arg in storbinary Message-ID: <E14NhuE-0005tE-00@usw-sf-web3.sourceforge.net> Patch #103517 has been updated. Project: python Category: library Status: Open Submitted by: mfx Assigned to : nobody Summary: ftplib.py: provide a default blocksize arg in storbinary ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103517&group_id=5470 From noreply@sourceforge.net Wed Jan 31 02:45:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 18:45:29 -0800 Subject: [Patches] [Patch #103512] symtable['.noopt'] = None, should be = 0 Message-ID: <E14NnGz-0000sD-00@usw-sf-web1.sourceforge.net> Patch #103512 has been updated. Project: python Category: core (C code) Status: Open Submitted by: donnc Assigned to : jhylton Summary: symtable['.noopt'] = None, should be = 0 Follow-Ups: Date: 2001-Jan-30 18:45 By: tim_one Comment: Assigned to Jeremy; sounds right to me! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103512&group_id=5470 From noreply@sourceforge.net Wed Jan 31 06:39:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 22:39:48 -0800 Subject: [Patches] [Patch #103511] robotparser.py: fix for top-level web names Message-ID: <E14Nqvk-0003Jj-00@usw-sf-web1.sourceforge.net> Patch #103511 has been updated. Project: python Category: library Status: Open Submitted by: dcohen Assigned to : montanaro Summary: robotparser.py: fix for top-level web names Follow-Ups: Date: 2001-Jan-30 22:39 By: montanaro Comment: Assigned to me. Looks pretty straightforward (so he says)... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103511&group_id=5470 From noreply@sourceforge.net Wed Jan 31 07:51:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 23:51:00 -0800 Subject: [Patches] [Patch #103523] mpz module doesn't build under cygwni Message-ID: <E14Ns2e-00039D-00@usw-sf-web2.sourceforge.net> Patch #103523 has been updated. Project: python Category: Modules Status: Open Submitted by: nobody Assigned to : nobody Summary: mpz module doesn't build under cygwni ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103523&group_id=5470 From noreply@sourceforge.net Wed Jan 31 08:24:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jan 2001 00:24:21 -0800 Subject: [Patches] [Patch #103523] mpz module doesn't build under cygwni Message-ID: <E14NsYv-0002Qm-00@usw-sf-web3.sourceforge.net> Patch #103523 has been updated. Project: python Category: Modules Status: Open Submitted by: nobody Assigned to : akuchling Summary: mpz module doesn't build under cygwni Follow-Ups: Date: 2001-Jan-31 00:24 By: tim_one Comment: Assigned to Andrew, because I'm hallucinating he may know more about mpz than the rest of us. Andrew, if you approve of this change, please make it, but on *all* platforms (i.e., do what the patch is getting at but don't apply the patch as-is -- there's no need to clutter the code with #ifdefs here). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103523&group_id=5470 From noreply@sourceforge.net Wed Jan 31 22:14:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jan 2001 14:14:05 -0800 Subject: [Patches] [Patch #103476] Two Lib/mailbox.py fixes Message-ID: <E14O5Vt-00085m-00@usw-sf-web1.sourceforge.net> Patch #103476 has been updated. Project: python Category: library Status: Closed Submitted by: bwarsaw Assigned to : bwarsaw Summary: Two Lib/mailbox.py fixes Follow-Ups: Date: 2001-Jan-31 14:14 By: bwarsaw Comment: Applying for Python 2.1a2. ------------------------------------------------------- Date: 2001-Jan-31 13:58 By: bwarsaw Comment: I changed my mind on this. For better backwards compatibility, I'm going to leave UnixMailbox doing the strict checking, and add a PortableUnixMailbox class which does the more general From_ line check. ------------------------------------------------------- Date: 2001-Jan-31 13:27 By: bwarsaw Comment: Good idea about the StrictUnixMailbox subclass. I'll add this, update NEWS and check it in. ------------------------------------------------------- Date: 2001-Jan-28 23:37 By: twouters Comment: Looks okay to me. I'm not sure if I'm "fine" with the idea of matching from_lines without a preceding blank line, but I also don't want to invest the time to rewrite the module to even allow that, so I can't expect anyone else to :) From-lineiness and the quoting of such differs greatly between mailers :P I *think* this will work for 99.9% of the mailboxes out there (since I know it works for Pine, Mutt, Nutscape and Eudorka (which uses an aditional file for message state, though)) but I'm still a bit wary of forcing people in the last promille to subclass and fiddle with internals themselves. Why not provide a StrictMailbox class that does it for them ? Don't forget Misc/NEWS, Barry. If I was supposed to mark it Accepted, consider it marked Accepted :) ------------------------------------------------------- Date: 2001-Jan-28 21:48 By: bwarsaw Comment: Assigned to Thomas for sanity checking. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103476&group_id=5470 From noreply@sourceforge.net Wed Jan 31 21:58:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jan 2001 13:58:51 -0800 Subject: [Patches] [Patch #103476] Two Lib/mailbox.py fixes Message-ID: <E14O5H9-0007zD-00@usw-sf-web1.sourceforge.net> Patch #103476 has been updated. Project: python Category: library Status: Accepted Submitted by: bwarsaw Assigned to : bwarsaw Summary: Two Lib/mailbox.py fixes Follow-Ups: Date: 2001-Jan-31 13:58 By: bwarsaw Comment: I changed my mind on this. For better backwards compatibility, I'm going to leave UnixMailbox doing the strict checking, and add a PortableUnixMailbox class which does the more general From_ line check. ------------------------------------------------------- Date: 2001-Jan-31 13:27 By: bwarsaw Comment: Good idea about the StrictUnixMailbox subclass. I'll add this, update NEWS and check it in. ------------------------------------------------------- Date: 2001-Jan-28 23:37 By: twouters Comment: Looks okay to me. I'm not sure if I'm "fine" with the idea of matching from_lines without a preceding blank line, but I also don't want to invest the time to rewrite the module to even allow that, so I can't expect anyone else to :) From-lineiness and the quoting of such differs greatly between mailers :P I *think* this will work for 99.9% of the mailboxes out there (since I know it works for Pine, Mutt, Nutscape and Eudorka (which uses an aditional file for message state, though)) but I'm still a bit wary of forcing people in the last promille to subclass and fiddle with internals themselves. Why not provide a StrictMailbox class that does it for them ? Don't forget Misc/NEWS, Barry. If I was supposed to mark it Accepted, consider it marked Accepted :) ------------------------------------------------------- Date: 2001-Jan-28 21:48 By: bwarsaw Comment: Assigned to Thomas for sanity checking. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103476&group_id=5470 From noreply@sourceforge.net Wed Jan 31 21:27:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jan 2001 13:27:16 -0800 Subject: [Patches] [Patch #103476] Two Lib/mailbox.py fixes Message-ID: <E14O4ma-0000ue-00@usw-sf-web2.sourceforge.net> Patch #103476 has been updated. Project: python Category: library Status: Accepted Submitted by: bwarsaw Assigned to : bwarsaw Summary: Two Lib/mailbox.py fixes Follow-Ups: Date: 2001-Jan-31 13:27 By: bwarsaw Comment: Good idea about the StrictUnixMailbox subclass. I'll add this, update NEWS and check it in. ------------------------------------------------------- Date: 2001-Jan-28 23:37 By: twouters Comment: Looks okay to me. I'm not sure if I'm "fine" with the idea of matching from_lines without a preceding blank line, but I also don't want to invest the time to rewrite the module to even allow that, so I can't expect anyone else to :) From-lineiness and the quoting of such differs greatly between mailers :P I *think* this will work for 99.9% of the mailboxes out there (since I know it works for Pine, Mutt, Nutscape and Eudorka (which uses an aditional file for message state, though)) but I'm still a bit wary of forcing people in the last promille to subclass and fiddle with internals themselves. Why not provide a StrictMailbox class that does it for them ? Don't forget Misc/NEWS, Barry. If I was supposed to mark it Accepted, consider it marked Accepted :) ------------------------------------------------------- Date: 2001-Jan-28 21:48 By: bwarsaw Comment: Assigned to Thomas for sanity checking. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103476&group_id=5470 From noreply@sourceforge.net Wed Jan 31 21:01:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jan 2001 13:01:28 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14O4Nc-0007gt-00@usw-sf-web1.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : tim_one Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-31 13:01 By: fdrake Comment: - The .islive() method has been removed. - .get() has been replaced with calling the reference. - Reference and proxy objects which have no callbacks are "shared"; new objects are not created for every requestor in this case. - The new() function has been renamed ref(), since there's no requirement that it return a new reference or proxy object. - Callback functions no longer receive the objects that are about to be finalized; the weak reference object or proxy that fired the callback is passed instead. Proxy objects still need support for rich comparisons. (PEP 205 has also been updated.) ------------------------------------------------------- Date: 2001-Jan-30 07:34 By: gvanrossum Comment: Grabbing this for code review (finally!) ------------------------------------------------------- Date: 2001-Jan-22 14:01 By: fdrake Comment: Removed the .clear() method from reference objects. Made proxy objects unhashable -- the semantics of hashing something that can mutate in fundamental ways is pretty painful; just don't use these as dictionary keys! Added strong warnings to the documentation that proxy semantics may change a bit before the final release that the weak dictionaries are unclear -- additional feedback is requested. These are not thread-safe. ------------------------------------------------------- Date: 2001-Jan-20 09:42 By: gvanrossum Comment: I think callbacks are needed to implement various forms of weak dicts: when the object is deleted, whatever's in the weak dict for it should be deleted as well. Even though we may not provide weak dicts in 2.1a1, we should still support writing them using what we *do* provide. IMHO (I still haven't had the time to read the PEP or Fred's code. :-( ) ------------------------------------------------------- Date: 2001-Jan-20 09:12 By: nascheme Comment: Why do weak references need callbacks? I see nothing in the PEP to justify this feature. If there is no good reason for them, I propose that the feature be removed for 2.1. Allowing callbacks may make it harder to implement weak references more efficiently later. ------------------------------------------------------- Date: 2001-Jan-18 16:03 By: loewis Comment: The patch looks ok in general, pending resolution of the issues on the PEP itself. Some nits: Integration with GC is still fuzzy. If an instance is GC collected and had a weak ref to it and the weak ref had a callback and the callback choses to resurrect the object, semantics is unclear. This is equivalent to the object having an __del__; the GC would normally *not* collect such objects, but put them into gc.garbage. Proposed resolution: it is a fatal error to resurrect an object in a weakref callback. Hashing: it appears that the hash of a weakref can change when the underlying object goes away. If the weakref is used as key in a dictionary, it appears to be impossible to get the key out of the dictionary after the underlying object is gone. Proposed resolution: a proxy weak ref should cache the hash of the underlying object after its hash function was called for the first time. Comparing: why is the return value of tp_compare -1 when try_3way_compare expects -2 on error? Shouldn't there be some exception set when the underlying object goes away? ------------------------------------------------------- Date: 2001-Jan-17 13:53 By: fdrake Comment: Ok, I tihnk this is it! http://starship.python.net/crew/fdrake/patches/weakref.patch-5 This patch fixes the compilation problems from the previoous patch related to the introduction of rich comparisons, and makes a change in the way new objects are initialized by PyObject_New() and PyObject_NEW() (and all their friends!) -- those functions now know to initialize the weak reference list to NULL for objects which support weak references. Without this change, more places in the code (especially extension modules) need to know more about initialization of weakly-referencable objects. For instance, the "cPickle" and "new" modules both can create instances without calling the code in classobject.c (using PyObject_New()), causing core dumps when such instances are deallocated if the weak-reference list for instances was not properly initialized. Since these modules (properly) tried to avoid call PyInstance_New(), core dumps ensued and the world fell apart. By moving the initialization of the weak reference list into the core object allocators, this problem is averted and extension code to construct new weakly referencable types is simplified. The documentation still needs work, and there are a few new entries for the Python/C API manual as well. A new constructor for instances, PyInstance_NewRaw(), will be added in a separate patch. ------------------------------------------------------- Date: 2001-Jan-17 11:58 By: nascheme Comment: The magic test is: ./python Lib/test/regrtest.py test_weakref test_new Try adding this patch: --- Modules/newmodule.c 2000/11/13 20:29:20 2.29 +++ Modules/newmodule.c 2001/01/17 19:55:46 @@ -24,6 +24,7 @@ Py_INCREF(dict); inst->in_class = (PyClassObject *)klass; inst->in_dict = dict; + inst->in_weakreflist = NULL; PyObject_GC_Init(inst); return (PyObject *)inst; } ------------------------------------------------------- Date: 2001-Jan-17 08:04 By: fdrake Comment: New version of the patch that's still broken but doesn't conflict with the rich comparisons changes: http://starship.python.net/crew/fdrake/patches/weakref.patch-4 ------------------------------------------------------- Date: 2001-Jan-16 21:35 By: fdrake Comment: Added a new (but broken!) version of the patch that fixes WeakDictionary.get() but doesn't interact properly with GC (appearantly) -- not usable as is: http://starship.python.net/crew/fdrake/patches/weakref.patch-3 Neil made the mistake of volunteering to look at the current problem, so assigning to him. (Thanks!) ------------------------------------------------------- Date: 2001-Jan-16 19:39 By: tim_one Comment: Just mentioning a general scenario in which weak keys are the bee's knees: sometimes you want to add attributes to objects dynamically, in ways the original class author(s -- may cut across many classes! even non-instance objects; or objects from extension modules that don't support setattr) never anticipated. Like maybe a German translation of the object's docstrings; or a list of JPEG contents referenced by a URLish object; or a table of usage statistics on methods and functions; etc. Then it's natural to use the conceptual attr name as the name of a dict instead, and write attr[object] = whatever instead of object.attr = whatever There's no point keeping the "whatever" around when the object goes away, but a regular dict makes the object and its "whatever" immortal. A dict with weak keys is exactly on-target. ------------------------------------------------------- Date: 2001-Jan-16 19:14 By: fdrake Comment: I'm not entirely sure why one would want weak keys rather than weak values, but I suspect it has to do with expectations of how the dict will be used in applications. I don't think it would be hard to support both flavors of dictionaries using the primitive reference objects. The constructor does not check that all incoming values are weak because that isn't required. It uses self.update() rather than self.data.update() to perform the inclusion, so any mapping that supports .keys() and .__getitem__() is sufficient. Some additional checking could be done to make sure that all added entries can be created before inserting any of them, offering more atomicity. .get() will be fixed in the next version of the patch; thanks! I've added GC support, but don't have it working quite right. I'm trying to isolate the failure now. ------------------------------------------------------- Date: 2001-Jan-12 14:36 By: loewis Comment: The weak dictionary data type needs more clarification in documentation and implementation. In java.util.WeakHashMap, they keys are weak, not the values (i.e. once the key is forgotten, the entry is cleared). In http://www.handshake.de/~dieter/weakdict.html, the values are weak, but it raises KeyErrors for entries that are collected. The initializer of a weak dict does not check the invariant (all values are weak). get() of a weakdict does not support an optional second parameter. weakref and friends need to participate in garbage collection, as the reference to the callback can create a cycle. ------------------------------------------------------- Date: 2001-Jan-12 11:27 By: fdrake Comment: Updated patch to also support proxy semantics using the same invalidation machinery as the basic weak reference type. The additional code is *heavily* borrowed from Neil Schemenauer. ------------------------------------------------------- Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Wed Jan 31 20:26:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jan 2001 12:26:46 -0800 Subject: [Patches] [Patch #103514] small speedup in Tkinter.Misc._bind Message-ID: <E14O3q2-0007Bp-00@usw-sf-web1.sourceforge.net> Patch #103514 has been updated. Project: python Category: Tkinter Status: Open Submitted by: mfx Assigned to : effbot Summary: small speedup in Tkinter.Misc._bind ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103514&group_id=5470 From noreply@sourceforge.net Wed Jan 31 20:26:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jan 2001 12:26:06 -0800 Subject: [Patches] [Patch #103513] Canvas.py fixes Message-ID: <E14O3pO-0007BW-00@usw-sf-web1.sourceforge.net> Patch #103513 has been updated. Project: python Category: Tkinter Status: Open Submitted by: mfx Assigned to : effbot Summary: Canvas.py fixes ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103513&group

From noreply@sourceforge.net Mon Jan 1 00:25:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 31 Dec 2000 16:25:55 -0800 Subject: [Patches] [Patch #101170] Prevent old extensions from crashing Message-ID: Patch #101170 has been updated. Project: python Category: Windows Status: Rejected Submitted by: chega Assigned to : nobody Summary: Prevent old extensions from crashing Follow-Ups: Date: 2000-Dec-31 16:25 By: tim_one Comment: Everyone agreed, so I Rejected it and unassigned it. ------------------------------------------------------- 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 Mon Jan 1 17:47:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Jan 2001 09:47:23 -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: 2001-Jan-01 09:47 By: gvanrossum Comment: I don't typically have the time to follow c.l.py anymore, so I wasn't aware of that. Would you mind pointing me to the discussion (a Deja.com URL would be dandy)? Your suggestion of rmLineTerm() for the method name suggests that you haven't done Python for very long either. Compare the other string method names. There's also the issue of why bother stripping \r and \r\n; if you're reading using f.readline(), these would already have been converted to \n. ------------------------------------------------------- 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 Mon Jan 1 17:57:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Jan 2001 09:57:17 -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 : gvanrossum 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 Mon Jan 1 17:59:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Jan 2001 09:59:21 -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: 2001-Jan-01 09:59 By: gvanrossum Comment: Bah. I don't like this one bit. More complexity for a little bit of extra speed. I'm keeping this open but expect to be closing it soon unless I hear a really good argument why more speed is really needed in this area. Down with code bloat and creeping featurism! ------------------------------------------------------- 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 Mon Jan 1 18:06:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Jan 2001 10:06:42 -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 : gvanrossum Summary: turtle.py has a minor bug. Follow-Ups: Date: 2001-Jan-01 10:06 By: gvanrossum Comment: Thanks, will fix. You may be the first user -- I've never seen feedback on it before. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103061&group_id=5470 From noreply@sourceforge.net Mon Jan 1 19:11:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Jan 2001 11:11:16 -0800 Subject: [Patches] [Patch #103061] turtle.py has a minor bug. Message-ID: Patch #103061 has been updated. Project: python Category: library Status: Closed Submitted by: nobody Assigned to : gvanrossum Summary: turtle.py has a minor bug. Follow-Ups: Date: 2001-Jan-01 11:11 By: gvanrossum Comment: Done. ------------------------------------------------------- Date: 2001-Jan-01 10:06 By: gvanrossum Comment: Thanks, will fix. You may be the first user -- I've never seen feedback on it before. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103061&group_id=5470 From noreply@sourceforge.net Mon Jan 1 21:38:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Jan 2001 13:38:16 -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 Mon Jan 1 21:42:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Jan 2001 13:42:32 -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 Mon Jan 1 21:44:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Jan 2001 13:44:51 -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: Open 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 Mon Jan 1 21:46:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Jan 2001 13:46:53 -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: 2001-Jan-01 13:46 By: loewis Comment: It is better to track the patch only under one patch ID, so I reopened the original patch, and close this one. I also had problems uploading the patch, so it hopefully stays at your side until it gets reviewed and integrated. ------------------------------------------------------- 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 Mon Jan 1 21:47:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Jan 2001 13:47:25 -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: Closed Submitted by: itojun Assigned to : fdrake Summary: IPv6 patch, against 2.0 CVS tree, Dec30-2000 Follow-Ups: Date: 2001-Jan-01 13:46 By: loewis Comment: It is better to track the patch only under one patch ID, so I reopened the original patch, and close this one. I also had problems uploading the patch, so it hopefully stays at your side until it gets reviewed and integrated. ------------------------------------------------------- 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 Mon Jan 1 22:15:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Jan 2001 14:15:37 -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: 2001-Jan-01 14:15 By: loewis Comment: As discussed on the mailing list, I put GvR as the copyright holder of this change. ------------------------------------------------------- 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 Mon Jan 1 22:18:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Jan 2001 14:18:52 -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: 2001-Jan-01 14:15 By: loewis Comment: As discussed on the mailing list, I put GvR as the copyright holder of this change. ------------------------------------------------------- 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 Mon Jan 1 22:20:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Jan 2001 14:20: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: 2001-Jan-01 14:15 By: loewis Comment: As discussed on the mailing list, I put GvR as the copyright holder of this change. ------------------------------------------------------- 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 Mon Jan 1 22:21:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Jan 2001 14:21:49 -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: 2001-Jan-01 14:15 By: loewis Comment: As discussed on the mailing list, I put GvR as the copyright holder of this change. ------------------------------------------------------- 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 Mon Jan 1 22:22:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Jan 2001 14:22:24 -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: 2001-Jan-01 14:15 By: loewis Comment: As discussed on the mailing list, I put GvR as the copyright holder of this change. ------------------------------------------------------- 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 Mon Jan 1 22:28:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Jan 2001 14:28:06 -0800 Subject: [Patches] [Patch #103067] Make interpreter recognize byte code files Message-ID: Patch #103067 has been updated. Project: python Category: core (C code) Status: Open Submitted by: loewis Assigned to : nobody Summary: Make interpreter recognize byte code files ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103067&group_id=5470 From noreply@sourceforge.net Tue Jan 2 15:59:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jan 2001 07:59:45 -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: Closed Submitted by: loewis Assigned to : nascheme Summary: Fix for 126345:Garbage collection for modules Follow-Ups: Date: 2001-Jan-02 07:59 By: nascheme Comment: Applied (moduleobject.c r2.31). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102939&group_id=5470 From noreply@sourceforge.net Tue Jan 2 16:30:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jan 2001 08:30:42 -0800 Subject: [Patches] [Patch #102878] More tests for coercion and comparison Message-ID: Patch #102878 has been updated. Project: python Category: library Status: Closed 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 Jan 2 17:02:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jan 2001 09:02:08 -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: 2001-Jan-02 09:02 By: tseaver Comment: Here is a testcase for the bug: import threading, StringIO from time import sleep from traceback import print_exc startEvent = threading.Event() quitEvent = threading.Event() SLEEP_INTERVAL = 0.2 class TempFileGreedy( threading.Thread ): """ """ error_count = 0 ok_count = 0 def run( self ): """ """ self.errors = StringIO.StringIO() startEvent.wait() while not quitEvent.isSet(): try: f = tempfile.TemporaryFile( "w+b" ) except: self.error_count = self.error_count + 1 print_exc( file=self.errors ) else: f.close() self.ok_count = self.ok_count + 1 sleep( SLEEP_INTERVAL ) if __name__ == '__main__': import sys if len( sys.argv ) > 1: sys.path.insert( 0, '.' ) import tempfile tempfile.gettempdir() # Do this now, to avoid spurious races later NUM_THREADS = 100 threads = [] print "Creating" for i in range( NUM_THREADS ): t = TempFileGreedy() threads.append( t ) t.start() RUN_INTERVAL = 200.0 print "Starting" startEvent.set() sleep( RUN_INTERVAL ) quitEvent.set() print "Reaping" ok = errors = 0 for thread in threads: thread.join() ok = ok + thread.ok_count errors = errors + thread.error_count if thread.error_count: print '%s errors:\n%s' % ( thread.getName() , thread.errors.getvalue() ) print "Done" print 'OK: %d\nErrors: %d' % ( ok, errors ) ------------------------------------------------------- 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 Wed Jan 3 14:02:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jan 2001 06:02:58 -0800 Subject: [Patches] [Patch #103081] Speed up for fileinput, using readlines(sizehint) Message-ID: Patch #103081 has been updated. Project: python Category: library Status: Open Submitted by: gvanrossum Assigned to : nobody Summary: Speed up for fileinput, using readlines(sizehint) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103081&group_id=5470 From noreply@sourceforge.net Wed Jan 3 14:08:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jan 2001 06:08:49 -0800 Subject: [Patches] [Patch #103067] Make interpreter recognize byte code files Message-ID: Patch #103067 has been updated. Project: python Category: core (C code) Status: Open Submitted by: loewis Assigned to : nobody Summary: Make interpreter recognize byte code files Follow-Ups: Date: 2001-Jan-03 06:08 By: gvanrossum Comment: I like this. But why check only half the magic number? Also, why not integrate this into PyRun_SimpleFileEx()? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103067&group_id=5470 From noreply@sourceforge.net Wed Jan 3 14:09:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jan 2001 06:09:22 -0800 Subject: [Patches] [Patch #103012] Update fpectlmodule for current glibc Message-ID: Patch #103012 has been updated. Project: python Category: Modules Status: Accepted Submitted by: akuchling Assigned to : nobody Summary: Update fpectlmodule for current glibc Follow-Ups: Date: 2001-Jan-03 06:09 By: gvanrossum Comment: Go for it. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103012&group_id=5470 From noreply@sourceforge.net Wed Jan 3 14:09:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jan 2001 06:09:46 -0800 Subject: [Patches] [Patch #103012] Update fpectlmodule for current glibc Message-ID: Patch #103012 has been updated. Project: python Category: Modules Status: Accepted Submitted by: akuchling Assigned to : akuchling Summary: Update fpectlmodule for current glibc Follow-Ups: Date: 2001-Jan-03 06:09 By: gvanrossum Comment: Go for it. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103012&group_id=5470 From noreply@sourceforge.net Wed Jan 3 14:10:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jan 2001 06:10:40 -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: 2001-Jan-03 06:10 By: gvanrossum Comment: Neil, this has now status Accepted. Go ahead and check it in! ------------------------------------------------------- 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 Wed Jan 3 14:14:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jan 2001 06:14:17 -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 : gvanrossum Summary: BaseServer class for SocketServer.py (inh. by TCPServer) Follow-Ups: Date: 2001-Jan-03 06:14 By: gvanrossum Comment: I like this idea. I noticed that you added a copyright statement to the file. Referring to http://mail.python.org/pipermail/python-dev/2001-January/011250.html I believe that it's better not to add explicit copyright statements, because the licensing conditions are unclear in that case. I'd be happy if you included an "Author:" statement instead. ------------------------------------------------------- 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 Wed Jan 3 16:47:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jan 2001 08:47:30 -0800 Subject: [Patches] [Patch #103082] speed up readline() using getc_unlocked() Message-ID: Patch #103082 has been updated. Project: python Category: core (C code) Status: Open Submitted by: gvanrossum Assigned to : nobody Summary: speed up readline() using getc_unlocked() ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103082&group_id=5470 From noreply@sourceforge.net Wed Jan 3 19:58:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jan 2001 11:58:12 -0800 Subject: [Patches] [Patch #103067] Make interpreter recognize byte code files Message-ID: Patch #103067 has been updated. Project: python Category: core (C code) Status: Open Submitted by: loewis Assigned to : nobody Summary: Make interpreter recognize byte code files Follow-Ups: Date: 2001-Jan-03 11:58 By: loewis Comment: If the file was opened in text mode, \r\n may come out as a variety of byte sequences from fread(), so I can trust fread only to get the first two bytes right. If the file was incorrectly identified as pyc, then run_pyc_file will still report an error. I took it out of PyRun_SimpleFileEx for readability, since indentation was going way beyond column 80 when it was inline. It would be no problem to move it back into the function. ------------------------------------------------------- Date: 2001-Jan-03 06:08 By: gvanrossum Comment: I like this. But why check only half the magic number? Also, why not integrate this into PyRun_SimpleFileEx()? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103067&group_id=5470 From noreply@sourceforge.net Wed Jan 3 21:05:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jan 2001 13:05:44 -0800 Subject: [Patches] [Patch #103082] speed up readline() using getc_unlocked() Message-ID: Patch #103082 has been updated. Project: python Category: core (C code) Status: Open Submitted by: gvanrossum Assigned to : nobody Summary: speed up readline() using getc_unlocked() Follow-Ups: Date: 2001-Jan-03 13:05 By: akuchling Comment: On Solaris 2.6, getc_unlocked() and friends are present, but not detected by the configure script. config.log reports: configure:5957: checking for flockfile configure:5985: gcc -o conftest -g -O2 conftest.c -lpthread -lsocket -lnsl -ldl -lthread 1>&5 configure:5969: conflicting types for `flockfile' /usr/include/stdio.h:311: previous declaration of `flockfile' configure: failed program was: #line 5962 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char flockfile(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char flockfile(); int main() { ... rest deleted For getc_unlocked, config.log contains: configure:5957: checking for getc_unlocked configure:5985: gcc -o conftest -g -O2 conftest.c -lpthread -lsocket -lnsl -l l -lthread 1>&5 configure:5969: macro `getc_unlocked' used without args configure:5979: macro `getc_unlocked' used without args configure: failed program was: #line 5962 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char getc_unlocked(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char getc_unlocked(); int main() { ... rest deleted Python still compiles, but obviously you gain no benefit from it. Do we need to write custom autoconf tests for these functions? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103082&group_id=5470 From noreply@sourceforge.net Wed Jan 3 21:27:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jan 2001 13:27:43 -0800 Subject: [Patches] [Patch #103082] speed up readline() using getc_unlocked() Message-ID: Patch #103082 has been updated. Project: python Category: core (C code) Status: Open Submitted by: gvanrossum Assigned to : nobody Summary: speed up readline() using getc_unlocked() Follow-Ups: Date: 2001-Jan-03 13:27 By: gvanrossum Comment: Thanks for the feedback. Here's a version with a custom autoconf test. Note: YOU MUST RUN BOTH AUTOCONF AND AUTOHEADER (and then ./configure of course). Let me know if this works on Solaris! ------------------------------------------------------- Date: 2001-Jan-03 13:05 By: akuchling Comment: On Solaris 2.6, getc_unlocked() and friends are present, but not detected by the configure script. config.log reports: configure:5957: checking for flockfile configure:5985: gcc -o conftest -g -O2 conftest.c -lpthread -lsocket -lnsl -ldl -lthread 1>&5 configure:5969: conflicting types for `flockfile' /usr/include/stdio.h:311: previous declaration of `flockfile' configure: failed program was: #line 5962 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char flockfile(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char flockfile(); int main() { ... rest deleted For getc_unlocked, config.log contains: configure:5957: checking for getc_unlocked configure:5985: gcc -o conftest -g -O2 conftest.c -lpthread -lsocket -lnsl -l l -lthread 1>&5 configure:5969: macro `getc_unlocked' used without args configure:5979: macro `getc_unlocked' used without args configure: failed program was: #line 5962 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char getc_unlocked(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char getc_unlocked(); int main() { ... rest deleted Python still compiles, but obviously you gain no benefit from it. Do we need to write custom autoconf tests for these functions? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103082&group_id=5470 From noreply@sourceforge.net Wed Jan 3 21:28:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jan 2001 13:28:15 -0800 Subject: [Patches] [Patch #103002] Fix for #116285: Properly raise UnicodeErrors Message-ID: Patch #103002 has been updated. Project: python Category: library Status: Closed Submitted by: loewis Assigned to : lemburg Summary: Fix for #116285: Properly raise UnicodeErrors Follow-Ups: Date: 2001-Jan-03 13:28 By: lemburg Comment: Slightly modified patch checked in. ------------------------------------------------------- Date: 2001-Jan-01 14:15 By: loewis Comment: As discussed on the mailing list, I put GvR as the copyright holder of this change. ------------------------------------------------------- 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 Wed Jan 3 21:35:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jan 2001 13:35:12 -0800 Subject: [Patches] [Patch #103082] speed up readline() using getc_unlocked() Message-ID: Patch #103082 has been updated. Project: python Category: core (C code) Status: Open Submitted by: gvanrossum Assigned to : nobody Summary: speed up readline() using getc_unlocked() Follow-Ups: Date: 2001-Jan-03 13:35 By: akuchling Comment: The revised version works correctly for me on both Solaris and Linux. ------------------------------------------------------- Date: 2001-Jan-03 13:27 By: gvanrossum Comment: Thanks for the feedback. Here's a version with a custom autoconf test. Note: YOU MUST RUN BOTH AUTOCONF AND AUTOHEADER (and then ./configure of course). Let me know if this works on Solaris! ------------------------------------------------------- Date: 2001-Jan-03 13:05 By: akuchling Comment: On Solaris 2.6, getc_unlocked() and friends are present, but not detected by the configure script. config.log reports: configure:5957: checking for flockfile configure:5985: gcc -o conftest -g -O2 conftest.c -lpthread -lsocket -lnsl -ldl -lthread 1>&5 configure:5969: conflicting types for `flockfile' /usr/include/stdio.h:311: previous declaration of `flockfile' configure: failed program was: #line 5962 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char flockfile(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char flockfile(); int main() { ... rest deleted For getc_unlocked, config.log contains: configure:5957: checking for getc_unlocked configure:5985: gcc -o conftest -g -O2 conftest.c -lpthread -lsocket -lnsl -l l -lthread 1>&5 configure:5969: macro `getc_unlocked' used without args configure:5979: macro `getc_unlocked' used without args configure: failed program was: #line 5962 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char getc_unlocked(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char getc_unlocked(); int main() { ... rest deleted Python still compiles, but obviously you gain no benefit from it. Do we need to write custom autoconf tests for these functions? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103082&group_id=5470 From noreply@sourceforge.net Thu Jan 4 01:01:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jan 2001 17:01:29 -0800 Subject: [Patches] [Patch #103012] Update fpectlmodule for current glibc Message-ID: Patch #103012 has been updated. Project: python Category: Modules Status: Closed Submitted by: akuchling Assigned to : akuchling Summary: Update fpectlmodule for current glibc Follow-Ups: Date: 2001-Jan-03 17:01 By: akuchling Comment: Checked in. ------------------------------------------------------- Date: 2001-Jan-03 06:09 By: gvanrossum Comment: Go for it. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103012&group_id=5470 From noreply@sourceforge.net Thu Jan 4 02:00:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jan 2001 18:00:24 -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: Closed Submitted by: nascheme Assigned to : nascheme Summary: Reference implementation for PEP 208 (coercion) Follow-Ups: Date: 2001-Jan-03 18:00 By: nascheme Comment: A modified version of this patch has been committed. ------------------------------------------------------- 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 Thu Jan 4 14:05:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 06:05:27 -0800 Subject: [Patches] [Patch #102337] revised CALL_FUNCTION implementation Message-ID: Patch #102337 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jhylton Assigned to : jhylton Summary: revised CALL_FUNCTION implementation Follow-Ups: Date: 2001-Jan-04 06:05 By: jhylton Comment: revised version checked in ------------------------------------------------------- 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 Thu Jan 4 15:43:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 07:43:17 -0800 Subject: [Patches] [Patch #101313] New builtin function doc Message-ID: Patch #101313 has been updated. Project: python Category: library Status: Closed Submitted by: loewis Assigned to : jhylton Summary: New builtin function doc Follow-Ups: Date: 2001-Jan-04 07:43 By: gvanrossum Comment: Superseded by PEP 233 (Python Online Help). ------------------------------------------------------- Date: 2000-Aug-26 11:36 By: twouters Comment: Someone (Vladimir, I think ?) was working on a help() function, which was a docstring-prettyprinter as well as helpful in many other ways. I also think doc() should only be defined in interactive mode, but that's personal. ------------------------------------------------------- Date: 2000-Aug-27 02:13 By: moshez Comment: Assigned to Jeremy, so he can postpone it. It's definitely not-for-2.0 stuff. ------------------------------------------------------- Date: 2000-Aug-28 00:43 By: tim_one Comment: Postponed it as requested (why didn't you do that yourself?). Left assigned to Jeremy for post-2.0 resurrection. ------------------------------------------------------- Date: 2000-Nov-01 04:14 By: moshez Comment: I don't like the fact that it either returns a string or prints it. Furthermore, nobody needs the function to return a string in the builtins, IMHO. My suggestion: have a function doc_translate in gettext.py, which does the translation, and have doc in the builtins (exactly like you did it, laziness and all) which does, basically, print doc_translate(obj) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101313&group_id=5470 From noreply@sourceforge.net Thu Jan 4 15:44:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 07:44:32 -0800 Subject: [Patches] [Patch #101335] Adds login to auth-type servers (smtplib.py) Message-ID: Patch #101335 has been updated. Project: python Category: library Status: Open Submitted by: alexisjuh Assigned to : jhylton Summary: Adds login to auth-type servers (smtplib.py) Follow-Ups: Date: 2001-Jan-04 07:44 By: gvanrossum Comment: Jeremy, can you look at this again? ------------------------------------------------------- Date: 2000-Aug-29 02:22 By: moshez Comment: Postponed -- we're in feature freeze. Assigned to Jeremy in case he disagrees. Note also that it's preferable to submit patches in diff format, not as human-readable summaries. Try "diff -c". ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101335&group_id=5470 From noreply@sourceforge.net Thu Jan 4 15:46:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 07:46:12 -0800 Subject: [Patches] [Patch #101970] Allow urllib to support http: Message-ID: Patch #101970 has been updated. Project: python Category: library Status: Open Submitted by: prescod Assigned to : prescod Summary: Allow urllib to support http: Follow-Ups: Date: 2001-Jan-04 07:46 By: gvanrossum Comment: This patch should be rejected based on form. Paul, you can do better than sending in a diff without context! Also, the subject makes no sense. If you still want this, please fix the subject and submit a new patch and we'll lookj at it again. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101970&group_id=5470 From noreply@sourceforge.net Thu Jan 4 15:46:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 07:46:43 -0800 Subject: [Patches] [Patch #101973] test_import.py fails on Unix when run any but the local dir Message-ID: Patch #101973 has been updated. Project: python Category: library Status: Open Submitted by: tmick Assigned to : jhylton Summary: test_import.py fails on Unix when run any but the local dir Follow-Ups: Date: 2001-Jan-04 07:46 By: gvanrossum Comment: Wasn't this already fixed? ------------------------------------------------------- Date: 2000-Oct-18 16:40 By: tmick Comment: Make test_import.py pass when it is invoked as follows: > ./python Lib/test/test_import.py or > ./python Lib/test/regrtest.py test_import I.e. from any dir other that where test_import.py exists. The problem was that on Unix, if a relative path to a script is given on the command line, that path is added to sys.path and *not* the current directory. That is fine, except that test_import.py presumed that the current directory (in which @TESTFN.py is created) is on sys.path. Solution: Put the current working dir on sys.path. ------------------------------------------------------- Date: 2000-Oct-18 16:41 By: tmick Comment: TIm's checkin said that this was your module Jeremy so I am assigning to you for review. ------------------------------------------------------- Date: 2000-Oct-18 23:10 By: tmick Comment: a comment from Neil: I disagree. The test suite should not assume write access to the current directory. It should probably create a temparary directory using mktemp() or similar, add that to sys.path and create files there. Sorry about not using SF but I'm on a 14.4k modem. :( Neil ------------------------------------------------------- Date: 2000-Oct-18 23:19 By: tmick Comment: Yes, I guess I agree. Frankly *every* use of test_support.TESTFN in the test suite should be replaced with the use of tempfile.mktemp(). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101973&group_id=5470 From noreply@sourceforge.net Thu Jan 4 15:47:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 07:47:49 -0800 Subject: [Patches] [Patch #102453] Modified urlencode in urllib to accept more types Message-ID: Patch #102453 has been updated. Project: python Category: library Status: Open Submitted by: nobody Assigned to : jhylton Summary: Modified urlencode in urllib to accept more types Follow-Ups: Date: 2001-Jan-04 07:47 By: gvanrossum Comment: This is a reasonable idea. Jeremy, if you have a minute, can you review this? ------------------------------------------------------- Date: 2000-Nov-21 03:18 By: moshez Comment: It looks good, except for accepting tuples: that's, IMHO, unneeded featurism. If it is accepted, here are docs: (replace the current docs for urlencode by:) \begin{funcdesc}{urlencode}{data} Convert a list of 2-tuples or a dictionary (treated as a list of (key, value) 2-tuples) to a ``url-encoded'' string, suitable to pass to \function{urlopen()} above as the optional \var{data} argument. This is useful to pass a dictionary of form fields to a \code{POST} request. The resulting string is a series of \code{\var{key}=\var{value}} pairs separated by \character{\&} characters, where both \var{key} and \var{value} are quoted using \function{quote_plus()} above. \end{funcdesc} Assigning to Jeremy 'cause he seems the urllib guy ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102453&group_id=5470 From noreply@sourceforge.net Thu Jan 4 15:48:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 07:48:23 -0800 Subject: [Patches] [Patch #102698] Fix for StreamReader bug Message-ID: Patch #102698 has been updated. Project: python Category: library Status: Open Submitted by: akuchling Assigned to : lemburg Summary: Fix for StreamReader bug Follow-Ups: Date: 2001-Jan-04 07:48 By: gvanrossum Comment: Marc-Andre, would you mind checking this in? ------------------------------------------------------- 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 Jan 4 15:49:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 07:49:16 -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: 2001-Jan-04 07:49 By: gvanrossum Comment: Eric, please review this. shlex is your baby. If you don't have time, let us know, but don't just let this sit undealt-with. ------------------------------------------------------- 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 Thu Jan 4 15:51:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 07:51:33 -0800 Subject: [Patches] [Patch #102698] Fix for StreamReader bug Message-ID: Patch #102698 has been updated. Project: python Category: library Status: Closed Submitted by: akuchling Assigned to : lemburg Summary: Fix for StreamReader bug Follow-Ups: Date: 2001-Jan-04 07:51 By: akuchling Comment: Actually I checked it in back in December, but forgot to update the patch. Sorry! ------------------------------------------------------- Date: 2001-Jan-04 07:48 By: gvanrossum Comment: Marc-Andre, would you mind checking this in? ------------------------------------------------------- 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 Jan 4 15:51:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 07:51:50 -0800 Subject: [Patches] [Patch #101196] IPv6 patch against 2.0 CVS tree, as of 20001230 Message-ID: Patch #101196 has been updated. Project: python Category: core (C code) Status: Open Submitted by: itojun Assigned to : fdrake Summary: IPv6 patch against 2.0 CVS tree, as of 20001230 Follow-Ups: Date: 2001-Jan-04 07:51 By: gvanrossum Comment: A new patch is available. I've changed the subject accordingly. Due to upload size restrictions, the patch is now at http://www.itojun.org/diary/20001230/python-2.0-v6-20001230.diff.gz ------------------------------------------------------- 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 Thu Jan 4 15:53:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 07:53:49 -0800 Subject: [Patches] [Patch #101264] Attribute Doc-Strings (PEP 224) Message-ID: Patch #101264 has been updated. Project: python Category: core (C code) Status: Open Submitted by: lemburg Assigned to : lemburg Summary: Attribute Doc-Strings (PEP 224) Follow-Ups: Date: 2001-Jan-04 07:53 By: gvanrossum Comment: This is (poresumably) for PEP 224, which is marked as pie-in-the-sky and thus won't be considered for 2.1. Really, I should pronounce on that PEP (I don't like it very much but haven't found the right argument to reject it :-) so this patch can either go in be rejected. ------------------------------------------------------- Date: 2000-Aug-23 02:22 By: lemburg Comment: This patch implements the proposed addition of doc-strings for e.g. class attribute, module attributes, etc. See the upcoming PEP for details (the PEP was already submitted to the PEP editor for review). Here's a shot excerpt: class C: " class C doc-string " a = 1 " attribute C.a doc-string (1)" b = 2 " attribute C.b doc-string (2)" results in following new class attributes to be created: C.__doc__a__ == " attribute C.a doc-string (1)" C.__doc__b__ == " attribute C.b doc-string (2)" ------------------------------------------------------- Date: 2000-Aug-23 08:21 By: tim_one Comment: Postponed due to 2.0 feature freeze and assigned to the release manager for re-opening. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101264&group_id=5470 From noreply@sourceforge.net Thu Jan 4 15:56:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 07:56:41 -0800 Subject: [Patches] [Patch #101843] Remove all uses of "assert" from the test suite Message-ID: Patch #101843 has been updated. Project: python Category: core (C code) Status: Open Submitted by: lemburg Assigned to : lemburg Summary: Remove all uses of "assert" from the test suite Follow-Ups: Date: 2001-Jan-04 07:56 By: gvanrossum Comment: Marc-Andre, do you have time to rework this for the current CVS tree? I still like the idea a lot! Once you have a current patch it can be checked in within days. ------------------------------------------------------- Date: 2000-Oct-09 07:25 By: lemburg Comment: This patch removes all uses of the assert statement from the regression test suite. Use of assert in the suite is depreciated due to asserts being removed from the byte code when Python is run in optimized mode. The patch adds a new function to test_support (verify) which handles the asserts in a more customizable way. It does not rely on the assert statement. I have tested this patch lightly (meaning that the suite runs through just fine). Not all execution paths are testable due to the nature of the patch, though. Please review. ------------------------------------------------------- Date: 2000-Oct-09 12:26 By: gvanrossum Comment: Great! But let's do this post-2.0 final release. I'm really getting worried about patches that touch every file in a particular corner of the universe... :-( ------------------------------------------------------- Date: 2000-Oct-24 13:57 By: gvanrossum Comment: Would you mind resubmitting this? Some of the patches fail, probably because there were a lot of changes to the whitespace. The idea is still as valid as it was before. A style nit: please don't include spaces inside parentheses: please write verify(cond, reason) rather than verify( cond, reason ). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101843&group_id=5470 From noreply@sourceforge.net Thu Jan 4 17:17:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 09:17:21 -0800 Subject: [Patches] [Patch #101229] Optional memory profiler Message-ID: Patch #101229 has been updated. Project: python Category: core (C code) Status: Open Submitted by: marangoz Assigned to : jhylton Summary: Optional memory profiler Follow-Ups: Date: 2000-Aug-19 00:18 By: marangoz Comment: An optional memory profiler, which goes in tandem with the optional object memory allocator (SourceForge patch #101104). The profiler was introduced briefly on python-dev: http://www.python.org/pipermail/python-dev/2000-August/015239.html Applying both patches gives for me (screen dump): ~> patch -p1 < ../obmalloc-patch patching file `Include/objimpl.h' patching file `Objects/object.c' patching file `Objects/obmalloc.c' patching file `acconfig.h' patching file `configure.in' ~> patch -p1 < ../memprof-patch patching file `Include/pydebug.h' patching file `Modules/Setup.config.in' patching file `Modules/main.c' patching file `Modules/memprof.c' patching file `Python/pythonrun.c' patching file `acconfig.h' patching file `configure.in' - Don't forget that you need to autoheader; autoconf; This patch: 1) introduces a new --with-memprof configure option. Off by default. 2) introduced a Py_ProfileFlag and a "-p" Python option which starts the profiler in Py_Initialize() before any initializations, and stops it in Py_Finalize() after all finalizations. 3) contains a new Modules/memprof.c module. The inclusion of this file in the core is similar to the thread and GC modules (Setup.config.in) The patch *can* be applied without the object allocator and it *does* compile on request. However, it issues a warning that it won't profile anything, because it can't be called (the profiler can't install its hooks). Besides, it will refuse to start(). The point is that both the profiler and the allocator are really optional. Needs docs & tests :( The interface can be improved (just like everything else) but the core functionality is there. It *is* useful for getting snapshots of the minimum allocated (object) memory, at least. Some worthy points to condifer, IMO, are listed in the TODO of memprof.c. I am submitting this for testing, reviewing, comments and more ideas. Overall, I think it is a BIG plus regarding Python's typical introspection. Comments welcome. As usual, flames to /dev/null . Status set straight to Postponed. Assigned to marangoz who's in charge of opening it in due time, together with #101104. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101229&group_id=5470 From noreply@sourceforge.net Thu Jan 4 17:17:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 09:17:18 -0800 Subject: [Patches] [Patch #101104] Optional object mem allocator Message-ID: Patch #101104 has been updated. Project: python Category: core (C code) Status: Open Submitted by: marangoz Assigned to : jhylton Summary: Optional object mem allocator Follow-Ups: Date: 2000-Aug-06 21:05 By: marangoz Comment: A stab on obmalloc.c -- an optional object allocator. A configure "--with(out)-pymalloc" option is introduced for enabling specialized mallocs. Off by default. The code is included conditionally at the end of object.c obmalloc.c contains only the core malloc functionality. No profiling, nor debugging are there -- these would come as separate (and optional) modules: memprof.c & memdebug.c in the Modules/ directory and will exploit the hooks of the allocator. I've managed to draw a rather nice diagram in the comments at the top of obmalloc.c explaining what this stuff is all about. Look there. ------------------------------------------------------- Date: 2000-Aug-07 06:30 By: twouters Comment: Small nit: you shouldn't edit config.h.in yourself, it's autogenerated from acconfig.h and configure.in (with 'autoheader', part of 'autoconf.) You should define WITH_PYMALLOC in acconfig.h, not config.h.in, and run 'autoheader' and 'autoconf' to generate a new 'configure'. I'm in the process of testing this patch on Linux and BSDI, by the way :) ------------------------------------------------------- Date: 2000-Aug-07 09:19 By: marangoz Comment: Thanks. Fixed (acconfig.h) ------------------------------------------------------- Date: 2000-Aug-12 13:31 By: marangoz Comment: Status set to Postponed. Although promising, this hasn't enjoyed much user testing for the 2.0 time frame (partly because of the lack of an introspective Python interface which can't be completed in time according to the release schedule). Assigned to marangoz who's responsible to reopen it again in due time (except if BDFL decides otherwise). ------------------------------------------------------- Date: 2000-Aug-18 21:11 By: marangoz Comment: Update: (1) fixing a missing case for realloc(p,0) == free(p) + ret NULL (2) simplify the hooks interface: set_hooks/fetch_hooks are better than install/uninstall. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101104&group_id=5470 From noreply@sourceforge.net Thu Jan 4 17:24:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 09:24:08 -0800 Subject: [Patches] [Patch #102679] linuxaudiodev: better format names (and error messages) Message-ID: Patch #102679 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : fdrake 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 Thu Jan 4 17:24:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 09:24:52 -0800 Subject: [Patches] [Patch #102681] issubclass() and isinstance() error messages Message-ID: Patch #102681 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : gvanrossum 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 Thu Jan 4 17:43:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 09:43:35 -0800 Subject: [Patches] [Patch #102229] a better robotparser.py module Message-ID: Patch #102229 has been updated. Project: python Category: Modules Status: Open Submitted by: calvin Assigned to : gvanrossum Summary: a better robotparser.py module Follow-Ups: Date: 2000-Nov-02 09:40 By: calvin Comment: I have written a new RobotParser module 'robotparser2.py'. This module is o backward compatible with the old one o makes correct useragent matching (is buggy in robotparser.py) o strips comments correctly (is buggy in robotparser.py) o uses httplib instead of urllib.urlopen() to catch HTTP connect errors correctly (is buggy in robotparser.py) o implements not only the draft at http://info.webcrawler.com/mak/projects/robots/norobots.html but also the new one at http://info.webcrawler.com/mak/projects/robots/norobots-rfc.html Bastian Kleineidam ------------------------------------------------------- Date: 2000-Nov-02 11:14 By: gvanrossum Comment: Skip, can you comment on this? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102229&group_id=5470 From noreply@sourceforge.net Thu Jan 4 17:44:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 09:44:07 -0800 Subject: [Patches] [Patch #102498] imputil.py: uninstall method & import of .pyc-files Message-ID: Patch #102498 has been updated. Project: python Category: Modules Status: Open Submitted by: nobody Assigned to : gvanrossum Summary: imputil.py: uninstall method & import of .pyc-files ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102498&group_id=5470 From noreply@sourceforge.net Thu Jan 4 17:47:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 09:47:35 -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 : gvanrossum Summary: xreadlines : readlines :: xrange : range Follow-Ups: Date: 2001-Jan-01 09:59 By: gvanrossum Comment: Bah. I don't like this one bit. More complexity for a little bit of extra speed. I'm keeping this open but expect to be closing it soon unless I hear a really good argument why more speed is really needed in this area. Down with code bloat and creeping featurism! ------------------------------------------------------- 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 Thu Jan 4 17:50:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 09:50:43 -0800 Subject: [Patches] [Patch #103100] Multicharacter replacements in PyUnicode_TranslateCharmap Message-ID: Patch #103100 has been updated. Project: python Category: core (C code) Status: Open Submitted by: doerwalter Assigned to : nobody Summary: Multicharacter replacements in PyUnicode_TranslateCharmap ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103100&group_id=5470 From noreply@sourceforge.net Thu Jan 4 18:33:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 10:33:29 -0800 Subject: [Patches] [Patch #103100] Multicharacter replacements in PyUnicode_TranslateCharmap Message-ID: Patch #103100 has been updated. Project: python Category: core (C code) Status: Open Submitted by: doerwalter Assigned to : nobody Summary: Multicharacter replacements in PyUnicode_TranslateCharmap Follow-Ups: Date: 2001-Jan-04 10:33 By: nobody Comment: I like the idea, but the implementation needs some reworking: the common case is 1-1 mapping so this should be as fast as possible; extra size checks slow things down too much. You can take a different approach, though: leave things as they are and only add a special case for the 1-n which does resizing depending on how many extra chars are inserted. Then as final step, if resizing occurred, call _PyUnicode_Resize() to cut down the allocate buffer to its true size. -- Marc-Andre ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103100&group_id=5470 From noreply@sourceforge.net Thu Jan 4 19:09:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 11:09:49 -0800 Subject: [Patches] [Patch #103100] Multicharacter replacements in PyUnicode_TranslateCharmap Message-ID: Patch #103100 has been updated. Project: python Category: core (C code) Status: Open Submitted by: doerwalter Assigned to : lemburg Summary: Multicharacter replacements in PyUnicode_TranslateCharmap Follow-Ups: Date: 2001-Jan-04 10:33 By: nobody Comment: I like the idea, but the implementation needs some reworking: the common case is 1-1 mapping so this should be as fast as possible; extra size checks slow things down too much. You can take a different approach, though: leave things as they are and only add a special case for the 1-n which does resizing depending on how many extra chars are inserted. Then as final step, if resizing occurred, call _PyUnicode_Resize() to cut down the allocate buffer to its true size. -- Marc-Andre ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103100&group_id=5470 From noreply@sourceforge.net Thu Jan 4 19:11:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 11:11:59 -0800 Subject: [Patches] [Patch #101843] Remove all uses of "assert" from the test suite Message-ID: Patch #101843 has been updated. Project: python Category: core (C code) Status: Open Submitted by: lemburg Assigned to : lemburg Summary: Remove all uses of "assert" from the test suite Follow-Ups: Date: 2001-Jan-04 11:11 By: lemburg Comment: I can't promise much because as always in the last few months, I'm way too busy with other tasks... ------------------------------------------------------- Date: 2001-Jan-04 07:56 By: gvanrossum Comment: Marc-Andre, do you have time to rework this for the current CVS tree? I still like the idea a lot! Once you have a current patch it can be checked in within days. ------------------------------------------------------- Date: 2000-Oct-09 07:25 By: lemburg Comment: This patch removes all uses of the assert statement from the regression test suite. Use of assert in the suite is depreciated due to asserts being removed from the byte code when Python is run in optimized mode. The patch adds a new function to test_support (verify) which handles the asserts in a more customizable way. It does not rely on the assert statement. I have tested this patch lightly (meaning that the suite runs through just fine). Not all execution paths are testable due to the nature of the patch, though. Please review. ------------------------------------------------------- Date: 2000-Oct-09 12:26 By: gvanrossum Comment: Great! But let's do this post-2.0 final release. I'm really getting worried about patches that touch every file in a particular corner of the universe... :-( ------------------------------------------------------- Date: 2000-Oct-24 13:57 By: gvanrossum Comment: Would you mind resubmitting this? Some of the patches fail, probably because there were a lot of changes to the whitespace. The idea is still as valid as it was before. A style nit: please don't include spaces inside parentheses: please write verify(cond, reason) rather than verify( cond, reason ). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101843&group_id=5470 From noreply@sourceforge.net Thu Jan 4 19:31:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 11:31:49 -0800 Subject: [Patches] [Patch #102679] linuxaudiodev: better format names (and error messages) Message-ID: Patch #102679 has been updated. Project: python Category: Modules Status: Accepted Submitted by: ping Assigned to : ping Summary: linuxaudiodev: better format names (and error messages) Follow-Ups: Date: 2001-Jan-04 11:31 By: fdrake Comment: Looks good; please check this in. ------------------------------------------------------- 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 Thu Jan 4 19:43:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 11:43:49 -0800 Subject: [Patches] [Patch #101264] Attribute Doc-Strings (PEP 224) Message-ID: Patch #101264 has been updated. Project: python Category: core (C code) Status: Open Submitted by: lemburg Assigned to : lemburg Summary: Attribute Doc-Strings (PEP 224) Follow-Ups: Date: 2001-Jan-04 11:43 By: lemburg Comment: Perhaps we should rediscuss the PEP on python-dev ? I really have a strong need to add documentation to attributes in a way which is compatible with the existing __doc__ string facilities, so I'd appreciate feedback. ------------------------------------------------------- Date: 2001-Jan-04 07:53 By: gvanrossum Comment: This is (poresumably) for PEP 224, which is marked as pie-in-the-sky and thus won't be considered for 2.1. Really, I should pronounce on that PEP (I don't like it very much but haven't found the right argument to reject it :-) so this patch can either go in be rejected. ------------------------------------------------------- Date: 2000-Aug-23 02:22 By: lemburg Comment: This patch implements the proposed addition of doc-strings for e.g. class attribute, module attributes, etc. See the upcoming PEP for details (the PEP was already submitted to the PEP editor for review). Here's a shot excerpt: class C: " class C doc-string " a = 1 " attribute C.a doc-string (1)" b = 2 " attribute C.b doc-string (2)" results in following new class attributes to be created: C.__doc__a__ == " attribute C.a doc-string (1)" C.__doc__b__ == " attribute C.b doc-string (2)" ------------------------------------------------------- Date: 2000-Aug-23 08:21 By: tim_one Comment: Postponed due to 2.0 feature freeze and assigned to the release manager for re-opening. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101264&group_id=5470 From noreply@sourceforge.net Thu Jan 4 20:32:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 12:32:55 -0800 Subject: [Patches] [Patch #103067] Make interpreter recognize byte code files Message-ID: Patch #103067 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: loewis Assigned to : nobody Summary: Make interpreter recognize byte code files Follow-Ups: Date: 2001-Jan-04 12:32 By: loewis Comment: Committed slightly modified patch as 2.116 of pythonrun.c. ------------------------------------------------------- Date: 2001-Jan-03 11:58 By: loewis Comment: If the file was opened in text mode, \r\n may come out as a variety of byte sequences from fread(), so I can trust fread only to get the first two bytes right. If the file was incorrectly identified as pyc, then run_pyc_file will still report an error. I took it out of PyRun_SimpleFileEx for readability, since indentation was going way beyond column 80 when it was inline. It would be no problem to move it back into the function. ------------------------------------------------------- Date: 2001-Jan-03 06:08 By: gvanrossum Comment: I like this. But why check only half the magic number? Also, why not integrate this into PyRun_SimpleFileEx()? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103067&group_id=5470 From noreply@sourceforge.net Thu Jan 4 21:05:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 13:05:56 -0800 Subject: [Patches] [Patch #102229] a better robotparser.py module Message-ID: Patch #102229 has been updated. Project: python Category: Modules Status: Open Submitted by: calvin Assigned to : gvanrossum Summary: a better robotparser.py module Follow-Ups: Date: 2001-Jan-04 13:05 By: montanaro Comment: I apologize for taking so long to take a look at this. I was reminded of it when I saw the switch from me to Guido. I spent a little time fiddling with this module today. I'm not satisfied that it works as advertised. Here are a number of problems I found: * in the test function, the debug variable is not declared global, so setting it to 1 has no effect * it never seemed to properly handle redirections, so it never got from http://www.musi-cal.com/robots.txt to http://musi-cal.mojam.com/robots.txt * once I worked around the redirection problem it seemed to parse the Musi-Cal robots.txt file incorrectly. I replaced httplib with urllib in the read method and got erroneous results. If you look at the above robots.txt file you'll see that a bunch of email address harvesters are explicitly forbidden (not that they pay attention to robots.txt!). The following should print 0, but prints 1: print rp.can_fetch('ExtractorPro', 'http://musi-cal.mojam.com/') This is (at least in part) due to the fact that the redirection never works. In the version I modified to use urllib, it displays incorrect permissions for things like ExtractorPro: User-agent: ExtractorPro Allow: / Note that the lines in the robot.txt file for ExtractorPro are actually User-agent: ExtractorPro Disallow: / Skip ------------------------------------------------------- Date: 2000-Nov-02 09:40 By: calvin Comment: I have written a new RobotParser module 'robotparser2.py'. This module is o backward compatible with the old one o makes correct useragent matching (is buggy in robotparser.py) o strips comments correctly (is buggy in robotparser.py) o uses httplib instead of urllib.urlopen() to catch HTTP connect errors correctly (is buggy in robotparser.py) o implements not only the draft at http://info.webcrawler.com/mak/projects/robots/norobots.html but also the new one at http://info.webcrawler.com/mak/projects/robots/norobots-rfc.html Bastian Kleineidam ------------------------------------------------------- Date: 2000-Nov-02 11:14 By: gvanrossum Comment: Skip, can you comment on this? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102229&group_id=5470 From noreply@sourceforge.net Thu Jan 4 23:51:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 15:51:54 -0800 Subject: [Patches] [Patch #102229] a better robotparser.py module Message-ID: Patch #102229 has been updated. Project: python Category: Modules Status: Open Submitted by: calvin Assigned to : gvanrossum Summary: a better robotparser.py module Follow-Ups: Date: 2001-Jan-04 15:51 By: calvin Comment: Changes: - global debug variable in the test function - redirection now works - accidently printed "Allow" when I meant "Disallow". This has been fixed. It parses the Musi-Cal robots.txt file correctly, but the robots.txt file has syntax errors: before each user-agent: line there has to be one or more empty lines. ------------------------------------------------------- Date: 2001-Jan-04 13:05 By: montanaro Comment: I apologize for taking so long to take a look at this. I was reminded of it when I saw the switch from me to Guido. I spent a little time fiddling with this module today. I'm not satisfied that it works as advertised. Here are a number of problems I found: * in the test function, the debug variable is not declared global, so setting it to 1 has no effect * it never seemed to properly handle redirections, so it never got from http://www.musi-cal.com/robots.txt to http://musi-cal.mojam.com/robots.txt * once I worked around the redirection problem it seemed to parse the Musi-Cal robots.txt file incorrectly. I replaced httplib with urllib in the read method and got erroneous results. If you look at the above robots.txt file you'll see that a bunch of email address harvesters are explicitly forbidden (not that they pay attention to robots.txt!). The following should print 0, but prints 1: print rp.can_fetch('ExtractorPro', 'http://musi-cal.mojam.com/') This is (at least in part) due to the fact that the redirection never works. In the version I modified to use urllib, it displays incorrect permissions for things like ExtractorPro: User-agent: ExtractorPro Allow: / Note that the lines in the robot.txt file for ExtractorPro are actually User-agent: ExtractorPro Disallow: / Skip ------------------------------------------------------- Date: 2000-Nov-02 09:40 By: calvin Comment: I have written a new RobotParser module 'robotparser2.py'. This module is o backward compatible with the old one o makes correct useragent matching (is buggy in robotparser.py) o strips comments correctly (is buggy in robotparser.py) o uses httplib instead of urllib.urlopen() to catch HTTP connect errors correctly (is buggy in robotparser.py) o implements not only the draft at http://info.webcrawler.com/mak/projects/robots/norobots.html but also the new one at http://info.webcrawler.com/mak/projects/robots/norobots-rfc.html Bastian Kleineidam ------------------------------------------------------- Date: 2000-Nov-02 11:14 By: gvanrossum Comment: Skip, can you comment on this? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102229&group_id=5470 From noreply@sourceforge.net Fri Jan 5 01:37:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 17:37:25 -0800 Subject: [Patches] [Patch #102498] imputil.py: uninstall method & import of .pyc-files Message-ID: Patch #102498 has been updated. Project: python Category: Modules Status: Open Submitted by: nobody Assigned to : gvanrossum Summary: imputil.py: uninstall method & import of .pyc-files Follow-Ups: Date: 2001-Jan-04 17:37 By: gstein Comment: The uninstall seems fine, but conversations with Guido (a while back on python-dev) indicated that importing a .pyc without a corresponding .py were going to be "frowned upon". Thus, the second part of this patch (the .pyc importer) should be tossed. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102498&group_id=5470 From noreply@sourceforge.net Fri Jan 5 01:43:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 17:43:31 -0800 Subject: [Patches] [Patch #102229] a better robotparser.py module Message-ID: Patch #102229 has been updated. Project: python Category: Modules Status: Open Submitted by: calvin Assigned to : gvanrossum Summary: a better robotparser.py module Follow-Ups: Date: 2001-Jan-04 17:43 By: montanaro Comment: I fixed the robots.txt file, but I think you should parse files without the requisite blank lines (be lenient in what you accept and strict in what you generate). The user-agent line can serve as an implicit separator between one record and the next. Skip ------------------------------------------------------- Date: 2001-Jan-04 15:51 By: calvin Comment: Changes: - global debug variable in the test function - redirection now works - accidently printed "Allow" when I meant "Disallow". This has been fixed. It parses the Musi-Cal robots.txt file correctly, but the robots.txt file has syntax errors: before each user-agent: line there has to be one or more empty lines. ------------------------------------------------------- Date: 2001-Jan-04 13:05 By: montanaro Comment: I apologize for taking so long to take a look at this. I was reminded of it when I saw the switch from me to Guido. I spent a little time fiddling with this module today. I'm not satisfied that it works as advertised. Here are a number of problems I found: * in the test function, the debug variable is not declared global, so setting it to 1 has no effect * it never seemed to properly handle redirections, so it never got from http://www.musi-cal.com/robots.txt to http://musi-cal.mojam.com/robots.txt * once I worked around the redirection problem it seemed to parse the Musi-Cal robots.txt file incorrectly. I replaced httplib with urllib in the read method and got erroneous results. If you look at the above robots.txt file you'll see that a bunch of email address harvesters are explicitly forbidden (not that they pay attention to robots.txt!). The following should print 0, but prints 1: print rp.can_fetch('ExtractorPro', 'http://musi-cal.mojam.com/') This is (at least in part) due to the fact that the redirection never works. In the version I modified to use urllib, it displays incorrect permissions for things like ExtractorPro: User-agent: ExtractorPro Allow: / Note that the lines in the robot.txt file for ExtractorPro are actually User-agent: ExtractorPro Disallow: / Skip ------------------------------------------------------- Date: 2000-Nov-02 09:40 By: calvin Comment: I have written a new RobotParser module 'robotparser2.py'. This module is o backward compatible with the old one o makes correct useragent matching (is buggy in robotparser.py) o strips comments correctly (is buggy in robotparser.py) o uses httplib instead of urllib.urlopen() to catch HTTP connect errors correctly (is buggy in robotparser.py) o implements not only the draft at http://info.webcrawler.com/mak/projects/robots/norobots.html but also the new one at http://info.webcrawler.com/mak/projects/robots/norobots-rfc.html Bastian Kleineidam ------------------------------------------------------- Date: 2000-Nov-02 11:14 By: gvanrossum Comment: Skip, can you comment on this? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102229&group_id=5470 From noreply@sourceforge.net Fri Jan 5 02:30:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 18:30:18 -0800 Subject: [Patches] [Patch #102498] imputil.py: uninstall method & import of .pyc-files Message-ID: Patch #102498 has been updated. Project: python Category: Modules Status: Open Submitted by: nobody Assigned to : gstein Summary: imputil.py: uninstall method & import of .pyc-files Follow-Ups: Date: 2001-Jan-04 18:30 By: gvanrossum Comment: Thanks for looking at this, Greg. Can you work with the author on a suitable patch and check it in? ------------------------------------------------------- Date: 2001-Jan-04 17:37 By: gstein Comment: The uninstall seems fine, but conversations with Guido (a while back on python-dev) indicated that importing a .pyc without a corresponding .py were going to be "frowned upon". Thus, the second part of this patch (the .pyc importer) should be tossed. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102498&group_id=5470 From noreply@sourceforge.net Fri Jan 5 02:31:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 18:31:23 -0800 Subject: [Patches] [Patch #102229] a better robotparser.py module Message-ID: Patch #102229 has been updated. Project: python Category: Modules Status: Open Submitted by: calvin Assigned to : montanaro Summary: a better robotparser.py module Follow-Ups: Date: 2001-Jan-04 18:31 By: gvanrossum Comment: Skip, back to you. Please work with the author on an acceptable version. You can check it in once you two agree. ------------------------------------------------------- Date: 2001-Jan-04 17:43 By: montanaro Comment: I fixed the robots.txt file, but I think you should parse files without the requisite blank lines (be lenient in what you accept and strict in what you generate). The user-agent line can serve as an implicit separator between one record and the next. Skip ------------------------------------------------------- Date: 2001-Jan-04 15:51 By: calvin Comment: Changes: - global debug variable in the test function - redirection now works - accidently printed "Allow" when I meant "Disallow". This has been fixed. It parses the Musi-Cal robots.txt file correctly, but the robots.txt file has syntax errors: before each user-agent: line there has to be one or more empty lines. ------------------------------------------------------- Date: 2001-Jan-04 13:05 By: montanaro Comment: I apologize for taking so long to take a look at this. I was reminded of it when I saw the switch from me to Guido. I spent a little time fiddling with this module today. I'm not satisfied that it works as advertised. Here are a number of problems I found: * in the test function, the debug variable is not declared global, so setting it to 1 has no effect * it never seemed to properly handle redirections, so it never got from http://www.musi-cal.com/robots.txt to http://musi-cal.mojam.com/robots.txt * once I worked around the redirection problem it seemed to parse the Musi-Cal robots.txt file incorrectly. I replaced httplib with urllib in the read method and got erroneous results. If you look at the above robots.txt file you'll see that a bunch of email address harvesters are explicitly forbidden (not that they pay attention to robots.txt!). The following should print 0, but prints 1: print rp.can_fetch('ExtractorPro', 'http://musi-cal.mojam.com/') This is (at least in part) due to the fact that the redirection never works. In the version I modified to use urllib, it displays incorrect permissions for things like ExtractorPro: User-agent: ExtractorPro Allow: / Note that the lines in the robot.txt file for ExtractorPro are actually User-agent: ExtractorPro Disallow: / Skip ------------------------------------------------------- Date: 2000-Nov-02 09:40 By: calvin Comment: I have written a new RobotParser module 'robotparser2.py'. This module is o backward compatible with the old one o makes correct useragent matching (is buggy in robotparser.py) o strips comments correctly (is buggy in robotparser.py) o uses httplib instead of urllib.urlopen() to catch HTTP connect errors correctly (is buggy in robotparser.py) o implements not only the draft at http://info.webcrawler.com/mak/projects/robots/norobots.html but also the new one at http://info.webcrawler.com/mak/projects/robots/norobots-rfc.html Bastian Kleineidam ------------------------------------------------------- Date: 2000-Nov-02 11:14 By: gvanrossum Comment: Skip, can you comment on this? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102229&group_id=5470 From noreply@sourceforge.net Fri Jan 5 02:40:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 18:40:17 -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 : gvanrossum Summary: xreadlines : readlines :: xrange : range Follow-Ups: Date: 2001-Jan-04 18:40 By: gvanrossum Comment: After timing tests and discussion on python-dev I'm much more inclined to accept this. Jeff, would you mind adding docs? I don't care about adding an xreadlines method to other file-line objects, since the xreadlines module can be used directly by those who want to be generic. ------------------------------------------------------- Date: 2001-Jan-01 09:59 By: gvanrossum Comment: Bah. I don't like this one bit. More complexity for a little bit of extra speed. I'm keeping this open but expect to be closing it soon unless I hear a really good argument why more speed is really needed in this area. Down with code bloat and creeping featurism! ------------------------------------------------------- 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 Fri Jan 5 02:41:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 18:41:49 -0800 Subject: [Patches] [Patch #102681] issubclass() and isinstance() error messages Message-ID: Patch #102681 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : gvanrossum Summary: issubclass() and isinstance() error messages Follow-Ups: Date: 2001-Jan-04 18:41 By: gvanrossum Comment: Ping, please answer my question! ------------------------------------------------------- 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 Fri Jan 5 14:22:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Jan 2001 06:22:27 -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 : gvanrossum Summary: xreadlines : readlines :: xrange : range Follow-Ups: Date: 2001-Jan-05 06:22 By: jepler Comment: As requested by Guido, add a docstring and info in Doc/lib xreadlines-as-method of the builtin file object is retained, but is not added to any builtin file-like object. the speedup of the fileinput module is still present and appears to work, but I note there's no testsuite for the fileinput module. If there's any concern about the behavior of my modifications to fileinput, just ignore those changes. ------------------------------------------------------- Date: 2001-Jan-04 18:40 By: gvanrossum Comment: After timing tests and discussion on python-dev I'm much more inclined to accept this. Jeff, would you mind adding docs? I don't care about adding an xreadlines method to other file-line objects, since the xreadlines module can be used directly by those who want to be generic. ------------------------------------------------------- Date: 2001-Jan-01 09:59 By: gvanrossum Comment: Bah. I don't like this one bit. More complexity for a little bit of extra speed. I'm keeping this open but expect to be closing it soon unless I hear a really good argument why more speed is really needed in this area. Down with code bloat and creeping featurism! ------------------------------------------------------- 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 Fri Jan 5 14:47:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Jan 2001 06:47:10 -0800 Subject: [Patches] [Patch #103081] Speed up for fileinput, using readlines(sizehint) Message-ID: Patch #103081 has been updated. Project: python Category: library Status: Closed Submitted by: gvanrossum Assigned to : gvanrossum Summary: Speed up for fileinput, using readlines(sizehint) Follow-Ups: Date: 2001-Jan-05 06:47 By: gvanrossum Comment: Checked in. (The bufsize argument could be added to the docs, I suppose, but it really doesn't appear to make any difference, so there's no hurry.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103081&group_id=5470 From noreply@sourceforge.net Fri Jan 5 14:47:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Jan 2001 06:47:37 -0800 Subject: [Patches] [Patch #103082] speed up readline() using getc_unlocked() Message-ID: Patch #103082 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: gvanrossum Assigned to : gvanrossum Summary: speed up readline() using getc_unlocked() Follow-Ups: Date: 2001-Jan-05 06:47 By: gvanrossum Comment: Checked in. ------------------------------------------------------- Date: 2001-Jan-03 13:35 By: akuchling Comment: The revised version works correctly for me on both Solaris and Linux. ------------------------------------------------------- Date: 2001-Jan-03 13:27 By: gvanrossum Comment: Thanks for the feedback. Here's a version with a custom autoconf test. Note: YOU MUST RUN BOTH AUTOCONF AND AUTOHEADER (and then ./configure of course). Let me know if this works on Solaris! ------------------------------------------------------- Date: 2001-Jan-03 13:05 By: akuchling Comment: On Solaris 2.6, getc_unlocked() and friends are present, but not detected by the configure script. config.log reports: configure:5957: checking for flockfile configure:5985: gcc -o conftest -g -O2 conftest.c -lpthread -lsocket -lnsl -ldl -lthread 1>&5 configure:5969: conflicting types for `flockfile' /usr/include/stdio.h:311: previous declaration of `flockfile' configure: failed program was: #line 5962 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char flockfile(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char flockfile(); int main() { ... rest deleted For getc_unlocked, config.log contains: configure:5957: checking for getc_unlocked configure:5985: gcc -o conftest -g -O2 conftest.c -lpthread -lsocket -lnsl -l l -lthread 1>&5 configure:5969: macro `getc_unlocked' used without args configure:5979: macro `getc_unlocked' used without args configure: failed program was: #line 5962 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char getc_unlocked(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char getc_unlocked(); int main() { ... rest deleted Python still compiles, but obviously you gain no benefit from it. Do we need to write custom autoconf tests for these functions? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103082&group_id=5470 From noreply@sourceforge.net Fri Jan 5 16:06:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Jan 2001 08:06:46 -0800 Subject: [Patches] [Patch #101352] PyOS_StackCheck for Unix Message-ID: Patch #101352 has been updated. Project: python Category: core (C code) Status: Open Submitted by: loewis Assigned to : loewis Summary: PyOS_StackCheck for Unix Follow-Ups: Date: 2001-Jan-05 08:06 By: jhylton Comment: The current solution to stack limits for Unix is simpler, but probably good enough. Are you still interested in pursuing the approach in this patch? ------------------------------------------------------- Date: 2000-Aug-30 02:15 By: lemburg Comment: Since getrlimit() might not return useful results on all Unix platforms, I'd suggest adding a test to the configure script (the test should check whether getrlimit() returns a non-zero value for the stack limit). Also, due to the added call overhead, I'd suggest raising the modulo value in ceval's hook to call PyOS_CheckStack(): #ifdef USE_STACKCHECK if (tstate->recursion_depth%10 == 0 && PyOS_CheckStack()) { PyErr_SetString(PyExc_MemoryError, "Stack overflow"); return NULL; } #endif to about 100. That way the stack check will most likely only be triggered by programs which actually use recursion, rather than those which only use shallow function call nesting (10 seems to low w/r to these). ------------------------------------------------------- Date: 2000-Aug-30 05:31 By: loewis Comment: IMO, testing could be deferred until some system shows up that indeed returns zero. As for the frequency of the OS call, it may be useful to cache the result of getrlimit, on a per-thread basis. That won't catch changes done by the script itself, or from the outside, but if people do such things, they need to be careful, anyway. ------------------------------------------------------- Date: 2000-Aug-30 12:52 By: gvanrossum Comment: Given to Jeremy. We don't think we can get PyOS_CheckStack to work reliably and efficiently on Unix. Instead, we're going to make the recursion limit a user settable thing (sys.{set,get}recursionlimit) with a small default, e.g. 1000. ------------------------------------------------------- Date: 2000-Aug-30 18:33 By: jhylton Comment: Postponed, because it is sufficiently complex to fall subject to the feature freeze for 2.0b1. ------------------------------------------------------- Date: 2000-Nov-01 04:29 By: moshez Comment: Two things: 1) For GOD's sake, don't use #if inside #else: #elif makes a mess not worse then it has to be 2) I'm not sure this patch is very "honest": Py_Initialize() can be called from a call hierarchy either shallower or deaper then, say, Py_CallObject(..) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101352&group_id=5470 From noreply@sourceforge.net Fri Jan 5 16:12:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Jan 2001 08:12:04 -0800 Subject: [Patches] [Patch #101973] test_import.py fails on Unix when run any but the local dir Message-ID: Patch #101973 has been updated. Project: python Category: library Status: Closed Submitted by: tmick Assigned to : jhylton Summary: test_import.py fails on Unix when run any but the local dir Follow-Ups: Date: 2001-Jan-05 08:12 By: jhylton Comment: This was fixed by rev1.2 of test_import.py ------------------------------------------------------- Date: 2001-Jan-04 07:46 By: gvanrossum Comment: Wasn't this already fixed? ------------------------------------------------------- Date: 2000-Oct-18 16:40 By: tmick Comment: Make test_import.py pass when it is invoked as follows: > ./python Lib/test/test_import.py or > ./python Lib/test/regrtest.py test_import I.e. from any dir other that where test_import.py exists. The problem was that on Unix, if a relative path to a script is given on the command line, that path is added to sys.path and *not* the current directory. That is fine, except that test_import.py presumed that the current directory (in which @TESTFN.py is created) is on sys.path. Solution: Put the current working dir on sys.path. ------------------------------------------------------- Date: 2000-Oct-18 16:41 By: tmick Comment: TIm's checkin said that this was your module Jeremy so I am assigning to you for review. ------------------------------------------------------- Date: 2000-Oct-18 23:10 By: tmick Comment: a comment from Neil: I disagree. The test suite should not assume write access to the current directory. It should probably create a temparary directory using mktemp() or similar, add that to sys.path and create files there. Sorry about not using SF but I'm on a 14.4k modem. :( Neil ------------------------------------------------------- Date: 2000-Oct-18 23:19 By: tmick Comment: Yes, I guess I agree. Frankly *every* use of test_support.TESTFN in the test suite should be replaced with the use of tempfile.mktemp(). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101973&group_id=5470 From noreply@sourceforge.net Fri Jan 5 17:07:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Jan 2001 09:07:35 -0800 Subject: [Patches] [Patch #103100] Multicharacter replacements in PyUnicode_TranslateCharmap Message-ID: Patch #103100 has been updated. Project: python Category: core (C code) Status: Open Submitted by: doerwalter Assigned to : lemburg Summary: Multicharacter replacements in PyUnicode_TranslateCharmap Follow-Ups: Date: 2001-Jan-05 09:07 By: doerwalter Comment: The problem, that you can't know beforehand how long the result string will be, i.e. if there really will be any 1-n replacements happening. It would be possible to do a loop through the replacement strings and see if there are any that are longer than one character, but even if there are, you don't know if they will really be used. So you have three choices: (1) You either guess how much space you need and reallocate when the space is not enough or (2) you do a dry run of the algorithm once and count how much space you need and do the algorithm a second time and this time use the strings. (3) you can keep the strings in a list and join the list into one string in the end. For the case of 1-1 mapping the following will happen: (1) The first allocation has exactly the right amount of space, there won't be any reallocations, but a size check for every character will be don (which should be only a few assembler instructions). The mapping will have to be accessed for every character in the source string once. (2) There will only be one allocation, but for every character in the source string, the mapping has to be accessed twice, which are calls to Python function, exception handling etc. (3) You have to make as many memory allocations are are parts of the final string that you create, including error handling etc. I think (1) is clearly the fastest method. ------------------------------------------------------- Date: 2001-Jan-04 10:33 By: nobody Comment: I like the idea, but the implementation needs some reworking: the common case is 1-1 mapping so this should be as fast as possible; extra size checks slow things down too much. You can take a different approach, though: leave things as they are and only add a special case for the 1-n which does resizing depending on how many extra chars are inserted. Then as final step, if resizing occurred, call _PyUnicode_Resize() to cut down the allocate buffer to its true size. -- Marc-Andre ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103100&group_id=5470 From noreply@sourceforge.net Fri Jan 5 18:45:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Jan 2001 10:45:53 -0800 Subject: [Patches] [Patch #103100] Multicharacter replacements in PyUnicode_TranslateCharmap Message-ID: Patch #103100 has been updated. Project: python Category: core (C code) Status: Open Submitted by: doerwalter Assigned to : lemburg Summary: Multicharacter replacements in PyUnicode_TranslateCharmap Follow-Ups: Date: 2001-Jan-05 10:45 By: nobody Comment: I'll checkin a patch for this tomorrow which implements what I had in mind. The patch doesn't change the performance of the charmap codec. Thanks, -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-05 09:07 By: doerwalter Comment: The problem, that you can't know beforehand how long the result string will be, i.e. if there really will be any 1-n replacements happening. It would be possible to do a loop through the replacement strings and see if there are any that are longer than one character, but even if there are, you don't know if they will really be used. So you have three choices: (1) You either guess how much space you need and reallocate when the space is not enough or (2) you do a dry run of the algorithm once and count how much space you need and do the algorithm a second time and this time use the strings. (3) you can keep the strings in a list and join the list into one string in the end. For the case of 1-1 mapping the following will happen: (1) The first allocation has exactly the right amount of space, there won't be any reallocations, but a size check for every character will be don (which should be only a few assembler instructions). The mapping will have to be accessed for every character in the source string once. (2) There will only be one allocation, but for every character in the source string, the mapping has to be accessed twice, which are calls to Python function, exception handling etc. (3) You have to make as many memory allocations are are parts of the final string that you create, including error handling etc. I think (1) is clearly the fastest method. ------------------------------------------------------- Date: 2001-Jan-04 10:33 By: nobody Comment: I like the idea, but the implementation needs some reworking: the common case is 1-1 mapping so this should be as fast as possible; extra size checks slow things down too much. You can take a different approach, though: leave things as they are and only add a special case for the 1-n which does resizing depending on how many extra chars are inserted. Then as final step, if resizing occurred, call _PyUnicode_Resize() to cut down the allocate buffer to its true size. -- Marc-Andre ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103100&group_id=5470 From noreply@sourceforge.net Fri Jan 5 18:52:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Jan 2001 10:52:49 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: Patch #102409 has been updated. Project: python Category: Build Status: Open Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 >> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Fri Jan 5 21:20:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Jan 2001 13:20:09 -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: 2001-Jan-05 13:20 By: tim_one Comment: +1 on the idea, -1 on the patch. If PyModule_ExportableName is supposed to be a new part of the public API, we need docs for it; else it should be renamed (with a leading underscore). If it is part of the public API, it needs to sanity-check its arguments (e.g., at least that m and s aren't NULL -- we'll get a core dump now if they are); else it should at least assert that they're sane. Needs a test in any case. ------------------------------------------------------- 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 Sat Jan 6 05:40:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Jan 2001 21:40:19 -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: 2001-Jan-05 21:40 By: nobody Comment: Shouldn't it be called "__all__" (for consistency with a similar functionality in packages)? ------------------------------------------------------- Date: 2001-Jan-05 13:20 By: tim_one Comment: +1 on the idea, -1 on the patch. If PyModule_ExportableName is supposed to be a new part of the public API, we need docs for it; else it should be renamed (with a leading underscore). If it is part of the public API, it needs to sanity-check its arguments (e.g., at least that m and s aren't NULL -- we'll get a core dump now if they are); else it should at least assert that they're sane. Needs a test in any case. ------------------------------------------------------- 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 Sat Jan 6 06:45:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Jan 2001 22:45:13 -0800 Subject: [Patches] [Patch #103123] PEP 232 implementation (function attributes) Message-ID: Patch #103123 has been updated. Project: python Category: core (C code) Status: Open Submitted by: bwarsaw Assigned to : nobody Summary: PEP 232 implementation (function attributes) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103123&group_id=5470 From noreply@sourceforge.net Sat Jan 6 07:01:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Jan 2001 23:01:50 -0800 Subject: [Patches] [Patch #103123] PEP 232 implementation (function attributes) Message-ID: Patch #103123 has been updated. Project: python Category: core (C code) Status: Open Submitted by: bwarsaw Assigned to : gvanrossum Summary: PEP 232 implementation (function attributes) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103123&group_id=5470 From noreply@sourceforge.net Sat Jan 6 09:35:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 06 Jan 2001 01:35:05 -0800 Subject: [Patches] [Patch #101352] PyOS_StackCheck for Unix Message-ID: Patch #101352 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: loewis Assigned to : nobody Summary: PyOS_StackCheck for Unix Follow-Ups: Date: 2001-Jan-06 01:35 By: loewis Comment: I withdraw this patch, as it has been superceded by a different solution. ------------------------------------------------------- Date: 2001-Jan-05 08:06 By: jhylton Comment: The current solution to stack limits for Unix is simpler, but probably good enough. Are you still interested in pursuing the approach in this patch? ------------------------------------------------------- Date: 2000-Aug-30 02:15 By: lemburg Comment: Since getrlimit() might not return useful results on all Unix platforms, I'd suggest adding a test to the configure script (the test should check whether getrlimit() returns a non-zero value for the stack limit). Also, due to the added call overhead, I'd suggest raising the modulo value in ceval's hook to call PyOS_CheckStack(): #ifdef USE_STACKCHECK if (tstate->recursion_depth%10 == 0 && PyOS_CheckStack()) { PyErr_SetString(PyExc_MemoryError, "Stack overflow"); return NULL; } #endif to about 100. That way the stack check will most likely only be triggered by programs which actually use recursion, rather than those which only use shallow function call nesting (10 seems to low w/r to these). ------------------------------------------------------- Date: 2000-Aug-30 05:31 By: loewis Comment: IMO, testing could be deferred until some system shows up that indeed returns zero. As for the frequency of the OS call, it may be useful to cache the result of getrlimit, on a per-thread basis. That won't catch changes done by the script itself, or from the outside, but if people do such things, they need to be careful, anyway. ------------------------------------------------------- Date: 2000-Aug-30 12:52 By: gvanrossum Comment: Given to Jeremy. We don't think we can get PyOS_CheckStack to work reliably and efficiently on Unix. Instead, we're going to make the recursion limit a user settable thing (sys.{set,get}recursionlimit) with a small default, e.g. 1000. ------------------------------------------------------- Date: 2000-Aug-30 18:33 By: jhylton Comment: Postponed, because it is sufficiently complex to fall subject to the feature freeze for 2.0b1. ------------------------------------------------------- Date: 2000-Nov-01 04:29 By: moshez Comment: Two things: 1) For GOD's sake, don't use #if inside #else: #elif makes a mess not worse then it has to be 2) I'm not sure this patch is very "honest": Py_Initialize() can be called from a call hierarchy either shallower or deaper then, say, Py_CallObject(..) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101352&group_id=5470 From noreply@sourceforge.net Sat Jan 6 12:31:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 06 Jan 2001 04:31:29 -0800 Subject: [Patches] [Patch #102229] a better robotparser.py module Message-ID: Patch #102229 has been updated. Project: python Category: Modules Status: Open Submitted by: calvin Assigned to : montanaro Summary: a better robotparser.py module Follow-Ups: Date: 2001-Jan-06 04:31 By: calvin Comment: Ok, some new changes: - allow parsing of user-agent: lines without preceding blank line - two licenses available: Python 2.0 license or GPL license - add some doc string for the classes Bastian ------------------------------------------------------- Date: 2001-Jan-04 18:31 By: gvanrossum Comment: Skip, back to you. Please work with the author on an acceptable version. You can check it in once you two agree. ------------------------------------------------------- Date: 2001-Jan-04 17:43 By: montanaro Comment: I fixed the robots.txt file, but I think you should parse files without the requisite blank lines (be lenient in what you accept and strict in what you generate). The user-agent line can serve as an implicit separator between one record and the next. Skip ------------------------------------------------------- Date: 2001-Jan-04 15:51 By: calvin Comment: Changes: - global debug variable in the test function - redirection now works - accidently printed "Allow" when I meant "Disallow". This has been fixed. It parses the Musi-Cal robots.txt file correctly, but the robots.txt file has syntax errors: before each user-agent: line there has to be one or more empty lines. ------------------------------------------------------- Date: 2001-Jan-04 13:05 By: montanaro Comment: I apologize for taking so long to take a look at this. I was reminded of it when I saw the switch from me to Guido. I spent a little time fiddling with this module today. I'm not satisfied that it works as advertised. Here are a number of problems I found: * in the test function, the debug variable is not declared global, so setting it to 1 has no effect * it never seemed to properly handle redirections, so it never got from http://www.musi-cal.com/robots.txt to http://musi-cal.mojam.com/robots.txt * once I worked around the redirection problem it seemed to parse the Musi-Cal robots.txt file incorrectly. I replaced httplib with urllib in the read method and got erroneous results. If you look at the above robots.txt file you'll see that a bunch of email address harvesters are explicitly forbidden (not that they pay attention to robots.txt!). The following should print 0, but prints 1: print rp.can_fetch('ExtractorPro', 'http://musi-cal.mojam.com/') This is (at least in part) due to the fact that the redirection never works. In the version I modified to use urllib, it displays incorrect permissions for things like ExtractorPro: User-agent: ExtractorPro Allow: / Note that the lines in the robot.txt file for ExtractorPro are actually User-agent: ExtractorPro Disallow: / Skip ------------------------------------------------------- Date: 2000-Nov-02 09:40 By: calvin Comment: I have written a new RobotParser module 'robotparser2.py'. This module is o backward compatible with the old one o makes correct useragent matching (is buggy in robotparser.py) o strips comments correctly (is buggy in robotparser.py) o uses httplib instead of urllib.urlopen() to catch HTTP connect errors correctly (is buggy in robotparser.py) o implements not only the draft at http://info.webcrawler.com/mak/projects/robots/norobots.html but also the new one at http://info.webcrawler.com/mak/projects/robots/norobots-rfc.html Bastian Kleineidam ------------------------------------------------------- Date: 2000-Nov-02 11:14 By: gvanrossum Comment: Skip, can you comment on this? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102229&group_id=5470 From noreply@sourceforge.net Sat Jan 6 15:03:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 06 Jan 2001 07:03:25 -0800 Subject: [Patches] [Patch #103100] Multicharacter replacements in PyUnicode_TranslateCharmap Message-ID: Patch #103100 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: doerwalter Assigned to : lemburg Summary: Multicharacter replacements in PyUnicode_TranslateCharmap Follow-Ups: Date: 2001-Jan-06 07:03 By: lemburg Comment: Checked in a different patch providing the same functionality. Please see the CVS checking message for details. ------------------------------------------------------- Date: 2001-Jan-05 10:45 By: nobody Comment: I'll checkin a patch for this tomorrow which implements what I had in mind. The patch doesn't change the performance of the charmap codec. Thanks, -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-05 09:07 By: doerwalter Comment: The problem, that you can't know beforehand how long the result string will be, i.e. if there really will be any 1-n replacements happening. It would be possible to do a loop through the replacement strings and see if there are any that are longer than one character, but even if there are, you don't know if they will really be used. So you have three choices: (1) You either guess how much space you need and reallocate when the space is not enough or (2) you do a dry run of the algorithm once and count how much space you need and do the algorithm a second time and this time use the strings. (3) you can keep the strings in a list and join the list into one string in the end. For the case of 1-1 mapping the following will happen: (1) The first allocation has exactly the right amount of space, there won't be any reallocations, but a size check for every character will be don (which should be only a few assembler instructions). The mapping will have to be accessed for every character in the source string once. (2) There will only be one allocation, but for every character in the source string, the mapping has to be accessed twice, which are calls to Python function, exception handling etc. (3) You have to make as many memory allocations are are parts of the final string that you create, including error handling etc. I think (1) is clearly the fastest method. ------------------------------------------------------- Date: 2001-Jan-04 10:33 By: nobody Comment: I like the idea, but the implementation needs some reworking: the common case is 1-1 mapping so this should be as fast as possible; extra size checks slow things down too much. You can take a different approach, though: leave things as they are and only add a special case for the 1-n which does resizing depending on how many extra chars are inserted. Then as final step, if resizing occurred, call _PyUnicode_Resize() to cut down the allocate buffer to its true size. -- Marc-Andre ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103100&group_id=5470 From noreply@sourceforge.net Sat Jan 6 15:34:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 06 Jan 2001 07:34:17 -0800 Subject: [Patches] [Patch #103123] PEP 232 implementation (function attributes) Message-ID: Patch #103123 has been updated. Project: python Category: core (C code) Status: Open Submitted by: bwarsaw Assigned to : gvanrossum Summary: PEP 232 implementation (function attributes) Follow-Ups: Date: 2001-Jan-06 07:34 By: montanaro Comment: Quick nit in the doc: How about "functions written in Python" instead of "non-built-in functions"? - right at the start of the patch. Also, how about an example of what you are trying to avoid when you don't allow setting bound methods' attributes (besides the obvious fact that classes and instances already have their own attributes) class C: def meth(self): print "hi!" c = C() d = C() c.meth.attr = "my name is 'c'" d.meth.attr = "my name is 'd'" If bound method attribute setting was allowed, c.meth.attr return "my name is 'd'"... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103123&group_id=5470 From noreply@sourceforge.net Sat Jan 6 21:33:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 06 Jan 2001 13:33:24 -0800 Subject: [Patches] [Patch #103129] Avoid unsafe arithmetic in xrange object Message-ID: Patch #103129 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nobody Assigned to : nobody Summary: Avoid unsafe arithmetic in xrange object ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103129&group_id=5470 From noreply@sourceforge.net Sat Jan 6 21:39:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 06 Jan 2001 13:39:30 -0800 Subject: [Patches] [Patch #103129] Avoid unsafe arithmetic in xrange object Message-ID: Patch #103129 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nobody Assigned to : nobody Summary: Avoid unsafe arithmetic in xrange object Follow-Ups: Date: 2001-Jan-06 13:39 By: greg_ball Comment: Sorry, accidently posted as nobody, somehow my back button logged me out. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103129&group_id=5470 From noreply@sourceforge.net Sat Jan 6 21:51:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 06 Jan 2001 13:51:46 -0800 Subject: [Patches] [Patch #103129] Avoid unsafe arithmetic in xrange object Message-ID: Patch #103129 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nobody Assigned to : nobody Summary: Avoid unsafe arithmetic in xrange object Follow-Ups: Date: 2001-Jan-06 13:51 By: greg_ball Comment: The extra "period" attribute was only added for debugging! I would take it out again, if only the patch was under my name. ------------------------------------------------------- Date: 2001-Jan-06 13:39 By: greg_ball Comment: Sorry, accidently posted as nobody, somehow my back button logged me out. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103129&group_id=5470 From noreply@sourceforge.net Sun Jan 7 00:20:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 06 Jan 2001 16:20:39 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: Patch #102409 has been updated. Project: python Category: Build Status: Open Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 >> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Sun Jan 7 10:32:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 07 Jan 2001 02:32:40 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: Patch #102409 has been updated. Project: python Category: Build Status: Open Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 >> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Sun Jan 7 16:14:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 07 Jan 2001 08:14:18 -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: 2001-Jan-07 08:14 By: greg_ball Comment: How about an alternative syntax: assignment to module.__dict__ (currently not allowed.) # module foo.py constant_number=3 def bar(): print constant_number import foo foo.__dict__={'bar':bar} # end of module foo Now attribute access can get only the objects in the new dict. However if you really want to, you can access foo.bar.func_globals since functions defined in foo keep a reference to their oringinal namespace. (otherwise this proposal would just break everything...) ------------------------------------------------------- Date: 2001-Jan-05 21:40 By: nobody Comment: Shouldn't it be called "__all__" (for consistency with a similar functionality in packages)? ------------------------------------------------------- Date: 2001-Jan-05 13:20 By: tim_one Comment: +1 on the idea, -1 on the patch. If PyModule_ExportableName is supposed to be a new part of the public API, we need docs for it; else it should be renamed (with a leading underscore). If it is part of the public API, it needs to sanity-check its arguments (e.g., at least that m and s aren't NULL -- we'll get a core dump now if they are); else it should at least assert that they're sane. Needs a test in any case. ------------------------------------------------------- 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 Sun Jan 7 18:35:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 07 Jan 2001 10:35:39 -0800 Subject: [Patches] [Patch #103134] Support code execution in PTH files Message-ID: Patch #103134 has been updated. Project: python Category: library Status: Open Submitted by: loewis Assigned to : nobody Summary: Support code execution in PTH files ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103134&group_id=5470 From noreply@sourceforge.net Sun Jan 7 20:37:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 07 Jan 2001 12:37:25 -0800 Subject: [Patches] [Patch #103138] Install IDLE via distutils Message-ID: Patch #103138 has been updated. Project: python Category: IDLE Status: Open Submitted by: loewis Assigned to : nobody Summary: Install IDLE via distutils ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103138&group_id=5470 From noreply@sourceforge.net Sun Jan 7 22:32:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 07 Jan 2001 14:32:18 -0800 Subject: [Patches] [Patch #103129] Avoid unsafe arithmetic in xrange object Message-ID: Patch #103129 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nobody Assigned to : tim_one Summary: Avoid unsafe arithmetic in xrange object Follow-Ups: Date: 2001-Jan-06 13:51 By: greg_ball Comment: The extra "period" attribute was only added for debugging! I would take it out again, if only the patch was under my name. ------------------------------------------------------- Date: 2001-Jan-06 13:39 By: greg_ball Comment: Sorry, accidently posted as nobody, somehow my back button logged me out. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103129&group_id=5470 From noreply@sourceforge.net Sun Jan 7 22:36:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 07 Jan 2001 14:36:00 -0800 Subject: [Patches] [Patch #103134] Support code execution in PTH files Message-ID: Patch #103134 has been updated. Project: python Category: library Status: Open Submitted by: loewis Assigned to : gvanrossum Summary: Support code execution in PTH files Follow-Ups: Date: 2001-Jan-07 14:36 By: fdrake Comment: I think this is a good idea, but it's not clear that others will agree. Assigning to Guido since this is largely a matter of policy, and I'm not at all sure he'll like the idea. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103134&group_id=5470 From noreply@sourceforge.net Sun Jan 7 22:36:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 07 Jan 2001 14:36:36 -0800 Subject: [Patches] [Patch #103138] Install IDLE via distutils Message-ID: Patch #103138 has been updated. Project: python Category: IDLE Status: Open Submitted by: loewis Assigned to : akuchling Summary: Install IDLE via distutils ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103138&group_id=5470 From noreply@sourceforge.net Mon Jan 8 04:01:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 07 Jan 2001 20:01:13 -0800 Subject: [Patches] [Patch #102953] [Bug #125452 ] shlex.shlex hangs Message-ID: Patch #102953 has been updated. Project: python Category: library Status: Accepted Submitted by: akuchling Assigned to : esr Summary: [Bug #125452 ] shlex.shlex hangs Follow-Ups: Date: 2001-Jan-04 07:49 By: gvanrossum Comment: Eric, please review this. shlex is your baby. If you don't have time, let us know, but don't just let this sit undealt-with. ------------------------------------------------------- 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 Mon Jan 8 04:03:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 07 Jan 2001 20:03:07 -0800 Subject: [Patches] [Patch #103139] Autconfigure curses and readline into the default build Message-ID: Patch #103139 has been updated. Project: python Category: Build Status: Open Submitted by: esr Assigned to : nobody Summary: Autconfigure curses and readline into the default build ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103139&group_id=5470 From noreply@sourceforge.net Mon Jan 8 05:43:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 07 Jan 2001 21:43:23 -0800 Subject: [Patches] [Patch #103139] Autconfigure curses and readline into the default build Message-ID: Patch #103139 has been updated. Project: python Category: Build Status: Open Submitted by: esr Assigned to : nobody Summary: Autconfigure curses and readline into the default build Follow-Ups: Date: 2001-Jan-07 21:43 By: nascheme Comment: On Linux I think you should link to ncurses instead of curses and leave termcap out. Debian doesn't have termcap development libraries. Also, this patch only works on Linux. I think Andrew's distutil approach is a much better long term solution. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103139&group_id=5470 From noreply@sourceforge.net Mon Jan 8 05:53:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 07 Jan 2001 21:53:31 -0800 Subject: [Patches] [Patch #103129] Avoid unsafe arithmetic in xrange object Message-ID: Patch #103129 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nobody Assigned to : tim_one Summary: Avoid unsafe arithmetic in xrange object Follow-Ups: Date: 2001-Jan-07 21:53 By: tim_one Comment: Greg, why not submit the patch you want to submit under your own name? I'll take it, and delete this one. Note too that the "Details" section in this patch is utterly unreadable, due to lack of any linebreaks. I can assure you in any case that nobody gives a rip about how fast xrange multiplication works -- I'd be surprised if 1 Python programmer in 1000 even knew it was supported. ------------------------------------------------------- Date: 2001-Jan-06 13:51 By: greg_ball Comment: The extra "period" attribute was only added for debugging! I would take it out again, if only the patch was under my name. ------------------------------------------------------- Date: 2001-Jan-06 13:39 By: greg_ball Comment: Sorry, accidently posted as nobody, somehow my back button logged me out. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103129&group_id=5470 From noreply@sourceforge.net Mon Jan 8 07:20:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 07 Jan 2001 23:20:54 -0800 Subject: [Patches] [Patch #103140] Minor fixes and enhancements for 2.0 docs. Message-ID: Patch #103140 has been updated. Project: python Category: documentation Status: Open Submitted by: esr Assigned to : nobody Summary: Minor fixes and enhancements for 2.0 docs. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103140&group_id=5470 From noreply@sourceforge.net Mon Jan 8 21:37:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 08 Jan 2001 13:37:40 -0800 Subject: [Patches] [Patch #103147] restrict dir output in presence of __exports__ Message-ID: Patch #103147 has been updated. Project: python Category: core (C code) Status: Open Submitted by: montanaro Assigned to : nobody Summary: restrict dir output in presence of __exports__ ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103147&group_id=5470 From noreply@sourceforge.net Tue Jan 9 02:14:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 08 Jan 2001 18:14:46 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: Patch #102409 has been updated. Project: python Category: Build Status: Open Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 >> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Tue Jan 9 02:17:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 08 Jan 2001 18:17:24 -0800 Subject: [Patches] [Patch #103139] Autconfigure curses and readline into the default build Message-ID: Patch #103139 has been updated. Project: python Category: Build Status: Open Submitted by: esr Assigned to : esr Summary: Autconfigure curses and readline into the default build Follow-Ups: Date: 2001-Jan-08 18:17 By: gvanrossum Comment: Eric, there seems to be a discrepancy in the patch: the configure script tests for ncurses but the Setup.config.in file links with -lcurses. What gives? ------------------------------------------------------- Date: 2001-Jan-07 21:43 By: nascheme Comment: On Linux I think you should link to ncurses instead of curses and leave termcap out. Debian doesn't have termcap development libraries. Also, this patch only works on Linux. I think Andrew's distutil approach is a much better long term solution. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103139&group_id=5470 From noreply@sourceforge.net Tue Jan 9 02:19:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 08 Jan 2001 18:19:36 -0800 Subject: [Patches] [Patch #103140] Minor fixes and enhancements for 2.0 docs. Message-ID: Patch #103140 has been updated. Project: python Category: documentation Status: Open Submitted by: esr Assigned to : fdrake Summary: Minor fixes and enhancements for 2.0 docs. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103140&group_id=5470 From noreply@sourceforge.net Tue Jan 9 03:01:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 08 Jan 2001 19:01:28 -0800 Subject: [Patches] [Patch #102953] [Bug #125452 ] shlex.shlex hangs Message-ID: Patch #102953 has been updated. Project: python Category: library Status: Closed Submitted by: akuchling Assigned to : esr Summary: [Bug #125452 ] shlex.shlex hangs Follow-Ups: Date: 2001-Jan-08 19:01 By: akuchling Comment: Applied. ------------------------------------------------------- Date: 2001-Jan-04 07:49 By: gvanrossum Comment: Eric, please review this. shlex is your baby. If you don't have time, let us know, but don't just let this sit undealt-with. ------------------------------------------------------- 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 esr@thyrsus.com Tue Jan 9 03:01:20 2001 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 8 Jan 2001 22:01:20 -0500 Subject: [Patches] Re: [Patch #103139] Autconfigure curses and readline into the default build In-Reply-To: ; from noreply@sourceforge.net on Mon, Jan 08, 2001 at 06:17:24PM -0800 References: Message-ID: <20010108220120.A25754@thyrsus.com> noreply@sourceforge.net : > Date: 2001-Jan-08 18:17 > By: gvanrossum > > Eric, there seems to be a discrepancy in the patch: the configure script > tests for ncurses but the Setup.config.in file links with -lcurses. What > gives? This gives: rwxrwxrwx 1 root root 17 Dec 24 16:13 /usr/lib/libcurses.so -> libncurses.so.5.2 -rw-r--r-- 1 root root 405020 Nov 17 13:05 /usr/lib/libncurses.a lrwxrwxrwx 1 root root 15 Dec 24 16:13 /usr/lib/libncurses.so -> libncurses.so.5 lrwxrwxrwx 1 root root 17 Dec 24 16:13 /usr/lib/libncurses.so.4 -> libncurses.so.4.0 -rwxr-xr-x 1 root root 260664 Jul 12 2000 /usr/lib/libncurses.so.4.0 lrwxrwxrwx 1 root root 17 Dec 24 16:05 /usr/lib/libncurses.so.5 -> libncurses.so.5.2 -rwxr-xr-x 1 root root 257300 Nov 17 13:05 /usr/lib/libncurse The clever people who build the ncurses 5.2 spec file arranged for the curses library to be symlinked to the ncurses library. This is a new feature of RH 7.0., it definitely wasdn't that way in 6.2. On the whole it's a good idea, but it had the effect of making my "-lcurses" typo in Setup.config.in into a no-op. :-). That should read "-lncurses", and I apologize for not catching it before I shipped. > Date: 2001-Jan-07 21:43 > By: nascheme > > Comment: > On Linux I think you should link to ncurses instead of > curses and leave termcap out. Debian doesn't have termcap > development libraries. Also, this patch only works on > Linux. I think Andrew's distutil approach is a much better > long term solution. Maybe it is. Let's put this in until the long term gets here. -- Eric S. Raymond "Extremism in the defense of liberty is no vice; moderation in the pursuit of justice is no virtue." -- Barry Goldwater (actually written by Karl Hess) From noreply@sourceforge.net Tue Jan 9 03:16:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 08 Jan 2001 19:16:33 -0800 Subject: [Patches] [Patch #102971] build_ext -L typo fix Message-ID: Patch #102971 has been updated. Project: python Category: distutils Status: Accepted Submitted by: calvin Assigned to : gward Summary: build_ext -L typo fix Follow-Ups: Date: 2001-Jan-08 19:16 By: akuchling Comment: Checked in; leaving it in "Accepted" so Greg can review it (and possibly back it out) when he gets back. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102971&group_id=5470 From noreply@sourceforge.net Tue Jan 9 05:06:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 08 Jan 2001 21:06:15 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: Patch #103154 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jlt63 Assigned to : nobody Summary: Cygwin Check Import Case Patch ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Tue Jan 9 05:11:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 08 Jan 2001 21:11:46 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: Patch #103154 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jlt63 Assigned to : nobody Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Tue Jan 9 08:23:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Jan 2001 00:23:13 -0800 Subject: [Patches] [Patch #103155] avoid warning using modules thread and threading Message-ID: Patch #103155 has been updated. Project: python Category: Modules Status: Open Submitted by: bertram Assigned to : nobody Summary: avoid warning using modules thread and threading ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103155&group_id=5470 From noreply@sourceforge.net Tue Jan 9 13:50:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Jan 2001 05:50:13 -0800 Subject: [Patches] [Patch #103155] avoid warning using modules thread and threading Message-ID: Patch #103155 has been updated. Project: python Category: Modules Status: Closed Submitted by: bertram Assigned to : gvanrossum Summary: avoid warning using modules thread and threading Follow-Ups: Date: 2001-Jan-09 05:50 By: gvanrossum Comment: Thanks. This was already fixed in the current CVS tree. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103155&group_id=5470 From noreply@sourceforge.net Tue Jan 9 14:23:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Jan 2001 06:23:19 -0800 Subject: [Patches] [Patch #103158] Don't do unsafe arithmetic in xrange object Message-ID: Patch #103158 has been updated. Project: python Category: core (C code) Status: Open Submitted by: greg_ball Assigned to : nobody Summary: Don't do unsafe arithmetic in xrange object ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103158&group_id=5470 From noreply@sourceforge.net Tue Jan 9 14:31:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Jan 2001 06:31:25 -0800 Subject: [Patches] [Patch #103158] Don't do unsafe arithmetic in xrange object Message-ID: Patch #103158 has been updated. Project: python Category: core (C code) Status: Open Submitted by: greg_ball Assigned to : nobody Summary: Don't do unsafe arithmetic in xrange object Follow-Ups: Date: 2001-Jan-09 06:31 By: greg_ball Comment: This is a replacement for patch 103129, as suggested by tim_one. Possibly interesting aspects of the patch: - xrange objects with overflowing lengths are not gratutiously rejected. An error is raised only if the length becomes relevant, under len() or negative indexing. Bad lengths are stored as -1. Objects with bad lengths allow any non-negative integer index. - On 64 bit platforms, sequence multiplication seems to cause an unsafe cast from long to int. This patch does not address that issue. Without my patch, on i686 Linux: Python 2.0 (#25, Jan 2 2001, 12:18:07) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "", line 1, in ? SystemError: error return without exception set >>> y = xrange(maxint/2)*3 >>> len(y) -1073741827 >>> y[-1] Traceback (most recent call last): File "", line 1, in ? SystemError: error return without exception set >>> y.tolist() Traceback (most recent call last): File "", line 1, in ? SystemError: listobject.c:33: bad argument to internal function >>> m = maxint >> 16 >>> xrange(0,maxint,m) xrange(0, -2147450883, 32767) >>> (xrange(1)*maxint)*maxint xrange(1) >>> With my patch Python 2.0 (#35, Jan 6 2001, 12:54:41) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange object too long >>> y = xrange(maxint/2)*3 >>> len(y) Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange object too long >>> y.tolist() Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange object too long >>> m = maxint >> 16 >>> xrange(0,maxint,m) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> (xrange(1)*maxint) * maxint Traceback (most recent call last): File "", line 1, in ? OverflowError: integer multiplication >>> Without patch on Digital Unix Python 2.0 (#5, Jan 6 2001, 15:42:58) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "", line 1, in ? SystemError: error return without exception set >>> xrange(0,maxint,m) xrange(0, -9223372034707292163, 2147483647) >>> xrange(1)*maxint xrange(0) >>> With patch Python 2.0 (#7, Jan 6 2001, 15:52:21) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange object too long >>> xrange(0,maxint,m) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(1)*maxint xrange(0) >>> ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103158&group_id=5470 From noreply@sourceforge.net Tue Jan 9 21:51:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Jan 2001 13:51:18 -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 : fdrake Summary: xreadlines : readlines :: xrange : range Follow-Ups: Date: 2001-Jan-09 13:51 By: gvanrossum Comment: Assigned to Fred so he can check in the docs. Note: fileinput.py is *not* affected. ------------------------------------------------------- Date: 2001-Jan-05 06:22 By: jepler Comment: As requested by Guido, add a docstring and info in Doc/lib xreadlines-as-method of the builtin file object is retained, but is not added to any builtin file-like object. the speedup of the fileinput module is still present and appears to work, but I note there's no testsuite for the fileinput module. If there's any concern about the behavior of my modifications to fileinput, just ignore those changes. ------------------------------------------------------- Date: 2001-Jan-04 18:40 By: gvanrossum Comment: After timing tests and discussion on python-dev I'm much more inclined to accept this. Jeff, would you mind adding docs? I don't care about adding an xreadlines method to other file-line objects, since the xreadlines module can be used directly by those who want to be generic. ------------------------------------------------------- Date: 2001-Jan-01 09:59 By: gvanrossum Comment: Bah. I don't like this one bit. More complexity for a little bit of extra speed. I'm keeping this open but expect to be closing it soon unless I hear a really good argument why more speed is really needed in this area. Down with code bloat and creeping featurism! ------------------------------------------------------- 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 Tue Jan 9 21:54:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Jan 2001 13:54:51 -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 : fdrake Summary: xreadlines : readlines :: xrange : range Follow-Ups: Date: 2001-Jan-09 13:54 By: gvanrossum Comment: The module, test, and fileobject change are checked in. Note for Fred: I changed the sizehint in the code to 8K, since I couldn't find a measurable difference between that an the half-a-Megabyte sizehint that the original code used. This affects the documentation a bit, which shows the sizehint in example code. I would be silent about the sizehint value instead. ------------------------------------------------------- Date: 2001-Jan-09 13:51 By: gvanrossum Comment: Assigned to Fred so he can check in the docs. Note: fileinput.py is *not* affected. ------------------------------------------------------- Date: 2001-Jan-05 06:22 By: jepler Comment: As requested by Guido, add a docstring and info in Doc/lib xreadlines-as-method of the builtin file object is retained, but is not added to any builtin file-like object. the speedup of the fileinput module is still present and appears to work, but I note there's no testsuite for the fileinput module. If there's any concern about the behavior of my modifications to fileinput, just ignore those changes. ------------------------------------------------------- Date: 2001-Jan-04 18:40 By: gvanrossum Comment: After timing tests and discussion on python-dev I'm much more inclined to accept this. Jeff, would you mind adding docs? I don't care about adding an xreadlines method to other file-line objects, since the xreadlines module can be used directly by those who want to be generic. ------------------------------------------------------- Date: 2001-Jan-01 09:59 By: gvanrossum Comment: Bah. I don't like this one bit. More complexity for a little bit of extra speed. I'm keeping this open but expect to be closing it soon unless I hear a really good argument why more speed is really needed in this area. Down with code bloat and creeping featurism! ------------------------------------------------------- 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 Tue Jan 9 22:06:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Jan 2001 14:06:11 -0800 Subject: [Patches] [Patch #103140] Minor fixes and enhancements for 2.0 docs. Message-ID: Patch #103140 has been updated. Project: python Category: documentation Status: Accepted Submitted by: esr Assigned to : esr Summary: Minor fixes and enhancements for 2.0 docs. Follow-Ups: Date: 2001-Jan-09 14:06 By: fdrake Comment: Please check this in. Note that I will be making a couple of markup adjustments in libstat.tex after you've checked it in -- it's easier to make the changes than to describe them. ;-) Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103140&group_id=5470 From noreply@sourceforge.net Tue Jan 9 22:55:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Jan 2001 14:55:40 -0800 Subject: [Patches] [Patch #102915] xreadlines : readlines :: xrange : range Message-ID: Patch #102915 has been updated. Project: python Category: Modules Status: Closed Submitted by: jepler Assigned to : fdrake Summary: xreadlines : readlines :: xrange : range Follow-Ups: Date: 2001-Jan-09 14:55 By: fdrake Comment: Checked in as Doc/lib/libstdtypes.tex revision 1.47 and new file Doc/lib/libxreadlines.tex. Closing the patch. ------------------------------------------------------- Date: 2001-Jan-09 13:54 By: gvanrossum Comment: The module, test, and fileobject change are checked in. Note for Fred: I changed the sizehint in the code to 8K, since I couldn't find a measurable difference between that an the half-a-Megabyte sizehint that the original code used. This affects the documentation a bit, which shows the sizehint in example code. I would be silent about the sizehint value instead. ------------------------------------------------------- Date: 2001-Jan-09 13:51 By: gvanrossum Comment: Assigned to Fred so he can check in the docs. Note: fileinput.py is *not* affected. ------------------------------------------------------- Date: 2001-Jan-05 06:22 By: jepler Comment: As requested by Guido, add a docstring and info in Doc/lib xreadlines-as-method of the builtin file object is retained, but is not added to any builtin file-like object. the speedup of the fileinput module is still present and appears to work, but I note there's no testsuite for the fileinput module. If there's any concern about the behavior of my modifications to fileinput, just ignore those changes. ------------------------------------------------------- Date: 2001-Jan-04 18:40 By: gvanrossum Comment: After timing tests and discussion on python-dev I'm much more inclined to accept this. Jeff, would you mind adding docs? I don't care about adding an xreadlines method to other file-line objects, since the xreadlines module can be used directly by those who want to be generic. ------------------------------------------------------- Date: 2001-Jan-01 09:59 By: gvanrossum Comment: Bah. I don't like this one bit. More complexity for a little bit of extra speed. I'm keeping this open but expect to be closing it soon unless I hear a really good argument why more speed is really needed in this area. Down with code bloat and creeping featurism! ------------------------------------------------------- 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 moshez@zadka.site.co.il Wed Jan 10 16:20:11 2001 From: moshez@zadka.site.co.il (Moshe Zadka) Date: Wed, 10 Jan 2001 18:20:11 +0200 (IST) Subject: [Patches] Cannot upload a patch, will someone do it for me? Message-ID: <20010110162011.239E9A82D@darjeeling.zadka.site.co.il> The comment should be: Patch to implement PEP 217. No documentation yet. Please assign it to Guido. Thanks in advance. (If you want to know what the problem is, I think it's that lynx doesn't support multipart/form-data, and I haven't any other browser. I'll install X over the weekend to solve that...:( ) Index: Python/ceval.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/ceval.c,v retrieving revision 2.215 diff -c -r2.215 ceval.c *** Python/ceval.c 2001/01/04 22:33:01 2.215 --- Python/ceval.c 2001/01/10 08:03:53 *************** *** 1245,1280 **** case PRINT_EXPR: v = POP(); ! /* Print value except if None */ ! /* After printing, also assign to '_' */ ! /* Before, set '_' to None to avoid recursion */ ! if (v != Py_None && ! (err = PyDict_SetItemString( ! f->f_builtins, "_", Py_None)) == 0) { ! err = Py_FlushLine(); ! if (err == 0) { ! x = PySys_GetObject("stdout"); ! if (x == NULL) { ! PyErr_SetString( ! PyExc_RuntimeError, ! "lost sys.stdout"); ! err = -1; ! } ! } ! if (err == 0) ! err = PyFile_WriteObject(v, x, 0); ! if (err == 0) { ! PyFile_SoftSpace(x, 1); ! err = Py_FlushLine(); ! } ! if (err == 0) { ! err = PyDict_SetItemString( ! f->f_builtins, "_", v); ! } } Py_DECREF(v); break; ! case PRINT_ITEM_TO: w = stream = POP(); /* fall through to PRINT_ITEM */ --- 1245,1270 ---- case PRINT_EXPR: v = POP(); ! w = PySys_GetObject("displayhook"); ! if (w == NULL) { ! PyErr_SetString(PyExc_RuntimeError, ! "lost sys.displayhook"); ! err = -1; } + if (err == 0) { + x = Py_BuildValue("(O)", v); + if (x == NULL) + err = -1; + } + if (err == 0) { + w = PyEval_CallObject(w, x); + if (w == NULL) + err = -1; + } Py_DECREF(v); + Py_XDECREF(x); break; ! case PRINT_ITEM_TO: w = stream = POP(); /* fall through to PRINT_ITEM */ Index: Python/sysmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/sysmodule.c,v retrieving revision 2.80 diff -c -r2.80 sysmodule.c *** Python/sysmodule.c 2000/12/15 22:02:05 2.80 --- Python/sysmodule.c 2001/01/10 08:05:44 *************** *** 68,73 **** --- 68,117 ---- } static PyObject * + sys_displayhook(PyObject *self, PyObject *args) + { + PyObject *o, *stdout; + PyInterpreterState *interp = PyThreadState_Get()->interp; + PyObject *modules = interp->modules; + PyObject *builtins = PyDict_GetItemString(modules, "__builtin__"); + + /* parse arguments */ + if (!PyArg_ParseTuple(args, "O:displayhook", &o)) + return NULL; + + /* Print value except if None */ + /* After printing, also assign to '_' */ + /* Before, set '_' to None to avoid recursion */ + if (o == Py_None) { + Py_INCREF(Py_None); + return Py_None; + } + if (PyObject_SetAttrString(builtins, "_", Py_None) != 0) + return NULL; + if (Py_FlushLine() != 0) + return NULL; + stdout = PySys_GetObject("stdout"); + if (stdout == NULL) { + PyErr_SetString(PyExc_RuntimeError, "lost sys.stdout"); + return NULL; + } + if (PyFile_WriteObject(o, stdout, 0) != 0) + return NULL; + PyFile_SoftSpace(stdout, 1); + if (Py_FlushLine() != 0) + return NULL; + if (PyObject_SetAttrString(builtins, "_", o) != 0) + return NULL; + Py_INCREF(Py_None); + return Py_None; + } + + static char displayhook_doc[] = + "displayhook(o) -> None\n" + "\n" + "Print o to the stdout, and save it in __builtin__._\n"; + + static PyObject * sys_exc_info(PyObject *self, PyObject *args) { PyThreadState *tstate; *************** *** 332,337 **** --- 376,382 ---- static PyMethodDef sys_methods[] = { /* Might as well keep this in alphabetic order */ + {"disp From noreply@sourceforge.net Wed Jan 10 08:24:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 00:24:59 -0800 Subject: [Patches] [Patch #103169] Display Hook for Interactive Use Message-ID: Patch #103169 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nowonder Assigned to : nobody Summary: Display Hook for Interactive Use ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103169&group_id=5470 From noreply@sourceforge.net Wed Jan 10 08:26:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 00:26:05 -0800 Subject: [Patches] [Patch #103169] Display Hook for Interactive Use Message-ID: Patch #103169 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nowonder Assigned to : gvanrossum Summary: Display Hook for Interactive Use ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103169&group_id=5470 From noreply@sourceforge.net Wed Jan 10 08:56:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 00:56:51 -0800 Subject: [Patches] [Patch #103170] (MosheZ) Implement PEP 217 Message-ID: Patch #103170 has been updated. Project: python Category: core (C code) Status: Open Submitted by: tim_one Assigned to : nobody Summary: (MosheZ) Implement PEP 217 ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103170&group_id=5470 From noreply@sourceforge.net Wed Jan 10 08:57:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 00:57:54 -0800 Subject: [Patches] [Patch #103170] (MosheZ) Implement PEP 217 Message-ID: Patch #103170 has been updated. Project: python Category: core (C code) Status: Open Submitted by: tim_one Assigned to : gvanrossum Summary: (MosheZ) Implement PEP 217 ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103170&group_id=5470 From tim.one@home.com Wed Jan 10 09:00:49 2001 From: tim.one@home.com (Tim Peters) Date: Wed, 10 Jan 2001 04:00:49 -0500 Subject: [Patches] Cannot upload a patch, will someone do it for me? In-Reply-To: <20010110162011.239E9A82D@darjeeling.zadka.site.co.il> Message-ID: [Moshe] > The comment should be: > Patch to implement PEP 217. > No documentation yet. > > Please assign it to Guido. > > Thanks in advance. You're welcome in retrospect. It's here: https://sourceforge.net/patch/index.php?func=detailpatch& patch_id=103170&group_id=5470 > If you want to know what the problem is ... No, I do not. I use a real OS and a real browser so I don't have to deal with silliness like that . From noreply@sourceforge.net Wed Jan 10 10:42:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 02:42:06 -0800 Subject: [Patches] [Patch #103169] Display Hook for Interactive Use Message-ID: Patch #103169 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nowonder Assigned to : gvanrossum Summary: Display Hook for Interactive Use Follow-Ups: Date: 2001-Jan-10 02:42 By: ping Comment: Maybe there should be a saved copy of the original built-in routine in sys.__displayhook__ so that (a) we can always restore the hook if we lose it and (b) a user-written displayhook routine can call on the original. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103169&group_id=5470 From noreply@sourceforge.net Wed Jan 10 10:44:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 02:44:39 -0800 Subject: [Patches] [Patch #103170] (MosheZ) Implement PEP 217 Message-ID: Patch #103170 has been updated. Project: python Category: core (C code) Status: Open Submitted by: tim_one Assigned to : gvanrossum Summary: (MosheZ) Implement PEP 217 Follow-Ups: Date: 2001-Jan-10 02:44 By: ping Comment: Maybe there should be a saved copy of the original built-in routine in sys.__displayhook__ so that (a) we can always restore the hook if we lose it and (b) a user-written displayhook routine can call on the original. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103170&group_id=5470 From noreply@sourceforge.net Wed Jan 10 10:45:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 02:45:01 -0800 Subject: [Patches] [Patch #103170] (MosheZ) Implement PEP 217 Message-ID: Patch #103170 has been updated. Project: python Category: core (C code) Status: Open Submitted by: tim_one Assigned to : gvanrossum Summary: (MosheZ) Implement PEP 217 Follow-Ups: Date: 2001-Jan-10 02:45 By: ping Comment: This patch appears truncated (check out the last line). ------------------------------------------------------- Date: 2001-Jan-10 02:44 By: ping Comment: Maybe there should be a saved copy of the original built-in routine in sys.__displayhook__ so that (a) we can always restore the hook if we lose it and (b) a user-written displayhook routine can call on the original. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103170&group_id=5470 From noreply@sourceforge.net Wed Jan 10 11:17:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 03:17:04 -0800 Subject: [Patches] [Patch #103170] (MosheZ) Implement PEP 217 Message-ID: Patch #103170 has been updated. Project: python Category: core (C code) Status: Open Submitted by: tim_one Assigned to : gvanrossum Summary: (MosheZ) Implement PEP 217 Follow-Ups: Date: 2001-Jan-10 03:17 By: moshez Comment: Stop gap measure, seeing as the patches@python.org method did not work... OK. This one is with docs. ------------------------------------------------------- Date: 2001-Jan-10 02:45 By: ping Comment: This patch appears truncated (check out the last line). ------------------------------------------------------- Date: 2001-Jan-10 02:44 By: ping Comment: Maybe there should be a saved copy of the original built-in routine in sys.__displayhook__ so that (a) we can always restore the hook if we lose it and (b) a user-written displayhook routine can call on the original. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103170&group_id=5470 From noreply@sourceforge.net Wed Jan 10 11:15:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 03:15:44 -0800 Subject: [Patches] [Patch #103169] Display Hook for Interactive Use Message-ID: Patch #103169 has been updated. Project: python Category: core (C code) Status: Rejected Submitted by: nowonder Assigned to : moshez Summary: Display Hook for Interactive Use Follow-Ups: Date: 2001-Jan-10 03:15 By: moshez Comment: Duplicate (Thanks anyway, Peter) ------------------------------------------------------- Date: 2001-Jan-10 02:42 By: ping Comment: Maybe there should be a saved copy of the original built-in routine in sys.__displayhook__ so that (a) we can always restore the hook if we lose it and (b) a user-written displayhook routine can call on the original. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103169&group_id=5470 From noreply@sourceforge.net Wed Jan 10 11:22:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 03:22:21 -0800 Subject: [Patches] [Patch #103170] (MosheZ) Implement PEP 217 Message-ID: Patch #103170 has been updated. Project: python Category: core (C code) Status: Open Submitted by: tim_one Assigned to : gvanrossum Summary: (MosheZ) Implement PEP 217 Follow-Ups: Date: 2001-Jan-10 03:22 By: moshez Comment: Ping: I don't think this is really necessary. No one should have need to "restore the original": this is likely to be set from .pythonrc scripts and their ilk. If a user defined routine wants to call on the original, it should save a reference to the original itself. This is the same philosophy that is taken with regards to __import__, which I tried to emulate. ------------------------------------------------------- Date: 2001-Jan-10 03:17 By: moshez Comment: Stop gap measure, seeing as the patches@python.org method did not work... OK. This one is with docs. ------------------------------------------------------- Date: 2001-Jan-10 02:45 By: ping Comment: This patch appears truncated (check out the last line). ------------------------------------------------------- Date: 2001-Jan-10 02:44 By: ping Comment: Maybe there should be a saved copy of the original built-in routine in sys.__displayhook__ so that (a) we can always restore the hook if we lose it and (b) a user-written displayhook routine can call on the original. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103170&group_id=5470 From noreply@sourceforge.net Wed Jan 10 13:01:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 05:01:20 -0800 Subject: [Patches] [Patch #103173] make uu.decode work with spaces in filename Message-ID: Patch #103173 has been updated. Project: python Category: library Status: Open Submitted by: pyretic Assigned to : nobody Summary: make uu.decode work with spaces in filename ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103173&group_id=5470 From noreply@sourceforge.net Wed Jan 10 16:25:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 08:25:00 -0800 Subject: [Patches] [Patch #103176] PEP 217 (display hook) Message-ID: Patch #103176 has been updated. Project: python Category: core (C code) Status: Open Submitted by: gvanrossum Assigned to : nobody Summary: PEP 217 (display hook) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103176&group_id=5470 From noreply@sourceforge.net Wed Jan 10 16:25:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 08:25:17 -0800 Subject: [Patches] [Patch #103147] restrict dir output in presence of __exports__ Message-ID: Patch #103147 has been updated. Project: python Category: core (C code) Status: Open Submitted by: montanaro Assigned to : gvanrossum Summary: restrict dir output in presence of __exports__ ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103147&group_id=5470 From noreply@sourceforge.net Wed Jan 10 16:25:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 08:25:18 -0800 Subject: [Patches] [Patch #103176] PEP 217 (display hook) Message-ID: Patch #103176 has been updated. Project: python Category: core (C code) Status: Open Submitted by: gvanrossum Assigned to : gvanrossum Summary: PEP 217 (display hook) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103176&group_id=5470 From noreply@sourceforge.net Wed Jan 10 16:25:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 08:25:18 -0800 Subject: [Patches] [Patch #103158] Don't do unsafe arithmetic in xrange object Message-ID: Patch #103158 has been updated. Project: python Category: core (C code) Status: Open Submitted by: greg_ball Assigned to : gvanrossum Summary: Don't do unsafe arithmetic in xrange object Follow-Ups: Date: 2001-Jan-09 06:31 By: greg_ball Comment: This is a replacement for patch 103129, as suggested by tim_one. Possibly interesting aspects of the patch: - xrange objects with overflowing lengths are not gratutiously rejected. An error is raised only if the length becomes relevant, under len() or negative indexing. Bad lengths are stored as -1. Objects with bad lengths allow any non-negative integer index. - On 64 bit platforms, sequence multiplication seems to cause an unsafe cast from long to int. This patch does not address that issue. Without my patch, on i686 Linux: Python 2.0 (#25, Jan 2 2001, 12:18:07) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "", line 1, in ? SystemError: error return without exception set >>> y = xrange(maxint/2)*3 >>> len(y) -1073741827 >>> y[-1] Traceback (most recent call last): File "", line 1, in ? SystemError: error return without exception set >>> y.tolist() Traceback (most recent call last): File "", line 1, in ? SystemError: listobject.c:33: bad argument to internal function >>> m = maxint >> 16 >>> xrange(0,maxint,m) xrange(0, -2147450883, 32767) >>> (xrange(1)*maxint)*maxint xrange(1) >>> With my patch Python 2.0 (#35, Jan 6 2001, 12:54:41) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange object too long >>> y = xrange(maxint/2)*3 >>> len(y) Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange object too long >>> y.tolist() Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange object too long >>> m = maxint >> 16 >>> xrange(0,maxint,m) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> (xrange(1)*maxint) * maxint Traceback (most recent call last): File "", line 1, in ? OverflowError: integer multiplication >>> Without patch on Digital Unix Python 2.0 (#5, Jan 6 2001, 15:42:58) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "", line 1, in ? SystemError: error return without exception set >>> xrange(0,maxint,m) xrange(0, -9223372034707292163, 2147483647) >>> xrange(1)*maxint xrange(0) >>> With patch Python 2.0 (#7, Jan 6 2001, 15:52:21) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange object too long >>> xrange(0,maxint,m) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(1)*maxint xrange(0) >>> ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103158&group_id=5470 From noreply@sourceforge.net Wed Jan 10 16:25:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 08:25:18 -0800 Subject: [Patches] [Patch #103173] make uu.decode work with spaces in filename Message-ID: Patch #103173 has been updated. Project: python Category: library Status: Open Submitted by: pyretic Assigned to : gvanrossum Summary: make uu.decode work with spaces in filename ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103173&group_id=5470 From noreply@sourceforge.net Wed Jan 10 16:25:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 08:25:17 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: Patch #103154 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From guido@python.org Wed Jan 10 16:26:58 2001 From: guido@python.org (Guido van Rossum) Date: Wed, 10 Jan 2001 11:26:58 -0500 Subject: [Patches] Cannot upload a patch, will someone do it for me? In-Reply-To: Your message of "Wed, 10 Jan 2001 18:20:11 +0200." <20010110162011.239E9A82D@darjeeling.zadka.site.co.il> References: <20010110162011.239E9A82D@darjeeling.zadka.site.co.il> Message-ID: <200101101626.LAA26626@cj20424-a.reston1.va.home.com> Thanks; I've uploaded it: http://sourceforge.net/patch/?func=detailpatch&patch_id=103176&group_id=5470 Anxiously waiting the docs... --Guido van Rossum (home page: http://www.python.org/~guido/) From noreply@sourceforge.net Wed Jan 10 16:27:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 08:27:39 -0800 Subject: [Patches] [Patch #103176] PEP 217 (display hook) Message-ID: Patch #103176 has been updated. Project: python Category: core (C code) Status: Deleted Submitted by: gvanrossum Assigned to : gvanrossum Summary: PEP 217 (display hook) Follow-Ups: Date: 2001-Jan-10 08:27 By: gvanrossum Comment: Oops. Duplicate upload. Please see the first upload of this patch: https://sourceforge.net/patch/index.php?func=detailpatch&patch_id=103170&group_id=5470 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103176&group_id=5470 From noreply@sourceforge.net Wed Jan 10 16:41:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 08:41:18 -0800 Subject: [Patches] [Patch #103170] (MosheZ) Implement PEP 217 Message-ID: Patch #103170 has been updated. Project: python Category: core (C code) Status: Open Submitted by: tim_one Assigned to : gvanrossum Summary: (MosheZ) Implement PEP 217 Follow-Ups: Date: 2001-Jan-10 08:41 By: gvanrossum Comment: I agree with Moshe -- there's no need to save the original. ------------------------------------------------------- Date: 2001-Jan-10 03:22 By: moshez Comment: Ping: I don't think this is really necessary. No one should have need to "restore the original": this is likely to be set from .pythonrc scripts and their ilk. If a user defined routine wants to call on the original, it should save a reference to the original itself. This is the same philosophy that is taken with regards to __import__, which I tried to emulate. ------------------------------------------------------- Date: 2001-Jan-10 03:17 By: moshez Comment: Stop gap measure, seeing as the patches@python.org method did not work... OK. This one is with docs. ------------------------------------------------------- Date: 2001-Jan-10 02:45 By: ping Comment: This patch appears truncated (check out the last line). ------------------------------------------------------- Date: 2001-Jan-10 02:44 By: ping Comment: Maybe there should be a saved copy of the original built-in routine in sys.__displayhook__ so that (a) we can always restore the hook if we lose it and (b) a user-written displayhook routine can call on the original. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103170&group_id=5470 From noreply@sourceforge.net Wed Jan 10 18:06:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 10:06:19 -0800 Subject: [Patches] [Patch #103169] Display Hook for Interactive Use Message-ID: Patch #103169 has been updated. Project: python Category: core (C code) Status: Deleted Submitted by: nowonder Assigned to : nobody Summary: Display Hook for Interactive Use Follow-Ups: Date: 2001-Jan-10 10:06 By: tim_one Comment: Changed from Rejected to Deleted, to prevent future confusion (this patch is a duplicate, and is damaged (truncated) anyway). ------------------------------------------------------- Date: 2001-Jan-10 03:15 By: moshez Comment: Duplicate (Thanks anyway, Peter) ------------------------------------------------------- Date: 2001-Jan-10 02:42 By: ping Comment: Maybe there should be a saved copy of the original built-in routine in sys.__displayhook__ so that (a) we can always restore the hook if we lose it and (b) a user-written displayhook routine can call on the original. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103169&group_id=5470 From noreply@sourceforge.net Wed Jan 10 18:28:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 10:28:28 -0800 Subject: [Patches] [Patch #103158] Don't do unsafe arithmetic in xrange object Message-ID: Patch #103158 has been updated. Project: python Category: core (C code) Status: Open Submitted by: greg_ball Assigned to : gvanrossum Summary: Don't do unsafe arithmetic in xrange object Follow-Ups: Date: 2001-Jan-10 10:28 By: gvanrossum Comment: I wonder why you made totlen an int. This seems to complicate the code quite a bit. I'd suggest making it a long. Then you have to test whether it's > INT_MAX only in tolist() -- in that case you should raise MemoryError. Other than that, it looks decent! ------------------------------------------------------- Date: 2001-Jan-09 06:31 By: greg_ball Comment: This is a replacement for patch 103129, as suggested by tim_one. Possibly interesting aspects of the patch: - xrange objects with overflowing lengths are not gratutiously rejected. An error is raised only if the length becomes relevant, under len() or negative indexing. Bad lengths are stored as -1. Objects with bad lengths allow any non-negative integer index. - On 64 bit platforms, sequence multiplication seems to cause an unsafe cast from long to int. This patch does not address that issue. Without my patch, on i686 Linux: Python 2.0 (#25, Jan 2 2001, 12:18:07) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "", line 1, in ? SystemError: error return without exception set >>> y = xrange(maxint/2)*3 >>> len(y) -1073741827 >>> y[-1] Traceback (most recent call last): File "", line 1, in ? SystemError: error return without exception set >>> y.tolist() Traceback (most recent call last): File "", line 1, in ? SystemError: listobject.c:33: bad argument to internal function >>> m = maxint >> 16 >>> xrange(0,maxint,m) xrange(0, -2147450883, 32767) >>> (xrange(1)*maxint)*maxint xrange(1) >>> With my patch Python 2.0 (#35, Jan 6 2001, 12:54:41) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange object too long >>> y = xrange(maxint/2)*3 >>> len(y) Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange object too long >>> y.tolist() Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange object too long >>> m = maxint >> 16 >>> xrange(0,maxint,m) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> (xrange(1)*maxint) * maxint Traceback (most recent call last): File "", line 1, in ? OverflowError: integer multiplication >>> Without patch on Digital Unix Python 2.0 (#5, Jan 6 2001, 15:42:58) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "", line 1, in ? SystemError: error return without exception set >>> xrange(0,maxint,m) xrange(0, -9223372034707292163, 2147483647) >>> xrange(1)*maxint xrange(0) >>> With patch Python 2.0 (#7, Jan 6 2001, 15:52:21) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange object too long >>> xrange(0,maxint,m) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(1)*maxint xrange(0) >>> ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103158&group_id=5470 From noreply@sourceforge.net Wed Jan 10 18:41:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 10:41:07 -0800 Subject: [Patches] [Patch #103179] Memory leak fix - partial fix for bug #127699 Message-ID: Patch #103179 has been updated. Project: python Category: core (C code) Status: Open Submitted by: cgw Assigned to : nobody Summary: Memory leak fix - partial fix for bug #127699 ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103179&group_id=5470 From noreply@sourceforge.net Wed Jan 10 19:15:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 11:15:25 -0800 Subject: [Patches] [Patch #103173] make uu.decode work with spaces in filename Message-ID: Patch #103173 has been updated. Project: python Category: library Status: Closed Submitted by: pyretic Assigned to : gvanrossum Summary: make uu.decode work with spaces in filename Follow-Ups: Date: 2001-Jan-10 11:15 By: gvanrossum Comment: Checked in, uu.py rev. 1.14. I use rstrip() instead of [:-1] to strip the trailing newline of the filename, since I don't want filenames with trailing spaces (most likely these are attempts to trick the recipient :-). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103173&group_id=5470 From noreply@sourceforge.net Wed Jan 10 19:16:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 11:16:25 -0800 Subject: [Patches] [Patch #103147] restrict dir output in presence of __exports__ Message-ID: Patch #103147 has been updated. Project: python Category: core (C code) Status: Rejected Submitted by: montanaro Assigned to : gvanrossum Summary: restrict dir output in presence of __exports__ Follow-Ups: Date: 2001-Jan-10 11:16 By: gvanrossum Comment: Rejected after recent python-dev discussions. We'll implement __all__, to be used only by from...import *. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103147&group_id=5470 From noreply@sourceforge.net Wed Jan 10 19:17:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 11:17:22 -0800 Subject: [Patches] [Patch #102808] Export control for modules Message-ID: Patch #102808 has been updated. Project: python Category: core (C code) Status: Rejected Submitted by: rumjuggler Assigned to : gvanrossum Summary: Export control for modules Follow-Ups: Date: 2001-Jan-10 11:17 By: gvanrossum Comment: Rejected based on extensive discussion in python-dev. We'll implement __all__ however; this will be used only by "from...import *". Thanks for getting this discussion started! ------------------------------------------------------- Date: 2001-Jan-07 08:14 By: greg_ball Comment: How about an alternative syntax: assignment to module.__dict__ (currently not allowed.) # module foo.py constant_number=3 def bar(): print constant_number import foo foo.__dict__={'bar':bar} # end of module foo Now attribute access can get only the objects in the new dict. However if you really want to, you can access foo.bar.func_globals since functions defined in foo keep a reference to their oringinal namespace. (otherwise this proposal would just break everything...) ------------------------------------------------------- Date: 2001-Jan-05 21:40 By: nobody Comment: Shouldn't it be called "__all__" (for consistency with a similar functionality in packages)? ------------------------------------------------------- Date: 2001-Jan-05 13:20 By: tim_one Comment: +1 on the idea, -1 on the patch. If PyModule_ExportableName is supposed to be a new part of the public API, we need docs for it; else it should be renamed (with a leading underscore). If it is part of the public API, it needs to sanity-check its arguments (e.g., at least that m and s aren't NULL -- we'll get a core dump now if they are); else it should at least assert that they're sane. Needs a test in any case. ------------------------------------------------------- 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 Jan 10 19:21:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 11:21:43 -0800 Subject: [Patches] [Patch #103147] restrict dir output in presence of __exports__ Message-ID: Patch #103147 has been updated. Project: python Category: core (C code) Status: Rejected Submitted by: montanaro Assigned to : gvanrossum Summary: restrict dir output in presence of __exports__ Follow-Ups: Date: 2001-Jan-10 11:21 By: montanaro Comment: Rejection is fine (I can take it, really I can ;-). It seems to me that making dir() match what "from ... import *" would import is a good thing. I strongly urge you to consider that possibility. S ------------------------------------------------------- Date: 2001-Jan-10 11:16 By: gvanrossum Comment: Rejected after recent python-dev discussions. We'll implement __all__, to be used only by from...import *. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103147&group_id=5470 From noreply@sourceforge.net Wed Jan 10 20:26:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 12:26:41 -0800 Subject: [Patches] [Patch #103179] Memory leak fix - partial fix for bug #127699 Message-ID: Patch #103179 has been updated. Project: python Category: core (C code) Status: Accepted Submitted by: cgw Assigned to : cgw Summary: Memory leak fix - partial fix for bug #127699 Follow-Ups: Date: 2001-Jan-10 12:26 By: gvanrossum Comment: Charles, looks good. Check it in! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103179&group_id=5470 From noreply@sourceforge.net Wed Jan 10 20:23:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 12:23:37 -0800 Subject: [Patches] [Patch #103170] (MosheZ) Implement PEP 217 Message-ID: Patch #103170 has been updated. Project: python Category: core (C code) Status: Accepted Submitted by: tim_one Assigned to : gvanrossum Summary: (MosheZ) Implement PEP 217 Follow-Ups: Date: 2001-Jan-10 12:23 By: gvanrossum Comment: Moshe, I've ACCEPTED your patch. Please check it in and close it. Congratulations! ------------------------------------------------------- Date: 2001-Jan-10 08:41 By: gvanrossum Comment: I agree with Moshe -- there's no need to save the original. ------------------------------------------------------- Date: 2001-Jan-10 03:22 By: moshez Comment: Ping: I don't think this is really necessary. No one should have need to "restore the original": this is likely to be set from .pythonrc scripts and their ilk. If a user defined routine wants to call on the original, it should save a reference to the original itself. This is the same philosophy that is taken with regards to __import__, which I tried to emulate. ------------------------------------------------------- Date: 2001-Jan-10 03:17 By: moshez Comment: Stop gap measure, seeing as the patches@python.org method did not work... OK. This one is with docs. ------------------------------------------------------- Date: 2001-Jan-10 02:45 By: ping Comment: This patch appears truncated (check out the last line). ------------------------------------------------------- Date: 2001-Jan-10 02:44 By: ping Comment: Maybe there should be a saved copy of the original built-in routine in sys.__displayhook__ so that (a) we can always restore the hook if we lose it and (b) a user-written displayhook routine can call on the original. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103170&group_id=5470 From noreply@sourceforge.net Wed Jan 10 20:24:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 12:24:01 -0800 Subject: [Patches] [Patch #103170] (MosheZ) Implement PEP 217 Message-ID: Patch #103170 has been updated. Project: python Category: core (C code) Status: Accepted Submitted by: tim_one Assigned to : moshez Summary: (MosheZ) Implement PEP 217 Follow-Ups: Date: 2001-Jan-10 12:23 By: gvanrossum Comment: Moshe, I've ACCEPTED your patch. Please check it in and close it. Congratulations! ------------------------------------------------------- Date: 2001-Jan-10 08:41 By: gvanrossum Comment: I agree with Moshe -- there's no need to save the original. ------------------------------------------------------- Date: 2001-Jan-10 03:22 By: moshez Comment: Ping: I don't think this is really necessary. No one should have need to "restore the original": this is likely to be set from .pythonrc scripts and their ilk. If a user defined routine wants to call on the original, it should save a reference to the original itself. This is the same philosophy that is taken with regards to __import__, which I tried to emulate. ------------------------------------------------------- Date: 2001-Jan-10 03:17 By: moshez Comment: Stop gap measure, seeing as the patches@python.org method did not work... OK. This one is with docs. ------------------------------------------------------- Date: 2001-Jan-10 02:45 By: ping Comment: This patch appears truncated (check out the last line). ------------------------------------------------------- Date: 2001-Jan-10 02:44 By: ping Comment: Maybe there should be a saved copy of the original built-in routine in sys.__displayhook__ so that (a) we can always restore the hook if we lose it and (b) a user-written displayhook routine can call on the original. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103170&group_id=5470 From noreply@sourceforge.net Wed Jan 10 20:45:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 12:45:46 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: Patch #103154 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Wed Jan 10 21:12:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 13:12:49 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: Patch #102409 has been updated. Project: python Category: Build Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 >> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Wed Jan 10 21:14:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 13:14:09 -0800 Subject: [Patches] [Patch #103134] Support code execution in PTH files Message-ID: Patch #103134 has been updated. Project: python Category: library Status: Accepted Submitted by: loewis Assigned to : loewis Summary: Support code execution in PTH files Follow-Ups: Date: 2001-Jan-10 13:14 By: gvanrossum Comment: This is sooooo cute, I accept it. Martin, please check it in. (Is there any documentation of .pth files at all? Maybe in the docs for the site.py module? Then this should be updated too!) ------------------------------------------------------- Date: 2001-Jan-07 14:36 By: fdrake Comment: I think this is a good idea, but it's not clear that others will agree. Assigning to Guido since this is largely a matter of policy, and I'm not at all sure he'll like the idea. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103134&group_id=5470 From noreply@sourceforge.net Wed Jan 10 21:37:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 13:37:43 -0800 Subject: [Patches] [Patch #102354] Fix dynamic module linking on Mac OSX/OSXS Message-ID: Patch #102354 has been updated. Project: python Category: Build Status: Rejected Submitted by: bbum Assigned to : gvanrossum Summary: Fix dynamic module linking on Mac OSX/OSXS Follow-Ups: Date: 2001-Jan-10 13:37 By: gvanrossum Comment: Looks to me like a newer version of this patch is submitted as #102362, so I'm rejecting this one. ------------------------------------------------------- Date: 2000-Nov-11 11:05 By: bbum Comment: *** /tmp/Python-2.0/configure.in Mon Oct 16 17:50:06 2000 --- configure.in Sat Nov 11 13:54:43 2000 *************** *** 573,581 **** Darwin/*|next/*) if test "$ns_dyld" then ! if test "$ac_sys_system" = Darwin ! then LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress' ! else LDSHARED='$(CC) $(LDFLAGS) -bundle -prebind' fi else LDSHARED='$(CC) $(CFLAGS) -nostdlib -r'; fi --- 573,579 ---- Darwin/*|next/*) if test "$ns_dyld" then ! LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress' fi else LDSHARED='$(CC) $(CFLAGS) -nostdlib -r'; fi *************** *** 646,652 **** # in System.framework; otherwise, __objcInit (referenced in # crt1.o) gets erroneously defined as common, which breaks dynamic # loading of any modules which reference it in System.framework ! next/4*|next/5*) LINKFORSHARED="-u __dummy -framework System" ;; Darwin/*) LINKFORSHARED="-framework System" ;; SCO_SV*) LINKFORSHARED="-Bdynamic -dy -Wl,-Bexport";; ReliantUNIX*) LINKFORSHARED="-W1 -Blargedynsym";; --- 644,650 ---- # in System.framework; otherwise, __objcInit (referenced in # crt1.o) gets erroneously defined as common, which breaks dynamic # loading of any modules which reference it in System.framework ! next/4*|next/5*) LINKFORSHARED="-u __dummy -framework System -framework Foundation" ;; Darwin/*) LINKFORSHARED="-framework System" ;; SCO_SV*) LINKFORSHARED="-Bdynamic -dy -Wl,-Bexport";; ReliantUNIX*) LINKFORSHARED="-W1 -Blargedynsym";; ------------------------------------------------------- Date: 2000-Nov-11 11:07 By: bbum Comment: The addition of -framework Foundation is required to allow dynamically loaded modules to have access to the Objective-C runtiem under OSXS. This *may* also be required under Darwin/OSX, but-- if that is the case-- it will be submitted as a separate patch once I restore my OSX work environment and can verify that it is the case. ------------------------------------------------------- Date: 2000-Nov-12 02:07 By: loewis Comment: If you add an option that is required for something, then it would be good to add a comment to indicate what the something is. Also, are you sure that linking with the Foundation framework is absolutely necessary? Would it be possible for extension modules to link with the framework themselves if they need it? ------------------------------------------------------- Date: 2000-Nov-12 08:22 By: bbum Comment: (It isn't clear where one can actually document a patch when uploading the first version. I'll have to make sure and add a comment after the initial upload-- or document the code better. Sorry about that.) The Foundation framework must be linked into the python executable if any dynamically loaded module is to ever use the Objective-C runtime. At least, I haven't found a workaround that allows one to link it into the loadable module. If it isn't, then the load dies with one of two erros depending on platform: OSX: dies with a duplicate symbol error on __objcInit. OSXS: dies with a "objc: link required classes into application" ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102354&group_id=5470 From noreply@sourceforge.net Wed Jan 10 21:44:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 13:44:51 -0800 Subject: [Patches] [Patch #102362] Support dynamic module loading under OSX [including support for modules w/Objective-C] Message-ID: Patch #102362 has been updated. Project: python Category: None Status: Closed Submitted by: bbum Assigned to : gvanrossum Summary: Support dynamic module loading under OSX [including support for modules w/Objective-C] Follow-Ups: Date: 2001-Jan-10 13:44 By: gvanrossum Comment: Applied. Apologies for taking so long! Comment on form: your diff utility generates invalid diffs (the line counts don't match) or some blank lines were suppressed in the upload. Also, I'm presuming that this is indeed an updated version of patch 102354 which you also submitted (and which had a bug in it -- you left a dangling 'fi' in it). If you have to do it, please add a comment to the invalidated patch so I don't waste time on it. But better is to use the "Upload Revised Patch" feature of sourceforge! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102362&group_id=5470 From noreply@sourceforge.net Wed Jan 10 21:46:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 13:46:53 -0800 Subject: [Patches] [Patch #102357] Add support for frameworks and objective-c source. Uesful for both GnuStep and for OSXS/OSX/Darwin. Message-ID: Patch #102357 has been updated. Project: python Category: Modules Status: Closed Submitted by: bbum Assigned to : gvanrossum Summary: Add support for frameworks and objective-c source. Uesful for both GnuStep and for OSXS/OSX/Darwin. Follow-Ups: Date: 2001-Jan-10 13:46 By: gvanrossum Comment: Applied. Again, somehow the line numbers in your diff were broken! I've changed $(CCC) to $(CXX) since that is now the name of the C++ compiler. If this wasn't what you intended, please get in touch. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102357&group_id=5470 From noreply@sourceforge.net Thu Jan 11 03:39:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 19:39:43 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: Patch #102409 has been updated. Project: python Category: Build Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-10 19:39 By: jlt63 Comment: Your welcome -- thanks for considering and accepting this patch. If the patch proves to reek havoc on other platforms (most likely only on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out. ------------------------------------------------------- Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 >> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Thu Jan 11 03:48:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 19:48:07 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: Patch #103154 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-10 19:48 By: jlt63 Comment: I have already checked that this patch does not break the Windows VC build before I submitted it. However, Tim is welcome to reverify himself. Unfortunately, I have found a bug with this patch that (only) affects Cygwin. Although this patch handles the following: import String it does not handle the following: import termios, TERMIOS I will resubmit a new version shortly, please change the status back to open. ------------------------------------------------------- Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Thu Jan 11 05:13:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 21:13:34 -0800 Subject: [Patches] [Patch #103185] Some more standard modules cleanup for Cygwin Message-ID: Patch #103185 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jlt63 Assigned to : nobody Summary: Some more standard modules cleanup for Cygwin ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103185&group_id=5470 From noreply@sourceforge.net Thu Jan 11 05:19:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 21:19:28 -0800 Subject: [Patches] [Patch #103185] Some more standard modules cleanup for Cygwin Message-ID: Patch #103185 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jlt63 Assigned to : nobody Summary: Some more standard modules cleanup for Cygwin Follow-Ups: Date: 2001-Jan-10 21:19 By: jlt63 Comment: Use the following procedure to patch: $ cd Modules $ # save modules.patch to current directory $ patch Patch #103170 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: tim_one Assigned to : moshez Summary: (MosheZ) Implement PEP 217 Follow-Ups: Date: 2001-Jan-10 22:51 By: moshez Comment: Applied to CVS ------------------------------------------------------- Date: 2001-Jan-10 12:23 By: gvanrossum Comment: Moshe, I've ACCEPTED your patch. Please check it in and close it. Congratulations! ------------------------------------------------------- Date: 2001-Jan-10 08:41 By: gvanrossum Comment: I agree with Moshe -- there's no need to save the original. ------------------------------------------------------- Date: 2001-Jan-10 03:22 By: moshez Comment: Ping: I don't think this is really necessary. No one should have need to "restore the original": this is likely to be set from .pythonrc scripts and their ilk. If a user defined routine wants to call on the original, it should save a reference to the original itself. This is the same philosophy that is taken with regards to __import__, which I tried to emulate. ------------------------------------------------------- Date: 2001-Jan-10 03:17 By: moshez Comment: Stop gap measure, seeing as the patches@python.org method did not work... OK. This one is with docs. ------------------------------------------------------- Date: 2001-Jan-10 02:45 By: ping Comment: This patch appears truncated (check out the last line). ------------------------------------------------------- Date: 2001-Jan-10 02:44 By: ping Comment: Maybe there should be a saved copy of the original built-in routine in sys.__displayhook__ so that (a) we can always restore the hook if we lose it and (b) a user-written displayhook routine can call on the original. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103170&group_id=5470 From noreply@sourceforge.net Thu Jan 11 06:55:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 22:55:41 -0800 Subject: [Patches] [Patch #103129] Avoid unsafe arithmetic in xrange object Message-ID: Patch #103129 has been updated. Project: python Category: core (C code) Status: Rejected Submitted by: nobody Assigned to : tim_one Summary: Avoid unsafe arithmetic in xrange object Follow-Ups: Date: 2001-Jan-10 22:55 By: moshez Comment: Obsoleted by 103158. Tim I'm leaving this assigned to you. ------------------------------------------------------- Date: 2001-Jan-07 21:53 By: tim_one Comment: Greg, why not submit the patch you want to submit under your own name? I'll take it, and delete this one. Note too that the "Details" section in this patch is utterly unreadable, due to lack of any linebreaks. I can assure you in any case that nobody gives a rip about how fast xrange multiplication works -- I'd be surprised if 1 Python programmer in 1000 even knew it was supported. ------------------------------------------------------- Date: 2001-Jan-06 13:51 By: greg_ball Comment: The extra "period" attribute was only added for debugging! I would take it out again, if only the patch was under my name. ------------------------------------------------------- Date: 2001-Jan-06 13:39 By: greg_ball Comment: Sorry, accidently posted as nobody, somehow my back button logged me out. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103129&group_id=5470 From noreply@sourceforge.net Thu Jan 11 08:11:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 00:11:31 -0800 Subject: [Patches] [Patch #103188] BeOS/ar-fake support for extra libraries Message-ID: Patch #103188 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : nobody Summary: BeOS/ar-fake support for extra libraries ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103188&group_id=5470 From noreply@sourceforge.net Thu Jan 11 09:08:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 01:08:31 -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 : gvanrossum Summary: Make tempfile.mktemp threadsafe Follow-Ups: Date: 2001-Jan-11 01:08 By: tim_one Comment: Guido, I'm briefly assigning this to you just to get an answer to a question: if threads aren't supported on some platform, do we then get an ImportError upon an attempt to do import thread ? If not, then how to check? if "thread" in sys.builtin_module_names? BTW, Tres's test case has surprising behavior on Windows (he ran it on Linux): it reports no errors, but that's because all of them pop up in the os.unlink, after some other thread has already deleted the (same-named!) temp file used by this thread. Then the thread dies because the exception is unhandled. So there's a large burst of errors when the test starts, but that kills off an equally large number of threads, so the test *appears* to get better-behaved over time. Note too that while the Summary line complains about mktemp, the Linux failures are really in TemporaryFile: mktemp returns the same name there sometimes, and there's clearly a race between that and os.open() creating a file of that (shared) name (i.e., mktemp's os.path.exists() test is ineffective in such cases, and os.open() goes on to try to create that file multiple times in O_EXCL mode). I can't fix this without strong exclusion (i.e., a lock) -- or a collection of platform-specific OS services for generating guaranteed-unique temp files (e.g., on Windows there's FILE* tmpfile(void); which returns a unique stream opened in binary update mode). The latter is a lot more work than slopping in a lock, though (e.g., Windows tmpfile attempts to create a file in the current working directory, & that's got problems of its own). ------------------------------------------------------- Date: 2001-Jan-02 09:02 By: tseaver Comment: Here is a testcase for the bug: import threading, StringIO from time import sleep from traceback import print_exc startEvent = threading.Event() quitEvent = threading.Event() SLEEP_INTERVAL = 0.2 class TempFileGreedy( threading.Thread ): """ """ error_count = 0 ok_count = 0 def run( self ): """ """ self.errors = StringIO.StringIO() startEvent.wait() while not quitEvent.isSet(): try: f = tempfile.TemporaryFile( "w+b" ) except: self.error_count = self.error_count + 1 print_exc( file=self.errors ) else: f.close() self.ok_count = self.ok_count + 1 sleep( SLEEP_INTERVAL ) if __name__ == '__main__': import sys if len( sys.argv ) > 1: sys.path.insert( 0, '.' ) import tempfile tempfile.gettempdir() # Do this now, to avoid spurious races later NUM_THREADS = 100 threads = [] print "Creating" for i in range( NUM_THREADS ): t = TempFileGreedy() threads.append( t ) t.start() RUN_INTERVAL = 200.0 print "Starting" startEvent.set() sleep( RUN_INTERVAL ) quitEvent.set() print "Reaping" ok = errors = 0 for thread in threads: thread.join() ok = ok + thread.ok_count errors = errors + thread.error_count if thread.error_count: print '%s errors:\n%s' % ( thread.getName() , thread.errors.getvalue() ) print "Done" print 'OK: %d\nErrors: %d' % ( ok, errors ) ------------------------------------------------------- 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 Jan 11 13:03:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 05:03:20 -0800 Subject: [Patches] [Patch #103134] Support code execution in PTH files Message-ID: Patch #103134 has been updated. Project: python Category: library Status: Closed Submitted by: loewis Assigned to : nobody Summary: Support code execution in PTH files Follow-Ups: Date: 2001-Jan-11 05:03 By: loewis Comment: Committed as site.py 1.23 ------------------------------------------------------- Date: 2001-Jan-10 13:14 By: gvanrossum Comment: This is sooooo cute, I accept it. Martin, please check it in. (Is there any documentation of .pth files at all? Maybe in the docs for the site.py module? Then this should be updated too!) ------------------------------------------------------- Date: 2001-Jan-07 14:36 By: fdrake Comment: I think this is a good idea, but it's not clear that others will agree. Assigning to Guido since this is largely a matter of policy, and I'm not at all sure he'll like the idea. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103134&group_id=5470 From noreply@sourceforge.net Thu Jan 11 14:47:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 06:47:49 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: Patch #103154 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-11 06:47 By: gvanrossum Comment: Reopened at request. Note that I believe that "import termios, TERMIOS" *should fail* -- not all filesystems used on Windows are case preserving. I've had this battle with Mark Hammond before. The case check is intended to prevent you from importing a moduleusing the wrong case (e.g. import String). It is *not* intended to let you have two modules that only differ in case. ------------------------------------------------------- Date: 2001-Jan-10 19:48 By: jlt63 Comment: I have already checked that this patch does not break the Windows VC build before I submitted it. However, Tim is welcome to reverify himself. Unfortunately, I have found a bug with this patch that (only) affects Cygwin. Although this patch handles the following: import String it does not handle the following: import termios, TERMIOS I will resubmit a new version shortly, please change the status back to open. ------------------------------------------------------- Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Thu Jan 11 14:51:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 06:51:56 -0800 Subject: [Patches] [Patch #103179] Memory leak fix - partial fix for bug #127699 Message-ID: Patch #103179 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: cgw Assigned to : cgw Summary: Memory leak fix - partial fix for bug #127699 Follow-Ups: Date: 2001-Jan-11 06:51 By: gvanrossum Comment: Charles checked this in, so I'm closing it now. (Charles, you could have closed it yourself. :-) ------------------------------------------------------- Date: 2001-Jan-10 12:26 By: gvanrossum Comment: Charles, looks good. Check it in! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103179&group_id=5470 From noreply@sourceforge.net Thu Jan 11 15:09:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 07:09:22 -0800 Subject: [Patches] [Patch #103147] restrict dir output in presence of __exports__ Message-ID: Patch #103147 has been updated. Project: python Category: core (C code) Status: Rejected Submitted by: montanaro Assigned to : gvanrossum Summary: restrict dir output in presence of __exports__ Follow-Ups: Date: 2001-Jan-11 07:09 By: gvanrossum Comment: Hm... Since you can still explicitly import something not included in __all__, I think it's appropriate for dir() to still return eveything it sees. ------------------------------------------------------- Date: 2001-Jan-10 11:21 By: montanaro Comment: Rejection is fine (I can take it, really I can ;-). It seems to me that making dir() match what "from ... import *" would import is a good thing. I strongly urge you to consider that possibility. S ------------------------------------------------------- Date: 2001-Jan-10 11:16 By: gvanrossum Comment: Rejected after recent python-dev discussions. We'll implement __all__, to be used only by from...import *. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103147&group_id=5470 From noreply@sourceforge.net Thu Jan 11 15:56:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 07:56:48 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: Patch #103154 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-11 07:56 By: jlt63 Comment: Actually, this is not a bug in my original version. Cygwin Python is behaving identically to the Win32 one. Unfortunately, as you pointed out Win32 Python definitely does not handle the situation of two modules that only differ by case. Sigh... If one tries to import the second module that would be found in sys.path, then a NameError: Case mismatch ... exception will *always* be generated. I'm not sure that I agree with this behavior but I really a UNIX guy. Since Cygwin Python should support as many UNIX modules as possible, it needs to deal with modules that only differ by case. termios and TERMIOS used by getpass is a perfect example. I have created a (hacky) patch, that solves this problem for both Cygwin and Win32. I can redo it so that it only affects Cygwin and leaves the Win32 functionality alone. I would like to upload it for discussion but I am concerned about overwriting the old version. Should I upload it anyway? ------------------------------------------------------- Date: 2001-Jan-11 06:47 By: gvanrossum Comment: Reopened at request. Note that I believe that "import termios, TERMIOS" *should fail* -- not all filesystems used on Windows are case preserving. I've had this battle with Mark Hammond before. The case check is intended to prevent you from importing a moduleusing the wrong case (e.g. import String). It is *not* intended to let you have two modules that only differ in case. ------------------------------------------------------- Date: 2001-Jan-10 19:48 By: jlt63 Comment: I have already checked that this patch does not break the Windows VC build before I submitted it. However, Tim is welcome to reverify himself. Unfortunately, I have found a bug with this patch that (only) affects Cygwin. Although this patch handles the following: import String it does not handle the following: import termios, TERMIOS I will resubmit a new version shortly, please change the status back to open. ------------------------------------------------------- Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Thu Jan 11 16:43:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 08:43:31 -0800 Subject: [Patches] [Patch #103200] from foo import * respects __all__ Message-ID: Patch #103200 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nobody Assigned to : nobody Summary: from foo import * respects __all__ ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103200&group_id=5470 From noreply@sourceforge.net Thu Jan 11 18:24:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 10:24:04 -0800 Subject: [Patches] [Patch #103147] restrict dir output in presence of __exports__ Message-ID: Patch #103147 has been updated. Project: python Category: core (C code) Status: Rejected Submitted by: montanaro Assigned to : gvanrossum Summary: restrict dir output in presence of __exports__ Follow-Ups: Date: 2001-Jan-11 10:24 By: nascheme Comment: Maybe the elusive help() function should use __all__ when passed a module or a class. It could also (optionally?) print doc strings for things it finds. New users could then be taught to use help() instead of dir(). I like to use dir() when debugging things interactively. Making only show names in __exports__ would be frustrating. ------------------------------------------------------- Date: 2001-Jan-11 07:09 By: gvanrossum Comment: Hm... Since you can still explicitly import something not included in __all__, I think it's appropriate for dir() to still return eveything it sees. ------------------------------------------------------- Date: 2001-Jan-10 11:21 By: montanaro Comment: Rejection is fine (I can take it, really I can ;-). It seems to me that making dir() match what "from ... import *" would import is a good thing. I strongly urge you to consider that possibility. S ------------------------------------------------------- Date: 2001-Jan-10 11:16 By: gvanrossum Comment: Rejected after recent python-dev discussions. We'll implement __all__, to be used only by from...import *. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103147&group_id=5470 From noreply@sourceforge.net Thu Jan 11 20:07:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 12:07:01 -0800 Subject: [Patches] [Patch #103202] fix bug parsing nested tags with htmllib Message-ID: Patch #103202 has been updated. Project: python Category: library Status: Open Submitted by: fbremmer Assigned to : nobody Summary: fix bug parsing nested tags with htmllib ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103202&group_id=5470 From noreply@sourceforge.net Thu Jan 11 20:15:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 12:15:23 -0800 Subject: [Patches] [Patch #103202] fix bug parsing nested tags with htmllib Message-ID: Patch #103202 has been updated. Project: python Category: library Status: Open Submitted by: fbremmer Assigned to : nobody Summary: fix bug parsing nested tags with htmllib Follow-Ups: Date: 2001-Jan-11 12:15 By: fbremmer Comment:

#! /usr/bin/env python
import htmllib, formatter
  
class MyParser(htmllib.HTMLParser):
    def __init__(self, formatterObject):
        htmllib.HTMLParser.__init__(self, formatterObject)
        self.text = ''
    def start_tag(self, attributes):
        self.save_bgn()
    def end_tag(self):
        self.text = self.save_end()

html = """"""
parser=MyParser(formatter.NullFormatter())

parser.nofill = 1
parser.feed(html)
parser.close()
print parser.text  # prints None instead of nothing

parser.nofill = 0
parser.feed(html)
parser.close()
print parser.text  # raises exception trying to call None.split()

------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103202&group_id=5470 From noreply@sourceforge.net Thu Jan 11 20:51:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 12:51:54 -0800 Subject: [Patches] [Patch #103200] from foo import * respects __all__ Message-ID: Patch #103200 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nobody Assigned to : gvanrossum Summary: from foo import * respects __all__ ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103200&group_id=5470 From noreply@sourceforge.net Thu Jan 11 21:39:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 13:39:58 -0800 Subject: [Patches] [Patch #103200] from foo import * respects __all__ Message-ID: Patch #103200 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nobody Assigned to : gvanrossum Summary: from foo import * respects __all__ Follow-Ups: Date: 2001-Jan-11 13:39 By: gvanrossum Comment: Thanks -- I'll merge this with the partial code I had for this myself. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103200&group_id=5470 From noreply@sourceforge.net Thu Jan 11 21:44:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 13:44:16 -0800 Subject: [Patches] [Patch #103202] fix bug parsing nested tags with htmllib Message-ID: Patch #103202 has been updated. Project: python Category: library Status: Rejected Submitted by: fbremmer Assigned to : gvanrossum Summary: fix bug parsing nested tags with htmllib Follow-Ups: Date: 2001-Jan-11 13:44 By: gvanrossum Comment: Rejected. The savedata mechanism is intended only for things like ; it shouldn't be used for tags that may be nested. Your example program is invalid. Your patch would cause all data to be saved all the time, even when no tag is interested in saving data. ------------------------------------------------------- Date: 2001-Jan-11 12:15 By: fbremmer Comment: <pre> #! /usr/bin/env python import htmllib, formatter class MyParser(htmllib.HTMLParser): def __init__(self, formatterObject): htmllib.HTMLParser.__init__(self, formatterObject) self.text = '' def start_tag(self, attributes): self.save_bgn() def end_tag(self): self.text = self.save_end() html = """<tag><tag></tag></tag>""" parser=MyParser(formatter.NullFormatter()) parser.nofill = 1 parser.feed(html) parser.close() print parser.text # prints None instead of nothing parser.nofill = 0 parser.feed(html) parser.close() print parser.text # raises exception trying to call None.split() </pre> ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103202&group_id=5470 From noreply@sourceforge.net Thu Jan 11 21:59:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 13:59:42 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: <E14Gpl0-00016l-00@usw-sf-web3.sourceforge.net> Patch #103154 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-11 13:59 By: gvanrossum Comment: Upload it as a new patch. But I believe the solution is that the TERMIOS module should be renamed. ------------------------------------------------------- Date: 2001-Jan-11 07:56 By: jlt63 Comment: Actually, this is not a bug in my original version. Cygwin Python is behaving identically to the Win32 one. Unfortunately, as you pointed out Win32 Python definitely does not handle the situation of two modules that only differ by case. Sigh... If one tries to import the second module that would be found in sys.path, then a NameError: Case mismatch ... exception will *always* be generated. I'm not sure that I agree with this behavior but I really a UNIX guy. Since Cygwin Python should support as many UNIX modules as possible, it needs to deal with modules that only differ by case. termios and TERMIOS used by getpass is a perfect example. I have created a (hacky) patch, that solves this problem for both Cygwin and Win32. I can redo it so that it only affects Cygwin and leaves the Win32 functionality alone. I would like to upload it for discussion but I am concerned about overwriting the old version. Should I upload it anyway? ------------------------------------------------------- Date: 2001-Jan-11 06:47 By: gvanrossum Comment: Reopened at request. Note that I believe that "import termios, TERMIOS" *should fail* -- not all filesystems used on Windows are case preserving. I've had this battle with Mark Hammond before. The case check is intended to prevent you from importing a moduleusing the wrong case (e.g. import String). It is *not* intended to let you have two modules that only differ in case. ------------------------------------------------------- Date: 2001-Jan-10 19:48 By: jlt63 Comment: I have already checked that this patch does not break the Windows VC build before I submitted it. However, Tim is welcome to reverify himself. Unfortunately, I have found a bug with this patch that (only) affects Cygwin. Although this patch handles the following: import String it does not handle the following: import termios, TERMIOS I will resubmit a new version shortly, please change the status back to open. ------------------------------------------------------- Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler <jt@dothill.com> * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Thu Jan 11 22:04:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 14:04:15 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14GppP-00018R-00@usw-sf-web3.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : nobody Summary: PEP 205: weak references implementation ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Thu Jan 11 22:05:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 14:05:53 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14Gpqz-000194-00@usw-sf-web3.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : loewis Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Thu Jan 11 23:27:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 15:27:53 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14Gr8L-0001e1-00@usw-sf-web3.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : loewis Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Fri Jan 12 03:08:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 19:08:08 -0800 Subject: [Patches] [Patch #103028] Make tempfile.mktemp threadsafe Message-ID: <E14GuZU-0007VY-00@usw-sf-web2.sourceforge.net> 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: 2001-Jan-11 19:08 By: tim_one Comment: Assigned back to me, cuz I got my question answered. I'll check in a related patch later tonight. ------------------------------------------------------- Date: 2001-Jan-11 01:08 By: tim_one Comment: Guido, I'm briefly assigning this to you just to get an answer to a question: if threads aren't supported on some platform, do we then get an ImportError upon an attempt to do import thread ? If not, then how to check? if "thread" in sys.builtin_module_names? BTW, Tres's test case has surprising behavior on Windows (he ran it on Linux): it reports no errors, but that's because all of them pop up in the os.unlink, after some other thread has already deleted the (same-named!) temp file used by this thread. Then the thread dies because the exception is unhandled. So there's a large burst of errors when the test starts, but that kills off an equally large number of threads, so the test *appears* <wink> to get better-behaved over time. Note too that while the Summary line complains about mktemp, the Linux failures are really in TemporaryFile: mktemp returns the same name there sometimes, and there's clearly a race between that and os.open() creating a file of that (shared) name (i.e., mktemp's os.path.exists() test is ineffective in such cases, and os.open() goes on to try to create that file multiple times in O_EXCL mode). I can't fix this without strong exclusion (i.e., a lock) -- or a collection of platform-specific OS services for generating guaranteed-unique temp files (e.g., on Windows there's FILE* tmpfile(void); which returns a unique stream opened in binary update mode). The latter is a lot more work than slopping in a lock, though (e.g., Windows tmpfile attempts to create a file in the current working directory, & that's got problems of its own). ------------------------------------------------------- Date: 2001-Jan-02 09:02 By: tseaver Comment: Here is a testcase for the bug: import threading, StringIO from time import sleep from traceback import print_exc startEvent = threading.Event() quitEvent = threading.Event() SLEEP_INTERVAL = 0.2 class TempFileGreedy( threading.Thread ): """ """ error_count = 0 ok_count = 0 def run( self ): """ """ self.errors = StringIO.StringIO() startEvent.wait() while not quitEvent.isSet(): try: f = tempfile.TemporaryFile( "w+b" ) except: self.error_count = self.error_count + 1 print_exc( file=self.errors ) else: f.close() self.ok_count = self.ok_count + 1 sleep( SLEEP_INTERVAL ) if __name__ == '__main__': import sys if len( sys.argv ) > 1: sys.path.insert( 0, '.' ) import tempfile tempfile.gettempdir() # Do this now, to avoid spurious races later NUM_THREADS = 100 threads = [] print "Creating" for i in range( NUM_THREADS ): t = TempFileGreedy() threads.append( t ) t.start() RUN_INTERVAL = 200.0 print "Starting" startEvent.set() sleep( RUN_INTERVAL ) quitEvent.set() print "Reaping" ok = errors = 0 for thread in threads: thread.join() ok = ok + thread.ok_count errors = errors + thread.error_count if thread.error_count: print '%s errors:\n%s' % ( thread.getName() , thread.errors.getvalue() ) print "Done" print 'OK: %d\nErrors: %d' % ( ok, errors ) ------------------------------------------------------- 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 Fri Jan 12 06:03:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 22:03:03 -0800 Subject: [Patches] [Patch #103200] from foo import * respects __all__ Message-ID: <E14GxIl-0002um-00@usw-sf-web3.sourceforge.net> Patch #103200 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nobody Assigned to : gvanrossum Summary: from foo import * respects __all__ Follow-Ups: Date: 2001-Jan-11 22:03 By: moshez Comment: Note: this patch also makes *any* Python object with an __all__ attribute valid for "from foo import *" (this comment is partially a test for whether I can post comments...) ------------------------------------------------------- Date: 2001-Jan-11 13:39 By: gvanrossum Comment: Thanks -- I'll merge this with the partial code I had for this myself. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103200&group_id=5470 From noreply@sourceforge.net Fri Jan 12 09:00:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 01:00:10 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14H04A-000650-00@usw-sf-web1.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : loewis Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Fri Jan 12 09:53:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 01:53:01 -0800 Subject: [Patches] [Patch #103211] webbrowser.py: fix spelling of "Konqueror" Message-ID: <E14H0tJ-0006MD-00@usw-sf-web1.sourceforge.net> Patch #103211 has been updated. Project: python Category: library Status: Open Submitted by: ping Assigned to : nobody Summary: webbrowser.py: fix spelling of "Konqueror" ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103211&group_id=5470 From noreply@sourceforge.net Fri Jan 12 10:08:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 02:08:38 -0800 Subject: [Patches] [Patch #103028] Make tempfile.mktemp threadsafe Message-ID: <E14H18Q-0006SW-00@usw-sf-web1.sourceforge.net> Patch #103028 has been updated. Project: python Category: library Status: Open Submitted by: nobody Assigned to : gvanrossum Summary: Make tempfile.mktemp threadsafe Follow-Ups: Date: 2001-Jan-12 02:08 By: tim_one Comment: I checked in a related patch, tempfile.py rev 1.23. Assigned to Guido hoping to shame him into testing this on Linux (if you don't want to, please assign to someone else -- whoever gives it a clean bill of Linux health should Close this). It's been tested brutally on Windows (my disk is still smoking <wink>). Also needs testing on a platform without threads. With mixed feelings, I did not check in the test case: it takes a long time to run. But a brief test that doesn't create lots of threads and run for a long time is too likely to pass by sheer luck even if the code is broken. ------------------------------------------------------- Date: 2001-Jan-11 19:08 By: tim_one Comment: Assigned back to me, cuz I got my question answered. I'll check in a related patch later tonight. ------------------------------------------------------- Date: 2001-Jan-11 01:08 By: tim_one Comment: Guido, I'm briefly assigning this to you just to get an answer to a question: if threads aren't supported on some platform, do we then get an ImportError upon an attempt to do import thread ? If not, then how to check? if "thread" in sys.builtin_module_names? BTW, Tres's test case has surprising behavior on Windows (he ran it on Linux): it reports no errors, but that's because all of them pop up in the os.unlink, after some other thread has already deleted the (same-named!) temp file used by this thread. Then the thread dies because the exception is unhandled. So there's a large burst of errors when the test starts, but that kills off an equally large number of threads, so the test *appears* <wink> to get better-behaved over time. Note too that while the Summary line complains about mktemp, the Linux failures are really in TemporaryFile: mktemp returns the same name there sometimes, and there's clearly a race between that and os.open() creating a file of that (shared) name (i.e., mktemp's os.path.exists() test is ineffective in such cases, and os.open() goes on to try to create that file multiple times in O_EXCL mode). I can't fix this without strong exclusion (i.e., a lock) -- or a collection of platform-specific OS services for generating guaranteed-unique temp files (e.g., on Windows there's FILE* tmpfile(void); which returns a unique stream opened in binary update mode). The latter is a lot more work than slopping in a lock, though (e.g., Windows tmpfile attempts to create a file in the current working directory, & that's got problems of its own). ------------------------------------------------------- Date: 2001-Jan-02 09:02 By: tseaver Comment: Here is a testcase for the bug: import threading, StringIO from time import sleep from traceback import print_exc startEvent = threading.Event() quitEvent = threading.Event() SLEEP_INTERVAL = 0.2 class TempFileGreedy( threading.Thread ): """ """ error_count = 0 ok_count = 0 def run( self ): """ """ self.errors = StringIO.StringIO() startEvent.wait() while not quitEvent.isSet(): try: f = tempfile.TemporaryFile( "w+b" ) except: self.error_count = self.error_count + 1 print_exc( file=self.errors ) else: f.close() self.ok_count = self.ok_count + 1 sleep( SLEEP_INTERVAL ) if __name__ == '__main__': import sys if len( sys.argv ) > 1: sys.path.insert( 0, '.' ) import tempfile tempfile.gettempdir() # Do this now, to avoid spurious races later NUM_THREADS = 100 threads = [] print "Creating" for i in range( NUM_THREADS ): t = TempFileGreedy() threads.append( t ) t.start() RUN_INTERVAL = 200.0 print "Starting" startEvent.set() sleep( RUN_INTERVAL ) quitEvent.set() print "Reaping" ok = errors = 0 for thread in threads: thread.join() ok = ok + thread.ok_count errors = errors + thread.error_count if thread.error_count: print '%s errors:\n%s' % ( thread.getName() , thread.errors.getvalue() ) print "Done" print 'OK: %d\nErrors: %d' % ( ok, errors ) ------------------------------------------------------- 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 Fri Jan 12 14:23:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 06:23:23 -0800 Subject: [Patches] [Patch #103211] webbrowser.py: fix spelling of "Konqueror" Message-ID: <E14H56x-0002da-00@usw-sf-web2.sourceforge.net> Patch #103211 has been updated. Project: python Category: library Status: Accepted Submitted by: ping Assigned to : ping Summary: webbrowser.py: fix spelling of "Konqueror" Follow-Ups: Date: 2001-Jan-12 06:23 By: gvanrossum Comment: Check it in, Ping! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103211&group_id=5470 From noreply@sourceforge.net Fri Jan 12 14:56:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 06:56:23 -0800 Subject: [Patches] [Patch #103028] Make tempfile.mktemp threadsafe Message-ID: <E14H5ct-0002v6-00@usw-sf-web2.sourceforge.net> Patch #103028 has been updated. Project: python Category: library Status: Closed Submitted by: nobody Assigned to : gvanrossum Summary: Make tempfile.mktemp threadsafe Follow-Ups: Date: 2001-Jan-12 06:56 By: gvanrossum Comment: Works for me on Linux -- both with threads enabled and disabled. Tres's test code gives me no errors. So closing this patch now. ------------------------------------------------------- Date: 2001-Jan-12 02:08 By: tim_one Comment: I checked in a related patch, tempfile.py rev 1.23. Assigned to Guido hoping to shame him into testing this on Linux (if you don't want to, please assign to someone else -- whoever gives it a clean bill of Linux health should Close this). It's been tested brutally on Windows (my disk is still smoking <wink>). Also needs testing on a platform without threads. With mixed feelings, I did not check in the test case: it takes a long time to run. But a brief test that doesn't create lots of threads and run for a long time is too likely to pass by sheer luck even if the code is broken. ------------------------------------------------------- Date: 2001-Jan-11 19:08 By: tim_one Comment: Assigned back to me, cuz I got my question answered. I'll check in a related patch later tonight. ------------------------------------------------------- Date: 2001-Jan-11 01:08 By: tim_one Comment: Guido, I'm briefly assigning this to you just to get an answer to a question: if threads aren't supported on some platform, do we then get an ImportError upon an attempt to do import thread ? If not, then how to check? if "thread" in sys.builtin_module_names? BTW, Tres's test case has surprising behavior on Windows (he ran it on Linux): it reports no errors, but that's because all of them pop up in the os.unlink, after some other thread has already deleted the (same-named!) temp file used by this thread. Then the thread dies because the exception is unhandled. So there's a large burst of errors when the test starts, but that kills off an equally large number of threads, so the test *appears* <wink> to get better-behaved over time. Note too that while the Summary line complains about mktemp, the Linux failures are really in TemporaryFile: mktemp returns the same name there sometimes, and there's clearly a race between that and os.open() creating a file of that (shared) name (i.e., mktemp's os.path.exists() test is ineffective in such cases, and os.open() goes on to try to create that file multiple times in O_EXCL mode). I can't fix this without strong exclusion (i.e., a lock) -- or a collection of platform-specific OS services for generating guaranteed-unique temp files (e.g., on Windows there's FILE* tmpfile(void); which returns a unique stream opened in binary update mode). The latter is a lot more work than slopping in a lock, though (e.g., Windows tmpfile attempts to create a file in the current working directory, & that's got problems of its own). ------------------------------------------------------- Date: 2001-Jan-02 09:02 By: tseaver Comment: Here is a testcase for the bug: import threading, StringIO from time import sleep from traceback import print_exc startEvent = threading.Event() quitEvent = threading.Event() SLEEP_INTERVAL = 0.2 class TempFileGreedy( threading.Thread ): """ """ error_count = 0 ok_count = 0 def run( self ): """ """ self.errors = StringIO.StringIO() startEvent.wait() while not quitEvent.isSet(): try: f = tempfile.TemporaryFile( "w+b" ) except: self.error_count = self.error_count + 1 print_exc( file=self.errors ) else: f.close() self.ok_count = self.ok_count + 1 sleep( SLEEP_INTERVAL ) if __name__ == '__main__': import sys if len( sys.argv ) > 1: sys.path.insert( 0, '.' ) import tempfile tempfile.gettempdir() # Do this now, to avoid spurious races later NUM_THREADS = 100 threads = [] print "Creating" for i in range( NUM_THREADS ): t = TempFileGreedy() threads.append( t ) t.start() RUN_INTERVAL = 200.0 print "Starting" startEvent.set() sleep( RUN_INTERVAL ) quitEvent.set() print "Reaping" ok = errors = 0 for thread in threads: thread.join() ok = ok + thread.ok_count errors = errors + thread.error_count if thread.error_count: print '%s errors:\n%s' % ( thread.getName() , thread.errors.getvalue() ) print "Done" print 'OK: %d\nErrors: %d' % ( ok, errors ) ------------------------------------------------------- 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 Fri Jan 12 14:57:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 06:57:25 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: <E14H5dt-0002vW-00@usw-sf-web2.sourceforge.net> Patch #103154 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-11 13:59 By: gvanrossum Comment: Upload it as a new patch. But I believe the solution is that the TERMIOS module should be renamed. ------------------------------------------------------- Date: 2001-Jan-11 07:56 By: jlt63 Comment: Actually, this is not a bug in my original version. Cygwin Python is behaving identically to the Win32 one. Unfortunately, as you pointed out Win32 Python definitely does not handle the situation of two modules that only differ by case. Sigh... If one tries to import the second module that would be found in sys.path, then a NameError: Case mismatch ... exception will *always* be generated. I'm not sure that I agree with this behavior but I really a UNIX guy. Since Cygwin Python should support as many UNIX modules as possible, it needs to deal with modules that only differ by case. termios and TERMIOS used by getpass is a perfect example. I have created a (hacky) patch, that solves this problem for both Cygwin and Win32. I can redo it so that it only affects Cygwin and leaves the Win32 functionality alone. I would like to upload it for discussion but I am concerned about overwriting the old version. Should I upload it anyway? ------------------------------------------------------- Date: 2001-Jan-11 06:47 By: gvanrossum Comment: Reopened at request. Note that I believe that "import termios, TERMIOS" *should fail* -- not all filesystems used on Windows are case preserving. I've had this battle with Mark Hammond before. The case check is intended to prevent you from importing a moduleusing the wrong case (e.g. import String). It is *not* intended to let you have two modules that only differ in case. ------------------------------------------------------- Date: 2001-Jan-10 19:48 By: jlt63 Comment: I have already checked that this patch does not break the Windows VC build before I submitted it. However, Tim is welcome to reverify himself. Unfortunately, I have found a bug with this patch that (only) affects Cygwin. Although this patch handles the following: import String it does not handle the following: import termios, TERMIOS I will resubmit a new version shortly, please change the status back to open. ------------------------------------------------------- Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler <jt@dothill.com> * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Fri Jan 12 16:06:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 08:06:17 -0800 Subject: [Patches] [Patch #102681] issubclass() and isinstance() error messages Message-ID: <E14H6iX-0008Ur-00@usw-sf-web1.sourceforge.net> Patch #102681 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: ping Assigned to : gvanrossum Summary: issubclass() and isinstance() error messages Follow-Ups: Date: 2001-Jan-12 08:06 By: gvanrossum Comment: I've checked in a slightly modified version of this. I fixed the errors in abstract_issubclass() to say that arg 1 or arg 2 must be a class, not mentioning the possibility that it could be a type -- in fact, a type isn't allowed (unless it has __bases__). I also changed builtin_isinstance() so that it doesn't override the error from abstract_issubclass() unless it' a TypeError (theoretically it could raise a MemoryError too). ------------------------------------------------------- Date: 2001-Jan-04 18:41 By: gvanrossum Comment: Ping, please answer my question! ------------------------------------------------------- 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 Fri Jan 12 16:24:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 08:24:57 -0800 Subject: [Patches] [Patch #103200] from foo import * respects __all__ Message-ID: <E14H70b-0003Se-00@usw-sf-web2.sourceforge.net> Patch #103200 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: nobody Assigned to : gvanrossum Summary: from foo import * respects __all__ Follow-Ups: Date: 2001-Jan-12 08:24 By: gvanrossum Comment: I've checked in something similar. (Note that your code leaks the value of __all__;-) ------------------------------------------------------- Date: 2001-Jan-11 22:03 By: moshez Comment: Note: this patch also makes *any* Python object with an __all__ attribute valid for "from foo import *" (this comment is partially a test for whether I can post comments...) ------------------------------------------------------- Date: 2001-Jan-11 13:39 By: gvanrossum Comment: Thanks -- I'll merge this with the partial code I had for this myself. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103200&group_id=5470 From noreply@sourceforge.net Fri Jan 12 16:28:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 08:28:17 -0800 Subject: [Patches] [Patch #103185] Some more standard modules cleanup for Cygwin Message-ID: <E14H73p-0003UK-00@usw-sf-web2.sourceforge.net> Patch #103185 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jlt63 Assigned to : gvanrossum Summary: Some more standard modules cleanup for Cygwin Follow-Ups: Date: 2001-Jan-10 21:19 By: jlt63 Comment: Use the following procedure to patch: $ cd Modules $ # save modules.patch to current directory $ patch <modules.patch ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103185&group_id=5470 From noreply@sourceforge.net Fri Jan 12 16:28:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 08:28:24 -0800 Subject: [Patches] [Patch #103188] BeOS/ar-fake support for extra libraries Message-ID: <E14H73w-0003US-00@usw-sf-web2.sourceforge.net> Patch #103188 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : gvanrossum Summary: BeOS/ar-fake support for extra libraries ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103188&group_id=5470 From noreply@sourceforge.net Fri Jan 12 17:44:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 09:44:51 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: <E14H8Fv-0003wZ-00@usw-sf-web2.sourceforge.net> Patch #103154 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-12 09:44 By: jlt63 Comment: I just uploaded a new patch. It fixes the case sensitive import problem for Cygwin without affecting Win32 (i.e., Win32 functions as before). Now Cygwin's import behavior is identical to other UNIX platforms. I'm not completely happy with the patch and would characterize it as hacky, but it is the best that I can do without fully grokking import.c. I think to do better would require major rework to find_module(). I guess by renaming TERMIOS you mean to change the module names generated by h2py.py. I have no issue with this -- will others? I thought all filesystems on Windows 95/NT 3.51 and later, were case preserving. To what filesystems and Windows versions are you referring? ------------------------------------------------------- Date: 2001-Jan-11 13:59 By: gvanrossum Comment: Upload it as a new patch. But I believe the solution is that the TERMIOS module should be renamed. ------------------------------------------------------- Date: 2001-Jan-11 07:56 By: jlt63 Comment: Actually, this is not a bug in my original version. Cygwin Python is behaving identically to the Win32 one. Unfortunately, as you pointed out Win32 Python definitely does not handle the situation of two modules that only differ by case. Sigh... If one tries to import the second module that would be found in sys.path, then a NameError: Case mismatch ... exception will *always* be generated. I'm not sure that I agree with this behavior but I really a UNIX guy. Since Cygwin Python should support as many UNIX modules as possible, it needs to deal with modules that only differ by case. termios and TERMIOS used by getpass is a perfect example. I have created a (hacky) patch, that solves this problem for both Cygwin and Win32. I can redo it so that it only affects Cygwin and leaves the Win32 functionality alone. I would like to upload it for discussion but I am concerned about overwriting the old version. Should I upload it anyway? ------------------------------------------------------- Date: 2001-Jan-11 06:47 By: gvanrossum Comment: Reopened at request. Note that I believe that "import termios, TERMIOS" *should fail* -- not all filesystems used on Windows are case preserving. I've had this battle with Mark Hammond before. The case check is intended to prevent you from importing a moduleusing the wrong case (e.g. import String). It is *not* intended to let you have two modules that only differ in case. ------------------------------------------------------- Date: 2001-Jan-10 19:48 By: jlt63 Comment: I have already checked that this patch does not break the Windows VC build before I submitted it. However, Tim is welcome to reverify himself. Unfortunately, I have found a bug with this patch that (only) affects Cygwin. Although this patch handles the following: import String it does not handle the following: import termios, TERMIOS I will resubmit a new version shortly, please change the status back to open. ------------------------------------------------------- Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler <jt@dothill.com> * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Fri Jan 12 17:50:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 09:50:05 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: <E14H8Kz-0003zQ-00@usw-sf-web2.sourceforge.net> Patch #103154 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-12 09:50 By: jlt63 Comment: Oops... Use the following procedure to patch: $ cd Python $ # save case.patch to current directory $ patch <case.patch ------------------------------------------------------- Date: 2001-Jan-12 09:44 By: jlt63 Comment: I just uploaded a new patch. It fixes the case sensitive import problem for Cygwin without affecting Win32 (i.e., Win32 functions as before). Now Cygwin's import behavior is identical to other UNIX platforms. I'm not completely happy with the patch and would characterize it as hacky, but it is the best that I can do without fully grokking import.c. I think to do better would require major rework to find_module(). I guess by renaming TERMIOS you mean to change the module names generated by h2py.py. I have no issue with this -- will others? I thought all filesystems on Windows 95/NT 3.51 and later, were case preserving. To what filesystems and Windows versions are you referring? ------------------------------------------------------- Date: 2001-Jan-11 13:59 By: gvanrossum Comment: Upload it as a new patch. But I believe the solution is that the TERMIOS module should be renamed. ------------------------------------------------------- Date: 2001-Jan-11 07:56 By: jlt63 Comment: Actually, this is not a bug in my original version. Cygwin Python is behaving identically to the Win32 one. Unfortunately, as you pointed out Win32 Python definitely does not handle the situation of two modules that only differ by case. Sigh... If one tries to import the second module that would be found in sys.path, then a NameError: Case mismatch ... exception will *always* be generated. I'm not sure that I agree with this behavior but I really a UNIX guy. Since Cygwin Python should support as many UNIX modules as possible, it needs to deal with modules that only differ by case. termios and TERMIOS used by getpass is a perfect example. I have created a (hacky) patch, that solves this problem for both Cygwin and Win32. I can redo it so that it only affects Cygwin and leaves the Win32 functionality alone. I would like to upload it for discussion but I am concerned about overwriting the old version. Should I upload it anyway? ------------------------------------------------------- Date: 2001-Jan-11 06:47 By: gvanrossum Comment: Reopened at request. Note that I believe that "import termios, TERMIOS" *should fail* -- not all filesystems used on Windows are case preserving. I've had this battle with Mark Hammond before. The case check is intended to prevent you from importing a moduleusing the wrong case (e.g. import String). It is *not* intended to let you have two modules that only differ in case. ------------------------------------------------------- Date: 2001-Jan-10 19:48 By: jlt63 Comment: I have already checked that this patch does not break the Windows VC build before I submitted it. However, Tim is welcome to reverify himself. Unfortunately, I have found a bug with this patch that (only) affects Cygwin. Although this patch handles the following: import String it does not handle the following: import termios, TERMIOS I will resubmit a new version shortly, please change the status back to open. ------------------------------------------------------- Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler <jt@dothill.com> * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Fri Jan 12 17:59:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 09:59:01 -0800 Subject: [Patches] [Patch #103216] Auto-detect dbmmodule and build dynamically Message-ID: <E14H8Td-00043Z-00@usw-sf-web2.sourceforge.net> Patch #103216 has been updated. Project: python Category: Build Status: Open Submitted by: bwarsaw Assigned to : nobody Summary: Auto-detect dbmmodule and build dynamically ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103216&group_id=5470 From noreply@sourceforge.net Fri Jan 12 18:00:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 10:00:46 -0800 Subject: [Patches] [Patch #103216] Auto-detect dbmmodule and build dynamically Message-ID: <E14H8VK-00044v-00@usw-sf-web2.sourceforge.net> Patch #103216 has been updated. Project: python Category: Build Status: Open Submitted by: bwarsaw Assigned to : gvanrossum Summary: Auto-detect dbmmodule and build dynamically Follow-Ups: Date: 2001-Jan-12 10:00 By: bwarsaw Comment: Note, I had to rip out the diff to configure because SF complained about the size of the patch. :( Since that can be generated from configure.in, I'm not worrying about it. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103216&group_id=5470 From noreply@sourceforge.net Fri Jan 12 18:26:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 10:26:40 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: <E14H8uO-0004FF-00@usw-sf-web2.sourceforge.net> Patch #103154 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-12 10:26 By: tim_one Comment: The filesystems do preserve the case of names. But all platform file *lookup* APIs are case-insensitive. ------------------------------------------------------- Date: 2001-Jan-12 09:50 By: jlt63 Comment: Oops... Use the following procedure to patch: $ cd Python $ # save case.patch to current directory $ patch <case.patch ------------------------------------------------------- Date: 2001-Jan-12 09:44 By: jlt63 Comment: I just uploaded a new patch. It fixes the case sensitive import problem for Cygwin without affecting Win32 (i.e., Win32 functions as before). Now Cygwin's import behavior is identical to other UNIX platforms. I'm not completely happy with the patch and would characterize it as hacky, but it is the best that I can do without fully grokking import.c. I think to do better would require major rework to find_module(). I guess by renaming TERMIOS you mean to change the module names generated by h2py.py. I have no issue with this -- will others? I thought all filesystems on Windows 95/NT 3.51 and later, were case preserving. To what filesystems and Windows versions are you referring? ------------------------------------------------------- Date: 2001-Jan-11 13:59 By: gvanrossum Comment: Upload it as a new patch. But I believe the solution is that the TERMIOS module should be renamed. ------------------------------------------------------- Date: 2001-Jan-11 07:56 By: jlt63 Comment: Actually, this is not a bug in my original version. Cygwin Python is behaving identically to the Win32 one. Unfortunately, as you pointed out Win32 Python definitely does not handle the situation of two modules that only differ by case. Sigh... If one tries to import the second module that would be found in sys.path, then a NameError: Case mismatch ... exception will *always* be generated. I'm not sure that I agree with this behavior but I really a UNIX guy. Since Cygwin Python should support as many UNIX modules as possible, it needs to deal with modules that only differ by case. termios and TERMIOS used by getpass is a perfect example. I have created a (hacky) patch, that solves this problem for both Cygwin and Win32. I can redo it so that it only affects Cygwin and leaves the Win32 functionality alone. I would like to upload it for discussion but I am concerned about overwriting the old version. Should I upload it anyway? ------------------------------------------------------- Date: 2001-Jan-11 06:47 By: gvanrossum Comment: Reopened at request. Note that I believe that "import termios, TERMIOS" *should fail* -- not all filesystems used on Windows are case preserving. I've had this battle with Mark Hammond before. The case check is intended to prevent you from importing a moduleusing the wrong case (e.g. import String). It is *not* intended to let you have two modules that only differ in case. ------------------------------------------------------- Date: 2001-Jan-10 19:48 By: jlt63 Comment: I have already checked that this patch does not break the Windows VC build before I submitted it. However, Tim is welcome to reverify himself. Unfortunately, I have found a bug with this patch that (only) affects Cygwin. Although this patch handles the following: import String it does not handle the following: import termios, TERMIOS I will resubmit a new version shortly, please change the status back to open. ------------------------------------------------------- Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler <jt@dothill.com> * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Fri Jan 12 18:32:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 10:32:25 -0800 Subject: [Patches] [Patch #103217] prevent htmllib from calling None.split() Message-ID: <E14H8zx-0004Hl-00@usw-sf-web2.sourceforge.net> Patch #103217 has been updated. Project: python Category: library Status: Open Submitted by: fbremmer Assigned to : nobody Summary: prevent htmllib from calling None.split() ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103217&group_id=5470 From noreply@sourceforge.net Fri Jan 12 18:47:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 10:47:08 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: <E14H9EC-0004Mr-00@usw-sf-web2.sourceforge.net> Patch #103154 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-12 10:47 By: jlt63 Comment: I know. I was just confused by the following On 2001-Jan-11 06:47, gvanrossum wrote: > Note that I believe that "import termios, TERMIOS" *should fail* -- not all > filesystems used on Windows are case preserving. ------------------------------------------------------- Date: 2001-Jan-12 10:26 By: tim_one Comment: The filesystems do preserve the case of names. But all platform file *lookup* APIs are case-insensitive. ------------------------------------------------------- Date: 2001-Jan-12 09:50 By: jlt63 Comment: Oops... Use the following procedure to patch: $ cd Python $ # save case.patch to current directory $ patch <case.patch ------------------------------------------------------- Date: 2001-Jan-12 09:44 By: jlt63 Comment: I just uploaded a new patch. It fixes the case sensitive import problem for Cygwin without affecting Win32 (i.e., Win32 functions as before). Now Cygwin's import behavior is identical to other UNIX platforms. I'm not completely happy with the patch and would characterize it as hacky, but it is the best that I can do without fully grokking import.c. I think to do better would require major rework to find_module(). I guess by renaming TERMIOS you mean to change the module names generated by h2py.py. I have no issue with this -- will others? I thought all filesystems on Windows 95/NT 3.51 and later, were case preserving. To what filesystems and Windows versions are you referring? ------------------------------------------------------- Date: 2001-Jan-11 13:59 By: gvanrossum Comment: Upload it as a new patch. But I believe the solution is that the TERMIOS module should be renamed. ------------------------------------------------------- Date: 2001-Jan-11 07:56 By: jlt63 Comment: Actually, this is not a bug in my original version. Cygwin Python is behaving identically to the Win32 one. Unfortunately, as you pointed out Win32 Python definitely does not handle the situation of two modules that only differ by case. Sigh... If one tries to import the second module that would be found in sys.path, then a NameError: Case mismatch ... exception will *always* be generated. I'm not sure that I agree with this behavior but I really a UNIX guy. Since Cygwin Python should support as many UNIX modules as possible, it needs to deal with modules that only differ by case. termios and TERMIOS used by getpass is a perfect example. I have created a (hacky) patch, that solves this problem for both Cygwin and Win32. I can redo it so that it only affects Cygwin and leaves the Win32 functionality alone. I would like to upload it for discussion but I am concerned about overwriting the old version. Should I upload it anyway? ------------------------------------------------------- Date: 2001-Jan-11 06:47 By: gvanrossum Comment: Reopened at request. Note that I believe that "import termios, TERMIOS" *should fail* -- not all filesystems used on Windows are case preserving. I've had this battle with Mark Hammond before. The case check is intended to prevent you from importing a moduleusing the wrong case (e.g. import String). It is *not* intended to let you have two modules that only differ in case. ------------------------------------------------------- Date: 2001-Jan-10 19:48 By: jlt63 Comment: I have already checked that this patch does not break the Windows VC build before I submitted it. However, Tim is welcome to reverify himself. Unfortunately, I have found a bug with this patch that (only) affects Cygwin. Although this patch handles the following: import String it does not handle the following: import termios, TERMIOS I will resubmit a new version shortly, please change the status back to open. ------------------------------------------------------- Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler <jt@dothill.com> * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Fri Jan 12 18:52:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 10:52:28 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: <E14H9JM-0007Uj-00@usw-sf-web3.sourceforge.net> Patch #103154 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-12 10:52 By: gvanrossum Comment: Maybe things are different now. But I definitely remember that when I introduced this test, Mark Hammond told me that there was a popular networking filesystem that didn't preserve case. This was either for Windows NT or Windows 95, so it's not a Windows 3.1 thing (although it's possible that the fileserver in question was a bad port from DOS or Windows 3.1 of course). ------------------------------------------------------- Date: 2001-Jan-12 10:47 By: jlt63 Comment: I know. I was just confused by the following On 2001-Jan-11 06:47, gvanrossum wrote: > Note that I believe that "import termios, TERMIOS" *should fail* -- not all > filesystems used on Windows are case preserving. ------------------------------------------------------- Date: 2001-Jan-12 10:26 By: tim_one Comment: The filesystems do preserve the case of names. But all platform file *lookup* APIs are case-insensitive. ------------------------------------------------------- Date: 2001-Jan-12 09:50 By: jlt63 Comment: Oops... Use the following procedure to patch: $ cd Python $ # save case.patch to current directory $ patch <case.patch ------------------------------------------------------- Date: 2001-Jan-12 09:44 By: jlt63 Comment: I just uploaded a new patch. It fixes the case sensitive import problem for Cygwin without affecting Win32 (i.e., Win32 functions as before). Now Cygwin's import behavior is identical to other UNIX platforms. I'm not completely happy with the patch and would characterize it as hacky, but it is the best that I can do without fully grokking import.c. I think to do better would require major rework to find_module(). I guess by renaming TERMIOS you mean to change the module names generated by h2py.py. I have no issue with this -- will others? I thought all filesystems on Windows 95/NT 3.51 and later, were case preserving. To what filesystems and Windows versions are you referring? ------------------------------------------------------- Date: 2001-Jan-11 13:59 By: gvanrossum Comment: Upload it as a new patch. But I believe the solution is that the TERMIOS module should be renamed. ------------------------------------------------------- Date: 2001-Jan-11 07:56 By: jlt63 Comment: Actually, this is not a bug in my original version. Cygwin Python is behaving identically to the Win32 one. Unfortunately, as you pointed out Win32 Python definitely does not handle the situation of two modules that only differ by case. Sigh... If one tries to import the second module that would be found in sys.path, then a NameError: Case mismatch ... exception will *always* be generated. I'm not sure that I agree with this behavior but I really a UNIX guy. Since Cygwin Python should support as many UNIX modules as possible, it needs to deal with modules that only differ by case. termios and TERMIOS used by getpass is a perfect example. I have created a (hacky) patch, that solves this problem for both Cygwin and Win32. I can redo it so that it only affects Cygwin and leaves the Win32 functionality alone. I would like to upload it for discussion but I am concerned about overwriting the old version. Should I upload it anyway? ------------------------------------------------------- Date: 2001-Jan-11 06:47 By: gvanrossum Comment: Reopened at request. Note that I believe that "import termios, TERMIOS" *should fail* -- not all filesystems used on Windows are case preserving. I've had this battle with Mark Hammond before. The case check is intended to prevent you from importing a moduleusing the wrong case (e.g. import String). It is *not* intended to let you have two modules that only differ in case. ------------------------------------------------------- Date: 2001-Jan-10 19:48 By: jlt63 Comment: I have already checked that this patch does not break the Windows VC build before I submitted it. However, Tim is welcome to reverify himself. Unfortunately, I have found a bug with this patch that (only) affects Cygwin. Although this patch handles the following: import String it does not handle the following: import termios, TERMIOS I will resubmit a new version shortly, please change the status back to open. ------------------------------------------------------- Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler <jt@dothill.com> * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Fri Jan 12 19:27:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 11:27:59 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14H9rj-0001NE-00@usw-sf-web1.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : loewis Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-12 11:27 By: fdrake Comment: Updated patch to also support proxy semantics using the same invalidation machinery as the basic weak reference type. The additional code is *heavily* borrowed from Neil Schemenauer. ------------------------------------------------------- Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Fri Jan 12 19:48:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 11:48:40 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: <E14HABk-0007sf-00@usw-sf-web3.sourceforge.net> Patch #103154 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-12 11:48 By: tim_one Comment: Ah, I see. There's a difference between Windows filesystems and filesystems used on Windows <wink/sigh>. Older Novell network fileservers for Windows do indeed destroy the case of file names, and newer ones are often configured in a compatability mode to keep on doing that. At my last employer, more than half the LAN servers were set up that way. Use of PYTHONCASEOK was universal as a result. We were also screwed in that one of the popular Windows source-control systems *also* destroyed case (I didn't use that, and have forgotten the name): check in OhNo.py, check out OHNO.PY. Brrrrrrrrr. ------------------------------------------------------- Date: 2001-Jan-12 10:52 By: gvanrossum Comment: Maybe things are different now. But I definitely remember that when I introduced this test, Mark Hammond told me that there was a popular networking filesystem that didn't preserve case. This was either for Windows NT or Windows 95, so it's not a Windows 3.1 thing (although it's possible that the fileserver in question was a bad port from DOS or Windows 3.1 of course). ------------------------------------------------------- Date: 2001-Jan-12 10:47 By: jlt63 Comment: I know. I was just confused by the following On 2001-Jan-11 06:47, gvanrossum wrote: > Note that I believe that "import termios, TERMIOS" *should fail* -- not all > filesystems used on Windows are case preserving. ------------------------------------------------------- Date: 2001-Jan-12 10:26 By: tim_one Comment: The filesystems do preserve the case of names. But all platform file *lookup* APIs are case-insensitive. ------------------------------------------------------- Date: 2001-Jan-12 09:50 By: jlt63 Comment: Oops... Use the following procedure to patch: $ cd Python $ # save case.patch to current directory $ patch <case.patch ------------------------------------------------------- Date: 2001-Jan-12 09:44 By: jlt63 Comment: I just uploaded a new patch. It fixes the case sensitive import problem for Cygwin without affecting Win32 (i.e., Win32 functions as before). Now Cygwin's import behavior is identical to other UNIX platforms. I'm not completely happy with the patch and would characterize it as hacky, but it is the best that I can do without fully grokking import.c. I think to do better would require major rework to find_module(). I guess by renaming TERMIOS you mean to change the module names generated by h2py.py. I have no issue with this -- will others? I thought all filesystems on Windows 95/NT 3.51 and later, were case preserving. To what filesystems and Windows versions are you referring? ------------------------------------------------------- Date: 2001-Jan-11 13:59 By: gvanrossum Comment: Upload it as a new patch. But I believe the solution is that the TERMIOS module should be renamed. ------------------------------------------------------- Date: 2001-Jan-11 07:56 By: jlt63 Comment: Actually, this is not a bug in my original version. Cygwin Python is behaving identically to the Win32 one. Unfortunately, as you pointed out Win32 Python definitely does not handle the situation of two modules that only differ by case. Sigh... If one tries to import the second module that would be found in sys.path, then a NameError: Case mismatch ... exception will *always* be generated. I'm not sure that I agree with this behavior but I really a UNIX guy. Since Cygwin Python should support as many UNIX modules as possible, it needs to deal with modules that only differ by case. termios and TERMIOS used by getpass is a perfect example. I have created a (hacky) patch, that solves this problem for both Cygwin and Win32. I can redo it so that it only affects Cygwin and leaves the Win32 functionality alone. I would like to upload it for discussion but I am concerned about overwriting the old version. Should I upload it anyway? ------------------------------------------------------- Date: 2001-Jan-11 06:47 By: gvanrossum Comment: Reopened at request. Note that I believe that "import termios, TERMIOS" *should fail* -- not all filesystems used on Windows are case preserving. I've had this battle with Mark Hammond before. The case check is intended to prevent you from importing a moduleusing the wrong case (e.g. import String). It is *not* intended to let you have two modules that only differ in case. ------------------------------------------------------- Date: 2001-Jan-10 19:48 By: jlt63 Comment: I have already checked that this patch does not break the Windows VC build before I submitted it. However, Tim is welcome to reverify himself. Unfortunately, I have found a bug with this patch that (only) affects Cygwin. Although this patch handles the following: import String it does not handle the following: import termios, TERMIOS I will resubmit a new version shortly, please change the status back to open. ------------------------------------------------------- Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler <jt@dothill.com> * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Fri Jan 12 20:11:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 12:11:23 -0800 Subject: [Patches] [Patch #103158] Don't do unsafe arithmetic in xrange object Message-ID: <E14HAXj-00081C-00@usw-sf-web3.sourceforge.net> Patch #103158 has been updated. Project: python Category: core (C code) Status: Open Submitted by: greg_ball Assigned to : gvanrossum Summary: Don't do unsafe arithmetic in xrange object Follow-Ups: Date: 2001-Jan-12 12:11 By: greg_ball Comment: The new version of the patch makes the code a bit less complicated. (Only error messages have changed in terms of behaviour; regression test run under linux and OSF1.) If it looks ok you can ignore the rest of this comment... I originally made totlen an int because it is the return value from range_length, and the argument to PyList_New(). The current patch makes totlen a long, but the ocde doesn't get hugely less complicated. The code would get simpler if it rejected objects whose length doesn't fit into a int, but that seemed too easy and there is a small chance someone's code might break. On the other hand by rejecting objects whose stop can't be correctly calculated, I _might_ have broken code already. Break just means "now raises exception" though, nothing insidious. ------------------------------------------------------- Date: 2001-Jan-10 10:28 By: gvanrossum Comment: I wonder why you made totlen an int. This seems to complicate the code quite a bit. I'd suggest making it a long. Then you have to test whether it's > INT_MAX only in tolist() -- in that case you should raise MemoryError. Other than that, it looks decent! ------------------------------------------------------- Date: 2001-Jan-09 06:31 By: greg_ball Comment: This is a replacement for patch 103129, as suggested by tim_one. Possibly interesting aspects of the patch: - xrange objects with overflowing lengths are not gratutiously rejected. An error is raised only if the length becomes relevant, under len() or negative indexing. Bad lengths are stored as -1. Objects with bad lengths allow any non-negative integer index. - On 64 bit platforms, sequence multiplication seems to cause an unsafe cast from long to int. This patch does not address that issue. Without my patch, on i686 Linux: Python 2.0 (#25, Jan 2 2001, 12:18:07) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> y = xrange(maxint/2)*3 >>> len(y) -1073741827 >>> y[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> y.tolist() Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: listobject.c:33: bad argument to internal function >>> m = maxint >> 16 >>> xrange(0,maxint,m) xrange(0, -2147450883, 32767) >>> (xrange(1)*maxint)*maxint xrange(1) >>> With my patch Python 2.0 (#35, Jan 6 2001, 12:54:41) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> y = xrange(maxint/2)*3 >>> len(y) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> y.tolist() Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> m = maxint >> 16 >>> xrange(0,maxint,m) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer addition >>> (xrange(1)*maxint) * maxint Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer multiplication >>> Without patch on Digital Unix Python 2.0 (#5, Jan 6 2001, 15:42:58) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> xrange(0,maxint,m) xrange(0, -9223372034707292163, 2147483647) >>> xrange(1)*maxint xrange(0) >>> With patch Python 2.0 (#7, Jan 6 2001, 15:52:21) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> xrange(0,maxint,m) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer addition >>> xrange(1)*maxint xrange(0) >>> ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103158&group_id=5470 From noreply@sourceforge.net Fri Jan 12 20:35:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 12:35:45 -0800 Subject: [Patches] [Patch #103158] Don't do unsafe arithmetic in xrange object Message-ID: <E14HAvJ-0008A9-00@usw-sf-web3.sourceforge.net> Patch #103158 has been updated. Project: python Category: core (C code) Status: Open Submitted by: greg_ball Assigned to : gvanrossum Summary: Don't do unsafe arithmetic in xrange object Follow-Ups: Date: 2001-Jan-12 12:35 By: tim_one Comment: Please do reject objects whose length doesn't fit into an int. I'll bet a dollar that no real code in the world will break as a result. I feel confident making that bet, because if someone's code *does* break as a result, it's worth a dollar to me to see Guido lecture them that their code was already broken <wink>. Really, it's very Pythonic to gripe about a problem just as soon as it crops up. It's not doing anyone a favor to delay griping until the object is used: at that point, it may be very difficult to figure out how the object *got* damaged. There's simply no payback in allowing creation of an unusable xrange object, and, as you say, life is simpler if you don't allow it. ------------------------------------------------------- Date: 2001-Jan-12 12:11 By: greg_ball Comment: The new version of the patch makes the code a bit less complicated. (Only error messages have changed in terms of behaviour; regression test run under linux and OSF1.) If it looks ok you can ignore the rest of this comment... I originally made totlen an int because it is the return value from range_length, and the argument to PyList_New(). The current patch makes totlen a long, but the ocde doesn't get hugely less complicated. The code would get simpler if it rejected objects whose length doesn't fit into a int, but that seemed too easy and there is a small chance someone's code might break. On the other hand by rejecting objects whose stop can't be correctly calculated, I _might_ have broken code already. Break just means "now raises exception" though, nothing insidious. ------------------------------------------------------- Date: 2001-Jan-10 10:28 By: gvanrossum Comment: I wonder why you made totlen an int. This seems to complicate the code quite a bit. I'd suggest making it a long. Then you have to test whether it's > INT_MAX only in tolist() -- in that case you should raise MemoryError. Other than that, it looks decent! ------------------------------------------------------- Date: 2001-Jan-09 06:31 By: greg_ball Comment: This is a replacement for patch 103129, as suggested by tim_one. Possibly interesting aspects of the patch: - xrange objects with overflowing lengths are not gratutiously rejected. An error is raised only if the length becomes relevant, under len() or negative indexing. Bad lengths are stored as -1. Objects with bad lengths allow any non-negative integer index. - On 64 bit platforms, sequence multiplication seems to cause an unsafe cast from long to int. This patch does not address that issue. Without my patch, on i686 Linux: Python 2.0 (#25, Jan 2 2001, 12:18:07) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> y = xrange(maxint/2)*3 >>> len(y) -1073741827 >>> y[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> y.tolist() Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: listobject.c:33: bad argument to internal function >>> m = maxint >> 16 >>> xrange(0,maxint,m) xrange(0, -2147450883, 32767) >>> (xrange(1)*maxint)*maxint xrange(1) >>> With my patch Python 2.0 (#35, Jan 6 2001, 12:54:41) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> y = xrange(maxint/2)*3 >>> len(y) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> y.tolist() Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> m = maxint >> 16 >>> xrange(0,maxint,m) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer addition >>> (xrange(1)*maxint) * maxint Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer multiplication >>> Without patch on Digital Unix Python 2.0 (#5, Jan 6 2001, 15:42:58) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> xrange(0,maxint,m) xrange(0, -9223372034707292163, 2147483647) >>> xrange(1)*maxint xrange(0) >>> With patch Python 2.0 (#7, Jan 6 2001, 15:52:21) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> xrange(0,maxint,m) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer addition >>> xrange(1)*maxint xrange(0) >>> ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103158&group_id=5470 From noreply@sourceforge.net Fri Jan 12 20:44:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 12:44:58 -0800 Subject: [Patches] [Patch #103158] Don't do unsafe arithmetic in xrange object Message-ID: <E14HB4E-0008Dv-00@usw-sf-web3.sourceforge.net> Patch #103158 has been updated. Project: python Category: core (C code) Status: Open Submitted by: greg_ball Assigned to : gvanrossum Summary: Don't do unsafe arithmetic in xrange object Follow-Ups: Date: 2001-Jan-12 12:44 By: gvanrossum Comment: In theory, there's a use for objects whose length doesn't fit in an int: for i in xrange(...) is routinely used for loops that expect to break well before the end but don't want to give an arbitrary upper bound. But I agree with Tim that this serves no real purpose. I think that if anything, the xrange() object should be scaled down. No repetition, no concationation, no slicing. the only real use ought to be "for i in xrange(...)". But of course, *that* is bound to break somebody's code somewhere. So let's not go there. But let's not complicate it any further. Prevent breakage, but don't stretch the functionality beyond what it currently does. ------------------------------------------------------- Date: 2001-Jan-12 12:35 By: tim_one Comment: Please do reject objects whose length doesn't fit into an int. I'll bet a dollar that no real code in the world will break as a result. I feel confident making that bet, because if someone's code *does* break as a result, it's worth a dollar to me to see Guido lecture them that their code was already broken <wink>. Really, it's very Pythonic to gripe about a problem just as soon as it crops up. It's not doing anyone a favor to delay griping until the object is used: at that point, it may be very difficult to figure out how the object *got* damaged. There's simply no payback in allowing creation of an unusable xrange object, and, as you say, life is simpler if you don't allow it. ------------------------------------------------------- Date: 2001-Jan-12 12:11 By: greg_ball Comment: The new version of the patch makes the code a bit less complicated. (Only error messages have changed in terms of behaviour; regression test run under linux and OSF1.) If it looks ok you can ignore the rest of this comment... I originally made totlen an int because it is the return value from range_length, and the argument to PyList_New(). The current patch makes totlen a long, but the ocde doesn't get hugely less complicated. The code would get simpler if it rejected objects whose length doesn't fit into a int, but that seemed too easy and there is a small chance someone's code might break. On the other hand by rejecting objects whose stop can't be correctly calculated, I _might_ have broken code already. Break just means "now raises exception" though, nothing insidious. ------------------------------------------------------- Date: 2001-Jan-10 10:28 By: gvanrossum Comment: I wonder why you made totlen an int. This seems to complicate the code quite a bit. I'd suggest making it a long. Then you have to test whether it's > INT_MAX only in tolist() -- in that case you should raise MemoryError. Other than that, it looks decent! ------------------------------------------------------- Date: 2001-Jan-09 06:31 By: greg_ball Comment: This is a replacement for patch 103129, as suggested by tim_one. Possibly interesting aspects of the patch: - xrange objects with overflowing lengths are not gratutiously rejected. An error is raised only if the length becomes relevant, under len() or negative indexing. Bad lengths are stored as -1. Objects with bad lengths allow any non-negative integer index. - On 64 bit platforms, sequence multiplication seems to cause an unsafe cast from long to int. This patch does not address that issue. Without my patch, on i686 Linux: Python 2.0 (#25, Jan 2 2001, 12:18:07) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> y = xrange(maxint/2)*3 >>> len(y) -1073741827 >>> y[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> y.tolist() Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: listobject.c:33: bad argument to internal function >>> m = maxint >> 16 >>> xrange(0,maxint,m) xrange(0, -2147450883, 32767) >>> (xrange(1)*maxint)*maxint xrange(1) >>> With my patch Python 2.0 (#35, Jan 6 2001, 12:54:41) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> y = xrange(maxint/2)*3 >>> len(y) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> y.tolist() Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> m = maxint >> 16 >>> xrange(0,maxint,m) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer addition >>> (xrange(1)*maxint) * maxint Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer multiplication >>> Without patch on Digital Unix Python 2.0 (#5, Jan 6 2001, 15:42:58) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> xrange(0,maxint,m) xrange(0, -9223372034707292163, 2147483647) >>> xrange(1)*maxint xrange(0) >>> With patch Python 2.0 (#7, Jan 6 2001, 15:52:21) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> xrange(0,maxint,m) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer addition >>> xrange(1)*maxint xrange(0) >>> ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103158&group_id=5470 From noreply@sourceforge.net Fri Jan 12 20:58:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 12:58:20 -0800 Subject: [Patches] [Patch #103158] Don't do unsafe arithmetic in xrange object Message-ID: <E14HBHA-0001xB-00@usw-sf-web1.sourceforge.net> Patch #103158 has been updated. Project: python Category: core (C code) Status: Open Submitted by: greg_ball Assigned to : gvanrossum Summary: Don't do unsafe arithmetic in xrange object Follow-Ups: Date: 2001-Jan-12 12:58 By: tim_one Comment: I'm aware of people who actually do x = xrange(sys.maxint) and that should continue to work. Python 2.0 already complains about more than that: >>> xrange(-1, sys.maxint) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange() has more than sys.maxint items >>> and I sure don't want to see that extended (unless it's part of a *sweeping* crusade to eradicate the visibile differences between ints and longs). ------------------------------------------------------- Date: 2001-Jan-12 12:44 By: gvanrossum Comment: In theory, there's a use for objects whose length doesn't fit in an int: for i in xrange(...) is routinely used for loops that expect to break well before the end but don't want to give an arbitrary upper bound. But I agree with Tim that this serves no real purpose. I think that if anything, the xrange() object should be scaled down. No repetition, no concationation, no slicing. the only real use ought to be "for i in xrange(...)". But of course, *that* is bound to break somebody's code somewhere. So let's not go there. But let's not complicate it any further. Prevent breakage, but don't stretch the functionality beyond what it currently does. ------------------------------------------------------- Date: 2001-Jan-12 12:35 By: tim_one Comment: Please do reject objects whose length doesn't fit into an int. I'll bet a dollar that no real code in the world will break as a result. I feel confident making that bet, because if someone's code *does* break as a result, it's worth a dollar to me to see Guido lecture them that their code was already broken <wink>. Really, it's very Pythonic to gripe about a problem just as soon as it crops up. It's not doing anyone a favor to delay griping until the object is used: at that point, it may be very difficult to figure out how the object *got* damaged. There's simply no payback in allowing creation of an unusable xrange object, and, as you say, life is simpler if you don't allow it. ------------------------------------------------------- Date: 2001-Jan-12 12:11 By: greg_ball Comment: The new version of the patch makes the code a bit less complicated. (Only error messages have changed in terms of behaviour; regression test run under linux and OSF1.) If it looks ok you can ignore the rest of this comment... I originally made totlen an int because it is the return value from range_length, and the argument to PyList_New(). The current patch makes totlen a long, but the ocde doesn't get hugely less complicated. The code would get simpler if it rejected objects whose length doesn't fit into a int, but that seemed too easy and there is a small chance someone's code might break. On the other hand by rejecting objects whose stop can't be correctly calculated, I _might_ have broken code already. Break just means "now raises exception" though, nothing insidious. ------------------------------------------------------- Date: 2001-Jan-10 10:28 By: gvanrossum Comment: I wonder why you made totlen an int. This seems to complicate the code quite a bit. I'd suggest making it a long. Then you have to test whether it's > INT_MAX only in tolist() -- in that case you should raise MemoryError. Other than that, it looks decent! ------------------------------------------------------- Date: 2001-Jan-09 06:31 By: greg_ball Comment: This is a replacement for patch 103129, as suggested by tim_one. Possibly interesting aspects of the patch: - xrange objects with overflowing lengths are not gratutiously rejected. An error is raised only if the length becomes relevant, under len() or negative indexing. Bad lengths are stored as -1. Objects with bad lengths allow any non-negative integer index. - On 64 bit platforms, sequence multiplication seems to cause an unsafe cast from long to int. This patch does not address that issue. Without my patch, on i686 Linux: Python 2.0 (#25, Jan 2 2001, 12:18:07) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> y = xrange(maxint/2)*3 >>> len(y) -1073741827 >>> y[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> y.tolist() Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: listobject.c:33: bad argument to internal function >>> m = maxint >> 16 >>> xrange(0,maxint,m) xrange(0, -2147450883, 32767) >>> (xrange(1)*maxint)*maxint xrange(1) >>> With my patch Python 2.0 (#35, Jan 6 2001, 12:54:41) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> y = xrange(maxint/2)*3 >>> len(y) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> y.tolist() Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> m = maxint >> 16 >>> xrange(0,maxint,m) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer addition >>> (xrange(1)*maxint) * maxint Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer multiplication >>> Without patch on Digital Unix Python 2.0 (#5, Jan 6 2001, 15:42:58) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> xrange(0,maxint,m) xrange(0, -9223372034707292163, 2147483647) >>> xrange(1)*maxint xrange(0) >>> With patch Python 2.0 (#7, Jan 6 2001, 15:52:21) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> xrange(0,maxint,m) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer addition >>> xrange(1)*maxint xrange(0) >>> ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103158&group_id=5470 From noreply@sourceforge.net Fri Jan 12 22:36:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 14:36:50 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14HCoU-0000TP-00@usw-sf-web3.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : loewis Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-12 14:36 By: loewis Comment: The weak dictionary data type needs more clarification in documentation and implementation. In java.util.WeakHashMap, they keys are weak, not the values (i.e. once the key is forgotten, the entry is cleared). In http://www.handshake.de/~dieter/weakdict.html, the values are weak, but it raises KeyErrors for entries that are collected. The initializer of a weak dict does not check the invariant (all values are weak). get() of a weakdict does not support an optional second parameter. weakref and friends need to participate in garbage collection, as the reference to the callback can create a cycle. ------------------------------------------------------- Date: 2001-Jan-12 11:27 By: fdrake Comment: Updated patch to also support proxy semantics using the same invalidation machinery as the basic weak reference type. The additional code is *heavily* borrowed from Neil Schemenauer. ------------------------------------------------------- Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Sat Jan 13 02:31:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 18:31:27 -0800 Subject: [Patches] [Patch #103220] Cygwin util.get_platform() fix Message-ID: <E14HGTX-0006yp-00@usw-sf-web2.sourceforge.net> Patch #103220 has been updated. Project: python Category: distutils Status: Open Submitted by: jlt63 Assigned to : nobody Summary: Cygwin util.get_platform() fix ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103220&group_id=5470 From noreply@sourceforge.net Sat Jan 13 02:32:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 18:32:17 -0800 Subject: [Patches] [Patch #103220] Cygwin util.get_platform() fix Message-ID: <E14HGUL-0006zG-00@usw-sf-web2.sourceforge.net> Patch #103220 has been updated. Project: python Category: distutils Status: Open Submitted by: jlt63 Assigned to : nobody Summary: Cygwin util.get_platform() fix Follow-Ups: Date: 2001-Jan-12 18:32 By: jlt63 Comment: This patch adds support for Cygwin to util.get_platform(). A Cygwin specific case is needed due to the format of Cygwin's uname command: $ uname -r 1.1.7(0.31/3/2) Since the release field contains slashes, a path component name that is based on this information becomes multiple path components instead of a single one. This patch corrects this problem by only using the leading part of the release field that matches the regular expression "[\d.]+". The procedure to apply the patch is as follows: $ cd Lib/distutils $ # save util.patch to the current directory $ patch <util.patch ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103220&group_id=5470 From noreply@sourceforge.net Sat Jan 13 05:01:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 21:01:54 -0800 Subject: [Patches] [Patch #103222] Remove case insensitive problem with "Python" directory Message-ID: <E14HIp8-0004XY-00@usw-sf-web1.sourceforge.net> Patch #103222 has been updated. Project: python Category: None Status: Open Submitted by: dkwolfe Assigned to : nobody Summary: Remove case insensitive problem with "Python" directory ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103222&group_id=5470 From noreply@sourceforge.net Sat Jan 13 07:00:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 23:00:20 -0800 Subject: [Patches] [Patch #103217] prevent htmllib from calling None.split() Message-ID: <E14HKfk-000550-00@usw-sf-web1.sourceforge.net> Patch #103217 has been updated. Project: python Category: library Status: Open Submitted by: fbremmer Assigned to : nobody Summary: prevent htmllib from calling None.split() Follow-Ups: Date: 2001-Jan-12 23:00 By: moshez Comment: Big +1! This also makes save_end's return type reliably a string, which probably would fix other people's bugs without them noticing... (IOW, user code that would get the return data from save_end and treat it as a string). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103217&group_id=5470 From noreply@sourceforge.net Sat Jan 13 07:02:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 23:02:17 -0800 Subject: [Patches] [Patch #103139] Autconfigure curses and readline into the default build Message-ID: <E14HKhd-00055c-00@usw-sf-web1.sourceforge.net> Patch #103139 has been updated. Project: python Category: Build Status: Open Submitted by: esr Assigned to : esr Summary: Autconfigure curses and readline into the default build Follow-Ups: Date: 2001-Jan-12 23:02 By: moshez Comment: Guido, didn't you just check in something like that? ------------------------------------------------------- Date: 2001-Jan-08 18:17 By: gvanrossum Comment: Eric, there seems to be a discrepancy in the patch: the configure script tests for ncurses but the Setup.config.in file links with -lcurses. What gives? ------------------------------------------------------- Date: 2001-Jan-07 21:43 By: nascheme Comment: On Linux I think you should link to ncurses instead of curses and leave termcap out. Debian doesn't have termcap development libraries. Also, this patch only works on Linux. I think Andrew's distutil approach is a much better long term solution. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103139&group_id=5470 From noreply@sourceforge.net Sat Jan 13 07:10:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 23:10:36 -0800 Subject: [Patches] [Patch #103222] Remove case insensitive problem with "Python" directory Message-ID: <E14HKpg-00058L-00@usw-sf-web1.sourceforge.net> Patch #103222 has been updated. Project: python Category: None Status: Open Submitted by: dkwolfe Assigned to : nobody Summary: Remove case insensitive problem with "Python" directory Follow-Ups: Date: 2001-Jan-12 23:10 By: moshez Comment: <pre> I'll summarize the changes: mv Python PyCore I don't think I like it at all....while the directory structure could use some restructuring, that's not the reason nor the time to do this...maybe it's better to have a "build" directory in dist/src, and build to that? I think I'd like that. </PRE> ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103222&group_id=5470 From noreply@sourceforge.net Sat Jan 13 07:15:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 23:15:31 -0800 Subject: [Patches] [Patch #103220] Cygwin util.get_platform() fix Message-ID: <E14HKuR-00059k-00@usw-sf-web1.sourceforge.net> Patch #103220 has been updated. Project: python Category: distutils Status: Open Submitted by: jlt63 Assigned to : nobody Summary: Cygwin util.get_platform() fix Follow-Ups: Date: 2001-Jan-12 23:15 By: moshez Comment: Hmmmmm...only one question, since I don't have Cygwin to play with: how is the "machine" in cygwin determined? You seem to go with the "os-release-machine" format, so I assume cygwin does distinguish the machines, but I have no idea wht the possibilities are. ------------------------------------------------------- Date: 2001-Jan-12 18:32 By: jlt63 Comment: This patch adds support for Cygwin to util.get_platform(). A Cygwin specific case is needed due to the format of Cygwin's uname command: $ uname -r 1.1.7(0.31/3/2) Since the release field contains slashes, a path component name that is based on this information becomes multiple path components instead of a single one. This patch corrects this problem by only using the leading part of the release field that matches the regular expression "[\d.]+". The procedure to apply the patch is as follows: $ cd Lib/distutils $ # save util.patch to the current directory $ patch <util.patch ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103220&group_id=5470 From noreply@sourceforge.net Sat Jan 13 15:28:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 07:28:35 -0800 Subject: [Patches] [Patch #103225] httplib: smallest Python patch ever Message-ID: <E14HSbb-0007T9-00@usw-sf-web1.sourceforge.net> Patch #103225 has been updated. Project: python Category: library Status: Open Submitted by: ping Assigned to : nobody Summary: httplib: smallest Python patch ever ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103225&group_id=5470 From noreply@sourceforge.net Sat Jan 13 16:55:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 08:55:59 -0800 Subject: [Patches] [Patch #103225] httplib: smallest Python patch ever Message-ID: <E14HTyB-0002eo-00@usw-sf-web2.sourceforge.net> Patch #103225 has been updated. Project: python Category: library Status: Closed Submitted by: ping Assigned to : nobody Summary: httplib: smallest Python patch ever Follow-Ups: Date: 2001-Jan-13 08:55 By: gvanrossum Comment: Yes, that's a nit if ever there was one. Good find! :-) Applied it already. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103225&group_id=5470 From noreply@sourceforge.net Sat Jan 13 17:07:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 09:07:50 -0800 Subject: [Patches] [Patch #103222] Remove case insensitive problem with "Python" directory Message-ID: <E14HU9e-0005po-00@usw-sf-web3.sourceforge.net> Patch #103222 has been updated. Project: python Category: None Status: Rejected Submitted by: dkwolfe Assigned to : nobody Summary: Remove case insensitive problem with "Python" directory Follow-Ups: Date: 2001-Jan-13 09:07 By: gvanrossum Comment: Rejected. Renaming a directory is too much of a hassle. ------------------------------------------------------- Date: 2001-Jan-12 23:10 By: moshez Comment: <pre> I'll summarize the changes: mv Python PyCore I don't think I like it at all....while the directory structure could use some restructuring, that's not the reason nor the time to do this...maybe it's better to have a "build" directory in dist/src, and build to that? I think I'd like that. </PRE> ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103222&group_id=5470 From noreply@sourceforge.net Sat Jan 13 17:08:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 09:08:18 -0800 Subject: [Patches] [Patch #103220] Cygwin util.get_platform() fix Message-ID: <E14HUA6-0005py-00@usw-sf-web3.sourceforge.net> Patch #103220 has been updated. Project: python Category: distutils Status: Open Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin util.get_platform() fix Follow-Ups: Date: 2001-Jan-12 23:15 By: moshez Comment: Hmmmmm...only one question, since I don't have Cygwin to play with: how is the "machine" in cygwin determined? You seem to go with the "os-release-machine" format, so I assume cygwin does distinguish the machines, but I have no idea wht the possibilities are. ------------------------------------------------------- Date: 2001-Jan-12 18:32 By: jlt63 Comment: This patch adds support for Cygwin to util.get_platform(). A Cygwin specific case is needed due to the format of Cygwin's uname command: $ uname -r 1.1.7(0.31/3/2) Since the release field contains slashes, a path component name that is based on this information becomes multiple path components instead of a single one. This patch corrects this problem by only using the leading part of the release field that matches the regular expression "[\d.]+". The procedure to apply the patch is as follows: $ cd Lib/distutils $ # save util.patch to the current directory $ patch <util.patch ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103220&group_id=5470 From noreply@sourceforge.net Sat Jan 13 17:11:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 09:11:37 -0800 Subject: [Patches] [Patch #103217] prevent htmllib from calling None.split() Message-ID: <E14HUDJ-0005rD-00@usw-sf-web3.sourceforge.net> Patch #103217 has been updated. Project: python Category: library Status: Rejected Submitted by: fbremmer Assigned to : gvanrossum Summary: prevent htmllib from calling None.split() Follow-Ups: Date: 2001-Jan-13 09:11 By: gvanrossum Comment: You don't understand. You're not supposed to call save_begin() and save_end() in a tag that can be nested. If the problem is that you can't trust your input, you should insert a check in your handler for <tag> that rejects recursive use. ------------------------------------------------------- Date: 2001-Jan-12 23:00 By: moshez Comment: Big +1! This also makes save_end's return type reliably a string, which probably would fix other people's bugs without them noticing... (IOW, user code that would get the return data from save_end and treat it as a string). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103217&group_id=5470 From noreply@sourceforge.net Sat Jan 13 17:12:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 09:12:24 -0800 Subject: [Patches] [Patch #103139] Autconfigure curses and readline into the default build Message-ID: <E14HUE4-0005rY-00@usw-sf-web3.sourceforge.net> Patch #103139 has been updated. Project: python Category: Build Status: Closed Submitted by: esr Assigned to : gvanrossum Summary: Autconfigure curses and readline into the default build Follow-Ups: Date: 2001-Jan-13 09:12 By: gvanrossum Comment: Closed. I already checked this in. ------------------------------------------------------- Date: 2001-Jan-12 23:02 By: moshez Comment: Guido, didn't you just check in something like that? ------------------------------------------------------- Date: 2001-Jan-08 18:17 By: gvanrossum Comment: Eric, there seems to be a discrepancy in the patch: the configure script tests for ncurses but the Setup.config.in file links with -lcurses. What gives? ------------------------------------------------------- Date: 2001-Jan-07 21:43 By: nascheme Comment: On Linux I think you should link to ncurses instead of curses and leave termcap out. Debian doesn't have termcap development libraries. Also, this patch only works on Linux. I think Andrew's distutil approach is a much better long term solution. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103139&group_id=5470 From noreply@sourceforge.net Sat Jan 13 18:40:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 10:40:17 -0800 Subject: [Patches] [Patch #102847] fix a memory leak Message-ID: <E14HVb7-0006Kx-00@usw-sf-web3.sourceforge.net> Patch #102847 has been updated. Project: python Category: core (C code) Status: Open Submitted by: cgw Assigned to : jhylton Summary: fix a memory leak Follow-Ups: Date: 2001-Jan-13 10:40 By: moshez Comment: 102337 is now closed. ------------------------------------------------------- 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 Jan 13 20:00:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 12:00:10 -0800 Subject: [Patches] [Patch #103227] make code.py appreciate softspace. Message-ID: <E14HWqQ-0000Td-00@usw-sf-web1.sourceforge.net> Patch #103227 has been updated. Project: python Category: library Status: Open Submitted by: mwh Assigned to : nobody Summary: make code.py appreciate softspace. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103227&group_id=5470 From noreply@sourceforge.net Sat Jan 13 20:01:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 12:01:50 -0800 Subject: [Patches] [Patch #103228] traceback.py nit. Message-ID: <E14HWs2-0000Uu-00@usw-sf-web1.sourceforge.net> Patch #103228 has been updated. Project: python Category: library Status: Open Submitted by: mwh Assigned to : nobody Summary: traceback.py nit. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103228&group_id=5470 From noreply@sourceforge.net Sat Jan 13 22:10:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 14:10:56 -0800 Subject: [Patches] [Patch #103227] make code.py appreciate softspace. Message-ID: <E14HYsy-0007Nz-00@usw-sf-web3.sourceforge.net> Patch #103227 has been updated. Project: python Category: library Status: Closed Submitted by: mwh Assigned to : gvanrossum Summary: make code.py appreciate softspace. Follow-Ups: Date: 2001-Jan-13 14:10 By: gvanrossum Comment: Thanks -- applied! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103227&group_id=5470 From noreply@sourceforge.net Sat Jan 13 22:14:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 14:14:50 -0800 Subject: [Patches] [Patch #103228] traceback.py nit. Message-ID: <E14HYwk-0007Pd-00@usw-sf-web3.sourceforge.net> Patch #103228 has been updated. Project: python Category: library Status: Closed Submitted by: mwh Assigned to : gvanrossum Summary: traceback.py nit. Follow-Ups: Date: 2001-Jan-13 14:14 By: gvanrossum Comment: Thanks! Applied. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103228&group_id=5470 From noreply@sourceforge.net Sun Jan 14 04:01:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 20:01:15 -0800 Subject: [Patches] [Patch #103220] Cygwin util.get_platform() fix Message-ID: <E14HeLz-0004cd-00@usw-sf-web3.sourceforge.net> Patch #103220 has been updated. Project: python Category: distutils Status: Open Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin util.get_platform() fix Follow-Ups: Date: 2001-Jan-13 20:01 By: jlt63 Comment: > how is the "machine" in cygwin determined? It is derived from Window's GetSystemInfo(). See the following, if interested: http://msdn.microsoft.com/library/psdk/sysmgmt/sysinfo_3t67.htm > You seem to go with the "os-release-machine" format Not for any good reason, I was just trying to get rid of the "(0.31/3/2)" cruft. I'm willing to go with "os-release", if that is deemed more appropriate. Let me know and I will upload a revised patch. > so I assume cygwin does distinguish the machines I don't think it does -- it just reports the machine type. > but I have no idea wht the possibilities are The current list is: i[3-6]86, alpha, mips, and unknown. ------------------------------------------------------- Date: 2001-Jan-12 23:15 By: moshez Comment: Hmmmmm...only one question, since I don't have Cygwin to play with: how is the "machine" in cygwin determined? You seem to go with the "os-release-machine" format, so I assume cygwin does distinguish the machines, but I have no idea wht the possibilities are. ------------------------------------------------------- Date: 2001-Jan-12 18:32 By: jlt63 Comment: This patch adds support for Cygwin to util.get_platform(). A Cygwin specific case is needed due to the format of Cygwin's uname command: $ uname -r 1.1.7(0.31/3/2) Since the release field contains slashes, a path component name that is based on this information becomes multiple path components instead of a single one. This patch corrects this problem by only using the leading part of the release field that matches the regular expression "[\d.]+". The procedure to apply the patch is as follows: $ cd Lib/distutils $ # save util.patch to the current directory $ patch <util.patch ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103220&group_id=5470 From noreply@sourceforge.net Sun Jan 14 18:12:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 10:12:44 -0800 Subject: [Patches] [Patch #103232] Preserve Nonstandard Port Number in Host Header Message-ID: <E14Hre0-0001b8-00@usw-sf-web3.sourceforge.net> Patch #103232 has been updated. Project: python Category: library Status: Open Submitted by: dougfort Assigned to : nobody Summary: Preserve Nonstandard Port Number in Host Header ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103232&group_id=5470 From noreply@sourceforge.net Sun Jan 14 21:03:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 13:03:43 -0800 Subject: [Patches] [Patch #103232] Preserve Nonstandard Port Number in Host Header Message-ID: <E14HuJT-0000og-00@usw-sf-web1.sourceforge.net> Patch #103232 has been updated. Project: python Category: library Status: Closed Submitted by: dougfort Assigned to : gvanrossum Summary: Preserve Nonstandard Port Number in Host Header Follow-Ups: Date: 2001-Jan-14 13:03 By: gvanrossum Comment: Thanks! Checked in. I believe the same should be added to urllib which sometimes generates its own Host: header. Can you submit a patch for that too? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103232&group_id=5470 From noreply@sourceforge.net Sun Jan 14 21:49:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 13:49:40 -0800 Subject: [Patches] [Patch #103232] Preserve Nonstandard Port Number in Host Header Message-ID: <E14Hv1w-00014F-00@usw-sf-web1.sourceforge.net> Patch #103232 has been updated. Project: python Category: library Status: Closed Submitted by: dougfort Assigned to : gvanrossum Summary: Preserve Nonstandard Port Number in Host Header Follow-Ups: Date: 2001-Jan-14 13:49 By: dougfort Comment: urllib handles :port correctly, no patch required. ------------------------------------------------------- Date: 2001-Jan-14 13:03 By: gvanrossum Comment: Thanks! Checked in. I believe the same should be added to urllib which sometimes generates its own Host: header. Can you submit a patch for that too? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103232&group_id=5470 From noreply@sourceforge.net Sun Jan 14 22:44:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 14:44:57 -0800 Subject: [Patches] [Patch #103232] Preserve Nonstandard Port Number in Host Header Message-ID: <E14HvtR-00036u-00@usw-sf-web3.sourceforge.net> Patch #103232 has been updated. Project: python Category: library Status: Closed Submitted by: dougfort Assigned to : gvanrossum Summary: Preserve Nonstandard Port Number in Host Header Follow-Ups: Date: 2001-Jan-14 14:44 By: gvanrossum Comment: Ah, I see. I learn something new every day. :-) Thanks! ------------------------------------------------------- Date: 2001-Jan-14 13:49 By: dougfort Comment: urllib handles :port correctly, no patch required. ------------------------------------------------------- Date: 2001-Jan-14 13:03 By: gvanrossum Comment: Thanks! Checked in. I believe the same should be added to urllib which sometimes generates its own Host: header. Can you submit a patch for that too? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103232&group_id=5470 From noreply@sourceforge.net Sun Jan 14 23:09:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 15:09:47 -0800 Subject: [Patches] [Patch #103211] webbrowser.py: fix spelling of "Konqueror" Message-ID: <E14HwHT-0004Yk-00@usw-sf-web2.sourceforge.net> Patch #103211 has been updated. Project: python Category: library Status: Closed Submitted by: ping Assigned to : gvanrossum Summary: webbrowser.py: fix spelling of "Konqueror" Follow-Ups: Date: 2001-Jan-14 15:09 By: gvanrossum Comment: Ah, I'm checking this in myself. ------------------------------------------------------- Date: 2001-Jan-12 06:23 By: gvanrossum Comment: Check it in, Ping! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103211&group_id=5470 From noreply@sourceforge.net Sun Jan 14 23:11:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 15:11:01 -0800 Subject: [Patches] [Patch #103234] tokenize.py: add support for u"", U'', etc. Message-ID: <E14HwIf-0003FT-00@usw-sf-web3.sourceforge.net> Patch #103234 has been updated. Project: python Category: None Status: Open Submitted by: ping Assigned to : nobody Summary: tokenize.py: add support for u"", U'', etc. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103234&group_id=5470 From noreply@sourceforge.net Sun Jan 14 23:20:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 15:20:45 -0800 Subject: [Patches] [Patch #101612] Prevent recursion limit when using ".*?xxx" Message-ID: <E14HwS5-0003J3-00@usw-sf-web3.sourceforge.net> Patch #101612 has been updated. Project: python Category: Modules Status: Closed Submitted by: dgallion Assigned to : effbot Summary: Prevent recursion limit when using ".*?xxx" Follow-Ups: Date: 2001-Jan-14 15:20 By: effbot Comment: I've adapted a variant of this patch. Not 100% sure this approach works in all cases, but it has survived all tests I've thrown at it. ------------------------------------------------------- Date: 2000-Sep-22 21:12 By: dgallion Comment: This pattern fails with sre: >>> re.match("(?s){.*?}","{"+' '*17000+"}") Traceback (most recent call last): File "<stdin>", line 1, in ? File "E:\pythonWinCVS\python\dist\src\lib\sre.py", line 44, in match return _compile(pattern, flags).match(string) RuntimeError: maximum recursion limit exceeded The same pattern with even a much larger search buffer works fine on 1.52 This patch optimizes the case ".*?" and avoids the recursion limit. After the patch: >>> import re >>> re.findall('ab.*?bc', 'abababbc') ['abababbc'] >>> re.findall('ab??bc', 'abababbc') ['abbc'] >>> re.sub("(?s){.*?}","","{"+' '*19047+"}") '' >>> re.match("(?s){.*?}","{"+' '*16048+"}") <SRE_Match object at 007E4490> >>> import test.test_re Running tests on re.search and re.match Running tests on re.sub Running tests on symbolic references Running tests on re.subn Running tests on re.split Running tests on re.findall Running tests on re.match Running tests on re.escape Pickling a RegexObject instance Test engine limitations maximum recursion limit exceeded Running re_tests test suite >>> ------------------------------------------------------- Date: 2000-Sep-22 21:23 By: tim_one Comment: Assigned to Fredrik. dgallion, please resubmit a context diff. Straight diffs aren't accepted (they're too brittle). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101612&group_id=5470 From noreply@sourceforge.net Mon Jan 15 00:05:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 16:05:31 -0800 Subject: [Patches] [Patch #103235] getargs: better error messages for wrong # of args Message-ID: <E14Hx9P-0004pN-00@usw-sf-web2.sourceforge.net> Patch #103235 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : nobody Summary: getargs: better error messages for wrong # of args ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103235&group_id=5470 From noreply@sourceforge.net Mon Jan 15 00:37:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 16:37:23 -0800 Subject: [Patches] [Patch #103236] urllib: Encode special characters in user and password Message-ID: <E14HxeF-0003gR-00@usw-sf-web3.sourceforge.net> Patch #103236 has been updated. Project: python Category: library Status: Open Submitted by: dougfort Assigned to : nobody Summary: urllib: Encode special characters in user and password ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103236&group_id=5470 From noreply@sourceforge.net Mon Jan 15 07:02:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 23:02:39 -0800 Subject: [Patches] [Patch #101416] coax _sre.c into using Py_GetRecursionLimit() Message-ID: <E14I3f5-0005ZO-00@usw-sf-web3.sourceforge.net> Patch #101416 has been updated. Project: python Category: Modules Status: Postponed Submitted by: montanaro Assigned to : effbot Summary: coax _sre.c into using Py_GetRecursionLimit() Follow-Ups: Date: 2001-Jan-14 23:02 By: effbot Comment: A few months later, I'm still sceptical: an SRE stackframe isn't the same thing as a ceval stackframe, and I'm not sure using the same value for both makes much sense. I'll postpone it for now. ------------------------------------------------------- Date: 2000-Sep-04 09:02 By: montanaro Comment: seems obvious that Fredrik should be the one to handle this... ------------------------------------------------------- Date: 2000-Sep-15 07:21 By: fdrake Comment: The declaration of rlimit should be wrapped in #ifdef USE_RECURSION_LIMIT / #endif, since it isn't used otherwise. ------------------------------------------------------- Date: 2000-Sep-15 08:26 By: montanaro Comment: thanks - new version adds the appropriate ifdef ------------------------------------------------------- Date: 2000-Sep-22 05:54 By: fdrake Comment: Fredrik, are there problems with this patch? Does it not make sense? Please take action on this. ------------------------------------------------------- Date: 2000-Sep-25 09:50 By: montanaro Comment: Postponing this is okay with me, but I am almost certain the new _sre module is going to cause problems for nasty regular expressions that the 1.5.2 re module could handle. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101416&group_id=5470 From noreply@sourceforge.net Mon Jan 15 17:06:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 09:06:19 -0800 Subject: [Patches] [Patch #103243] another code.py fix - compiling can lead to UnicodeError Message-ID: <E14ID5H-0007gz-00@usw-sf-web1.sourceforge.net> Patch #103243 has been updated. Project: python Category: library Status: Open Submitted by: mwh Assigned to : nobody Summary: another code.py fix - compiling can lead to UnicodeError ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103243&group_id=5470 From noreply@sourceforge.net Mon Jan 15 17:07:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 09:07:24 -0800 Subject: [Patches] [Patch #103216] Auto-detect dbmmodule and build dynamically Message-ID: <E14ID6K-0000lr-00@usw-sf-web3.sourceforge.net> Patch #103216 has been updated. Project: python Category: Build Status: Closed Submitted by: bwarsaw Assigned to : gvanrossum Summary: Auto-detect dbmmodule and build dynamically Follow-Ups: Date: 2001-Jan-15 09:07 By: bwarsaw Comment: Patch approved by Guido, applied by Barry. ------------------------------------------------------- Date: 2001-Jan-12 10:00 By: bwarsaw Comment: Note, I had to rip out the diff to configure because SF complained about the size of the patch. :( Since that can be generated from configure.in, I'm not worrying about it. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103216&group_id=5470 From noreply@sourceforge.net Mon Jan 15 17:09:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 09:09:44 -0800 Subject: [Patches] [Patch #103243] another code.py fix - compiling can lead to UnicodeError Message-ID: <E14ID8a-0007iQ-00@usw-sf-web1.sourceforge.net> Patch #103243 has been updated. Project: python Category: library Status: Open Submitted by: mwh Assigned to : nobody Summary: another code.py fix - compiling can lead to UnicodeError Follow-Ups: Date: 2001-Jan-15 09:09 By: mwh Comment: <sigh> upload version that doesn't also have my last patch in it... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103243&group_id=5470 From noreply@sourceforge.net Mon Jan 15 17:10:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 09:10:47 -0800 Subject: [Patches] [Patch #103158] Don't do unsafe arithmetic in xrange object Message-ID: <E14ID9b-0007io-00@usw-sf-web1.sourceforge.net> Patch #103158 has been updated. Project: python Category: core (C code) Status: Open Submitted by: greg_ball Assigned to : gvanrossum Summary: Don't do unsafe arithmetic in xrange object Follow-Ups: Date: 2001-Jan-15 09:10 By: greg_ball Comment: If we only allow lengths that will fit into a C int, x = xrange(sys.maxint) would fail on 64-bit platforms. (and that code is always going to get written by people on 32-bit platforms.) Making some sort of special case for this particular idiom would not make the code simpler, I'm guessing. One obvious simple way to support it is by truncating the length to INT_MAX as is done in _PyEval_SliceIndex. Then len() and negative indexing can produce consistent non-garbage results, if not what the user might naively expect. In Python 2.0, you get garbage. Using my patch, you get an exception. But nobody actually uses those features, in all probability. Of course the natural extension of this approach is to allow any python integer arguments at all to xrange() (which Tim doesn't want to do) and truncate as necessary. But there is no need to go there; we can just leave bltin_xrange alone. As an aside, how important for performance is the use of C ints rather than C longs in the Python internals on 64 bit machines? 16 bit machines? ------------------------------------------------------- Date: 2001-Jan-12 12:11 By: greg_ball Comment: The new version of the patch makes the code a bit less complicated. (Only error messages have changed in terms of behaviour; regression test run under linux and OSF1.) If it looks ok you can ignore the rest of this comment... I originally made totlen an int because it is the return value from range_length, and the argument to PyList_New(). The current patch makes totlen a long, but the ocde doesn't get hugely less complicated. The code would get simpler if it rejected objects whose length doesn't fit into a int, but that seemed too easy and there is a small chance someone's code might break. On the other hand by rejecting objects whose stop can't be correctly calculated, I _might_ have broken code already. Break just means "now raises exception" though, nothing insidious. ------------------------------------------------------- Date: 2001-Jan-12 12:58 By: tim_one Comment: I'm aware of people who actually do x = xrange(sys.maxint) and that should continue to work. Python 2.0 already complains about more than that: >>> xrange(-1, sys.maxint) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange() has more than sys.maxint items >>> and I sure don't want to see that extended (unless it's part of a *sweeping* crusade to eradicate the visibile differences between ints and longs). ------------------------------------------------------- Date: 2001-Jan-12 12:44 By: gvanrossum Comment: In theory, there's a use for objects whose length doesn't fit in an int: for i in xrange(...) is routinely used for loops that expect to break well before the end but don't want to give an arbitrary upper bound. But I agree with Tim that this serves no real purpose. I think that if anything, the xrange() object should be scaled down. No repetition, no concationation, no slicing. the only real use ought to be "for i in xrange(...)". But of course, *that* is bound to break somebody's code somewhere. So let's not go there. But let's not complicate it any further. Prevent breakage, but don't stretch the functionality beyond what it currently does. ------------------------------------------------------- Date: 2001-Jan-12 12:35 By: tim_one Comment: Please do reject objects whose length doesn't fit into an int. I'll bet a dollar that no real code in the world will break as a result. I feel confident making that bet, because if someone's code *does* break as a result, it's worth a dollar to me to see Guido lecture them that their code was already broken <wink>. Really, it's very Pythonic to gripe about a problem just as soon as it crops up. It's not doing anyone a favor to delay griping until the object is used: at that point, it may be very difficult to figure out how the object *got* damaged. There's simply no payback in allowing creation of an unusable xrange object, and, as you say, life is simpler if you don't allow it. ------------------------------------------------------- Date: 2001-Jan-10 10:28 By: gvanrossum Comment: I wonder why you made totlen an int. This seems to complicate the code quite a bit. I'd suggest making it a long. Then you have to test whether it's > INT_MAX only in tolist() -- in that case you should raise MemoryError. Other than that, it looks decent! ------------------------------------------------------- Date: 2001-Jan-09 06:31 By: greg_ball Comment: This is a replacement for patch 103129, as suggested by tim_one. Possibly interesting aspects of the patch: - xrange objects with overflowing lengths are not gratutiously rejected. An error is raised only if the length becomes relevant, under len() or negative indexing. Bad lengths are stored as -1. Objects with bad lengths allow any non-negative integer index. - On 64 bit platforms, sequence multiplication seems to cause an unsafe cast from long to int. This patch does not address that issue. Without my patch, on i686 Linux: Python 2.0 (#25, Jan 2 2001, 12:18:07) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> y = xrange(maxint/2)*3 >>> len(y) -1073741827 >>> y[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> y.tolist() Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: listobject.c:33: bad argument to internal function >>> m = maxint >> 16 >>> xrange(0,maxint,m) xrange(0, -2147450883, 32767) >>> (xrange(1)*maxint)*maxint xrange(1) >>> With my patch Python 2.0 (#35, Jan 6 2001, 12:54:41) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> y = xrange(maxint/2)*3 >>> len(y) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> y.tolist() Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> m = maxint >> 16 >>> xrange(0,maxint,m) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer addition >>> (xrange(1)*maxint) * maxint Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer multiplication >>> Without patch on Digital Unix Python 2.0 (#5, Jan 6 2001, 15:42:58) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> xrange(0,maxint,m) xrange(0, -9223372034707292163, 2147483647) >>> xrange(1)*maxint xrange(0) >>> With patch Python 2.0 (#7, Jan 6 2001, 15:52:21) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> xrange(0,maxint,m) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer addition >>> xrange(1)*maxint xrange(0) >>> ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103158&group_id=5470 From noreply@sourceforge.net Mon Jan 15 18:14:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 10:14:17 -0800 Subject: [Patches] [Patch #103243] another code.py fix - compiling can lead to UnicodeError Message-ID: <E14IE93-0001Ba-00@usw-sf-web3.sourceforge.net> Patch #103243 has been updated. Project: python Category: library Status: Closed Submitted by: mwh Assigned to : gvanrossum Summary: another code.py fix - compiling can lead to UnicodeError Follow-Ups: Date: 2001-Jan-15 10:14 By: gvanrossum Comment: I'll do you one better -- ValueError can be raised too (try '\x'). Checked something in that catches both (UnicodeError is derived from ValueError). ------------------------------------------------------- Date: 2001-Jan-15 09:09 By: mwh Comment: <sigh> upload version that doesn't also have my last patch in it... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103243&group_id=5470 From noreply@sourceforge.net Mon Jan 15 18:16:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 10:16:03 -0800 Subject: [Patches] [Patch #103234] tokenize.py: add support for u"", U'', etc. Message-ID: <E14IEAl-0001CP-00@usw-sf-web3.sourceforge.net> Patch #103234 has been updated. Project: python Category: None Status: Open Submitted by: ping Assigned to : ping Summary: tokenize.py: add support for u"", U'', etc. Follow-Ups: Date: 2001-Jan-15 10:16 By: gvanrossum Comment: Check it in, ping! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103234&group_id=5470 From noreply@sourceforge.net Mon Jan 15 18:21:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 10:21:14 -0800 Subject: [Patches] [Patch #103235] getargs: better error messages for wrong # of args Message-ID: <E14IEFm-0001ED-00@usw-sf-web3.sourceforge.net> Patch #103235 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : ping Summary: getargs: better error messages for wrong # of args Follow-Ups: Date: 2001-Jan-15 10:21 By: gvanrossum Comment: Cool patch, Ping. Please check it in! Note that this breaks test_pyexpat; since the breakage seems to be just that the text of the error message has changed, I suggest that you can fix that, too! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103235&group_id=5470 From noreply@sourceforge.net Mon Jan 15 18:31:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 10:31:57 -0800 Subject: [Patches] [Patch #103236] urllib: Encode special characters in user and password Message-ID: <E14IEQ9-0008DZ-00@usw-sf-web1.sourceforge.net> Patch #103236 has been updated. Project: python Category: library Status: Closed Submitted by: dougfort Assigned to : gvanrossum Summary: urllib: Encode special characters in user and password Follow-Ups: Date: 2001-Jan-15 10:31 By: gvanrossum Comment: Done! Please next time send in a context diff, and please let it be a diff of (oldfile, newfile) rather than reversed. :-) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103236&group_id=5470 From noreply@sourceforge.net Mon Jan 15 18:59:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 10:59:24 -0800 Subject: [Patches] [Patch #103158] Don't do unsafe arithmetic in xrange object Message-ID: <E14IEqi-0008Nn-00@usw-sf-web1.sourceforge.net> Patch #103158 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: greg_ball Assigned to : gvanrossum Summary: Don't do unsafe arithmetic in xrange object Follow-Ups: Date: 2001-Jan-15 10:59 By: gvanrossum Comment: I've checked in this version of the patch -- having looked and thought it over for a bit, I agree that this is about as good as we can expect it to do without changing certain internal APIs. Your question about the wisdom of using ints is a good one! In particular it is stupid that PyIntObject holds a long but that the return value from the sq_length function is constrained to be an int. This is from way back when I thought that size_t would never be larger than int. Boy was I wrong. In an ideal world, the int size used for Python ints would be a configuration option, and the configure script would work hard to make it a 64-bit int whenever supported (even on 32-bit platforms). A simpler change would be to simply change the specification for sq_length to return a long, but that's not without problems: existing extensions would have to be recompiled for platforms where int and long aren't the same size (64-bit platforms except Win64). ------------------------------------------------------- Date: 2001-Jan-15 09:10 By: greg_ball Comment: If we only allow lengths that will fit into a C int, x = xrange(sys.maxint) would fail on 64-bit platforms. (and that code is always going to get written by people on 32-bit platforms.) Making some sort of special case for this particular idiom would not make the code simpler, I'm guessing. One obvious simple way to support it is by truncating the length to INT_MAX as is done in _PyEval_SliceIndex. Then len() and negative indexing can produce consistent non-garbage results, if not what the user might naively expect. In Python 2.0, you get garbage. Using my patch, you get an exception. But nobody actually uses those features, in all probability. Of course the natural extension of this approach is to allow any python integer arguments at all to xrange() (which Tim doesn't want to do) and truncate as necessary. But there is no need to go there; we can just leave bltin_xrange alone. As an aside, how important for performance is the use of C ints rather than C longs in the Python internals on 64 bit machines? 16 bit machines? ------------------------------------------------------- Date: 2001-Jan-12 12:11 By: greg_ball Comment: The new version of the patch makes the code a bit less complicated. (Only error messages have changed in terms of behaviour; regression test run under linux and OSF1.) If it looks ok you can ignore the rest of this comment... I originally made totlen an int because it is the return value from range_length, and the argument to PyList_New(). The current patch makes totlen a long, but the ocde doesn't get hugely less complicated. The code would get simpler if it rejected objects whose length doesn't fit into a int, but that seemed too easy and there is a small chance someone's code might break. On the other hand by rejecting objects whose stop can't be correctly calculated, I _might_ have broken code already. Break just means "now raises exception" though, nothing insidious. ------------------------------------------------------- Date: 2001-Jan-12 12:58 By: tim_one Comment: I'm aware of people who actually do x = xrange(sys.maxint) and that should continue to work. Python 2.0 already complains about more than that: >>> xrange(-1, sys.maxint) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange() has more than sys.maxint items >>> and I sure don't want to see that extended (unless it's part of a *sweeping* crusade to eradicate the visibile differences between ints and longs). ------------------------------------------------------- Date: 2001-Jan-12 12:44 By: gvanrossum Comment: In theory, there's a use for objects whose length doesn't fit in an int: for i in xrange(...) is routinely used for loops that expect to break well before the end but don't want to give an arbitrary upper bound. But I agree with Tim that this serves no real purpose. I think that if anything, the xrange() object should be scaled down. No repetition, no concationation, no slicing. the only real use ought to be "for i in xrange(...)". But of course, *that* is bound to break somebody's code somewhere. So let's not go there. But let's not complicate it any further. Prevent breakage, but don't stretch the functionality beyond what it currently does. ------------------------------------------------------- Date: 2001-Jan-12 12:35 By: tim_one Comment: Please do reject objects whose length doesn't fit into an int. I'll bet a dollar that no real code in the world will break as a result. I feel confident making that bet, because if someone's code *does* break as a result, it's worth a dollar to me to see Guido lecture them that their code was already broken <wink>. Really, it's very Pythonic to gripe about a problem just as soon as it crops up. It's not doing anyone a favor to delay griping until the object is used: at that point, it may be very difficult to figure out how the object *got* damaged. There's simply no payback in allowing creation of an unusable xrange object, and, as you say, life is simpler if you don't allow it. ------------------------------------------------------- Date: 2001-Jan-10 10:28 By: gvanrossum Comment: I wonder why you made totlen an int. This seems to complicate the code quite a bit. I'd suggest making it a long. Then you have to test whether it's > INT_MAX only in tolist() -- in that case you should raise MemoryError. Other than that, it looks decent! ------------------------------------------------------- Date: 2001-Jan-09 06:31 By: greg_ball Comment: This is a replacement for patch 103129, as suggested by tim_one. Possibly interesting aspects of the patch: - xrange objects with overflowing lengths are not gratutiously rejected. An error is raised only if the length becomes relevant, under len() or negative indexing. Bad lengths are stored as -1. Objects with bad lengths allow any non-negative integer index. - On 64 bit platforms, sequence multiplication seems to cause an unsafe cast from long to int. This patch does not address that issue. Without my patch, on i686 Linux: Python 2.0 (#25, Jan 2 2001, 12:18:07) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> y = xrange(maxint/2)*3 >>> len(y) -1073741827 >>> y[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> y.tolist() Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: listobject.c:33: bad argument to internal function >>> m = maxint >> 16 >>> xrange(0,maxint,m) xrange(0, -2147450883, 32767) >>> (xrange(1)*maxint)*maxint xrange(1) >>> With my patch Python 2.0 (#35, Jan 6 2001, 12:54:41) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> y = xrange(maxint/2)*3 >>> len(y) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> y.tolist() Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> m = maxint >> 16 >>> xrange(0,maxint,m) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer addition >>> (xrange(1)*maxint) * maxint Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer multiplication >>> Without patch on Digital Unix Python 2.0 (#5, Jan 6 2001, 15:42:58) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> xrange(0,maxint,m) xrange(0, -9223372034707292163, 2147483647) >>> xrange(1)*maxint xrange(0) >>> With patch Python 2.0 (#7, Jan 6 2001, 15:52:21) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> xrange(0,maxint,m) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer addition >>> xrange(1)*maxint xrange(0) >>> ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103158&group_id=5470 From noreply@sourceforge.net Mon Jan 15 19:08:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 11:08:29 -0800 Subject: [Patches] [Patch #103123] PEP 232 implementation (function attributes) Message-ID: <E14IEzV-0008RT-00@usw-sf-web1.sourceforge.net> Patch #103123 has been updated. Project: python Category: core (C code) Status: Open Submitted by: bwarsaw Assigned to : gvanrossum Summary: PEP 232 implementation (function attributes) Follow-Ups: Date: 2001-Jan-15 11:08 By: gvanrossum Comment: Looks good, Barry. Check it in. Please also add an item to the NEWS file! ------------------------------------------------------- Date: 2001-Jan-06 07:34 By: montanaro Comment: Quick nit in the doc: How about "functions written in Python" instead of "non-built-in functions"? - right at the start of the patch. Also, how about an example of what you are trying to avoid when you don't allow setting bound methods' attributes (besides the obvious fact that classes and instances already have their own attributes) class C: def meth(self): print "hi!" c = C() d = C() c.meth.attr = "my name is 'c'" d.meth.attr = "my name is 'd'" If bound method attribute setting was allowed, c.meth.attr return "my name is 'd'"... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103123&group_id=5470 From noreply@sourceforge.net Mon Jan 15 19:50:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 11:50:35 -0800 Subject: [Patches] [Patch #103123] PEP 232 implementation (function attributes) Message-ID: <E14IFeF-0000Fb-00@usw-sf-web1.sourceforge.net> Patch #103123 has been updated. Project: python Category: core (C code) Status: Open Submitted by: bwarsaw Assigned to : bwarsaw Summary: PEP 232 implementation (function attributes) Follow-Ups: Date: 2001-Jan-15 11:08 By: gvanrossum Comment: Looks good, Barry. Check it in. Please also add an item to the NEWS file! ------------------------------------------------------- Date: 2001-Jan-06 07:34 By: montanaro Comment: Quick nit in the doc: How about "functions written in Python" instead of "non-built-in functions"? - right at the start of the patch. Also, how about an example of what you are trying to avoid when you don't allow setting bound methods' attributes (besides the obvious fact that classes and instances already have their own attributes) class C: def meth(self): print "hi!" c = C() d = C() c.meth.attr = "my name is 'c'" d.meth.attr = "my name is 'd'" If bound method attribute setting was allowed, c.meth.attr return "my name is 'd'"... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103123&group_id=5470 From noreply@sourceforge.net Mon Jan 15 20:49:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 12:49:51 -0800 Subject: [Patches] [Patch #103123] PEP 232 implementation (function attributes) Message-ID: <E14IGZb-00028K-00@usw-sf-web3.sourceforge.net> Patch #103123 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: bwarsaw Assigned to : bwarsaw Summary: PEP 232 implementation (function attributes) Follow-Ups: Date: 2001-Jan-15 12:49 By: bwarsaw Comment: Patch has been applied. ------------------------------------------------------- Date: 2001-Jan-15 11:08 By: gvanrossum Comment: Looks good, Barry. Check it in. Please also add an item to the NEWS file! ------------------------------------------------------- Date: 2001-Jan-06 07:34 By: montanaro Comment: Quick nit in the doc: How about "functions written in Python" instead of "non-built-in functions"? - right at the start of the patch. Also, how about an example of what you are trying to avoid when you don't allow setting bound methods' attributes (besides the obvious fact that classes and instances already have their own attributes) class C: def meth(self): print "hi!" c = C() d = C() c.meth.attr = "my name is 'c'" d.meth.attr = "my name is 'd'" If bound method attribute setting was allowed, c.meth.attr return "my name is 'd'"... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103123&group_id=5470 From noreply@sourceforge.net Mon Jan 15 22:06:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 14:06:44 -0800 Subject: [Patches] [Patch #103234] tokenize.py: add support for u"", U'', etc. Message-ID: <E14IHm0-000196-00@usw-sf-web1.sourceforge.net> Patch #103234 has been updated. Project: python Category: None Status: Closed Submitted by: ping Assigned to : ping Summary: tokenize.py: add support for u"", U'', etc. Follow-Ups: Date: 2001-Jan-15 14:06 By: ping Comment: Okay, done. ------------------------------------------------------- Date: 2001-Jan-15 10:16 By: gvanrossum Comment: Check it in, ping! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103234&group_id=5470 From noreply@sourceforge.net Mon Jan 15 22:18:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 14:18:57 -0800 Subject: [Patches] [Patch #103235] getargs: better error messages for wrong # of args Message-ID: <E14IHxp-0002i6-00@usw-sf-web3.sourceforge.net> Patch #103235 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: ping Assigned to : ping Summary: getargs: better error messages for wrong # of args Follow-Ups: Date: 2001-Jan-15 14:18 By: ping Comment: Sorry, i didn't have XML libraries installed, so regrtest skipped py_expat. I updated test/output/test_pyexpat; it should be right now. Checked in; thanks! ------------------------------------------------------- Date: 2001-Jan-15 10:21 By: gvanrossum Comment: Cool patch, Ping. Please check it in! Note that this breaks test_pyexpat; since the breakage seems to be just that the text of the error message has changed, I suggest that you can fix that, too! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103235&group_id=5470 From noreply@sourceforge.net Mon Jan 15 22:21:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 14:21:54 -0800 Subject: [Patches] [Patch #102679] linuxaudiodev: better format names (and error messages) Message-ID: <E14II0g-0002j2-00@usw-sf-web3.sourceforge.net> Patch #102679 has been updated. Project: python Category: Modules Status: Closed Submitted by: ping Assigned to : ping Summary: linuxaudiodev: better format names (and error messages) Follow-Ups: Date: 2001-Jan-15 14:21 By: ping Comment: Checked in. ------------------------------------------------------- Date: 2001-Jan-04 11:31 By: fdrake Comment: Looks good; please check this in. ------------------------------------------------------- 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 Mon Jan 15 22:34:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 14:34:23 -0800 Subject: [Patches] [Patch #103246] Remove unneeded string exception compat from Queue Message-ID: <E14IICl-0001JJ-00@usw-sf-web1.sourceforge.net> Patch #103246 has been updated. Project: python Category: None Status: Open Submitted by: montanaro Assigned to : nobody Summary: Remove unneeded string exception compat from Queue ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103246&group_id=5470 From noreply@sourceforge.net Mon Jan 15 22:43:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 14:43:15 -0800 Subject: [Patches] [Patch #103246] Remove unneeded string exception compat from Queue Message-ID: <E14IILL-0001Mi-00@usw-sf-web1.sourceforge.net> Patch #103246 has been updated. Project: python Category: None Status: Open Submitted by: montanaro Assigned to : tim_one Summary: Remove unneeded string exception compat from Queue Follow-Ups: Date: 2001-Jan-15 14:43 By: tim_one Comment: Assigned to me. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103246&group_id=5470 From noreply@sourceforge.net Mon Jan 15 22:44:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 14:44:13 -0800 Subject: [Patches] [Patch #103247] Strings: '\012' -> '\n' Message-ID: <E14IIMH-00047X-00@usw-sf-web2.sourceforge.net> Patch #103247 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : nobody Summary: Strings: '\012' -> '\n' ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103247&group_id=5470 From noreply@sourceforge.net Mon Jan 15 22:55:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 14:55:07 -0800 Subject: [Patches] [Patch #103246] Remove unneeded string exception compat from Queue Message-ID: <E14IIWp-0001Qw-00@usw-sf-web1.sourceforge.net> Patch #103246 has been updated. Project: python Category: library Status: Closed Submitted by: montanaro Assigned to : tim_one Summary: Remove unneeded string exception compat from Queue Follow-Ups: Date: 2001-Jan-15 14:55 By: tim_one Comment: Thanks, Skip! I checked in a minor variant in Queue.py rev 1.12. I sure hope you don't get another job <wink>. ------------------------------------------------------- Date: 2001-Jan-15 14:43 By: tim_one Comment: Assigned to me. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103246&group_id=5470 From noreply@sourceforge.net Mon Jan 15 23:35:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 15:35:12 -0800 Subject: [Patches] [Patch #103248] Fix a memory leak in _sre.c Message-ID: <E14IJ9c-00038X-00@usw-sf-web3.sourceforge.net> Patch #103248 has been updated. Project: python Category: core (C code) Status: Open Submitted by: cgw Assigned to : nobody Summary: Fix a memory leak in _sre.c ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103248&group_id=5470 From noreply@sourceforge.net Tue Jan 16 00:32:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 16:32:33 -0800 Subject: [Patches] [Patch #103249] fix for bug # 128921 Message-ID: <E14IK37-0003RW-00@usw-sf-web3.sourceforge.net> Patch #103249 has been updated. Project: python Category: core (C code) Status: Open Submitted by: mwh Assigned to : nobody Summary: fix for bug # 128921 ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103249&group_id=5470 From noreply@sourceforge.net Tue Jan 16 00:42:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 16:42:26 -0800 Subject: [Patches] [Patch #103250] Optimize a strspn() out of startup Message-ID: <E14IKCg-00023I-00@usw-sf-web1.sourceforge.net> Patch #103250 has been updated. Project: python Category: None Status: Open Submitted by: pj99 Assigned to : nobody Summary: Optimize a strspn() out of startup ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103250&group_id=5470 From noreply@sourceforge.net Tue Jan 16 01:55:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 17:55:51 -0800 Subject: [Patches] [Patch #103252] Startup optimize: read *.pyc as string, not with getc() Message-ID: <E14ILLj-0002Qe-00@usw-sf-web1.sourceforge.net> Patch #103252 has been updated. Project: python Category: core (C code) Status: Open Submitted by: pj99 Assigned to : nobody Summary: Startup optimize: read *.pyc as string, not with getc() ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103252&group_id=5470 From noreply@sourceforge.net Tue Jan 16 02:16:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 18:16:20 -0800 Subject: [Patches] [Patch #103253] Plug memory leak in posixmodule.c Message-ID: <E14ILfY-0003za-00@usw-sf-web3.sourceforge.net> Patch #103253 has been updated. Project: python Category: None Status: Open Submitted by: nascheme Assigned to : nobody Summary: Plug memory leak in posixmodule.c ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103253&group_id=5470 From noreply@sourceforge.net Tue Jan 16 02:18:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 18:18:54 -0800 Subject: [Patches] [Patch #103253] Plug memory leak in posixmodule.c Message-ID: <E14ILi2-00040F-00@usw-sf-web3.sourceforge.net> Patch #103253 has been updated. Project: python Category: None Status: Open Submitted by: nascheme Assigned to : gvanrossum Summary: Plug memory leak in posixmodule.c Follow-Ups: Date: 2001-Jan-15 18:18 By: nascheme Comment: Assigned to Guido because I think he last touched the posix_putenv_garbage code. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103253&group_id=5470 From noreply@sourceforge.net Tue Jan 16 03:30:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 19:30:34 -0800 Subject: [Patches] [Patch #103248] Fix a memory leak in _sre.c Message-ID: <E14IMpO-0002wt-00@usw-sf-web1.sourceforge.net> Patch #103248 has been updated. Project: python Category: core (C code) Status: Open Submitted by: cgw Assigned to : effbot Summary: Fix a memory leak in _sre.c ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103248&group_id=5470 From noreply@sourceforge.net Tue Jan 16 03:35:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 19:35:03 -0800 Subject: [Patches] [Patch #103250] Optimize a strspn() out of startup Message-ID: <E14IMtj-0002yg-00@usw-sf-web1.sourceforge.net> Patch #103250 has been updated. Project: python Category: None Status: Open Submitted by: pj99 Assigned to : nobody Summary: Optimize a strspn() out of startup Follow-Ups: Date: 2001-Jan-15 19:35 By: gvanrossum Comment: Looks cool to me. Do you have an idea what to do about the other 98.5%? :) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103250&group_id=5470 From noreply@sourceforge.net Tue Jan 16 03:39:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 19:39:45 -0800 Subject: [Patches] [Patch #103252] Startup optimize: read *.pyc as string, not with getc() Message-ID: <E14IMyH-00030K-00@usw-sf-web1.sourceforge.net> Patch #103252 has been updated. Project: python Category: core (C code) Status: Open Submitted by: pj99 Assigned to : nobody Summary: Startup optimize: read *.pyc as string, not with getc() Follow-Ups: Date: 2001-Jan-15 19:39 By: gvanrossum Comment: Not a bad idea. I'd up the limit to 256K so Tkinter.pyc (comfortably) fits. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103252&group_id=5470 From noreply@sourceforge.net Tue Jan 16 03:41:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 19:41:11 -0800 Subject: [Patches] [Patch #103253] Plug memory leak in posixmodule.c Message-ID: <E14IMzf-00030o-00@usw-sf-web1.sourceforge.net> Patch #103253 has been updated. Project: python Category: None Status: Open Submitted by: nascheme Assigned to : nascheme Summary: Plug memory leak in posixmodule.c Follow-Ups: Date: 2001-Jan-15 19:41 By: gvanrossum Comment: Excellent, please check in and close the patch! ------------------------------------------------------- Date: 2001-Jan-15 18:18 By: nascheme Comment: Assigned to Guido because I think he last touched the posix_putenv_garbage code. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103253&group_id=5470 From noreply@sourceforge.net Tue Jan 16 04:05:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 20:05:42 -0800 Subject: [Patches] [Patch #103252] Startup optimize: read *.pyc as string, not with getc() Message-ID: <E14INNO-0004Wm-00@usw-sf-web3.sourceforge.net> Patch #103252 has been updated. Project: python Category: core (C code) Status: Open Submitted by: pj99 Assigned to : nobody Summary: Startup optimize: read *.pyc as string, not with getc() Follow-Ups: Date: 2001-Jan-15 20:05 By: tim_one Comment: I like the idea, but gimmicks like this make porting to tiny platforms harder when pushed "too far". People concerned about startup time seem mostly to deal with apps that e.g. fire up Python 1000s of times from shell scripts or cgi. They're not going to care about monster modules (like Tkinter and grail). So I think Paul's original 64K is a good compromise. ------------------------------------------------------- Date: 2001-Jan-15 19:39 By: gvanrossum Comment: Not a bad idea. I'd up the limit to 256K so Tkinter.pyc (comfortably) fits. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103252&group_id=5470 From noreply@sourceforge.net Tue Jan 16 04:18:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 20:18:51 -0800 Subject: [Patches] [Patch #103252] Startup optimize: read *.pyc as string, not with getc() Message-ID: <E14INa7-0004b1-00@usw-sf-web3.sourceforge.net> Patch #103252 has been updated. Project: python Category: core (C code) Status: Open Submitted by: pj99 Assigned to : nobody Summary: Startup optimize: read *.pyc as string, not with getc() Follow-Ups: Date: 2001-Jan-15 20:18 By: gvanrossum Comment: Oh, but I do care about the load time of Tkinter. :-) Anything to keep IDLE ahead of Komodo in the race. :-) ------------------------------------------------------- Date: 2001-Jan-15 20:05 By: tim_one Comment: I like the idea, but gimmicks like this make porting to tiny platforms harder when pushed "too far". People concerned about startup time seem mostly to deal with apps that e.g. fire up Python 1000s of times from shell scripts or cgi. They're not going to care about monster modules (like Tkinter and grail). So I think Paul's original 64K is a good compromise. ------------------------------------------------------- Date: 2001-Jan-15 19:39 By: gvanrossum Comment: Not a bad idea. I'd up the limit to 256K so Tkinter.pyc (comfortably) fits. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103252&group_id=5470 From noreply@sourceforge.net Tue Jan 16 04:21:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 20:21:08 -0800 Subject: [Patches] [Patch #103247] Strings: '\012' -> '\n' Message-ID: <E14INcK-0004bp-00@usw-sf-web3.sourceforge.net> Patch #103247 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : nobody Summary: Strings: '\012' -> '\n' Follow-Ups: Date: 2001-Jan-15 20:21 By: gvanrossum Comment: Nice. Style nit: I don't care for the fputc(), fputc(); form. Can you resubmit (and retest!) a version that uses \x%02x too? I'd expect that this would require updates to some docs and the tutorial, too. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103247&group_id=5470 From noreply@sourceforge.net Tue Jan 16 04:21:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 20:21:18 -0800 Subject: [Patches] [Patch #103247] Strings: '\012' -> '\n' Message-ID: <E14INcU-0004bx-00@usw-sf-web3.sourceforge.net> Patch #103247 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : ping Summary: Strings: '\012' -> '\n' Follow-Ups: Date: 2001-Jan-15 20:21 By: gvanrossum Comment: Nice. Style nit: I don't care for the fputc(), fputc(); form. Can you resubmit (and retest!) a version that uses \x%02x too? I'd expect that this would require updates to some docs and the tutorial, too. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103247&group_id=5470 From noreply@sourceforge.net Tue Jan 16 04:26:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 20:26:06 -0800 Subject: [Patches] [Patch #103252] Startup optimize: read *.pyc as string, not with getc() Message-ID: <E14INh8-0003GC-00@usw-sf-web1.sourceforge.net> Patch #103252 has been updated. Project: python Category: core (C code) Status: Open Submitted by: pj99 Assigned to : tim_one Summary: Startup optimize: read *.pyc as string, not with getc() Follow-Ups: Date: 2001-Jan-15 20:26 By: tim_one Comment: Indeed, IDLE takes more than a full second to come up on my box, *much* longer than Notepad. Now that we have a clear goal, I assigned this patch to me <wink>. (OK, it's really that I was abrupt with Paul when this came up on c.l.py, and left him hanging there -- I owe him on this one). ------------------------------------------------------- Date: 2001-Jan-15 20:18 By: gvanrossum Comment: Oh, but I do care about the load time of Tkinter. :-) Anything to keep IDLE ahead of Komodo in the race. :-) ------------------------------------------------------- Date: 2001-Jan-15 20:05 By: tim_one Comment: I like the idea, but gimmicks like this make porting to tiny platforms harder when pushed "too far". People concerned about startup time seem mostly to deal with apps that e.g. fire up Python 1000s of times from shell scripts or cgi. They're not going to care about monster modules (like Tkinter and grail). So I think Paul's original 64K is a good compromise. ------------------------------------------------------- Date: 2001-Jan-15 19:39 By: gvanrossum Comment: Not a bad idea. I'd up the limit to 256K so Tkinter.pyc (comfortably) fits. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103252&group_id=5470 From noreply@sourceforge.net Tue Jan 16 04:28:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 20:28:23 -0800 Subject: [Patches] [Patch #103253] Plug memory leak in posixmodule.c Message-ID: <E14INjL-0005wx-00@usw-sf-web2.sourceforge.net> Patch #103253 has been updated. Project: python Category: None Status: Closed Submitted by: nascheme Assigned to : nascheme Summary: Plug memory leak in posixmodule.c Follow-Ups: Date: 2001-Jan-15 20:28 By: nascheme Comment: Checked in (posixmodule.c 2.181). ------------------------------------------------------- Date: 2001-Jan-15 19:41 By: gvanrossum Comment: Excellent, please check in and close the patch! ------------------------------------------------------- Date: 2001-Jan-15 18:18 By: nascheme Comment: Assigned to Guido because I think he last touched the posix_putenv_garbage code. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103253&group_id=5470 From noreply@sourceforge.net Tue Jan 16 05:30:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 21:30:23 -0800 Subject: [Patches] [Patch #102891] Alternative readline module Message-ID: <E14IOhL-0003cS-00@usw-sf-web1.sourceforge.net> Patch #102891 has been updated. Project: python Category: Modules Status: Accepted Submitted by: nascheme Assigned to : esr Summary: Alternative readline module Follow-Ups: Date: 2001-Jan-15 21:30 By: nascheme Comment: Hmm, I still like pyrl better. What to do about GNU readline now that its in Setup.conf? You can't enable them both and I don't feel comfortable enough with autoconf to fix things. ESR, if you could add the magic to test for termios that would be cool. configure should use readline if its there and fall back to edline if termios is available. Feel free to bounce it back to me if you don't have time. ------------------------------------------------------- Date: 2001-Jan-03 06:10 By: gvanrossum Comment: Neil, this has now status Accepted. Go ahead and check it in! ------------------------------------------------------- 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 Tue Jan 16 05:42:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 21:42:27 -0800 Subject: [Patches] [Patch #103247] Strings: '\012' -> '\n' Message-ID: <E14IOt1-0006Km-00@usw-sf-web2.sourceforge.net> Patch #103247 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : ping Summary: Strings: '\012' -> '\n' Follow-Ups: Date: 2001-Jan-15 21:42 By: ping Comment: Yes, the docs will take some work. I'll resubmit when i've gone through all the documentation. ------------------------------------------------------- Date: 2001-Jan-15 20:21 By: gvanrossum Comment: Nice. Style nit: I don't care for the fputc(), fputc(); form. Can you resubmit (and retest!) a version that uses \x%02x too? I'd expect that this would require updates to some docs and the tutorial, too. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103247&group_id=5470 From noreply@sourceforge.net Tue Jan 16 06:50:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 22:50:10 -0800 Subject: [Patches] [Patch #103248] Fix a memory leak in _sre.c Message-ID: <E14IPwY-00042i-00@usw-sf-web1.sourceforge.net> Patch #103248 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: cgw Assigned to : effbot Summary: Fix a memory leak in _sre.c ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103248&group_id=5470 From noreply@sourceforge.net Tue Jan 16 07:25:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 23:25:40 -0800 Subject: [Patches] [Patch #103250] Optimize a strspn() out of startup Message-ID: <E14IQUu-0005YB-00@usw-sf-web3.sourceforge.net> Patch #103250 has been updated. Project: python Category: None Status: Open Submitted by: pj99 Assigned to : nobody Summary: Optimize a strspn() out of startup Follow-Ups: Date: 2001-Jan-15 23:25 By: nobody Comment: Why not (isalpha(c) || isdigit(c) || c=='_') ? ------------------------------------------------------- Date: 2001-Jan-15 19:35 By: gvanrossum Comment: Looks cool to me. Do you have an idea what to do about the other 98.5%? :) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103250&group_id=5470 From noreply@sourceforge.net Tue Jan 16 10:25:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 02:25:05 -0800 Subject: [Patches] [Patch #102891] Alternative readline module Message-ID: <E14ITIX-0007Re-00@usw-sf-web2.sourceforge.net> Patch #102891 has been updated. Project: python Category: Modules Status: Accepted Submitted by: nascheme Assigned to : esr Summary: Alternative readline module Follow-Ups: Date: 2001-Jan-16 02:23 By: mwh Comment: You could defer the decision between readline and edline until runtime, as in: (will sf mangle this? we'll see) Index: Modules/main.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/main.c,v retrieving revision 1.47 diff -c -r1.47 main.c *** Modules/main.c 2000/12/15 22:00:54 1.47 --- Modules/main.c 2001/01/16 10:19:45 *************** *** 267,274 **** isatty(fileno(stdin))) { PyObject *v; v = PyImport_ImportModule("readline"); ! if (v == NULL) PyErr_Clear(); else Py_DECREF(v); } --- 267,280 ---- isatty(fileno(stdin))) { PyObject *v; v = PyImport_ImportModule("readline"); ! if (v == NULL) { PyErr_Clear(); + v = PyImport_ImportModule("edline"); + if (v == NULL) + PyErr_Clear(); + else + Py_DECREF(v); + } else Py_DECREF(v); } (and pyrl's not going to be ready for 2.1, by a country mile...) ------------------------------------------------------- Date: 2001-Jan-15 21:30 By: nascheme Comment: Hmm, I still like pyrl better. What to do about GNU readline now that its in Setup.conf? You can't enable them both and I don't feel comfortable enough with autoconf to fix things. ESR, if you could add the magic to test for termios that would be cool. configure should use readline if its there and fall back to edline if termios is available. Feel free to bounce it back to me if you don't have time. ------------------------------------------------------- Date: 2001-Jan-03 06:10 By: gvanrossum Comment: Neil, this has now status Accepted. Go ahead and check it in! ------------------------------------------------------- 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 Tue Jan 16 10:26:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 02:26:47 -0800 Subject: [Patches] [Patch #103258] Cookie.py docs: example incorrect Message-ID: <E14ITKB-0005K9-00@usw-sf-web1.sourceforge.net> Patch #103258 has been updated. Project: python Category: documentation Status: Open Submitted by: ping Assigned to : nobody Summary: Cookie.py docs: example incorrect ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103258&group_id=5470 From noreply@sourceforge.net Tue Jan 16 10:29:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 02:29:17 -0800 Subject: [Patches] [Patch #103259] Tutorial: Unicode section says UTF-8 is default Message-ID: <E14ITMb-0005LP-00@usw-sf-web1.sourceforge.net> Patch #103259 has been updated. Project: python Category: documentation Status: Open Submitted by: ping Assigned to : nobody Summary: Tutorial: Unicode section says UTF-8 is default ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103259&group_id=5470 From esr@thyrsus.com Tue Jan 16 10:51:46 2001 From: esr@thyrsus.com (Eric S. Raymond) Date: Tue, 16 Jan 2001 05:51:46 -0500 Subject: [Patches] Re: [Patch #102891] Alternative readline module In-Reply-To: <E14ITIX-0007Re-00@usw-sf-web2.sourceforge.net>; from noreply@sourceforge.net on Tue, Jan 16, 2001 at 02:25:05AM -0800 References: <E14ITIX-0007Re-00@usw-sf-web2.sourceforge.net> Message-ID: <20010116055146.B12847@thyrsus.com> noreply@sourceforge.net <noreply@sourceforge.net>: > ESR, if you could add the magic > to test for termios that would be cool. configure should > use readline if its there and fall back to edline if > termios is available. > > Feel free to bounce it back to me if you don't have time. I'm on it. Gotta ship my PC9 paper first, though. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> The right of self-defense is the first law of nature: in most governments it has been the study of rulers to confine this right within the narrowest limits possible. Wherever standing armies are kept up, and when the right of the people to keep and bear arms is, under any color or pretext whatsoever, prohibited, liberty, if not already annihilated, is on the brink of destruction." -- Henry St. George Tucker (in Blackstone's Commentaries) From noreply@sourceforge.net Tue Jan 16 13:41:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 05:41:25 -0800 Subject: [Patches] [Patch #102891] Alternative readline module Message-ID: <E14IWMX-0006UZ-00@usw-sf-web1.sourceforge.net> Patch #102891 has been updated. Project: python Category: Modules Status: Accepted Submitted by: nascheme Assigned to : esr Summary: Alternative readline module Follow-Ups: Date: 2001-Jan-16 05:41 By: gvanrossum Comment: What's pyrl in this context? A Google search turns up a bunch of references to a Perl preprocessor that takes Pythonic syntax and translates it into Perl. :-) [ESR replied Neil via email: "I'm on it. Gotta ship my PC9 paper first, though."] ------------------------------------------------------- Date: 2001-Jan-16 02:23 By: mwh Comment: You could defer the decision between readline and edline until runtime, as in: (will sf mangle this? we'll see) Index: Modules/main.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/main.c,v retrieving revision 1.47 diff -c -r1.47 main.c *** Modules/main.c 2000/12/15 22:00:54 1.47 --- Modules/main.c 2001/01/16 10:19:45 *************** *** 267,274 **** isatty(fileno(stdin))) { PyObject *v; v = PyImport_ImportModule("readline"); ! if (v == NULL) PyErr_Clear(); else Py_DECREF(v); } --- 267,280 ---- isatty(fileno(stdin))) { PyObject *v; v = PyImport_ImportModule("readline"); ! if (v == NULL) { PyErr_Clear(); + v = PyImport_ImportModule("edline"); + if (v == NULL) + PyErr_Clear(); + else + Py_DECREF(v); + } else Py_DECREF(v); } (and pyrl's not going to be ready for 2.1, by a country mile...) ------------------------------------------------------- Date: 2001-Jan-15 21:30 By: nascheme Comment: Hmm, I still like pyrl better. What to do about GNU readline now that its in Setup.conf? You can't enable them both and I don't feel comfortable enough with autoconf to fix things. ESR, if you could add the magic to test for termios that would be cool. configure should use readline if its there and fall back to edline if termios is available. Feel free to bounce it back to me if you don't have time. ------------------------------------------------------- Date: 2001-Jan-03 06:10 By: gvanrossum Comment: Neil, this has now status Accepted. Go ahead and check it in! ------------------------------------------------------- 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 Tue Jan 16 14:21:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 06:21:41 -0800 Subject: [Patches] [Patch #103258] Cookie.py docs: example incorrect Message-ID: <E14IWzV-0000Rz-00@usw-sf-web2.sourceforge.net> Patch #103258 has been updated. Project: python Category: documentation Status: Open Submitted by: ping Assigned to : fdrake Summary: Cookie.py docs: example incorrect ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103258&group_id=5470 From noreply@sourceforge.net Tue Jan 16 14:21:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 06:21:53 -0800 Subject: [Patches] [Patch #103250] Optimize a strspn() out of startup Message-ID: <E14IWzh-0000ST-00@usw-sf-web2.sourceforge.net> Patch #103250 has been updated. Project: python Category: None Status: Open Submitted by: pj99 Assigned to : gvanrossum Summary: Optimize a strspn() out of startup Follow-Ups: Date: 2001-Jan-15 23:25 By: nobody Comment: Why not (isalpha(c) || isdigit(c) || c=='_') ? ------------------------------------------------------- Date: 2001-Jan-15 19:35 By: gvanrossum Comment: Looks cool to me. Do you have an idea what to do about the other 98.5%? :) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103250&group_id=5470 From noreply@sourceforge.net Tue Jan 16 14:22:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 06:22:02 -0800 Subject: [Patches] [Patch #103259] Tutorial: Unicode section says UTF-8 is default Message-ID: <E14IWzq-0000Sb-00@usw-sf-web2.sourceforge.net> Patch #103259 has been updated. Project: python Category: documentation Status: Open Submitted by: ping Assigned to : fdrake Summary: Tutorial: Unicode section says UTF-8 is default ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103259&group_id=5470 From noreply@sourceforge.net Tue Jan 16 14:23:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 06:23:53 -0800 Subject: [Patches] [Patch #103249] fix for bug # 128921 Message-ID: <E14IX1d-0000T5-00@usw-sf-web2.sourceforge.net> Patch #103249 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: mwh Assigned to : lemburg Summary: fix for bug # 128921 Follow-Ups: Date: 2001-Jan-16 06:23 By: gvanrossum Comment: Marc-Andre checked in an extended version of this patch. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103249&group_id=5470 From noreply@sourceforge.net Tue Jan 16 14:34:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 06:34:02 -0800 Subject: [Patches] [Patch #102891] Alternative readline module Message-ID: <E14IXBS-000713-00@usw-sf-web1.sourceforge.net> Patch #102891 has been updated. Project: python Category: Modules Status: Accepted Submitted by: nascheme Assigned to : esr Summary: Alternative readline module Follow-Ups: Date: 2001-Jan-16 06:34 By: mwh Comment: pyrl is my line reader written in Python that I've been intermittently blathering about on python-dev: http://www-jcsu.jesus.cam.ac.uk/~mwh21/hacks/pyrl-0.2.0.tar.gz it's still very experimental, though. ------------------------------------------------------- Date: 2001-Jan-16 05:41 By: gvanrossum Comment: What's pyrl in this context? A Google search turns up a bunch of references to a Perl preprocessor that takes Pythonic syntax and translates it into Perl. :-) [ESR replied Neil via email: "I'm on it. Gotta ship my PC9 paper first, though."] ------------------------------------------------------- Date: 2001-Jan-16 02:23 By: mwh Comment: You could defer the decision between readline and edline until runtime, as in: (will sf mangle this? we'll see) Index: Modules/main.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/main.c,v retrieving revision 1.47 diff -c -r1.47 main.c *** Modules/main.c 2000/12/15 22:00:54 1.47 --- Modules/main.c 2001/01/16 10:19:45 *************** *** 267,274 **** isatty(fileno(stdin))) { PyObject *v; v = PyImport_ImportModule("readline"); ! if (v == NULL) PyErr_Clear(); else Py_DECREF(v); } --- 267,280 ---- isatty(fileno(stdin))) { PyObject *v; v = PyImport_ImportModule("readline"); ! if (v == NULL) { PyErr_Clear(); + v = PyImport_ImportModule("edline"); + if (v == NULL) + PyErr_Clear(); + else + Py_DECREF(v); + } else Py_DECREF(v); } (and pyrl's not going to be ready for 2.1, by a country mile...) ------------------------------------------------------- Date: 2001-Jan-15 21:30 By: nascheme Comment: Hmm, I still like pyrl better. What to do about GNU readline now that its in Setup.conf? You can't enable them both and I don't feel comfortable enough with autoconf to fix things. ESR, if you could add the magic to test for termios that would be cool. configure should use readline if its there and fall back to edline if termios is available. Feel free to bounce it back to me if you don't have time. ------------------------------------------------------- Date: 2001-Jan-03 06:10 By: gvanrossum Comment: Neil, this has now status Accepted. Go ahead and check it in! ------------------------------------------------------- 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 Tue Jan 16 14:59:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 06:59:07 -0800 Subject: [Patches] [Patch #102891] Alternative readline module Message-ID: <E14IXZj-0007Cc-00@usw-sf-web1.sourceforge.net> Patch #102891 has been updated. Project: python Category: Modules Status: Accepted Submitted by: nascheme Assigned to : esr Summary: Alternative readline module Follow-Ups: Date: 2001-Jan-16 06:59 By: gvanrossum Comment: Ah, of course. I saw that, even played with it a bit. Looks cool, but I don't know about using it to replace readline. But you might want to change the name given that pyrl is already taken. ;-) ------------------------------------------------------- Date: 2001-Jan-16 06:34 By: mwh Comment: pyrl is my line reader written in Python that I've been intermittently blathering about on python-dev: http://www-jcsu.jesus.cam.ac.uk/~mwh21/hacks/pyrl-0.2.0.tar.gz it's still very experimental, though. ------------------------------------------------------- Date: 2001-Jan-16 05:41 By: gvanrossum Comment: What's pyrl in this context? A Google search turns up a bunch of references to a Perl preprocessor that takes Pythonic syntax and translates it into Perl. :-) [ESR replied Neil via email: "I'm on it. Gotta ship my PC9 paper first, though."] ------------------------------------------------------- Date: 2001-Jan-16 02:23 By: mwh Comment: You could defer the decision between readline and edline until runtime, as in: (will sf mangle this? we'll see) Index: Modules/main.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/main.c,v retrieving revision 1.47 diff -c -r1.47 main.c *** Modules/main.c 2000/12/15 22:00:54 1.47 --- Modules/main.c 2001/01/16 10:19:45 *************** *** 267,274 **** isatty(fileno(stdin))) { PyObject *v; v = PyImport_ImportModule("readline"); ! if (v == NULL) PyErr_Clear(); else Py_DECREF(v); } --- 267,280 ---- isatty(fileno(stdin))) { PyObject *v; v = PyImport_ImportModule("readline"); ! if (v == NULL) { PyErr_Clear(); + v = PyImport_ImportModule("edline"); + if (v == NULL) + PyErr_Clear(); + else + Py_DECREF(v); + } else Py_DECREF(v); } (and pyrl's not going to be ready for 2.1, by a country mile...) ------------------------------------------------------- Date: 2001-Jan-15 21:30 By: nascheme Comment: Hmm, I still like pyrl better. What to do about GNU readline now that its in Setup.conf? You can't enable them both and I don't feel comfortable enough with autoconf to fix things. ESR, if you could add the magic to test for termios that would be cool. configure should use readline if its there and fall back to edline if termios is available. Feel free to bounce it back to me if you don't have time. ------------------------------------------------------- Date: 2001-Jan-03 06:10 By: gvanrossum Comment: Neil, this has now status Accepted. Go ahead and check it in! ------------------------------------------------------- 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 esr@thyrsus.com Tue Jan 16 15:39:14 2001 From: esr@thyrsus.com (Eric S. Raymond) Date: Tue, 16 Jan 2001 10:39:14 -0500 Subject: [Patches] Re: [Patch #102891] Alternative readline module In-Reply-To: <E14IXBS-000713-00@usw-sf-web1.sourceforge.net>; from noreply@sourceforge.net on Tue, Jan 16, 2001 at 06:34:02AM -0800 References: <E14IXBS-000713-00@usw-sf-web1.sourceforge.net> Message-ID: <20010116103914.A2556@thyrsus.com> > [ESR replied Neil via email: "I'm on it. Gotta ship my PC9 paper first, > though."] It's done. At least the back half, the autoconf/autoheader machinery to test for termios, is now in place. I don't really grok how edline fits into the build, so I haven't tried to write the front half -- but the magic you wanted is there, you can check the value of ac_cv_header_termios_h to see if termios is present. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> What is a magician but a practicing theorist? -- Obi-Wan Kenobi, 'Return of the Jedi' From noreply@sourceforge.net Tue Jan 16 16:01:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 08:01:50 -0800 Subject: [Patches] [Patch #103158] Don't do unsafe arithmetic in xrange object Message-ID: <E14IYYQ-0007bx-00@usw-sf-web1.sourceforge.net> Patch #103158 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: greg_ball Assigned to : gvanrossum Summary: Don't do unsafe arithmetic in xrange object Follow-Ups: Date: 2001-Jan-16 08:01 By: greg_ball Comment: Something for Py3K maybe. Cheers. ------------------------------------------------------- Date: 2001-Jan-15 10:59 By: gvanrossum Comment: I've checked in this version of the patch -- having looked and thought it over for a bit, I agree that this is about as good as we can expect it to do without changing certain internal APIs. Your question about the wisdom of using ints is a good one! In particular it is stupid that PyIntObject holds a long but that the return value from the sq_length function is constrained to be an int. This is from way back when I thought that size_t would never be larger than int. Boy was I wrong. In an ideal world, the int size used for Python ints would be a configuration option, and the configure script would work hard to make it a 64-bit int whenever supported (even on 32-bit platforms). A simpler change would be to simply change the specification for sq_length to return a long, but that's not without problems: existing extensions would have to be recompiled for platforms where int and long aren't the same size (64-bit platforms except Win64). ------------------------------------------------------- Date: 2001-Jan-15 09:10 By: greg_ball Comment: If we only allow lengths that will fit into a C int, x = xrange(sys.maxint) would fail on 64-bit platforms. (and that code is always going to get written by people on 32-bit platforms.) Making some sort of special case for this particular idiom would not make the code simpler, I'm guessing. One obvious simple way to support it is by truncating the length to INT_MAX as is done in _PyEval_SliceIndex. Then len() and negative indexing can produce consistent non-garbage results, if not what the user might naively expect. In Python 2.0, you get garbage. Using my patch, you get an exception. But nobody actually uses those features, in all probability. Of course the natural extension of this approach is to allow any python integer arguments at all to xrange() (which Tim doesn't want to do) and truncate as necessary. But there is no need to go there; we can just leave bltin_xrange alone. As an aside, how important for performance is the use of C ints rather than C longs in the Python internals on 64 bit machines? 16 bit machines? ------------------------------------------------------- Date: 2001-Jan-12 12:11 By: greg_ball Comment: The new version of the patch makes the code a bit less complicated. (Only error messages have changed in terms of behaviour; regression test run under linux and OSF1.) If it looks ok you can ignore the rest of this comment... I originally made totlen an int because it is the return value from range_length, and the argument to PyList_New(). The current patch makes totlen a long, but the ocde doesn't get hugely less complicated. The code would get simpler if it rejected objects whose length doesn't fit into a int, but that seemed too easy and there is a small chance someone's code might break. On the other hand by rejecting objects whose stop can't be correctly calculated, I _might_ have broken code already. Break just means "now raises exception" though, nothing insidious. ------------------------------------------------------- Date: 2001-Jan-12 12:58 By: tim_one Comment: I'm aware of people who actually do x = xrange(sys.maxint) and that should continue to work. Python 2.0 already complains about more than that: >>> xrange(-1, sys.maxint) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange() has more than sys.maxint items >>> and I sure don't want to see that extended (unless it's part of a *sweeping* crusade to eradicate the visibile differences between ints and longs). ------------------------------------------------------- Date: 2001-Jan-12 12:44 By: gvanrossum Comment: In theory, there's a use for objects whose length doesn't fit in an int: for i in xrange(...) is routinely used for loops that expect to break well before the end but don't want to give an arbitrary upper bound. But I agree with Tim that this serves no real purpose. I think that if anything, the xrange() object should be scaled down. No repetition, no concationation, no slicing. the only real use ought to be "for i in xrange(...)". But of course, *that* is bound to break somebody's code somewhere. So let's not go there. But let's not complicate it any further. Prevent breakage, but don't stretch the functionality beyond what it currently does. ------------------------------------------------------- Date: 2001-Jan-12 12:35 By: tim_one Comment: Please do reject objects whose length doesn't fit into an int. I'll bet a dollar that no real code in the world will break as a result. I feel confident making that bet, because if someone's code *does* break as a result, it's worth a dollar to me to see Guido lecture them that their code was already broken <wink>. Really, it's very Pythonic to gripe about a problem just as soon as it crops up. It's not doing anyone a favor to delay griping until the object is used: at that point, it may be very difficult to figure out how the object *got* damaged. There's simply no payback in allowing creation of an unusable xrange object, and, as you say, life is simpler if you don't allow it. ------------------------------------------------------- Date: 2001-Jan-10 10:28 By: gvanrossum Comment: I wonder why you made totlen an int. This seems to complicate the code quite a bit. I'd suggest making it a long. Then you have to test whether it's > INT_MAX only in tolist() -- in that case you should raise MemoryError. Other than that, it looks decent! ------------------------------------------------------- Date: 2001-Jan-09 06:31 By: greg_ball Comment: This is a replacement for patch 103129, as suggested by tim_one. Possibly interesting aspects of the patch: - xrange objects with overflowing lengths are not gratutiously rejected. An error is raised only if the length becomes relevant, under len() or negative indexing. Bad lengths are stored as -1. Objects with bad lengths allow any non-negative integer index. - On 64 bit platforms, sequence multiplication seems to cause an unsafe cast from long to int. This patch does not address that issue. Without my patch, on i686 Linux: Python 2.0 (#25, Jan 2 2001, 12:18:07) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> y = xrange(maxint/2)*3 >>> len(y) -1073741827 >>> y[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> y.tolist() Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: listobject.c:33: bad argument to internal function >>> m = maxint >> 16 >>> xrange(0,maxint,m) xrange(0, -2147450883, 32767) >>> (xrange(1)*maxint)*maxint xrange(1) >>> With my patch Python 2.0 (#35, Jan 6 2001, 12:54:41) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> x = xrange(maxint) * 2 >>> len(x) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> y = xrange(maxint/2)*3 >>> len(y) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> y.tolist() Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> m = maxint >> 16 >>> xrange(0,maxint,m) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer addition >>> (xrange(1)*maxint) * maxint Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer multiplication >>> Without patch on Digital Unix Python 2.0 (#5, Jan 6 2001, 15:42:58) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) -2 >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: error return without exception set >>> xrange(0,maxint,m) xrange(0, -9223372034707292163, 2147483647) >>> xrange(1)*maxint xrange(0) >>> With patch Python 2.0 (#7, Jan 6 2001, 15:52:21) [C] on osf1V4 Type "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> m=maxint >> 32 >>> x = xrange(maxint)*2 >>> x (xrange(9223372036854775807) * 2) >>> len(x) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> x[-1] Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: xrange object too long >>> xrange(0,maxint,m) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer addition >>> xrange(1)*maxint xrange(0) >>> ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103158&group_id=5470 From mwh21@cam.ac.uk Tue Jan 16 16:55:43 2001 From: mwh21@cam.ac.uk (Michael Hudson) Date: 16 Jan 2001 16:55:43 +0000 Subject: [Patches] [Patch #102891] Alternative readline module In-Reply-To: noreply@sourceforge.net's message of "Tue, 16 Jan 2001 06:59:07 -0800" References: <E14IXZj-0007Cc-00@usw-sf-web1.sourceforge.net> Message-ID: <m366jf4esw.fsf@atrus.jesus.cam.ac.uk> noreply@sourceforge.net writes: > Ah, of course. I saw that, even played with it a bit. I saw that *someone* had downloaded it from a *.reston1.va.home.com address... > Looks cool, but I don't know about using it to replace readline. No, neither do I. But it might be nice to have sufficient hooks in the core to allow a sufficiently enterprising user to replace readline with it. > But you might want to change the name given that pyrl is already > taken. ;-) >From http://www.amk.ca/quotations/python-quotes.html: I would recommend not wasting any more time on the naming issue. (This is a recurring theme in my posts -- remember, I spent about 0.3 microseconds thinking about whether "Python" would be a good name for a programming language, and I've never regretted it.) Guido van Rossum, 25 Nov 1998 I'll give you 0.2 microseconds :-) But, yes. Anyone have any ideas? (or I'll just call it pyttyinput) Cheers, M. From noreply@sourceforge.net Tue Jan 16 18:51:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 10:51:02 -0800 Subject: [Patches] [Patch #103265] Let time functions default to 'now' (where it makes sense) Message-ID: <E14IbCA-0002ID-00@usw-sf-web2.sourceforge.net> Patch #103265 has been updated. Project: python Category: Modules Status: Open Submitted by: twouters Assigned to : nobody Summary: Let time functions default to 'now' (where it makes sense) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103265&group_id=5470 From guido@python.org Tue Jan 16 20:37:44 2001 From: guido@python.org (Guido van Rossum) Date: Tue, 16 Jan 2001 15:37:44 -0500 Subject: [Patches] [Patch #102891] Alternative readline module In-Reply-To: Your message of "16 Jan 2001 16:55:43 GMT." <m366jf4esw.fsf@atrus.jesus.cam.ac.uk> References: <E14IXZj-0007Cc-00@usw-sf-web1.sourceforge.net> <m366jf4esw.fsf@atrus.jesus.cam.ac.uk> Message-ID: <200101162037.PAA10721@cj20424-a.reston1.va.home.com> > > Ah, of course. I saw that, even played with it a bit. > > I saw that *someone* had downloaded it from a *.reston1.va.home.com > address... Could've been Fred or Tim... > > Looks cool, but I don't know about using it to replace readline. > > No, neither do I. But it might be nice to have sufficient hooks in > the core to allow a sufficiently enterprising user to replace readline > with it. A hook exists: you can assign a readline-ish function to PyOS_ReadlineFunctionPointer. > > But you might want to change the name given that pyrl is already > > taken. ;-) > > >From http://www.amk.ca/quotations/python-quotes.html: > > I would recommend not wasting any more time on the naming > issue. (This is a recurring theme in my posts -- remember, I spent > about 0.3 microseconds thinking about whether "Python" would be a > good name for a programming language, and I've never regretted it.) > Guido van Rossum, 25 Nov 1998 > > I'll give you 0.2 microseconds :-) > > But, yes. Anyone have any ideas? (or I'll just call it pyttyinput) Not me, I wasted my 0.2 usec on Python :-). Note that the patches list doesn't have much of a readership. --Guido van Rossum (home page: http://www.python.org/~guido/) From nas@arctrix.com Tue Jan 16 14:09:45 2001 From: nas@arctrix.com (Neil Schemenauer) Date: Tue, 16 Jan 2001 06:09:45 -0800 Subject: [Patches] [Patch #102891] Alternative readline module In-Reply-To: <200101162037.PAA10721@cj20424-a.reston1.va.home.com>; from guido@python.org on Tue, Jan 16, 2001 at 03:37:44PM -0500 References: <E14IXZj-0007Cc-00@usw-sf-web1.sourceforge.net> <m366jf4esw.fsf@atrus.jesus.cam.ac.uk> <200101162037.PAA10721@cj20424-a.reston1.va.home.com> Message-ID: <20010116060945.A8505@glacier.fnational.com> On Tue, Jan 16, 2001 at 03:37:44PM -0500, Guido van Rossum wrote: > A hook exists: you can assign a readline-ish function to > PyOS_ReadlineFunctionPointer. You can't do that from within Python code though, can you? Although pyrl is not nearly ready for the prime time, I think the general approach is a good one long term. Command line editing is not a performance critical task. Python code is fast enough. Moving this task to Python should allow the editor to be made cross platform more easily. Also, it should be easier to add more advanced features. I would like the editor to work like the Z shell editor in that you can edit whole blocks. For example, if I enter: for i in range(10): print i and press up arrow I would be able to edit the whole for loop as a block. > Note that the patches list doesn't have much of a readership. I'm still here. :-) Neil From noreply@sourceforge.net Tue Jan 16 21:28:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 13:28:24 -0800 Subject: [Patches] [Patch #103276] zipfile.py - file header size calculation fixed Message-ID: <E14IdeS-0001Ao-00@usw-sf-web1.sourceforge.net> Patch #103276 has been updated. Project: python Category: None Status: Open Submitted by: snejsource Assigned to : nobody Summary: zipfile.py - file header size calculation fixed ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103276&group_id=5470 From noreply@sourceforge.net Tue Jan 16 21:36:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 13:36:24 -0800 Subject: [Patches] [Patch #103252] Startup optimize: read *.pyc as string, not with getc() Message-ID: <E14IdmC-0003JI-00@usw-sf-web2.sourceforge.net> Patch #103252 has been updated. Project: python Category: core (C code) Status: Open Submitted by: pj99 Assigned to : tim_one Summary: Startup optimize: read *.pyc as string, not with getc() Follow-Ups: Date: 2001-Jan-16 13:36 By: pj99 Comment: No problem, Tim (on the alledged abruptness). In any case, it was useful - in that it helped motivate /f into proposing a fix, me into coding it, and you to consider applying it. All in all a useful result. Most thanks, Tim. ------------------------------------------------------- Date: 2001-Jan-15 20:26 By: tim_one Comment: Indeed, IDLE takes more than a full second to come up on my box, *much* longer than Notepad. Now that we have a clear goal, I assigned this patch to me <wink>. (OK, it's really that I was abrupt with Paul when this came up on c.l.py, and left him hanging there -- I owe him on this one). ------------------------------------------------------- Date: 2001-Jan-15 20:18 By: gvanrossum Comment: Oh, but I do care about the load time of Tkinter. :-) Anything to keep IDLE ahead of Komodo in the race. :-) ------------------------------------------------------- Date: 2001-Jan-15 20:05 By: tim_one Comment: I like the idea, but gimmicks like this make porting to tiny platforms harder when pushed "too far". People concerned about startup time seem mostly to deal with apps that e.g. fire up Python 1000s of times from shell scripts or cgi. They're not going to care about monster modules (like Tkinter and grail). So I think Paul's original 64K is a good compromise. ------------------------------------------------------- Date: 2001-Jan-15 19:39 By: gvanrossum Comment: Not a bad idea. I'd up the limit to 256K so Tkinter.pyc (comfortably) fits. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103252&group_id=5470 From noreply@sourceforge.net Tue Jan 16 22:28:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 14:28:28 -0800 Subject: [Patches] [Patch #103250] Optimize a strspn() out of startup Message-ID: <E14Ieaa-0001WU-00@usw-sf-web1.sourceforge.net> Patch #103250 has been updated. Project: python Category: None Status: Open Submitted by: pj99 Assigned to : gvanrossum Summary: Optimize a strspn() out of startup Follow-Ups: Date: 2001-Jan-16 14:28 By: pj99 Comment: The (isalpha(c) || isdigit(c) || c=='_') suggestion seems to me to be the better idea. However, how does this interact with localization and unicode and such? Do we want exactly the list of specified NAME_CHARS allowed here, or do we want a localized set of alpha/digit/'_' chars allowed here? As for the other 98.5%, I have a nice table from my profiler, showing where the time is, but I don't know how to put that table here, without mangling the format. It shows about 19% of the time in malloc/free, about 15% of the time in pthread code, about 14% in dictobject.c code, and about 6% in acceler.c code (esp. fixstate()). And of course the getc() savings that come from loading an entire *.pyc file in a single fread(), as being persued in patch 103252, saves perhaps 24% of what's left. (Note, the 19,15,14 and 6 percents above are based on what's left, _after_ the 24% getc() optimization is applied). *If* much of the malloc/free use is for lots of small chunks, coming and going, as tends to happen with object based code, then I could imagine a custom allocator (based on top of malloc/free, so quite portable). This might save much of the pthread cost as well, if the custom allocator kept separate pools of small chunks of malloc'd memory, per thread, avoiding locks (if that can be done ?). I have done work in the past in a C++/mmap environment that reduced the costs of many small dynamic allocations to near zero, both space and time. But that relied on the second argument to C++ delete(), which is the size of the object being deleted, as well as on an AUTOGROW mmap region. This is not applicable to C, nor is it particularly portable. Still, something like this, perhaps requiring recoding of some critical free() calls to use an optional method that passed in a second sizeof argument, might be the next most useful optimization. Someone else in the news thread that was parent to this patch suggested emacs-like dump facility, to capture the state of the Python interpreter after it has loaded the usual suspects. But I can't imagine that this would be sufficiently portable or maintainable to be relevant. As someone who has had to maintain O.S./library support for and compatibility with this emacs dump facility, I have grown to dislike it strongly. ------------------------------------------------------- Date: 2001-Jan-15 23:25 By: nobody Comment: Why not (isalpha(c) || isdigit(c) || c=='_') ? ------------------------------------------------------- Date: 2001-Jan-15 19:35 By: gvanrossum Comment: Looks cool to me. Do you have an idea what to do about the other 98.5%? :) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103250&group_id=5470 From noreply@sourceforge.net Tue Jan 16 22:53:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 14:53:31 -0800 Subject: [Patches] [Patch #102588] PEP 229: Use Distutils to build Message-ID: <E14Ieyp-00038V-00@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: 2001-Jan-16 14:53 By: akuchling Comment: I've made an updated version of the patch; because it's 55K, SF won't accept it, so I've put it at http://www.mems-exchange.org/software/files/python/pep229.patch. There are only a very few things left to fix at this point: * setup.cfg hard-wires the installation directory because it has no access to a variable holding the installation prefix * installs in subdirectories don't work because setup.cfg is only found in the current directory. I think those are the only two remaining issues before this can be checked in (doubtless causing the sun to explode). ------------------------------------------------------- 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 Tue Jan 16 23:06:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 15:06:26 -0800 Subject: [Patches] [Patch #103277] Enables a package to have more than one source dir Message-ID: <E14IfBK-0003DI-00@usw-sf-web3.sourceforge.net> Patch #103277 has been updated. Project: python Category: distutils Status: Open Submitted by: nobody Assigned to : nobody Summary: Enables a package to have more than one source dir ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103277&group_id=5470 From guido@python.org Tue Jan 16 23:35:20 2001 From: guido@python.org (Guido van Rossum) Date: Tue, 16 Jan 2001 18:35:20 -0500 Subject: [Patches] [Patch #102891] Alternative readline module In-Reply-To: Your message of "Tue, 16 Jan 2001 06:09:45 PST." <20010116060945.A8505@glacier.fnational.com> References: <E14IXZj-0007Cc-00@usw-sf-web1.sourceforge.net> <m366jf4esw.fsf@atrus.jesus.cam.ac.uk> <200101162037.PAA10721@cj20424-a.reston1.va.home.com> <20010116060945.A8505@glacier.fnational.com> Message-ID: <200101162335.SAA16622@cj20424-a.reston1.va.home.com> > On Tue, Jan 16, 2001 at 03:37:44PM -0500, Guido van Rossum wrote: > > A hook exists: you can assign a readline-ish function to > > PyOS_ReadlineFunctionPointer. > > You can't do that from within Python code though, can you? No, but you could easily write a little extension that sets it to a C function that can call an arbitrary Python code. (Just realize that it's called without the Python global interpreter lock held.) > Although pyrl is not nearly ready for the prime time, I think the > general approach is a good one long term. Command line editing > is not a performance critical task. Python code is fast enough. > Moving this task to Python should allow the editor to be made > cross platform more easily. Sadly, this isn't the case -- pyrl uses curses and/or termios calls that are highly Unix specific. :-) > Also, it should be easier to add > more advanced features. I would like the editor to work like the > Z shell editor in that you can edit whole blocks. For example, > if I enter: > > for i in range(10): > print i > > and press up arrow I would be able to edit the whole for loop as > a block. Just use IDLE -- it has all that. Character cell interfaces aren't worth the effort of keeping up. --Guido van Rossum (home page: http://www.python.org/~guido/) From skip@mojam.com (Skip Montanaro) Wed Jan 17 00:06:52 2001 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 16 Jan 2001 18:06:52 -0600 (CST) Subject: [Patches] [Patch #102891] Alternative readline module In-Reply-To: <200101162335.SAA16622@cj20424-a.reston1.va.home.com> References: <E14IXZj-0007Cc-00@usw-sf-web1.sourceforge.net> <m366jf4esw.fsf@atrus.jesus.cam.ac.uk> <200101162037.PAA10721@cj20424-a.reston1.va.home.com> <20010116060945.A8505@glacier.fnational.com> <200101162335.SAA16622@cj20424-a.reston1.va.home.com> Message-ID: <14948.57884.434679.220050@beluga.mojam.com> >> and press up arrow I would be able to edit the whole for loop as a >> block. Guido> Just use IDLE -- it has all that. Character cell interfaces Guido> aren't worth the effort of keeping up. Hey! I resemble that remark! I still just use the bare interpreter for all my interactive twiddlings and wouldn't turn my nose up at more sophisticated history recall/editing. Starts up a heckuva lot faster than IDLE. Skip From mwh21@cam.ac.uk Wed Jan 17 00:09:58 2001 From: mwh21@cam.ac.uk (Michael Hudson) Date: 17 Jan 2001 00:09:58 +0000 Subject: [Patches] [Patch #102891] Alternative readline module In-Reply-To: Guido van Rossum's message of "Tue, 16 Jan 2001 18:35:20 -0500" References: <E14IXZj-0007Cc-00@usw-sf-web1.sourceforge.net> <m366jf4esw.fsf@atrus.jesus.cam.ac.uk> <200101162037.PAA10721@cj20424-a.reston1.va.home.com> <20010116060945.A8505@glacier.fnational.com> <200101162335.SAA16622@cj20424-a.reston1.va.home.com> Message-ID: <m3snmj2g4p.fsf@atrus.jesus.cam.ac.uk> This is a really silly place to be having this discussion, isn't it? Oh well. I might create an sf project when sf isn't broken any more... Guido van Rossum <guido@python.org> writes: > > Although pyrl is not nearly ready for the prime time, I think the > > general approach is a good one long term. Command line editing > > is not a performance critical task. Python code is fast enough. > > Moving this task to Python should allow the editor to be made > > cross platform more easily. > > Sadly, this isn't the case -- pyrl uses curses and/or termios calls > that are highly Unix specific. :-) Actually one could probably rewrite the bottom layer to use /F's Console library without too much sweat. Currently my code is also highly tty dependent - it dies horribly if you try to use it inside emacs, for example. > > Also, it should be easier to add > > more advanced features. I would like the editor to work like the > > Z shell editor in that you can edit whole blocks. For example, > > if I enter: > > > > for i in range(10): > > print i > > > > and press up arrow I would be able to edit the whole for loop as > > a block. This works in pyrl today! It was, in fact, one of my main motivations for writing pyrl. > Just use IDLE -- it has all that. Character cell interfaces aren't > worth the effort of keeping up. Well, I like them, and if I'm prepared to put the effort into writing one, that's all it takes, isn't it? I don't necessarily expect people to understand me... Cheers, M. From guido@python.org Wed Jan 17 00:17:02 2001 From: guido@python.org (Guido van Rossum) Date: Tue, 16 Jan 2001 19:17:02 -0500 Subject: [Patches] [Patch #102891] Alternative readline module In-Reply-To: Your message of "Tue, 16 Jan 2001 18:06:52 CST." <14948.57884.434679.220050@beluga.mojam.com> References: <E14IXZj-0007Cc-00@usw-sf-web1.sourceforge.net> <m366jf4esw.fsf@atrus.jesus.cam.ac.uk> <200101162037.PAA10721@cj20424-a.reston1.va.home.com> <20010116060945.A8505@glacier.fnational.com> <200101162335.SAA16622@cj20424-a.reston1.va.home.com> <14948.57884.434679.220050@beluga.mojam.com> Message-ID: <200101170017.TAA17059@cj20424-a.reston1.va.home.com> > Hey! I resemble that remark! I still just use the bare interpreter for all > my interactive twiddlings and wouldn't turn my nose up at more sophisticated > history recall/editing. Starts up a heckuva lot faster than IDLE. Me too (on Unix). But GNU readline does everything I need, and the price is right. (The GPL license worries will soon be resolved -- CNRI and the FSF have reached an agreement on changes to the 1.6 license.) --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Wed Jan 17 00:27:41 2001 From: guido@python.org (Guido van Rossum) Date: Tue, 16 Jan 2001 19:27:41 -0500 Subject: [Patches] [Patch #102891] Alternative readline module In-Reply-To: Your message of "17 Jan 2001 00:09:58 GMT." <m3snmj2g4p.fsf@atrus.jesus.cam.ac.uk> References: <E14IXZj-0007Cc-00@usw-sf-web1.sourceforge.net> <m366jf4esw.fsf@atrus.jesus.cam.ac.uk> <200101162037.PAA10721@cj20424-a.reston1.va.home.com> <20010116060945.A8505@glacier.fnational.com> <200101162335.SAA16622@cj20424-a.reston1.va.home.com> <m3snmj2g4p.fsf@atrus.jesus.cam.ac.uk> Message-ID: <200101170027.TAA17107@cj20424-a.reston1.va.home.com> > > Sadly, this isn't the case -- pyrl uses curses and/or termios calls > > that are highly Unix specific. :-) > > Actually one could probably rewrite the bottom layer to use /F's > Console library without too much sweat. Currently my code is also > highly tty dependent - it dies horribly if you try to use it inside > emacs, for example. I believe that everything /F's console library does is also done by the classes in the standard code module! Check it out... (Even IDLE uses that, and it's future-proof.) > > Just use IDLE -- it has all that. Character cell interfaces aren't > > worth the effort of keeping up. > > Well, I like them, and if I'm prepared to put the effort into writing > one, that's all it takes, isn't it? I don't necessarily expect people > to understand me... Of course. I don't want to discourage you. But I also don't want to be pressured into adopting your code into the core. --Guido van Rossum (home page: http://www.python.org/~guido/) From tim.one@home.com Wed Jan 17 00:42:51 2001 From: tim.one@home.com (Tim Peters) Date: Tue, 16 Jan 2001 19:42:51 -0500 Subject: [Patches] [Patch #102891] Alternative readline module In-Reply-To: <m3snmj2g4p.fsf@atrus.jesus.cam.ac.uk> Message-ID: <LNBBLJKPBEHFEDALKOLCIEBMIJAA.tim.one@home.com> [Michael Hudson] > This is a really silly place to be having this discussion, isn't it? That's because we just turned off the patches reply-to to python-dev. It was predicted that people would be careful to type in python-dev themselves when it was warranted <snort>. but-better-in-one-wrong-forum-than-in-random-xposting-among-three-ly y'rs - tim From guido@python.org Wed Jan 17 00:50:40 2001 From: guido@python.org (Guido van Rossum) Date: Tue, 16 Jan 2001 19:50:40 -0500 Subject: [Patches] [Patch #102891] Alternative readline module In-Reply-To: Your message of "Tue, 16 Jan 2001 19:42:51 EST." <LNBBLJKPBEHFEDALKOLCIEBMIJAA.tim.one@home.com> References: <LNBBLJKPBEHFEDALKOLCIEBMIJAA.tim.one@home.com> Message-ID: <200101170050.TAA17404@cj20424-a.reston1.va.home.com> > [Michael Hudson] > > This is a really silly place to be having this discussion, isn't it? [Tim] > That's because we just turned off the patches reply-to to python-dev. It > was predicted that people would be careful to type in python-dev themselves > when it was warranted <snort>. Not so quick! That's not the origin of *this* thread. AFAICT it started when Eric Raymond followed up to a message from SourceForge in the patches list. The patches list wasn't affected by the reply-to change, AFAIK -- only the python-checkin list was. --Guido van Rossum (home page: http://www.python.org/~guido/) From tim.one@home.com Wed Jan 17 01:05:25 2001 From: tim.one@home.com (Tim Peters) Date: Tue, 16 Jan 2001 20:05:25 -0500 Subject: [Patches] [Patch #102891] Alternative readline module In-Reply-To: <200101170050.TAA17404@cj20424-a.reston1.va.home.com> Message-ID: <LNBBLJKPBEHFEDALKOLCAEBOIJAA.tim.one@home.com> [Tim] > That's because we just turned off the patches reply-to to python-dev ... [Guido] > Not so quick! ...[and explains]... OK, I'll save it and repost it when the first reply gets made to the checkin list <wink>. From noreply@sourceforge.net Wed Jan 17 01:51:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 17:51:34 -0800 Subject: [Patches] [Patch #103279] Flag for making sysconfig assume build directories Message-ID: <E14Ihl8-00040x-00@usw-sf-web3.sourceforge.net> Patch #103279 has been updated. Project: python Category: distutils Status: Open Submitted by: akuchling Assigned to : nobody Summary: Flag for making sysconfig assume build directories ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103279&group_id=5470 From noreply@sourceforge.net Wed Jan 17 01:54:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 17:54:02 -0800 Subject: [Patches] [Patch #103279] Flag for making sysconfig assume build directories Message-ID: <E14IhnW-000420-00@usw-sf-web3.sourceforge.net> Patch #103279 has been updated. Project: python Category: distutils Status: Open Submitted by: akuchling Assigned to : gward Summary: Flag for making sysconfig assume build directories ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103279&group_id=5470 From noreply@sourceforge.net Wed Jan 17 03:14:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 19:14:32 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14Ij3Q-000561-00@usw-sf-web2.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : loewis Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-16 19:14 By: fdrake Comment: I'm not entirely sure why one would want weak keys rather than weak values, but I suspect it has to do with expectations of how the dict will be used in applications. I don't think it would be hard to support both flavors of dictionaries using the primitive reference objects. The constructor does not check that all incoming values are weak because that isn't required. It uses self.update() rather than self.data.update() to perform the inclusion, so any mapping that supports .keys() and .__getitem__() is sufficient. Some additional checking could be done to make sure that all added entries can be created before inserting any of them, offering more atomicity. .get() will be fixed in the next version of the patch; thanks! I've added GC support, but don't have it working quite right. I'm trying to isolate the failure now. ------------------------------------------------------- Date: 2001-Jan-12 14:36 By: loewis Comment: The weak dictionary data type needs more clarification in documentation and implementation. In java.util.WeakHashMap, they keys are weak, not the values (i.e. once the key is forgotten, the entry is cleared). In http://www.handshake.de/~dieter/weakdict.html, the values are weak, but it raises KeyErrors for entries that are collected. The initializer of a weak dict does not check the invariant (all values are weak). get() of a weakdict does not support an optional second parameter. weakref and friends need to participate in garbage collection, as the reference to the callback can create a cycle. ------------------------------------------------------- Date: 2001-Jan-12 11:27 By: fdrake Comment: Updated patch to also support proxy semantics using the same invalidation machinery as the basic weak reference type. The additional code is *heavily* borrowed from Neil Schemenauer. ------------------------------------------------------- Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Wed Jan 17 03:39:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 19:39:59 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14IjS3-00035k-00@usw-sf-web1.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : loewis Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-16 19:39 By: tim_one Comment: Just mentioning a general scenario in which weak keys are the bee's knees: sometimes you want to add attributes to objects dynamically, in ways the original class author(s -- may cut across many classes! even non-instance objects; or objects from extension modules that don't support setattr) never anticipated. Like maybe a German translation of the object's docstrings; or a list of JPEG contents referenced by a URLish object; or a table of usage statistics on methods and functions; etc. Then it's natural to use the conceptual attr name as the name of a dict instead, and write attr[object] = whatever instead of object.attr = whatever There's no point keeping the "whatever" around when the object goes away, but a regular dict makes the object and its "whatever" immortal. A dict with weak keys is exactly on-target. ------------------------------------------------------- Date: 2001-Jan-16 19:14 By: fdrake Comment: I'm not entirely sure why one would want weak keys rather than weak values, but I suspect it has to do with expectations of how the dict will be used in applications. I don't think it would be hard to support both flavors of dictionaries using the primitive reference objects. The constructor does not check that all incoming values are weak because that isn't required. It uses self.update() rather than self.data.update() to perform the inclusion, so any mapping that supports .keys() and .__getitem__() is sufficient. Some additional checking could be done to make sure that all added entries can be created before inserting any of them, offering more atomicity. .get() will be fixed in the next version of the patch; thanks! I've added GC support, but don't have it working quite right. I'm trying to isolate the failure now. ------------------------------------------------------- Date: 2001-Jan-12 14:36 By: loewis Comment: The weak dictionary data type needs more clarification in documentation and implementation. In java.util.WeakHashMap, they keys are weak, not the values (i.e. once the key is forgotten, the entry is cleared). In http://www.handshake.de/~dieter/weakdict.html, the values are weak, but it raises KeyErrors for entries that are collected. The initializer of a weak dict does not check the invariant (all values are weak). get() of a weakdict does not support an optional second parameter. weakref and friends need to participate in garbage collection, as the reference to the callback can create a cycle. ------------------------------------------------------- Date: 2001-Jan-12 11:27 By: fdrake Comment: Updated patch to also support proxy semantics using the same invalidation machinery as the basic weak reference type. The additional code is *heavily* borrowed from Neil Schemenauer. ------------------------------------------------------- Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Wed Jan 17 04:20:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 20:20:46 -0800 Subject: [Patches] [Patch #103283] Rich comparisons technical preview Message-ID: <E14Ik5W-0004ht-00@usw-sf-web3.sourceforge.net> Patch #103283 has been updated. Project: python Category: core (C code) Status: Open Submitted by: gvanrossum Assigned to : nobody Summary: Rich comparisons technical preview ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103283&group_id=5470 From noreply@sourceforge.net Wed Jan 17 04:24:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 20:24:25 -0800 Subject: [Patches] [Patch #103283] Rich comparisons technical preview Message-ID: <E14Ik93-0003IH-00@usw-sf-web1.sourceforge.net> Patch #103283 has been updated. Project: python Category: core (C code) Status: Open Submitted by: gvanrossum Assigned to : gvanrossum Summary: Rich comparisons technical preview ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103283&group_id=5470 From noreply@sourceforge.net Wed Jan 17 04:24:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 20:24:59 -0800 Subject: [Patches] [Patch #103277] Enables a package to have more than one source dir Message-ID: <E14Ik9b-0003IV-00@usw-sf-web1.sourceforge.net> Patch #103277 has been updated. Project: python Category: distutils Status: Open Submitted by: nobody Assigned to : akuchling Summary: Enables a package to have more than one source dir ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103277&group_id=5470 From noreply@sourceforge.net Wed Jan 17 04:29:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 20:29:42 -0800 Subject: [Patches] [Patch #103265] Let time functions default to 'now' (where it makes sense) Message-ID: <E14IkEA-0005SW-00@usw-sf-web2.sourceforge.net> Patch #103265 has been updated. Project: python Category: Modules Status: Open Submitted by: twouters Assigned to : twouters Summary: Let time functions default to 'now' (where it makes sense) Follow-Ups: Date: 2001-Jan-16 20:29 By: gvanrossum Comment: How hard would it be to avoid calling floattime() when an argument is present (in gmtime() and localtime())? Missing: docs, NEWS item. Otherwise, great -- ready to check in if you fix the above things! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103265&group_id=5470 From noreply@sourceforge.net Wed Jan 17 04:31:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 20:31:06 -0800 Subject: [Patches] [Patch #103276] zipfile.py - file header size calculation fixed Message-ID: <E14IkFW-0005TE-00@usw-sf-web2.sourceforge.net> Patch #103276 has been updated. Project: python Category: library Status: Open Submitted by: snejsource Assigned to : fdrake Summary: zipfile.py - file header size calculation fixed Follow-Ups: Date: 2001-Jan-16 20:31 By: gvanrossum Comment: Assigned to Fred. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103276&group_id=5470 From noreply@sourceforge.net Wed Jan 17 05:33:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 21:33:06 -0800 Subject: [Patches] [Patch #103250] Optimize a strspn() out of startup Message-ID: <E14IlDW-0005ln-00@usw-sf-web2.sourceforge.net> Patch #103250 has been updated. Project: python Category: None Status: Open Submitted by: pj99 Assigned to : gvanrossum Summary: Optimize a strspn() out of startup Follow-Ups: Date: 2001-Jan-16 21:33 By: nobody Comment: At least the Python tokenizer uses (isalnum(c) || c == '_') ... ------------------------------------------------------- Date: 2001-Jan-16 14:28 By: pj99 Comment: The (isalpha(c) || isdigit(c) || c=='_') suggestion seems to me to be the better idea. However, how does this interact with localization and unicode and such? Do we want exactly the list of specified NAME_CHARS allowed here, or do we want a localized set of alpha/digit/'_' chars allowed here? As for the other 98.5%, I have a nice table from my profiler, showing where the time is, but I don't know how to put that table here, without mangling the format. It shows about 19% of the time in malloc/free, about 15% of the time in pthread code, about 14% in dictobject.c code, and about 6% in acceler.c code (esp. fixstate()). And of course the getc() savings that come from loading an entire *.pyc file in a single fread(), as being persued in patch 103252, saves perhaps 24% of what's left. (Note, the 19,15,14 and 6 percents above are based on what's left, _after_ the 24% getc() optimization is applied). *If* much of the malloc/free use is for lots of small chunks, coming and going, as tends to happen with object based code, then I could imagine a custom allocator (based on top of malloc/free, so quite portable). This might save much of the pthread cost as well, if the custom allocator kept separate pools of small chunks of malloc'd memory, per thread, avoiding locks (if that can be done ?). I have done work in the past in a C++/mmap environment that reduced the costs of many small dynamic allocations to near zero, both space and time. But that relied on the second argument to C++ delete(), which is the size of the object being deleted, as well as on an AUTOGROW mmap region. This is not applicable to C, nor is it particularly portable. Still, something like this, perhaps requiring recoding of some critical free() calls to use an optional method that passed in a second sizeof argument, might be the next most useful optimization. Someone else in the news thread that was parent to this patch suggested emacs-like dump facility, to capture the state of the Python interpreter after it has loaded the usual suspects. But I can't imagine that this would be sufficiently portable or maintainable to be relevant. As someone who has had to maintain O.S./library support for and compatibility with this emacs dump facility, I have grown to dislike it strongly. ------------------------------------------------------- Date: 2001-Jan-15 23:25 By: nobody Comment: Why not (isalpha(c) || isdigit(c) || c=='_') ? ------------------------------------------------------- Date: 2001-Jan-15 19:35 By: gvanrossum Comment: Looks cool to me. Do you have an idea what to do about the other 98.5%? :) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103250&group_id=5470 From noreply@sourceforge.net Wed Jan 17 05:35:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 21:35:07 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14IlFT-0005mP-00@usw-sf-web2.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : nascheme Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-16 21:35 By: fdrake Comment: Added a new (but broken!) version of the patch that fixes WeakDictionary.get() but doesn't interact properly with GC (appearantly) -- not usable as is: http://starship.python.net/crew/fdrake/patches/weakref.patch-3 Neil made the mistake of volunteering to look at the current problem, so assigning to him. (Thanks!) ------------------------------------------------------- Date: 2001-Jan-16 19:39 By: tim_one Comment: Just mentioning a general scenario in which weak keys are the bee's knees: sometimes you want to add attributes to objects dynamically, in ways the original class author(s -- may cut across many classes! even non-instance objects; or objects from extension modules that don't support setattr) never anticipated. Like maybe a German translation of the object's docstrings; or a list of JPEG contents referenced by a URLish object; or a table of usage statistics on methods and functions; etc. Then it's natural to use the conceptual attr name as the name of a dict instead, and write attr[object] = whatever instead of object.attr = whatever There's no point keeping the "whatever" around when the object goes away, but a regular dict makes the object and its "whatever" immortal. A dict with weak keys is exactly on-target. ------------------------------------------------------- Date: 2001-Jan-16 19:14 By: fdrake Comment: I'm not entirely sure why one would want weak keys rather than weak values, but I suspect it has to do with expectations of how the dict will be used in applications. I don't think it would be hard to support both flavors of dictionaries using the primitive reference objects. The constructor does not check that all incoming values are weak because that isn't required. It uses self.update() rather than self.data.update() to perform the inclusion, so any mapping that supports .keys() and .__getitem__() is sufficient. Some additional checking could be done to make sure that all added entries can be created before inserting any of them, offering more atomicity. .get() will be fixed in the next version of the patch; thanks! I've added GC support, but don't have it working quite right. I'm trying to isolate the failure now. ------------------------------------------------------- Date: 2001-Jan-12 14:36 By: loewis Comment: The weak dictionary data type needs more clarification in documentation and implementation. In java.util.WeakHashMap, they keys are weak, not the values (i.e. once the key is forgotten, the entry is cleared). In http://www.handshake.de/~dieter/weakdict.html, the values are weak, but it raises KeyErrors for entries that are collected. The initializer of a weak dict does not check the invariant (all values are weak). get() of a weakdict does not support an optional second parameter. weakref and friends need to participate in garbage collection, as the reference to the callback can create a cycle. ------------------------------------------------------- Date: 2001-Jan-12 11:27 By: fdrake Comment: Updated patch to also support proxy semantics using the same invalidation machinery as the basic weak reference type. The additional code is *heavily* borrowed from Neil Schemenauer. ------------------------------------------------------- Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Wed Jan 17 06:15:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 22:15:11 -0800 Subject: [Patches] [Patch #103252] Startup optimize: read *.pyc as string, not with getc() Message-ID: <E14IlsF-0005DW-00@usw-sf-web3.sourceforge.net> Patch #103252 has been updated. Project: python Category: core (C code) Status: Open Submitted by: pj99 Assigned to : tim_one Summary: Startup optimize: read *.pyc as string, not with getc() Follow-Ups: Date: 2001-Jan-16 22:15 By: tim_one Comment: I'm afraid this patch needs major work before we could use it. The big thing is that stat isn't std C, and as far as I can tell we don't even define a config symbol saying whether it's available. Even when it is available, on at least one oddball platform it apparently needs oddball declarations (see the STAT/FSTAT/etc macros in posixfile.c). And the Macintosh code isn't in the CVS tree (Jack Jansen owns it), so no telling how it's done there. *Standard* C doesn't have a good way to determine the size of a file, either. While Python's os.path.getsize() is supported on all platforms, that's done in platform-dependent ways in platform-dependent files, and there's no Python C API for it. So the first step would be to define and implement a PyOS_GetFileSize() C API, akin to the existing PyOS_GetLastModificationTime() (in getmtime.c). Beyond that, there are small things that need fixing. Like: + malloc's return should be cast to char* + but malloc shouldn't be called directly to begin with (see pymem.h) + ditto free() + the pointer test (buf > 0) doesn't make sense (buf != NULL was intended) Once we get beyond all that <wink>, I think a three-tiered strategy would be worth implementing: also declare a 16K stack buffer. If a file is small enough, read into that; else if less than 256K (as Guido asked) malloc a buffer as is done now; else give up. 75% of the .pyc files on my box are under 16K (90% of IDLE's), so that would save the bulk of the malloc/free calls due to this. ------------------------------------------------------- Date: 2001-Jan-16 13:36 By: pj99 Comment: No problem, Tim (on the alledged abruptness). In any case, it was useful - in that it helped motivate /f into proposing a fix, me into coding it, and you to consider applying it. All in all a useful result. Most thanks, Tim. ------------------------------------------------------- Date: 2001-Jan-15 20:26 By: tim_one Comment: Indeed, IDLE takes more than a full second to come up on my box, *much* longer than Notepad. Now that we have a clear goal, I assigned this patch to me <wink>. (OK, it's really that I was abrupt with Paul when this came up on c.l.py, and left him hanging there -- I owe him on this one). ------------------------------------------------------- Date: 2001-Jan-15 20:18 By: gvanrossum Comment: Oh, but I do care about the load time of Tkinter. :-) Anything to keep IDLE ahead of Komodo in the race. :-) ------------------------------------------------------- Date: 2001-Jan-15 20:05 By: tim_one Comment: I like the idea, but gimmicks like this make porting to tiny platforms harder when pushed "too far". People concerned about startup time seem mostly to deal with apps that e.g. fire up Python 1000s of times from shell scripts or cgi. They're not going to care about monster modules (like Tkinter and grail). So I think Paul's original 64K is a good compromise. ------------------------------------------------------- Date: 2001-Jan-15 19:39 By: gvanrossum Comment: Not a bad idea. I'd up the limit to 256K so Tkinter.pyc (comfortably) fits. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103252&group_id=5470 From thomas@xs4all.net Wed Jan 17 09:02:19 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 17 Jan 2001 10:02:19 +0100 Subject: [Patches] [Patch #102891] Alternative readline module In-Reply-To: <LNBBLJKPBEHFEDALKOLCIEBMIJAA.tim.one@home.com>; from tim.one@home.com on Tue, Jan 16, 2001 at 07:42:51PM -0500 References: <m3snmj2g4p.fsf@atrus.jesus.cam.ac.uk> <LNBBLJKPBEHFEDALKOLCIEBMIJAA.tim.one@home.com> Message-ID: <20010117100206.D2776@xs4all.nl> On Tue, Jan 16, 2001 at 07:42:51PM -0500, Tim Peters wrote: > [Michael Hudson] > > This is a really silly place to be having this discussion, isn't it? > That's because we just turned off the patches reply-to to python-dev. It > was predicted that people would be careful to type in python-dev themselves > when it was warranted <snort>. Actually, it's party Guido's (or maybe Michael's) fault too... Neil sneakily put in a 'Mail-Followup-To' header to python-dev, but either noone replied to him, or their mailers ignored the header :-) -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From noreply@sourceforge.net Wed Jan 17 09:24:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 01:24:20 -0800 Subject: [Patches] [Patch #103265] Let time functions default to 'now' (where it makes sense) Message-ID: <E14IopI-00065t-00@usw-sf-web3.sourceforge.net> Patch #103265 has been updated. Project: python Category: Modules Status: Open Submitted by: twouters Assigned to : twouters Summary: Let time functions default to 'now' (where it makes sense) Follow-Ups: Date: 2001-Jan-17 01:24 By: twouters Comment: Calling floattime() only when necessary would be nice, but isn't possible without a value that reads as 'empty'. There is no way to see whether optional values of a ParseTuple call were filled or not, except by comparing the old value with the new one, and that means making a token float value that means 'no argument'. We could check the length of 'args' to see howmany arguments it contains, but that is a very fragile way, and breaks the wonderful transparentness of argument-passing and PyArg_Parse*. The alternative to this approach is not reading a double from the arglist, but a Python object (initialized as NULL,) and converting that to a float. That would have my preference over the other two options, above, but I still prefer the current way -- much less code, not that much slower (if slower at all, I didn't time it.) (Unless of course there is a way to see howmany optional arguments were used ? Like a separate format character that fills an int with that information, or a separate PyArg API call that returns not success/failure, but the number of optional arguments used, and -1 on failure.) I'll add news + docs, too, sometime before friday if work permits :P ------------------------------------------------------- Date: 2001-Jan-16 20:29 By: gvanrossum Comment: How hard would it be to avoid calling floattime() when an argument is present (in gmtime() and localtime())? Missing: docs, NEWS item. Otherwise, great -- ready to check in if you fix the above things! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103265&group_id=5470 From noreply@sourceforge.net Wed Jan 17 13:56:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 05:56:05 -0800 Subject: [Patches] [Patch #103252] Startup optimize: read *.pyc as string, not with getc() Message-ID: <E14It4H-0007mV-00@usw-sf-web2.sourceforge.net> Patch #103252 has been updated. Project: python Category: core (C code) Status: Open Submitted by: pj99 Assigned to : tim_one Summary: Startup optimize: read *.pyc as string, not with getc() Follow-Ups: Date: 2001-Jan-17 05:56 By: gvanrossum Comment: Re the stat syscall: you seem to be using fstat(), and HAVE_FSTAT *does* exist. (It is used in fileobject.c.) And if you need stat(): HAVE_STAT is also defined (used in import.c). So I think you're in good shape there. I agree with Tim's other recommendations! ------------------------------------------------------- Date: 2001-Jan-16 22:15 By: tim_one Comment: I'm afraid this patch needs major work before we could use it. The big thing is that stat isn't std C, and as far as I can tell we don't even define a config symbol saying whether it's available. Even when it is available, on at least one oddball platform it apparently needs oddball declarations (see the STAT/FSTAT/etc macros in posixfile.c). And the Macintosh code isn't in the CVS tree (Jack Jansen owns it), so no telling how it's done there. *Standard* C doesn't have a good way to determine the size of a file, either. While Python's os.path.getsize() is supported on all platforms, that's done in platform-dependent ways in platform-dependent files, and there's no Python C API for it. So the first step would be to define and implement a PyOS_GetFileSize() C API, akin to the existing PyOS_GetLastModificationTime() (in getmtime.c). Beyond that, there are small things that need fixing. Like: + malloc's return should be cast to char* + but malloc shouldn't be called directly to begin with (see pymem.h) + ditto free() + the pointer test (buf > 0) doesn't make sense (buf != NULL was intended) Once we get beyond all that <wink>, I think a three-tiered strategy would be worth implementing: also declare a 16K stack buffer. If a file is small enough, read into that; else if less than 256K (as Guido asked) malloc a buffer as is done now; else give up. 75% of the .pyc files on my box are under 16K (90% of IDLE's), so that would save the bulk of the malloc/free calls due to this. ------------------------------------------------------- Date: 2001-Jan-16 13:36 By: pj99 Comment: No problem, Tim (on the alledged abruptness). In any case, it was useful - in that it helped motivate /f into proposing a fix, me into coding it, and you to consider applying it. All in all a useful result. Most thanks, Tim. ------------------------------------------------------- Date: 2001-Jan-15 20:26 By: tim_one Comment: Indeed, IDLE takes more than a full second to come up on my box, *much* longer than Notepad. Now that we have a clear goal, I assigned this patch to me <wink>. (OK, it's really that I was abrupt with Paul when this came up on c.l.py, and left him hanging there -- I owe him on this one). ------------------------------------------------------- Date: 2001-Jan-15 20:18 By: gvanrossum Comment: Oh, but I do care about the load time of Tkinter. :-) Anything to keep IDLE ahead of Komodo in the race. :-) ------------------------------------------------------- Date: 2001-Jan-15 20:05 By: tim_one Comment: I like the idea, but gimmicks like this make porting to tiny platforms harder when pushed "too far". People concerned about startup time seem mostly to deal with apps that e.g. fire up Python 1000s of times from shell scripts or cgi. They're not going to care about monster modules (like Tkinter and grail). So I think Paul's original 64K is a good compromise. ------------------------------------------------------- Date: 2001-Jan-15 19:39 By: gvanrossum Comment: Not a bad idea. I'd up the limit to 256K so Tkinter.pyc (comfortably) fits. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103252&group_id=5470 From noreply@sourceforge.net Wed Jan 17 14:01:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 06:01:21 -0800 Subject: [Patches] [Patch #103265] Let time functions default to 'now' (where it makes sense) Message-ID: <E14It9N-0005a1-00@usw-sf-web1.sourceforge.net> Patch #103265 has been updated. Project: python Category: Modules Status: Open Submitted by: twouters Assigned to : twouters Summary: Let time functions default to 'now' (where it makes sense) Follow-Ups: Date: 2001-Jan-17 06:01 By: gvanrossum Comment: With METH_VARARGS, args is guaranteed to be a tuple, so you can simply use PyTuple_Size(). ------------------------------------------------------- Date: 2001-Jan-17 01:24 By: twouters Comment: Calling floattime() only when necessary would be nice, but isn't possible without a value that reads as 'empty'. There is no way to see whether optional values of a ParseTuple call were filled or not, except by comparing the old value with the new one, and that means making a token float value that means 'no argument'. We could check the length of 'args' to see howmany arguments it contains, but that is a very fragile way, and breaks the wonderful transparentness of argument-passing and PyArg_Parse*. The alternative to this approach is not reading a double from the arglist, but a Python object (initialized as NULL,) and converting that to a float. That would have my preference over the other two options, above, but I still prefer the current way -- much less code, not that much slower (if slower at all, I didn't time it.) (Unless of course there is a way to see howmany optional arguments were used ? Like a separate format character that fills an int with that information, or a separate PyArg API call that returns not success/failure, but the number of optional arguments used, and -1 on failure.) I'll add news + docs, too, sometime before friday if work permits :P ------------------------------------------------------- Date: 2001-Jan-16 20:29 By: gvanrossum Comment: How hard would it be to avoid calling floattime() when an argument is present (in gmtime() and localtime())? Missing: docs, NEWS item. Otherwise, great -- ready to check in if you fix the above things! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103265&group_id=5470 From noreply@sourceforge.net Wed Jan 17 14:55:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 06:55:40 -0800 Subject: [Patches] [Patch #103265] Let time functions default to 'now' (where it makes sense) Message-ID: <E14Itzw-0007DE-00@usw-sf-web3.sourceforge.net> Patch #103265 has been updated. Project: python Category: Modules Status: Open Submitted by: twouters Assigned to : fdrake Summary: Let time functions default to 'now' (where it makes sense) Follow-Ups: Date: 2001-Jan-17 06:55 By: twouters Comment: That's what I meant with 'check the size', but I still think it kind of breaks the abstraction of 'args'. Not in a terribly scary way, but the difference between calling floattime() always and doing a check whether or not to call floattime() isn't that big either. But you is BDFL, boss, so here's a patch that does it your way :) It also adds a NEWS entry and fixes the docs for timemodule (including docstrings.) Assigned to Fred so he can take a quick look at the docs. Don't need to check the TeX code though, Fred, I successfully built ps files on my laptop :) ------------------------------------------------------- Date: 2001-Jan-17 06:01 By: gvanrossum Comment: With METH_VARARGS, args is guaranteed to be a tuple, so you can simply use PyTuple_Size(). ------------------------------------------------------- Date: 2001-Jan-17 01:24 By: twouters Comment: Calling floattime() only when necessary would be nice, but isn't possible without a value that reads as 'empty'. There is no way to see whether optional values of a ParseTuple call were filled or not, except by comparing the old value with the new one, and that means making a token float value that means 'no argument'. We could check the length of 'args' to see howmany arguments it contains, but that is a very fragile way, and breaks the wonderful transparentness of argument-passing and PyArg_Parse*. The alternative to this approach is not reading a double from the arglist, but a Python object (initialized as NULL,) and converting that to a float. That would have my preference over the other two options, above, but I still prefer the current way -- much less code, not that much slower (if slower at all, I didn't time it.) (Unless of course there is a way to see howmany optional arguments were used ? Like a separate format character that fills an int with that information, or a separate PyArg API call that returns not success/failure, but the number of optional arguments used, and -1 on failure.) I'll add news + docs, too, sometime before friday if work permits :P ------------------------------------------------------- Date: 2001-Jan-16 20:29 By: gvanrossum Comment: How hard would it be to avoid calling floattime() when an argument is present (in gmtime() and localtime())? Missing: docs, NEWS item. Otherwise, great -- ready to check in if you fix the above things! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103265&group_id=5470 From noreply@sourceforge.net Wed Jan 17 15:17:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 07:17:02 -0800 Subject: [Patches] [Patch #103279] Flag for making sysconfig assume build directories Message-ID: <E14IuKc-0007Hn-00@usw-sf-web3.sourceforge.net> Patch #103279 has been updated. Project: python Category: distutils Status: Accepted Submitted by: akuchling Assigned to : gward Summary: Flag for making sysconfig assume build directories Follow-Ups: Date: 2001-Jan-17 07:17 By: akuchling Comment: Checked in and moved to 'Accepted' status, so gward can look at it later. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103279&group_id=5470 From noreply@sourceforge.net Wed Jan 17 15:18:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 07:18:03 -0800 Subject: [Patches] [Patch #103258] Cookie.py docs: example incorrect Message-ID: <E14IuLb-0007Hw-00@usw-sf-web3.sourceforge.net> Patch #103258 has been updated. Project: python Category: documentation Status: Accepted Submitted by: ping Assigned to : ping Summary: Cookie.py docs: example incorrect Follow-Ups: Date: 2001-Jan-17 07:18 By: fdrake Comment: Thanks; please check it in! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103258&group_id=5470 From noreply@sourceforge.net Wed Jan 17 15:43:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 07:43:27 -0800 Subject: [Patches] [Patch #101664] Add new unistr() builtin + PyObject_Unicode() C API Message-ID: <E14IukB-0008CG-00@usw-sf-web2.sourceforge.net> Patch #101664 has been updated. Project: python Category: core (C code) Status: Open Submitted by: lemburg Assigned to : lemburg Summary: Add new unistr() builtin + PyObject_Unicode() C API Follow-Ups: Date: 2001-Jan-17 07:43 By: gvanrossum Comment: Go ahead and check it in, Marc! ------------------------------------------------------- Date: 2000-Sep-26 04:14 By: lemburg Comment: This patch adds a utility function unistr() which works just like the standard builtin str() -- only that the return value will always be a Unicode object. The patch also adds a new object level C API PyObject_Unicode() which complements PyObject_Str(). Since this is a new feature, I have postponed the patch to be reopened in the 2.1 cycle. ------------------------------------------------------- Date: 2000-Oct-30 06:44 By: moshez Comment: There is no documentation for unistr() and PyObject_Unicode(), which is usually considered a show stopper by the powers that be. Here's some draft docos Insert into Doc/libfuncs.tex, after \begin{funcdesc}{str}....\end{funcdesc}: \begin{funcdesc}{unistr}{object} Return a Unicode representation of an object. It returns the result of converting the str(object) to unicode if the object can be converted into a string. It returns unicode objects as is. \end{funcdesc} Insert the following in Doc/api/api.tex after \begin{cfuncdesc}{PyObject*}{PyObject_Str}{PyObject *o}...\end{cfuncdesc} \begin{cfuncdesc}{PyObject *}{PyObject_Unicode}{PyObject *O} Compute a unicode representation of \var{o}. Returns the unicode representation on success \NULL{} on failure. This is the equivalent of the Python expression \samp{unistr(\var{o})}. Called by the \function{unistr()}\bifuncindex{unistr} built-in function. \end{cfuncdesc} Oh, and please don't use PyObject_GetAttrString: It's slow.... ------------------------------------------------------- Date: 2000-Oct-30 07:19 By: nobody Comment: Thanks. I'll add the docs to the patch. About PyObject_GetAttrString() ... I'll add an optimization somewhat like in classobject.c to PyObject_Unicode() which should help boost the performance somewhat. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101664&group_id=5470 From noreply@sourceforge.net Wed Jan 17 15:50:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 07:50:20 -0800 Subject: [Patches] [Patch #103265] Let time functions default to 'now' (where it makes sense) Message-ID: <E14Iuqq-0005zB-00@usw-sf-web1.sourceforge.net> Patch #103265 has been updated. Project: python Category: Modules Status: Open Submitted by: twouters Assigned to : fdrake Summary: Let time functions default to 'now' (where it makes sense) Follow-Ups: Date: 2001-Jan-17 07:50 By: gvanrossum Comment: Thomas, go for it. I'd say "the current time" instead of "now" in the NEWS item. I'll defer to Fred for the docs. ------------------------------------------------------- Date: 2001-Jan-17 06:55 By: twouters Comment: That's what I meant with 'check the size', but I still think it kind of breaks the abstraction of 'args'. Not in a terribly scary way, but the difference between calling floattime() always and doing a check whether or not to call floattime() isn't that big either. But you is BDFL, boss, so here's a patch that does it your way :) It also adds a NEWS entry and fixes the docs for timemodule (including docstrings.) Assigned to Fred so he can take a quick look at the docs. Don't need to check the TeX code though, Fred, I successfully built ps files on my laptop :) ------------------------------------------------------- Date: 2001-Jan-17 06:01 By: gvanrossum Comment: With METH_VARARGS, args is guaranteed to be a tuple, so you can simply use PyTuple_Size(). ------------------------------------------------------- Date: 2001-Jan-17 01:24 By: twouters Comment: Calling floattime() only when necessary would be nice, but isn't possible without a value that reads as 'empty'. There is no way to see whether optional values of a ParseTuple call were filled or not, except by comparing the old value with the new one, and that means making a token float value that means 'no argument'. We could check the length of 'args' to see howmany arguments it contains, but that is a very fragile way, and breaks the wonderful transparentness of argument-passing and PyArg_Parse*. The alternative to this approach is not reading a double from the arglist, but a Python object (initialized as NULL,) and converting that to a float. That would have my preference over the other two options, above, but I still prefer the current way -- much less code, not that much slower (if slower at all, I didn't time it.) (Unless of course there is a way to see howmany optional arguments were used ? Like a separate format character that fills an int with that information, or a separate PyArg API call that returns not success/failure, but the number of optional arguments used, and -1 on failure.) I'll add news + docs, too, sometime before friday if work permits :P ------------------------------------------------------- Date: 2001-Jan-16 20:29 By: gvanrossum Comment: How hard would it be to avoid calling floattime() when an argument is present (in gmtime() and localtime())? Missing: docs, NEWS item. Otherwise, great -- ready to check in if you fix the above things! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103265&group_id=5470 From noreply@sourceforge.net Wed Jan 17 15:51:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 07:51:47 -0800 Subject: [Patches] [Patch #103297] __all__ values for a handful of modules Message-ID: <E14IusF-0008E3-00@usw-sf-web2.sourceforge.net> Patch #103297 has been updated. Project: python Category: None Status: Open Submitted by: montanaro Assigned to : nobody Summary: __all__ values for a handful of modules ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103297&group_id=5470 From noreply@sourceforge.net Wed Jan 17 16:04:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 08:04:59 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14Iv51-0008Gz-00@usw-sf-web2.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : nascheme Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-17 08:04 By: fdrake Comment: New version of the patch that's still broken but doesn't conflict with the rich comparisons changes: http://starship.python.net/crew/fdrake/patches/weakref.patch-4 ------------------------------------------------------- Date: 2001-Jan-16 21:35 By: fdrake Comment: Added a new (but broken!) version of the patch that fixes WeakDictionary.get() but doesn't interact properly with GC (appearantly) -- not usable as is: http://starship.python.net/crew/fdrake/patches/weakref.patch-3 Neil made the mistake of volunteering to look at the current problem, so assigning to him. (Thanks!) ------------------------------------------------------- Date: 2001-Jan-16 19:39 By: tim_one Comment: Just mentioning a general scenario in which weak keys are the bee's knees: sometimes you want to add attributes to objects dynamically, in ways the original class author(s -- may cut across many classes! even non-instance objects; or objects from extension modules that don't support setattr) never anticipated. Like maybe a German translation of the object's docstrings; or a list of JPEG contents referenced by a URLish object; or a table of usage statistics on methods and functions; etc. Then it's natural to use the conceptual attr name as the name of a dict instead, and write attr[object] = whatever instead of object.attr = whatever There's no point keeping the "whatever" around when the object goes away, but a regular dict makes the object and its "whatever" immortal. A dict with weak keys is exactly on-target. ------------------------------------------------------- Date: 2001-Jan-16 19:14 By: fdrake Comment: I'm not entirely sure why one would want weak keys rather than weak values, but I suspect it has to do with expectations of how the dict will be used in applications. I don't think it would be hard to support both flavors of dictionaries using the primitive reference objects. The constructor does not check that all incoming values are weak because that isn't required. It uses self.update() rather than self.data.update() to perform the inclusion, so any mapping that supports .keys() and .__getitem__() is sufficient. Some additional checking could be done to make sure that all added entries can be created before inserting any of them, offering more atomicity. .get() will be fixed in the next version of the patch; thanks! I've added GC support, but don't have it working quite right. I'm trying to isolate the failure now. ------------------------------------------------------- Date: 2001-Jan-12 14:36 By: loewis Comment: The weak dictionary data type needs more clarification in documentation and implementation. In java.util.WeakHashMap, they keys are weak, not the values (i.e. once the key is forgotten, the entry is cleared). In http://www.handshake.de/~dieter/weakdict.html, the values are weak, but it raises KeyErrors for entries that are collected. The initializer of a weak dict does not check the invariant (all values are weak). get() of a weakdict does not support an optional second parameter. weakref and friends need to participate in garbage collection, as the reference to the callback can create a cycle. ------------------------------------------------------- Date: 2001-Jan-12 11:27 By: fdrake Comment: Updated patch to also support proxy semantics using the same invalidation machinery as the basic weak reference type. The additional code is *heavily* borrowed from Neil Schemenauer. ------------------------------------------------------- Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Wed Jan 17 17:09:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 09:09:16 -0800 Subject: [Patches] [Patch #101664] Add new unistr() builtin + PyObject_Unicode() C API Message-ID: <E14Iw5E-0006DU-00@usw-sf-web1.sourceforge.net> Patch #101664 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: lemburg Assigned to : lemburg Summary: Add new unistr() builtin + PyObject_Unicode() C API Follow-Ups: Date: 2001-Jan-17 09:09 By: lemburg Comment: Checked in. ------------------------------------------------------- Date: 2001-Jan-17 07:43 By: gvanrossum Comment: Go ahead and check it in, Marc! ------------------------------------------------------- Date: 2000-Sep-26 04:14 By: lemburg Comment: This patch adds a utility function unistr() which works just like the standard builtin str() -- only that the return value will always be a Unicode object. The patch also adds a new object level C API PyObject_Unicode() which complements PyObject_Str(). Since this is a new feature, I have postponed the patch to be reopened in the 2.1 cycle. ------------------------------------------------------- Date: 2000-Oct-30 06:44 By: moshez Comment: There is no documentation for unistr() and PyObject_Unicode(), which is usually considered a show stopper by the powers that be. Here's some draft docos Insert into Doc/libfuncs.tex, after \begin{funcdesc}{str}....\end{funcdesc}: \begin{funcdesc}{unistr}{object} Return a Unicode representation of an object. It returns the result of converting the str(object) to unicode if the object can be converted into a string. It returns unicode objects as is. \end{funcdesc} Insert the following in Doc/api/api.tex after \begin{cfuncdesc}{PyObject*}{PyObject_Str}{PyObject *o}...\end{cfuncdesc} \begin{cfuncdesc}{PyObject *}{PyObject_Unicode}{PyObject *O} Compute a unicode representation of \var{o}. Returns the unicode representation on success \NULL{} on failure. This is the equivalent of the Python expression \samp{unistr(\var{o})}. Called by the \function{unistr()}\bifuncindex{unistr} built-in function. \end{cfuncdesc} Oh, and please don't use PyObject_GetAttrString: It's slow.... ------------------------------------------------------- Date: 2000-Oct-30 07:19 By: nobody Comment: Thanks. I'll add the docs to the patch. About PyObject_GetAttrString() ... I'll add an optimization somewhat like in classobject.c to PyObject_Unicode() which should help boost the performance somewhat. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101664&group_id=5470 From noreply@sourceforge.net Wed Jan 17 19:07:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 11:07:58 -0800 Subject: [Patches] [Patch #101843] Remove all uses of "assert" from the test suite Message-ID: <E14Ixw6-0000Ol-00@usw-sf-web2.sourceforge.net> Patch #101843 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: lemburg Assigned to : lemburg Summary: Remove all uses of "assert" from the test suite Follow-Ups: Date: 2001-Jan-17 11:07 By: lemburg Comment: Checked in. The alpha tests will hopefully catch any bugs which this patch introduced -- I can't check all tests on my platform. ------------------------------------------------------- Date: 2001-Jan-04 11:11 By: lemburg Comment: I can't promise much because as always in the last few months, I'm way too busy with other tasks... ------------------------------------------------------- Date: 2001-Jan-04 07:56 By: gvanrossum Comment: Marc-Andre, do you have time to rework this for the current CVS tree? I still like the idea a lot! Once you have a current patch it can be checked in within days. ------------------------------------------------------- Date: 2000-Oct-09 07:25 By: lemburg Comment: This patch removes all uses of the assert statement from the regression test suite. Use of assert in the suite is depreciated due to asserts being removed from the byte code when Python is run in optimized mode. The patch adds a new function to test_support (verify) which handles the asserts in a more customizable way. It does not rely on the assert statement. I have tested this patch lightly (meaning that the suite runs through just fine). Not all execution paths are testable due to the nature of the patch, though. Please review. ------------------------------------------------------- Date: 2000-Oct-09 12:26 By: gvanrossum Comment: Great! But let's do this post-2.0 final release. I'm really getting worried about patches that touch every file in a particular corner of the universe... :-( ------------------------------------------------------- Date: 2000-Oct-24 13:57 By: gvanrossum Comment: Would you mind resubmitting this? Some of the patches fail, probably because there were a lot of changes to the whitespace. The idea is still as valid as it was before. A style nit: please don't include spaces inside parentheses: please write verify(cond, reason) rather than verify( cond, reason ). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101843&group_id=5470 From noreply@sourceforge.net Wed Jan 17 19:48:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 11:48:35 -0800 Subject: [Patches] [Patch #103303] patch to fix dis.py in the face of function attributes Message-ID: <E14IyZP-00089h-00@usw-sf-web3.sourceforge.net> Patch #103303 has been updated. Project: python Category: library Status: Open Submitted by: bwarsaw Assigned to : nobody Summary: patch to fix dis.py in the face of function attributes ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103303&group_id=5470 From noreply@sourceforge.net Wed Jan 17 19:58:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 11:58:51 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14IyjL-0000Yf-00@usw-sf-web2.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : fdrake Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-17 11:58 By: nascheme Comment: The magic test is: ./python Lib/test/regrtest.py test_weakref test_new Try adding this patch: --- Modules/newmodule.c 2000/11/13 20:29:20 2.29 +++ Modules/newmodule.c 2001/01/17 19:55:46 @@ -24,6 +24,7 @@ Py_INCREF(dict); inst->in_class = (PyClassObject *)klass; inst->in_dict = dict; + inst->in_weakreflist = NULL; PyObject_GC_Init(inst); return (PyObject *)inst; } ------------------------------------------------------- Date: 2001-Jan-17 08:04 By: fdrake Comment: New version of the patch that's still broken but doesn't conflict with the rich comparisons changes: http://starship.python.net/crew/fdrake/patches/weakref.patch-4 ------------------------------------------------------- Date: 2001-Jan-16 21:35 By: fdrake Comment: Added a new (but broken!) version of the patch that fixes WeakDictionary.get() but doesn't interact properly with GC (appearantly) -- not usable as is: http://starship.python.net/crew/fdrake/patches/weakref.patch-3 Neil made the mistake of volunteering to look at the current problem, so assigning to him. (Thanks!) ------------------------------------------------------- Date: 2001-Jan-16 19:39 By: tim_one Comment: Just mentioning a general scenario in which weak keys are the bee's knees: sometimes you want to add attributes to objects dynamically, in ways the original class author(s -- may cut across many classes! even non-instance objects; or objects from extension modules that don't support setattr) never anticipated. Like maybe a German translation of the object's docstrings; or a list of JPEG contents referenced by a URLish object; or a table of usage statistics on methods and functions; etc. Then it's natural to use the conceptual attr name as the name of a dict instead, and write attr[object] = whatever instead of object.attr = whatever There's no point keeping the "whatever" around when the object goes away, but a regular dict makes the object and its "whatever" immortal. A dict with weak keys is exactly on-target. ------------------------------------------------------- Date: 2001-Jan-16 19:14 By: fdrake Comment: I'm not entirely sure why one would want weak keys rather than weak values, but I suspect it has to do with expectations of how the dict will be used in applications. I don't think it would be hard to support both flavors of dictionaries using the primitive reference objects. The constructor does not check that all incoming values are weak because that isn't required. It uses self.update() rather than self.data.update() to perform the inclusion, so any mapping that supports .keys() and .__getitem__() is sufficient. Some additional checking could be done to make sure that all added entries can be created before inserting any of them, offering more atomicity. .get() will be fixed in the next version of the patch; thanks! I've added GC support, but don't have it working quite right. I'm trying to isolate the failure now. ------------------------------------------------------- Date: 2001-Jan-12 14:36 By: loewis Comment: The weak dictionary data type needs more clarification in documentation and implementation. In java.util.WeakHashMap, they keys are weak, not the values (i.e. once the key is forgotten, the entry is cleared). In http://www.handshake.de/~dieter/weakdict.html, the values are weak, but it raises KeyErrors for entries that are collected. The initializer of a weak dict does not check the invariant (all values are weak). get() of a weakdict does not support an optional second parameter. weakref and friends need to participate in garbage collection, as the reference to the callback can create a cycle. ------------------------------------------------------- Date: 2001-Jan-12 11:27 By: fdrake Comment: Updated patch to also support proxy semantics using the same invalidation machinery as the basic weak reference type. The additional code is *heavily* borrowed from Neil Schemenauer. ------------------------------------------------------- Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Wed Jan 17 21:06:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 13:06:49 -0800 Subject: [Patches] [Patch #103252] Startup optimize: read *.pyc as string, not with getc() Message-ID: <E14Izn7-0008WK-00@usw-sf-web3.sourceforge.net> Patch #103252 has been updated. Project: python Category: core (C code) Status: Open Submitted by: pj99 Assigned to : tim_one Summary: Startup optimize: read *.pyc as string, not with getc() Follow-Ups: Date: 2001-Jan-17 13:06 By: tim_one Comment: Brrrr. HAVE_STAT and HAVE_FSTAT aren't defined in a usable way -- they're defined *by* (and local to) the files in question, if symbols like DONT_HAVE_STAT are *not* defined. So I'll rip that stuff out, get rid of the duplication, and move the HAVE_[F]STAT stuff into pyport.h first. Assuming that doesn't break the build for anyone else, and since we agree on what ought to be done next, I'll then rework the patch accordingly and check it in. ------------------------------------------------------- Date: 2001-Jan-17 05:56 By: gvanrossum Comment: Re the stat syscall: you seem to be using fstat(), and HAVE_FSTAT *does* exist. (It is used in fileobject.c.) And if you need stat(): HAVE_STAT is also defined (used in import.c). So I think you're in good shape there. I agree with Tim's other recommendations! ------------------------------------------------------- Date: 2001-Jan-16 22:15 By: tim_one Comment: I'm afraid this patch needs major work before we could use it. The big thing is that stat isn't std C, and as far as I can tell we don't even define a config symbol saying whether it's available. Even when it is available, on at least one oddball platform it apparently needs oddball declarations (see the STAT/FSTAT/etc macros in posixfile.c). And the Macintosh code isn't in the CVS tree (Jack Jansen owns it), so no telling how it's done there. *Standard* C doesn't have a good way to determine the size of a file, either. While Python's os.path.getsize() is supported on all platforms, that's done in platform-dependent ways in platform-dependent files, and there's no Python C API for it. So the first step would be to define and implement a PyOS_GetFileSize() C API, akin to the existing PyOS_GetLastModificationTime() (in getmtime.c). Beyond that, there are small things that need fixing. Like: + malloc's return should be cast to char* + but malloc shouldn't be called directly to begin with (see pymem.h) + ditto free() + the pointer test (buf > 0) doesn't make sense (buf != NULL was intended) Once we get beyond all that <wink>, I think a three-tiered strategy would be worth implementing: also declare a 16K stack buffer. If a file is small enough, read into that; else if less than 256K (as Guido asked) malloc a buffer as is done now; else give up. 75% of the .pyc files on my box are under 16K (90% of IDLE's), so that would save the bulk of the malloc/free calls due to this. ------------------------------------------------------- Date: 2001-Jan-16 13:36 By: pj99 Comment: No problem, Tim (on the alledged abruptness). In any case, it was useful - in that it helped motivate /f into proposing a fix, me into coding it, and you to consider applying it. All in all a useful result. Most thanks, Tim. ------------------------------------------------------- Date: 2001-Jan-15 20:26 By: tim_one Comment: Indeed, IDLE takes more than a full second to come up on my box, *much* longer than Notepad. Now that we have a clear goal, I assigned this patch to me <wink>. (OK, it's really that I was abrupt with Paul when this came up on c.l.py, and left him hanging there -- I owe him on this one). ------------------------------------------------------- Date: 2001-Jan-15 20:18 By: gvanrossum Comment: Oh, but I do care about the load time of Tkinter. :-) Anything to keep IDLE ahead of Komodo in the race. :-) ------------------------------------------------------- Date: 2001-Jan-15 20:05 By: tim_one Comment: I like the idea, but gimmicks like this make porting to tiny platforms harder when pushed "too far". People concerned about startup time seem mostly to deal with apps that e.g. fire up Python 1000s of times from shell scripts or cgi. They're not going to care about monster modules (like Tkinter and grail). So I think Paul's original 64K is a good compromise. ------------------------------------------------------- Date: 2001-Jan-15 19:39 By: gvanrossum Comment: Not a bad idea. I'd up the limit to 256K so Tkinter.pyc (comfortably) fits. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103252&group_id=5470 From noreply@sourceforge.net Wed Jan 17 21:53:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 13:53:55 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14J0Wh-0000RW-00@usw-sf-web3.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : nascheme Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-17 13:53 By: fdrake Comment: Ok, I tihnk this is it! http://starship.python.net/crew/fdrake/patches/weakref.patch-5 This patch fixes the compilation problems from the previoous patch related to the introduction of rich comparisons, and makes a change in the way new objects are initialized by PyObject_New() and PyObject_NEW() (and all their friends!) -- those functions now know to initialize the weak reference list to NULL for objects which support weak references. Without this change, more places in the code (especially extension modules) need to know more about initialization of weakly-referencable objects. For instance, the "cPickle" and "new" modules both can create instances without calling the code in classobject.c (using PyObject_New()), causing core dumps when such instances are deallocated if the weak-reference list for instances was not properly initialized. Since these modules (properly) tried to avoid call PyInstance_New(), core dumps ensued and the world fell apart. By moving the initialization of the weak reference list into the core object allocators, this problem is averted and extension code to construct new weakly referencable types is simplified. The documentation still needs work, and there are a few new entries for the Python/C API manual as well. A new constructor for instances, PyInstance_NewRaw(), will be added in a separate patch. ------------------------------------------------------- Date: 2001-Jan-17 11:58 By: nascheme Comment: The magic test is: ./python Lib/test/regrtest.py test_weakref test_new Try adding this patch: --- Modules/newmodule.c 2000/11/13 20:29:20 2.29 +++ Modules/newmodule.c 2001/01/17 19:55:46 @@ -24,6 +24,7 @@ Py_INCREF(dict); inst->in_class = (PyClassObject *)klass; inst->in_dict = dict; + inst->in_weakreflist = NULL; PyObject_GC_Init(inst); return (PyObject *)inst; } ------------------------------------------------------- Date: 2001-Jan-17 08:04 By: fdrake Comment: New version of the patch that's still broken but doesn't conflict with the rich comparisons changes: http://starship.python.net/crew/fdrake/patches/weakref.patch-4 ------------------------------------------------------- Date: 2001-Jan-16 21:35 By: fdrake Comment: Added a new (but broken!) version of the patch that fixes WeakDictionary.get() but doesn't interact properly with GC (appearantly) -- not usable as is: http://starship.python.net/crew/fdrake/patches/weakref.patch-3 Neil made the mistake of volunteering to look at the current problem, so assigning to him. (Thanks!) ------------------------------------------------------- Date: 2001-Jan-16 19:39 By: tim_one Comment: Just mentioning a general scenario in which weak keys are the bee's knees: sometimes you want to add attributes to objects dynamically, in ways the original class author(s -- may cut across many classes! even non-instance objects; or objects from extension modules that don't support setattr) never anticipated. Like maybe a German translation of the object's docstrings; or a list of JPEG contents referenced by a URLish object; or a table of usage statistics on methods and functions; etc. Then it's natural to use the conceptual attr name as the name of a dict instead, and write attr[object] = whatever instead of object.attr = whatever There's no point keeping the "whatever" around when the object goes away, but a regular dict makes the object and its "whatever" immortal. A dict with weak keys is exactly on-target. ------------------------------------------------------- Date: 2001-Jan-16 19:14 By: fdrake Comment: I'm not entirely sure why one would want weak keys rather than weak values, but I suspect it has to do with expectations of how the dict will be used in applications. I don't think it would be hard to support both flavors of dictionaries using the primitive reference objects. The constructor does not check that all incoming values are weak because that isn't required. It uses self.update() rather than self.data.update() to perform the inclusion, so any mapping that supports .keys() and .__getitem__() is sufficient. Some additional checking could be done to make sure that all added entries can be created before inserting any of them, offering more atomicity. .get() will be fixed in the next version of the patch; thanks! I've added GC support, but don't have it working quite right. I'm trying to isolate the failure now. ------------------------------------------------------- Date: 2001-Jan-12 14:36 By: loewis Comment: The weak dictionary data type needs more clarification in documentation and implementation. In java.util.WeakHashMap, they keys are weak, not the values (i.e. once the key is forgotten, the entry is cleared). In http://www.handshake.de/~dieter/weakdict.html, the values are weak, but it raises KeyErrors for entries that are collected. The initializer of a weak dict does not check the invariant (all values are weak). get() of a weakdict does not support an optional second parameter. weakref and friends need to participate in garbage collection, as the reference to the callback can create a cycle. ------------------------------------------------------- Date: 2001-Jan-12 11:27 By: fdrake Comment: Updated patch to also support proxy semantics using the same invalidation machinery as the basic weak reference type. The additional code is *heavily* borrowed from Neil Schemenauer. ------------------------------------------------------- Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Wed Jan 17 22:01:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 14:01:47 -0800 Subject: [Patches] [Patch #103305] function attribute segfault Message-ID: <E14J0eJ-0000U5-00@usw-sf-web3.sourceforge.net> Patch #103305 has been updated. Project: python Category: core (C code) Status: Open Submitted by: greg_ball Assigned to : nobody Summary: function attribute segfault ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103305&group_id=5470 From noreply@sourceforge.net Wed Jan 17 22:03:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 14:03:45 -0800 Subject: [Patches] [Patch #103305] function attribute segfault Message-ID: <E14J0gD-0000Uy-00@usw-sf-web3.sourceforge.net> Patch #103305 has been updated. Project: python Category: core (C code) Status: Open Submitted by: greg_ball Assigned to : nobody Summary: function attribute segfault Follow-Ups: Date: 2001-Jan-17 14:03 By: greg_ball Comment: At two points, the code did not check for NULL, leading to segmentation fault soon after. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103305&group_id=5470 From noreply@sourceforge.net Wed Jan 17 22:46:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 14:46:03 -0800 Subject: [Patches] [Patch #100938] [Draft] libpython as shared library (.so) on Linux Message-ID: <E14J1L9-0001Ve-00@usw-sf-web2.sourceforge.net> Patch #100938 has been updated. Project: python Category: None Status: Open Submitted by: flight Assigned to : jhylton Summary: [Draft] libpython as shared library (.so) on Linux Follow-Ups: Date: 2001-Jan-17 14:46 By: nobody Comment: Getting this patch into the next version of Python would be "A Good Thing"(tm) in my opinion. We use libpython as a .so at ILM and end up having to make changes like this by hand every time we get a new version... ------------------------------------------------------- Date: 2000-Jul-19 14:10 By: flight Comment: This is what it used in product to build libpython as shared library(.so) for Debian. Note: This patch is not ready for inclusion in the upstream Python distribution. Anyway, I think this might be a start. The Python 1.5 executable in Debian GNU/Linux is built against a shared libpython1.5.so since April 1999, and I haven't yet heard about any problems. Using a shared library should have an advantage if you're running multiple instances of Python (be it standalone interpreter or embedded applications). ------------------------------------------------------- Date: 2000-Aug-15 10:52 By: tim_one Comment: Assigned to Barry because he's a Linux weenie. Barry, if you think there's something here that should go into 2.0, please pursue it now, else change the status to Postponed. ------------------------------------------------------- Date: 2000-Aug-16 00:40 By: moshez Comment: I suggest we postpone it. It isn't really complete (only works on real distributions <wink>), and the complete solution should work on all unices. If Tcl/Perl can do it, there is no reason Python can't -- and a half hearted solution isn't that good. flight, you should use this for the Python in woody in the mean time -- I doubt woody will be stable before Python 2.1 comes out, so 2.1 sounds like a good timeframe to do it. ------------------------------------------------------- Date: 2000-Aug-23 09:26 By: jhylton Comment: In the absence of anyone arguing for inclusion of this patch and a one-week idle period, it is postponed. ------------------------------------------------------- Date: 2000-Oct-26 14:13 By: gvanrossum Comment: Let's give this to Jeremy instead, because he seems to know more about build issues. Jeremy, it would be good to look into getting this to work with your RPM suite. Flight's argument (has been used without complaints in Debian Python 1.5.2 since 1999) is good. ------------------------------------------------------- Date: 2000-Nov-01 03:32 By: moshez Comment: I've had a look at the patch, and it seems it has two orthogonal parts. One is adding the infrastructure for compiling another version for the Python library, which can be more or less integrated as-is, and one is hard-coding the particular way, in Linux, of building shared objects. Since we discover how to build shared objects in the configure script anyway (otherwise we could not have built modules as shared objects), we should embed that information there, not the Linux flags. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100938&group_id=5470 From noreply@sourceforge.net Wed Jan 17 22:51:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 14:51:54 -0800 Subject: [Patches] [Patch #103305] function attribute segfault Message-ID: <E14J1Qo-0001Xq-00@usw-sf-web2.sourceforge.net> Patch #103305 has been updated. Project: python Category: core (C code) Status: Open Submitted by: greg_ball Assigned to : nobody Summary: function attribute segfault Follow-Ups: Date: 2001-Jan-17 14:51 By: greg_ball Comment: I have ready a new version of the patch (I won't upload it yet in case it's not welcome) which does the following: reference to f.__dict__ or f.func_dict returns a new dictionary if f did not previously have one. (Similar to what happens on first assignent to arbitrary attribute.) Then the following code works: >>> def f(): pass ... >>> d=f.__dict__ >>> f.a=1 >>> d['a'] 1 instead of d being an unsubscriptable object. To me it seems nasty if somethings __dict__ attribute might not be a dictionary. Since f.__dict__ never now _appears_ to be None, I also removed the feature of assigning it to None to get rid of it. del f.__dict__ can now be used for this purpose. (previously only for creating sig11 =) ) One other thought: as it stands, function attributes are strangely behaving in restricted mode. You can't set any attributes directly. You can't directly get attributes that don't start with an underscore. However, you can get __dict__ and then do anything you like to it... ------------------------------------------------------- Date: 2001-Jan-17 14:03 By: greg_ball Comment: At two points, the code did not check for NULL, leading to segmentation fault soon after. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103305&group_id=5470 From noreply@sourceforge.net Wed Jan 17 23:09:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 15:09:14 -0800 Subject: [Patches] [Patch #100938] [Draft] libpython as shared library (.so) on Linux Message-ID: <E14J1ha-0007k8-00@usw-sf-web1.sourceforge.net> Patch #100938 has been updated. Project: python Category: None Status: Open Submitted by: flight Assigned to : akuchling Summary: [Draft] libpython as shared library (.so) on Linux Follow-Ups: Date: 2001-Jan-17 15:09 By: gvanrossum Comment: Andrew, I'm tentatively reassigning this to you, since you're taking charge of the build process at the moment (setup.py). I suspect that the patch no longer works as is -- would it make sense to mark it postponed and get the author to submit a new version before we release 2.1a1? ------------------------------------------------------- Date: 2001-Jan-17 14:46 By: nobody Comment: Getting this patch into the next version of Python would be "A Good Thing"(tm) in my opinion. We use libpython as a .so at ILM and end up having to make changes like this by hand every time we get a new version... ------------------------------------------------------- Date: 2000-Jul-19 14:10 By: flight Comment: This is what it used in product to build libpython as shared library(.so) for Debian. Note: This patch is not ready for inclusion in the upstream Python distribution. Anyway, I think this might be a start. The Python 1.5 executable in Debian GNU/Linux is built against a shared libpython1.5.so since April 1999, and I haven't yet heard about any problems. Using a shared library should have an advantage if you're running multiple instances of Python (be it standalone interpreter or embedded applications). ------------------------------------------------------- Date: 2000-Aug-15 10:52 By: tim_one Comment: Assigned to Barry because he's a Linux weenie. Barry, if you think there's something here that should go into 2.0, please pursue it now, else change the status to Postponed. ------------------------------------------------------- Date: 2000-Aug-16 00:40 By: moshez Comment: I suggest we postpone it. It isn't really complete (only works on real distributions <wink>), and the complete solution should work on all unices. If Tcl/Perl can do it, there is no reason Python can't -- and a half hearted solution isn't that good. flight, you should use this for the Python in woody in the mean time -- I doubt woody will be stable before Python 2.1 comes out, so 2.1 sounds like a good timeframe to do it. ------------------------------------------------------- Date: 2000-Aug-23 09:26 By: jhylton Comment: In the absence of anyone arguing for inclusion of this patch and a one-week idle period, it is postponed. ------------------------------------------------------- Date: 2000-Oct-26 14:13 By: gvanrossum Comment: Let's give this to Jeremy instead, because he seems to know more about build issues. Jeremy, it would be good to look into getting this to work with your RPM suite. Flight's argument (has been used without complaints in Debian Python 1.5.2 since 1999) is good. ------------------------------------------------------- Date: 2000-Nov-01 03:32 By: moshez Comment: I've had a look at the patch, and it seems it has two orthogonal parts. One is adding the infrastructure for compiling another version for the Python library, which can be more or less integrated as-is, and one is hard-coding the particular way, in Linux, of building shared objects. Since we discover how to build shared objects in the configure script anyway (otherwise we could not have built modules as shared objects), we should embed that information there, not the Linux flags. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100938&group_id=5470 From noreply@sourceforge.net Thu Jan 18 04:41:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 20:41:43 -0800 Subject: [Patches] [Patch #103252] Startup optimize: read *.pyc as string, not with getc() Message-ID: <E14J6tL-0002XB-00@usw-sf-web3.sourceforge.net> Patch #103252 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: pj99 Assigned to : tim_one Summary: Startup optimize: read *.pyc as string, not with getc() Follow-Ups: Date: 2001-Jan-17 20:41 By: tim_one Comment: Thanks for pushing this, Paul! Checked in a variant as discussed here, marshal.c ver 1.59 and ACKS ver 1.71. The stat/fstat fiddling was done in a previous checkin. ------------------------------------------------------- Date: 2001-Jan-17 13:06 By: tim_one Comment: Brrrr. HAVE_STAT and HAVE_FSTAT aren't defined in a usable way -- they're defined *by* (and local to) the files in question, if symbols like DONT_HAVE_STAT are *not* defined. So I'll rip that stuff out, get rid of the duplication, and move the HAVE_[F]STAT stuff into pyport.h first. Assuming that doesn't break the build for anyone else, and since we agree on what ought to be done next, I'll then rework the patch accordingly and check it in. ------------------------------------------------------- Date: 2001-Jan-17 05:56 By: gvanrossum Comment: Re the stat syscall: you seem to be using fstat(), and HAVE_FSTAT *does* exist. (It is used in fileobject.c.) And if you need stat(): HAVE_STAT is also defined (used in import.c). So I think you're in good shape there. I agree with Tim's other recommendations! ------------------------------------------------------- Date: 2001-Jan-16 22:15 By: tim_one Comment: I'm afraid this patch needs major work before we could use it. The big thing is that stat isn't std C, and as far as I can tell we don't even define a config symbol saying whether it's available. Even when it is available, on at least one oddball platform it apparently needs oddball declarations (see the STAT/FSTAT/etc macros in posixfile.c). And the Macintosh code isn't in the CVS tree (Jack Jansen owns it), so no telling how it's done there. *Standard* C doesn't have a good way to determine the size of a file, either. While Python's os.path.getsize() is supported on all platforms, that's done in platform-dependent ways in platform-dependent files, and there's no Python C API for it. So the first step would be to define and implement a PyOS_GetFileSize() C API, akin to the existing PyOS_GetLastModificationTime() (in getmtime.c). Beyond that, there are small things that need fixing. Like: + malloc's return should be cast to char* + but malloc shouldn't be called directly to begin with (see pymem.h) + ditto free() + the pointer test (buf > 0) doesn't make sense (buf != NULL was intended) Once we get beyond all that <wink>, I think a three-tiered strategy would be worth implementing: also declare a 16K stack buffer. If a file is small enough, read into that; else if less than 256K (as Guido asked) malloc a buffer as is done now; else give up. 75% of the .pyc files on my box are under 16K (90% of IDLE's), so that would save the bulk of the malloc/free calls due to this. ------------------------------------------------------- Date: 2001-Jan-16 13:36 By: pj99 Comment: No problem, Tim (on the alledged abruptness). In any case, it was useful - in that it helped motivate /f into proposing a fix, me into coding it, and you to consider applying it. All in all a useful result. Most thanks, Tim. ------------------------------------------------------- Date: 2001-Jan-15 20:26 By: tim_one Comment: Indeed, IDLE takes more than a full second to come up on my box, *much* longer than Notepad. Now that we have a clear goal, I assigned this patch to me <wink>. (OK, it's really that I was abrupt with Paul when this came up on c.l.py, and left him hanging there -- I owe him on this one). ------------------------------------------------------- Date: 2001-Jan-15 20:18 By: gvanrossum Comment: Oh, but I do care about the load time of Tkinter. :-) Anything to keep IDLE ahead of Komodo in the race. :-) ------------------------------------------------------- Date: 2001-Jan-15 20:05 By: tim_one Comment: I like the idea, but gimmicks like this make porting to tiny platforms harder when pushed "too far". People concerned about startup time seem mostly to deal with apps that e.g. fire up Python 1000s of times from shell scripts or cgi. They're not going to care about monster modules (like Tkinter and grail). So I think Paul's original 64K is a good compromise. ------------------------------------------------------- Date: 2001-Jan-15 19:39 By: gvanrossum Comment: Not a bad idea. I'd up the limit to 256K so Tkinter.pyc (comfortably) fits. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103252&group_id=5470 From noreply@sourceforge.net Thu Jan 18 05:23:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 21:23:48 -0800 Subject: [Patches] [Patch #103252] Startup optimize: read *.pyc as string, not with getc() Message-ID: <E14J7Y4-00018N-00@usw-sf-web1.sourceforge.net> Patch #103252 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: pj99 Assigned to : tim_one Summary: Startup optimize: read *.pyc as string, not with getc() Follow-Ups: Date: 2001-Jan-17 21:23 By: pj99 Comment: You're welcome, Tim. Thanks for finishing it off! I was about to post saying that I was skeptical of the 16 Kb stack array, but since that's done (and since it was Guido himself suggesting it, and you agreeing to it), I won't go into that. Lets just say that I spent a past life working in a 4 Kb fixed length kernel stack. Good work. ------------------------------------------------------- Date: 2001-Jan-17 20:41 By: tim_one Comment: Thanks for pushing this, Paul! Checked in a variant as discussed here, marshal.c ver 1.59 and ACKS ver 1.71. The stat/fstat fiddling was done in a previous checkin. ------------------------------------------------------- Date: 2001-Jan-17 13:06 By: tim_one Comment: Brrrr. HAVE_STAT and HAVE_FSTAT aren't defined in a usable way -- they're defined *by* (and local to) the files in question, if symbols like DONT_HAVE_STAT are *not* defined. So I'll rip that stuff out, get rid of the duplication, and move the HAVE_[F]STAT stuff into pyport.h first. Assuming that doesn't break the build for anyone else, and since we agree on what ought to be done next, I'll then rework the patch accordingly and check it in. ------------------------------------------------------- Date: 2001-Jan-17 05:56 By: gvanrossum Comment: Re the stat syscall: you seem to be using fstat(), and HAVE_FSTAT *does* exist. (It is used in fileobject.c.) And if you need stat(): HAVE_STAT is also defined (used in import.c). So I think you're in good shape there. I agree with Tim's other recommendations! ------------------------------------------------------- Date: 2001-Jan-16 22:15 By: tim_one Comment: I'm afraid this patch needs major work before we could use it. The big thing is that stat isn't std C, and as far as I can tell we don't even define a config symbol saying whether it's available. Even when it is available, on at least one oddball platform it apparently needs oddball declarations (see the STAT/FSTAT/etc macros in posixfile.c). And the Macintosh code isn't in the CVS tree (Jack Jansen owns it), so no telling how it's done there. *Standard* C doesn't have a good way to determine the size of a file, either. While Python's os.path.getsize() is supported on all platforms, that's done in platform-dependent ways in platform-dependent files, and there's no Python C API for it. So the first step would be to define and implement a PyOS_GetFileSize() C API, akin to the existing PyOS_GetLastModificationTime() (in getmtime.c). Beyond that, there are small things that need fixing. Like: + malloc's return should be cast to char* + but malloc shouldn't be called directly to begin with (see pymem.h) + ditto free() + the pointer test (buf > 0) doesn't make sense (buf != NULL was intended) Once we get beyond all that <wink>, I think a three-tiered strategy would be worth implementing: also declare a 16K stack buffer. If a file is small enough, read into that; else if less than 256K (as Guido asked) malloc a buffer as is done now; else give up. 75% of the .pyc files on my box are under 16K (90% of IDLE's), so that would save the bulk of the malloc/free calls due to this. ------------------------------------------------------- Date: 2001-Jan-16 13:36 By: pj99 Comment: No problem, Tim (on the alledged abruptness). In any case, it was useful - in that it helped motivate /f into proposing a fix, me into coding it, and you to consider applying it. All in all a useful result. Most thanks, Tim. ------------------------------------------------------- Date: 2001-Jan-15 20:26 By: tim_one Comment: Indeed, IDLE takes more than a full second to come up on my box, *much* longer than Notepad. Now that we have a clear goal, I assigned this patch to me <wink>. (OK, it's really that I was abrupt with Paul when this came up on c.l.py, and left him hanging there -- I owe him on this one). ------------------------------------------------------- Date: 2001-Jan-15 20:18 By: gvanrossum Comment: Oh, but I do care about the load time of Tkinter. :-) Anything to keep IDLE ahead of Komodo in the race. :-) ------------------------------------------------------- Date: 2001-Jan-15 20:05 By: tim_one Comment: I like the idea, but gimmicks like this make porting to tiny platforms harder when pushed "too far". People concerned about startup time seem mostly to deal with apps that e.g. fire up Python 1000s of times from shell scripts or cgi. They're not going to care about monster modules (like Tkinter and grail). So I think Paul's original 64K is a good compromise. ------------------------------------------------------- Date: 2001-Jan-15 19:39 By: gvanrossum Comment: Not a bad idea. I'd up the limit to 256K so Tkinter.pyc (comfortably) fits. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103252&group_id=5470 From noreply@sourceforge.net Thu Jan 18 05:39:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 21:39:24 -0800 Subject: [Patches] [Patch #103252] Startup optimize: read *.pyc as string, not with getc() Message-ID: <E14J7nA-0001Df-00@usw-sf-web1.sourceforge.net> Patch #103252 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: pj99 Assigned to : tim_one Summary: Startup optimize: read *.pyc as string, not with getc() Follow-Ups: Date: 2001-Jan-17 21:39 By: tim_one Comment: file.readlines() already uses a stack buffer at least 8Kb, so I wasn't worried much about that. But worried enough to make sure this got into the alpha release. We get away with it or we don't; not a big deal either way. ------------------------------------------------------- Date: 2001-Jan-17 21:23 By: pj99 Comment: You're welcome, Tim. Thanks for finishing it off! I was about to post saying that I was skeptical of the 16 Kb stack array, but since that's done (and since it was Guido himself suggesting it, and you agreeing to it), I won't go into that. Lets just say that I spent a past life working in a 4 Kb fixed length kernel stack. Good work. ------------------------------------------------------- Date: 2001-Jan-17 20:41 By: tim_one Comment: Thanks for pushing this, Paul! Checked in a variant as discussed here, marshal.c ver 1.59 and ACKS ver 1.71. The stat/fstat fiddling was done in a previous checkin. ------------------------------------------------------- Date: 2001-Jan-17 13:06 By: tim_one Comment: Brrrr. HAVE_STAT and HAVE_FSTAT aren't defined in a usable way -- they're defined *by* (and local to) the files in question, if symbols like DONT_HAVE_STAT are *not* defined. So I'll rip that stuff out, get rid of the duplication, and move the HAVE_[F]STAT stuff into pyport.h first. Assuming that doesn't break the build for anyone else, and since we agree on what ought to be done next, I'll then rework the patch accordingly and check it in. ------------------------------------------------------- Date: 2001-Jan-17 05:56 By: gvanrossum Comment: Re the stat syscall: you seem to be using fstat(), and HAVE_FSTAT *does* exist. (It is used in fileobject.c.) And if you need stat(): HAVE_STAT is also defined (used in import.c). So I think you're in good shape there. I agree with Tim's other recommendations! ------------------------------------------------------- Date: 2001-Jan-16 22:15 By: tim_one Comment: I'm afraid this patch needs major work before we could use it. The big thing is that stat isn't std C, and as far as I can tell we don't even define a config symbol saying whether it's available. Even when it is available, on at least one oddball platform it apparently needs oddball declarations (see the STAT/FSTAT/etc macros in posixfile.c). And the Macintosh code isn't in the CVS tree (Jack Jansen owns it), so no telling how it's done there. *Standard* C doesn't have a good way to determine the size of a file, either. While Python's os.path.getsize() is supported on all platforms, that's done in platform-dependent ways in platform-dependent files, and there's no Python C API for it. So the first step would be to define and implement a PyOS_GetFileSize() C API, akin to the existing PyOS_GetLastModificationTime() (in getmtime.c). Beyond that, there are small things that need fixing. Like: + malloc's return should be cast to char* + but malloc shouldn't be called directly to begin with (see pymem.h) + ditto free() + the pointer test (buf > 0) doesn't make sense (buf != NULL was intended) Once we get beyond all that <wink>, I think a three-tiered strategy would be worth implementing: also declare a 16K stack buffer. If a file is small enough, read into that; else if less than 256K (as Guido asked) malloc a buffer as is done now; else give up. 75% of the .pyc files on my box are under 16K (90% of IDLE's), so that would save the bulk of the malloc/free calls due to this. ------------------------------------------------------- Date: 2001-Jan-16 13:36 By: pj99 Comment: No problem, Tim (on the alledged abruptness). In any case, it was useful - in that it helped motivate /f into proposing a fix, me into coding it, and you to consider applying it. All in all a useful result. Most thanks, Tim. ------------------------------------------------------- Date: 2001-Jan-15 20:26 By: tim_one Comment: Indeed, IDLE takes more than a full second to come up on my box, *much* longer than Notepad. Now that we have a clear goal, I assigned this patch to me <wink>. (OK, it's really that I was abrupt with Paul when this came up on c.l.py, and left him hanging there -- I owe him on this one). ------------------------------------------------------- Date: 2001-Jan-15 20:18 By: gvanrossum Comment: Oh, but I do care about the load time of Tkinter. :-) Anything to keep IDLE ahead of Komodo in the race. :-) ------------------------------------------------------- Date: 2001-Jan-15 20:05 By: tim_one Comment: I like the idea, but gimmicks like this make porting to tiny platforms harder when pushed "too far". People concerned about startup time seem mostly to deal with apps that e.g. fire up Python 1000s of times from shell scripts or cgi. They're not going to care about monster modules (like Tkinter and grail). So I think Paul's original 64K is a good compromise. ------------------------------------------------------- Date: 2001-Jan-15 19:39 By: gvanrossum Comment: Not a bad idea. I'd up the limit to 256K so Tkinter.pyc (comfortably) fits. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103252&group_id=5470 From ping@lfw.org Thu Jan 18 07:51:48 2001 From: ping@lfw.org (Ka-Ping Yee) Date: Wed, 17 Jan 2001 23:51:48 -0800 (PST) Subject: [Patches] [Patch #101664] Add new unistr() builtin + PyObject_Unicode() C API In-Reply-To: <E14IukB-0008CG-00@usw-sf-web2.sourceforge.net> Message-ID: <Pine.LNX.4.10.10101172348060.1568-100000@skuld.kingmanhall.org> On Wed, 17 Jan 2001 noreply@sourceforge.net wrote: > Comment: > This patch adds a utility function unistr() which works just like > the standard builtin str() -- only that the return value will > always be a Unicode object. Sorry for barging in, but i have an issue/question: Why are unistr() and unicode() two separate functions? str() performs one task: convert to string. It can convert anything, including strings or Unicode strings, numbers, instances, etc. The other type-named functions e.g. int(), long(), float(), list(), tuple() are similar in intent. Why have unicode() just for converting strings to Unicode strings, and unistr() for converting everything else to a Unicode string? What does unistr(x) do differently from unicode(x) if x is a string? -- ?!ng From noreply@sourceforge.net Thu Jan 18 07:58:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 23:58:01 -0800 Subject: [Patches] [Patch #103258] Cookie.py docs: example incorrect Message-ID: <E14J9xJ-0003na-00@usw-sf-web3.sourceforge.net> Patch #103258 has been updated. Project: python Category: documentation Status: Closed Submitted by: ping Assigned to : ping Summary: Cookie.py docs: example incorrect Follow-Ups: Date: 2001-Jan-17 23:58 By: ping Comment: Checked in. ------------------------------------------------------- Date: 2001-Jan-17 07:18 By: fdrake Comment: Thanks; please check it in! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103258&group_id=5470 From mal@lemburg.com Thu Jan 18 09:52:12 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 18 Jan 2001 10:52:12 +0100 Subject: [Patches] [Patch #101664] Add new unistr() builtin + PyObject_Unicode()C API References: <Pine.LNX.4.10.10101172348060.1568-100000@skuld.kingmanhall.org> Message-ID: <3A66BCCC.14997FE3@lemburg.com> Ka-Ping Yee wrote: > > On Wed, 17 Jan 2001 noreply@sourceforge.net wrote: > > Comment: > > This patch adds a utility function unistr() which works just like > > the standard builtin str() -- only that the return value will > > always be a Unicode object. > > Sorry for barging in, but i have an issue/question: > > Why are unistr() and unicode() two separate functions? > > str() performs one task: convert to string. It can convert anything, > including strings or Unicode strings, numbers, instances, etc. > > The other type-named functions e.g. int(), long(), float(), list(), > tuple() are similar in intent. > > Why have unicode() just for converting strings to Unicode strings, > and unistr() for converting everything else to a Unicode string? > What does unistr(x) do differently from unicode(x) if x is a string? unistr() is meant to complement str() very closely. unicode() works as constructor for Unicode objects which can also take care of decoding encoded data. str() and unistr() don't provide this capability but instead always assume the default encoding. There's also a subtle difference in that str() and unistr() try the tp_str slot which unicode() doesn't. unicode() supports any character buffer which str() and unistr() don't. Perhaps you are right though in that we should make all three APIs behave in the same way with respect to coercing their arguments. This could hide some errors... still in the long run, I agree that the existing setup probably causes more confusion than good. Guido ? -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From noreply@sourceforge.net Thu Jan 18 16:02:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 08:02:45 -0800 Subject: [Patches] [Patch #103313] Include build directory when running "make test" Message-ID: <E14JHWP-0007NN-00@usw-sf-web2.sourceforge.net> Patch #103313 has been updated. Project: python Category: Build Status: Open Submitted by: akuchling Assigned to : nobody Summary: Include build directory when running "make test" ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103313&group_id=5470 From noreply@sourceforge.net Thu Jan 18 16:35:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 08:35:10 -0800 Subject: [Patches] [Patch #102989] Allow 'continue' inside 'try' clause Message-ID: <E14JI1m-0007bc-00@usw-sf-web2.sourceforge.net> 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: 2001-Jan-18 08:35 By: twouters Comment: It seems Jeremy doesn't have time to review it right now, either. Which is not suprising, looking at the number of tasks assigned to him ;) Maybe someone else can take a look at this ? It shouldn't be that hard, the patch isn't *that* controversial, and it would be nice to have this in alpha1, I do think. The patch still applies fine, though it gives some harmless offset/fuzz warnings. Also, you need either to bump the bytecode magic or remove all .pyc files for it to actually matter (or run 'make distclean'.) ------------------------------------------------------- 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 Jan 18 16:37:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 08:37:38 -0800 Subject: [Patches] [Patch #103048] Generate simple JUMP_FORWARD for 'break' outside 'try' Message-ID: <E14JI4A-0007cO-00@usw-sf-web2.sourceforge.net> 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: 2001-Jan-18 08:37 By: twouters Comment: I'm going to suggest postponing this patch until 2.2, unless someone comes up and disagrees :) This is not a terribly useful feature, it's not visible from the 'outside' to start with, and the benifits are unclear. I'm also not sure if it works properly yet. I mostly submitted this patch to get rid of the 'TODO' entry at the top of compile.c. ------------------------------------------------------- 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 Thu Jan 18 17:32:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 09:32:13 -0800 Subject: [Patches] [Patch #102989] Allow 'continue' inside 'try' clause Message-ID: <E14JIuz-0007wb-00@usw-sf-web2.sourceforge.net> 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: 2001-Jan-18 09:32 By: jhylton Comment: I will take a look at this patch before 2.1a1. I am trying to finish up some fairly major compiler changes, so it seems natural to review this patch next. ------------------------------------------------------- Date: 2001-Jan-18 08:35 By: twouters Comment: It seems Jeremy doesn't have time to review it right now, either. Which is not suprising, looking at the number of tasks assigned to him ;) Maybe someone else can take a look at this ? It shouldn't be that hard, the patch isn't *that* controversial, and it would be nice to have this in alpha1, I do think. The patch still applies fine, though it gives some harmless offset/fuzz warnings. Also, you need either to bump the bytecode magic or remove all .pyc files for it to actually matter (or run 'make distclean'.) ------------------------------------------------------- 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 Jan 18 17:38:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 09:38:51 -0800 Subject: [Patches] [Patch #103314] allow urllib.urlencode to work with multivalued parameters Message-ID: <E14JJ1P-0007zK-00@usw-sf-web2.sourceforge.net> Patch #103314 has been updated. Project: python Category: library Status: Open Submitted by: montanaro Assigned to : nobody Summary: allow urllib.urlencode to work with multivalued parameters ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103314&group_id=5470 From noreply@sourceforge.net Thu Jan 18 17:39:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 09:39:58 -0800 Subject: [Patches] [Patch #101137] Add raw packet support to socketmodule.c Message-ID: <E14JJ2U-0007zk-00@usw-sf-web2.sourceforge.net> Patch #101137 has been updated. Project: python Category: Modules Status: Open Submitted by: grante Assigned to : jhylton Summary: Add raw packet support to socketmodule.c Follow-Ups: Date: 2001-Jan-18 09:39 By: jhylton Comment: Is Grant still interested in this patch? I don't have time to fix it myself, but I would be happy to look at it again if we comments and questions are addressed. ------------------------------------------------------- Date: 2000-Aug-09 14:49 By: grante Comment: Patch has only been tested on Linux: RH6.2 (Intel). Patch is against 1.6b1 ------------------------------------------------------- Date: 2000-Aug-15 15:15 By: tim_one Comment: Assigned to Barry, since he just volunteered to rewrite all of Python's socket code anyway <wink>. ------------------------------------------------------- Date: 2000-Aug-24 14:27 By: jhylton Comment: Not sure about this patch. It needs to be tested on more platforms than just Linux, but I don't see that we'll have time before 2.0. There are several other issues that must be resolved, too. Thus, this patch falls subject to the feature freeze. Style points: Indention is wrong. The opening curly brace of an if belongs on the same line as the test. Whitespace is required around = and after commas in argument lists. The strncpy in makesockaddr does not check the size of the source string. It could overflow the buffer. In makesockaddr, a new socket is created just to look up the interface name associated with a particular interface. This seems wasteful, particularly in cases where few file descriptors are available. I'm not sure what the solution is, although it might be to change the makesockaddr function so that it takes the socket itself. Perhaps that socket address for AF_PACKET should also accept and/or produce interface numbers which the client can convert to names manually. The sockaddr_ll has members ssl_hatype and ssl_pkttype, which are not made accessible by this patch. It seems like they should be, but I am not sure. Can you use SOCK_DGRAM without specifying the packet type? getsockaddrarg is handled, but getsockaddrlen is not. Question: Are there any other constants that should be added? This relates to the packet type question. * ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101137&group_id=5470 From noreply@sourceforge.net Thu Jan 18 17:42:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 09:42:16 -0800 Subject: [Patches] [Patch #103314] allow urllib.urlencode to work with multivalued parameters Message-ID: <E14JJ4i-00080s-00@usw-sf-web2.sourceforge.net> Patch #103314 has been updated. Project: python Category: library Status: Open Submitted by: montanaro Assigned to : fdrake Summary: allow urllib.urlencode to work with multivalued parameters Follow-Ups: Date: 2001-Jan-18 09:42 By: montanaro Comment: Assigned to Fred for starters because it does have a doc change. Fred, Guido probably wants to look at it next, but you're a better judge of who might have more free time... S ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103314&group_id=5470 From noreply@sourceforge.net Thu Jan 18 18:01:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 10:01:32 -0800 Subject: [Patches] [Patch #101137] Add raw packet support to socketmodule.c Message-ID: <E14JJNM-0005gt-00@usw-sf-web1.sourceforge.net> Patch #101137 has been updated. Project: python Category: Modules Status: Open Submitted by: grante Assigned to : jhylton Summary: Add raw packet support to socketmodule.c Follow-Ups: Date: 2001-Jan-18 10:01 By: nobody Comment: Yes, I'm still interested in this patch. Winthin the next week or two I'll try to get a revised patch submitted that addresses some of the comments. Two things I can't do much about are: 1) I only have Linux systems for testing: I don't have root privledges on any other type of system. 2) Unless it is agreed to change parameters for makesockaddr, I can't do anything except create a temporary socket in order to look up the interface name. I suppose I could require user code to provide an interface index, but I don't really like that option since it diverges quite a bit from the "C" usage. ------------------------------------------------------- Date: 2001-Jan-18 09:39 By: jhylton Comment: Is Grant still interested in this patch? I don't have time to fix it myself, but I would be happy to look at it again if we comments and questions are addressed. ------------------------------------------------------- Date: 2000-Aug-09 14:49 By: grante Comment: Patch has only been tested on Linux: RH6.2 (Intel). Patch is against 1.6b1 ------------------------------------------------------- Date: 2000-Aug-15 15:15 By: tim_one Comment: Assigned to Barry, since he just volunteered to rewrite all of Python's socket code anyway <wink>. ------------------------------------------------------- Date: 2000-Aug-24 14:27 By: jhylton Comment: Not sure about this patch. It needs to be tested on more platforms than just Linux, but I don't see that we'll have time before 2.0. There are several other issues that must be resolved, too. Thus, this patch falls subject to the feature freeze. Style points: Indention is wrong. The opening curly brace of an if belongs on the same line as the test. Whitespace is required around = and after commas in argument lists. The strncpy in makesockaddr does not check the size of the source string. It could overflow the buffer. In makesockaddr, a new socket is created just to look up the interface name associated with a particular interface. This seems wasteful, particularly in cases where few file descriptors are available. I'm not sure what the solution is, although it might be to change the makesockaddr function so that it takes the socket itself. Perhaps that socket address for AF_PACKET should also accept and/or produce interface numbers which the client can convert to names manually. The sockaddr_ll has members ssl_hatype and ssl_pkttype, which are not made accessible by this patch. It seems like they should be, but I am not sure. Can you use SOCK_DGRAM without specifying the packet type? getsockaddrarg is handled, but getsockaddrlen is not. Question: Are there any other constants that should be added? This relates to the packet type question. * ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101137&group_id=5470 From noreply@sourceforge.net Thu Jan 18 18:09:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 10:09:55 -0800 Subject: [Patches] [Patch #103314] allow urllib.urlencode to work with multivalued parameters Message-ID: <E14JJVT-0005jZ-00@usw-sf-web1.sourceforge.net> Patch #103314 has been updated. Project: python Category: library Status: Open Submitted by: montanaro Assigned to : fdrake Summary: allow urllib.urlencode to work with multivalued parameters Follow-Ups: Date: 2001-Jan-18 10:09 By: gvanrossum Comment: Comment: I would test for doseq once, and then have two loops: one with the old behavior and one with the new. Also, you might want to catch Unicode and explicitly force it into ASCII (rather than committing to a conversion without knowing what's the right thing). ------------------------------------------------------- Date: 2001-Jan-18 09:42 By: montanaro Comment: Assigned to Fred for starters because it does have a doc change. Fred, Guido probably wants to look at it next, but you're a better judge of who might have more free time... S ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103314&group_id=5470 From guido@digicool.com Thu Jan 18 18:09:24 2001 From: guido@digicool.com (Guido van Rossum) Date: Thu, 18 Jan 2001 13:09:24 -0500 Subject: [Patches] [Patch #101664] Add new unistr() builtin + PyObject_Unicode()C API In-Reply-To: Your message of "Thu, 18 Jan 2001 10:52:12 +0100." <3A66BCCC.14997FE3@lemburg.com> References: <Pine.LNX.4.10.10101172348060.1568-100000@skuld.kingmanhall.org> <3A66BCCC.14997FE3@lemburg.com> Message-ID: <200101181809.NAA08231@cj20424-a.reston1.va.home.com> Let's redirect this to python-dev, please! --Guido van Rossum (home page: http://www.python.org/~guido/) From noreply@sourceforge.net Thu Jan 18 21:23:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 13:23:26 -0800 Subject: [Patches] [Patch #103313] Include build directory when running "make test" Message-ID: <E14JMWk-0000nG-00@usw-sf-web2.sourceforge.net> Patch #103313 has been updated. Project: python Category: Build Status: Closed Submitted by: akuchling Assigned to : akuchling Summary: Include build directory when running "make test" Follow-Ups: Date: 2001-Jan-18 13:23 By: akuchling Comment: Checked in on Barry's urging. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103313&group_id=5470 From noreply@sourceforge.net Thu Jan 18 21:30:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 13:30:58 -0800 Subject: [Patches] [Patch #103305] function attribute segfault Message-ID: <E14JMe2-0004JE-00@usw-sf-web1.sourceforge.net> Patch #103305 has been updated. Project: python Category: core (C code) Status: Open Submitted by: greg_ball Assigned to : bwarsaw Summary: function attribute segfault Follow-Ups: Date: 2001-Jan-18 13:30 By: bwarsaw Comment: Assigning this to me to look at later. ------------------------------------------------------- Date: 2001-Jan-17 14:51 By: greg_ball Comment: I have ready a new version of the patch (I won't upload it yet in case it's not welcome) which does the following: reference to f.__dict__ or f.func_dict returns a new dictionary if f did not previously have one. (Similar to what happens on first assignent to arbitrary attribute.) Then the following code works: >>> def f(): pass ... >>> d=f.__dict__ >>> f.a=1 >>> d['a'] 1 instead of d being an unsubscriptable object. To me it seems nasty if somethings __dict__ attribute might not be a dictionary. Since f.__dict__ never now _appears_ to be None, I also removed the feature of assigning it to None to get rid of it. del f.__dict__ can now be used for this purpose. (previously only for creating sig11 =) ) One other thought: as it stands, function attributes are strangely behaving in restricted mode. You can't set any attributes directly. You can't directly get attributes that don't start with an underscore. However, you can get __dict__ and then do anything you like to it... ------------------------------------------------------- Date: 2001-Jan-17 14:03 By: greg_ball Comment: At two points, the code did not check for NULL, leading to segmentation fault soon after. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103305&group_id=5470 From noreply@sourceforge.net Fri Jan 19 01:57:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 17:57:26 -0800 Subject: [Patches] [Patch #103305] function attribute segfault Message-ID: <E14JQnu-0005cm-00@usw-sf-web1.sourceforge.net> Patch #103305 has been updated. Project: python Category: core (C code) Status: Open Submitted by: greg_ball Assigned to : bwarsaw Summary: function attribute segfault Follow-Ups: Date: 2001-Jan-18 17:57 By: gvanrossum Comment: This is a high priority patch -- needs to be deal with before 2.1a1 can go out. ------------------------------------------------------- Date: 2001-Jan-18 13:30 By: bwarsaw Comment: Assigning this to me to look at later. ------------------------------------------------------- Date: 2001-Jan-17 14:51 By: greg_ball Comment: I have ready a new version of the patch (I won't upload it yet in case it's not welcome) which does the following: reference to f.__dict__ or f.func_dict returns a new dictionary if f did not previously have one. (Similar to what happens on first assignent to arbitrary attribute.) Then the following code works: >>> def f(): pass ... >>> d=f.__dict__ >>> f.a=1 >>> d['a'] 1 instead of d being an unsubscriptable object. To me it seems nasty if somethings __dict__ attribute might not be a dictionary. Since f.__dict__ never now _appears_ to be None, I also removed the feature of assigning it to None to get rid of it. del f.__dict__ can now be used for this purpose. (previously only for creating sig11 =) ) One other thought: as it stands, function attributes are strangely behaving in restricted mode. You can't set any attributes directly. You can't directly get attributes that don't start with an underscore. However, you can get __dict__ and then do anything you like to it... ------------------------------------------------------- Date: 2001-Jan-17 14:03 By: greg_ball Comment: At two points, the code did not check for NULL, leading to segmentation fault soon after. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103305&group_id=5470 From noreply@sourceforge.net Fri Jan 19 02:32:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 18:32:03 -0800 Subject: [Patches] [Patch #103297] __all__ values for a handful of modules Message-ID: <E14JRLP-0001Ol-00@usw-sf-web3.sourceforge.net> Patch #103297 has been updated. Project: python Category: library Status: Open Submitted by: montanaro Assigned to : nobody Summary: __all__ values for a handful of modules Follow-Ups: Date: 2001-Jan-18 18:32 By: gvanrossum Comment: Nice, Skip! I wonder if the "test" functions should really be included in __all__? Especially StringIO's test isn't generally needed. I'd be happy if I had to import it explicitly using "from StringIO import test" if I really wanted it. Ditto for the HTTP server classes. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103297&group_id=5470 From noreply@sourceforge.net Fri Jan 19 02:41:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 18:41:16 -0800 Subject: [Patches] [Patch #103303] patch to fix dis.py in the face of function attributes Message-ID: <E14JRUK-0001RW-00@usw-sf-web3.sourceforge.net> Patch #103303 has been updated. Project: python Category: library Status: Closed Submitted by: bwarsaw Assigned to : gvanrossum Summary: patch to fix dis.py in the face of function attributes Follow-Ups: Date: 2001-Jan-18 18:41 By: gvanrossum Comment: Checked in, with one change: test for im_func first and for func_code second, like it did before. I was surprised that with the test for func_code first it worked for (un)bound methods, but it really did! The reason is that if C.f is an unbound method, the expression C.f.func_code (which previously was not defined) now passes the func_code attribute to the function! Still, it's more logical to test for im_func first so we don't rely on this dubious behavior. Closed. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103303&group_id=5470 From noreply@sourceforge.net Fri Jan 19 03:04:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 19:04:01 -0800 Subject: [Patches] [Patch #102549] simpler, faster(!) implementation of string.join Message-ID: <E14JRqL-0005vk-00@usw-sf-web1.sourceforge.net> Patch #102549 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: mwh Assigned to : tim_one Summary: simpler, faster(!) implementation of string.join Follow-Ups: Date: 2001-Jan-18 19:04 By: tim_one Comment: Agree the rewrite was a good idea. Thanks! Checked in a derived patch, in stringobject.c rev 2.98. That also fixes two join bugs that have been around at least since 2.0 was released (see checkin comment). ------------------------------------------------------- Date: 2000-Nov-27 12:40 By: mwh Comment: attempting to fix a but in string.join, I realised that I didn't understand the current implementation. So I rewrote it. In doing so, I found the bug, but as my rewrite seems to be a little faster I thought I'd submit it. The additional clarity is the main point though. ------------------------------------------------------- Date: 2000-Nov-27 13:32 By: gvanrossum Comment: Tim -- can you review this? ------------------------------------------------------- Date: 2000-Nov-27 13:54 By: gvanrossum Comment: In Python-dev, /F says: your patch changes the behaviour of join on non-standard sequences. if you use join on a long synthetic sequence, your new version may run out of memory where the old one worked just fine. not sure that's a good idea. -0 ------------------------------------------------------- Date: 2000-Nov-27 13:57 By: gvanrossum Comment: And then later: looking again, this was obviously only true for the unicode version (which uses PySequence_GetItem), not for the 8-bit string version (which uses the PySequence_Fast API). maybe we should change the 8-bit implementation instead? if not, +1. </F> ------------------------------------------------------- Date: 2000-Nov-28 00:26 By: mwh Comment: oops - my code had a bug. 'sep'.join(['a','b']) would return 'asepbsep'. ------------------------------------------------------- Date: 2000-Nov-28 09:42 By: mwh Comment: oops again - this now doesn't dump core with empty sequences... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102549&group_id=5470 From noreply@sourceforge.net Fri Jan 19 02:56:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 18:56:04 -0800 Subject: [Patches] [Patch #103318] non-recursive makefile Message-ID: <E14JRie-0001WC-00@usw-sf-web3.sourceforge.net> Patch #103318 has been updated. Project: python Category: Build Status: Open Submitted by: nascheme Assigned to : nobody Summary: non-recursive makefile Follow-Ups: Date: 2001-Jan-18 18:56 By: gvanrossum Comment: I'm in a quandary. This is really awesone! But a bit too rough to add to the 2.1a1 release. You don't seem to deal with buildno properly -- what's the problem there? Also, I seem to recall that the "-o file.o" option is not universal amongst C compilers. Could someone who uses a non-GCC compiler (e.g. SunPro, or HP, or AIX) check the portability of this Makefile? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103318&group_id=5470 From noreply@sourceforge.net Fri Jan 19 03:09:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 19:09:57 -0800 Subject: [Patches] [Patch #103297] __all__ values for a handful of modules Message-ID: <E14JRw5-0001aG-00@usw-sf-web3.sourceforge.net> Patch #103297 has been updated. Project: python Category: library Status: Open Submitted by: montanaro Assigned to : nobody Summary: __all__ values for a handful of modules Follow-Ups: Date: 2001-Jan-18 19:09 By: montanaro Comment: Yeah, I wondered about including "test". I included it only because I thought I remembered someone mentioning that in a previous thread. I'll remove "test" from __all__ in my next update. Assuming everything else is okay, I will keep adding to the number of modified modules. ------------------------------------------------------- Date: 2001-Jan-18 18:32 By: gvanrossum Comment: Nice, Skip! I wonder if the "test" functions should really be included in __all__? Especially StringIO's test isn't generally needed. I'd be happy if I had to import it explicitly using "from StringIO import test" if I really wanted it. Ditto for the HTTP server classes. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103297&group_id=5470 From noreply@sourceforge.net Fri Jan 19 03:18:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 19:18:11 -0800 Subject: [Patches] [Patch #103323] trivial tests of all untested modules Message-ID: <E14JS43-0005zZ-00@usw-sf-web1.sourceforge.net> Patch #103323 has been updated. Project: python Category: None Status: Open Submitted by: jhylton Assigned to : nobody Summary: trivial tests of all untested modules ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103323&group_id=5470 From noreply@sourceforge.net Thu Jan 18 23:14:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 15:14:47 -0800 Subject: [Patches] [Patch #103318] non-recursive makefile Message-ID: <E14JOGV-0000U7-00@usw-sf-web3.sourceforge.net> Patch #103318 has been updated. Project: python Category: Build Status: Open Submitted by: nascheme Assigned to : nobody Summary: non-recursive makefile ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103318&group_id=5470 From noreply@sourceforge.net Thu Jan 18 23:56:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 15:56:32 -0800 Subject: [Patches] [Patch #102847] fix a memory leak Message-ID: <E14JOuu-0001cS-00@usw-sf-web2.sourceforge.net> Patch #102847 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: cgw Assigned to : jhylton Summary: fix a memory leak Follow-Ups: Date: 2001-Jan-18 15:56 By: jhylton Comment: no longer relevant; the mainloop is different ------------------------------------------------------- Date: 2001-Jan-13 10:40 By: moshez Comment: 102337 is now closed. ------------------------------------------------------- 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 Thu Jan 18 23:57:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 15:57:53 -0800 Subject: [Patches] [Patch #101702] Modify co_filename in frozen programs Message-ID: <E14JOwD-0001cx-00@usw-sf-web2.sourceforge.net> Patch #101702 has been updated. Project: python Category: demos and tools Status: Open Submitted by: lhudson Assigned to : mhammond Summary: Modify co_filename in frozen programs Follow-Ups: Date: 2001-Jan-18 15:57 By: jhylton Comment: (somewhat) randomly reassigned; don't have time to look at this ------------------------------------------------------- Date: 2000-Sep-29 04:39 By: lhudson Comment: A new feature for freeze. This patch was developed primarily to reduce the size of the frozen binary. It is particularly useful when freezing for 'small' platforms, such as Palm OS, where you really want to save that last miserable byte. A limitation of this patch is that it does not provide any feedback about the replacements being made. As the path matching is case-sensitive this may lead to unexpected behaviour for DOS and Windows people, eg > freeze.py -r C:\Python\Lib\=py\ goats.py should probably be: > freeze.py -r c:\python\lib\=py\ goats.py ------------------------------------------------------- Date: 2000-Sep-29 07:28 By: jhylton Comment: This sounds like a reasonable enough feature, but we are in feature freeze for Python 2.0. ------------------------------------------------------- Date: 2000-Oct-23 12:33 By: gvanrossum Comment: I like the idea, but I have a few suggestions. - To avoid the case sensitivity issue you mention, you could use os.path.normpath() before the string comparisons. - Rather than writing to a real temporary file, you could marshal to a string and than unmarshal from a StringIO file. - And the big whopper: rather than using a modified version of unmarshal, I suggest writing a recursive code object transformer. It takes a code object and a replace_paths list, and returns a similar code object with the co_filename attribute changed according to the list. The trick is that it should also do this, recursively, to any code object found in the co_consts tuple. (That's the only place where code objects can occur recursively.) While this is probably not much less code than the marshaller you wrote, it has the advantage of not being dependent on the details of the marshal format. Please upload a new patch -- I'm interested in getting this into Python 2.1. ------------------------------------------------------- Date: 2000-Oct-25 01:36 By: lhudson Comment: A recursive code object transformer has been implemented as a member of the ModuleFinder. Case sensitivity issue: normpath strips trailing '/' or '\\' which reduces the flexibility of the path replacement. It also does not seem to solve the case-sensitivity problem: D:\>python Python 2.0 (#8, Oct 17 2000, 15:27:24) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import os >>> os.path.normpath("c:\\python\\lib\\") 'c:\\python\\lib' >>> os.path.normpath("c:\\python\\Lib\\") 'c:\\python\\Lib' >>> ModuleFinder's debugging system is used to report the status of each unique path encountered. Temporary file: marshal.dump() and marshal.load() only work with file objects, not file-like objects. Now that new code objects are being created there is no longer any reason to re-marshal so this problem disappears. ------------------------------------------------------- Date: 2000-Oct-25 04:19 By: gvanrossum Comment: Thanks for the new patch! I'll assign this to Jeremy for further review and to carry it to completion. (Jeremy, if you're swamped, please find someone else to do it.) Re normpath: my mistake -- I meant normcase. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101702&group_id=5470 From noreply@sourceforge.net Fri Jan 19 00:03:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 16:03:42 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14JP1q-000573-00@usw-sf-web1.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : nascheme Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-18 16:03 By: loewis Comment: The patch looks ok in general, pending resolution of the issues on the PEP itself. Some nits: Integration with GC is still fuzzy. If an instance is GC collected and had a weak ref to it and the weak ref had a callback and the callback choses to resurrect the object, semantics is unclear. This is equivalent to the object having an __del__; the GC would normally *not* collect such objects, but put them into gc.garbage. Proposed resolution: it is a fatal error to resurrect an object in a weakref callback. Hashing: it appears that the hash of a weakref can change when the underlying object goes away. If the weakref is used as key in a dictionary, it appears to be impossible to get the key out of the dictionary after the underlying object is gone. Proposed resolution: a proxy weak ref should cache the hash of the underlying object after its hash function was called for the first time. Comparing: why is the return value of tp_compare -1 when try_3way_compare expects -2 on error? Shouldn't there be some exception set when the underlying object goes away? ------------------------------------------------------- Date: 2001-Jan-17 13:53 By: fdrake Comment: Ok, I tihnk this is it! http://starship.python.net/crew/fdrake/patches/weakref.patch-5 This patch fixes the compilation problems from the previoous patch related to the introduction of rich comparisons, and makes a change in the way new objects are initialized by PyObject_New() and PyObject_NEW() (and all their friends!) -- those functions now know to initialize the weak reference list to NULL for objects which support weak references. Without this change, more places in the code (especially extension modules) need to know more about initialization of weakly-referencable objects. For instance, the "cPickle" and "new" modules both can create instances without calling the code in classobject.c (using PyObject_New()), causing core dumps when such instances are deallocated if the weak-reference list for instances was not properly initialized. Since these modules (properly) tried to avoid call PyInstance_New(), core dumps ensued and the world fell apart. By moving the initialization of the weak reference list into the core object allocators, this problem is averted and extension code to construct new weakly referencable types is simplified. The documentation still needs work, and there are a few new entries for the Python/C API manual as well. A new constructor for instances, PyInstance_NewRaw(), will be added in a separate patch. ------------------------------------------------------- Date: 2001-Jan-17 11:58 By: nascheme Comment: The magic test is: ./python Lib/test/regrtest.py test_weakref test_new Try adding this patch: --- Modules/newmodule.c 2000/11/13 20:29:20 2.29 +++ Modules/newmodule.c 2001/01/17 19:55:46 @@ -24,6 +24,7 @@ Py_INCREF(dict); inst->in_class = (PyClassObject *)klass; inst->in_dict = dict; + inst->in_weakreflist = NULL; PyObject_GC_Init(inst); return (PyObject *)inst; } ------------------------------------------------------- Date: 2001-Jan-17 08:04 By: fdrake Comment: New version of the patch that's still broken but doesn't conflict with the rich comparisons changes: http://starship.python.net/crew/fdrake/patches/weakref.patch-4 ------------------------------------------------------- Date: 2001-Jan-16 21:35 By: fdrake Comment: Added a new (but broken!) version of the patch that fixes WeakDictionary.get() but doesn't interact properly with GC (appearantly) -- not usable as is: http://starship.python.net/crew/fdrake/patches/weakref.patch-3 Neil made the mistake of volunteering to look at the current problem, so assigning to him. (Thanks!) ------------------------------------------------------- Date: 2001-Jan-16 19:39 By: tim_one Comment: Just mentioning a general scenario in which weak keys are the bee's knees: sometimes you want to add attributes to objects dynamically, in ways the original class author(s -- may cut across many classes! even non-instance objects; or objects from extension modules that don't support setattr) never anticipated. Like maybe a German translation of the object's docstrings; or a list of JPEG contents referenced by a URLish object; or a table of usage statistics on methods and functions; etc. Then it's natural to use the conceptual attr name as the name of a dict instead, and write attr[object] = whatever instead of object.attr = whatever There's no point keeping the "whatever" around when the object goes away, but a regular dict makes the object and its "whatever" immortal. A dict with weak keys is exactly on-target. ------------------------------------------------------- Date: 2001-Jan-16 19:14 By: fdrake Comment: I'm not entirely sure why one would want weak keys rather than weak values, but I suspect it has to do with expectations of how the dict will be used in applications. I don't think it would be hard to support both flavors of dictionaries using the primitive reference objects. The constructor does not check that all incoming values are weak because that isn't required. It uses self.update() rather than self.data.update() to perform the inclusion, so any mapping that supports .keys() and .__getitem__() is sufficient. Some additional checking could be done to make sure that all added entries can be created before inserting any of them, offering more atomicity. .get() will be fixed in the next version of the patch; thanks! I've added GC support, but don't have it working quite right. I'm trying to isolate the failure now. ------------------------------------------------------- Date: 2001-Jan-12 14:36 By: loewis Comment: The weak dictionary data type needs more clarification in documentation and implementation. In java.util.WeakHashMap, they keys are weak, not the values (i.e. once the key is forgotten, the entry is cleared). In http://www.handshake.de/~dieter/weakdict.html, the values are weak, but it raises KeyErrors for entries that are collected. The initializer of a weak dict does not check the invariant (all values are weak). get() of a weakdict does not support an optional second parameter. weakref and friends need to participate in garbage collection, as the reference to the callback can create a cycle. ------------------------------------------------------- Date: 2001-Jan-12 11:27 By: fdrake Comment: Updated patch to also support proxy semantics using the same invalidation machinery as the basic weak reference type. The additional code is *heavily* borrowed from Neil Schemenauer. ------------------------------------------------------- Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Fri Jan 19 00:04:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 16:04:00 -0800 Subject: [Patches] [Patch #102891] Alternative readline module Message-ID: <E14JP28-0001ev-00@usw-sf-web2.sourceforge.net> Patch #102891 has been updated. Project: python Category: Modules Status: Open Submitted by: nascheme Assigned to : nascheme Summary: Alternative readline module Follow-Ups: Date: 2001-Jan-18 16:04 By: gvanrossum Comment: Neil, I'm assigning this back to you and reopening it (from Accepted). It seems patches with status Accepted frequently get lost -- probably because "My Patches" doesn't show them. In any case, I think you should just check this in ASAP and close the patch! ------------------------------------------------------- Date: 2001-Jan-16 06:59 By: gvanrossum Comment: Ah, of course. I saw that, even played with it a bit. Looks cool, but I don't know about using it to replace readline. But you might want to change the name given that pyrl is already taken. ;-) ------------------------------------------------------- Date: 2001-Jan-16 06:34 By: mwh Comment: pyrl is my line reader written in Python that I've been intermittently blathering about on python-dev: http://www-jcsu.jesus.cam.ac.uk/~mwh21/hacks/pyrl-0.2.0.tar.gz it's still very experimental, though. ------------------------------------------------------- Date: 2001-Jan-16 05:41 By: gvanrossum Comment: What's pyrl in this context? A Google search turns up a bunch of references to a Perl preprocessor that takes Pythonic syntax and translates it into Perl. :-) [ESR replied Neil via email: "I'm on it. Gotta ship my PC9 paper first, though."] ------------------------------------------------------- Date: 2001-Jan-16 02:23 By: mwh Comment: You could defer the decision between readline and edline until runtime, as in: (will sf mangle this? we'll see) Index: Modules/main.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/main.c,v retrieving revision 1.47 diff -c -r1.47 main.c *** Modules/main.c 2000/12/15 22:00:54 1.47 --- Modules/main.c 2001/01/16 10:19:45 *************** *** 267,274 **** isatty(fileno(stdin))) { PyObject *v; v = PyImport_ImportModule("readline"); ! if (v == NULL) PyErr_Clear(); else Py_DECREF(v); } --- 267,280 ---- isatty(fileno(stdin))) { PyObject *v; v = PyImport_ImportModule("readline"); ! if (v == NULL) { PyErr_Clear(); + v = PyImport_ImportModule("edline"); + if (v == NULL) + PyErr_Clear(); + else + Py_DECREF(v); + } else Py_DECREF(v); } (and pyrl's not going to be ready for 2.1, by a country mile...) ------------------------------------------------------- Date: 2001-Jan-15 21:30 By: nascheme Comment: Hmm, I still like pyrl better. What to do about GNU readline now that its in Setup.conf? You can't enable them both and I don't feel comfortable enough with autoconf to fix things. ESR, if you could add the magic to test for termios that would be cool. configure should use readline if its there and fall back to edline if termios is available. Feel free to bounce it back to me if you don't have time. ------------------------------------------------------- Date: 2001-Jan-03 06:10 By: gvanrossum Comment: Neil, this has now status Accepted. Go ahead and check it in! ------------------------------------------------------- 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 Fri Jan 19 00:05:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 16:05:25 -0800 Subject: [Patches] [Patch #102971] build_ext -L typo fix Message-ID: <E14JP3V-0000jg-00@usw-sf-web3.sourceforge.net> Patch #102971 has been updated. Project: python Category: distutils Status: Closed Submitted by: calvin Assigned to : akuchling Summary: build_ext -L typo fix Follow-Ups: Date: 2001-Jan-18 16:05 By: gvanrossum Comment: This was checked in alrady. ------------------------------------------------------- Date: 2001-Jan-08 19:16 By: akuchling Comment: Checked in; leaving it in "Accepted" so Greg can review it (and possibly back it out) when he gets back. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102971&group_id=5470 From noreply@sourceforge.net Fri Jan 19 00:05:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 16:05:19 -0800 Subject: [Patches] [Patch #102860] Add PyDict_Update() function to C API. Message-ID: <E14JP3P-0001fE-00@usw-sf-web2.sourceforge.net> Patch #102860 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: fdrake Assigned to : jhylton Summary: Add PyDict_Update() function to C API. Follow-Ups: Date: 2001-Jan-18 16:05 By: jhylton Comment: Oh, well. The latest version of compile.c doesn't need the subtraction, so I can't provide any motivation for this feature. ------------------------------------------------------- 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 Jan 19 00:05:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 16:05:56 -0800 Subject: [Patches] [Patch #102971] build_ext -L typo fix Message-ID: <E14JP40-0000k7-00@usw-sf-web3.sourceforge.net> Patch #102971 has been updated. Project: python Category: distutils Status: Accepted Submitted by: calvin Assigned to : akuchling Summary: build_ext -L typo fix Follow-Ups: Date: 2001-Jan-18 16:05 By: gvanrossum Comment: This was checked in alrady. ------------------------------------------------------- Date: 2001-Jan-18 16:05 By: gvanrossum Comment: This was checked in alrady. ------------------------------------------------------- Date: 2001-Jan-08 19:16 By: akuchling Comment: Checked in; leaving it in "Accepted" so Greg can review it (and possibly back it out) when he gets back. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102971&group_id=5470 From noreply@sourceforge.net Fri Jan 19 00:07:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 16:07:21 -0800 Subject: [Patches] [Patch #102863] another memory leak Message-ID: <E14JP5N-0001fk-00@usw-sf-web2.sourceforge.net> Patch #102863 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: cgw Assigned to : jhylton Summary: another memory leak Follow-Ups: Date: 2001-Jan-18 16:07 By: jhylton Comment: not relevant any longer ------------------------------------------------------- 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 Jan 19 00:07:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 16:07:54 -0800 Subject: [Patches] [Patch #103140] Minor fixes and enhancements for 2.0 docs. Message-ID: <E14JP5u-0001g9-00@usw-sf-web2.sourceforge.net> Patch #103140 has been updated. Project: python Category: documentation Status: Closed Submitted by: esr Assigned to : esr Summary: Minor fixes and enhancements for 2.0 docs. Follow-Ups: Date: 2001-Jan-18 16:07 By: gvanrossum Comment: This was checked in by Fred. ------------------------------------------------------- Date: 2001-Jan-09 14:06 By: fdrake Comment: Please check this in. Note that I will be making a couple of markup adjustments in libstat.tex after you've checked it in -- it's easier to make the changes than to describe them. ;-) Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103140&group_id=5470 From noreply@sourceforge.net Fri Jan 19 00:08:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 16:08:34 -0800 Subject: [Patches] [Patch #102971] build_ext -L typo fix Message-ID: <E14JP6Y-0000kq-00@usw-sf-web3.sourceforge.net> Patch #102971 has been updated. Project: python Category: distutils Status: Accepted Submitted by: calvin Assigned to : gward Summary: build_ext -L typo fix Follow-Ups: Date: 2001-Jan-18 16:08 By: gvanrossum Comment: Sorry. I didn't realize why Andrew left it Accepted. ------------------------------------------------------- Date: 2001-Jan-18 16:05 By: gvanrossum Comment: This was checked in alrady. ------------------------------------------------------- Date: 2001-Jan-18 16:05 By: gvanrossum Comment: This was checked in alrady. ------------------------------------------------------- Date: 2001-Jan-08 19:16 By: akuchling Comment: Checked in; leaving it in "Accepted" so Greg can review it (and possibly back it out) when he gets back. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102971&group_id=5470 From noreply@sourceforge.net Fri Jan 19 00:16:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 16:16:04 -0800 Subject: [Patches] [Patch #103283] Rich comparisons technical preview Message-ID: <E14JPDo-0005AY-00@usw-sf-web1.sourceforge.net> Patch #103283 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: gvanrossum Assigned to : gvanrossum Summary: Rich comparisons technical preview Follow-Ups: Date: 2001-Jan-18 16:16 By: gvanrossum Comment: This is all checked in. There are still loose ends, but no need to keep the patch open. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103283&group_id=5470 From noreply@sourceforge.net Fri Jan 19 00:24:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 16:24:58 -0800 Subject: [Patches] [Patch #103250] Optimize a strspn() out of startup Message-ID: <E14JPMQ-0001lT-00@usw-sf-web2.sourceforge.net> Patch #103250 has been updated. Project: python Category: None Status: Closed Submitted by: pj99 Assigned to : gvanrossum Summary: Optimize a strspn() out of startup Follow-Ups: Date: 2001-Jan-18 16:24 By: gvanrossum Comment: OK, I've applied this, and am closing the patch. It's actually disturbing that the parser uses isalnum() -- the language is not *supposed* to accept non-ASCII letters in the Latin-1 character set, but under certain circumstances, that may be the effect! ------------------------------------------------------- Date: 2001-Jan-16 21:33 By: nobody Comment: At least the Python tokenizer uses (isalnum(c) || c == '_') ... ------------------------------------------------------- Date: 2001-Jan-16 14:28 By: pj99 Comment: The (isalpha(c) || isdigit(c) || c=='_') suggestion seems to me to be the better idea. However, how does this interact with localization and unicode and such? Do we want exactly the list of specified NAME_CHARS allowed here, or do we want a localized set of alpha/digit/'_' chars allowed here? As for the other 98.5%, I have a nice table from my profiler, showing where the time is, but I don't know how to put that table here, without mangling the format. It shows about 19% of the time in malloc/free, about 15% of the time in pthread code, about 14% in dictobject.c code, and about 6% in acceler.c code (esp. fixstate()). And of course the getc() savings that come from loading an entire *.pyc file in a single fread(), as being persued in patch 103252, saves perhaps 24% of what's left. (Note, the 19,15,14 and 6 percents above are based on what's left, _after_ the 24% getc() optimization is applied). *If* much of the malloc/free use is for lots of small chunks, coming and going, as tends to happen with object based code, then I could imagine a custom allocator (based on top of malloc/free, so quite portable). This might save much of the pthread cost as well, if the custom allocator kept separate pools of small chunks of malloc'd memory, per thread, avoiding locks (if that can be done ?). I have done work in the past in a C++/mmap environment that reduced the costs of many small dynamic allocations to near zero, both space and time. But that relied on the second argument to C++ delete(), which is the size of the object being deleted, as well as on an AUTOGROW mmap region. This is not applicable to C, nor is it particularly portable. Still, something like this, perhaps requiring recoding of some critical free() calls to use an optional method that passed in a second sizeof argument, might be the next most useful optimization. Someone else in the news thread that was parent to this patch suggested emacs-like dump facility, to capture the state of the Python interpreter after it has loaded the usual suspects. But I can't imagine that this would be sufficiently portable or maintainable to be relevant. As someone who has had to maintain O.S./library support for and compatibility with this emacs dump facility, I have grown to dislike it strongly. ------------------------------------------------------- Date: 2001-Jan-15 23:25 By: nobody Comment: Why not (isalpha(c) || isdigit(c) || c=='_') ? ------------------------------------------------------- Date: 2001-Jan-15 19:35 By: gvanrossum Comment: Looks cool to me. Do you have an idea what to do about the other 98.5%? :) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103250&group_id=5470 From noreply@sourceforge.net Fri Jan 19 00:25:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 16:25:43 -0800 Subject: [Patches] [Patch #103220] Cygwin util.get_platform() fix Message-ID: <E14JPN9-0005Dh-00@usw-sf-web1.sourceforge.net> Patch #103220 has been updated. Project: python Category: distutils Status: Open Submitted by: jlt63 Assigned to : akuchling Summary: Cygwin util.get_platform() fix Follow-Ups: Date: 2001-Jan-18 16:25 By: gvanrossum Comment: Oops, this should have been assigned to Andrew. Andrew, does it look OK? Please check it in then! ------------------------------------------------------- Date: 2001-Jan-13 20:01 By: jlt63 Comment: > how is the "machine" in cygwin determined? It is derived from Window's GetSystemInfo(). See the following, if interested: http://msdn.microsoft.com/library/psdk/sysmgmt/sysinfo_3t67.htm > You seem to go with the "os-release-machine" format Not for any good reason, I was just trying to get rid of the "(0.31/3/2)" cruft. I'm willing to go with "os-release", if that is deemed more appropriate. Let me know and I will upload a revised patch. > so I assume cygwin does distinguish the machines I don't think it does -- it just reports the machine type. > but I have no idea wht the possibilities are The current list is: i[3-6]86, alpha, mips, and unknown. ------------------------------------------------------- Date: 2001-Jan-12 23:15 By: moshez Comment: Hmmmmm...only one question, since I don't have Cygwin to play with: how is the "machine" in cygwin determined? You seem to go with the "os-release-machine" format, so I assume cygwin does distinguish the machines, but I have no idea wht the possibilities are. ------------------------------------------------------- Date: 2001-Jan-12 18:32 By: jlt63 Comment: This patch adds support for Cygwin to util.get_platform(). A Cygwin specific case is needed due to the format of Cygwin's uname command: $ uname -r 1.1.7(0.31/3/2) Since the release field contains slashes, a path component name that is based on this information becomes multiple path components instead of a single one. This patch corrects this problem by only using the leading part of the release field that matches the regular expression "[\d.]+". The procedure to apply the patch is as follows: $ cd Lib/distutils $ # save util.patch to the current directory $ patch <util.patch ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103220&group_id=5470 From noreply@sourceforge.net Fri Jan 19 00:29:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 16:29:19 -0800 Subject: [Patches] [Patch #103185] Some more standard modules cleanup for Cygwin Message-ID: <E14JPQd-0005Ek-00@usw-sf-web1.sourceforge.net> Patch #103185 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Some more standard modules cleanup for Cygwin Follow-Ups: Date: 2001-Jan-18 16:29 By: gvanrossum Comment: Applied, and closed. ------------------------------------------------------- Date: 2001-Jan-10 21:19 By: jlt63 Comment: Use the following procedure to patch: $ cd Modules $ # save modules.patch to current directory $ patch <modules.patch ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103185&group_id=5470 From noreply@sourceforge.net Fri Jan 19 00:31:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 16:31:17 -0800 Subject: [Patches] [Patch #103188] BeOS/ar-fake support for extra libraries Message-ID: <E14JPSX-0001nd-00@usw-sf-web2.sourceforge.net> Patch #103188 has been updated. Project: python Category: Build Status: Closed Submitted by: donnc Assigned to : gvanrossum Summary: BeOS/ar-fake support for extra libraries Follow-Ups: Date: 2001-Jan-18 16:31 By: gvanrossum Comment: Checked in, closed. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103188&group_id=5470 From noreply@sourceforge.net Fri Jan 19 00:45:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 16:45:36 -0800 Subject: [Patches] [Patch #102980] BaseServer class for SocketServer.py (inh. by TCPServer) Message-ID: <E14JPgO-0005Jn-00@usw-sf-web1.sourceforge.net> Patch #102980 has been updated. Project: python Category: library Status: Closed Submitted by: lkcl Assigned to : gvanrossum Summary: BaseServer class for SocketServer.py (inh. by TCPServer) Follow-Ups: Date: 2001-Jan-18 16:45 By: gvanrossum Comment: Thanks, checked in, and closing this patch now. (There were a few weirdnesses with the patch, possibly caused by lost whitespace -- I think I've got it all now though.) ------------------------------------------------------- Date: 2001-Jan-03 06:14 By: gvanrossum Comment: I like this idea. I noticed that you added a copyright statement to the file. Referring to http://mail.python.org/pipermail/python-dev/2001-January/011250.html I believe that it's better not to add explicit copyright statements, because the licensing conditions are unclear in that case. I'd be happy if you included an "Author:" statement instead. ------------------------------------------------------- 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 Fri Jan 19 03:23:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 19:23:35 -0800 Subject: [Patches] [Patch #103323] trivial tests of all untested modules Message-ID: <E14JS9H-000610-00@usw-sf-web1.sourceforge.net> Patch #103323 has been updated. Project: python Category: None Status: Open Submitted by: jhylton Assigned to : tim_one Summary: trivial tests of all untested modules ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103323&group_id=5470 From noreply@sourceforge.net Fri Jan 19 04:43:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 20:43:30 -0800 Subject: [Patches] [Patch #103318] non-recursive makefile Message-ID: <E14JTOc-00033s-00@usw-sf-web2.sourceforge.net> Patch #103318 has been updated. Project: python Category: Build Status: Open Submitted by: nascheme Assigned to : nobody Summary: non-recursive makefile Follow-Ups: Date: 2001-Jan-18 20:43 By: nascheme Comment: New patch. I think makesetup works as it should. There is one issue with MAKE_LDLIBRARY on cygwin but it should be easy to fix. Object files for threads and dynamic loading show be okay now. I might be missing a few "clean" targets. I removed a bunch of "foo.o: $(srcdir)/foo.c" lines. As far as I can tell they are useless. Any make that supports VPATH should be able to figure out where to get the source. Other makes can look in the same dir as the source file. Surely they are not that broken. Guido, do you know if there was a good reason for these lines? Building with GNU make works great for any situation I can think of. pmake is not smart enough to re-read the makefile if it got updated. I don't know of any way around that. Building in a separate dir works fine. I didn't do buildno because I like to type "make" and see the prompt come back right away. What is buildno for and when should it be incremented? ------------------------------------------------------- Date: 2001-Jan-18 18:56 By: gvanrossum Comment: I'm in a quandary. This is really awesone! But a bit too rough to add to the 2.1a1 release. You don't seem to deal with buildno properly -- what's the problem there? Also, I seem to recall that the "-o file.o" option is not universal amongst C compilers. Could someone who uses a non-GCC compiler (e.g. SunPro, or HP, or AIX) check the portability of this Makefile? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103318&group_id=5470 From noreply@sourceforge.net Fri Jan 19 04:52:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 20:52:53 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: <E14JTXh-0006Wt-00@usw-sf-web1.sourceforge.net> Patch #102409 has been updated. Project: python Category: Build Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-18 20:52 By: jlt63 Comment: Please reopen because I need to redo the Cygwin build to handle the use of distutils to build the standard extension modules instead of Modules/Makefile.pre.in. How much time (if any) do I have to resolve these issues before 2.1a is released. I heard that the release date is tomorrow. Sigh... ------------------------------------------------------- Date: 2001-Jan-10 19:39 By: jlt63 Comment: Your welcome -- thanks for considering and accepting this patch. If the patch proves to reek havoc on other platforms (most likely only on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out. ------------------------------------------------------- Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 <Cygwin-1.1.5-Python-2.0.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Fri Jan 19 05:41:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 21:41:56 -0800 Subject: [Patches] [Patch #103323] trivial tests of all untested modules Message-ID: <E14JUJA-0006pO-00@usw-sf-web1.sourceforge.net> Patch #103323 has been updated. Project: python Category: library Status: Closed Submitted by: jhylton Assigned to : tim_one Summary: trivial tests of all untested modules Follow-Ups: Date: 2001-Jan-18 21:41 By: tim_one Comment: Clearly this is an excellent idea! Unsure why you didn't just check it in. So I did. Note that I commented out the imports of "curses" and "rlcompleter", because those can't be imported on Windows (relying on _curses and readline, respectively). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103323&group_id=5470 From noreply@sourceforge.net Fri Jan 19 09:41:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 01:41:19 -0800 Subject: [Patches] [Patch #103329] Update poplib to use re Message-ID: <E14JY2p-0007yz-00@usw-sf-web1.sourceforge.net> Patch #103329 has been updated. Project: python Category: library Status: Open Submitted by: moshez Assigned to : nobody Summary: Update poplib to use re ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103329&group_id=5470 From noreply@sourceforge.net Fri Jan 19 09:43:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 01:43:43 -0800 Subject: [Patches] [Patch #103329] Update poplib to use re Message-ID: <E14JY59-0007zr-00@usw-sf-web1.sourceforge.net> Patch #103329 has been updated. Project: python Category: library Status: Open Submitted by: moshez Assigned to : jhylton Summary: Update poplib to use re ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103329&group_id=5470 From lkcl@samba.org Fri Jan 19 10:12:04 2001 From: lkcl@samba.org (Luke Kenneth Casson Leighton) Date: Fri, 19 Jan 2001 21:12:04 +1100 Subject: [Patches] Re: [Patch #102980] BaseServer class for SocketServer.py (inh. by TCPServer) In-Reply-To: <E14JPgO-0005Jn-00@usw-sf-web1.sourceforge.net> Message-ID: <Pine.SGI.4.05.10101192110050.24116-100000@samba.org> On Thu, 18 Jan 2001 noreply@sourceforge.net wrote: > Patch #102980 has been updated. > > Project: python > Category: library > Status: Closed > Submitted by: lkcl > Assigned to : gvanrossum > Summary: BaseServer class for SocketServer.py (inh. by TCPServer) > > Follow-Ups: > > Date: 2001-Jan-18 16:45 > By: gvanrossum > > Comment: > Thanks, checked in, and closing this patch now. great. you got my message about hi, yes you can have copyright for the patch and authorship remains me, neh? > (There were a few weirdnesses with the patch, possibly caused by lost > whitespace -- I think I've got it all now though.) yes, i had to hand-paste it into the dialog box on sourceforge. > ------------------------------------------------------- > > Date: 2001-Jan-03 06:14 > By: gvanrossum > > Comment: > I like this idea. > > I noticed that you added a copyright statement to the file. Referring to > > http://mail.python.org/pipermail/python-dev/2001-January/011250.html > > I believe that it's better not to add explicit copyright statements, > because the licensing conditions are unclear in that case. I'd be happy if > you included an "Author:" statement instead. > ------------------------------------------------------- From noreply@sourceforge.net Fri Jan 19 15:53:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 07:53:42 -0800 Subject: [Patches] [Patch #101702] Modify co_filename in frozen programs Message-ID: <E14JdrC-0001cB-00@usw-sf-web1.sourceforge.net> Patch #101702 has been updated. Project: python Category: demos and tools Status: Open Submitted by: lhudson Assigned to : gvanrossum Summary: Modify co_filename in frozen programs Follow-Ups: Date: 2001-Jan-19 07:53 By: gvanrossum Comment: I'm taking this, on the assumption that Mark's too busy and freeze is our shared responsibility. ------------------------------------------------------- Date: 2001-Jan-18 15:57 By: jhylton Comment: (somewhat) randomly reassigned; don't have time to look at this ------------------------------------------------------- Date: 2000-Sep-29 04:39 By: lhudson Comment: A new feature for freeze. This patch was developed primarily to reduce the size of the frozen binary. It is particularly useful when freezing for 'small' platforms, such as Palm OS, where you really want to save that last miserable byte. A limitation of this patch is that it does not provide any feedback about the replacements being made. As the path matching is case-sensitive this may lead to unexpected behaviour for DOS and Windows people, eg > freeze.py -r C:\Python\Lib\=py\ goats.py should probably be: > freeze.py -r c:\python\lib\=py\ goats.py ------------------------------------------------------- Date: 2000-Sep-29 07:28 By: jhylton Comment: This sounds like a reasonable enough feature, but we are in feature freeze for Python 2.0. ------------------------------------------------------- Date: 2000-Oct-23 12:33 By: gvanrossum Comment: I like the idea, but I have a few suggestions. - To avoid the case sensitivity issue you mention, you could use os.path.normpath() before the string comparisons. - Rather than writing to a real temporary file, you could marshal to a string and than unmarshal from a StringIO file. - And the big whopper: rather than using a modified version of unmarshal, I suggest writing a recursive code object transformer. It takes a code object and a replace_paths list, and returns a similar code object with the co_filename attribute changed according to the list. The trick is that it should also do this, recursively, to any code object found in the co_consts tuple. (That's the only place where code objects can occur recursively.) While this is probably not much less code than the marshaller you wrote, it has the advantage of not being dependent on the details of the marshal format. Please upload a new patch -- I'm interested in getting this into Python 2.1. ------------------------------------------------------- Date: 2000-Oct-25 01:36 By: lhudson Comment: A recursive code object transformer has been implemented as a member of the ModuleFinder. Case sensitivity issue: normpath strips trailing '/' or '\\' which reduces the flexibility of the path replacement. It also does not seem to solve the case-sensitivity problem: D:\>python Python 2.0 (#8, Oct 17 2000, 15:27:24) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import os >>> os.path.normpath("c:\\python\\lib\\") 'c:\\python\\lib' >>> os.path.normpath("c:\\python\\Lib\\") 'c:\\python\\Lib' >>> ModuleFinder's debugging system is used to report the status of each unique path encountered. Temporary file: marshal.dump() and marshal.load() only work with file objects, not file-like objects. Now that new code objects are being created there is no longer any reason to re-marshal so this problem disappears. ------------------------------------------------------- Date: 2000-Oct-25 04:19 By: gvanrossum Comment: Thanks for the new patch! I'll assign this to Jeremy for further review and to carry it to completion. (Jeremy, if you're swamped, please find someone else to do it.) Re normpath: my mistake -- I meant normcase. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101702&group_id=5470 From noreply@sourceforge.net Fri Jan 19 16:19:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 08:19:31 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: <E14JeGB-0001mE-00@usw-sf-web1.sourceforge.net> Patch #102409 has been updated. Project: python Category: Build Status: Open Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-19 08:19 By: gvanrossum Comment: Reopened at request. Don't sweat the release date -- t's only the first alpha release. I have a feeling it'll be put off till Monday. ------------------------------------------------------- Date: 2001-Jan-18 20:52 By: jlt63 Comment: Please reopen because I need to redo the Cygwin build to handle the use of distutils to build the standard extension modules instead of Modules/Makefile.pre.in. How much time (if any) do I have to resolve these issues before 2.1a is released. I heard that the release date is tomorrow. Sigh... ------------------------------------------------------- Date: 2001-Jan-10 19:39 By: jlt63 Comment: Your welcome -- thanks for considering and accepting this patch. If the patch proves to reek havoc on other platforms (most likely only on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out. ------------------------------------------------------- Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 <Cygwin-1.1.5-Python-2.0.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Fri Jan 19 16:26:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 08:26:36 -0800 Subject: [Patches] [Patch #103220] Cygwin util.get_platform() fix Message-ID: <E14JeN2-0005vH-00@usw-sf-web3.sourceforge.net> Patch #103220 has been updated. Project: python Category: distutils Status: Closed Submitted by: jlt63 Assigned to : akuchling Summary: Cygwin util.get_platform() fix Follow-Ups: Date: 2001-Jan-19 08:26 By: akuchling Comment: Since it only affects the results on the Cygwin platform and have no way of testing it, I'll assume it's correct for that platform. Checked in. ------------------------------------------------------- Date: 2001-Jan-18 16:25 By: gvanrossum Comment: Oops, this should have been assigned to Andrew. Andrew, does it look OK? Please check it in then! ------------------------------------------------------- Date: 2001-Jan-13 20:01 By: jlt63 Comment: > how is the "machine" in cygwin determined? It is derived from Window's GetSystemInfo(). See the following, if interested: http://msdn.microsoft.com/library/psdk/sysmgmt/sysinfo_3t67.htm > You seem to go with the "os-release-machine" format Not for any good reason, I was just trying to get rid of the "(0.31/3/2)" cruft. I'm willing to go with "os-release", if that is deemed more appropriate. Let me know and I will upload a revised patch. > so I assume cygwin does distinguish the machines I don't think it does -- it just reports the machine type. > but I have no idea wht the possibilities are The current list is: i[3-6]86, alpha, mips, and unknown. ------------------------------------------------------- Date: 2001-Jan-12 23:15 By: moshez Comment: Hmmmmm...only one question, since I don't have Cygwin to play with: how is the "machine" in cygwin determined? You seem to go with the "os-release-machine" format, so I assume cygwin does distinguish the machines, but I have no idea wht the possibilities are. ------------------------------------------------------- Date: 2001-Jan-12 18:32 By: jlt63 Comment: This patch adds support for Cygwin to util.get_platform(). A Cygwin specific case is needed due to the format of Cygwin's uname command: $ uname -r 1.1.7(0.31/3/2) Since the release field contains slashes, a path component name that is based on this information becomes multiple path components instead of a single one. This patch corrects this problem by only using the leading part of the release field that matches the regular expression "[\d.]+". The procedure to apply the patch is as follows: $ cd Lib/distutils $ # save util.patch to the current directory $ patch <util.patch ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103220&group_id=5470 From noreply@sourceforge.net Fri Jan 19 16:34:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 08:34:30 -0800 Subject: [Patches] [Patch #103329] Update poplib to use re Message-ID: <E14JeUg-0006p7-00@usw-sf-web2.sourceforge.net> Patch #103329 has been updated. Project: python Category: library Status: Accepted Submitted by: moshez Assigned to : jhylton Summary: Update poplib to use re Follow-Ups: Date: 2001-Jan-19 08:34 By: akuchling Comment: The patch looks correct after a quick reading. Moshe, go ahead and check it in. (Bonus points if you can actually test it against a POP server.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103329&group_id=5470 From guido@digicool.com Fri Jan 19 16:45:04 2001 From: guido@digicool.com (Guido van Rossum) Date: Fri, 19 Jan 2001 11:45:04 -0500 Subject: [Patches] Re: [Patch #102980] BaseServer class for SocketServer.py (inh. by TCPServer) In-Reply-To: Your message of "Fri, 19 Jan 2001 21:12:04 +1100." <Pine.SGI.4.05.10101192110050.24116-100000@samba.org> References: <Pine.SGI.4.05.10101192110050.24116-100000@samba.org> Message-ID: <200101191645.LAA29383@cj20424-a.reston1.va.home.com> > > Thanks, checked in, and closing this patch now. > > great. you got my message about hi, yes you can have copyright for the > patch and authorship remains me, neh? Yes, got it. I've added a note about your authorship of the patch to the source file now. > > (There were a few weirdnesses with the patch, possibly caused by lost > > whitespace -- I think I've got it all now though.) > > yes, i had to hand-paste it into the dialog box on sourceforge. Ah, that explains. --Guido van Rossum (home page: http://www.python.org/~guido/) From lkcl@samba.org Fri Jan 19 17:42:01 2001 From: lkcl@samba.org (Luke Kenneth Casson Leighton) Date: Sat, 20 Jan 2001 04:42:01 +1100 Subject: [Patches] Re: [Patch #102980] BaseServer class for SocketServer.py (inh. by TCPServer) In-Reply-To: <200101191645.LAA29383@cj20424-a.reston1.va.home.com> Message-ID: <Pine.SGI.4.05.10101200440180.7983-100000@samba.org> On Fri, 19 Jan 2001, Guido van Rossum wrote: > > > Thanks, checked in, and closing this patch now. > > > > great. you got my message about hi, yes you can have copyright for the > > patch and authorship remains me, neh? > > Yes, got it. I've added a note about your authorship of the patch to > the source file now. you want me to create a BaseServer.py? with: import SocketServer class ThreadedMixIn(SocketServer.ThreadedMixIn): """ legacy redirection """ pass etc. ? and have BaseServer class in BaseServer.py? From noreply@sourceforge.net Fri Jan 19 18:11:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 10:11:39 -0800 Subject: [Patches] [Patch #103329] Update poplib to use re Message-ID: <E14Jg0h-0007Nz-00@usw-sf-web2.sourceforge.net> Patch #103329 has been updated. Project: python Category: library Status: Accepted Submitted by: moshez Assigned to : moshez Summary: Update poplib to use re Follow-Ups: Date: 2001-Jan-19 10:11 By: gvanrossum Comment: Assigned to Moshe. Thanks! Please check in ASAP! ------------------------------------------------------- Date: 2001-Jan-19 08:34 By: akuchling Comment: The patch looks correct after a quick reading. Moshe, go ahead and check it in. (Bonus points if you can actually test it against a POP server.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103329&group_id=5470 From noreply@sourceforge.net Fri Jan 19 18:13:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 10:13:03 -0800 Subject: [Patches] [Patch #103318] non-recursive makefile Message-ID: <E14Jg23-0002Qd-00@usw-sf-web1.sourceforge.net> Patch #103318 has been updated. Project: python Category: Build Status: Open Submitted by: nascheme Assigned to : nobody Summary: non-recursive makefile Follow-Ups: Date: 2001-Jan-19 10:13 By: nascheme Comment: Fix silly bug ("! test -f" instead of "test ! -f" in configure.in). ------------------------------------------------------- Date: 2001-Jan-18 20:43 By: nascheme Comment: New patch. I think makesetup works as it should. There is one issue with MAKE_LDLIBRARY on cygwin but it should be easy to fix. Object files for threads and dynamic loading show be okay now. I might be missing a few "clean" targets. I removed a bunch of "foo.o: $(srcdir)/foo.c" lines. As far as I can tell they are useless. Any make that supports VPATH should be able to figure out where to get the source. Other makes can look in the same dir as the source file. Surely they are not that broken. Guido, do you know if there was a good reason for these lines? Building with GNU make works great for any situation I can think of. pmake is not smart enough to re-read the makefile if it got updated. I don't know of any way around that. Building in a separate dir works fine. I didn't do buildno because I like to type "make" and see the prompt come back right away. What is buildno for and when should it be incremented? ------------------------------------------------------- Date: 2001-Jan-18 18:56 By: gvanrossum Comment: I'm in a quandary. This is really awesone! But a bit too rough to add to the 2.1a1 release. You don't seem to deal with buildno properly -- what's the problem there? Also, I seem to recall that the "-o file.o" option is not universal amongst C compilers. Could someone who uses a non-GCC compiler (e.g. SunPro, or HP, or AIX) check the portability of this Makefile? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103318&group_id=5470 From guido@digicool.com Fri Jan 19 18:19:39 2001 From: guido@digicool.com (Guido van Rossum) Date: Fri, 19 Jan 2001 13:19:39 -0500 Subject: [Patches] Re: [Patch #102980] BaseServer class for SocketServer.py (inh. by TCPServer) In-Reply-To: Your message of "Sat, 20 Jan 2001 04:42:01 +1100." <Pine.SGI.4.05.10101200440180.7983-100000@samba.org> References: <Pine.SGI.4.05.10101200440180.7983-100000@samba.org> Message-ID: <200101191819.NAA02148@cj20424-a.reston1.va.home.com> > you want me to create a BaseServer.py? > > with: > > import SocketServer > > class ThreadedMixIn(SocketServer.ThreadedMixIn): > """ legacy redirection """ > pass > > etc. > > ? > > and have BaseServer class in BaseServer.py? Hm, I think it's fine the way it is. Anyway, don't want to think about it until after the 2.1a1 release. :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From noreply@sourceforge.net Fri Jan 19 19:43:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 11:43:38 -0800 Subject: [Patches] [Patch #103305] function attribute segfault Message-ID: <E14JhRi-0006yM-00@usw-sf-web3.sourceforge.net> Patch #103305 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: greg_ball Assigned to : bwarsaw Summary: function attribute segfault Follow-Ups: Date: 2001-Jan-19 11:43 By: bwarsaw Comment: Attached is a new version of this patch, which I'm about to check in. greg_ball's patch and discovery of the bug was excellent, but there were a few other things to clean up in the file too (crashing on del f.func_defaults, raising the wrong exception when del'ing a non-existant attribute). Applying and closing. ------------------------------------------------------- Date: 2001-Jan-18 17:57 By: gvanrossum Comment: This is a high priority patch -- needs to be deal with before 2.1a1 can go out. ------------------------------------------------------- Date: 2001-Jan-18 13:30 By: bwarsaw Comment: Assigning this to me to look at later. ------------------------------------------------------- Date: 2001-Jan-17 14:51 By: greg_ball Comment: I have ready a new version of the patch (I won't upload it yet in case it's not welcome) which does the following: reference to f.__dict__ or f.func_dict returns a new dictionary if f did not previously have one. (Similar to what happens on first assignent to arbitrary attribute.) Then the following code works: >>> def f(): pass ... >>> d=f.__dict__ >>> f.a=1 >>> d['a'] 1 instead of d being an unsubscriptable object. To me it seems nasty if somethings __dict__ attribute might not be a dictionary. Since f.__dict__ never now _appears_ to be None, I also removed the feature of assigning it to None to get rid of it. del f.__dict__ can now be used for this purpose. (previously only for creating sig11 =) ) One other thought: as it stands, function attributes are strangely behaving in restricted mode. You can't set any attributes directly. You can't directly get attributes that don't start with an underscore. However, you can get __dict__ and then do anything you like to it... ------------------------------------------------------- Date: 2001-Jan-17 14:03 By: greg_ball Comment: At two points, the code did not check for NULL, leading to segmentation fault soon after. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103305&group_id=5470 From noreply@sourceforge.net Fri Jan 19 19:45:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 11:45:07 -0800 Subject: [Patches] [Patch #103305] function attribute segfault Message-ID: <E14JhT9-0006yo-00@usw-sf-web3.sourceforge.net> Patch #103305 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: greg_ball Assigned to : bwarsaw Summary: function attribute segfault Follow-Ups: Date: 2001-Jan-19 11:45 By: bwarsaw Comment: Oops, I forgot to write out the new patch. Here 'tis for the historical record. ------------------------------------------------------- Date: 2001-Jan-19 11:43 By: bwarsaw Comment: Attached is a new version of this patch, which I'm about to check in. greg_ball's patch and discovery of the bug was excellent, but there were a few other things to clean up in the file too (crashing on del f.func_defaults, raising the wrong exception when del'ing a non-existant attribute). Applying and closing. ------------------------------------------------------- Date: 2001-Jan-18 17:57 By: gvanrossum Comment: This is a high priority patch -- needs to be deal with before 2.1a1 can go out. ------------------------------------------------------- Date: 2001-Jan-18 13:30 By: bwarsaw Comment: Assigning this to me to look at later. ------------------------------------------------------- Date: 2001-Jan-17 14:51 By: greg_ball Comment: I have ready a new version of the patch (I won't upload it yet in case it's not welcome) which does the following: reference to f.__dict__ or f.func_dict returns a new dictionary if f did not previously have one. (Similar to what happens on first assignent to arbitrary attribute.) Then the following code works: >>> def f(): pass ... >>> d=f.__dict__ >>> f.a=1 >>> d['a'] 1 instead of d being an unsubscriptable object. To me it seems nasty if somethings __dict__ attribute might not be a dictionary. Since f.__dict__ never now _appears_ to be None, I also removed the feature of assigning it to None to get rid of it. del f.__dict__ can now be used for this purpose. (previously only for creating sig11 =) ) One other thought: as it stands, function attributes are strangely behaving in restricted mode. You can't set any attributes directly. You can't directly get attributes that don't start with an underscore. However, you can get __dict__ and then do anything you like to it... ------------------------------------------------------- Date: 2001-Jan-17 14:03 By: greg_ball Comment: At two points, the code did not check for NULL, leading to segmentation fault soon after. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103305&group_id=5470 From noreply@sourceforge.net Fri Jan 19 19:46:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 11:46:15 -0800 Subject: [Patches] [Patch #103305] function attribute segfault Message-ID: <E14JhUF-0006zU-00@usw-sf-web3.sourceforge.net> Patch #103305 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: greg_ball Assigned to : bwarsaw Summary: function attribute segfault Follow-Ups: Date: 2001-Jan-19 11:46 By: bwarsaw Comment: Sorry, one more try. ------------------------------------------------------- Date: 2001-Jan-19 11:45 By: bwarsaw Comment: Oops, I forgot to write out the new patch. Here 'tis for the historical record. ------------------------------------------------------- Date: 2001-Jan-19 11:43 By: bwarsaw Comment: Attached is a new version of this patch, which I'm about to check in. greg_ball's patch and discovery of the bug was excellent, but there were a few other things to clean up in the file too (crashing on del f.func_defaults, raising the wrong exception when del'ing a non-existant attribute). Applying and closing. ------------------------------------------------------- Date: 2001-Jan-18 17:57 By: gvanrossum Comment: This is a high priority patch -- needs to be deal with before 2.1a1 can go out. ------------------------------------------------------- Date: 2001-Jan-18 13:30 By: bwarsaw Comment: Assigning this to me to look at later. ------------------------------------------------------- Date: 2001-Jan-17 14:51 By: greg_ball Comment: I have ready a new version of the patch (I won't upload it yet in case it's not welcome) which does the following: reference to f.__dict__ or f.func_dict returns a new dictionary if f did not previously have one. (Similar to what happens on first assignent to arbitrary attribute.) Then the following code works: >>> def f(): pass ... >>> d=f.__dict__ >>> f.a=1 >>> d['a'] 1 instead of d being an unsubscriptable object. To me it seems nasty if somethings __dict__ attribute might not be a dictionary. Since f.__dict__ never now _appears_ to be None, I also removed the feature of assigning it to None to get rid of it. del f.__dict__ can now be used for this purpose. (previously only for creating sig11 =) ) One other thought: as it stands, function attributes are strangely behaving in restricted mode. You can't set any attributes directly. You can't directly get attributes that don't start with an underscore. However, you can get __dict__ and then do anything you like to it... ------------------------------------------------------- Date: 2001-Jan-17 14:03 By: greg_ball Comment: At two points, the code did not check for NULL, leading to segmentation fault soon after. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103305&group_id=5470 From noreply@sourceforge.net Fri Jan 19 20:00:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 12:00:34 -0800 Subject: [Patches] [Patch #103329] Update poplib to use re Message-ID: <E14Jhi6-0007xa-00@usw-sf-web2.sourceforge.net> Patch #103329 has been updated. Project: python Category: library Status: Accepted Submitted by: moshez Assigned to : moshez Summary: Update poplib to use re Follow-Ups: Date: 2001-Jan-19 12:00 By: moshez Comment: Checked in as version 1.12, beating the 3pm on Friday rule by 3 minutes. Unfortunately, my POP server doesn't support APOP, so please give it good testing. ------------------------------------------------------- Date: 2001-Jan-19 10:11 By: gvanrossum Comment: Assigned to Moshe. Thanks! Please check in ASAP! ------------------------------------------------------- Date: 2001-Jan-19 08:34 By: akuchling Comment: The patch looks correct after a quick reading. Moshe, go ahead and check it in. (Bonus points if you can actually test it against a POP server.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103329&group_id=5470 From noreply@sourceforge.net Fri Jan 19 20:16:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 12:16:39 -0800 Subject: [Patches] [Patch #101485] Patch to test sendmail virtual domain gid's for bug #114235 Message-ID: <E14Jhxf-00082W-00@usw-sf-web2.sourceforge.net> Patch #101485 has been updated. Project: python Category: None Status: Closed Submitted by: bwarsaw Assigned to : bwarsaw Summary: Patch to test sendmail virtual domain gid's for bug #114235 Follow-Ups: Date: 2001-Jan-19 12:16 By: bwarsaw Comment: This patch has nothing to do with Python. ------------------------------------------------------- Date: 2000-Sep-12 15:22 By: bwarsaw Comment: See SF bug #114235 for what this program tests. This patch (and the bug) really have nothing to do with Python, I believe. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101485&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:44:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:44:21 -0800 Subject: [Patches] [Patch #103318] non-recursive makefile Message-ID: <E14JkGb-0003pf-00@usw-sf-web1.sourceforge.net> Patch #103318 has been updated. Project: python Category: Build Status: Open Submitted by: nascheme Assigned to : nascheme Summary: non-recursive makefile Follow-Ups: Date: 2001-Jan-19 14:44 By: gvanrossum Comment: Let's put this off until after the 2.1a1 release. It should go into 2.1a2 though, and probably should be checked in soon after 2.1a1 is released. ------------------------------------------------------- Date: 2001-Jan-19 10:13 By: nascheme Comment: Fix silly bug ("! test -f" instead of "test ! -f" in configure.in). ------------------------------------------------------- Date: 2001-Jan-18 20:43 By: nascheme Comment: New patch. I think makesetup works as it should. There is one issue with MAKE_LDLIBRARY on cygwin but it should be easy to fix. Object files for threads and dynamic loading show be okay now. I might be missing a few "clean" targets. I removed a bunch of "foo.o: $(srcdir)/foo.c" lines. As far as I can tell they are useless. Any make that supports VPATH should be able to figure out where to get the source. Other makes can look in the same dir as the source file. Surely they are not that broken. Guido, do you know if there was a good reason for these lines? Building with GNU make works great for any situation I can think of. pmake is not smart enough to re-read the makefile if it got updated. I don't know of any way around that. Building in a separate dir works fine. I didn't do buildno because I like to type "make" and see the prompt come back right away. What is buildno for and when should it be incremented? ------------------------------------------------------- Date: 2001-Jan-18 18:56 By: gvanrossum Comment: I'm in a quandary. This is really awesone! But a bit too rough to add to the 2.1a1 release. You don't seem to deal with buildno properly -- what's the problem there? Also, I seem to recall that the "-o file.o" option is not universal amongst C compilers. Could someone who uses a non-GCC compiler (e.g. SunPro, or HP, or AIX) check the portability of this Makefile? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103318&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:45:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:45:39 -0800 Subject: [Patches] [Patch #101702] Modify co_filename in frozen programs Message-ID: <E14JkHr-0007yE-00@usw-sf-web3.sourceforge.net> Patch #101702 has been updated. Project: python Category: demos and tools Status: Open Submitted by: lhudson Assigned to : gvanrossum Summary: Modify co_filename in frozen programs Follow-Ups: Date: 2001-Jan-19 14:45 By: gvanrossum Comment: No time to review this before the 2.1a1 release; I'll do this for 2.1a2. ------------------------------------------------------- Date: 2001-Jan-19 07:53 By: gvanrossum Comment: I'm taking this, on the assumption that Mark's too busy and freeze is our shared responsibility. ------------------------------------------------------- Date: 2001-Jan-18 15:57 By: jhylton Comment: (somewhat) randomly reassigned; don't have time to look at this ------------------------------------------------------- Date: 2000-Sep-29 04:39 By: lhudson Comment: A new feature for freeze. This patch was developed primarily to reduce the size of the frozen binary. It is particularly useful when freezing for 'small' platforms, such as Palm OS, where you really want to save that last miserable byte. A limitation of this patch is that it does not provide any feedback about the replacements being made. As the path matching is case-sensitive this may lead to unexpected behaviour for DOS and Windows people, eg > freeze.py -r C:\Python\Lib\=py\ goats.py should probably be: > freeze.py -r c:\python\lib\=py\ goats.py ------------------------------------------------------- Date: 2000-Sep-29 07:28 By: jhylton Comment: This sounds like a reasonable enough feature, but we are in feature freeze for Python 2.0. ------------------------------------------------------- Date: 2000-Oct-23 12:33 By: gvanrossum Comment: I like the idea, but I have a few suggestions. - To avoid the case sensitivity issue you mention, you could use os.path.normpath() before the string comparisons. - Rather than writing to a real temporary file, you could marshal to a string and than unmarshal from a StringIO file. - And the big whopper: rather than using a modified version of unmarshal, I suggest writing a recursive code object transformer. It takes a code object and a replace_paths list, and returns a similar code object with the co_filename attribute changed according to the list. The trick is that it should also do this, recursively, to any code object found in the co_consts tuple. (That's the only place where code objects can occur recursively.) While this is probably not much less code than the marshaller you wrote, it has the advantage of not being dependent on the details of the marshal format. Please upload a new patch -- I'm interested in getting this into Python 2.1. ------------------------------------------------------- Date: 2000-Oct-25 01:36 By: lhudson Comment: A recursive code object transformer has been implemented as a member of the ModuleFinder. Case sensitivity issue: normpath strips trailing '/' or '\\' which reduces the flexibility of the path replacement. It also does not seem to solve the case-sensitivity problem: D:\>python Python 2.0 (#8, Oct 17 2000, 15:27:24) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import os >>> os.path.normpath("c:\\python\\lib\\") 'c:\\python\\lib' >>> os.path.normpath("c:\\python\\Lib\\") 'c:\\python\\Lib' >>> ModuleFinder's debugging system is used to report the status of each unique path encountered. Temporary file: marshal.dump() and marshal.load() only work with file objects, not file-like objects. Now that new code objects are being created there is no longer any reason to re-marshal so this problem disappears. ------------------------------------------------------- Date: 2000-Oct-25 04:19 By: gvanrossum Comment: Thanks for the new patch! I'll assign this to Jeremy for further review and to carry it to completion. (Jeremy, if you're swamped, please find someone else to do it.) Re normpath: my mistake -- I meant normcase. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101702&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:46:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:46:37 -0800 Subject: [Patches] [Patch #100938] [Draft] libpython as shared library (.so) on Linux Message-ID: <E14JkIn-0003qH-00@usw-sf-web1.sourceforge.net> Patch #100938 has been updated. Project: python Category: None Status: Open Submitted by: flight Assigned to : nascheme Summary: [Draft] libpython as shared library (.so) on Linux Follow-Ups: Date: 2001-Jan-19 14:46 By: gvanrossum Comment: I'm reassigning this to Neil. Neil, can you see if you can integrate this into your flat Makefile? ------------------------------------------------------- Date: 2001-Jan-17 15:09 By: gvanrossum Comment: Andrew, I'm tentatively reassigning this to you, since you're taking charge of the build process at the moment (setup.py). I suspect that the patch no longer works as is -- would it make sense to mark it postponed and get the author to submit a new version before we release 2.1a1? ------------------------------------------------------- Date: 2001-Jan-17 14:46 By: nobody Comment: Getting this patch into the next version of Python would be "A Good Thing"(tm) in my opinion. We use libpython as a .so at ILM and end up having to make changes like this by hand every time we get a new version... ------------------------------------------------------- Date: 2000-Jul-19 14:10 By: flight Comment: This is what it used in product to build libpython as shared library(.so) for Debian. Note: This patch is not ready for inclusion in the upstream Python distribution. Anyway, I think this might be a start. The Python 1.5 executable in Debian GNU/Linux is built against a shared libpython1.5.so since April 1999, and I haven't yet heard about any problems. Using a shared library should have an advantage if you're running multiple instances of Python (be it standalone interpreter or embedded applications). ------------------------------------------------------- Date: 2000-Aug-15 10:52 By: tim_one Comment: Assigned to Barry because he's a Linux weenie. Barry, if you think there's something here that should go into 2.0, please pursue it now, else change the status to Postponed. ------------------------------------------------------- Date: 2000-Aug-16 00:40 By: moshez Comment: I suggest we postpone it. It isn't really complete (only works on real distributions <wink>), and the complete solution should work on all unices. If Tcl/Perl can do it, there is no reason Python can't -- and a half hearted solution isn't that good. flight, you should use this for the Python in woody in the mean time -- I doubt woody will be stable before Python 2.1 comes out, so 2.1 sounds like a good timeframe to do it. ------------------------------------------------------- Date: 2000-Aug-23 09:26 By: jhylton Comment: In the absence of anyone arguing for inclusion of this patch and a one-week idle period, it is postponed. ------------------------------------------------------- Date: 2000-Oct-26 14:13 By: gvanrossum Comment: Let's give this to Jeremy instead, because he seems to know more about build issues. Jeremy, it would be good to look into getting this to work with your RPM suite. Flight's argument (has been used without complaints in Debian Python 1.5.2 since 1999) is good. ------------------------------------------------------- Date: 2000-Nov-01 03:32 By: moshez Comment: I've had a look at the patch, and it seems it has two orthogonal parts. One is adding the infrastructure for compiling another version for the Python library, which can be more or less integrated as-is, and one is hard-coding the particular way, in Linux, of building shared objects. Since we discover how to build shared objects in the configure script anyway (otherwise we could not have built modules as shared objects), we should embed that information there, not the Linux flags. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100938&group_id=5470 From noreply@sourceforge.net Fri Jan 19 23:18:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 15:18:54 -0800 Subject: [Patches] [Patch #103265] Let time functions default to 'now' (where it makes sense) Message-ID: <E14Jko2-0000aF-00@usw-sf-web2.sourceforge.net> Patch #103265 has been updated. Project: python Category: Modules Status: Closed Submitted by: twouters Assigned to : twouters Summary: Let time functions default to 'now' (where it makes sense) Follow-Ups: Date: 2001-Jan-19 15:18 By: twouters Comment: Checked in, revision 2.105 of Modules/timemodule.c, 1.35 of Doc/lib/libtime.tex and 1.102 of Misc/NEWS. ------------------------------------------------------- Date: 2001-Jan-19 14:53 By: fdrake Comment: The docs look good -- please include them in the checkin. ------------------------------------------------------- Date: 2001-Jan-19 14:48 By: gvanrossum Comment: Thomas, please check this in -- there's still time to get it into 2.1a1. Then reassign to Fred for the docs! ------------------------------------------------------- Date: 2001-Jan-17 07:50 By: gvanrossum Comment: Thomas, go for it. I'd say "the current time" instead of "now" in the NEWS item. I'll defer to Fred for the docs. ------------------------------------------------------- Date: 2001-Jan-17 06:55 By: twouters Comment: That's what I meant with 'check the size', but I still think it kind of breaks the abstraction of 'args'. Not in a terribly scary way, but the difference between calling floattime() always and doing a check whether or not to call floattime() isn't that big either. But you is BDFL, boss, so here's a patch that does it your way :) It also adds a NEWS entry and fixes the docs for timemodule (including docstrings.) Assigned to Fred so he can take a quick look at the docs. Don't need to check the TeX code though, Fred, I successfully built ps files on my laptop :) ------------------------------------------------------- Date: 2001-Jan-17 06:01 By: gvanrossum Comment: With METH_VARARGS, args is guaranteed to be a tuple, so you can simply use PyTuple_Size(). ------------------------------------------------------- Date: 2001-Jan-17 01:24 By: twouters Comment: Calling floattime() only when necessary would be nice, but isn't possible without a value that reads as 'empty'. There is no way to see whether optional values of a ParseTuple call were filled or not, except by comparing the old value with the new one, and that means making a token float value that means 'no argument'. We could check the length of 'args' to see howmany arguments it contains, but that is a very fragile way, and breaks the wonderful transparentness of argument-passing and PyArg_Parse*. The alternative to this approach is not reading a double from the arglist, but a Python object (initialized as NULL,) and converting that to a float. That would have my preference over the other two options, above, but I still prefer the current way -- much less code, not that much slower (if slower at all, I didn't time it.) (Unless of course there is a way to see howmany optional arguments were used ? Like a separate format character that fills an int with that information, or a separate PyArg API call that returns not success/failure, but the number of optional arguments used, and -1 on failure.) I'll add news + docs, too, sometime before friday if work permits :P ------------------------------------------------------- Date: 2001-Jan-16 20:29 By: gvanrossum Comment: How hard would it be to avoid calling floattime() when an argument is present (in gmtime() and localtime())? Missing: docs, NEWS item. Otherwise, great -- ready to check in if you fix the above things! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103265&group_id=5470 From noreply@sourceforge.net Fri Jan 19 23:42:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 15:42:39 -0800 Subject: [Patches] [Patch #103336] Missing cast Message-ID: <E14JlB1-0008GQ-00@usw-sf-web3.sourceforge.net> Patch #103336 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jackjansen Assigned to : nobody Summary: Missing cast ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103336&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:31:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:31:40 -0800 Subject: [Patches] [Patch #103333] install_data does not do pathname conversion Message-ID: <E14Jk4K-0007tO-00@usw-sf-web3.sourceforge.net> Patch #103333 has been updated. Project: python Category: distutils Status: Open Submitted by: jackjansen Assigned to : nobody Summary: install_data does not do pathname conversion ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103333&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:35:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:35:15 -0800 Subject: [Patches] [Patch #103334] Strip "." pathname components Message-ID: <E14Jk7n-0007ut-00@usw-sf-web3.sourceforge.net> Patch #103334 has been updated. Project: python Category: distutils Status: Open Submitted by: jackjansen Assigned to : nobody Summary: Strip "." pathname components ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103334&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:41:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:41:31 -0800 Subject: [Patches] [Patch #103334] Strip "." pathname components Message-ID: <E14JkDr-0000Nk-00@usw-sf-web2.sourceforge.net> Patch #103334 has been updated. Project: python Category: distutils Status: Open Submitted by: jackjansen Assigned to : akuchling Summary: Strip "." pathname components Follow-Ups: Date: 2001-Jan-19 14:41 By: gvanrossum Comment: Looks decent to me. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103334&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:42:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:42:10 -0800 Subject: [Patches] [Patch #103333] install_data does not do pathname conversion Message-ID: <E14JkEU-0007wu-00@usw-sf-web3.sourceforge.net> Patch #103333 has been updated. Project: python Category: distutils Status: Open Submitted by: jackjansen Assigned to : akuchling Summary: install_data does not do pathname conversion Follow-Ups: Date: 2001-Jan-19 14:42 By: gvanrossum Comment: For Andrew. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103333&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:43:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:43:11 -0800 Subject: [Patches] [Patch #103297] __all__ values for a handful of modules Message-ID: <E14JkFT-0007xQ-00@usw-sf-web3.sourceforge.net> Patch #103297 has been updated. Project: python Category: library Status: Open Submitted by: montanaro Assigned to : montanaro Summary: __all__ values for a handful of modules Follow-Ups: Date: 2001-Jan-19 14:43 By: gvanrossum Comment: So where's the next update? I would approve of adding this to the alpha1 release. ------------------------------------------------------- Date: 2001-Jan-18 18:32 By: gvanrossum Comment: Nice, Skip! I wonder if the "test" functions should really be included in __all__? Especially StringIO's test isn't generally needed. I'd be happy if I had to import it explicitly using "from StringIO import test" if I really wanted it. Ditto for the HTTP server classes. ------------------------------------------------------- Date: 2001-Jan-18 19:09 By: montanaro Comment: Yeah, I wondered about including "test". I included it only because I thought I remembered someone mentioning that in a previous thread. I'll remove "test" from __all__ in my next update. Assuming everything else is okay, I will keep adding to the number of modified modules. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103297&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:48:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:48:41 -0800 Subject: [Patches] [Patch #103265] Let time functions default to 'now' (where it makes sense) Message-ID: <E14JkKn-0003rE-00@usw-sf-web1.sourceforge.net> Patch #103265 has been updated. Project: python Category: Modules Status: Open Submitted by: twouters Assigned to : twouters Summary: Let time functions default to 'now' (where it makes sense) Follow-Ups: Date: 2001-Jan-19 14:48 By: gvanrossum Comment: Thomas, please check this in -- there's still time to get it into 2.1a1. Then reassign to Fred for the docs! ------------------------------------------------------- Date: 2001-Jan-17 07:50 By: gvanrossum Comment: Thomas, go for it. I'd say "the current time" instead of "now" in the NEWS item. I'll defer to Fred for the docs. ------------------------------------------------------- Date: 2001-Jan-17 06:55 By: twouters Comment: That's what I meant with 'check the size', but I still think it kind of breaks the abstraction of 'args'. Not in a terribly scary way, but the difference between calling floattime() always and doing a check whether or not to call floattime() isn't that big either. But you is BDFL, boss, so here's a patch that does it your way :) It also adds a NEWS entry and fixes the docs for timemodule (including docstrings.) Assigned to Fred so he can take a quick look at the docs. Don't need to check the TeX code though, Fred, I successfully built ps files on my laptop :) ------------------------------------------------------- Date: 2001-Jan-17 06:01 By: gvanrossum Comment: With METH_VARARGS, args is guaranteed to be a tuple, so you can simply use PyTuple_Size(). ------------------------------------------------------- Date: 2001-Jan-17 01:24 By: twouters Comment: Calling floattime() only when necessary would be nice, but isn't possible without a value that reads as 'empty'. There is no way to see whether optional values of a ParseTuple call were filled or not, except by comparing the old value with the new one, and that means making a token float value that means 'no argument'. We could check the length of 'args' to see howmany arguments it contains, but that is a very fragile way, and breaks the wonderful transparentness of argument-passing and PyArg_Parse*. The alternative to this approach is not reading a double from the arglist, but a Python object (initialized as NULL,) and converting that to a float. That would have my preference over the other two options, above, but I still prefer the current way -- much less code, not that much slower (if slower at all, I didn't time it.) (Unless of course there is a way to see howmany optional arguments were used ? Like a separate format character that fills an int with that information, or a separate PyArg API call that returns not success/failure, but the number of optional arguments used, and -1 on failure.) I'll add news + docs, too, sometime before friday if work permits :P ------------------------------------------------------- Date: 2001-Jan-16 20:29 By: gvanrossum Comment: How hard would it be to avoid calling floattime() when an argument is present (in gmtime() and localtime())? Missing: docs, NEWS item. Otherwise, great -- ready to check in if you fix the above things! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103265&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:51:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:51:21 -0800 Subject: [Patches] [Patch #101782] Enhances 1.6 compiler to raise 'proper' SyntaxErrors Message-ID: <E14JkNN-0000Qe-00@usw-sf-web2.sourceforge.net> Patch #101782 has been updated. Project: python Category: Parser/Compiler Status: Open Submitted by: roman_sulzhyk Assigned to : jhylton Summary: Enhances 1.6 compiler to raise 'proper' SyntaxErrors Follow-Ups: Date: 2001-Jan-19 14:51 By: gvanrossum Comment: This is better for Jeremy to review, since he has done a major refactoring on the compiler code. Jeremy, I don't want this in 2.1a1, but could you see if you can get it either approved or rejected in time for 2.1a2? ------------------------------------------------------- Date: 2000-Oct-04 12:29 By: roman_sulzhyk Comment: Hello: There's a problem with the compiler.c (which persists in 2.0 also) which means it raises 'old style' SyntaxErrors, which could not be formatted properly. I mentioned this to Guido during the last conference, and he said it can best be done by moving parts of the 'linecache' functionality to core python, or something along those lines. Well, I've put together something which is not so far-fetching, but plugs this hole. The only time it reverts to the 'old style' compile error is when the input file is not a regular file (like stdin), since the line information is lost at that point - don't think parser.c saves it anywhere. Tell me what you think - should I port it to 2.0, or just drop it altogether if it's not needed. Thanks, Roman ------------------------------------------------------- Date: 2000-Oct-04 23:40 By: fdrake Comment: This needs to be ported to the latest CVS version before being considered for implementation (but discussion of the feature is welcome!). This cannot be considered for inclusion in 2.0 since we're in feature freeze already, and are only fixing bugs at this point. This can be considered for 2.1. Marking as postponed. ------------------------------------------------------- Date: 2000-Oct-09 10:59 By: roman_sulzhyk Comment: I've ported it to the latest CVS version - check it out, Roman ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101782&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:53:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:53:19 -0800 Subject: [Patches] [Patch #103265] Let time functions default to 'now' (where it makes sense) Message-ID: <E14JkPH-0003t0-00@usw-sf-web1.sourceforge.net> Patch #103265 has been updated. Project: python Category: Modules Status: Accepted Submitted by: twouters Assigned to : twouters Summary: Let time functions default to 'now' (where it makes sense) Follow-Ups: Date: 2001-Jan-19 14:53 By: fdrake Comment: The docs look good -- please include them in the checkin. ------------------------------------------------------- Date: 2001-Jan-19 14:48 By: gvanrossum Comment: Thomas, please check this in -- there's still time to get it into 2.1a1. Then reassign to Fred for the docs! ------------------------------------------------------- Date: 2001-Jan-17 07:50 By: gvanrossum Comment: Thomas, go for it. I'd say "the current time" instead of "now" in the NEWS item. I'll defer to Fred for the docs. ------------------------------------------------------- Date: 2001-Jan-17 06:55 By: twouters Comment: That's what I meant with 'check the size', but I still think it kind of breaks the abstraction of 'args'. Not in a terribly scary way, but the difference between calling floattime() always and doing a check whether or not to call floattime() isn't that big either. But you is BDFL, boss, so here's a patch that does it your way :) It also adds a NEWS entry and fixes the docs for timemodule (including docstrings.) Assigned to Fred so he can take a quick look at the docs. Don't need to check the TeX code though, Fred, I successfully built ps files on my laptop :) ------------------------------------------------------- Date: 2001-Jan-17 06:01 By: gvanrossum Comment: With METH_VARARGS, args is guaranteed to be a tuple, so you can simply use PyTuple_Size(). ------------------------------------------------------- Date: 2001-Jan-17 01:24 By: twouters Comment: Calling floattime() only when necessary would be nice, but isn't possible without a value that reads as 'empty'. There is no way to see whether optional values of a ParseTuple call were filled or not, except by comparing the old value with the new one, and that means making a token float value that means 'no argument'. We could check the length of 'args' to see howmany arguments it contains, but that is a very fragile way, and breaks the wonderful transparentness of argument-passing and PyArg_Parse*. The alternative to this approach is not reading a double from the arglist, but a Python object (initialized as NULL,) and converting that to a float. That would have my preference over the other two options, above, but I still prefer the current way -- much less code, not that much slower (if slower at all, I didn't time it.) (Unless of course there is a way to see howmany optional arguments were used ? Like a separate format character that fills an int with that information, or a separate PyArg API call that returns not success/failure, but the number of optional arguments used, and -1 on failure.) I'll add news + docs, too, sometime before friday if work permits :P ------------------------------------------------------- Date: 2001-Jan-16 20:29 By: gvanrossum Comment: How hard would it be to avoid calling floattime() when an argument is present (in gmtime() and localtime())? Missing: docs, NEWS item. Otherwise, great -- ready to check in if you fix the above things! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103265&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:54:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:54:24 -0800 Subject: [Patches] [Patch #103314] allow urllib.urlencode to work with multivalued parameters Message-ID: <E14JkQK-0003tM-00@usw-sf-web1.sourceforge.net> Patch #103314 has been updated. Project: python Category: library Status: Open Submitted by: montanaro Assigned to : fdrake Summary: allow urllib.urlencode to work with multivalued parameters Follow-Ups: Date: 2001-Jan-19 14:54 By: gvanrossum Comment: Skip, please check the code in, leave the docs until Fred approves. ------------------------------------------------------- Date: 2001-Jan-18 10:09 By: gvanrossum Comment: Comment: I would test for doseq once, and then have two loops: one with the old behavior and one with the new. Also, you might want to catch Unicode and explicitly force it into ASCII (rather than committing to a conversion without knowing what's the right thing). ------------------------------------------------------- Date: 2001-Jan-18 09:42 By: montanaro Comment: Assigned to Fred for starters because it does have a doc change. Fred, Guido probably wants to look at it next, but you're a better judge of who might have more free time... S ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103314&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:57:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:57:07 -0800 Subject: [Patches] [Patch #102229] a better robotparser.py module Message-ID: <E14JkSx-00082B-00@usw-sf-web3.sourceforge.net> Patch #102229 has been updated. Project: python Category: Modules Status: Open Submitted by: calvin Assigned to : montanaro Summary: a better robotparser.py module Follow-Ups: Date: 2001-Jan-19 14:57 By: gvanrossum Comment: Skip, if this is ok with you, can you check it in? (Unless you feel you don't want to check it in because you still feel your module is better -- in that case we should probably drop it or reassign it...) ------------------------------------------------------- Date: 2001-Jan-06 04:31 By: calvin Comment: Ok, some new changes: - allow parsing of user-agent: lines without preceding blank line - two licenses available: Python 2.0 license or GPL license - add some doc string for the classes Bastian ------------------------------------------------------- Date: 2001-Jan-04 18:31 By: gvanrossum Comment: Skip, back to you. Please work with the author on an acceptable version. You can check it in once you two agree. ------------------------------------------------------- Date: 2001-Jan-04 17:43 By: montanaro Comment: I fixed the robots.txt file, but I think you should parse files without the requisite blank lines (be lenient in what you accept and strict in what you generate). The user-agent line can serve as an implicit separator between one record and the next. Skip ------------------------------------------------------- Date: 2001-Jan-04 15:51 By: calvin Comment: Changes: - global debug variable in the test function - redirection now works - accidently printed "Allow" when I meant "Disallow". This has been fixed. It parses the Musi-Cal robots.txt file correctly, but the robots.txt file has syntax errors: before each user-agent: line there has to be one or more empty lines. ------------------------------------------------------- Date: 2001-Jan-04 13:05 By: montanaro Comment: I apologize for taking so long to take a look at this. I was reminded of it when I saw the switch from me to Guido. I spent a little time fiddling with this module today. I'm not satisfied that it works as advertised. Here are a number of problems I found: * in the test function, the debug variable is not declared global, so setting it to 1 has no effect * it never seemed to properly handle redirections, so it never got from http://www.musi-cal.com/robots.txt to http://musi-cal.mojam.com/robots.txt * once I worked around the redirection problem it seemed to parse the Musi-Cal robots.txt file incorrectly. I replaced httplib with urllib in the read method and got erroneous results. If you look at the above robots.txt file you'll see that a bunch of email address harvesters are explicitly forbidden (not that they pay attention to robots.txt!). The following should print 0, but prints 1: print rp.can_fetch('ExtractorPro', 'http://musi-cal.mojam.com/') This is (at least in part) due to the fact that the redirection never works. In the version I modified to use urllib, it displays incorrect permissions for things like ExtractorPro: User-agent: ExtractorPro Allow: / Note that the lines in the robot.txt file for ExtractorPro are actually User-agent: ExtractorPro Disallow: / Skip ------------------------------------------------------- Date: 2000-Nov-02 09:40 By: calvin Comment: I have written a new RobotParser module 'robotparser2.py'. This module is o backward compatible with the old one o makes correct useragent matching (is buggy in robotparser.py) o strips comments correctly (is buggy in robotparser.py) o uses httplib instead of urllib.urlopen() to catch HTTP connect errors correctly (is buggy in robotparser.py) o implements not only the draft at http://info.webcrawler.com/mak/projects/robots/norobots.html but also the new one at http://info.webcrawler.com/mak/projects/robots/norobots-rfc.html Bastian Kleineidam ------------------------------------------------------- Date: 2000-Nov-02 11:14 By: gvanrossum Comment: Skip, can you comment on this? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102229&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:59:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:59:35 -0800 Subject: [Patches] [Patch #101970] Allow urllib to support http: Message-ID: <E14JkVL-0003vF-00@usw-sf-web1.sourceforge.net> Patch #101970 has been updated. Project: python Category: library Status: Open Submitted by: prescod Assigned to : prescod Summary: Allow urllib to support http: Follow-Ups: Date: 2001-Jan-19 14:59 By: gvanrossum Comment: Paul, if you're not interested in this any more, I'll just reject it, OK? ------------------------------------------------------- Date: 2001-Jan-04 07:46 By: gvanrossum Comment: This patch should be rejected based on form. Paul, you can do better than sending in a diff without context! Also, the subject makes no sense. If you still want this, please fix the subject and submit a new patch and we'll lookj at it again. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101970&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:58:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:58:36 -0800 Subject: [Patches] [Patch #103247] Strings: '\012' -> '\n' Message-ID: <E14JkUO-0000Sv-00@usw-sf-web2.sourceforge.net> Patch #103247 has been updated. Project: python Category: core (C code) Status: Open Submitted by: ping Assigned to : ping Summary: Strings: '\012' -> '\n' Follow-Ups: Date: 2001-Jan-19 14:58 By: gvanrossum Comment: Ping, please check this in before Monday, so it can go into the alpha1. The docs can come later. ------------------------------------------------------- Date: 2001-Jan-15 21:42 By: ping Comment: Yes, the docs will take some work. I'll resubmit when i've gone through all the documentation. ------------------------------------------------------- Date: 2001-Jan-15 20:21 By: gvanrossum Comment: Nice. Style nit: I don't care for the fputc(), fputc(); form. Can you resubmit (and retest!) a version that uses \x%02x too? I'd expect that this would require updates to some docs and the tutorial, too. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103247&group_id=5470 From noreply@sourceforge.net Sat Jan 20 01:49:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 17:49:28 -0800 Subject: [Patches] [Patch #103297] __all__ values for a handful of modules Message-ID: <E14Jn9k-0001IF-00@usw-sf-web2.sourceforge.net> Patch #103297 has been updated. Project: python Category: library Status: Open Submitted by: montanaro Assigned to : montanaro Summary: __all__ values for a handful of modules Follow-Ups: Date: 2001-Jan-19 17:49 By: tim_one Comment: I had wondered out loud whether test functions would get included in the context of the __exports__ patch, which was an unbreachable wall: I didn't want to be left with *no* way to execute a module's test function from within a different module. I agree that test functions should not be included in the context of __all__, though -- I can get at them whether or not they're in __all__, and they're not what an "import *" abuser wants to see anyway. ------------------------------------------------------- Date: 2001-Jan-19 14:43 By: gvanrossum Comment: So where's the next update? I would approve of adding this to the alpha1 release. ------------------------------------------------------- Date: 2001-Jan-18 18:32 By: gvanrossum Comment: Nice, Skip! I wonder if the "test" functions should really be included in __all__? Especially StringIO's test isn't generally needed. I'd be happy if I had to import it explicitly using "from StringIO import test" if I really wanted it. Ditto for the HTTP server classes. ------------------------------------------------------- Date: 2001-Jan-18 19:09 By: montanaro Comment: Yeah, I wondered about including "test". I included it only because I thought I remembered someone mentioning that in a previous thread. I'll remove "test" from __all__ in my next update. Assuming everything else is okay, I will keep adding to the number of modified modules. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103297&group_id=5470 From noreply@sourceforge.net Sat Jan 20 05:13:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 21:13:44 -0800 Subject: [Patches] [Patch #103336] Missing cast Message-ID: <E14JqLQ-0005YJ-00@usw-sf-web1.sourceforge.net> Patch #103336 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jackjansen Assigned to : tim_one Summary: Missing cast ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103336&group_id=5470 From noreply@sourceforge.net Sat Jan 20 05:16:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 21:16:11 -0800 Subject: [Patches] [Patch #103336] Missing cast Message-ID: <E14JqNn-0005Zc-00@usw-sf-web1.sourceforge.net> Patch #103336 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jackjansen Assigned to : tim_one Summary: Missing cast Follow-Ups: Date: 2001-Jan-19 21:16 By: tim_one Comment: Checked in to compile.c rev 2.147. Jack is my hero! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103336&group_id=5470 From noreply@sourceforge.net Sat Jan 20 06:31:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 22:31:19 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: <E14JrYV-0005u3-00@usw-sf-web1.sourceforge.net> Patch #102409 has been updated. Project: python Category: Build Status: Open Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-19 22:31 By: jlt63 Comment: This patch enables Cygwin Python to build using the new Distutils style Python build. Please note that the build_ext.py part is from Jorge Sousa <jsousa@cfn.ist.utl.pt>. To patch, change directory to the top of the CVS tree and use $ patch -p0 <dist.patch The following is the ChangeLog: Sat Jan 20 01:05:18 2001 Jason Tishler <jt@dothill.com> * Makefile.in($(srcdir)/Lib/$(PLATDIR)): Add Distutils build library directory to PYTHONPATH so regen works again. (sharedinstall): Add --install-platlib option so shared extensions follow $(exec_prefix). * setup.py: Add checks for Cygwin so unsupported modules (i.e., dbm and resource) are not built. * Lib/distutils/command/build_ext.py(build_ext.finalize_options): Add Cygwin specific code to append Python's library directory to the extension's list of library directories. (build_ext.get_libraries): Add Cygwin specific code to append Python's (import) library to the extension's list of libraries. ------------------------------------------------------- Date: 2001-Jan-19 08:19 By: gvanrossum Comment: Reopened at request. Don't sweat the release date -- t's only the first alpha release. I have a feeling it'll be put off till Monday. ------------------------------------------------------- Date: 2001-Jan-18 20:52 By: jlt63 Comment: Please reopen because I need to redo the Cygwin build to handle the use of distutils to build the standard extension modules instead of Modules/Makefile.pre.in. How much time (if any) do I have to resolve these issues before 2.1a is released. I heard that the release date is tomorrow. Sigh... ------------------------------------------------------- Date: 2001-Jan-10 19:39 By: jlt63 Comment: Your welcome -- thanks for considering and accepting this patch. If the patch proves to reek havoc on other platforms (most likely only on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out. ------------------------------------------------------- Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 <Cygwin-1.1.5-Python-2.0.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Sat Jan 20 06:38:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 22:38:14 -0800 Subject: [Patches] [Patch #103185] Some more standard modules cleanup for Cygwin Message-ID: <E14JrfC-0005w6-00@usw-sf-web1.sourceforge.net> Patch #103185 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Some more standard modules cleanup for Cygwin Follow-Ups: Date: 2001-Jan-19 22:38 By: jlt63 Comment: A few more courtesy of the Distutils style Python build. Note that Modules/syslogmodule.c will *not* build cleanly until I submit a minor patch to Cygwin to resolve this issue. To patch, change directory to the top of the CVS tree and use $ patch -p0 <mods.patch ------------------------------------------------------- Date: 2001-Jan-18 16:29 By: gvanrossum Comment: Applied, and closed. ------------------------------------------------------- Date: 2001-Jan-10 21:19 By: jlt63 Comment: Use the following procedure to patch: $ cd Modules $ # save modules.patch to current directory $ patch <modules.patch ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103185&group_id=5470 From noreply@sourceforge.net Sat Jan 20 06:59:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 22:59:56 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: <E14Js0C-00061P-00@usw-sf-web1.sourceforge.net> Patch #103154 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-19 22:59 By: jlt63 Comment: Please reopen so that this issue is not accidentally overlooked. At least, until the case sensitive import problem is resolved. I still have a pending patch submitted for consideration. Sorry, to be a pest... ------------------------------------------------------- Date: 2001-Jan-12 11:48 By: tim_one Comment: Ah, I see. There's a difference between Windows filesystems and filesystems used on Windows <wink/sigh>. Older Novell network fileservers for Windows do indeed destroy the case of file names, and newer ones are often configured in a compatability mode to keep on doing that. At my last employer, more than half the LAN servers were set up that way. Use of PYTHONCASEOK was universal as a result. We were also screwed in that one of the popular Windows source-control systems *also* destroyed case (I didn't use that, and have forgotten the name): check in OhNo.py, check out OHNO.PY. Brrrrrrrrr. ------------------------------------------------------- Date: 2001-Jan-12 10:52 By: gvanrossum Comment: Maybe things are different now. But I definitely remember that when I introduced this test, Mark Hammond told me that there was a popular networking filesystem that didn't preserve case. This was either for Windows NT or Windows 95, so it's not a Windows 3.1 thing (although it's possible that the fileserver in question was a bad port from DOS or Windows 3.1 of course). ------------------------------------------------------- Date: 2001-Jan-12 10:47 By: jlt63 Comment: I know. I was just confused by the following On 2001-Jan-11 06:47, gvanrossum wrote: > Note that I believe that "import termios, TERMIOS" *should fail* -- not all > filesystems used on Windows are case preserving. ------------------------------------------------------- Date: 2001-Jan-12 10:26 By: tim_one Comment: The filesystems do preserve the case of names. But all platform file *lookup* APIs are case-insensitive. ------------------------------------------------------- Date: 2001-Jan-12 09:50 By: jlt63 Comment: Oops... Use the following procedure to patch: $ cd Python $ # save case.patch to current directory $ patch <case.patch ------------------------------------------------------- Date: 2001-Jan-12 09:44 By: jlt63 Comment: I just uploaded a new patch. It fixes the case sensitive import problem for Cygwin without affecting Win32 (i.e., Win32 functions as before). Now Cygwin's import behavior is identical to other UNIX platforms. I'm not completely happy with the patch and would characterize it as hacky, but it is the best that I can do without fully grokking import.c. I think to do better would require major rework to find_module(). I guess by renaming TERMIOS you mean to change the module names generated by h2py.py. I have no issue with this -- will others? I thought all filesystems on Windows 95/NT 3.51 and later, were case preserving. To what filesystems and Windows versions are you referring? ------------------------------------------------------- Date: 2001-Jan-11 13:59 By: gvanrossum Comment: Upload it as a new patch. But I believe the solution is that the TERMIOS module should be renamed. ------------------------------------------------------- Date: 2001-Jan-11 07:56 By: jlt63 Comment: Actually, this is not a bug in my original version. Cygwin Python is behaving identically to the Win32 one. Unfortunately, as you pointed out Win32 Python definitely does not handle the situation of two modules that only differ by case. Sigh... If one tries to import the second module that would be found in sys.path, then a NameError: Case mismatch ... exception will *always* be generated. I'm not sure that I agree with this behavior but I really a UNIX guy. Since Cygwin Python should support as many UNIX modules as possible, it needs to deal with modules that only differ by case. termios and TERMIOS used by getpass is a perfect example. I have created a (hacky) patch, that solves this problem for both Cygwin and Win32. I can redo it so that it only affects Cygwin and leaves the Win32 functionality alone. I would like to upload it for discussion but I am concerned about overwriting the old version. Should I upload it anyway? ------------------------------------------------------- Date: 2001-Jan-11 06:47 By: gvanrossum Comment: Reopened at request. Note that I believe that "import termios, TERMIOS" *should fail* -- not all filesystems used on Windows are case preserving. I've had this battle with Mark Hammond before. The case check is intended to prevent you from importing a moduleusing the wrong case (e.g. import String). It is *not* intended to let you have two modules that only differ in case. ------------------------------------------------------- Date: 2001-Jan-10 19:48 By: jlt63 Comment: I have already checked that this patch does not break the Windows VC build before I submitted it. However, Tim is welcome to reverify himself. Unfortunately, I have found a bug with this patch that (only) affects Cygwin. Although this patch handles the following: import String it does not handle the following: import termios, TERMIOS I will resubmit a new version shortly, please change the status back to open. ------------------------------------------------------- Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler <jt@dothill.com> * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Sat Jan 20 16:03:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 20 Jan 2001 08:03:56 -0800 Subject: [Patches] [Patch #102229] a better robotparser.py module Message-ID: <E14K0Ue-00053k-00@usw-sf-web2.sourceforge.net> Patch #102229 has been updated. Project: python Category: library Status: Closed Submitted by: calvin Assigned to : montanaro Summary: a better robotparser.py module Follow-Ups: Date: 2001-Jan-20 08:03 By: montanaro Comment: Checked in and closed. Thanks Bastian! ------------------------------------------------------- Date: 2001-Jan-19 14:57 By: gvanrossum Comment: Skip, if this is ok with you, can you check it in? (Unless you feel you don't want to check it in because you still feel your module is better -- in that case we should probably drop it or reassign it...) ------------------------------------------------------- Date: 2001-Jan-06 04:31 By: calvin Comment: Ok, some new changes: - allow parsing of user-agent: lines without preceding blank line - two licenses available: Python 2.0 license or GPL license - add some doc string for the classes Bastian ------------------------------------------------------- Date: 2001-Jan-04 18:31 By: gvanrossum Comment: Skip, back to you. Please work with the author on an acceptable version. You can check it in once you two agree. ------------------------------------------------------- Date: 2001-Jan-04 17:43 By: montanaro Comment: I fixed the robots.txt file, but I think you should parse files without the requisite blank lines (be lenient in what you accept and strict in what you generate). The user-agent line can serve as an implicit separator between one record and the next. Skip ------------------------------------------------------- Date: 2001-Jan-04 15:51 By: calvin Comment: Changes: - global debug variable in the test function - redirection now works - accidently printed "Allow" when I meant "Disallow". This has been fixed. It parses the Musi-Cal robots.txt file correctly, but the robots.txt file has syntax errors: before each user-agent: line there has to be one or more empty lines. ------------------------------------------------------- Date: 2001-Jan-04 13:05 By: montanaro Comment: I apologize for taking so long to take a look at this. I was reminded of it when I saw the switch from me to Guido. I spent a little time fiddling with this module today. I'm not satisfied that it works as advertised. Here are a number of problems I found: * in the test function, the debug variable is not declared global, so setting it to 1 has no effect * it never seemed to properly handle redirections, so it never got from http://www.musi-cal.com/robots.txt to http://musi-cal.mojam.com/robots.txt * once I worked around the redirection problem it seemed to parse the Musi-Cal robots.txt file incorrectly. I replaced httplib with urllib in the read method and got erroneous results. If you look at the above robots.txt file you'll see that a bunch of email address harvesters are explicitly forbidden (not that they pay attention to robots.txt!). The following should print 0, but prints 1: print rp.can_fetch('ExtractorPro', 'http://musi-cal.mojam.com/') This is (at least in part) due to the fact that the redirection never works. In the version I modified to use urllib, it displays incorrect permissions for things like ExtractorPro: User-agent: ExtractorPro Allow: / Note that the lines in the robot.txt file for ExtractorPro are actually User-agent: ExtractorPro Disallow: / Skip ------------------------------------------------------- Date: 2000-Nov-02 09:40 By: calvin Comment: I have written a new RobotParser module 'robotparser2.py'. This module is o backward compatible with the old one o makes correct useragent matching (is buggy in robotparser.py) o strips comments correctly (is buggy in robotparser.py) o uses httplib instead of urllib.urlopen() to catch HTTP connect errors correctly (is buggy in robotparser.py) o implements not only the draft at http://info.webcrawler.com/mak/projects/robots/norobots.html but also the new one at http://info.webcrawler.com/mak/projects/robots/norobots-rfc.html Bastian Kleineidam ------------------------------------------------------- Date: 2000-Nov-02 11:14 By: gvanrossum Comment: Skip, can you comment on this? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102229&group_id=5470 From noreply@sourceforge.net Sat Jan 20 16:47:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 20 Jan 2001 08:47:17 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: <E14K1Ab-0000JN-00@usw-sf-web1.sourceforge.net> Patch #103154 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-20 08:47 By: gvanrossum Comment: Reopened at request. But I won't *do* anything about this until I've heard the arguments one more time. ------------------------------------------------------- Date: 2001-Jan-19 22:59 By: jlt63 Comment: Please reopen so that this issue is not accidentally overlooked. At least, until the case sensitive import problem is resolved. I still have a pending patch submitted for consideration. Sorry, to be a pest... ------------------------------------------------------- Date: 2001-Jan-12 11:48 By: tim_one Comment: Ah, I see. There's a difference between Windows filesystems and filesystems used on Windows <wink/sigh>. Older Novell network fileservers for Windows do indeed destroy the case of file names, and newer ones are often configured in a compatability mode to keep on doing that. At my last employer, more than half the LAN servers were set up that way. Use of PYTHONCASEOK was universal as a result. We were also screwed in that one of the popular Windows source-control systems *also* destroyed case (I didn't use that, and have forgotten the name): check in OhNo.py, check out OHNO.PY. Brrrrrrrrr. ------------------------------------------------------- Date: 2001-Jan-12 10:52 By: gvanrossum Comment: Maybe things are different now. But I definitely remember that when I introduced this test, Mark Hammond told me that there was a popular networking filesystem that didn't preserve case. This was either for Windows NT or Windows 95, so it's not a Windows 3.1 thing (although it's possible that the fileserver in question was a bad port from DOS or Windows 3.1 of course). ------------------------------------------------------- Date: 2001-Jan-12 10:47 By: jlt63 Comment: I know. I was just confused by the following On 2001-Jan-11 06:47, gvanrossum wrote: > Note that I believe that "import termios, TERMIOS" *should fail* -- not all > filesystems used on Windows are case preserving. ------------------------------------------------------- Date: 2001-Jan-12 10:26 By: tim_one Comment: The filesystems do preserve the case of names. But all platform file *lookup* APIs are case-insensitive. ------------------------------------------------------- Date: 2001-Jan-12 09:50 By: jlt63 Comment: Oops... Use the following procedure to patch: $ cd Python $ # save case.patch to current directory $ patch <case.patch ------------------------------------------------------- Date: 2001-Jan-12 09:44 By: jlt63 Comment: I just uploaded a new patch. It fixes the case sensitive import problem for Cygwin without affecting Win32 (i.e., Win32 functions as before). Now Cygwin's import behavior is identical to other UNIX platforms. I'm not completely happy with the patch and would characterize it as hacky, but it is the best that I can do without fully grokking import.c. I think to do better would require major rework to find_module(). I guess by renaming TERMIOS you mean to change the module names generated by h2py.py. I have no issue with this -- will others? I thought all filesystems on Windows 95/NT 3.51 and later, were case preserving. To what filesystems and Windows versions are you referring? ------------------------------------------------------- Date: 2001-Jan-11 13:59 By: gvanrossum Comment: Upload it as a new patch. But I believe the solution is that the TERMIOS module should be renamed. ------------------------------------------------------- Date: 2001-Jan-11 07:56 By: jlt63 Comment: Actually, this is not a bug in my original version. Cygwin Python is behaving identically to the Win32 one. Unfortunately, as you pointed out Win32 Python definitely does not handle the situation of two modules that only differ by case. Sigh... If one tries to import the second module that would be found in sys.path, then a NameError: Case mismatch ... exception will *always* be generated. I'm not sure that I agree with this behavior but I really a UNIX guy. Since Cygwin Python should support as many UNIX modules as possible, it needs to deal with modules that only differ by case. termios and TERMIOS used by getpass is a perfect example. I have created a (hacky) patch, that solves this problem for both Cygwin and Win32. I can redo it so that it only affects Cygwin and leaves the Win32 functionality alone. I would like to upload it for discussion but I am concerned about overwriting the old version. Should I upload it anyway? ------------------------------------------------------- Date: 2001-Jan-11 06:47 By: gvanrossum Comment: Reopened at request. Note that I believe that "import termios, TERMIOS" *should fail* -- not all filesystems used on Windows are case preserving. I've had this battle with Mark Hammond before. The case check is intended to prevent you from importing a moduleusing the wrong case (e.g. import String). It is *not* intended to let you have two modules that only differ in case. ------------------------------------------------------- Date: 2001-Jan-10 19:48 By: jlt63 Comment: I have already checked that this patch does not break the Windows VC build before I submitted it. However, Tim is welcome to reverify himself. Unfortunately, I have found a bug with this patch that (only) affects Cygwin. Although this patch handles the following: import String it does not handle the following: import termios, TERMIOS I will resubmit a new version shortly, please change the status back to open. ------------------------------------------------------- Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler <jt@dothill.com> * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Sat Jan 20 17:12:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 20 Jan 2001 09:12:47 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14K1ZH-0005O8-00@usw-sf-web2.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : nascheme Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-20 09:12 By: nascheme Comment: Why do weak references need callbacks? I see nothing in the PEP to justify this feature. If there is no good reason for them, I propose that the feature be removed for 2.1. Allowing callbacks may make it harder to implement weak references more efficiently later. ------------------------------------------------------- Date: 2001-Jan-18 16:03 By: loewis Comment: The patch looks ok in general, pending resolution of the issues on the PEP itself. Some nits: Integration with GC is still fuzzy. If an instance is GC collected and had a weak ref to it and the weak ref had a callback and the callback choses to resurrect the object, semantics is unclear. This is equivalent to the object having an __del__; the GC would normally *not* collect such objects, but put them into gc.garbage. Proposed resolution: it is a fatal error to resurrect an object in a weakref callback. Hashing: it appears that the hash of a weakref can change when the underlying object goes away. If the weakref is used as key in a dictionary, it appears to be impossible to get the key out of the dictionary after the underlying object is gone. Proposed resolution: a proxy weak ref should cache the hash of the underlying object after its hash function was called for the first time. Comparing: why is the return value of tp_compare -1 when try_3way_compare expects -2 on error? Shouldn't there be some exception set when the underlying object goes away? ------------------------------------------------------- Date: 2001-Jan-17 13:53 By: fdrake Comment: Ok, I tihnk this is it! http://starship.python.net/crew/fdrake/patches/weakref.patch-5 This patch fixes the compilation problems from the previoous patch related to the introduction of rich comparisons, and makes a change in the way new objects are initialized by PyObject_New() and PyObject_NEW() (and all their friends!) -- those functions now know to initialize the weak reference list to NULL for objects which support weak references. Without this change, more places in the code (especially extension modules) need to know more about initialization of weakly-referencable objects. For instance, the "cPickle" and "new" modules both can create instances without calling the code in classobject.c (using PyObject_New()), causing core dumps when such instances are deallocated if the weak-reference list for instances was not properly initialized. Since these modules (properly) tried to avoid call PyInstance_New(), core dumps ensued and the world fell apart. By moving the initialization of the weak reference list into the core object allocators, this problem is averted and extension code to construct new weakly referencable types is simplified. The documentation still needs work, and there are a few new entries for the Python/C API manual as well. A new constructor for instances, PyInstance_NewRaw(), will be added in a separate patch. ------------------------------------------------------- Date: 2001-Jan-17 11:58 By: nascheme Comment: The magic test is: ./python Lib/test/regrtest.py test_weakref test_new Try adding this patch: --- Modules/newmodule.c 2000/11/13 20:29:20 2.29 +++ Modules/newmodule.c 2001/01/17 19:55:46 @@ -24,6 +24,7 @@ Py_INCREF(dict); inst->in_class = (PyClassObject *)klass; inst->in_dict = dict; + inst->in_weakreflist = NULL; PyObject_GC_Init(inst); return (PyObject *)inst; } ------------------------------------------------------- Date: 2001-Jan-17 08:04 By: fdrake Comment: New version of the patch that's still broken but doesn't conflict with the rich comparisons changes: http://starship.python.net/crew/fdrake/patches/weakref.patch-4 ------------------------------------------------------- Date: 2001-Jan-16 21:35 By: fdrake Comment: Added a new (but broken!) version of the patch that fixes WeakDictionary.get() but doesn't interact properly with GC (appearantly) -- not usable as is: http://starship.python.net/crew/fdrake/patches/weakref.patch-3 Neil made the mistake of volunteering to look at the current problem, so assigning to him. (Thanks!) ------------------------------------------------------- Date: 2001-Jan-16 19:39 By: tim_one Comment: Just mentioning a general scenario in which weak keys are the bee's knees: sometimes you want to add attributes to objects dynamically, in ways the original class author(s -- may cut across many classes! even non-instance objects; or objects from extension modules that don't support setattr) never anticipated. Like maybe a German translation of the object's docstrings; or a list of JPEG contents referenced by a URLish object; or a table of usage statistics on methods and functions; etc. Then it's natural to use the conceptual attr name as the name of a dict instead, and write attr[object] = whatever instead of object.attr = whatever There's no point keeping the "whatever" around when the object goes away, but a regular dict makes the object and its "whatever" immortal. A dict with weak keys is exactly on-target. ------------------------------------------------------- Date: 2001-Jan-16 19:14 By: fdrake Comment: I'm not entirely sure why one would want weak keys rather than weak values, but I suspect it has to do with expectations of how the dict will be used in applications. I don't think it would be hard to support both flavors of dictionaries using the primitive reference objects. The constructor does not check that all incoming values are weak because that isn't required. It uses self.update() rather than self.data.update() to perform the inclusion, so any mapping that supports .keys() and .__getitem__() is sufficient. Some additional checking could be done to make sure that all added entries can be created before inserting any of them, offering more atomicity. .get() will be fixed in the next version of the patch; thanks! I've added GC support, but don't have it working quite right. I'm trying to isolate the failure now. ------------------------------------------------------- Date: 2001-Jan-12 14:36 By: loewis Comment: The weak dictionary data type needs more clarification in documentation and implementation. In java.util.WeakHashMap, they keys are weak, not the values (i.e. once the key is forgotten, the entry is cleared). In http://www.handshake.de/~dieter/weakdict.html, the values are weak, but it raises KeyErrors for entries that are collected. The initializer of a weak dict does not check the invariant (all values are weak). get() of a weakdict does not support an optional second parameter. weakref and friends need to participate in garbage collection, as the reference to the callback can create a cycle. ------------------------------------------------------- Date: 2001-Jan-12 11:27 By: fdrake Comment: Updated patch to also support proxy semantics using the same invalidation machinery as the basic weak reference type. The additional code is *heavily* borrowed from Neil Schemenauer. ------------------------------------------------------- Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Sat Jan 20 17:42:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 20 Jan 2001 09:42:16 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14K21o-0000Zv-00@usw-sf-web1.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : nascheme Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-20 09:42 By: gvanrossum Comment: I think callbacks are needed to implement various forms of weak dicts: when the object is deleted, whatever's in the weak dict for it should be deleted as well. Even though we may not provide weak dicts in 2.1a1, we should still support writing them using what we *do* provide. IMHO (I still haven't had the time to read the PEP or Fred's code. :-( ) ------------------------------------------------------- Date: 2001-Jan-20 09:12 By: nascheme Comment: Why do weak references need callbacks? I see nothing in the PEP to justify this feature. If there is no good reason for them, I propose that the feature be removed for 2.1. Allowing callbacks may make it harder to implement weak references more efficiently later. ------------------------------------------------------- Date: 2001-Jan-18 16:03 By: loewis Comment: The patch looks ok in general, pending resolution of the issues on the PEP itself. Some nits: Integration with GC is still fuzzy. If an instance is GC collected and had a weak ref to it and the weak ref had a callback and the callback choses to resurrect the object, semantics is unclear. This is equivalent to the object having an __del__; the GC would normally *not* collect such objects, but put them into gc.garbage. Proposed resolution: it is a fatal error to resurrect an object in a weakref callback. Hashing: it appears that the hash of a weakref can change when the underlying object goes away. If the weakref is used as key in a dictionary, it appears to be impossible to get the key out of the dictionary after the underlying object is gone. Proposed resolution: a proxy weak ref should cache the hash of the underlying object after its hash function was called for the first time. Comparing: why is the return value of tp_compare -1 when try_3way_compare expects -2 on error? Shouldn't there be some exception set when the underlying object goes away? ------------------------------------------------------- Date: 2001-Jan-17 13:53 By: fdrake Comment: Ok, I tihnk this is it! http://starship.python.net/crew/fdrake/patches/weakref.patch-5 This patch fixes the compilation problems from the previoous patch related to the introduction of rich comparisons, and makes a change in the way new objects are initialized by PyObject_New() and PyObject_NEW() (and all their friends!) -- those functions now know to initialize the weak reference list to NULL for objects which support weak references. Without this change, more places in the code (especially extension modules) need to know more about initialization of weakly-referencable objects. For instance, the "cPickle" and "new" modules both can create instances without calling the code in classobject.c (using PyObject_New()), causing core dumps when such instances are deallocated if the weak-reference list for instances was not properly initialized. Since these modules (properly) tried to avoid call PyInstance_New(), core dumps ensued and the world fell apart. By moving the initialization of the weak reference list into the core object allocators, this problem is averted and extension code to construct new weakly referencable types is simplified. The documentation still needs work, and there are a few new entries for the Python/C API manual as well. A new constructor for instances, PyInstance_NewRaw(), will be added in a separate patch. ------------------------------------------------------- Date: 2001-Jan-17 11:58 By: nascheme Comment: The magic test is: ./python Lib/test/regrtest.py test_weakref test_new Try adding this patch: --- Modules/newmodule.c 2000/11/13 20:29:20 2.29 +++ Modules/newmodule.c 2001/01/17 19:55:46 @@ -24,6 +24,7 @@ Py_INCREF(dict); inst->in_class = (PyClassObject *)klass; inst->in_dict = dict; + inst->in_weakreflist = NULL; PyObject_GC_Init(inst); return (PyObject *)inst; } ------------------------------------------------------- Date: 2001-Jan-17 08:04 By: fdrake Comment: New version of the patch that's still broken but doesn't conflict with the rich comparisons changes: http://starship.python.net/crew/fdrake/patches/weakref.patch-4 ------------------------------------------------------- Date: 2001-Jan-16 21:35 By: fdrake Comment: Added a new (but broken!) version of the patch that fixes WeakDictionary.get() but doesn't interact properly with GC (appearantly) -- not usable as is: http://starship.python.net/crew/fdrake/patches/weakref.patch-3 Neil made the mistake of volunteering to look at the current problem, so assigning to him. (Thanks!) ------------------------------------------------------- Date: 2001-Jan-16 19:39 By: tim_one Comment: Just mentioning a general scenario in which weak keys are the bee's knees: sometimes you want to add attributes to objects dynamically, in ways the original class author(s -- may cut across many classes! even non-instance objects; or objects from extension modules that don't support setattr) never anticipated. Like maybe a German translation of the object's docstrings; or a list of JPEG contents referenced by a URLish object; or a table of usage statistics on methods and functions; etc. Then it's natural to use the conceptual attr name as the name of a dict instead, and write attr[object] = whatever instead of object.attr = whatever There's no point keeping the "whatever" around when the object goes away, but a regular dict makes the object and its "whatever" immortal. A dict with weak keys is exactly on-target. ------------------------------------------------------- Date: 2001-Jan-16 19:14 By: fdrake Comment: I'm not entirely sure why one would want weak keys rather than weak values, but I suspect it has to do with expectations of how the dict will be used in applications. I don't think it would be hard to support both flavors of dictionaries using the primitive reference objects. The constructor does not check that all incoming values are weak because that isn't required. It uses self.update() rather than self.data.update() to perform the inclusion, so any mapping that supports .keys() and .__getitem__() is sufficient. Some additional checking could be done to make sure that all added entries can be created before inserting any of them, offering more atomicity. .get() will be fixed in the next version of the patch; thanks! I've added GC support, but don't have it working quite right. I'm trying to isolate the failure now. ------------------------------------------------------- Date: 2001-Jan-12 14:36 By: loewis Comment: The weak dictionary data type needs more clarification in documentation and implementation. In java.util.WeakHashMap, they keys are weak, not the values (i.e. once the key is forgotten, the entry is cleared). In http://www.handshake.de/~dieter/weakdict.html, the values are weak, but it raises KeyErrors for entries that are collected. The initializer of a weak dict does not check the invariant (all values are weak). get() of a weakdict does not support an optional second parameter. weakref and friends need to participate in garbage collection, as the reference to the callback can create a cycle. ------------------------------------------------------- Date: 2001-Jan-12 11:27 By: fdrake Comment: Updated patch to also support proxy semantics using the same invalidation machinery as the basic weak reference type. The additional code is *heavily* borrowed from Neil Schemenauer. ------------------------------------------------------- Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Sat Jan 20 19:07:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 20 Jan 2001 11:07:25 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: <E14K3MD-00054s-00@usw-sf-web3.sourceforge.net> Patch #103154 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-20 11:07 By: jlt63 Comment: Skip Montanaro and yourself (at least initially) suggested that this problem should be solved by renaming the modules in question (e.g., TERMIOS) so that they are unique regardless of case. As a following up, you suggested that "An even better solution is to get rid of those generated headers and incorporate the desired symbols directly in the C extension modules." If neither of the two solutions will make it into 2.1a, then I will lobby for the acceptance of my (albeit hacky) patch. It will only affect Cygwin Python and makes it behave identical to other UNIX versions. When a better solution is finally implemented, then the Cygwin cruft can be ripped out. ------------------------------------------------------- Date: 2001-Jan-20 08:47 By: gvanrossum Comment: Reopened at request. But I won't *do* anything about this until I've heard the arguments one more time. ------------------------------------------------------- Date: 2001-Jan-19 22:59 By: jlt63 Comment: Please reopen so that this issue is not accidentally overlooked. At least, until the case sensitive import problem is resolved. I still have a pending patch submitted for consideration. Sorry, to be a pest... ------------------------------------------------------- Date: 2001-Jan-12 11:48 By: tim_one Comment: Ah, I see. There's a difference between Windows filesystems and filesystems used on Windows <wink/sigh>. Older Novell network fileservers for Windows do indeed destroy the case of file names, and newer ones are often configured in a compatability mode to keep on doing that. At my last employer, more than half the LAN servers were set up that way. Use of PYTHONCASEOK was universal as a result. We were also screwed in that one of the popular Windows source-control systems *also* destroyed case (I didn't use that, and have forgotten the name): check in OhNo.py, check out OHNO.PY. Brrrrrrrrr. ------------------------------------------------------- Date: 2001-Jan-12 10:52 By: gvanrossum Comment: Maybe things are different now. But I definitely remember that when I introduced this test, Mark Hammond told me that there was a popular networking filesystem that didn't preserve case. This was either for Windows NT or Windows 95, so it's not a Windows 3.1 thing (although it's possible that the fileserver in question was a bad port from DOS or Windows 3.1 of course). ------------------------------------------------------- Date: 2001-Jan-12 10:47 By: jlt63 Comment: I know. I was just confused by the following On 2001-Jan-11 06:47, gvanrossum wrote: > Note that I believe that "import termios, TERMIOS" *should fail* -- not all > filesystems used on Windows are case preserving. ------------------------------------------------------- Date: 2001-Jan-12 10:26 By: tim_one Comment: The filesystems do preserve the case of names. But all platform file *lookup* APIs are case-insensitive. ------------------------------------------------------- Date: 2001-Jan-12 09:50 By: jlt63 Comment: Oops... Use the following procedure to patch: $ cd Python $ # save case.patch to current directory $ patch <case.patch ------------------------------------------------------- Date: 2001-Jan-12 09:44 By: jlt63 Comment: I just uploaded a new patch. It fixes the case sensitive import problem for Cygwin without affecting Win32 (i.e., Win32 functions as before). Now Cygwin's import behavior is identical to other UNIX platforms. I'm not completely happy with the patch and would characterize it as hacky, but it is the best that I can do without fully grokking import.c. I think to do better would require major rework to find_module(). I guess by renaming TERMIOS you mean to change the module names generated by h2py.py. I have no issue with this -- will others? I thought all filesystems on Windows 95/NT 3.51 and later, were case preserving. To what filesystems and Windows versions are you referring? ------------------------------------------------------- Date: 2001-Jan-11 13:59 By: gvanrossum Comment: Upload it as a new patch. But I believe the solution is that the TERMIOS module should be renamed. ------------------------------------------------------- Date: 2001-Jan-11 07:56 By: jlt63 Comment: Actually, this is not a bug in my original version. Cygwin Python is behaving identically to the Win32 one. Unfortunately, as you pointed out Win32 Python definitely does not handle the situation of two modules that only differ by case. Sigh... If one tries to import the second module that would be found in sys.path, then a NameError: Case mismatch ... exception will *always* be generated. I'm not sure that I agree with this behavior but I really a UNIX guy. Since Cygwin Python should support as many UNIX modules as possible, it needs to deal with modules that only differ by case. termios and TERMIOS used by getpass is a perfect example. I have created a (hacky) patch, that solves this problem for both Cygwin and Win32. I can redo it so that it only affects Cygwin and leaves the Win32 functionality alone. I would like to upload it for discussion but I am concerned about overwriting the old version. Should I upload it anyway? ------------------------------------------------------- Date: 2001-Jan-11 06:47 By: gvanrossum Comment: Reopened at request. Note that I believe that "import termios, TERMIOS" *should fail* -- not all filesystems used on Windows are case preserving. I've had this battle with Mark Hammond before. The case check is intended to prevent you from importing a moduleusing the wrong case (e.g. import String). It is *not* intended to let you have two modules that only differ in case. ------------------------------------------------------- Date: 2001-Jan-10 19:48 By: jlt63 Comment: I have already checked that this patch does not break the Windows VC build before I submitted it. However, Tim is welcome to reverify himself. Unfortunately, I have found a bug with this patch that (only) affects Cygwin. Although this patch handles the following: import String it does not handle the following: import termios, TERMIOS I will resubmit a new version shortly, please change the status back to open. ------------------------------------------------------- Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler <jt@dothill.com> * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Sat Jan 20 19:08:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 20 Jan 2001 11:08:34 -0800 Subject: [Patches] [Patch #103297] __all__ values for a handful of modules Message-ID: <E14K3NK-00012y-00@usw-sf-web1.sourceforge.net> Patch #103297 has been updated. Project: python Category: library Status: Open Submitted by: montanaro Assigned to : montanaro Summary: __all__ values for a handful of modules Follow-Ups: Date: 2001-Jan-20 11:08 By: montanaro Comment: Latest version - this takes me through dis.py, and throws in robotparser.py for good measure. ------------------------------------------------------- Date: 2001-Jan-19 17:49 By: tim_one Comment: I had wondered out loud whether test functions would get included in the context of the __exports__ patch, which was an unbreachable wall: I didn't want to be left with *no* way to execute a module's test function from within a different module. I agree that test functions should not be included in the context of __all__, though -- I can get at them whether or not they're in __all__, and they're not what an "import *" abuser wants to see anyway. ------------------------------------------------------- Date: 2001-Jan-19 14:43 By: gvanrossum Comment: So where's the next update? I would approve of adding this to the alpha1 release. ------------------------------------------------------- Date: 2001-Jan-18 18:32 By: gvanrossum Comment: Nice, Skip! I wonder if the "test" functions should really be included in __all__? Especially StringIO's test isn't generally needed. I'd be happy if I had to import it explicitly using "from StringIO import test" if I really wanted it. Ditto for the HTTP server classes. ------------------------------------------------------- Date: 2001-Jan-18 19:09 By: montanaro Comment: Yeah, I wondered about including "test". I included it only because I thought I remembered someone mentioning that in a previous thread. I'll remove "test" from __all__ in my next update. Assuming everything else is okay, I will keep adding to the number of modified modules. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103297&group_id=5470 From noreply@sourceforge.net Sat Jan 20 19:50:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 20 Jan 2001 11:50:29 -0800 Subject: [Patches] [Patch #103297] __all__ values for a handful of modules Message-ID: <E14K41t-0005J1-00@usw-sf-web3.sourceforge.net> Patch #103297 has been updated. Project: python Category: library Status: Open Submitted by: montanaro Assigned to : montanaro Summary: __all__ values for a handful of modules Follow-Ups: Date: 2001-Jan-20 11:50 By: montanaro Comment: whoops... (maybe SF should warn about this mistake?) okay, here it is for real. Includes a test___all__.py script and output as well. Please have a look at the test script and see if it seems suitable. In the meantime, I will check these things in and close the patch. ------------------------------------------------------- Date: 2001-Jan-20 11:35 By: gvanrossum Comment: Skip, I think your upload failed. Make sure that you click the "Upload Revised Patch" checkbox as well as specifying a file... (You can also just check this in, it all seems pretty harmless to me.) ------------------------------------------------------- Date: 2001-Jan-20 11:08 By: montanaro Comment: Latest version - this takes me through dis.py, and throws in robotparser.py for good measure. ------------------------------------------------------- Date: 2001-Jan-19 17:49 By: tim_one Comment: I had wondered out loud whether test functions would get included in the context of the __exports__ patch, which was an unbreachable wall: I didn't want to be left with *no* way to execute a module's test function from within a different module. I agree that test functions should not be included in the context of __all__, though -- I can get at them whether or not they're in __all__, and they're not what an "import *" abuser wants to see anyway. ------------------------------------------------------- Date: 2001-Jan-19 14:43 By: gvanrossum Comment: So where's the next update? I would approve of adding this to the alpha1 release. ------------------------------------------------------- Date: 2001-Jan-18 18:32 By: gvanrossum Comment: Nice, Skip! I wonder if the "test" functions should really be included in __all__? Especially StringIO's test isn't generally needed. I'd be happy if I had to import it explicitly using "from StringIO import test" if I really wanted it. Ditto for the HTTP server classes. ------------------------------------------------------- Date: 2001-Jan-18 19:09 By: montanaro Comment: Yeah, I wondered about including "test". I included it only because I thought I remembered someone mentioning that in a previous thread. I'll remove "test" from __all__ in my next update. Assuming everything else is okay, I will keep adding to the number of modified modules. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103297&group_id=5470 From noreply@sourceforge.net Sat Jan 20 19:33:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 20 Jan 2001 11:33:41 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: <E14K3ld-0001BH-00@usw-sf-web1.sourceforge.net> Patch #103154 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-20 11:33 By: gvanrossum Comment: Indeed, it's too late for 2.1a1 (now planned for Monday 1/22), but not for 2.1a2. It would be much more productive if you spent your time on adding the termios constants to that module, than lobbying for a hack that I oppose. ------------------------------------------------------- Date: 2001-Jan-20 11:07 By: jlt63 Comment: Skip Montanaro and yourself (at least initially) suggested that this problem should be solved by renaming the modules in question (e.g., TERMIOS) so that they are unique regardless of case. As a following up, you suggested that "An even better solution is to get rid of those generated headers and incorporate the desired symbols directly in the C extension modules." If neither of the two solutions will make it into 2.1a, then I will lobby for the acceptance of my (albeit hacky) patch. It will only affect Cygwin Python and makes it behave identical to other UNIX versions. When a better solution is finally implemented, then the Cygwin cruft can be ripped out. ------------------------------------------------------- Date: 2001-Jan-20 08:47 By: gvanrossum Comment: Reopened at request. But I won't *do* anything about this until I've heard the arguments one more time. ------------------------------------------------------- Date: 2001-Jan-19 22:59 By: jlt63 Comment: Please reopen so that this issue is not accidentally overlooked. At least, until the case sensitive import problem is resolved. I still have a pending patch submitted for consideration. Sorry, to be a pest... ------------------------------------------------------- Date: 2001-Jan-12 11:48 By: tim_one Comment: Ah, I see. There's a difference between Windows filesystems and filesystems used on Windows <wink/sigh>. Older Novell network fileservers for Windows do indeed destroy the case of file names, and newer ones are often configured in a compatability mode to keep on doing that. At my last employer, more than half the LAN servers were set up that way. Use of PYTHONCASEOK was universal as a result. We were also screwed in that one of the popular Windows source-control systems *also* destroyed case (I didn't use that, and have forgotten the name): check in OhNo.py, check out OHNO.PY. Brrrrrrrrr. ------------------------------------------------------- Date: 2001-Jan-12 10:52 By: gvanrossum Comment: Maybe things are different now. But I definitely remember that when I introduced this test, Mark Hammond told me that there was a popular networking filesystem that didn't preserve case. This was either for Windows NT or Windows 95, so it's not a Windows 3.1 thing (although it's possible that the fileserver in question was a bad port from DOS or Windows 3.1 of course). ------------------------------------------------------- Date: 2001-Jan-12 10:47 By: jlt63 Comment: I know. I was just confused by the following On 2001-Jan-11 06:47, gvanrossum wrote: > Note that I believe that "import termios, TERMIOS" *should fail* -- not all > filesystems used on Windows are case preserving. ------------------------------------------------------- Date: 2001-Jan-12 10:26 By: tim_one Comment: The filesystems do preserve the case of names. But all platform file *lookup* APIs are case-insensitive. ------------------------------------------------------- Date: 2001-Jan-12 09:50 By: jlt63 Comment: Oops... Use the following procedure to patch: $ cd Python $ # save case.patch to current directory $ patch <case.patch ------------------------------------------------------- Date: 2001-Jan-12 09:44 By: jlt63 Comment: I just uploaded a new patch. It fixes the case sensitive import problem for Cygwin without affecting Win32 (i.e., Win32 functions as before). Now Cygwin's import behavior is identical to other UNIX platforms. I'm not completely happy with the patch and would characterize it as hacky, but it is the best that I can do without fully grokking import.c. I think to do better would require major rework to find_module(). I guess by renaming TERMIOS you mean to change the module names generated by h2py.py. I have no issue with this -- will others? I thought all filesystems on Windows 95/NT 3.51 and later, were case preserving. To what filesystems and Windows versions are you referring? ------------------------------------------------------- Date: 2001-Jan-11 13:59 By: gvanrossum Comment: Upload it as a new patch. But I believe the solution is that the TERMIOS module should be renamed. ------------------------------------------------------- Date: 2001-Jan-11 07:56 By: jlt63 Comment: Actually, this is not a bug in my original version. Cygwin Python is behaving identically to the Win32 one. Unfortunately, as you pointed out Win32 Python definitely does not handle the situation of two modules that only differ by case. Sigh... If one tries to import the second module that would be found in sys.path, then a NameError: Case mismatch ... exception will *always* be generated. I'm not sure that I agree with this behavior but I really a UNIX guy. Since Cygwin Python should support as many UNIX modules as possible, it needs to deal with modules that only differ by case. termios and TERMIOS used by getpass is a perfect example. I have created a (hacky) patch, that solves this problem for both Cygwin and Win32. I can redo it so that it only affects Cygwin and leaves the Win32 functionality alone. I would like to upload it for discussion but I am concerned about overwriting the old version. Should I upload it anyway? ------------------------------------------------------- Date: 2001-Jan-11 06:47 By: gvanrossum Comment: Reopened at request. Note that I believe that "import termios, TERMIOS" *should fail* -- not all filesystems used on Windows are case preserving. I've had this battle with Mark Hammond before. The case check is intended to prevent you from importing a moduleusing the wrong case (e.g. import String). It is *not* intended to let you have two modules that only differ in case. ------------------------------------------------------- Date: 2001-Jan-10 19:48 By: jlt63 Comment: I have already checked that this patch does not break the Windows VC build before I submitted it. However, Tim is welcome to reverify himself. Unfortunately, I have found a bug with this patch that (only) affects Cygwin. Although this patch handles the following: import String it does not handle the following: import termios, TERMIOS I will resubmit a new version shortly, please change the status back to open. ------------------------------------------------------- Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler <jt@dothill.com> * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Sat Jan 20 19:41:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 20 Jan 2001 11:41:11 -0800 Subject: [Patches] [Patch #103329] Update poplib to use re Message-ID: <E14K3st-0001Da-00@usw-sf-web1.sourceforge.net> Patch #103329 has been updated. Project: python Category: library Status: Closed Submitted by: moshez Assigned to : moshez Summary: Update poplib to use re Follow-Ups: Date: 2001-Jan-19 12:00 By: moshez Comment: Checked in as version 1.12, beating the 3pm on Friday rule by 3 minutes. Unfortunately, my POP server doesn't support APOP, so please give it good testing. ------------------------------------------------------- Date: 2001-Jan-19 10:11 By: gvanrossum Comment: Assigned to Moshe. Thanks! Please check in ASAP! ------------------------------------------------------- Date: 2001-Jan-19 08:34 By: akuchling Comment: The patch looks correct after a quick reading. Moshe, go ahead and check it in. (Bonus points if you can actually test it against a POP server.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103329&group_id=5470 From noreply@sourceforge.net Sat Jan 20 19:35:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 20 Jan 2001 11:35:15 -0800 Subject: [Patches] [Patch #103297] __all__ values for a handful of modules Message-ID: <E14K3n9-0005EU-00@usw-sf-web3.sourceforge.net> Patch #103297 has been updated. Project: python Category: library Status: Open Submitted by: montanaro Assigned to : montanaro Summary: __all__ values for a handful of modules Follow-Ups: Date: 2001-Jan-20 11:35 By: gvanrossum Comment: Skip, I think your upload failed. Make sure that you click the "Upload Revised Patch" checkbox as well as specifying a file... (You can also just check this in, it all seems pretty harmless to me.) ------------------------------------------------------- Date: 2001-Jan-20 11:08 By: montanaro Comment: Latest version - this takes me through dis.py, and throws in robotparser.py for good measure. ------------------------------------------------------- Date: 2001-Jan-19 17:49 By: tim_one Comment: I had wondered out loud whether test functions would get included in the context of the __exports__ patch, which was an unbreachable wall: I didn't want to be left with *no* way to execute a module's test function from within a different module. I agree that test functions should not be included in the context of __all__, though -- I can get at them whether or not they're in __all__, and they're not what an "import *" abuser wants to see anyway. ------------------------------------------------------- Date: 2001-Jan-19 14:43 By: gvanrossum Comment: So where's the next update? I would approve of adding this to the alpha1 release. ------------------------------------------------------- Date: 2001-Jan-18 18:32 By: gvanrossum Comment: Nice, Skip! I wonder if the "test" functions should really be included in __all__? Especially StringIO's test isn't generally needed. I'd be happy if I had to import it explicitly using "from StringIO import test" if I really wanted it. Ditto for the HTTP server classes. ------------------------------------------------------- Date: 2001-Jan-18 19:09 By: montanaro Comment: Yeah, I wondered about including "test". I included it only because I thought I remembered someone mentioning that in a previous thread. I'll remove "test" from __all__ in my next update. Assuming everything else is okay, I will keep adding to the number of modified modules. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103297&group_id=5470 From noreply@sourceforge.net Sat Jan 20 19:55:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 20 Jan 2001 11:55:06 -0800 Subject: [Patches] [Patch #103297] __all__ values for a handful of modules Message-ID: <E14K46M-0001Hq-00@usw-sf-web1.sourceforge.net> Patch #103297 has been updated. Project: python Category: library Status: Closed Submitted by: montanaro Assigned to : montanaro Summary: __all__ values for a handful of modules Follow-Ups: Date: 2001-Jan-20 11:55 By: montanaro Comment: files checked in and patch closed. further addition of __all__ seems not to warrant patch submission. will get to them as I have time. ------------------------------------------------------- Date: 2001-Jan-20 11:50 By: montanaro Comment: whoops... (maybe SF should warn about this mistake?) okay, here it is for real. Includes a test___all__.py script and output as well. Please have a look at the test script and see if it seems suitable. In the meantime, I will check these things in and close the patch. ------------------------------------------------------- Date: 2001-Jan-20 11:35 By: gvanrossum Comment: Skip, I think your upload failed. Make sure that you click the "Upload Revised Patch" checkbox as well as specifying a file... (You can also just check this in, it all seems pretty harmless to me.) ------------------------------------------------------- Date: 2001-Jan-20 11:08 By: montanaro Comment: Latest version - this takes me through dis.py, and throws in robotparser.py for good measure. ------------------------------------------------------- Date: 2001-Jan-19 17:49 By: tim_one Comment: I had wondered out loud whether test functions would get included in the context of the __exports__ patch, which was an unbreachable wall: I didn't want to be left with *no* way to execute a module's test function from within a different module. I agree that test functions should not be included in the context of __all__, though -- I can get at them whether or not they're in __all__, and they're not what an "import *" abuser wants to see anyway. ------------------------------------------------------- Date: 2001-Jan-19 14:43 By: gvanrossum Comment: So where's the next update? I would approve of adding this to the alpha1 release. ------------------------------------------------------- Date: 2001-Jan-18 18:32 By: gvanrossum Comment: Nice, Skip! I wonder if the "test" functions should really be included in __all__? Especially StringIO's test isn't generally needed. I'd be happy if I had to import it explicitly using "from StringIO import test" if I really wanted it. Ditto for the HTTP server classes. ------------------------------------------------------- Date: 2001-Jan-18 19:09 By: montanaro Comment: Yeah, I wondered about including "test". I included it only because I thought I remembered someone mentioning that in a previous thread. I'll remove "test" from __all__ in my next update. Assuming everything else is okay, I will keep adding to the number of modified modules. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103297&group_id=5470 From noreply@sourceforge.net Sun Jan 21 13:20:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 05:20:50 -0800 Subject: [Patches] [Patch #103342] Make shutil.copytree more useful under Jython Message-ID: <E14KKQM-0005ou-00@usw-sf-web1.sourceforge.net> Patch #103342 has been updated. Project: python Category: library Status: Open Submitted by: bckfnn Assigned to : nobody Summary: Make shutil.copytree more useful under Jython ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103342&group_id=5470 From noreply@sourceforge.net Sun Jan 21 13:25:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 05:25:17 -0800 Subject: [Patches] [Patch #103343] Allow the important test_pkg to succeed under Jython Message-ID: <E14KKUf-0001Pr-00@usw-sf-web3.sourceforge.net> Patch #103343 has been updated. Project: python Category: library Status: Open Submitted by: bckfnn Assigned to : nobody Summary: Allow the important test_pkg to succeed under Jython ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103343&group_id=5470 From noreply@sourceforge.net Sun Jan 21 13:31:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 05:31:54 -0800 Subject: [Patches] [Patch #103344] Sort dicts from extcall for easier comparison with Jython Message-ID: <E14KKb4-0001RU-00@usw-sf-web3.sourceforge.net> Patch #103344 has been updated. Project: python Category: None Status: Open Submitted by: bckfnn Assigned to : nobody Summary: Sort dicts from extcall for easier comparison with Jython ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103344&group_id=5470 From noreply@sourceforge.net Sun Jan 21 13:39:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 05:39:55 -0800 Subject: [Patches] [Patch #103345] Avoid outdated exec form in test_class.py. Message-ID: <E14KKip-0005uB-00@usw-sf-web1.sourceforge.net> Patch #103345 has been updated. Project: python Category: library Status: Open Submitted by: bckfnn Assigned to : nobody Summary: Avoid outdated exec form in test_class.py. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103345&group_id=5470 From noreply@sourceforge.net Sun Jan 21 16:11:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 08:11:23 -0800 Subject: [Patches] [Patch #103349] Allow pickle.py to be using with Jython unicode strings Message-ID: <E14KN5P-0003Jn-00@usw-sf-web3.sourceforge.net> Patch #103349 has been updated. Project: python Category: library Status: Open Submitted by: bckfnn Assigned to : nobody Summary: Allow pickle.py to be using with Jython unicode strings ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103349&group_id=5470 From noreply@sourceforge.net Sun Jan 21 18:29:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 10:29:03 -0800 Subject: [Patches] [Patch #103344] Sort dicts from extcall for easier comparison with Jython Message-ID: <E14KPEd-0004lh-00@usw-sf-web2.sourceforge.net> Patch #103344 has been updated. Project: python Category: library Status: Open Submitted by: bckfnn Assigned to : tim_one Summary: Sort dicts from extcall for easier comparison with Jython ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103344&group_id=5470 From noreply@sourceforge.net Sun Jan 21 18:54:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 10:54:12 -0800 Subject: [Patches] [Patch #103344] Sort dicts from extcall for easier comparison with Jython Message-ID: <E14KPcy-0004tX-00@usw-sf-web2.sourceforge.net> Patch #103344 has been updated. Project: python Category: library Status: Closed Submitted by: bckfnn Assigned to : tim_one Summary: Sort dicts from extcall for easier comparison with Jython Follow-Ups: Date: 2001-Jan-21 10:54 By: tim_one Comment: Checked in, test_extcall.py rev 1.12, output/test_extcall rev 1.7. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103344&group_id=5470 From noreply@sourceforge.net Sun Jan 21 19:53:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 11:53:21 -0800 Subject: [Patches] [Patch #103343] Allow the important test_pkg to succeed under Jython Message-ID: <E14KQYD-0004SI-00@usw-sf-web3.sourceforge.net> Patch #103343 has been updated. Project: python Category: library Status: Closed Submitted by: bckfnn Assigned to : tim_one Summary: Allow the important test_pkg to succeed under Jython Follow-Ups: Date: 2001-Jan-21 11:53 By: tim_one Comment: Checked in, test_pkg.py rev 1.12, output/test_pkg rev 1.6 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103343&group_id=5470 From noreply@sourceforge.net Sun Jan 21 20:00:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 12:00:40 -0800 Subject: [Patches] [Patch #103342] Make shutil.copytree more useful under Jython Message-ID: <E14KQfI-0004VI-00@usw-sf-web3.sourceforge.net> Patch #103342 has been updated. Project: python Category: library Status: Closed Submitted by: bckfnn Assigned to : tim_one Summary: Make shutil.copytree more useful under Jython Follow-Ups: Date: 2001-Jan-21 12:00 By: tim_one Comment: Checked in, shutil.py rev 1.19. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103342&group_id=5470 From noreply@sourceforge.net Mon Jan 22 03:00:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 19:00:24 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: <E14KXDU-0002cM-00@usw-sf-web1.sourceforge.net> Patch #103154 has been updated. Project: python Category: core (C code) Status: Open Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Jan-21 19:00 By: jlt63 Comment: My intentions when I asked you to reopen this patch were to determine whether consensus was reached on how to resolve this issue, not to provoke you in any way. If I did, then I apologize. From your previous comments, it was not clear that you opposed this patch. Now that I know, I will desist with this approach. I'm willing to do as you suggest, but I have the following concerns: 1. At least two more modules that will need this conversion too (i.e., FCNTL and SOCKET). Are there more? 2. Unless there is some (enforceable) policy that module names cannot differ only in case, then Cygwin Python will behave differently than other UNIX versions in this regard. Can you allay my concerns before I set out on this endeavor. BTW, when is 2.1a2 scheduled so I know how much time that I have? ------------------------------------------------------- Date: 2001-Jan-20 11:33 By: gvanrossum Comment: Indeed, it's too late for 2.1a1 (now planned for Monday 1/22), but not for 2.1a2. It would be much more productive if you spent your time on adding the termios constants to that module, than lobbying for a hack that I oppose. ------------------------------------------------------- Date: 2001-Jan-20 11:07 By: jlt63 Comment: Skip Montanaro and yourself (at least initially) suggested that this problem should be solved by renaming the modules in question (e.g., TERMIOS) so that they are unique regardless of case. As a following up, you suggested that "An even better solution is to get rid of those generated headers and incorporate the desired symbols directly in the C extension modules." If neither of the two solutions will make it into 2.1a, then I will lobby for the acceptance of my (albeit hacky) patch. It will only affect Cygwin Python and makes it behave identical to other UNIX versions. When a better solution is finally implemented, then the Cygwin cruft can be ripped out. ------------------------------------------------------- Date: 2001-Jan-20 08:47 By: gvanrossum Comment: Reopened at request. But I won't *do* anything about this until I've heard the arguments one more time. ------------------------------------------------------- Date: 2001-Jan-19 22:59 By: jlt63 Comment: Please reopen so that this issue is not accidentally overlooked. At least, until the case sensitive import problem is resolved. I still have a pending patch submitted for consideration. Sorry, to be a pest... ------------------------------------------------------- Date: 2001-Jan-12 11:48 By: tim_one Comment: Ah, I see. There's a difference between Windows filesystems and filesystems used on Windows <wink/sigh>. Older Novell network fileservers for Windows do indeed destroy the case of file names, and newer ones are often configured in a compatability mode to keep on doing that. At my last employer, more than half the LAN servers were set up that way. Use of PYTHONCASEOK was universal as a result. We were also screwed in that one of the popular Windows source-control systems *also* destroyed case (I didn't use that, and have forgotten the name): check in OhNo.py, check out OHNO.PY. Brrrrrrrrr. ------------------------------------------------------- Date: 2001-Jan-12 10:52 By: gvanrossum Comment: Maybe things are different now. But I definitely remember that when I introduced this test, Mark Hammond told me that there was a popular networking filesystem that didn't preserve case. This was either for Windows NT or Windows 95, so it's not a Windows 3.1 thing (although it's possible that the fileserver in question was a bad port from DOS or Windows 3.1 of course). ------------------------------------------------------- Date: 2001-Jan-12 10:47 By: jlt63 Comment: I know. I was just confused by the following On 2001-Jan-11 06:47, gvanrossum wrote: > Note that I believe that "import termios, TERMIOS" *should fail* -- not all > filesystems used on Windows are case preserving. ------------------------------------------------------- Date: 2001-Jan-12 10:26 By: tim_one Comment: The filesystems do preserve the case of names. But all platform file *lookup* APIs are case-insensitive. ------------------------------------------------------- Date: 2001-Jan-12 09:50 By: jlt63 Comment: Oops... Use the following procedure to patch: $ cd Python $ # save case.patch to current directory $ patch <case.patch ------------------------------------------------------- Date: 2001-Jan-12 09:44 By: jlt63 Comment: I just uploaded a new patch. It fixes the case sensitive import problem for Cygwin without affecting Win32 (i.e., Win32 functions as before). Now Cygwin's import behavior is identical to other UNIX platforms. I'm not completely happy with the patch and would characterize it as hacky, but it is the best that I can do without fully grokking import.c. I think to do better would require major rework to find_module(). I guess by renaming TERMIOS you mean to change the module names generated by h2py.py. I have no issue with this -- will others? I thought all filesystems on Windows 95/NT 3.51 and later, were case preserving. To what filesystems and Windows versions are you referring? ------------------------------------------------------- Date: 2001-Jan-11 13:59 By: gvanrossum Comment: Upload it as a new patch. But I believe the solution is that the TERMIOS module should be renamed. ------------------------------------------------------- Date: 2001-Jan-11 07:56 By: jlt63 Comment: Actually, this is not a bug in my original version. Cygwin Python is behaving identically to the Win32 one. Unfortunately, as you pointed out Win32 Python definitely does not handle the situation of two modules that only differ by case. Sigh... If one tries to import the second module that would be found in sys.path, then a NameError: Case mismatch ... exception will *always* be generated. I'm not sure that I agree with this behavior but I really a UNIX guy. Since Cygwin Python should support as many UNIX modules as possible, it needs to deal with modules that only differ by case. termios and TERMIOS used by getpass is a perfect example. I have created a (hacky) patch, that solves this problem for both Cygwin and Win32. I can redo it so that it only affects Cygwin and leaves the Win32 functionality alone. I would like to upload it for discussion but I am concerned about overwriting the old version. Should I upload it anyway? ------------------------------------------------------- Date: 2001-Jan-11 06:47 By: gvanrossum Comment: Reopened at request. Note that I believe that "import termios, TERMIOS" *should fail* -- not all filesystems used on Windows are case preserving. I've had this battle with Mark Hammond before. The case check is intended to prevent you from importing a moduleusing the wrong case (e.g. import String). It is *not* intended to let you have two modules that only differ in case. ------------------------------------------------------- Date: 2001-Jan-10 19:48 By: jlt63 Comment: I have already checked that this patch does not break the Windows VC build before I submitted it. However, Tim is welcome to reverify himself. Unfortunately, I have found a bug with this patch that (only) affects Cygwin. Although this patch handles the following: import String it does not handle the following: import termios, TERMIOS I will resubmit a new version shortly, please change the status back to open. ------------------------------------------------------- Date: 2001-Jan-10 12:45 By: gvanrossum Comment: Thanks -- checked in! Note: I didn't check this on Cygwin -- I only tested that this doesn't break the build on Linux. I hope that Tim will check that it doesn't break the VC build on Windows. ------------------------------------------------------- Date: 2001-Jan-08 21:11 By: jlt63 Comment: [The formating was lost on my initial post, so I try again. Sigh...] This patch enables the imported module name case checking code for Cygwin that is already enabled by default for Win32. Use the configure --with-check-import-case option to enable this feature. Without this patch, the following code from getpass.getuser() behaves incorrectly: import termios, TERMIOS The folowing is a ChangeLog: Mon Jan 8 23:54:00 2001 Jason Tishler <jt@dothill.com> * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Mon Jan 22 03:04:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 19:04:37 -0800 Subject: [Patches] [Patch #103185] Some more standard modules cleanup for Cygwin Message-ID: <E14KXHZ-0002dT-00@usw-sf-web1.sourceforge.net> Patch #103185 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Some more standard modules cleanup for Cygwin Follow-Ups: Date: 2001-Jan-21 19:04 By: jlt63 Comment: Please reopen to facilitate the inclusion of this patch into alpha 2. ------------------------------------------------------- Date: 2001-Jan-19 22:38 By: jlt63 Comment: A few more courtesy of the Distutils style Python build. Note that Modules/syslogmodule.c will *not* build cleanly until I submit a minor patch to Cygwin to resolve this issue. To patch, change directory to the top of the CVS tree and use $ patch -p0 <mods.patch ------------------------------------------------------- Date: 2001-Jan-18 16:29 By: gvanrossum Comment: Applied, and closed. ------------------------------------------------------- Date: 2001-Jan-10 21:19 By: jlt63 Comment: Use the following procedure to patch: $ cd Modules $ # save modules.patch to current directory $ patch <modules.patch ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103185&group_id=5470 From noreply@sourceforge.net Mon Jan 22 04:25:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 20:25:01 -0800 Subject: [Patches] [Patch #102588] PEP 229: Use Distutils to build Message-ID: <E14KYXN-00030R-00@usw-sf-web1.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: 2001-Jan-21 20:25 By: jlt63 Comment: While working on the build so that Cygwin Python builds OOTB again, I found the following issues now that Python is using Distutils intrinsically: 1. setup.py needs to improve its ability to select only platform appropriate modules. I believe that this has already been discussed on python-dev. 2. make install is not passing $(prefix) to setup.py so the standard extension modules are always installed in the configured location and cannot be overridden at install time. 3. make install fails during the regen step for platforms that do not have a Lib/platform-foo in CVS. This is due to PYTHONPATH no longer being set correctly. 4. Most of the standard extension modules have different filenames (i.e., missing "module") than they had in 2.0. For example on Linux, the socket module was called _socketmodule.so -- now it is called _socket.so. FYI, I have submitted the following patch: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 which has a Cygwin specific solution for 1 and platform independent solutions for 2 and 3. I just noticed your comment regarding setup.cfg, but maybe my "solution" to 2 will prove useful anyway. ------------------------------------------------------- Date: 2001-Jan-16 14:53 By: akuchling Comment: I've made an updated version of the patch; because it's 55K, SF won't accept it, so I've put it at http://www.mems-exchange.org/software/files/python/pep229.patch. There are only a very few things left to fix at this point: * setup.cfg hard-wires the installation directory because it has no access to a variable holding the installation prefix * installs in subdirectories don't work because setup.cfg is only found in the current directory. I think those are the only two remaining issues before this can be checked in (doubtless causing the sun to explode). ------------------------------------------------------- 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 Jan 22 14:51:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 06:51:48 -0800 Subject: [Patches] [Patch #103345] Avoid outdated exec form in test_class.py. Message-ID: <E14KiJw-000297-00@usw-sf-web3.sourceforge.net> Patch #103345 has been updated. Project: python Category: library Status: Closed Submitted by: bckfnn Assigned to : nobody Summary: Avoid outdated exec form in test_class.py. Follow-Ups: Date: 2001-Jan-22 06:51 By: gvanrossum Comment: Done! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103345&group_id=5470 From noreply@sourceforge.net Mon Jan 22 14:53:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 06:53:38 -0800 Subject: [Patches] [Patch #103349] Allow pickle.py to be using with Jython unicode strings Message-ID: <E14KiLi-0002AL-00@usw-sf-web3.sourceforge.net> Patch #103349 has been updated. Project: python Category: library Status: Closed Submitted by: bckfnn Assigned to : nobody Summary: Allow pickle.py to be using with Jython unicode strings Follow-Ups: Date: 2001-Jan-22 06:53 By: gvanrossum Comment: Done. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103349&group_id=5470 From noreply@sourceforge.net Mon Jan 22 15:27:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 07:27:58 -0800 Subject: [Patches] [Patch #103318] non-recursive makefile Message-ID: <E14Kisw-0002NZ-00@usw-sf-web3.sourceforge.net> Patch #103318 has been updated. Project: python Category: Build Status: Open Submitted by: nascheme Assigned to : nascheme Summary: non-recursive makefile Follow-Ups: Date: 2001-Jan-22 07:27 By: nascheme Comment: Cleaned up Cygwin build. Tested with lastest Cygwin on Win98. Added (some?) header file dependencies. Partially merged Linux .so patch. Signal module is now enabled by configure. Things are looking good. I only have access to Linux, Cygwin, and Solaris. Please test on other platforms. ------------------------------------------------------- Date: 2001-Jan-19 14:44 By: gvanrossum Comment: Let's put this off until after the 2.1a1 release. It should go into 2.1a2 though, and probably should be checked in soon after 2.1a1 is released. ------------------------------------------------------- Date: 2001-Jan-19 10:13 By: nascheme Comment: Fix silly bug ("! test -f" instead of "test ! -f" in configure.in). ------------------------------------------------------- Date: 2001-Jan-18 20:43 By: nascheme Comment: New patch. I think makesetup works as it should. There is one issue with MAKE_LDLIBRARY on cygwin but it should be easy to fix. Object files for threads and dynamic loading show be okay now. I might be missing a few "clean" targets. I removed a bunch of "foo.o: $(srcdir)/foo.c" lines. As far as I can tell they are useless. Any make that supports VPATH should be able to figure out where to get the source. Other makes can look in the same dir as the source file. Surely they are not that broken. Guido, do you know if there was a good reason for these lines? Building with GNU make works great for any situation I can think of. pmake is not smart enough to re-read the makefile if it got updated. I don't know of any way around that. Building in a separate dir works fine. I didn't do buildno because I like to type "make" and see the prompt come back right away. What is buildno for and when should it be incremented? ------------------------------------------------------- Date: 2001-Jan-18 18:56 By: gvanrossum Comment: I'm in a quandary. This is really awesone! But a bit too rough to add to the 2.1a1 release. You don't seem to deal with buildno properly -- what's the problem there? Also, I seem to recall that the "-o file.o" option is not universal amongst C compilers. Could someone who uses a non-GCC compiler (e.g. SunPro, or HP, or AIX) check the portability of this Makefile? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103318&group_id=5470 From noreply@sourceforge.net Mon Jan 22 15:38:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 07:38:24 -0800 Subject: [Patches] [Patch #103185] Some more standard modules cleanup for Cygwin Message-ID: <E14Kj32-0003M9-00@usw-sf-web2.sourceforge.net> Patch #103185 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Some more standard modules cleanup for Cygwin Follow-Ups: Date: 2001-Jan-22 07:38 By: gvanrossum Comment: Done, still in 2.1a1. Note that the socket patch had to be fixed, the SSL struct only exists whn USE_SSL is defined. ------------------------------------------------------- Date: 2001-Jan-21 19:04 By: jlt63 Comment: Please reopen to facilitate the inclusion of this patch into alpha 2. ------------------------------------------------------- Date: 2001-Jan-19 22:38 By: jlt63 Comment: A few more courtesy of the Distutils style Python build. Note that Modules/syslogmodule.c will *not* build cleanly until I submit a minor patch to Cygwin to resolve this issue. To patch, change directory to the top of the CVS tree and use $ patch -p0 <mods.patch ------------------------------------------------------- Date: 2001-Jan-18 16:29 By: gvanrossum Comment: Applied, and closed. ------------------------------------------------------- Date: 2001-Jan-10 21:19 By: jlt63 Comment: Use the following procedure to patch: $ cd Modules $ # save modules.patch to current directory $ patch <modules.patch ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103185&group_id=5470 From noreply@sourceforge.net Mon Jan 22 15:40:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 07:40:38 -0800 Subject: [Patches] [Patch #103185] Some more standard modules cleanup for Cygwin Message-ID: <E14Kj5C-0003NG-00@usw-sf-web2.sourceforge.net> Patch #103185 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Some more standard modules cleanup for Cygwin Follow-Ups: Date: 2001-Jan-22 07:40 By: gvanrossum Comment: PS please submit new patches as a new patch entry, reopening closed patches is not the right procedure (and is likely to be lost, as nobody scans old patches for new comments, and the mail notifications are prone to being drupped during times of heavy email :-). ------------------------------------------------------- Date: 2001-Jan-22 07:38 By: gvanrossum Comment: Done, still in 2.1a1. Note that the socket patch had to be fixed, the SSL struct only exists whn USE_SSL is defined. ------------------------------------------------------- Date: 2001-Jan-21 19:04 By: jlt63 Comment: Please reopen to facilitate the inclusion of this patch into alpha 2. ------------------------------------------------------- Date: 2001-Jan-19 22:38 By: jlt63 Comment: A few more courtesy of the Distutils style Python build. Note that Modules/syslogmodule.c will *not* build cleanly until I submit a minor patch to Cygwin to resolve this issue. To patch, change directory to the top of the CVS tree and use $ patch -p0 <mods.patch ------------------------------------------------------- Date: 2001-Jan-18 16:29 By: gvanrossum Comment: Applied, and closed. ------------------------------------------------------- Date: 2001-Jan-10 21:19 By: jlt63 Comment: Use the following procedure to patch: $ cd Modules $ # save modules.patch to current directory $ patch <modules.patch ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103185&group_id=5470 From noreply@sourceforge.net Mon Jan 22 16:11:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 08:11:44 -0800 Subject: [Patches] [Patch #103185] Some more standard modules cleanup for Cygwin Message-ID: <E14KjZI-0002en-00@usw-sf-web3.sourceforge.net> Patch #103185 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Some more standard modules cleanup for Cygwin Follow-Ups: Date: 2001-Jan-22 08:11 By: jlt63 Comment: > Done, still in 2.1a1. Thanks. > Note that the socket patch had to be fixed, ... Oops, thanks for cleaning up after me. > PS please submit new patches as a new patch entry, ... Will do. ------------------------------------------------------- Date: 2001-Jan-22 07:40 By: gvanrossum Comment: PS please submit new patches as a new patch entry, reopening closed patches is not the right procedure (and is likely to be lost, as nobody scans old patches for new comments, and the mail notifications are prone to being drupped during times of heavy email :-). ------------------------------------------------------- Date: 2001-Jan-22 07:38 By: gvanrossum Comment: Done, still in 2.1a1. Note that the socket patch had to be fixed, the SSL struct only exists whn USE_SSL is defined. ------------------------------------------------------- Date: 2001-Jan-21 19:04 By: jlt63 Comment: Please reopen to facilitate the inclusion of this patch into alpha 2. ------------------------------------------------------- Date: 2001-Jan-19 22:38 By: jlt63 Comment: A few more courtesy of the Distutils style Python build. Note that Modules/syslogmodule.c will *not* build cleanly until I submit a minor patch to Cygwin to resolve this issue. To patch, change directory to the top of the CVS tree and use $ patch -p0 <mods.patch ------------------------------------------------------- Date: 2001-Jan-18 16:29 By: gvanrossum Comment: Applied, and closed. ------------------------------------------------------- Date: 2001-Jan-10 21:19 By: jlt63 Comment: Use the following procedure to patch: $ cd Modules $ # save modules.patch to current directory $ patch <modules.patch ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103185&group_id=5470 From noreply@sourceforge.net Mon Jan 22 22:01:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 14:01:03 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14Kp1L-0004xf-00@usw-sf-web3.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : nascheme Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-22 14:01 By: fdrake Comment: Removed the .clear() method from reference objects. Made proxy objects unhashable -- the semantics of hashing something that can mutate in fundamental ways is pretty painful; just don't use these as dictionary keys! Added strong warnings to the documentation that proxy semantics may change a bit before the final release that the weak dictionaries are unclear -- additional feedback is requested. These are not thread-safe. ------------------------------------------------------- Date: 2001-Jan-20 09:42 By: gvanrossum Comment: I think callbacks are needed to implement various forms of weak dicts: when the object is deleted, whatever's in the weak dict for it should be deleted as well. Even though we may not provide weak dicts in 2.1a1, we should still support writing them using what we *do* provide. IMHO (I still haven't had the time to read the PEP or Fred's code. :-( ) ------------------------------------------------------- Date: 2001-Jan-20 09:12 By: nascheme Comment: Why do weak references need callbacks? I see nothing in the PEP to justify this feature. If there is no good reason for them, I propose that the feature be removed for 2.1. Allowing callbacks may make it harder to implement weak references more efficiently later. ------------------------------------------------------- Date: 2001-Jan-18 16:03 By: loewis Comment: The patch looks ok in general, pending resolution of the issues on the PEP itself. Some nits: Integration with GC is still fuzzy. If an instance is GC collected and had a weak ref to it and the weak ref had a callback and the callback choses to resurrect the object, semantics is unclear. This is equivalent to the object having an __del__; the GC would normally *not* collect such objects, but put them into gc.garbage. Proposed resolution: it is a fatal error to resurrect an object in a weakref callback. Hashing: it appears that the hash of a weakref can change when the underlying object goes away. If the weakref is used as key in a dictionary, it appears to be impossible to get the key out of the dictionary after the underlying object is gone. Proposed resolution: a proxy weak ref should cache the hash of the underlying object after its hash function was called for the first time. Comparing: why is the return value of tp_compare -1 when try_3way_compare expects -2 on error? Shouldn't there be some exception set when the underlying object goes away? ------------------------------------------------------- Date: 2001-Jan-17 13:53 By: fdrake Comment: Ok, I tihnk this is it! http://starship.python.net/crew/fdrake/patches/weakref.patch-5 This patch fixes the compilation problems from the previoous patch related to the introduction of rich comparisons, and makes a change in the way new objects are initialized by PyObject_New() and PyObject_NEW() (and all their friends!) -- those functions now know to initialize the weak reference list to NULL for objects which support weak references. Without this change, more places in the code (especially extension modules) need to know more about initialization of weakly-referencable objects. For instance, the "cPickle" and "new" modules both can create instances without calling the code in classobject.c (using PyObject_New()), causing core dumps when such instances are deallocated if the weak-reference list for instances was not properly initialized. Since these modules (properly) tried to avoid call PyInstance_New(), core dumps ensued and the world fell apart. By moving the initialization of the weak reference list into the core object allocators, this problem is averted and extension code to construct new weakly referencable types is simplified. The documentation still needs work, and there are a few new entries for the Python/C API manual as well. A new constructor for instances, PyInstance_NewRaw(), will be added in a separate patch. ------------------------------------------------------- Date: 2001-Jan-17 11:58 By: nascheme Comment: The magic test is: ./python Lib/test/regrtest.py test_weakref test_new Try adding this patch: --- Modules/newmodule.c 2000/11/13 20:29:20 2.29 +++ Modules/newmodule.c 2001/01/17 19:55:46 @@ -24,6 +24,7 @@ Py_INCREF(dict); inst->in_class = (PyClassObject *)klass; inst->in_dict = dict; + inst->in_weakreflist = NULL; PyObject_GC_Init(inst); return (PyObject *)inst; } ------------------------------------------------------- Date: 2001-Jan-17 08:04 By: fdrake Comment: New version of the patch that's still broken but doesn't conflict with the rich comparisons changes: http://starship.python.net/crew/fdrake/patches/weakref.patch-4 ------------------------------------------------------- Date: 2001-Jan-16 21:35 By: fdrake Comment: Added a new (but broken!) version of the patch that fixes WeakDictionary.get() but doesn't interact properly with GC (appearantly) -- not usable as is: http://starship.python.net/crew/fdrake/patches/weakref.patch-3 Neil made the mistake of volunteering to look at the current problem, so assigning to him. (Thanks!) ------------------------------------------------------- Date: 2001-Jan-16 19:39 By: tim_one Comment: Just mentioning a general scenario in which weak keys are the bee's knees: sometimes you want to add attributes to objects dynamically, in ways the original class author(s -- may cut across many classes! even non-instance objects; or objects from extension modules that don't support setattr) never anticipated. Like maybe a German translation of the object's docstrings; or a list of JPEG contents referenced by a URLish object; or a table of usage statistics on methods and functions; etc. Then it's natural to use the conceptual attr name as the name of a dict instead, and write attr[object] = whatever instead of object.attr = whatever There's no point keeping the "whatever" around when the object goes away, but a regular dict makes the object and its "whatever" immortal. A dict with weak keys is exactly on-target. ------------------------------------------------------- Date: 2001-Jan-16 19:14 By: fdrake Comment: I'm not entirely sure why one would want weak keys rather than weak values, but I suspect it has to do with expectations of how the dict will be used in applications. I don't think it would be hard to support both flavors of dictionaries using the primitive reference objects. The constructor does not check that all incoming values are weak because that isn't required. It uses self.update() rather than self.data.update() to perform the inclusion, so any mapping that supports .keys() and .__getitem__() is sufficient. Some additional checking could be done to make sure that all added entries can be created before inserting any of them, offering more atomicity. .get() will be fixed in the next version of the patch; thanks! I've added GC support, but don't have it working quite right. I'm trying to isolate the failure now. ------------------------------------------------------- Date: 2001-Jan-12 14:36 By: loewis Comment: The weak dictionary data type needs more clarification in documentation and implementation. In java.util.WeakHashMap, they keys are weak, not the values (i.e. once the key is forgotten, the entry is cleared). In http://www.handshake.de/~dieter/weakdict.html, the values are weak, but it raises KeyErrors for entries that are collected. The initializer of a weak dict does not check the invariant (all values are weak). get() of a weakdict does not support an optional second parameter. weakref and friends need to participate in garbage collection, as the reference to the callback can create a cycle. ------------------------------------------------------- Date: 2001-Jan-12 11:27 By: fdrake Comment: Updated patch to also support proxy semantics using the same invalidation machinery as the basic weak reference type. The additional code is *heavily* borrowed from Neil Schemenauer. ------------------------------------------------------- Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Tue Jan 23 16:15:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 08:15:54 -0800 Subject: [Patches] [Patch #103373] zlib sync-flush fix Message-ID: <E14L66s-0000ZA-00@usw-sf-web1.sourceforge.net> Patch #103373 has been updated. Project: python Category: Modules Status: Open Submitted by: abo Assigned to : nobody Summary: zlib sync-flush fix ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103373&group_id=5470 From noreply@sourceforge.net Tue Jan 23 16:26:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 08:26:37 -0800 Subject: [Patches] [Patch #103373] zlib sync-flush fix Message-ID: <E14L6HF-0005Et-00@usw-sf-web2.sourceforge.net> Patch #103373 has been updated. Project: python Category: Modules Status: Open Submitted by: abo Assigned to : nobody Summary: zlib sync-flush fix Follow-Ups: Date: 2001-Jan-23 08:26 By: nobody Comment: Argh... my line by line fix list got munged. You'll have to apply imaginary comments to delimit each fix. The bug this fixes is 124981 "zlib decompress of sync-flushed data fails" A lot of the patch changes are simply whitespace changes to clean up the formating. The patch can probably be edited to only include the changes to the PyZlib_objdecompress routine to fix the most important bug, but this would leave the code even more inconsistant than it is. Most of the rest of the fixes are to make the other routines cleaner, though they do also fix the minor bugs mentioned. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103373&group_id=5470 From noreply@sourceforge.net Tue Jan 23 23:07:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 15:07:08 -0800 Subject: [Patches] [Patch #103373] zlib sync-flush fix Message-ID: <E14LCWq-0006p4-00@usw-sf-web3.sourceforge.net> Patch #103373 has been updated. Project: python Category: Modules Status: Open Submitted by: abo Assigned to : akuchling Summary: zlib sync-flush fix Follow-Ups: Date: 2001-Jan-23 08:26 By: nobody Comment: Argh... my line by line fix list got munged. You'll have to apply imaginary comments to delimit each fix. The bug this fixes is 124981 "zlib decompress of sync-flushed data fails" A lot of the patch changes are simply whitespace changes to clean up the formating. The patch can probably be edited to only include the changes to the PyZlib_objdecompress routine to fix the most important bug, but this would leave the code even more inconsistant than it is. Most of the rest of the fixes are to make the other routines cleaner, though they do also fix the minor bugs mentioned. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103373&group_id=5470 From noreply@sourceforge.net Wed Jan 24 02:26:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 18:26:45 -0800 Subject: [Patches] [Patch #103052] Restore non-cyclic operation of pulldom.PullDOM Message-ID: <E14LFe1-0004aK-00@usw-sf-web1.sourceforge.net> Patch #103052 has been updated. Project: python Category: XML Status: Accepted Submitted by: loewis Assigned to : prescod Summary: Restore non-cyclic operation of pulldom.PullDOM Follow-Ups: Date: 2001-Jan-23 18:26 By: akuchling Comment: The patch appears correct as far as I can tell. Note that I'm not that familiar with pulldom; marking as accepted and also assigning to Paul Prescod, in case he can find time to look at it before Martin checks it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103052&group_id=5470 From noreply@sourceforge.net Wed Jan 24 02:55:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 18:55:02 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: <E14LG5O-0001IP-00@usw-sf-web2.sourceforge.net> Patch #102409 has been updated. Project: python Category: Build Status: Open Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-23 18:55 By: akuchling Comment: Looking at the Makefile.in part of this patch, why is the --install-platlib argument needed. The setup.cfg file should be handling this... or does it do the wrong thing somehow? ------------------------------------------------------- Date: 2001-Jan-19 22:31 By: jlt63 Comment: This patch enables Cygwin Python to build using the new Distutils style Python build. Please note that the build_ext.py part is from Jorge Sousa <jsousa@cfn.ist.utl.pt>. To patch, change directory to the top of the CVS tree and use $ patch -p0 <dist.patch The following is the ChangeLog: Sat Jan 20 01:05:18 2001 Jason Tishler <jt@dothill.com> * Makefile.in($(srcdir)/Lib/$(PLATDIR)): Add Distutils build library directory to PYTHONPATH so regen works again. (sharedinstall): Add --install-platlib option so shared extensions follow $(exec_prefix). * setup.py: Add checks for Cygwin so unsupported modules (i.e., dbm and resource) are not built. * Lib/distutils/command/build_ext.py(build_ext.finalize_options): Add Cygwin specific code to append Python's library directory to the extension's list of library directories. (build_ext.get_libraries): Add Cygwin specific code to append Python's (import) library to the extension's list of libraries. ------------------------------------------------------- Date: 2001-Jan-19 08:19 By: gvanrossum Comment: Reopened at request. Don't sweat the release date -- t's only the first alpha release. I have a feeling it'll be put off till Monday. ------------------------------------------------------- Date: 2001-Jan-18 20:52 By: jlt63 Comment: Please reopen because I need to redo the Cygwin build to handle the use of distutils to build the standard extension modules instead of Modules/Makefile.pre.in. How much time (if any) do I have to resolve these issues before 2.1a is released. I heard that the release date is tomorrow. Sigh... ------------------------------------------------------- Date: 2001-Jan-10 19:39 By: jlt63 Comment: Your welcome -- thanks for considering and accepting this patch. If the patch proves to reek havoc on other platforms (most likely only on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out. ------------------------------------------------------- Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 <Cygwin-1.1.5-Python-2.0.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Wed Jan 24 03:05:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 19:05:40 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: <E14LGFg-0004ql-00@usw-sf-web1.sourceforge.net> Patch #102409 has been updated. Project: python Category: Build Status: Open Submitted by: jlt63 Assigned to : akuchling Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-23 18:55 By: akuchling Comment: Looking at the Makefile.in part of this patch, why is the --install-platlib argument needed. The setup.cfg file should be handling this... or does it do the wrong thing somehow? ------------------------------------------------------- Date: 2001-Jan-19 22:31 By: jlt63 Comment: This patch enables Cygwin Python to build using the new Distutils style Python build. Please note that the build_ext.py part is from Jorge Sousa <jsousa@cfn.ist.utl.pt>. To patch, change directory to the top of the CVS tree and use $ patch -p0 <dist.patch The following is the ChangeLog: Sat Jan 20 01:05:18 2001 Jason Tishler <jt@dothill.com> * Makefile.in($(srcdir)/Lib/$(PLATDIR)): Add Distutils build library directory to PYTHONPATH so regen works again. (sharedinstall): Add --install-platlib option so shared extensions follow $(exec_prefix). * setup.py: Add checks for Cygwin so unsupported modules (i.e., dbm and resource) are not built. * Lib/distutils/command/build_ext.py(build_ext.finalize_options): Add Cygwin specific code to append Python's library directory to the extension's list of library directories. (build_ext.get_libraries): Add Cygwin specific code to append Python's (import) library to the extension's list of libraries. ------------------------------------------------------- Date: 2001-Jan-19 08:19 By: gvanrossum Comment: Reopened at request. Don't sweat the release date -- t's only the first alpha release. I have a feeling it'll be put off till Monday. ------------------------------------------------------- Date: 2001-Jan-18 20:52 By: jlt63 Comment: Please reopen because I need to redo the Cygwin build to handle the use of distutils to build the standard extension modules instead of Modules/Makefile.pre.in. How much time (if any) do I have to resolve these issues before 2.1a is released. I heard that the release date is tomorrow. Sigh... ------------------------------------------------------- Date: 2001-Jan-10 19:39 By: jlt63 Comment: Your welcome -- thanks for considering and accepting this patch. If the patch proves to reek havoc on other platforms (most likely only on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out. ------------------------------------------------------- Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 <Cygwin-1.1.5-Python-2.0.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Wed Jan 24 03:31:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 19:31:45 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: <E14LGev-0001Wy-00@usw-sf-web2.sourceforge.net> Patch #102409 has been updated. Project: python Category: Build Status: Open Submitted by: jlt63 Assigned to : akuchling Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-23 19:31 By: akuchling Comment: Checked in the setup.py portion of this patch, modified to factor out the getting of a platform value into a get_platform() method. ------------------------------------------------------- Date: 2001-Jan-23 18:55 By: akuchling Comment: Looking at the Makefile.in part of this patch, why is the --install-platlib argument needed. The setup.cfg file should be handling this... or does it do the wrong thing somehow? ------------------------------------------------------- Date: 2001-Jan-19 22:31 By: jlt63 Comment: This patch enables Cygwin Python to build using the new Distutils style Python build. Please note that the build_ext.py part is from Jorge Sousa <jsousa@cfn.ist.utl.pt>. To patch, change directory to the top of the CVS tree and use $ patch -p0 <dist.patch The following is the ChangeLog: Sat Jan 20 01:05:18 2001 Jason Tishler <jt@dothill.com> * Makefile.in($(srcdir)/Lib/$(PLATDIR)): Add Distutils build library directory to PYTHONPATH so regen works again. (sharedinstall): Add --install-platlib option so shared extensions follow $(exec_prefix). * setup.py: Add checks for Cygwin so unsupported modules (i.e., dbm and resource) are not built. * Lib/distutils/command/build_ext.py(build_ext.finalize_options): Add Cygwin specific code to append Python's library directory to the extension's list of library directories. (build_ext.get_libraries): Add Cygwin specific code to append Python's (import) library to the extension's list of libraries. ------------------------------------------------------- Date: 2001-Jan-19 08:19 By: gvanrossum Comment: Reopened at request. Don't sweat the release date -- t's only the first alpha release. I have a feeling it'll be put off till Monday. ------------------------------------------------------- Date: 2001-Jan-18 20:52 By: jlt63 Comment: Please reopen because I need to redo the Cygwin build to handle the use of distutils to build the standard extension modules instead of Modules/Makefile.pre.in. How much time (if any) do I have to resolve these issues before 2.1a is released. I heard that the release date is tomorrow. Sigh... ------------------------------------------------------- Date: 2001-Jan-10 19:39 By: jlt63 Comment: Your welcome -- thanks for considering and accepting this patch. If the patch proves to reek havoc on other platforms (most likely only on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out. ------------------------------------------------------- Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 <Cygwin-1.1.5-Python-2.0.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Wed Jan 24 04:00:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 20:00:06 -0800 Subject: [Patches] [Patch #103391] Add support for lists in urlencode Message-ID: <E14LH6M-0005D5-00@usw-sf-web1.sourceforge.net> Patch #103391 has been updated. Project: python Category: library Status: Open Submitted by: bquinlan Assigned to : nobody Summary: Add support for lists in urlencode ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103391&group_id=5470 From noreply@sourceforge.net Wed Jan 24 04:01:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 20:01:20 -0800 Subject: [Patches] [Patch #103392] Add support for lists in urlencode Message-ID: <E14LH7Y-0005De-00@usw-sf-web1.sourceforge.net> Patch #103392 has been updated. Project: python Category: library Status: Open Submitted by: bquinlan Assigned to : nobody Summary: Add support for lists in urlencode ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103392&group_id=5470 From noreply@sourceforge.net Wed Jan 24 04:28:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 20:28:57 -0800 Subject: [Patches] [Patch #103314] allow urllib.urlencode to work with multivalued parameters Message-ID: <E14LHYH-0005Lx-00@usw-sf-web1.sourceforge.net> Patch #103314 has been updated. Project: python Category: library Status: Closed Submitted by: montanaro Assigned to : montanaro Summary: allow urllib.urlencode to work with multivalued parameters Follow-Ups: Date: 2001-Jan-23 20:28 By: fdrake Comment: The docs look ok to me; please check in. ------------------------------------------------------- Date: 2001-Jan-19 14:54 By: gvanrossum Comment: Skip, please check the code in, leave the docs until Fred approves. ------------------------------------------------------- Date: 2001-Jan-18 10:09 By: gvanrossum Comment: Comment: I would test for doseq once, and then have two loops: one with the old behavior and one with the new. Also, you might want to catch Unicode and explicitly force it into ASCII (rather than committing to a conversion without knowing what's the right thing). ------------------------------------------------------- Date: 2001-Jan-18 09:42 By: montanaro Comment: Assigned to Fred for starters because it does have a doc change. Fred, Guido probably wants to look at it next, but you're a better judge of who might have more free time... S ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103314&group_id=5470 From noreply@sourceforge.net Wed Jan 24 06:34:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 22:34:35 -0800 Subject: [Patches] [Patch #103391] Add support for lists in urlencode Message-ID: <E14LJVr-000104-00@usw-sf-web3.sourceforge.net> Patch #103391 has been updated. Project: python Category: library Status: Open Submitted by: bquinlan Assigned to : nobody Summary: Add support for lists in urlencode Follow-Ups: Date: 2001-Jan-23 22:34 By: montanaro Comment: Seems like a reasonable extension to me. needs a Doc/lib/liburllib.tex update though. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103391&group_id=5470 From noreply@sourceforge.net Wed Jan 24 06:35:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 22:35:20 -0800 Subject: [Patches] [Patch #103394] check for libtermcap as well as libreadline Message-ID: <E14LJWa-00010E-00@usw-sf-web3.sourceforge.net> Patch #103394 has been updated. Project: python Category: Build Status: Open Submitted by: sdm7g Assigned to : nobody Summary: check for libtermcap as well as libreadline ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103394&group_id=5470 From noreply@sourceforge.net Wed Jan 24 06:53:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 22:53:37 -0800 Subject: [Patches] [Patch #103395] Guido changed his mind! Quickly, add 'if key in dict'! Message-ID: <E14LJoH-0002Yo-00@usw-sf-web2.sourceforge.net> Patch #103395 has been updated. Project: python Category: core (C code) Status: Open Submitted by: twouters Assigned to : nobody Summary: Guido changed his mind! Quickly, add 'if key in dict'! ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103395&group_id=5470 From noreply@sourceforge.net Wed Jan 24 06:57:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 22:57:23 -0800 Subject: [Patches] [Patch #103395] Guido changed his mind! Quickly, add 'if key in dict'! Message-ID: <E14LJrv-0002Zk-00@usw-sf-web2.sourceforge.net> Patch #103395 has been updated. Project: python Category: core (C code) Status: Open Submitted by: twouters Assigned to : gvanrossum Summary: Guido changed his mind! Quickly, add 'if key in dict'! Follow-Ups: Date: 2001-Jan-23 22:57 By: twouters Comment: There yah go, Guido. Does my being awakened by my loud and malicious partner (who needs to head to her office 4 hours before me) earn me yet another free and legally useless 2.1 alpha ? :-) Note: it's missing docs. Will add then once I figure out where to add them. Also haven't updated the std-lib yet, will do that next. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103395&group_id=5470 From noreply@sourceforge.net Wed Jan 24 07:20:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 23:20:48 -0800 Subject: [Patches] [Patch #103395] Guido changed his mind! Quickly, add 'if key in dict'! Message-ID: <E14LKEa-0002hL-00@usw-sf-web2.sourceforge.net> Patch #103395 has been updated. Project: python Category: core (C code) Status: Open Submitted by: twouters Assigned to : gvanrossum Summary: Guido changed his mind! Quickly, add 'if key in dict'! Follow-Ups: Date: 2001-Jan-23 23:20 By: twouters Comment: Add some docs (not guarded by a 'new in 2.1' statement, I don't know how to do that), NEWS item and support in UserDict.UserDict. Docs of has_key should probably also mention that 'if key in dict' does the same, but I'm not sure how to say that's new in Python 2.1. ------------------------------------------------------- Date: 2001-Jan-23 22:57 By: twouters Comment: There yah go, Guido. Does my being awakened by my loud and malicious partner (who needs to head to her office 4 hours before me) earn me yet another free and legally useless 2.1 alpha ? :-) Note: it's missing docs. Will add then once I figure out where to add them. Also haven't updated the std-lib yet, will do that next. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103395&group_id=5470 From noreply@sourceforge.net Wed Jan 24 07:39:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 23:39:04 -0800 Subject: [Patches] [Patch #103395] Guido changed his mind! Quickly, add 'if key in dict'! Message-ID: <E14LKWG-0001Jo-00@usw-sf-web3.sourceforge.net> Patch #103395 has been updated. Project: python Category: core (C code) Status: Open Submitted by: twouters Assigned to : gvanrossum Summary: Guido changed his mind! Quickly, add 'if key in dict'! Follow-Ups: Date: 2001-Jan-23 23:39 By: twouters Comment: Added testcases for dict and UserDict. ------------------------------------------------------- Date: 2001-Jan-23 23:20 By: twouters Comment: Add some docs (not guarded by a 'new in 2.1' statement, I don't know how to do that), NEWS item and support in UserDict.UserDict. Docs of has_key should probably also mention that 'if key in dict' does the same, but I'm not sure how to say that's new in Python 2.1. ------------------------------------------------------- Date: 2001-Jan-23 22:57 By: twouters Comment: There yah go, Guido. Does my being awakened by my loud and malicious partner (who needs to head to her office 4 hours before me) earn me yet another free and legally useless 2.1 alpha ? :-) Note: it's missing docs. Will add then once I figure out where to add them. Also haven't updated the std-lib yet, will do that next. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103395&group_id=5470 From noreply@sourceforge.net Wed Jan 24 09:05:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 01:05:31 -0800 Subject: [Patches] [Patch #103395] Guido changed his mind! Quickly, add 'if key in dict'! Message-ID: <E14LLrv-0003Ht-00@usw-sf-web2.sourceforge.net> Patch #103395 has been updated. Project: python Category: core (C code) Status: Open Submitted by: twouters Assigned to : gvanrossum Summary: Guido changed his mind! Quickly, add 'if key in dict'! Follow-Ups: Date: 2001-Jan-24 01:05 By: tim_one Comment: There must be something in the air, besides email delays. I'll take your word for it that Guido changed his mind, but I was about to say +1 anyway! Now all we have to do is trick xreadlines into iterating over dicts <wink>. ------------------------------------------------------- Date: 2001-Jan-23 23:39 By: twouters Comment: Added testcases for dict and UserDict. ------------------------------------------------------- Date: 2001-Jan-23 23:20 By: twouters Comment: Add some docs (not guarded by a 'new in 2.1' statement, I don't know how to do that), NEWS item and support in UserDict.UserDict. Docs of has_key should probably also mention that 'if key in dict' does the same, but I'm not sure how to say that's new in Python 2.1. ------------------------------------------------------- Date: 2001-Jan-23 22:57 By: twouters Comment: There yah go, Guido. Does my being awakened by my loud and malicious partner (who needs to head to her office 4 hours before me) earn me yet another free and legally useless 2.1 alpha ? :-) Note: it's missing docs. Will add then once I figure out where to add them. Also haven't updated the std-lib yet, will do that next. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103395&group_id=5470 From noreply@sourceforge.net Wed Jan 24 14:46:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 06:46:36 -0800 Subject: [Patches] [Patch #103318] non-recursive makefile Message-ID: <E14LRC0-0003rx-00@usw-sf-web3.sourceforge.net> Patch #103318 has been updated. Project: python Category: Build Status: Open Submitted by: nascheme Assigned to : gvanrossum Summary: non-recursive makefile Follow-Ups: Date: 2001-Jan-24 06:46 By: nascheme Comment: Should I check this in now? ------------------------------------------------------- Date: 2001-Jan-22 07:27 By: nascheme Comment: Cleaned up Cygwin build. Tested with lastest Cygwin on Win98. Added (some?) header file dependencies. Partially merged Linux .so patch. Signal module is now enabled by configure. Things are looking good. I only have access to Linux, Cygwin, and Solaris. Please test on other platforms. ------------------------------------------------------- Date: 2001-Jan-19 14:44 By: gvanrossum Comment: Let's put this off until after the 2.1a1 release. It should go into 2.1a2 though, and probably should be checked in soon after 2.1a1 is released. ------------------------------------------------------- Date: 2001-Jan-19 10:13 By: nascheme Comment: Fix silly bug ("! test -f" instead of "test ! -f" in configure.in). ------------------------------------------------------- Date: 2001-Jan-18 20:43 By: nascheme Comment: New patch. I think makesetup works as it should. There is one issue with MAKE_LDLIBRARY on cygwin but it should be easy to fix. Object files for threads and dynamic loading show be okay now. I might be missing a few "clean" targets. I removed a bunch of "foo.o: $(srcdir)/foo.c" lines. As far as I can tell they are useless. Any make that supports VPATH should be able to figure out where to get the source. Other makes can look in the same dir as the source file. Surely they are not that broken. Guido, do you know if there was a good reason for these lines? Building with GNU make works great for any situation I can think of. pmake is not smart enough to re-read the makefile if it got updated. I don't know of any way around that. Building in a separate dir works fine. I didn't do buildno because I like to type "make" and see the prompt come back right away. What is buildno for and when should it be incremented? ------------------------------------------------------- Date: 2001-Jan-18 18:56 By: gvanrossum Comment: I'm in a quandary. This is really awesone! But a bit too rough to add to the 2.1a1 release. You don't seem to deal with buildno properly -- what's the problem there? Also, I seem to recall that the "-o file.o" option is not universal amongst C compilers. Could someone who uses a non-GCC compiler (e.g. SunPro, or HP, or AIX) check the portability of this Makefile? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103318&group_id=5470 From noreply@sourceforge.net Wed Jan 24 14:58:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 06:58:38 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: <E14LRNe-0005Ug-00@usw-sf-web2.sourceforge.net> Patch #102409 has been updated. Project: python Category: Build Status: Open Submitted by: jlt63 Assigned to : akuchling Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-24 06:58 By: jlt63 Comment: > The setup.cfg file should be handling this... or does it do the wrong thing somehow? As you mentioned in a comment for the PEP 229 patch, setup.cfg is hard-coding the installation directory at configure time to "@prefix@/lib/python@VERSION@/lib-dynload". Which means that "make prefix=/tmp/python/usr/local install" does not work as expected. That is, everything except for the standard modules install in "/tmp/python/usr/local" but the standard modules still end up in "/usr/local/lib/python2.1/lib-dynload". This makes it difficult to create a pre-built distribution. Are you the right person to commit the Lib/distutils/command/build_ext.py part? This is crucial to getting the Cygwin build working again. It appears that the regen hunk of the Makefile.in part is no longer necessary since python seems to be setting sys.path correctly to find the standard modules when running out of the build directory now. BTW, setup.cfg.in is missed a NL at the end of the file. ------------------------------------------------------- Date: 2001-Jan-23 19:31 By: akuchling Comment: Checked in the setup.py portion of this patch, modified to factor out the getting of a platform value into a get_platform() method. ------------------------------------------------------- Date: 2001-Jan-23 18:55 By: akuchling Comment: Looking at the Makefile.in part of this patch, why is the --install-platlib argument needed. The setup.cfg file should be handling this... or does it do the wrong thing somehow? ------------------------------------------------------- Date: 2001-Jan-19 22:31 By: jlt63 Comment: This patch enables Cygwin Python to build using the new Distutils style Python build. Please note that the build_ext.py part is from Jorge Sousa <jsousa@cfn.ist.utl.pt>. To patch, change directory to the top of the CVS tree and use $ patch -p0 <dist.patch The following is the ChangeLog: Sat Jan 20 01:05:18 2001 Jason Tishler <jt@dothill.com> * Makefile.in($(srcdir)/Lib/$(PLATDIR)): Add Distutils build library directory to PYTHONPATH so regen works again. (sharedinstall): Add --install-platlib option so shared extensions follow $(exec_prefix). * setup.py: Add checks for Cygwin so unsupported modules (i.e., dbm and resource) are not built. * Lib/distutils/command/build_ext.py(build_ext.finalize_options): Add Cygwin specific code to append Python's library directory to the extension's list of library directories. (build_ext.get_libraries): Add Cygwin specific code to append Python's (import) library to the extension's list of libraries. ------------------------------------------------------- Date: 2001-Jan-19 08:19 By: gvanrossum Comment: Reopened at request. Don't sweat the release date -- t's only the first alpha release. I have a feeling it'll be put off till Monday. ------------------------------------------------------- Date: 2001-Jan-18 20:52 By: jlt63 Comment: Please reopen because I need to redo the Cygwin build to handle the use of distutils to build the standard extension modules instead of Modules/Makefile.pre.in. How much time (if any) do I have to resolve these issues before 2.1a is released. I heard that the release date is tomorrow. Sigh... ------------------------------------------------------- Date: 2001-Jan-10 19:39 By: jlt63 Comment: Your welcome -- thanks for considering and accepting this patch. If the patch proves to reek havoc on other platforms (most likely only on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out. ------------------------------------------------------- Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 <Cygwin-1.1.5-Python-2.0.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Wed Jan 24 15:26:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 07:26:16 -0800 Subject: [Patches] [Patch #103318] non-recursive makefile Message-ID: <E14LRoO-00047R-00@usw-sf-web3.sourceforge.net> Patch #103318 has been updated. Project: python Category: Build Status: Open Submitted by: nascheme Assigned to : nascheme Summary: non-recursive makefile Follow-Ups: Date: 2001-Jan-24 07:26 By: gvanrossum Comment: Check it in, as long as you have time to deal with the complaints you expect in a timely manner. ;-) ------------------------------------------------------- Date: 2001-Jan-24 06:46 By: nascheme Comment: Should I check this in now? ------------------------------------------------------- Date: 2001-Jan-22 07:27 By: nascheme Comment: Cleaned up Cygwin build. Tested with lastest Cygwin on Win98. Added (some?) header file dependencies. Partially merged Linux .so patch. Signal module is now enabled by configure. Things are looking good. I only have access to Linux, Cygwin, and Solaris. Please test on other platforms. ------------------------------------------------------- Date: 2001-Jan-19 14:44 By: gvanrossum Comment: Let's put this off until after the 2.1a1 release. It should go into 2.1a2 though, and probably should be checked in soon after 2.1a1 is released. ------------------------------------------------------- Date: 2001-Jan-19 10:13 By: nascheme Comment: Fix silly bug ("! test -f" instead of "test ! -f" in configure.in). ------------------------------------------------------- Date: 2001-Jan-18 20:43 By: nascheme Comment: New patch. I think makesetup works as it should. There is one issue with MAKE_LDLIBRARY on cygwin but it should be easy to fix. Object files for threads and dynamic loading show be okay now. I might be missing a few "clean" targets. I removed a bunch of "foo.o: $(srcdir)/foo.c" lines. As far as I can tell they are useless. Any make that supports VPATH should be able to figure out where to get the source. Other makes can look in the same dir as the source file. Surely they are not that broken. Guido, do you know if there was a good reason for these lines? Building with GNU make works great for any situation I can think of. pmake is not smart enough to re-read the makefile if it got updated. I don't know of any way around that. Building in a separate dir works fine. I didn't do buildno because I like to type "make" and see the prompt come back right away. What is buildno for and when should it be incremented? ------------------------------------------------------- Date: 2001-Jan-18 18:56 By: gvanrossum Comment: I'm in a quandary. This is really awesone! But a bit too rough to add to the 2.1a1 release. You don't seem to deal with buildno properly -- what's the problem there? Also, I seem to recall that the "-o file.o" option is not universal amongst C compilers. Could someone who uses a non-GCC compiler (e.g. SunPro, or HP, or AIX) check the portability of this Makefile? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103318&group_id=5470 From noreply@sourceforge.net Wed Jan 24 15:34:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 07:34:36 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: <E14LRwS-0004Aa-00@usw-sf-web3.sourceforge.net> Patch #102409 has been updated. Project: python Category: Build Status: Open Submitted by: jlt63 Assigned to : akuchling Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-24 07:34 By: akuchling Comment: OK. Then the right thing is probably to lose the setup.cfg file completely, and rely on the command-line declaration of install_platlib. This means that just running './python setup.py install' from the command line won't install in the right place, but oh well... And yes, I'm responsible for built_ext at the moment. ------------------------------------------------------- Date: 2001-Jan-24 06:58 By: jlt63 Comment: > The setup.cfg file should be handling this... or does it do the wrong thing somehow? As you mentioned in a comment for the PEP 229 patch, setup.cfg is hard-coding the installation directory at configure time to "@prefix@/lib/python@VERSION@/lib-dynload". Which means that "make prefix=/tmp/python/usr/local install" does not work as expected. That is, everything except for the standard modules install in "/tmp/python/usr/local" but the standard modules still end up in "/usr/local/lib/python2.1/lib-dynload". This makes it difficult to create a pre-built distribution. Are you the right person to commit the Lib/distutils/command/build_ext.py part? This is crucial to getting the Cygwin build working again. It appears that the regen hunk of the Makefile.in part is no longer necessary since python seems to be setting sys.path correctly to find the standard modules when running out of the build directory now. BTW, setup.cfg.in is missed a NL at the end of the file. ------------------------------------------------------- Date: 2001-Jan-23 19:31 By: akuchling Comment: Checked in the setup.py portion of this patch, modified to factor out the getting of a platform value into a get_platform() method. ------------------------------------------------------- Date: 2001-Jan-23 18:55 By: akuchling Comment: Looking at the Makefile.in part of this patch, why is the --install-platlib argument needed. The setup.cfg file should be handling this... or does it do the wrong thing somehow? ------------------------------------------------------- Date: 2001-Jan-19 22:31 By: jlt63 Comment: This patch enables Cygwin Python to build using the new Distutils style Python build. Please note that the build_ext.py part is from Jorge Sousa <jsousa@cfn.ist.utl.pt>. To patch, change directory to the top of the CVS tree and use $ patch -p0 <dist.patch The following is the ChangeLog: Sat Jan 20 01:05:18 2001 Jason Tishler <jt@dothill.com> * Makefile.in($(srcdir)/Lib/$(PLATDIR)): Add Distutils build library directory to PYTHONPATH so regen works again. (sharedinstall): Add --install-platlib option so shared extensions follow $(exec_prefix). * setup.py: Add checks for Cygwin so unsupported modules (i.e., dbm and resource) are not built. * Lib/distutils/command/build_ext.py(build_ext.finalize_options): Add Cygwin specific code to append Python's library directory to the extension's list of library directories. (build_ext.get_libraries): Add Cygwin specific code to append Python's (import) library to the extension's list of libraries. ------------------------------------------------------- Date: 2001-Jan-19 08:19 By: gvanrossum Comment: Reopened at request. Don't sweat the release date -- t's only the first alpha release. I have a feeling it'll be put off till Monday. ------------------------------------------------------- Date: 2001-Jan-18 20:52 By: jlt63 Comment: Please reopen because I need to redo the Cygwin build to handle the use of distutils to build the standard extension modules instead of Modules/Makefile.pre.in. How much time (if any) do I have to resolve these issues before 2.1a is released. I heard that the release date is tomorrow. Sigh... ------------------------------------------------------- Date: 2001-Jan-10 19:39 By: jlt63 Comment: Your welcome -- thanks for considering and accepting this patch. If the patch proves to reek havoc on other platforms (most likely only on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out. ------------------------------------------------------- Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 <Cygwin-1.1.5-Python-2.0.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Wed Jan 24 15:43:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 07:43:24 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: <E14LS4y-0004E0-00@usw-sf-web3.sourceforge.net> Patch #102409 has been updated. Project: python Category: Build Status: Open Submitted by: jlt63 Assigned to : akuchling Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-24 07:43 By: akuchling Comment: Checked in the build_ext.py portion of this patch. ------------------------------------------------------- Date: 2001-Jan-24 07:34 By: akuchling Comment: OK. Then the right thing is probably to lose the setup.cfg file completely, and rely on the command-line declaration of install_platlib. This means that just running './python setup.py install' from the command line won't install in the right place, but oh well... And yes, I'm responsible for built_ext at the moment. ------------------------------------------------------- Date: 2001-Jan-24 06:58 By: jlt63 Comment: > The setup.cfg file should be handling this... or does it do the wrong thing somehow? As you mentioned in a comment for the PEP 229 patch, setup.cfg is hard-coding the installation directory at configure time to "@prefix@/lib/python@VERSION@/lib-dynload". Which means that "make prefix=/tmp/python/usr/local install" does not work as expected. That is, everything except for the standard modules install in "/tmp/python/usr/local" but the standard modules still end up in "/usr/local/lib/python2.1/lib-dynload". This makes it difficult to create a pre-built distribution. Are you the right person to commit the Lib/distutils/command/build_ext.py part? This is crucial to getting the Cygwin build working again. It appears that the regen hunk of the Makefile.in part is no longer necessary since python seems to be setting sys.path correctly to find the standard modules when running out of the build directory now. BTW, setup.cfg.in is missed a NL at the end of the file. ------------------------------------------------------- Date: 2001-Jan-23 19:31 By: akuchling Comment: Checked in the setup.py portion of this patch, modified to factor out the getting of a platform value into a get_platform() method. ------------------------------------------------------- Date: 2001-Jan-23 18:55 By: akuchling Comment: Looking at the Makefile.in part of this patch, why is the --install-platlib argument needed. The setup.cfg file should be handling this... or does it do the wrong thing somehow? ------------------------------------------------------- Date: 2001-Jan-19 22:31 By: jlt63 Comment: This patch enables Cygwin Python to build using the new Distutils style Python build. Please note that the build_ext.py part is from Jorge Sousa <jsousa@cfn.ist.utl.pt>. To patch, change directory to the top of the CVS tree and use $ patch -p0 <dist.patch The following is the ChangeLog: Sat Jan 20 01:05:18 2001 Jason Tishler <jt@dothill.com> * Makefile.in($(srcdir)/Lib/$(PLATDIR)): Add Distutils build library directory to PYTHONPATH so regen works again. (sharedinstall): Add --install-platlib option so shared extensions follow $(exec_prefix). * setup.py: Add checks for Cygwin so unsupported modules (i.e., dbm and resource) are not built. * Lib/distutils/command/build_ext.py(build_ext.finalize_options): Add Cygwin specific code to append Python's library directory to the extension's list of library directories. (build_ext.get_libraries): Add Cygwin specific code to append Python's (import) library to the extension's list of libraries. ------------------------------------------------------- Date: 2001-Jan-19 08:19 By: gvanrossum Comment: Reopened at request. Don't sweat the release date -- t's only the first alpha release. I have a feeling it'll be put off till Monday. ------------------------------------------------------- Date: 2001-Jan-18 20:52 By: jlt63 Comment: Please reopen because I need to redo the Cygwin build to handle the use of distutils to build the standard extension modules instead of Modules/Makefile.pre.in. How much time (if any) do I have to resolve these issues before 2.1a is released. I heard that the release date is tomorrow. Sigh... ------------------------------------------------------- Date: 2001-Jan-10 19:39 By: jlt63 Comment: Your welcome -- thanks for considering and accepting this patch. If the patch proves to reek havoc on other platforms (most likely only on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out. ------------------------------------------------------- Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 <Cygwin-1.1.5-Python-2.0.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Wed Jan 24 17:16:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 09:16:14 -0800 Subject: [Patches] [Patch #103259] Tutorial: Unicode section says UTF-8 is default Message-ID: <E14LTWo-0004na-00@usw-sf-web3.sourceforge.net> Patch #103259 has been updated. Project: python Category: documentation Status: Closed Submitted by: ping Assigned to : fdrake Summary: Tutorial: Unicode section says UTF-8 is default Follow-Ups: Date: 2001-Jan-24 09:16 By: ping Comment: Checked this in. (Guido approved.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103259&group_id=5470 From noreply@sourceforge.net Wed Jan 24 17:20:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 09:20:37 -0800 Subject: [Patches] [Patch #103247] Strings: '\012' -> '\n' Message-ID: <E14LTb3-0004pU-00@usw-sf-web3.sourceforge.net> Patch #103247 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: ping Assigned to : ping Summary: Strings: '\012' -> '\n' Follow-Ups: Date: 2001-Jan-24 09:20 By: ping Comment: Checked in. (Escapes are also now hex instead of octal.) ------------------------------------------------------- Date: 2001-Jan-19 14:58 By: gvanrossum Comment: Ping, please check this in before Monday, so it can go into the alpha1. The docs can come later. ------------------------------------------------------- Date: 2001-Jan-15 21:42 By: ping Comment: Yes, the docs will take some work. I'll resubmit when i've gone through all the documentation. ------------------------------------------------------- Date: 2001-Jan-15 20:21 By: gvanrossum Comment: Nice. Style nit: I don't care for the fputc(), fputc(); form. Can you resubmit (and retest!) a version that uses \x%02x too? I'd expect that this would require updates to some docs and the tutorial, too. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103247&group_id=5470 From noreply@sourceforge.net Wed Jan 24 17:29:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 09:29:34 -0800 Subject: [Patches] [Patch #103318] non-recursive makefile Message-ID: <E14LTji-0001YT-00@usw-sf-web1.sourceforge.net> Patch #103318 has been updated. Project: python Category: Build Status: Closed Submitted by: nascheme Assigned to : nobody Summary: non-recursive makefile Follow-Ups: Date: 2001-Jan-24 09:29 By: nascheme Comment: Updated version applied. The old makefiles are still around for now. ------------------------------------------------------- Date: 2001-Jan-24 07:26 By: gvanrossum Comment: Check it in, as long as you have time to deal with the complaints you expect in a timely manner. ;-) ------------------------------------------------------- Date: 2001-Jan-24 06:46 By: nascheme Comment: Should I check this in now? ------------------------------------------------------- Date: 2001-Jan-22 07:27 By: nascheme Comment: Cleaned up Cygwin build. Tested with lastest Cygwin on Win98. Added (some?) header file dependencies. Partially merged Linux .so patch. Signal module is now enabled by configure. Things are looking good. I only have access to Linux, Cygwin, and Solaris. Please test on other platforms. ------------------------------------------------------- Date: 2001-Jan-19 14:44 By: gvanrossum Comment: Let's put this off until after the 2.1a1 release. It should go into 2.1a2 though, and probably should be checked in soon after 2.1a1 is released. ------------------------------------------------------- Date: 2001-Jan-19 10:13 By: nascheme Comment: Fix silly bug ("! test -f" instead of "test ! -f" in configure.in). ------------------------------------------------------- Date: 2001-Jan-18 20:43 By: nascheme Comment: New patch. I think makesetup works as it should. There is one issue with MAKE_LDLIBRARY on cygwin but it should be easy to fix. Object files for threads and dynamic loading show be okay now. I might be missing a few "clean" targets. I removed a bunch of "foo.o: $(srcdir)/foo.c" lines. As far as I can tell they are useless. Any make that supports VPATH should be able to figure out where to get the source. Other makes can look in the same dir as the source file. Surely they are not that broken. Guido, do you know if there was a good reason for these lines? Building with GNU make works great for any situation I can think of. pmake is not smart enough to re-read the makefile if it got updated. I don't know of any way around that. Building in a separate dir works fine. I didn't do buildno because I like to type "make" and see the prompt come back right away. What is buildno for and when should it be incremented? ------------------------------------------------------- Date: 2001-Jan-18 18:56 By: gvanrossum Comment: I'm in a quandary. This is really awesone! But a bit too rough to add to the 2.1a1 release. You don't seem to deal with buildno properly -- what's the problem there? Also, I seem to recall that the "-o file.o" option is not universal amongst C compilers. Could someone who uses a non-GCC compiler (e.g. SunPro, or HP, or AIX) check the portability of this Makefile? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103318&group_id=5470 From noreply@sourceforge.net Wed Jan 24 19:06:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 11:06:00 -0800 Subject: [Patches] [Patch #101647] adds SSL server socket support to socketmodule.c Message-ID: <E14LVF2-00076Y-00@usw-sf-web2.sourceforge.net> Patch #101647 has been updated. Project: python Category: Modules Status: Rejected Submitted by: drew_csillag Assigned to : gvanrossum Summary: adds SSL server socket support to socketmodule.c Follow-Ups: Date: 2001-Jan-24 11:06 By: drew_csillag Comment: Sorry for the no-reply... Anyhoo, the ssl stuff currently in the socket module only allows ssl on client connections (i.e. where you connect to somebody else) as opposed to server connections (i.e. where somebody connects to you). For example, you have a cheesy SSL socket client: from socket import * s = socket(AF_INET, SOCK_STREAM) s.connect(('',9999)) ss = ssl(s,None,None) ss.write("foo!\n") The patch is required in order to be able to write the corresponding server, as such: from socket import * s = socket(AF_INET, SOCK_STREAM) s.bind(('',9999)) s.listen(5) f,a = s.accept() ss = sslserv(f, "keyfilename", "certfilename") print ss.read(5) If you try to just use the ssl function on both sides and it doesn't work. ------------------------------------------------------- Date: 2000-Sep-25 09:41 By: jhylton Comment: too late for 2.0 ------------------------------------------------------- Date: 2000-Sep-27 03:51 By: naris Comment: too late ? this patch solves world hunger and brings world peace! such a valuable patch, but i guess deadlines are deadlines :-( ------------------------------------------------------- Date: 2000-Oct-25 13:54 By: gvanrossum Comment: Drew, could you provide an example of how this is used? If I can't test it I can't add it. It doesn't have to be a test module (although a test module for all the SSL support is sorely needed) but I would like to see a little motivation for why this is useful. Also note that the SSL support in the socket module is controversial; there are some who believe that a different approach is needed, e.g. based on M2crypto. ------------------------------------------------------- Date: 2000-Nov-13 11:41 By: gvanrossum Comment: Still no reply. I'll reject the patch now, for lack of sufficient motivation. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101647&group_id=5470 From noreply@sourceforge.net Wed Jan 24 19:20:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 11:20:53 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: <E14LVTR-0005b1-00@usw-sf-web3.sourceforge.net> Patch #102409 has been updated. Project: python Category: Build Status: Open Submitted by: jlt63 Assigned to : akuchling Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-24 11:20 By: akuchling Comment: Neil's checkin of the non-recursive affects Makefile.in, the only portion of this patch that isn't checked in. jlt, should I try to port the Makefile.in changes, or do you want to port them and submit a revised patch? ------------------------------------------------------- Date: 2001-Jan-24 07:43 By: akuchling Comment: Checked in the build_ext.py portion of this patch. ------------------------------------------------------- Date: 2001-Jan-24 07:34 By: akuchling Comment: OK. Then the right thing is probably to lose the setup.cfg file completely, and rely on the command-line declaration of install_platlib. This means that just running './python setup.py install' from the command line won't install in the right place, but oh well... And yes, I'm responsible for built_ext at the moment. ------------------------------------------------------- Date: 2001-Jan-24 06:58 By: jlt63 Comment: > The setup.cfg file should be handling this... or does it do the wrong thing somehow? As you mentioned in a comment for the PEP 229 patch, setup.cfg is hard-coding the installation directory at configure time to "@prefix@/lib/python@VERSION@/lib-dynload". Which means that "make prefix=/tmp/python/usr/local install" does not work as expected. That is, everything except for the standard modules install in "/tmp/python/usr/local" but the standard modules still end up in "/usr/local/lib/python2.1/lib-dynload". This makes it difficult to create a pre-built distribution. Are you the right person to commit the Lib/distutils/command/build_ext.py part? This is crucial to getting the Cygwin build working again. It appears that the regen hunk of the Makefile.in part is no longer necessary since python seems to be setting sys.path correctly to find the standard modules when running out of the build directory now. BTW, setup.cfg.in is missed a NL at the end of the file. ------------------------------------------------------- Date: 2001-Jan-23 19:31 By: akuchling Comment: Checked in the setup.py portion of this patch, modified to factor out the getting of a platform value into a get_platform() method. ------------------------------------------------------- Date: 2001-Jan-23 18:55 By: akuchling Comment: Looking at the Makefile.in part of this patch, why is the --install-platlib argument needed. The setup.cfg file should be handling this... or does it do the wrong thing somehow? ------------------------------------------------------- Date: 2001-Jan-19 22:31 By: jlt63 Comment: This patch enables Cygwin Python to build using the new Distutils style Python build. Please note that the build_ext.py part is from Jorge Sousa <jsousa@cfn.ist.utl.pt>. To patch, change directory to the top of the CVS tree and use $ patch -p0 <dist.patch The following is the ChangeLog: Sat Jan 20 01:05:18 2001 Jason Tishler <jt@dothill.com> * Makefile.in($(srcdir)/Lib/$(PLATDIR)): Add Distutils build library directory to PYTHONPATH so regen works again. (sharedinstall): Add --install-platlib option so shared extensions follow $(exec_prefix). * setup.py: Add checks for Cygwin so unsupported modules (i.e., dbm and resource) are not built. * Lib/distutils/command/build_ext.py(build_ext.finalize_options): Add Cygwin specific code to append Python's library directory to the extension's list of library directories. (build_ext.get_libraries): Add Cygwin specific code to append Python's (import) library to the extension's list of libraries. ------------------------------------------------------- Date: 2001-Jan-19 08:19 By: gvanrossum Comment: Reopened at request. Don't sweat the release date -- t's only the first alpha release. I have a feeling it'll be put off till Monday. ------------------------------------------------------- Date: 2001-Jan-18 20:52 By: jlt63 Comment: Please reopen because I need to redo the Cygwin build to handle the use of distutils to build the standard extension modules instead of Modules/Makefile.pre.in. How much time (if any) do I have to resolve these issues before 2.1a is released. I heard that the release date is tomorrow. Sigh... ------------------------------------------------------- Date: 2001-Jan-10 19:39 By: jlt63 Comment: Your welcome -- thanks for considering and accepting this patch. If the patch proves to reek havoc on other platforms (most likely only on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out. ------------------------------------------------------- Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 <Cygwin-1.1.5-Python-2.0.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Wed Jan 24 19:24:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 11:24:33 -0800 Subject: [Patches] [Patch #101647] adds SSL server socket support to socketmodule.c Message-ID: <E14LVWz-0005cl-00@usw-sf-web3.sourceforge.net> Patch #101647 has been updated. Project: python Category: Modules Status: Rejected Submitted by: drew_csillag Assigned to : gvanrossum Summary: adds SSL server socket support to socketmodule.c Follow-Ups: Date: 2001-Jan-24 11:24 By: akuchling Comment: Guido, want me to re-open this patch and take it over? IMHO, if the SSL support is left in, then this patch should be added; no point in having only half-working support. ------------------------------------------------------- Date: 2001-Jan-24 11:06 By: drew_csillag Comment: Sorry for the no-reply... Anyhoo, the ssl stuff currently in the socket module only allows ssl on client connections (i.e. where you connect to somebody else) as opposed to server connections (i.e. where somebody connects to you). For example, you have a cheesy SSL socket client: from socket import * s = socket(AF_INET, SOCK_STREAM) s.connect(('',9999)) ss = ssl(s,None,None) ss.write("foo!\n") The patch is required in order to be able to write the corresponding server, as such: from socket import * s = socket(AF_INET, SOCK_STREAM) s.bind(('',9999)) s.listen(5) f,a = s.accept() ss = sslserv(f, "keyfilename", "certfilename") print ss.read(5) If you try to just use the ssl function on both sides and it doesn't work. ------------------------------------------------------- Date: 2000-Sep-25 09:41 By: jhylton Comment: too late for 2.0 ------------------------------------------------------- Date: 2000-Sep-27 03:51 By: naris Comment: too late ? this patch solves world hunger and brings world peace! such a valuable patch, but i guess deadlines are deadlines :-( ------------------------------------------------------- Date: 2000-Oct-25 13:54 By: gvanrossum Comment: Drew, could you provide an example of how this is used? If I can't test it I can't add it. It doesn't have to be a test module (although a test module for all the SSL support is sorely needed) but I would like to see a little motivation for why this is useful. Also note that the SSL support in the socket module is controversial; there are some who believe that a different approach is needed, e.g. based on M2crypto. ------------------------------------------------------- Date: 2000-Nov-13 11:41 By: gvanrossum Comment: Still no reply. I'll reject the patch now, for lack of sufficient motivation. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101647&group_id=5470 From noreply@sourceforge.net Wed Jan 24 20:05:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 12:05:32 -0800 Subject: [Patches] [Patch #101647] adds SSL server socket support to socketmodule.c Message-ID: <E14LWAe-0002cE-00@usw-sf-web1.sourceforge.net> Patch #101647 has been updated. Project: python Category: Modules Status: Open Submitted by: drew_csillag Assigned to : akuchling Summary: adds SSL server socket support to socketmodule.c Follow-Ups: Date: 2001-Jan-24 12:05 By: gvanrossum Comment: OK, Andrew, it's all yours. (But I disagree with your last point: client-only SSL support is still a lot better than no SSL support! :-) ------------------------------------------------------- Date: 2001-Jan-24 11:24 By: akuchling Comment: Guido, want me to re-open this patch and take it over? IMHO, if the SSL support is left in, then this patch should be added; no point in having only half-working support. ------------------------------------------------------- Date: 2001-Jan-24 11:06 By: drew_csillag Comment: Sorry for the no-reply... Anyhoo, the ssl stuff currently in the socket module only allows ssl on client connections (i.e. where you connect to somebody else) as opposed to server connections (i.e. where somebody connects to you). For example, you have a cheesy SSL socket client: from socket import * s = socket(AF_INET, SOCK_STREAM) s.connect(('',9999)) ss = ssl(s,None,None) ss.write("foo!\n") The patch is required in order to be able to write the corresponding server, as such: from socket import * s = socket(AF_INET, SOCK_STREAM) s.bind(('',9999)) s.listen(5) f,a = s.accept() ss = sslserv(f, "keyfilename", "certfilename") print ss.read(5) If you try to just use the ssl function on both sides and it doesn't work. ------------------------------------------------------- Date: 2000-Sep-25 09:41 By: jhylton Comment: too late for 2.0 ------------------------------------------------------- Date: 2000-Sep-27 03:51 By: naris Comment: too late ? this patch solves world hunger and brings world peace! such a valuable patch, but i guess deadlines are deadlines :-( ------------------------------------------------------- Date: 2000-Oct-25 13:54 By: gvanrossum Comment: Drew, could you provide an example of how this is used? If I can't test it I can't add it. It doesn't have to be a test module (although a test module for all the SSL support is sorely needed) but I would like to see a little motivation for why this is useful. Also note that the SSL support in the socket module is controversial; there are some who believe that a different approach is needed, e.g. based on M2crypto. ------------------------------------------------------- Date: 2000-Nov-13 11:41 By: gvanrossum Comment: Still no reply. I'll reject the patch now, for lack of sufficient motivation. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101647&group_id=5470 From noreply@sourceforge.net Wed Jan 24 22:32:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 14:32:41 -0800 Subject: [Patches] [Patch #103409] install: setup.py 'dbm' header file searching Message-ID: <E14LYT3-0003b6-00@usw-sf-web1.sourceforge.net> Patch #103409 has been updated. Project: python Category: Build Status: Open Submitted by: calvin Assigned to : nobody Summary: install: setup.py 'dbm' header file searching ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103409&group_id=5470 From noreply@sourceforge.net Wed Jan 24 22:46:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 14:46:14 -0800 Subject: [Patches] [Patch #103409] install: setup.py 'dbm' header file searching Message-ID: <E14LYgA-0003hn-00@usw-sf-web1.sourceforge.net> Patch #103409 has been updated. Project: python Category: Build Status: Open Submitted by: calvin Assigned to : nobody Summary: install: setup.py 'dbm' header file searching Follow-Ups: Date: 2001-Jan-24 14:46 By: calvin Comment: Argh, thats not my problem: the configure program does not find the db1/ndbm.h file. Hmm, will look further into this. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103409&group_id=5470 From noreply@sourceforge.net Wed Jan 24 22:53:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 14:53:02 -0800 Subject: [Patches] [Patch #103409] install: setup.py 'dbm' header file searching Message-ID: <E14LYmk-0008TW-00@usw-sf-web2.sourceforge.net> Patch #103409 has been updated. Project: python Category: Build Status: Open Submitted by: calvin Assigned to : nobody Summary: install: setup.py 'dbm' header file searching Follow-Ups: Date: 2001-Jan-24 14:53 By: calvin Comment: Ok, its a Debian bug, never mind. ------------------------------------------------------- Date: 2001-Jan-24 14:46 By: calvin Comment: Argh, thats not my problem: the configure program does not find the db1/ndbm.h file. Hmm, will look further into this. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103409&group_id=5470 From noreply@sourceforge.net Thu Jan 25 00:57:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 16:57:42 -0800 Subject: [Patches] [Patch #102588] PEP 229: Use Distutils to build Message-ID: <E14LajO-0000nA-00@usw-sf-web2.sourceforge.net> Patch #102588 has been updated. Project: python Category: Build Status: Closed Submitted by: akuchling Assigned to : akuchling Summary: PEP 229: Use Distutils to build Follow-Ups: Date: 2001-Jan-24 16:57 By: akuchling Comment: Checked in, so I'm going to close this patch. Further discussion and development will occur in different patches/bug reports. ------------------------------------------------------- Date: 2001-Jan-21 20:25 By: jlt63 Comment: While working on the build so that Cygwin Python builds OOTB again, I found the following issues now that Python is using Distutils intrinsically: 1. setup.py needs to improve its ability to select only platform appropriate modules. I believe that this has already been discussed on python-dev. 2. make install is not passing $(prefix) to setup.py so the standard extension modules are always installed in the configured location and cannot be overridden at install time. 3. make install fails during the regen step for platforms that do not have a Lib/platform-foo in CVS. This is due to PYTHONPATH no longer being set correctly. 4. Most of the standard extension modules have different filenames (i.e., missing "module") than they had in 2.0. For example on Linux, the socket module was called _socketmodule.so -- now it is called _socket.so. FYI, I have submitted the following patch: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 which has a Cygwin specific solution for 1 and platform independent solutions for 2 and 3. I just noticed your comment regarding setup.cfg, but maybe my "solution" to 2 will prove useful anyway. ------------------------------------------------------- Date: 2001-Jan-16 14:53 By: akuchling Comment: I've made an updated version of the patch; because it's 55K, SF won't accept it, so I've put it at http://www.mems-exchange.org/software/files/python/pep229.patch. There are only a very few things left to fix at this point: * setup.cfg hard-wires the installation directory because it has no access to a variable holding the installation prefix * installs in subdirectories don't work because setup.cfg is only found in the current directory. I think those are the only two remaining issues before this can be checked in (doubtless causing the sun to explode). ------------------------------------------------------- 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 Thu Jan 25 01:00:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 17:00:21 -0800 Subject: [Patches] [Patch #103334] Strip "." pathname components Message-ID: <E14Lalx-0000oz-00@usw-sf-web2.sourceforge.net> Patch #103334 has been updated. Project: python Category: distutils Status: Accepted Submitted by: jackjansen Assigned to : akuchling Summary: Strip "." pathname components Follow-Ups: Date: 2001-Jan-24 17:00 By: akuchling Comment: Seems reasonable; please go ahead and check it in. ------------------------------------------------------- Date: 2001-Jan-19 14:41 By: gvanrossum Comment: Looks decent to me. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103334&group_id=5470 From noreply@sourceforge.net Thu Jan 25 01:01:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 17:01:28 -0800 Subject: [Patches] [Patch #103333] install_data does not do pathname conversion Message-ID: <E14Lan2-0000pS-00@usw-sf-web2.sourceforge.net> Patch #103333 has been updated. Project: python Category: distutils Status: Accepted Submitted by: jackjansen Assigned to : akuchling Summary: install_data does not do pathname conversion Follow-Ups: Date: 2001-Jan-24 17:01 By: akuchling Comment: Looks good; please check it in. ------------------------------------------------------- Date: 2001-Jan-19 14:42 By: gvanrossum Comment: For Andrew. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103333&group_id=5470 From noreply@sourceforge.net Thu Jan 25 02:45:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 18:45:38 -0800 Subject: [Patches] [Patch #103412] Complete description of percent formatting in libstdtypes Message-ID: <E14LcPq-0008Ux-00@usw-sf-web3.sourceforge.net> Patch #103412 has been updated. Project: python Category: documentation Status: Open Submitted by: efm Assigned to : nobody Summary: Complete description of percent formatting in libstdtypes ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103412&group_id=5470 From noreply@sourceforge.net Thu Jan 25 03:04:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 19:04:12 -0800 Subject: [Patches] [Patch #101647] adds SSL server socket support to socketmodule.c Message-ID: <E14Lcho-0001VH-00@usw-sf-web2.sourceforge.net> Patch #101647 has been updated. Project: python Category: Modules Status: Open Submitted by: drew_csillag Assigned to : akuchling Summary: adds SSL server socket support to socketmodule.c Follow-Ups: Date: 2001-Jan-24 19:04 By: akuchling Comment: newServerSSLObject() is a near-duplicate of newSSLobject(). Rather than just cut-and-paste the code into a new function, newSSLobject() should take a fourth argument, and perform either the client or server initialization. I've already modified the patch to do this. Before uploading the modified version, I'd like to test it, but can't figure out what it wants for the key and cert arguments. Drew, do you have a test program you used to test the code? Can you please e-mail it to me, or add it as a comment to this patch? ------------------------------------------------------- Date: 2001-Jan-24 12:05 By: gvanrossum Comment: OK, Andrew, it's all yours. (But I disagree with your last point: client-only SSL support is still a lot better than no SSL support! :-) ------------------------------------------------------- Date: 2001-Jan-24 11:24 By: akuchling Comment: Guido, want me to re-open this patch and take it over? IMHO, if the SSL support is left in, then this patch should be added; no point in having only half-working support. ------------------------------------------------------- Date: 2001-Jan-24 11:06 By: drew_csillag Comment: Sorry for the no-reply... Anyhoo, the ssl stuff currently in the socket module only allows ssl on client connections (i.e. where you connect to somebody else) as opposed to server connections (i.e. where somebody connects to you). For example, you have a cheesy SSL socket client: from socket import * s = socket(AF_INET, SOCK_STREAM) s.connect(('',9999)) ss = ssl(s,None,None) ss.write("foo!\n") The patch is required in order to be able to write the corresponding server, as such: from socket import * s = socket(AF_INET, SOCK_STREAM) s.bind(('',9999)) s.listen(5) f,a = s.accept() ss = sslserv(f, "keyfilename", "certfilename") print ss.read(5) If you try to just use the ssl function on both sides and it doesn't work. ------------------------------------------------------- Date: 2000-Sep-25 09:41 By: jhylton Comment: too late for 2.0 ------------------------------------------------------- Date: 2000-Sep-27 03:51 By: naris Comment: too late ? this patch solves world hunger and brings world peace! such a valuable patch, but i guess deadlines are deadlines :-( ------------------------------------------------------- Date: 2000-Oct-25 13:54 By: gvanrossum Comment: Drew, could you provide an example of how this is used? If I can't test it I can't add it. It doesn't have to be a test module (although a test module for all the SSL support is sorely needed) but I would like to see a little motivation for why this is useful. Also note that the SSL support in the socket module is controversial; there are some who believe that a different approach is needed, e.g. based on M2crypto. ------------------------------------------------------- Date: 2000-Nov-13 11:41 By: gvanrossum Comment: Still no reply. I'll reject the patch now, for lack of sufficient motivation. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101647&group_id=5470 From noreply@sourceforge.net Thu Jan 25 05:38:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 21:38:44 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: <E14Lf7M-0000xv-00@usw-sf-web3.sourceforge.net> Patch #102409 has been updated. Project: python Category: Build Status: Open Submitted by: jlt63 Assigned to : akuchling Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-24 21:38 By: jlt63 Comment: There were two sections to my original Makefile.in patch, fixes for: 1. regen 2. make install I indicated that #1 was already fixed in my comment on 2001-Jan-24 05:58: > It appears that the regen hunk of the Makefile.in part is no longer necessary > since python seems to be setting sys.path correctly to find the standard > modules when running out of the build directory now. Hence, that only leave #2. Do you mind doing that part? ------------------------------------------------------- Date: 2001-Jan-24 11:20 By: akuchling Comment: Neil's checkin of the non-recursive affects Makefile.in, the only portion of this patch that isn't checked in. jlt, should I try to port the Makefile.in changes, or do you want to port them and submit a revised patch? ------------------------------------------------------- Date: 2001-Jan-24 07:43 By: akuchling Comment: Checked in the build_ext.py portion of this patch. ------------------------------------------------------- Date: 2001-Jan-24 07:34 By: akuchling Comment: OK. Then the right thing is probably to lose the setup.cfg file completely, and rely on the command-line declaration of install_platlib. This means that just running './python setup.py install' from the command line won't install in the right place, but oh well... And yes, I'm responsible for built_ext at the moment. ------------------------------------------------------- Date: 2001-Jan-24 06:58 By: jlt63 Comment: > The setup.cfg file should be handling this... or does it do the wrong thing somehow? As you mentioned in a comment for the PEP 229 patch, setup.cfg is hard-coding the installation directory at configure time to "@prefix@/lib/python@VERSION@/lib-dynload". Which means that "make prefix=/tmp/python/usr/local install" does not work as expected. That is, everything except for the standard modules install in "/tmp/python/usr/local" but the standard modules still end up in "/usr/local/lib/python2.1/lib-dynload". This makes it difficult to create a pre-built distribution. Are you the right person to commit the Lib/distutils/command/build_ext.py part? This is crucial to getting the Cygwin build working again. It appears that the regen hunk of the Makefile.in part is no longer necessary since python seems to be setting sys.path correctly to find the standard modules when running out of the build directory now. BTW, setup.cfg.in is missed a NL at the end of the file. ------------------------------------------------------- Date: 2001-Jan-23 19:31 By: akuchling Comment: Checked in the setup.py portion of this patch, modified to factor out the getting of a platform value into a get_platform() method. ------------------------------------------------------- Date: 2001-Jan-23 18:55 By: akuchling Comment: Looking at the Makefile.in part of this patch, why is the --install-platlib argument needed. The setup.cfg file should be handling this... or does it do the wrong thing somehow? ------------------------------------------------------- Date: 2001-Jan-19 22:31 By: jlt63 Comment: This patch enables Cygwin Python to build using the new Distutils style Python build. Please note that the build_ext.py part is from Jorge Sousa <jsousa@cfn.ist.utl.pt>. To patch, change directory to the top of the CVS tree and use $ patch -p0 <dist.patch The following is the ChangeLog: Sat Jan 20 01:05:18 2001 Jason Tishler <jt@dothill.com> * Makefile.in($(srcdir)/Lib/$(PLATDIR)): Add Distutils build library directory to PYTHONPATH so regen works again. (sharedinstall): Add --install-platlib option so shared extensions follow $(exec_prefix). * setup.py: Add checks for Cygwin so unsupported modules (i.e., dbm and resource) are not built. * Lib/distutils/command/build_ext.py(build_ext.finalize_options): Add Cygwin specific code to append Python's library directory to the extension's list of library directories. (build_ext.get_libraries): Add Cygwin specific code to append Python's (import) library to the extension's list of libraries. ------------------------------------------------------- Date: 2001-Jan-19 08:19 By: gvanrossum Comment: Reopened at request. Don't sweat the release date -- t's only the first alpha release. I have a feeling it'll be put off till Monday. ------------------------------------------------------- Date: 2001-Jan-18 20:52 By: jlt63 Comment: Please reopen because I need to redo the Cygwin build to handle the use of distutils to build the standard extension modules instead of Modules/Makefile.pre.in. How much time (if any) do I have to resolve these issues before 2.1a is released. I heard that the release date is tomorrow. Sigh... ------------------------------------------------------- Date: 2001-Jan-10 19:39 By: jlt63 Comment: Your welcome -- thanks for considering and accepting this patch. If the patch proves to reek havoc on other platforms (most likely only on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out. ------------------------------------------------------- Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 <Cygwin-1.1.5-Python-2.0.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Thu Jan 25 06:54:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 22:54:12 -0800 Subject: [Patches] [Patch #101970] Generate more modern file:///C:/foo/bar syntax Message-ID: <E14LgIO-0002nv-00@usw-sf-web2.sourceforge.net> Patch #101970 has been updated. Project: python Category: library Status: Open Submitted by: prescod Assigned to : gvanrossum Summary: Generate more modern file:///C:/foo/bar syntax Follow-Ups: Date: 2001-Jan-24 22:54 By: prescod Comment: Sorry. I must have been drunk when I submitted the first time. :( This patch is better and has an updated docstring. Here's the intent: Newer Windows browsers use the colon to represent the colon instead of the pipe symbol. Therefore, the colon replacement character is an optional argument. If you care about the colon replacement then you should specify it explicitly because the default may change in the future. --- Teaching urllib to accept various forms of Windows file URLs for conversion to (instead of from) pathnames is a whole other science project...but being able to generate URLs suitable for a browser is a good first step. (I'll be on vacation after sending this so discussion will have to wait until I return) ------------------------------------------------------- Date: 2001-Jan-19 14:59 By: gvanrossum Comment: Paul, if you're not interested in this any more, I'll just reject it, OK? ------------------------------------------------------- Date: 2001-Jan-04 07:46 By: gvanrossum Comment: This patch should be rejected based on form. Paul, you can do better than sending in a diff without context! Also, the subject makes no sense. If you still want this, please fix the subject and submit a new patch and we'll lookj at it again. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101970&group_id=5470 From noreply@sourceforge.net Thu Jan 25 08:09:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 00:09:15 -0800 Subject: [Patches] [Patch #103409] install: setup.py 'dbm' header file searching Message-ID: <E14LhT1-0006gf-00@usw-sf-web1.sourceforge.net> Patch #103409 has been updated. Project: python Category: Build Status: Deleted Submitted by: calvin Assigned to : nobody Summary: install: setup.py 'dbm' header file searching Follow-Ups: Date: 2001-Jan-25 00:09 By: moshez Comment: Calvin decided the patch is irrelevant ------------------------------------------------------- Date: 2001-Jan-24 14:53 By: calvin Comment: Ok, its a Debian bug, never mind. ------------------------------------------------------- Date: 2001-Jan-24 14:46 By: calvin Comment: Argh, thats not my problem: the configure program does not find the db1/ndbm.h file. Hmm, will look further into this. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103409&group_id=5470 From noreply@sourceforge.net Thu Jan 25 08:10:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 00:10:31 -0800 Subject: [Patches] [Patch #103392] Add support for lists in urlencode Message-ID: <E14LhUF-0006h5-00@usw-sf-web1.sourceforge.net> Patch #103392 has been updated. Project: python Category: library Status: Open Submitted by: bquinlan Assigned to : nobody Summary: Add support for lists in urlencode Follow-Ups: Date: 2001-Jan-25 00:10 By: moshez Comment: Duplicate 0f 103391 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103392&group_id=5470 From noreply@sourceforge.net Thu Jan 25 08:10:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 00:10:38 -0800 Subject: [Patches] [Patch #103392] Add support for lists in urlencode Message-ID: <E14LhUM-0006h8-00@usw-sf-web1.sourceforge.net> Patch #103392 has been updated. Project: python Category: library Status: Deleted Submitted by: bquinlan Assigned to : nobody Summary: Add support for lists in urlencode Follow-Ups: Date: 2001-Jan-25 00:10 By: moshez Comment: Duplicate 0f 103391 ------------------------------------------------------- Date: 2001-Jan-25 00:10 By: moshez Comment: Duplicate 0f 103391 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103392&group_id=5470 From noreply@sourceforge.net Thu Jan 25 08:14:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 00:14:05 -0800 Subject: [Patches] [Patch #103412] Complete description of percent formatting in libstdtypes Message-ID: <E14LhXh-0006iJ-00@usw-sf-web1.sourceforge.net> Patch #103412 has been updated. Project: python Category: documentation Status: Open Submitted by: efm Assigned to : fdrake Summary: Complete description of percent formatting in libstdtypes Follow-Ups: Date: 2001-Jan-25 00:14 By: moshez Comment: This patch is supposed to close bug 121207 Fred, there are some TeX problems, so I'm assigning this to you. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103412&group_id=5470 From noreply@sourceforge.net Thu Jan 25 13:37:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 05:37:45 -0800 Subject: [Patches] [Patch #101162] a Python/C API testing framework (simple simple) Message-ID: <E14Lmav-0003gz-00@usw-sf-web3.sourceforge.net> Patch #101162 has been updated. Project: python Category: Build Status: Open Submitted by: tmick Assigned to : tim_one Summary: a Python/C API testing framework (simple simple) Follow-Ups: Date: 2001-Jan-25 05:37 By: nobody Comment: This patch needs to be modified to use setup.py rather then Makefile.pre.in ------------------------------------------------------- Date: 2000-Aug-11 13:37 By: tmick Comment: Here is a proposed patch for a Python/C API testing framework. Simple simple. Basic Overview: - add a _test C extension module that exports test functions beginning with 'test_'; NULL and a TestError exception indicates a test failure and Py_None indicate a test pass - add a test_capi.py test module that calls each of the 'test_' exported functions in the '_test' module - changes to the build system files for Win32 and Unix are includes to build _testmodule.c as a shared extension - new files: Lib/test/test_capi.py, Lib/test/output/test_capi, Modules/_testmodule.c, and PCbuild/_test.dsp ------------------------------------------------------- Date: 2000-Aug-11 13:48 By: tmick Comment: don't use C++ style comments ------------------------------------------------------- Date: 2000-Aug-12 13:46 By: tmick Comment: Skip, You seemed to have some interest in this the couple of times it came up on python-dev. I wonder if you might want to review this. No rush, I don't expect this to go in anytime soon. Unless, of course, people just *have* to have it. <wink> ------------------------------------------------------- Date: 2000-Aug-15 15:23 By: tim_one Comment: Sorry, but there is a rush! Since Python 2.0 is scheduled to have only 1 beta cycle, if this doesn't make it into the beta (< 2 weeks, according to the schedule), it's for 2.1 at best. It would be very good to have a start at this (no matter how simple) in place for 2.0. ------------------------------------------------------- Date: 2000-Aug-16 12:05 By: tmick Comment: re: delaying to 2.1: doesn't bother me much Should it now be "postponed", Tim? ------------------------------------------------------- Date: 2000-Aug-21 19:54 By: montanaro Comment: postponed until 2.1 ------------------------------------------------------- Date: 2000-Nov-27 07:47 By: gvanrossum Comment: Randomly reassigned for review now that 2.1 is open and Skip seems to be too busy to look at this. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101162&group_id=5470 From noreply@sourceforge.net Fri Jan 26 15:12:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 07:12:25 -0800 Subject: [Patches] [Patch #103391] Add support for lists in urlencode Message-ID: <E14MAY5-0006rR-00@usw-sf-web2.sourceforge.net> Patch #103391 has been updated. Project: python Category: library Status: Postponed Submitted by: bquinlan Assigned to : montanaro Summary: Add support for lists in urlencode Follow-Ups: Date: 2001-Jan-26 07:12 By: fdrake Comment: This sounds to me like those CGI scripts are buggy. Postponed pending documentation and test suite updates. Assigned to Skip since he thought the idea was reasonable & I can't assign to the submittor. ------------------------------------------------------- Date: 2001-Jan-23 22:34 By: montanaro Comment: Seems like a reasonable extension to me. needs a Doc/lib/liburllib.tex update though. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103391&group_id=5470 From noreply@sourceforge.net Fri Jan 26 15:18:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 07:18:04 -0800 Subject: [Patches] [Patch #103394] check for libtermcap as well as libreadline Message-ID: <E14MAdY-0006uv-00@usw-sf-web2.sourceforge.net> Patch #103394 has been updated. Project: python Category: Build Status: Open Submitted by: sdm7g Assigned to : lemburg Summary: check for libtermcap as well as libreadline Follow-Ups: Date: 2001-Jan-26 07:18 By: fdrake Comment: Assigned to Marc-Andre since he said he'd be working on a patch for this. He can accept this or propose an alternate patch if needed. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103394&group_id=5470 From noreply@sourceforge.net Fri Jan 26 16:22:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 08:22:06 -0800 Subject: [Patches] [Patch #103441] an inline syntax for function attributes Message-ID: <E14MBdW-0005qQ-00@usw-sf-web3.sourceforge.net> Patch #103441 has been updated. Project: python Category: core (C code) Status: Open Submitted by: mwh Assigned to : nobody Summary: an inline syntax for function attributes ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103441&group_id=5470 From noreply@sourceforge.net Fri Jan 26 17:56:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 09:56:12 -0800 Subject: [Patches] [Patch #103391] Add support for lists in urlencode Message-ID: <E14MD6a-0006a6-00@usw-sf-web3.sourceforge.net> Patch #103391 has been updated. Project: python Category: library Status: Postponed Submitted by: bquinlan Assigned to : montanaro Summary: Add support for lists in urlencode Follow-Ups: Date: 2001-Jan-26 09:56 By: bquinlan Comment: Unfortunately, we must sometimes interoperate with scripts that we did not write. Therefore their (buggy) behavior must be accomodated. I did update the test suite. I'll provide a diff for the .tex file sometime today. ------------------------------------------------------- Date: 2001-Jan-26 07:12 By: fdrake Comment: This sounds to me like those CGI scripts are buggy. Postponed pending documentation and test suite updates. Assigned to Skip since he thought the idea was reasonable & I can't assign to the submittor. ------------------------------------------------------- Date: 2001-Jan-23 22:34 By: montanaro Comment: Seems like a reasonable extension to me. needs a Doc/lib/liburllib.tex update though. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103391&group_id=5470 From noreply@sourceforge.net Fri Jan 26 18:23:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 10:23:21 -0800 Subject: [Patches] [Patch #103394] check for libtermcap as well as libreadline Message-ID: <E14MDWr-0006lI-00@usw-sf-web3.sourceforge.net> Patch #103394 has been updated. Project: python Category: Build Status: Closed Submitted by: sdm7g Assigned to : lemburg Summary: check for libtermcap as well as libreadline Follow-Ups: Date: 2001-Jan-26 10:23 By: lemburg Comment: Checked in a slightly different fix. Please verify. ------------------------------------------------------- Date: 2001-Jan-26 07:18 By: fdrake Comment: Assigned to Marc-Andre since he said he'd be working on a patch for this. He can accept this or propose an alternate patch if needed. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103394&group_id=5470 From noreply@sourceforge.net Fri Jan 26 18:34:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 10:34:40 -0800 Subject: [Patches] [Patch #103445] Fixed DB_RECNO support in bsddb module Message-ID: <E14MDho-0008So-00@usw-sf-web2.sourceforge.net> Patch #103445 has been updated. Project: python Category: Modules Status: Open Submitted by: niemeyer Assigned to : nobody Summary: Fixed DB_RECNO support in bsddb module ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103445&group_id=5470 From noreply@sourceforge.net Fri Jan 26 18:54:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 10:54:36 -0800 Subject: [Patches] [Patch #103052] Restore non-cyclic operation of pulldom.PullDOM Message-ID: <E14ME16-000705-00@usw-sf-web3.sourceforge.net> Patch #103052 has been updated. Project: python Category: XML Status: Closed Submitted by: loewis Assigned to : nobody Summary: Restore non-cyclic operation of pulldom.PullDOM Follow-Ups: Date: 2001-Jan-26 10:54 By: loewis Comment: Checked in as 1.15 of pulldom.py ------------------------------------------------------- Date: 2001-Jan-23 18:26 By: akuchling Comment: The patch appears correct as far as I can tell. Note that I'm not that familiar with pulldom; marking as accepted and also assigning to Paul Prescod, in case he can find time to look at it before Martin checks it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103052&group_id=5470 From noreply@sourceforge.net Fri Jan 26 20:01:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 12:01:18 -0800 Subject: [Patches] [Patch #103391] Add support for lists in urlencode Message-ID: <E14MF3e-0000lA-00@usw-sf-web2.sourceforge.net> Patch #103391 has been updated. Project: python Category: library Status: Postponed Submitted by: bquinlan Assigned to : montanaro Summary: Add support for lists in urlencode Follow-Ups: Date: 2001-Jan-26 12:01 By: montanaro Comment: I'll take a closer look at this. It's actually not a bug in the CGI scripts. CGI parameters are supposed to be returned in the order they appear in the form. This allows you to, for instance, ask for two lines of addresses in a mailing label form and name both parameters "address" without losing the user's input order. Kind of fragile though, so I don't recommend it as a standard form programming practice. Skip ------------------------------------------------------- Date: 2001-Jan-26 09:56 By: bquinlan Comment: Unfortunately, we must sometimes interoperate with scripts that we did not write. Therefore their (buggy) behavior must be accomodated. I did update the test suite. I'll provide a diff for the .tex file sometime today. ------------------------------------------------------- Date: 2001-Jan-26 07:12 By: fdrake Comment: This sounds to me like those CGI scripts are buggy. Postponed pending documentation and test suite updates. Assigned to Skip since he thought the idea was reasonable & I can't assign to the submittor. ------------------------------------------------------- Date: 2001-Jan-23 22:34 By: montanaro Comment: Seems like a reasonable extension to me. needs a Doc/lib/liburllib.tex update though. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103391&group_id=5470 From noreply@sourceforge.net Fri Jan 26 20:49:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 12:49:28 -0800 Subject: [Patches] [Patch #103412] Complete description of percent formatting in libstdtypes Message-ID: <E14MFoG-00017n-00@usw-sf-web2.sourceforge.net> Patch #103412 has been updated. Project: python Category: documentation Status: Closed Submitted by: efm Assigned to : fdrake Summary: Complete description of percent formatting in libstdtypes Follow-Ups: Date: 2001-Jan-26 12:49 By: fdrake Comment: Checked in a modified version of this patch as Doc/lib/libstdtypes.tex revision 1.51. Thanks, Evelyn! ------------------------------------------------------- Date: 2001-Jan-25 00:14 By: moshez Comment: This patch is supposed to close bug 121207 Fred, there are some TeX problems, so I'm assigning this to you. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103412&group_id=5470 From noreply@sourceforge.net Fri Jan 26 22:55:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 14:55:25 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: <E14MHm9-0000KQ-00@usw-sf-web3.sourceforge.net> Patch #102409 has been updated. Project: python Category: Build Status: Open Submitted by: jlt63 Assigned to : akuchling Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-26 14:55 By: akuchling Comment: Checked in the change to the sharedinstall target in Makefile.in, which should be the last part of this patch. Jason, when you get time, can you please check whether everything works out of the box now? ------------------------------------------------------- Date: 2001-Jan-24 21:38 By: jlt63 Comment: There were two sections to my original Makefile.in patch, fixes for: 1. regen 2. make install I indicated that #1 was already fixed in my comment on 2001-Jan-24 05:58: > It appears that the regen hunk of the Makefile.in part is no longer necessary > since python seems to be setting sys.path correctly to find the standard > modules when running out of the build directory now. Hence, that only leave #2. Do you mind doing that part? ------------------------------------------------------- Date: 2001-Jan-24 11:20 By: akuchling Comment: Neil's checkin of the non-recursive affects Makefile.in, the only portion of this patch that isn't checked in. jlt, should I try to port the Makefile.in changes, or do you want to port them and submit a revised patch? ------------------------------------------------------- Date: 2001-Jan-24 07:43 By: akuchling Comment: Checked in the build_ext.py portion of this patch. ------------------------------------------------------- Date: 2001-Jan-24 07:34 By: akuchling Comment: OK. Then the right thing is probably to lose the setup.cfg file completely, and rely on the command-line declaration of install_platlib. This means that just running './python setup.py install' from the command line won't install in the right place, but oh well... And yes, I'm responsible for built_ext at the moment. ------------------------------------------------------- Date: 2001-Jan-24 06:58 By: jlt63 Comment: > The setup.cfg file should be handling this... or does it do the wrong thing somehow? As you mentioned in a comment for the PEP 229 patch, setup.cfg is hard-coding the installation directory at configure time to "@prefix@/lib/python@VERSION@/lib-dynload". Which means that "make prefix=/tmp/python/usr/local install" does not work as expected. That is, everything except for the standard modules install in "/tmp/python/usr/local" but the standard modules still end up in "/usr/local/lib/python2.1/lib-dynload". This makes it difficult to create a pre-built distribution. Are you the right person to commit the Lib/distutils/command/build_ext.py part? This is crucial to getting the Cygwin build working again. It appears that the regen hunk of the Makefile.in part is no longer necessary since python seems to be setting sys.path correctly to find the standard modules when running out of the build directory now. BTW, setup.cfg.in is missed a NL at the end of the file. ------------------------------------------------------- Date: 2001-Jan-23 19:31 By: akuchling Comment: Checked in the setup.py portion of this patch, modified to factor out the getting of a platform value into a get_platform() method. ------------------------------------------------------- Date: 2001-Jan-23 18:55 By: akuchling Comment: Looking at the Makefile.in part of this patch, why is the --install-platlib argument needed. The setup.cfg file should be handling this... or does it do the wrong thing somehow? ------------------------------------------------------- Date: 2001-Jan-19 22:31 By: jlt63 Comment: This patch enables Cygwin Python to build using the new Distutils style Python build. Please note that the build_ext.py part is from Jorge Sousa <jsousa@cfn.ist.utl.pt>. To patch, change directory to the top of the CVS tree and use $ patch -p0 <dist.patch The following is the ChangeLog: Sat Jan 20 01:05:18 2001 Jason Tishler <jt@dothill.com> * Makefile.in($(srcdir)/Lib/$(PLATDIR)): Add Distutils build library directory to PYTHONPATH so regen works again. (sharedinstall): Add --install-platlib option so shared extensions follow $(exec_prefix). * setup.py: Add checks for Cygwin so unsupported modules (i.e., dbm and resource) are not built. * Lib/distutils/command/build_ext.py(build_ext.finalize_options): Add Cygwin specific code to append Python's library directory to the extension's list of library directories. (build_ext.get_libraries): Add Cygwin specific code to append Python's (import) library to the extension's list of libraries. ------------------------------------------------------- Date: 2001-Jan-19 08:19 By: gvanrossum Comment: Reopened at request. Don't sweat the release date -- t's only the first alpha release. I have a feeling it'll be put off till Monday. ------------------------------------------------------- Date: 2001-Jan-18 20:52 By: jlt63 Comment: Please reopen because I need to redo the Cygwin build to handle the use of distutils to build the standard extension modules instead of Modules/Makefile.pre.in. How much time (if any) do I have to resolve these issues before 2.1a is released. I heard that the release date is tomorrow. Sigh... ------------------------------------------------------- Date: 2001-Jan-10 19:39 By: jlt63 Comment: Your welcome -- thanks for considering and accepting this patch. If the patch proves to reek havoc on other platforms (most likely only on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out. ------------------------------------------------------- Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 <Cygwin-1.1.5-Python-2.0.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Fri Jan 26 23:11:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 15:11:35 -0800 Subject: [Patches] [Patch #103138] Install IDLE via distutils Message-ID: <E14MI1n-0002AW-00@usw-sf-web2.sourceforge.net> Patch #103138 has been updated. Project: python Category: IDLE Status: Accepted Submitted by: loewis Assigned to : akuchling Summary: Install IDLE via distutils Follow-Ups: Date: 2001-Jan-26 15:11 By: akuchling Comment: Looks good. Go ahead and check it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103138&group_id=5470 From noreply@sourceforge.net Sat Jan 27 04:04:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 20:04:02 -0800 Subject: [Patches] [Patch #103453] PyMember_Set of T_CHAR always raises exception Message-ID: <E14MMao-0002BW-00@usw-sf-web3.sourceforge.net> Patch #103453 has been updated. Project: python Category: core (C code) Status: Open Submitted by: davecole Assigned to : nobody Summary: PyMember_Set of T_CHAR always raises exception ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103453&group_id=5470 From noreply@sourceforge.net Sat Jan 27 04:57:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 20:57:18 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: <E14MNQM-0002TT-00@usw-sf-web3.sourceforge.net> Patch #102409 has been updated. Project: python Category: Build Status: Open Submitted by: jlt63 Assigned to : akuchling Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-26 20:57 By: jlt63 Comment: Thanks for checking in your changes -- they were all fine. Unfortunately, the changes added for "flattening" the makefiles by nascheme broke the Cygwin build. The attached patch allows Cygwin to build OOTB again. Please reassign to nascheme or check in yourself, if appropriate. ------------------------------------------------------- Date: 2001-Jan-26 14:55 By: akuchling Comment: Checked in the change to the sharedinstall target in Makefile.in, which should be the last part of this patch. Jason, when you get time, can you please check whether everything works out of the box now? ------------------------------------------------------- Date: 2001-Jan-24 21:38 By: jlt63 Comment: There were two sections to my original Makefile.in patch, fixes for: 1. regen 2. make install I indicated that #1 was already fixed in my comment on 2001-Jan-24 05:58: > It appears that the regen hunk of the Makefile.in part is no longer necessary > since python seems to be setting sys.path correctly to find the standard > modules when running out of the build directory now. Hence, that only leave #2. Do you mind doing that part? ------------------------------------------------------- Date: 2001-Jan-24 11:20 By: akuchling Comment: Neil's checkin of the non-recursive affects Makefile.in, the only portion of this patch that isn't checked in. jlt, should I try to port the Makefile.in changes, or do you want to port them and submit a revised patch? ------------------------------------------------------- Date: 2001-Jan-24 07:43 By: akuchling Comment: Checked in the build_ext.py portion of this patch. ------------------------------------------------------- Date: 2001-Jan-24 07:34 By: akuchling Comment: OK. Then the right thing is probably to lose the setup.cfg file completely, and rely on the command-line declaration of install_platlib. This means that just running './python setup.py install' from the command line won't install in the right place, but oh well... And yes, I'm responsible for built_ext at the moment. ------------------------------------------------------- Date: 2001-Jan-24 06:58 By: jlt63 Comment: > The setup.cfg file should be handling this... or does it do the wrong thing somehow? As you mentioned in a comment for the PEP 229 patch, setup.cfg is hard-coding the installation directory at configure time to "@prefix@/lib/python@VERSION@/lib-dynload". Which means that "make prefix=/tmp/python/usr/local install" does not work as expected. That is, everything except for the standard modules install in "/tmp/python/usr/local" but the standard modules still end up in "/usr/local/lib/python2.1/lib-dynload". This makes it difficult to create a pre-built distribution. Are you the right person to commit the Lib/distutils/command/build_ext.py part? This is crucial to getting the Cygwin build working again. It appears that the regen hunk of the Makefile.in part is no longer necessary since python seems to be setting sys.path correctly to find the standard modules when running out of the build directory now. BTW, setup.cfg.in is missed a NL at the end of the file. ------------------------------------------------------- Date: 2001-Jan-23 19:31 By: akuchling Comment: Checked in the setup.py portion of this patch, modified to factor out the getting of a platform value into a get_platform() method. ------------------------------------------------------- Date: 2001-Jan-23 18:55 By: akuchling Comment: Looking at the Makefile.in part of this patch, why is the --install-platlib argument needed. The setup.cfg file should be handling this... or does it do the wrong thing somehow? ------------------------------------------------------- Date: 2001-Jan-19 22:31 By: jlt63 Comment: This patch enables Cygwin Python to build using the new Distutils style Python build. Please note that the build_ext.py part is from Jorge Sousa <jsousa@cfn.ist.utl.pt>. To patch, change directory to the top of the CVS tree and use $ patch -p0 <dist.patch The following is the ChangeLog: Sat Jan 20 01:05:18 2001 Jason Tishler <jt@dothill.com> * Makefile.in($(srcdir)/Lib/$(PLATDIR)): Add Distutils build library directory to PYTHONPATH so regen works again. (sharedinstall): Add --install-platlib option so shared extensions follow $(exec_prefix). * setup.py: Add checks for Cygwin so unsupported modules (i.e., dbm and resource) are not built. * Lib/distutils/command/build_ext.py(build_ext.finalize_options): Add Cygwin specific code to append Python's library directory to the extension's list of library directories. (build_ext.get_libraries): Add Cygwin specific code to append Python's (import) library to the extension's list of libraries. ------------------------------------------------------- Date: 2001-Jan-19 08:19 By: gvanrossum Comment: Reopened at request. Don't sweat the release date -- t's only the first alpha release. I have a feeling it'll be put off till Monday. ------------------------------------------------------- Date: 2001-Jan-18 20:52 By: jlt63 Comment: Please reopen because I need to redo the Cygwin build to handle the use of distutils to build the standard extension modules instead of Modules/Makefile.pre.in. How much time (if any) do I have to resolve these issues before 2.1a is released. I heard that the release date is tomorrow. Sigh... ------------------------------------------------------- Date: 2001-Jan-10 19:39 By: jlt63 Comment: Your welcome -- thanks for considering and accepting this patch. If the patch proves to reek havoc on other platforms (most likely only on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out. ------------------------------------------------------- Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 <Cygwin-1.1.5-Python-2.0.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Sat Jan 27 05:30:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 21:30:57 -0800 Subject: [Patches] [Patch #103391] Add support for lists in urlencode Message-ID: <E14MNwv-0004Ub-00@usw-sf-web2.sourceforge.net> Patch #103391 has been updated. Project: python Category: library Status: Postponed Submitted by: bquinlan Assigned to : montanaro Summary: Add support for lists in urlencode Follow-Ups: Date: 2001-Jan-26 21:30 By: bquinlan Comment: Not sure how to post this... Here is a mod to liburllib.tex, change the section for urlencode at 146: \begin{funcdesc}{urlencode}{query\optional{, doseq}} Convert a list of 2-tuples or a dictionary to a ``url-encoded'' string, suitable to pass to \function{urlopen()} above as the optional \var{data} argument. This is useful to pass form fields to a \code{POST} request. The resulting string is a series of \code{\var{key}=\var{value}} pairs separated by \character{\&} characters, where both \var{key} and \var{value} are quoted using \function{quote_plus()} above. If the optional parameter \var{doseq} is present and evaluates to true, individual \code{\var{key}=\var{value}} pairs are generated for each element of the sequence. \end{funcdesc} ------------------------------------------------------- Date: 2001-Jan-26 12:01 By: montanaro Comment: I'll take a closer look at this. It's actually not a bug in the CGI scripts. CGI parameters are supposed to be returned in the order they appear in the form. This allows you to, for instance, ask for two lines of addresses in a mailing label form and name both parameters "address" without losing the user's input order. Kind of fragile though, so I don't recommend it as a standard form programming practice. Skip ------------------------------------------------------- Date: 2001-Jan-26 09:56 By: bquinlan Comment: Unfortunately, we must sometimes interoperate with scripts that we did not write. Therefore their (buggy) behavior must be accomodated. I did update the test suite. I'll provide a diff for the .tex file sometime today. ------------------------------------------------------- Date: 2001-Jan-26 07:12 By: fdrake Comment: This sounds to me like those CGI scripts are buggy. Postponed pending documentation and test suite updates. Assigned to Skip since he thought the idea was reasonable & I can't assign to the submittor. ------------------------------------------------------- Date: 2001-Jan-23 22:34 By: montanaro Comment: Seems like a reasonable extension to me. needs a Doc/lib/liburllib.tex update though. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103391&group_id=5470 From noreply@sourceforge.net Sat Jan 27 06:05:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 22:05:45 -0800 Subject: [Patches] [Patch #103453] PyMember_Set of T_CHAR always raises exception Message-ID: <E14MOUb-0002r0-00@usw-sf-web3.sourceforge.net> Patch #103453 has been updated. Project: python Category: core (C code) Status: Open Submitted by: davecole Assigned to : tim_one Summary: PyMember_Set of T_CHAR always raises exception Follow-Ups: Date: 2001-Jan-26 22:05 By: tim_one Comment: Assigned to me. This also related to some recent bug report. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103453&group_id=5470 From noreply@sourceforge.net Sat Jan 27 06:06:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 22:06:15 -0800 Subject: [Patches] [Patch #103445] Fixed DB_RECNO support in bsddb module Message-ID: <E14MOV5-0002rM-00@usw-sf-web3.sourceforge.net> Patch #103445 has been updated. Project: python Category: Modules Status: Open Submitted by: niemeyer Assigned to : montanaro Summary: Fixed DB_RECNO support in bsddb module Follow-Ups: Date: 2001-Jan-26 22:06 By: fdrake Comment: I think this is fine from a quick eyeballing of the code, but would add the di_type declaration before the WITH_THREAD conditional section so that the optional part is at the end. Assigned to Skip since he's dealt a lot with this module recently. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103445&group_id=5470 From noreply@sourceforge.net Sat Jan 27 06:21:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 22:21:44 -0800 Subject: [Patches] [Patch #103453] PyMember_Set of T_CHAR always raises exception Message-ID: <E14MOk4-0002wc-00@usw-sf-web3.sourceforge.net> Patch #103453 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: davecole Assigned to : tim_one Summary: PyMember_Set of T_CHAR always raises exception Follow-Ups: Date: 2001-Jan-26 22:21 By: tim_one Comment: Applied and closed, structmember.c rev 2.19, ACKS rev 1.75. Checkin comment: SF bug http://sourceforge.net/bugs/?func=detailbug&bug_id=130242&group_id=5470 SF patch http://sourceforge.net/patch/?func=detailpatch&patch_id=103453&group_id=5470 PyMember_Set of T_CHAR always raises exception. Unfortunately, this is a use of a C API function that Python itself never makes, so there's no .py test I can check in to verify this stays fixed. But the fault in the code is obvious, and Dave Cole's patch just as obviously fixes it. ------------------------------------------------------- Date: 2001-Jan-26 22:05 By: tim_one Comment: Assigned to me. This also related to some recent bug report. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103453&group_id=5470 From noreply@sourceforge.net Sat Jan 27 20:28:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 27 Jan 2001 12:28:26 -0800 Subject: [Patches] [Patch #103457] Fixed shadowing problem with cmpfunc in Mac OS X Message-ID: <E14MbxS-0001bd-00@usw-sf-web2.sourceforge.net> Patch #103457 has been updated. Project: python Category: core (C code) Status: Open Submitted by: bquinlan Assigned to : nobody Summary: Fixed shadowing problem with cmpfunc in Mac OS X ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103457&group_id=5470 From noreply@sourceforge.net Sat Jan 27 21:10:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 27 Jan 2001 13:10:53 -0800 Subject: [Patches] [Patch #103457] Fixed shadowing problem with cmpfunc in Mac OS X Message-ID: <E14MccX-0001rh-00@usw-sf-web2.sourceforge.net> Patch #103457 has been updated. Project: python Category: core (C code) Status: Open Submitted by: bquinlan Assigned to : nobody Summary: Fixed shadowing problem with cmpfunc in Mac OS X Follow-Ups: Date: 2001-Jan-27 13:10 By: bquinlan Comment: See bug #129827 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103457&group_id=5470 From noreply@sourceforge.net Sat Jan 27 21:48:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 27 Jan 2001 13:48:54 -0800 Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch Message-ID: <E14MdDK-00026f-00@usw-sf-web2.sourceforge.net> Patch #102409 has been updated. Project: python Category: Build Status: Closed Submitted by: jlt63 Assigned to : nobody Summary: Cygwin Python DLL and Shared Extension Patch Follow-Ups: Date: 2001-Jan-27 13:48 By: nascheme Comment: Checked in. Thanks Jason. ------------------------------------------------------- Date: 2001-Jan-26 20:57 By: jlt63 Comment: Thanks for checking in your changes -- they were all fine. Unfortunately, the changes added for "flattening" the makefiles by nascheme broke the Cygwin build. The attached patch allows Cygwin to build OOTB again. Please reassign to nascheme or check in yourself, if appropriate. ------------------------------------------------------- Date: 2001-Jan-26 14:55 By: akuchling Comment: Checked in the change to the sharedinstall target in Makefile.in, which should be the last part of this patch. Jason, when you get time, can you please check whether everything works out of the box now? ------------------------------------------------------- Date: 2001-Jan-24 21:38 By: jlt63 Comment: There were two sections to my original Makefile.in patch, fixes for: 1. regen 2. make install I indicated that #1 was already fixed in my comment on 2001-Jan-24 05:58: > It appears that the regen hunk of the Makefile.in part is no longer necessary > since python seems to be setting sys.path correctly to find the standard > modules when running out of the build directory now. Hence, that only leave #2. Do you mind doing that part? ------------------------------------------------------- Date: 2001-Jan-24 11:20 By: akuchling Comment: Neil's checkin of the non-recursive affects Makefile.in, the only portion of this patch that isn't checked in. jlt, should I try to port the Makefile.in changes, or do you want to port them and submit a revised patch? ------------------------------------------------------- Date: 2001-Jan-24 07:43 By: akuchling Comment: Checked in the build_ext.py portion of this patch. ------------------------------------------------------- Date: 2001-Jan-24 07:34 By: akuchling Comment: OK. Then the right thing is probably to lose the setup.cfg file completely, and rely on the command-line declaration of install_platlib. This means that just running './python setup.py install' from the command line won't install in the right place, but oh well... And yes, I'm responsible for built_ext at the moment. ------------------------------------------------------- Date: 2001-Jan-24 06:58 By: jlt63 Comment: > The setup.cfg file should be handling this... or does it do the wrong thing somehow? As you mentioned in a comment for the PEP 229 patch, setup.cfg is hard-coding the installation directory at configure time to "@prefix@/lib/python@VERSION@/lib-dynload". Which means that "make prefix=/tmp/python/usr/local install" does not work as expected. That is, everything except for the standard modules install in "/tmp/python/usr/local" but the standard modules still end up in "/usr/local/lib/python2.1/lib-dynload". This makes it difficult to create a pre-built distribution. Are you the right person to commit the Lib/distutils/command/build_ext.py part? This is crucial to getting the Cygwin build working again. It appears that the regen hunk of the Makefile.in part is no longer necessary since python seems to be setting sys.path correctly to find the standard modules when running out of the build directory now. BTW, setup.cfg.in is missed a NL at the end of the file. ------------------------------------------------------- Date: 2001-Jan-23 19:31 By: akuchling Comment: Checked in the setup.py portion of this patch, modified to factor out the getting of a platform value into a get_platform() method. ------------------------------------------------------- Date: 2001-Jan-23 18:55 By: akuchling Comment: Looking at the Makefile.in part of this patch, why is the --install-platlib argument needed. The setup.cfg file should be handling this... or does it do the wrong thing somehow? ------------------------------------------------------- Date: 2001-Jan-19 22:31 By: jlt63 Comment: This patch enables Cygwin Python to build using the new Distutils style Python build. Please note that the build_ext.py part is from Jorge Sousa <jsousa@cfn.ist.utl.pt>. To patch, change directory to the top of the CVS tree and use $ patch -p0 <dist.patch The following is the ChangeLog: Sat Jan 20 01:05:18 2001 Jason Tishler <jt@dothill.com> * Makefile.in($(srcdir)/Lib/$(PLATDIR)): Add Distutils build library directory to PYTHONPATH so regen works again. (sharedinstall): Add --install-platlib option so shared extensions follow $(exec_prefix). * setup.py: Add checks for Cygwin so unsupported modules (i.e., dbm and resource) are not built. * Lib/distutils/command/build_ext.py(build_ext.finalize_options): Add Cygwin specific code to append Python's library directory to the extension's list of library directories. (build_ext.get_libraries): Add Cygwin specific code to append Python's (import) library to the extension's list of libraries. ------------------------------------------------------- Date: 2001-Jan-19 08:19 By: gvanrossum Comment: Reopened at request. Don't sweat the release date -- t's only the first alpha release. I have a feeling it'll be put off till Monday. ------------------------------------------------------- Date: 2001-Jan-18 20:52 By: jlt63 Comment: Please reopen because I need to redo the Cygwin build to handle the use of distutils to build the standard extension modules instead of Modules/Makefile.pre.in. How much time (if any) do I have to resolve these issues before 2.1a is released. I heard that the release date is tomorrow. Sigh... ------------------------------------------------------- Date: 2001-Jan-10 19:39 By: jlt63 Comment: Your welcome -- thanks for considering and accepting this patch. If the patch proves to reek havoc on other platforms (most likely only on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out. ------------------------------------------------------- Date: 2001-Jan-10 13:12 By: gvanrossum Comment: Checked in. Thanks! Again, I've only verified that this doesn't break the Linux build. ------------------------------------------------------- Date: 2001-Jan-08 18:14 By: jlt63 Comment: This is the second version of the patch with the following significant changes since the first version: 1. The standard modules also can be built as shared extensions and they will have the same basenames as on other UNIX platforms. 2. Fixed a problem that prevented the loading of multiple shared extensions due to DLL base address conflicts. Please see the ChangeLog below for more details. Otherwise, the patch is essential the same as the previous one. I agree with Tim's 2001-Jan-05 09:52 assessment of the patch -- it is more important to determine whether this patch will break other platforms than whether it works on Cygwin. Although any change to the configure, makefile, and makesetup infrastructure can break any platform (other than Win32), I feel that the following change is the one that needs the most scrutinizing: * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Although I have tested the patch on Linux and can do so on Solaris, HP-UX, and Win32. Unfortunately, I cannot test it on NeXT, DG/UX, or BeOS which are the only platforms that currently use LDLIBRARY. Can someone knowledgeable with these platforms be asked to evaluate the impact on their respective platforms? Once this issue is resolved, then I feel (possibly naively) that the rest of the patch has a good chance of being accepted. The following is an annotated ChangeLog for the second version of the patch: Mon Jan 8 20:32:30 2001 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. * configure.in: Add Cygwin case to set CCSHARED appropriately. * Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.pre.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add section to define extra libraries used during the linking of shared extensions (currently only used by Cygwin). * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change shared extension rule to include extra libraries (if any) during linking. Is it undesirable to put platform specific code in makesetup? * Modules/mmapmodule.c: Clean up to enable building as a Cygwin (and Win32) shared extension. * Modules/readline.c: Ditto. * Modules/rotormodule.c: Ditto. * Modules/shamodule.c: Ditto. * Python/dynload_shlib.c: Add "module.dll" to the list of Cygwin shared extensions; remove ".pyd". Note that his change essentially backs out the fix for bug #115973. Should ".pyd" be retained instead for posterity? ------------------------------------------------------- Date: 2001-Jan-07 02:32 By: tim_one Comment: Yes, I told Jason (in email) I would agitate toward this end. At this point it needs someone more familiar with the Unixish build process than I am, though (haven't run a Unix box since '94, back when Python Unix config wasn't hiding under umpteen layers of black magic ...). ------------------------------------------------------- Date: 2001-Jan-06 16:20 By: nhv Comment: Any chance of getting this patch applied before the 2.1 release ? ------------------------------------------------------- Date: 2001-Jan-05 10:52 By: tim_one Comment: Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what appears to be a clean Cygwin install on my box now, but, as with any new build environment, it will take an unknown number of hours to work out its quirks. And I'll do that someday, but, frankly, it's irrelevant: this is no different than a patch that purports to improve the build process on, say, HP-UX. The author says it works, and while it would be *nice* to take the time to confirm that, it's *essential* to confirm that it doesn't break the build process on the systems we do use (I may build Python on Cygwim from time to time someday because "it's nice to check it", but that's never going to be a platform I routinely *use*). Since the patch has no possible effect on the MS Windows build process (the changes are entirely to the Unix build process), checking that it doesn't break other builds is something a Unix guy has to do. Of course that "Unix guy" doesn't need to be you -- but it sure isn't me. ------------------------------------------------------- Date: 2000-Nov-16 07:40 By: jlt63 Comment: This patch builds Cygwin Python with its core as a DLL -- similar to the way that Win32 Python is built. Once Cygwin Python is built as a "shared library" (i.e., DLL), the procedure for building extensions is the same as on UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. The following is the procedure to apply the patch and build Cygwin Python: $ patch -p0 <Cygwin-1.1.5-Python-2.0.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. The following is an annotated ChangeLog for the patch: Thu Nov 16 10:38:20 2000 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set LN appropriately. * configure.in: Add Cygwin case to set OPT appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? ------------------------------------------------------- Date: 2000-Nov-16 10:01 By: nhv Comment: Incorporating this patch will make Cygwin a much nicer enviroment for Python development. I have beta tested this and it works as advertised for me :-) ------------------------------------------------------- Date: 2000-Nov-27 13:27 By: gvanrossum Comment: Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added! ------------------------------------------------------- Date: 2000-Nov-27 14:23 By: jlt63 Comment: Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 From noreply@sourceforge.net Sun Jan 28 01:02:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 27 Jan 2001 17:02:30 -0800 Subject: [Patches] [Patch #101137] Add raw packet support to socketmodule.c Message-ID: <E14MgEg-0003Hg-00@usw-sf-web2.sourceforge.net> Patch #101137 has been updated. Project: python Category: Modules Status: Open Submitted by: grante Assigned to : jhylton Summary: Add raw packet support to socketmodule.c Follow-Ups: Date: 2001-Jan-27 17:02 By: grante Comment: Revised patch: 1) fixed indentation style. 2) fixed possible strncpy buffer overrun. 3) fixed bug in getsockname. 4) exposed sll_pkttype and sll_hatype fields of sockaddr_ll struct (AFAICT, they're not useful). 5) changed conditional compilation so AF_PACKET stuff is only built under Linux. (patch is against 2.0) ------------------------------------------------------- Date: 2001-Jan-18 10:01 By: nobody Comment: Yes, I'm still interested in this patch. Winthin the next week or two I'll try to get a revised patch submitted that addresses some of the comments. Two things I can't do much about are: 1) I only have Linux systems for testing: I don't have root privledges on any other type of system. 2) Unless it is agreed to change parameters for makesockaddr, I can't do anything except create a temporary socket in order to look up the interface name. I suppose I could require user code to provide an interface index, but I don't really like that option since it diverges quite a bit from the "C" usage. ------------------------------------------------------- Date: 2001-Jan-18 09:39 By: jhylton Comment: Is Grant still interested in this patch? I don't have time to fix it myself, but I would be happy to look at it again if we comments and questions are addressed. ------------------------------------------------------- Date: 2000-Aug-09 14:49 By: grante Comment: Patch has only been tested on Linux: RH6.2 (Intel). Patch is against 1.6b1 ------------------------------------------------------- Date: 2000-Aug-15 15:15 By: tim_one Comment: Assigned to Barry, since he just volunteered to rewrite all of Python's socket code anyway <wink>. ------------------------------------------------------- Date: 2000-Aug-24 14:27 By: jhylton Comment: Not sure about this patch. It needs to be tested on more platforms than just Linux, but I don't see that we'll have time before 2.0. There are several other issues that must be resolved, too. Thus, this patch falls subject to the feature freeze. Style points: Indention is wrong. The opening curly brace of an if belongs on the same line as the test. Whitespace is required around = and after commas in argument lists. The strncpy in makesockaddr does not check the size of the source string. It could overflow the buffer. In makesockaddr, a new socket is created just to look up the interface name associated with a particular interface. This seems wasteful, particularly in cases where few file descriptors are available. I'm not sure what the solution is, although it might be to change the makesockaddr function so that it takes the socket itself. Perhaps that socket address for AF_PACKET should also accept and/or produce interface numbers which the client can convert to names manually. The sockaddr_ll has members ssl_hatype and ssl_pkttype, which are not made accessible by this patch. It seems like they should be, but I am not sure. Can you use SOCK_DGRAM without specifying the packet type? getsockaddrarg is handled, but getsockaddrlen is not. Question: Are there any other constants that should be added? This relates to the packet type question. * ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101137&group_id=5470 From noreply@sourceforge.net Sun Jan 28 01:26:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 27 Jan 2001 17:26:34 -0800 Subject: [Patches] [Patch #103395] Guido changed his mind! Quickly, add 'if key in dict'! Message-ID: <E14Mgby-000577-00@usw-sf-web1.sourceforge.net> Patch #103395 has been updated. Project: python Category: core (C code) Status: Open Submitted by: twouters Assigned to : gvanrossum Summary: Guido changed his mind! Quickly, add 'if key in dict'! Follow-Ups: Date: 2001-Jan-27 17:26 By: twouters Comment: Newer patch, avoids Misc/NEWS conflict, fixes oversight in dict_contains. ------------------------------------------------------- Date: 2001-Jan-24 01:05 By: tim_one Comment: There must be something in the air, besides email delays. I'll take your word for it that Guido changed his mind, but I was about to say +1 anyway! Now all we have to do is trick xreadlines into iterating over dicts <wink>. ------------------------------------------------------- Date: 2001-Jan-23 23:39 By: twouters Comment: Added testcases for dict and UserDict. ------------------------------------------------------- Date: 2001-Jan-23 23:20 By: twouters Comment: Add some docs (not guarded by a 'new in 2.1' statement, I don't know how to do that), NEWS item and support in UserDict.UserDict. Docs of has_key should probably also mention that 'if key in dict' does the same, but I'm not sure how to say that's new in Python 2.1. ------------------------------------------------------- Date: 2001-Jan-23 22:57 By: twouters Comment: There yah go, Guido. Does my being awakened by my loud and malicious partner (who needs to head to her office 4 hours before me) earn me yet another free and legally useless 2.1 alpha ? :-) Note: it's missing docs. Will add then once I figure out where to add them. Also haven't updated the std-lib yet, will do that next. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103395&group_id=5470 From noreply@sourceforge.net Sun Jan 28 05:53:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 27 Jan 2001 21:53:02 -0800 Subject: [Patches] [Patch #103395] Guido changed his mind! Quickly, add 'if key in dict'! Message-ID: <E14Mklq-0003EJ-00@usw-sf-web3.sourceforge.net> Patch #103395 has been updated. Project: python Category: core (C code) Status: Open Submitted by: twouters Assigned to : tim_one Summary: Guido changed his mind! Quickly, add 'if key in dict'! Follow-Ups: Date: 2001-Jan-27 21:53 By: tim_one Comment: Assigned to me while Guido is sleeping so he doesn't get a chance to change his mind. ------------------------------------------------------- Date: 2001-Jan-27 17:26 By: twouters Comment: Newer patch, avoids Misc/NEWS conflict, fixes oversight in dict_contains. ------------------------------------------------------- Date: 2001-Jan-24 01:05 By: tim_one Comment: There must be something in the air, besides email delays. I'll take your word for it that Guido changed his mind, but I was about to say +1 anyway! Now all we have to do is trick xreadlines into iterating over dicts <wink>. ------------------------------------------------------- Date: 2001-Jan-23 23:39 By: twouters Comment: Added testcases for dict and UserDict. ------------------------------------------------------- Date: 2001-Jan-23 23:20 By: twouters Comment: Add some docs (not guarded by a 'new in 2.1' statement, I don't know how to do that), NEWS item and support in UserDict.UserDict. Docs of has_key should probably also mention that 'if key in dict' does the same, but I'm not sure how to say that's new in Python 2.1. ------------------------------------------------------- Date: 2001-Jan-23 22:57 By: twouters Comment: There yah go, Guido. Does my being awakened by my loud and malicious partner (who needs to head to her office 4 hours before me) earn me yet another free and legally useless 2.1 alpha ? :-) Note: it's missing docs. Will add then once I figure out where to add them. Also haven't updated the std-lib yet, will do that next. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103395&group_id=5470 From noreply@sourceforge.net Sun Jan 28 07:11:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 27 Jan 2001 23:11:02 -0800 Subject: [Patches] [Patch #103445] Fixed DB_RECNO support in bsddb module Message-ID: <E14MlzK-0003cO-00@usw-sf-web3.sourceforge.net> Patch #103445 has been updated. Project: python Category: Modules Status: Open Submitted by: niemeyer Assigned to : fdrake Summary: Fixed DB_RECNO support in bsddb module Follow-Ups: Date: 2001-Jan-27 23:11 By: fdrake Comment: Re-assigned to me; Skip only worked on the build process for this, not the module code. ------------------------------------------------------- Date: 2001-Jan-26 22:06 By: fdrake Comment: I think this is fine from a quick eyeballing of the code, but would add the di_type declaration before the WITH_THREAD conditional section so that the optional part is at the end. Assigned to Skip since he's dealt a lot with this module recently. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103445&group_id=5470 From noreply@sourceforge.net Sun Jan 28 07:18:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 27 Jan 2001 23:18:11 -0800 Subject: [Patches] [Patch #103395] Guido changed his mind! Quickly, add 'if key in dict'! Message-ID: <E14Mm6F-0003ew-00@usw-sf-web3.sourceforge.net> Patch #103395 has been updated. Project: python Category: core (C code) Status: Open Submitted by: twouters Assigned to : fdrake Summary: Guido changed his mind! Quickly, add 'if key in dict'! Follow-Ups: Date: 2001-Jan-27 23:18 By: tim_one Comment: Reviewed the code and tried it out. Boffo! It's Accepted as far as I'm concerned. Cute: the Cygwin "patch" program core dumped consistently when trying to apply the NEWS patch, so I didn't test that part <wink>. Assigned to Fred for final disposition, since Thomas noted doc questions in his comments. I'll add that, since the docs already explain has_key, nothing good can come of trying to explain "in" via different words; would be shorter and better to just say x in dict == dict.has_key(x) x not in dict == not dict.has_key(x) everywhere it comes up. ------------------------------------------------------- Date: 2001-Jan-27 21:53 By: tim_one Comment: Assigned to me while Guido is sleeping so he doesn't get a chance to change his mind. ------------------------------------------------------- Date: 2001-Jan-27 17:26 By: twouters Comment: Newer patch, avoids Misc/NEWS conflict, fixes oversight in dict_contains. ------------------------------------------------------- Date: 2001-Jan-24 01:05 By: tim_one Comment: There must be something in the air, besides email delays. I'll take your word for it that Guido changed his mind, but I was about to say +1 anyway! Now all we have to do is trick xreadlines into iterating over dicts <wink>. ------------------------------------------------------- Date: 2001-Jan-23 23:39 By: twouters Comment: Added testcases for dict and UserDict. ------------------------------------------------------- Date: 2001-Jan-23 23:20 By: twouters Comment: Add some docs (not guarded by a 'new in 2.1' statement, I don't know how to do that), NEWS item and support in UserDict.UserDict. Docs of has_key should probably also mention that 'if key in dict' does the same, but I'm not sure how to say that's new in Python 2.1. ------------------------------------------------------- Date: 2001-Jan-23 22:57 By: twouters Comment: There yah go, Guido. Does my being awakened by my loud and malicious partner (who needs to head to her office 4 hours before me) earn me yet another free and legally useless 2.1 alpha ? :-) Note: it's missing docs. Will add then once I figure out where to add them. Also haven't updated the std-lib yet, will do that next. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103395&group_id=5470 From noreply@sourceforge.net Sun Jan 28 11:02:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 28 Jan 2001 03:02:41 -0800 Subject: [Patches] [Patch #103138] Install IDLE via distutils Message-ID: <E14MpbV-0004rd-00@usw-sf-web3.sourceforge.net> Patch #103138 has been updated. Project: python Category: IDLE Status: Closed Submitted by: loewis Assigned to : nobody Summary: Install IDLE via distutils Follow-Ups: Date: 2001-Jan-26 15:11 By: akuchling Comment: Looks good. Go ahead and check it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103138&group_id=5470 From noreply@sourceforge.net Sun Jan 28 11:03:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 28 Jan 2001 03:03:20 -0800 Subject: [Patches] [Patch #103138] Install IDLE via distutils Message-ID: <E14Mpc8-0004rq-00@usw-sf-web3.sourceforge.net> Patch #103138 has been updated. Project: python Category: IDLE Status: Closed Submitted by: loewis Assigned to : nobody Summary: Install IDLE via distutils Follow-Ups: Date: 2001-Jan-28 03:03 By: loewis Comment: Committed as 1.3 of idle and 1.1 of setup.py ------------------------------------------------------- Date: 2001-Jan-26 15:11 By: akuchling Comment: Looks good. Go ahead and check it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103138&group_id=5470 From noreply@sourceforge.net Sun Jan 28 17:44:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 28 Jan 2001 09:44:30 -0800 Subject: [Patches] [Patch #103471] xml pretty-printing in minidom Message-ID: <E14MvsM-0001UB-00@usw-sf-web2.sourceforge.net> Patch #103471 has been updated. Project: python Category: library Status: Open Submitted by: isk Assigned to : nobody Summary: xml pretty-printing in minidom ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103471&group_id=5470 From noreply@sourceforge.net Sun Jan 28 18:19:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 28 Jan 2001 10:19:25 -0800 Subject: [Patches] [Patch #103277] Enables a package to have more than one source dir Message-ID: <E14MwQ9-0001io-00@usw-sf-web2.sourceforge.net> Patch #103277 has been updated. Project: python Category: distutils Status: Open Submitted by: nobody Assigned to : akuchling Summary: Enables a package to have more than one source dir Follow-Ups: Date: 2001-Jan-28 10:19 By: akuchling Comment: I'm doubtful of the usefulness of this patch; can you please explain the motivation? Why do you want to have multiple directories containing the Python files for a single package? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103277&group_id=5470 From noreply@sourceforge.net Sun Jan 28 20:32:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 28 Jan 2001 12:32:17 -0800 Subject: [Patches] [Patch #103473] Cookie.py: Allow values containing '=' Message-ID: <E14MyUj-0002b3-00@usw-sf-web2.sourceforge.net> Patch #103473 has been updated. Project: python Category: library Status: Open Submitted by: dougfort Assigned to : nobody Summary: Cookie.py: Allow values containing '=' ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103473&group_id=5470 From noreply@sourceforge.net Sun Jan 28 21:19:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 28 Jan 2001 13:19:43 -0800 Subject: [Patches] [Patch #103391] Add support for lists in urlencode Message-ID: <E14MzEd-0004oQ-00@usw-sf-web1.sourceforge.net> Patch #103391 has been updated. Project: python Category: library Status: Accepted Submitted by: bquinlan Assigned to : fdrake Summary: Add support for lists in urlencode Follow-Ups: Date: 2001-Jan-28 13:19 By: montanaro Comment: accepted with modifications and closed the major modification was to expand the acceptable input types beyond dictionaries and lists. Anything that has an items method should work as a stand-in for a real dictionary, and anything that is a non-empty sequence of two-element tuples should workk as a stand-in for lists. test cases suitably extended & documentation adjusted. Marked as accepted and reassigned to Fred so he can sign off on the urlencode documentation. (Fred, close it out when you're happy...) ------------------------------------------------------- Date: 2001-Jan-26 21:30 By: bquinlan Comment: Not sure how to post this... Here is a mod to liburllib.tex, change the section for urlencode at 146: \begin{funcdesc}{urlencode}{query\optional{, doseq}} Convert a list of 2-tuples or a dictionary to a ``url-encoded'' string, suitable to pass to \function{urlopen()} above as the optional \var{data} argument. This is useful to pass form fields to a \code{POST} request. The resulting string is a series of \code{\var{key}=\var{value}} pairs separated by \character{\&} characters, where both \var{key} and \var{value} are quoted using \function{quote_plus()} above. If the optional parameter \var{doseq} is present and evaluates to true, individual \code{\var{key}=\var{value}} pairs are generated for each element of the sequence. \end{funcdesc} ------------------------------------------------------- Date: 2001-Jan-26 12:01 By: montanaro Comment: I'll take a closer look at this. It's actually not a bug in the CGI scripts. CGI parameters are supposed to be returned in the order they appear in the form. This allows you to, for instance, ask for two lines of addresses in a mailing label form and name both parameters "address" without losing the user's input order. Kind of fragile though, so I don't recommend it as a standard form programming practice. Skip ------------------------------------------------------- Date: 2001-Jan-26 09:56 By: bquinlan Comment: Unfortunately, we must sometimes interoperate with scripts that we did not write. Therefore their (buggy) behavior must be accomodated. I did update the test suite. I'll provide a diff for the .tex file sometime today. ------------------------------------------------------- Date: 2001-Jan-26 07:12 By: fdrake Comment: This sounds to me like those CGI scripts are buggy. Postponed pending documentation and test suite updates. Assigned to Skip since he thought the idea was reasonable & I can't assign to the submittor. ------------------------------------------------------- Date: 2001-Jan-23 22:34 By: montanaro Comment: Seems like a reasonable extension to me. needs a Doc/lib/liburllib.tex update though. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103391&group_id=5470 From noreply@sourceforge.net Mon Jan 29 05:47:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 28 Jan 2001 21:47:06 -0800 Subject: [Patches] [Patch #103476] Two Lib/mailbox.py fixes Message-ID: <E14N79e-000897-00@usw-sf-web1.sourceforge.net> Patch #103476 has been updated. Project: python Category: library Status: Open Submitted by: bwarsaw Assigned to : nobody Summary: Two Lib/mailbox.py fixes ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103476&group_id=5470 From noreply@sourceforge.net Mon Jan 29 05:48:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 28 Jan 2001 21:48:13 -0800 Subject: [Patches] [Patch #103476] Two Lib/mailbox.py fixes Message-ID: <E14N7Aj-00089c-00@usw-sf-web1.sourceforge.net> Patch #103476 has been updated. Project: python Category: library Status: Open Submitted by: bwarsaw Assigned to : twouters Summary: Two Lib/mailbox.py fixes Follow-Ups: Date: 2001-Jan-28 21:48 By: bwarsaw Comment: Assigned to Thomas for sanity checking. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103476&group_id=5470 From noreply@sourceforge.net Mon Jan 29 07:37:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 28 Jan 2001 23:37:47 -0800 Subject: [Patches] [Patch #103476] Two Lib/mailbox.py fixes Message-ID: <E14N8sl-0005SV-00@usw-sf-web3.sourceforge.net> Patch #103476 has been updated. Project: python Category: library Status: Open Submitted by: bwarsaw Assigned to : bwarsaw Summary: Two Lib/mailbox.py fixes Follow-Ups: Date: 2001-Jan-28 23:37 By: twouters Comment: Looks okay to me. I'm not sure if I'm "fine" with the idea of matching from_lines without a preceding blank line, but I also don't want to invest the time to rewrite the module to even allow that, so I can't expect anyone else to :) From-lineiness and the quoting of such differs greatly between mailers :P I *think* this will work for 99.9% of the mailboxes out there (since I know it works for Pine, Mutt, Nutscape and Eudorka (which uses an aditional file for message state, though)) but I'm still a bit wary of forcing people in the last promille to subclass and fiddle with internals themselves. Why not provide a StrictMailbox class that does it for them ? Don't forget Misc/NEWS, Barry. If I was supposed to mark it Accepted, consider it marked Accepted :) ------------------------------------------------------- Date: 2001-Jan-28 21:48 By: bwarsaw Comment: Assigned to Thomas for sanity checking. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103476&group_id=5470 From noreply@sourceforge.net Mon Jan 29 07:53:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 28 Jan 2001 23:53:18 -0800 Subject: [Patches] [Patch #103477] BeOS build scripts, setup.py Message-ID: <E14N97m-0000ii-00@usw-sf-web1.sourceforge.net> Patch #103477 has been updated. Project: python Category: None Status: Open Submitted by: donnc Assigned to : nobody Summary: BeOS build scripts, setup.py ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103477&group_id=5470 From noreply@sourceforge.net Mon Jan 29 07:58:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 28 Jan 2001 23:58:31 -0800 Subject: [Patches] [Patch #103478] Lib/test for BeOS Message-ID: <E14N9Cp-0000kv-00@usw-sf-web1.sourceforge.net> Patch #103478 has been updated. Project: python Category: library Status: Open Submitted by: donnc Assigned to : nobody Summary: Lib/test for BeOS ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103478&group_id=5470 From noreply@sourceforge.net Mon Jan 29 19:29:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 11:29:44 -0800 Subject: [Patches] [Patch #103485] _cursesmodule.c, AIX and NetBSD Message-ID: <E14NJzk-0002OL-00@usw-sf-web3.sourceforge.net> Patch #103485 has been updated. Project: python Category: Modules Status: Open Submitted by: donnc Assigned to : nobody Summary: _cursesmodule.c, AIX and NetBSD ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103485&group_id=5470 From noreply@sourceforge.net Mon Jan 29 20:47:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 12:47:19 -0800 Subject: [Patches] [Patch #103485] _cursesmodule.c, AIX and NetBSD Message-ID: <E14NLCp-00084f-00@usw-sf-web1.sourceforge.net> Patch #103485 has been updated. Project: python Category: Modules Status: Open Submitted by: donnc Assigned to : akuchling Summary: _cursesmodule.c, AIX and NetBSD Follow-Ups: Date: 2001-Jan-29 12:47 By: akuchling Comment: Checked in, with one modification. I removed the use of 'lines' as a variable name, so the #undef lines should now be unnecessary. Donn, please let me know if the current CVS now compiles cleanly for you on AIX and NetBSD. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103485&group_id=5470 From noreply@sourceforge.net Mon Jan 29 20:51:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 12:51:33 -0800 Subject: [Patches] [Patch #101162] a Python/C API testing framework (simple simple) Message-ID: <E14NLGv-00087h-00@usw-sf-web1.sourceforge.net> Patch #101162 has been updated. Project: python Category: Build Status: Open Submitted by: tmick Assigned to : tim_one Summary: a Python/C API testing framework (simple simple) Follow-Ups: Date: 2001-Jan-29 12:51 By: akuchling Comment: Assuming that the _test module doesn't need anything special to compile (and why should it?), the change to setup.py is simple, adding the following line: exts.append( Extension('_test', ['_testmodule.c']) ) ------------------------------------------------------- Date: 2001-Jan-25 05:37 By: nobody Comment: This patch needs to be modified to use setup.py rather then Makefile.pre.in ------------------------------------------------------- Date: 2000-Aug-11 13:37 By: tmick Comment: Here is a proposed patch for a Python/C API testing framework. Simple simple. Basic Overview: - add a _test C extension module that exports test functions beginning with 'test_'; NULL and a TestError exception indicates a test failure and Py_None indicate a test pass - add a test_capi.py test module that calls each of the 'test_' exported functions in the '_test' module - changes to the build system files for Win32 and Unix are includes to build _testmodule.c as a shared extension - new files: Lib/test/test_capi.py, Lib/test/output/test_capi, Modules/_testmodule.c, and PCbuild/_test.dsp ------------------------------------------------------- Date: 2000-Aug-11 13:48 By: tmick Comment: don't use C++ style comments ------------------------------------------------------- Date: 2000-Aug-12 13:46 By: tmick Comment: Skip, You seemed to have some interest in this the couple of times it came up on python-dev. I wonder if you might want to review this. No rush, I don't expect this to go in anytime soon. Unless, of course, people just *have* to have it. <wink> ------------------------------------------------------- Date: 2000-Aug-15 15:23 By: tim_one Comment: Sorry, but there is a rush! Since Python 2.0 is scheduled to have only 1 beta cycle, if this doesn't make it into the beta (< 2 weeks, according to the schedule), it's for 2.1 at best. It would be very good to have a start at this (no matter how simple) in place for 2.0. ------------------------------------------------------- Date: 2000-Aug-16 12:05 By: tmick Comment: re: delaying to 2.1: doesn't bother me much Should it now be "postponed", Tim? ------------------------------------------------------- Date: 2000-Aug-21 19:54 By: montanaro Comment: postponed until 2.1 ------------------------------------------------------- Date: 2000-Nov-27 07:47 By: gvanrossum Comment: Randomly reassigned for review now that 2.1 is open and Skip seems to be too busy to look at this. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101162&group_id=5470 From noreply@sourceforge.net Mon Jan 29 21:33:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 13:33:08 -0800 Subject: [Patches] [Patch #103485] _cursesmodule.c, AIX and NetBSD Message-ID: <E14NLvA-00005C-00@usw-sf-web1.sourceforge.net> Patch #103485 has been updated. Project: python Category: Modules Status: Open Submitted by: donnc Assigned to : akuchling Summary: _cursesmodule.c, AIX and NetBSD Follow-Ups: Date: 2001-Jan-29 13:33 By: donnc Comment: Checked out _cursesmodule.c compiles, links, and loads on NetBSD 1.5 and AIX 4.3.3. ------------------------------------------------------- Date: 2001-Jan-29 12:47 By: akuchling Comment: Checked in, with one modification. I removed the use of 'lines' as a variable name, so the #undef lines should now be unnecessary. Donn, please let me know if the current CVS now compiles cleanly for you on AIX and NetBSD. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103485&group_id=5470 From noreply@sourceforge.net Mon Jan 29 21:42:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 13:42:28 -0800 Subject: [Patches] [Patch #103485] _cursesmodule.c, AIX and NetBSD Message-ID: <E14NM4C-0004hO-00@usw-sf-web2.sourceforge.net> Patch #103485 has been updated. Project: python Category: Modules Status: Closed Submitted by: donnc Assigned to : akuchling Summary: _cursesmodule.c, AIX and NetBSD Follow-Ups: Date: 2001-Jan-29 13:42 By: akuchling Comment: Marking as closed. ------------------------------------------------------- Date: 2001-Jan-29 13:33 By: donnc Comment: Checked out _cursesmodule.c compiles, links, and loads on NetBSD 1.5 and AIX 4.3.3. ------------------------------------------------------- Date: 2001-Jan-29 12:47 By: akuchling Comment: Checked in, with one modification. I removed the use of 'lines' as a variable name, so the #undef lines should now be unnecessary. Donn, please let me know if the current CVS now compiles cleanly for you on AIX and NetBSD. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103485&group_id=5470 From noreply@sourceforge.net Mon Jan 29 22:19:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 14:19:21 -0800 Subject: [Patches] [Patch #103487] BeOS build scripts, setup.py Message-ID: <E14NMdt-0000cC-00@usw-sf-web1.sourceforge.net> Patch #103487 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : nobody Summary: BeOS build scripts, setup.py ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103487&group_id=5470 From noreply@sourceforge.net Mon Jan 29 22:23:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 14:23:56 -0800 Subject: [Patches] [Patch #103477] BeOS build scripts, setup.py Message-ID: <E14NMiK-0000f5-00@usw-sf-web1.sourceforge.net> Patch #103477 has been updated. Project: python Category: None Status: Open Submitted by: donnc Assigned to : nobody Summary: BeOS build scripts, setup.py Follow-Ups: Date: 2001-Jan-29 14:23 By: donnc Comment: Please close this one and use 103487 instead, which has a couple of bug fixes discovered when I built it on AIX. (Tried "upload revised patch" here, couldn't make it work.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103477&group_id=5470 From noreply@sourceforge.net Mon Jan 29 22:26:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 14:26:08 -0800 Subject: [Patches] [Patch #103477] BeOS build scripts, setup.py Message-ID: <E14NMkS-00053t-00@usw-sf-web2.sourceforge.net> Patch #103477 has been updated. Project: python Category: None Status: Closed Submitted by: donnc Assigned to : nobody Summary: BeOS build scripts, setup.py Follow-Ups: Date: 2001-Jan-29 14:23 By: donnc Comment: Please close this one and use 103487 instead, which has a couple of bug fixes discovered when I built it on AIX. (Tried "upload revised patch" here, couldn't make it work.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103477&group_id=5470 From noreply@sourceforge.net Mon Jan 29 23:47:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 15:47:30 -0800 Subject: [Patches] [Patch #103441] an inline syntax for function attributes Message-ID: <E14NO1C-0001SM-00@usw-sf-web1.sourceforge.net> Patch #103441 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: mwh Assigned to : gvanrossum Summary: an inline syntax for function attributes Follow-Ups: Date: 2001-Jan-29 15:47 By: gvanrossum Comment: Cute, but I think this s too much innovation. :-) Let's stick to attribute assignment. I'll reject the patch. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103441&group_id=5470 From noreply@sourceforge.net Mon Jan 29 23:51:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 15:51:25 -0800 Subject: [Patches] [Patch #103457] Fixed shadowing problem with cmpfunc in Mac OS X Message-ID: <E14NO4z-0001Uk-00@usw-sf-web1.sourceforge.net> Patch #103457 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: bquinlan Assigned to : gvanrossum Summary: Fixed shadowing problem with cmpfunc in Mac OS X Follow-Ups: Date: 2001-Jan-29 15:51 By: gvanrossum Comment: It's simple: cmpfunc is already a typedef, so that local was unfortunately named. I've fixed it. (Note; it's classobject.c, not complexobject.c! And please use diff -c, not ndiff to submit diffs next time.) ------------------------------------------------------- Date: 2001-Jan-27 13:10 By: bquinlan Comment: See bug #129827 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103457&group_id=5470 From noreply@sourceforge.net Mon Jan 29 23:52:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 15:52:01 -0800 Subject: [Patches] [Patch #103471] xml pretty-printing in minidom Message-ID: <E14NO5Z-0001Ux-00@usw-sf-web1.sourceforge.net> Patch #103471 has been updated. Project: python Category: library Status: Open Submitted by: isk Assigned to : loewis Summary: xml pretty-printing in minidom Follow-Ups: Date: 2001-Jan-29 15:52 By: gvanrossum Comment: Martin, are you taking care of minidom these days? If not, who is? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103471&group_id=5470 From noreply@sourceforge.net Mon Jan 29 23:53:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 15:53:17 -0800 Subject: [Patches] [Patch #103473] Cookie.py: Allow values containing '=' Message-ID: <E14NO6n-0001Vk-00@usw-sf-web1.sourceforge.net> Patch #103473 has been updated. Project: python Category: library Status: Open Submitted by: dougfort Assigned to : akuchling Summary: Cookie.py: Allow values containing '=' Follow-Ups: Date: 2001-Jan-29 15:53 By: gvanrossum Comment: Andrew, can you check this? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103473&group_id=5470 From noreply@sourceforge.net Mon Jan 29 23:53:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 15:53:32 -0800 Subject: [Patches] [Patch #103495] case sensitive import for case insensitive FileSystem Message-ID: <E14NO72-0004ee-00@usw-sf-web3.sourceforge.net> Patch #103495 has been updated. Project: python Category: core (C code) Status: Open Submitted by: sdm7g Assigned to : nobody Summary: case sensitive import for case insensitive FileSystem ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103495&group_id=5470 From noreply@sourceforge.net Mon Jan 29 23:53:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 15:53:38 -0800 Subject: [Patches] [Patch #103487] BeOS build scripts, setup.py Message-ID: <E14NO78-0001W1-00@usw-sf-web1.sourceforge.net> Patch #103487 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : akuchling Summary: BeOS build scripts, setup.py ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103487&group_id=5470 From noreply@sourceforge.net Mon Jan 29 23:53:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 15:53:48 -0800 Subject: [Patches] [Patch #103487] BeOS build scripts, setup.py Message-ID: <E14NO7I-0001W9-00@usw-sf-web1.sourceforge.net> Patch #103487 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : akuchling Summary: BeOS build scripts, setup.py ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103487&group_id=5470 From noreply@sourceforge.net Mon Jan 29 23:54:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 15:54:49 -0800 Subject: [Patches] [Patch #103478] Lib/test for BeOS Message-ID: <E14NO8H-0001We-00@usw-sf-web1.sourceforge.net> Patch #103478 has been updated. Project: python Category: library Status: Open Submitted by: donnc Assigned to : moshez Summary: Lib/test for BeOS Follow-Ups: Date: 2001-Jan-29 15:54 By: gvanrossum Comment: Randomly assigned to Moshe. (Nobody here has BeOS, so your only task is to ensure that thsi doesn't break on Linux.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103478&group_id=5470 From noreply@sourceforge.net Tue Jan 30 00:02:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 16:02:54 -0800 Subject: [Patches] [Patch #103457] Fixed shadowing problem with cmpfunc in Mac OS X Message-ID: <E14NOG6-0005qb-00@usw-sf-web2.sourceforge.net> Patch #103457 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: bquinlan Assigned to : gvanrossum Summary: Fixed shadowing problem with cmpfunc in Mac OS X Follow-Ups: Date: 2001-Jan-29 16:02 By: nobody Comment: OK, thanks. I would have thought giving a variable the same name as a typedef with global scope would have masked the typedef, not resulted in a syntax error (with a cryptic error message). I guess old versions of C didn't allow this? That is why I assumed that it was a preprocessor directive... ------------------------------------------------------- Date: 2001-Jan-29 15:51 By: gvanrossum Comment: It's simple: cmpfunc is already a typedef, so that local was unfortunately named. I've fixed it. (Note; it's classobject.c, not complexobject.c! And please use diff -c, not ndiff to submit diffs next time.) ------------------------------------------------------- Date: 2001-Jan-27 13:10 By: bquinlan Comment: See bug #129827 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103457&group_id=5470 From noreply@sourceforge.net Tue Jan 30 03:22:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 19:22:34 -0800 Subject: [Patches] [Patch #103395] Guido changed his mind! Quickly, add 'if key in dict'! Message-ID: <E14NRNK-0007KZ-00@usw-sf-web2.sourceforge.net> Patch #103395 has been updated. Project: python Category: core (C code) Status: Postponed Submitted by: twouters Assigned to : tim_one Summary: Guido changed his mind! Quickly, add 'if key in dict'! Follow-Ups: Date: 2001-Jan-29 19:22 By: tim_one Comment: Changed to Postponed since the issues blossomed, and there's no hope of resolving them before 2.1a2 (hence also before 2.2). Reassigned to me. ------------------------------------------------------- Date: 2001-Jan-27 23:18 By: tim_one Comment: Reviewed the code and tried it out. Boffo! It's Accepted as far as I'm concerned. Cute: the Cygwin "patch" program core dumped consistently when trying to apply the NEWS patch, so I didn't test that part <wink>. Assigned to Fred for final disposition, since Thomas noted doc questions in his comments. I'll add that, since the docs already explain has_key, nothing good can come of trying to explain "in" via different words; would be shorter and better to just say x in dict == dict.has_key(x) x not in dict == not dict.has_key(x) everywhere it comes up. ------------------------------------------------------- Date: 2001-Jan-27 21:53 By: tim_one Comment: Assigned to me while Guido is sleeping so he doesn't get a chance to change his mind. ------------------------------------------------------- Date: 2001-Jan-27 17:26 By: twouters Comment: Newer patch, avoids Misc/NEWS conflict, fixes oversight in dict_contains. ------------------------------------------------------- Date: 2001-Jan-24 01:05 By: tim_one Comment: There must be something in the air, besides email delays. I'll take your word for it that Guido changed his mind, but I was about to say +1 anyway! Now all we have to do is trick xreadlines into iterating over dicts <wink>. ------------------------------------------------------- Date: 2001-Jan-23 23:39 By: twouters Comment: Added testcases for dict and UserDict. ------------------------------------------------------- Date: 2001-Jan-23 23:20 By: twouters Comment: Add some docs (not guarded by a 'new in 2.1' statement, I don't know how to do that), NEWS item and support in UserDict.UserDict. Docs of has_key should probably also mention that 'if key in dict' does the same, but I'm not sure how to say that's new in Python 2.1. ------------------------------------------------------- Date: 2001-Jan-23 22:57 By: twouters Comment: There yah go, Guido. Does my being awakened by my loud and malicious partner (who needs to head to her office 4 hours before me) earn me yet another free and legally useless 2.1 alpha ? :-) Note: it's missing docs. Will add then once I figure out where to add them. Also haven't updated the std-lib yet, will do that next. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103395&group_id=5470 From noreply@sourceforge.net Tue Jan 30 03:23:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 19:23:37 -0800 Subject: [Patches] [Patch #103495] case sensitive import for case insensitive FileSystem Message-ID: <E14NROL-0007Kt-00@usw-sf-web2.sourceforge.net> Patch #103495 has been updated. Project: python Category: core (C code) Status: Open Submitted by: sdm7g Assigned to : gvanrossum Summary: case sensitive import for case insensitive FileSystem ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103495&group_id=5470 From noreply@sourceforge.net Tue Jan 30 03:37:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 19:37:11 -0800 Subject: [Patches] [Patch #103441] an inline syntax for function attributes Message-ID: <E14NRbT-0007RH-00@usw-sf-web2.sourceforge.net> Patch #103441 has been updated. Project: python Category: core (C code) Status: Rejected Submitted by: mwh Assigned to : nobody Summary: an inline syntax for function attributes Follow-Ups: Date: 2001-Jan-29 19:37 By: tim_one Comment: Guido said "rejected" but didn't. Fiddled fields accordingly. ------------------------------------------------------- Date: 2001-Jan-29 15:47 By: gvanrossum Comment: Cute, but I think this s too much innovation. :-) Let's stick to attribute assignment. I'll reject the patch. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103441&group_id=5470 From noreply@sourceforge.net Tue Jan 30 04:27:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 20:27:39 -0800 Subject: [Patches] [Patch #103495] case sensitive import for case insensitive FileSystem Message-ID: <E14NSOJ-0006jV-00@usw-sf-web3.sourceforge.net> Patch #103495 has been updated. Project: python Category: core (C code) Status: Open Submitted by: sdm7g Assigned to : gvanrossum Summary: case sensitive import for case insensitive FileSystem Follow-Ups: Date: 2001-Jan-29 20:27 By: sdm7g Comment: Oops! The previous patch crashes if the path is empty, which is the case for the current directory. Added a line to check for that and use "." instead on diropen. -- Steve M. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103495&group_id=5470 From noreply@sourceforge.net Tue Jan 30 04:30:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 20:30:19 -0800 Subject: [Patches] [Patch #103495] case sensitive import for case insensitive FileSystem Message-ID: <E14NSQt-0006kh-00@usw-sf-web3.sourceforge.net> Patch #103495 has been updated. Project: python Category: core (C code) Status: Open Submitted by: sdm7g Assigned to : gvanrossum Summary: case sensitive import for case insensitive FileSystem Follow-Ups: Date: 2001-Jan-29 20:30 By: sdm7g Comment: Oops! The previous patch crashes if the path is empty, which is the case for the current directory. Added a line to check for that and use "." instead on diropen. -- Steve M. ------------------------------------------------------- Date: 2001-Jan-29 20:27 By: sdm7g Comment: Oops! The previous patch crashes if the path is empty, which is the case for the current directory. Added a line to check for that and use "." instead on diropen. -- Steve M. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103495&group_id=5470 From noreply@sourceforge.net Tue Jan 30 06:29:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 22:29:24 -0800 Subject: [Patches] [Patch #103478] Lib/test for BeOS Message-ID: <E14NUI8-0007Zv-00@usw-sf-web3.sourceforge.net> Patch #103478 has been updated. Project: python Category: library Status: Accepted Submitted by: donnc Assigned to : gvanrossum Summary: Lib/test for BeOS Follow-Ups: Date: 2001-Jan-29 22:29 By: moshez Comment: I've never seen BeOS at a distance <wink>, but it doesn't break my Debian GNU/Linux (sid) build. Assigned to Guido, marked accepted. Guido, reassign to me if you want me to actually check it in. ------------------------------------------------------- Date: 2001-Jan-29 15:54 By: gvanrossum Comment: Randomly assigned to Moshe. (Nobody here has BeOS, so your only task is to ensure that thsi doesn't break on Linux.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103478&group_id=5470 From noreply@sourceforge.net Tue Jan 30 15:10:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 07:10:20 -0800 Subject: [Patches] [Patch #103478] Lib/test for BeOS Message-ID: <E14NcQG-0001Ss-00@usw-sf-web1.sourceforge.net> Patch #103478 has been updated. Project: python Category: library Status: Accepted Submitted by: donnc Assigned to : moshez Summary: Lib/test for BeOS Follow-Ups: Date: 2001-Jan-30 07:10 By: gvanrossum Comment: OK, check it in already! ------------------------------------------------------- Date: 2001-Jan-29 22:29 By: moshez Comment: I've never seen BeOS at a distance <wink>, but it doesn't break my Debian GNU/Linux (sid) build. Assigned to Guido, marked accepted. Guido, reassign to me if you want me to actually check it in. ------------------------------------------------------- Date: 2001-Jan-29 15:54 By: gvanrossum Comment: Randomly assigned to Moshe. (Nobody here has BeOS, so your only task is to ensure that thsi doesn't break on Linux.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103478&group_id=5470 From noreply@sourceforge.net Tue Jan 30 15:34:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 07:34:02 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14NcnC-0003C8-00@usw-sf-web3.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : gvanrossum Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-30 07:34 By: gvanrossum Comment: Grabbing this for code review (finally!) ------------------------------------------------------- Date: 2001-Jan-22 14:01 By: fdrake Comment: Removed the .clear() method from reference objects. Made proxy objects unhashable -- the semantics of hashing something that can mutate in fundamental ways is pretty painful; just don't use these as dictionary keys! Added strong warnings to the documentation that proxy semantics may change a bit before the final release that the weak dictionaries are unclear -- additional feedback is requested. These are not thread-safe. ------------------------------------------------------- Date: 2001-Jan-20 09:42 By: gvanrossum Comment: I think callbacks are needed to implement various forms of weak dicts: when the object is deleted, whatever's in the weak dict for it should be deleted as well. Even though we may not provide weak dicts in 2.1a1, we should still support writing them using what we *do* provide. IMHO (I still haven't had the time to read the PEP or Fred's code. :-( ) ------------------------------------------------------- Date: 2001-Jan-20 09:12 By: nascheme Comment: Why do weak references need callbacks? I see nothing in the PEP to justify this feature. If there is no good reason for them, I propose that the feature be removed for 2.1. Allowing callbacks may make it harder to implement weak references more efficiently later. ------------------------------------------------------- Date: 2001-Jan-18 16:03 By: loewis Comment: The patch looks ok in general, pending resolution of the issues on the PEP itself. Some nits: Integration with GC is still fuzzy. If an instance is GC collected and had a weak ref to it and the weak ref had a callback and the callback choses to resurrect the object, semantics is unclear. This is equivalent to the object having an __del__; the GC would normally *not* collect such objects, but put them into gc.garbage. Proposed resolution: it is a fatal error to resurrect an object in a weakref callback. Hashing: it appears that the hash of a weakref can change when the underlying object goes away. If the weakref is used as key in a dictionary, it appears to be impossible to get the key out of the dictionary after the underlying object is gone. Proposed resolution: a proxy weak ref should cache the hash of the underlying object after its hash function was called for the first time. Comparing: why is the return value of tp_compare -1 when try_3way_compare expects -2 on error? Shouldn't there be some exception set when the underlying object goes away? ------------------------------------------------------- Date: 2001-Jan-17 13:53 By: fdrake Comment: Ok, I tihnk this is it! http://starship.python.net/crew/fdrake/patches/weakref.patch-5 This patch fixes the compilation problems from the previoous patch related to the introduction of rich comparisons, and makes a change in the way new objects are initialized by PyObject_New() and PyObject_NEW() (and all their friends!) -- those functions now know to initialize the weak reference list to NULL for objects which support weak references. Without this change, more places in the code (especially extension modules) need to know more about initialization of weakly-referencable objects. For instance, the "cPickle" and "new" modules both can create instances without calling the code in classobject.c (using PyObject_New()), causing core dumps when such instances are deallocated if the weak-reference list for instances was not properly initialized. Since these modules (properly) tried to avoid call PyInstance_New(), core dumps ensued and the world fell apart. By moving the initialization of the weak reference list into the core object allocators, this problem is averted and extension code to construct new weakly referencable types is simplified. The documentation still needs work, and there are a few new entries for the Python/C API manual as well. A new constructor for instances, PyInstance_NewRaw(), will be added in a separate patch. ------------------------------------------------------- Date: 2001-Jan-17 11:58 By: nascheme Comment: The magic test is: ./python Lib/test/regrtest.py test_weakref test_new Try adding this patch: --- Modules/newmodule.c 2000/11/13 20:29:20 2.29 +++ Modules/newmodule.c 2001/01/17 19:55:46 @@ -24,6 +24,7 @@ Py_INCREF(dict); inst->in_class = (PyClassObject *)klass; inst->in_dict = dict; + inst->in_weakreflist = NULL; PyObject_GC_Init(inst); return (PyObject *)inst; } ------------------------------------------------------- Date: 2001-Jan-17 08:04 By: fdrake Comment: New version of the patch that's still broken but doesn't conflict with the rich comparisons changes: http://starship.python.net/crew/fdrake/patches/weakref.patch-4 ------------------------------------------------------- Date: 2001-Jan-16 21:35 By: fdrake Comment: Added a new (but broken!) version of the patch that fixes WeakDictionary.get() but doesn't interact properly with GC (appearantly) -- not usable as is: http://starship.python.net/crew/fdrake/patches/weakref.patch-3 Neil made the mistake of volunteering to look at the current problem, so assigning to him. (Thanks!) ------------------------------------------------------- Date: 2001-Jan-16 19:39 By: tim_one Comment: Just mentioning a general scenario in which weak keys are the bee's knees: sometimes you want to add attributes to objects dynamically, in ways the original class author(s -- may cut across many classes! even non-instance objects; or objects from extension modules that don't support setattr) never anticipated. Like maybe a German translation of the object's docstrings; or a list of JPEG contents referenced by a URLish object; or a table of usage statistics on methods and functions; etc. Then it's natural to use the conceptual attr name as the name of a dict instead, and write attr[object] = whatever instead of object.attr = whatever There's no point keeping the "whatever" around when the object goes away, but a regular dict makes the object and its "whatever" immortal. A dict with weak keys is exactly on-target. ------------------------------------------------------- Date: 2001-Jan-16 19:14 By: fdrake Comment: I'm not entirely sure why one would want weak keys rather than weak values, but I suspect it has to do with expectations of how the dict will be used in applications. I don't think it would be hard to support both flavors of dictionaries using the primitive reference objects. The constructor does not check that all incoming values are weak because that isn't required. It uses self.update() rather than self.data.update() to perform the inclusion, so any mapping that supports .keys() and .__getitem__() is sufficient. Some additional checking could be done to make sure that all added entries can be created before inserting any of them, offering more atomicity. .get() will be fixed in the next version of the patch; thanks! I've added GC support, but don't have it working quite right. I'm trying to isolate the failure now. ------------------------------------------------------- Date: 2001-Jan-12 14:36 By: loewis Comment: The weak dictionary data type needs more clarification in documentation and implementation. In java.util.WeakHashMap, they keys are weak, not the values (i.e. once the key is forgotten, the entry is cleared). In http://www.handshake.de/~dieter/weakdict.html, the values are weak, but it raises KeyErrors for entries that are collected. The initializer of a weak dict does not check the invariant (all values are weak). get() of a weakdict does not support an optional second parameter. weakref and friends need to participate in garbage collection, as the reference to the callback can create a cycle. ------------------------------------------------------- Date: 2001-Jan-12 11:27 By: fdrake Comment: Updated patch to also support proxy semantics using the same invalidation machinery as the basic weak reference type. The additional code is *heavily* borrowed from Neil Schemenauer. ------------------------------------------------------- Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Tue Jan 30 18:40:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 10:40:48 -0800 Subject: [Patches] [Patch #103478] Lib/test for BeOS Message-ID: <E14Nfhw-0005je-00@usw-sf-web2.sourceforge.net> Patch #103478 has been updated. Project: python Category: library Status: Accepted Submitted by: donnc Assigned to : moshez Summary: Lib/test for BeOS Follow-Ups: Date: 2001-Jan-30 10:40 By: moshez Comment: Checked in as test_fork1 1.8, test_popen 1.5 Or should I say, "checked it in already?" ------------------------------------------------------- Date: 2001-Jan-30 07:10 By: gvanrossum Comment: OK, check it in already! ------------------------------------------------------- Date: 2001-Jan-29 22:29 By: moshez Comment: I've never seen BeOS at a distance <wink>, but it doesn't break my Debian GNU/Linux (sid) build. Assigned to Guido, marked accepted. Guido, reassign to me if you want me to actually check it in. ------------------------------------------------------- Date: 2001-Jan-29 15:54 By: gvanrossum Comment: Randomly assigned to Moshe. (Nobody here has BeOS, so your only task is to ensure that thsi doesn't break on Linux.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103478&group_id=5470 From noreply@sourceforge.net Tue Jan 30 18:41:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 10:41:27 -0800 Subject: [Patches] [Patch #103478] Lib/test for BeOS Message-ID: <E14NfiZ-0005k3-00@usw-sf-web2.sourceforge.net> Patch #103478 has been updated. Project: python Category: library Status: Closed Submitted by: donnc Assigned to : moshez Summary: Lib/test for BeOS Follow-Ups: Date: 2001-Jan-30 10:40 By: moshez Comment: Checked in as test_fork1 1.8, test_popen 1.5 Or should I say, "checked it in already?" ------------------------------------------------------- Date: 2001-Jan-30 07:10 By: gvanrossum Comment: OK, check it in already! ------------------------------------------------------- Date: 2001-Jan-29 22:29 By: moshez Comment: I've never seen BeOS at a distance <wink>, but it doesn't break my Debian GNU/Linux (sid) build. Assigned to Guido, marked accepted. Guido, reassign to me if you want me to actually check it in. ------------------------------------------------------- Date: 2001-Jan-29 15:54 By: gvanrossum Comment: Randomly assigned to Moshe. (Nobody here has BeOS, so your only task is to ensure that thsi doesn't break on Linux.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103478&group_id=5470 From noreply@sourceforge.net Tue Jan 30 18:43:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 10:43:57 -0800 Subject: [Patches] [Patch #103511] robotparser.py: fix for top-level web names Message-ID: <E14Nfkz-0003sX-00@usw-sf-web1.sourceforge.net> Patch #103511 has been updated. Project: python Category: library Status: Open Submitted by: dcohen Assigned to : nobody Summary: robotparser.py: fix for top-level web names ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103511&group_id=5470 From noreply@sourceforge.net Tue Jan 30 18:59:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 10:59:33 -0800 Subject: [Patches] [Patch #103512] symtable['.noopt'] = None, should be = 0 Message-ID: <E14Ng05-00042p-00@usw-sf-web1.sourceforge.net> Patch #103512 has been updated. Project: python Category: core (C code) Status: Open Submitted by: donnc Assigned to : nobody Summary: symtable['.noopt'] = None, should be = 0 ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103512&group_id=5470 From noreply@sourceforge.net Tue Jan 30 20:00:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 12:00:48 -0800 Subject: [Patches] [Patch #103513] Canvas.py fixes Message-ID: <E14NgxM-0004mZ-00@usw-sf-web1.sourceforge.net> Patch #103513 has been updated. Project: python Category: Tkinter Status: Open Submitted by: mfx Assigned to : nobody Summary: Canvas.py fixes ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103513&group_id=5470 From noreply@sourceforge.net Tue Jan 30 20:21:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 12:21:45 -0800 Subject: [Patches] [Patch #103514] small speedup in Tkinter.Misc._bind Message-ID: <E14NhHd-00050G-00@usw-sf-web1.sourceforge.net> Patch #103514 has been updated. Project: python Category: Tkinter Status: Open Submitted by: mfx Assigned to : nobody Summary: small speedup in Tkinter.Misc._bind ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103514&group_id=5470 From noreply@sourceforge.net Tue Jan 30 20:46:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 12:46:07 -0800 Subject: [Patches] [Patch #103516] zipfile.py: use hex constants for magic numbers Message-ID: <E14NhfD-0005ls-00@usw-sf-web3.sourceforge.net> Patch #103516 has been updated. Project: python Category: library Status: Open Submitted by: mfx Assigned to : nobody Summary: zipfile.py: use hex constants for magic numbers ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103516&group_id=5470 From noreply@sourceforge.net Tue Jan 30 21:01:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 13:01:38 -0800 Subject: [Patches] [Patch #103517] ftplib.py: provide a default blocksize arg in storbinary Message-ID: <E14NhuE-0005tE-00@usw-sf-web3.sourceforge.net> Patch #103517 has been updated. Project: python Category: library Status: Open Submitted by: mfx Assigned to : nobody Summary: ftplib.py: provide a default blocksize arg in storbinary ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103517&group_id=5470 From noreply@sourceforge.net Wed Jan 31 02:45:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 18:45:29 -0800 Subject: [Patches] [Patch #103512] symtable['.noopt'] = None, should be = 0 Message-ID: <E14NnGz-0000sD-00@usw-sf-web1.sourceforge.net> Patch #103512 has been updated. Project: python Category: core (C code) Status: Open Submitted by: donnc Assigned to : jhylton Summary: symtable['.noopt'] = None, should be = 0 Follow-Ups: Date: 2001-Jan-30 18:45 By: tim_one Comment: Assigned to Jeremy; sounds right to me! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103512&group_id=5470 From noreply@sourceforge.net Wed Jan 31 06:39:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 22:39:48 -0800 Subject: [Patches] [Patch #103511] robotparser.py: fix for top-level web names Message-ID: <E14Nqvk-0003Jj-00@usw-sf-web1.sourceforge.net> Patch #103511 has been updated. Project: python Category: library Status: Open Submitted by: dcohen Assigned to : montanaro Summary: robotparser.py: fix for top-level web names Follow-Ups: Date: 2001-Jan-30 22:39 By: montanaro Comment: Assigned to me. Looks pretty straightforward (so he says)... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103511&group_id=5470 From noreply@sourceforge.net Wed Jan 31 07:51:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 23:51:00 -0800 Subject: [Patches] [Patch #103523] mpz module doesn't build under cygwni Message-ID: <E14Ns2e-00039D-00@usw-sf-web2.sourceforge.net> Patch #103523 has been updated. Project: python Category: Modules Status: Open Submitted by: nobody Assigned to : nobody Summary: mpz module doesn't build under cygwni ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103523&group_id=5470 From noreply@sourceforge.net Wed Jan 31 08:24:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jan 2001 00:24:21 -0800 Subject: [Patches] [Patch #103523] mpz module doesn't build under cygwni Message-ID: <E14NsYv-0002Qm-00@usw-sf-web3.sourceforge.net> Patch #103523 has been updated. Project: python Category: Modules Status: Open Submitted by: nobody Assigned to : akuchling Summary: mpz module doesn't build under cygwni Follow-Ups: Date: 2001-Jan-31 00:24 By: tim_one Comment: Assigned to Andrew, because I'm hallucinating he may know more about mpz than the rest of us. Andrew, if you approve of this change, please make it, but on *all* platforms (i.e., do what the patch is getting at but don't apply the patch as-is -- there's no need to clutter the code with #ifdefs here). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103523&group_id=5470 From noreply@sourceforge.net Wed Jan 31 22:14:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jan 2001 14:14:05 -0800 Subject: [Patches] [Patch #103476] Two Lib/mailbox.py fixes Message-ID: <E14O5Vt-00085m-00@usw-sf-web1.sourceforge.net> Patch #103476 has been updated. Project: python Category: library Status: Closed Submitted by: bwarsaw Assigned to : bwarsaw Summary: Two Lib/mailbox.py fixes Follow-Ups: Date: 2001-Jan-31 14:14 By: bwarsaw Comment: Applying for Python 2.1a2. ------------------------------------------------------- Date: 2001-Jan-31 13:58 By: bwarsaw Comment: I changed my mind on this. For better backwards compatibility, I'm going to leave UnixMailbox doing the strict checking, and add a PortableUnixMailbox class which does the more general From_ line check. ------------------------------------------------------- Date: 2001-Jan-31 13:27 By: bwarsaw Comment: Good idea about the StrictUnixMailbox subclass. I'll add this, update NEWS and check it in. ------------------------------------------------------- Date: 2001-Jan-28 23:37 By: twouters Comment: Looks okay to me. I'm not sure if I'm "fine" with the idea of matching from_lines without a preceding blank line, but I also don't want to invest the time to rewrite the module to even allow that, so I can't expect anyone else to :) From-lineiness and the quoting of such differs greatly between mailers :P I *think* this will work for 99.9% of the mailboxes out there (since I know it works for Pine, Mutt, Nutscape and Eudorka (which uses an aditional file for message state, though)) but I'm still a bit wary of forcing people in the last promille to subclass and fiddle with internals themselves. Why not provide a StrictMailbox class that does it for them ? Don't forget Misc/NEWS, Barry. If I was supposed to mark it Accepted, consider it marked Accepted :) ------------------------------------------------------- Date: 2001-Jan-28 21:48 By: bwarsaw Comment: Assigned to Thomas for sanity checking. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103476&group_id=5470 From noreply@sourceforge.net Wed Jan 31 21:58:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jan 2001 13:58:51 -0800 Subject: [Patches] [Patch #103476] Two Lib/mailbox.py fixes Message-ID: <E14O5H9-0007zD-00@usw-sf-web1.sourceforge.net> Patch #103476 has been updated. Project: python Category: library Status: Accepted Submitted by: bwarsaw Assigned to : bwarsaw Summary: Two Lib/mailbox.py fixes Follow-Ups: Date: 2001-Jan-31 13:58 By: bwarsaw Comment: I changed my mind on this. For better backwards compatibility, I'm going to leave UnixMailbox doing the strict checking, and add a PortableUnixMailbox class which does the more general From_ line check. ------------------------------------------------------- Date: 2001-Jan-31 13:27 By: bwarsaw Comment: Good idea about the StrictUnixMailbox subclass. I'll add this, update NEWS and check it in. ------------------------------------------------------- Date: 2001-Jan-28 23:37 By: twouters Comment: Looks okay to me. I'm not sure if I'm "fine" with the idea of matching from_lines without a preceding blank line, but I also don't want to invest the time to rewrite the module to even allow that, so I can't expect anyone else to :) From-lineiness and the quoting of such differs greatly between mailers :P I *think* this will work for 99.9% of the mailboxes out there (since I know it works for Pine, Mutt, Nutscape and Eudorka (which uses an aditional file for message state, though)) but I'm still a bit wary of forcing people in the last promille to subclass and fiddle with internals themselves. Why not provide a StrictMailbox class that does it for them ? Don't forget Misc/NEWS, Barry. If I was supposed to mark it Accepted, consider it marked Accepted :) ------------------------------------------------------- Date: 2001-Jan-28 21:48 By: bwarsaw Comment: Assigned to Thomas for sanity checking. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103476&group_id=5470 From noreply@sourceforge.net Wed Jan 31 21:27:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jan 2001 13:27:16 -0800 Subject: [Patches] [Patch #103476] Two Lib/mailbox.py fixes Message-ID: <E14O4ma-0000ue-00@usw-sf-web2.sourceforge.net> Patch #103476 has been updated. Project: python Category: library Status: Accepted Submitted by: bwarsaw Assigned to : bwarsaw Summary: Two Lib/mailbox.py fixes Follow-Ups: Date: 2001-Jan-31 13:27 By: bwarsaw Comment: Good idea about the StrictUnixMailbox subclass. I'll add this, update NEWS and check it in. ------------------------------------------------------- Date: 2001-Jan-28 23:37 By: twouters Comment: Looks okay to me. I'm not sure if I'm "fine" with the idea of matching from_lines without a preceding blank line, but I also don't want to invest the time to rewrite the module to even allow that, so I can't expect anyone else to :) From-lineiness and the quoting of such differs greatly between mailers :P I *think* this will work for 99.9% of the mailboxes out there (since I know it works for Pine, Mutt, Nutscape and Eudorka (which uses an aditional file for message state, though)) but I'm still a bit wary of forcing people in the last promille to subclass and fiddle with internals themselves. Why not provide a StrictMailbox class that does it for them ? Don't forget Misc/NEWS, Barry. If I was supposed to mark it Accepted, consider it marked Accepted :) ------------------------------------------------------- Date: 2001-Jan-28 21:48 By: bwarsaw Comment: Assigned to Thomas for sanity checking. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103476&group_id=5470 From noreply@sourceforge.net Wed Jan 31 21:01:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jan 2001 13:01:28 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: <E14O4Nc-0007gt-00@usw-sf-web1.sourceforge.net> Patch #103203 has been updated. Project: python Category: core (C code) Status: Open Submitted by: fdrake Assigned to : tim_one Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-31 13:01 By: fdrake Comment: - The .islive() method has been removed. - .get() has been replaced with calling the reference. - Reference and proxy objects which have no callbacks are "shared"; new objects are not created for every requestor in this case. - The new() function has been renamed ref(), since there's no requirement that it return a new reference or proxy object. - Callback functions no longer receive the objects that are about to be finalized; the weak reference object or proxy that fired the callback is passed instead. Proxy objects still need support for rich comparisons. (PEP 205 has also been updated.) ------------------------------------------------------- Date: 2001-Jan-30 07:34 By: gvanrossum Comment: Grabbing this for code review (finally!) ------------------------------------------------------- Date: 2001-Jan-22 14:01 By: fdrake Comment: Removed the .clear() method from reference objects. Made proxy objects unhashable -- the semantics of hashing something that can mutate in fundamental ways is pretty painful; just don't use these as dictionary keys! Added strong warnings to the documentation that proxy semantics may change a bit before the final release that the weak dictionaries are unclear -- additional feedback is requested. These are not thread-safe. ------------------------------------------------------- Date: 2001-Jan-20 09:42 By: gvanrossum Comment: I think callbacks are needed to implement various forms of weak dicts: when the object is deleted, whatever's in the weak dict for it should be deleted as well. Even though we may not provide weak dicts in 2.1a1, we should still support writing them using what we *do* provide. IMHO (I still haven't had the time to read the PEP or Fred's code. :-( ) ------------------------------------------------------- Date: 2001-Jan-20 09:12 By: nascheme Comment: Why do weak references need callbacks? I see nothing in the PEP to justify this feature. If there is no good reason for them, I propose that the feature be removed for 2.1. Allowing callbacks may make it harder to implement weak references more efficiently later. ------------------------------------------------------- Date: 2001-Jan-18 16:03 By: loewis Comment: The patch looks ok in general, pending resolution of the issues on the PEP itself. Some nits: Integration with GC is still fuzzy. If an instance is GC collected and had a weak ref to it and the weak ref had a callback and the callback choses to resurrect the object, semantics is unclear. This is equivalent to the object having an __del__; the GC would normally *not* collect such objects, but put them into gc.garbage. Proposed resolution: it is a fatal error to resurrect an object in a weakref callback. Hashing: it appears that the hash of a weakref can change when the underlying object goes away. If the weakref is used as key in a dictionary, it appears to be impossible to get the key out of the dictionary after the underlying object is gone. Proposed resolution: a proxy weak ref should cache the hash of the underlying object after its hash function was called for the first time. Comparing: why is the return value of tp_compare -1 when try_3way_compare expects -2 on error? Shouldn't there be some exception set when the underlying object goes away? ------------------------------------------------------- Date: 2001-Jan-17 13:53 By: fdrake Comment: Ok, I tihnk this is it! http://starship.python.net/crew/fdrake/patches/weakref.patch-5 This patch fixes the compilation problems from the previoous patch related to the introduction of rich comparisons, and makes a change in the way new objects are initialized by PyObject_New() and PyObject_NEW() (and all their friends!) -- those functions now know to initialize the weak reference list to NULL for objects which support weak references. Without this change, more places in the code (especially extension modules) need to know more about initialization of weakly-referencable objects. For instance, the "cPickle" and "new" modules both can create instances without calling the code in classobject.c (using PyObject_New()), causing core dumps when such instances are deallocated if the weak-reference list for instances was not properly initialized. Since these modules (properly) tried to avoid call PyInstance_New(), core dumps ensued and the world fell apart. By moving the initialization of the weak reference list into the core object allocators, this problem is averted and extension code to construct new weakly referencable types is simplified. The documentation still needs work, and there are a few new entries for the Python/C API manual as well. A new constructor for instances, PyInstance_NewRaw(), will be added in a separate patch. ------------------------------------------------------- Date: 2001-Jan-17 11:58 By: nascheme Comment: The magic test is: ./python Lib/test/regrtest.py test_weakref test_new Try adding this patch: --- Modules/newmodule.c 2000/11/13 20:29:20 2.29 +++ Modules/newmodule.c 2001/01/17 19:55:46 @@ -24,6 +24,7 @@ Py_INCREF(dict); inst->in_class = (PyClassObject *)klass; inst->in_dict = dict; + inst->in_weakreflist = NULL; PyObject_GC_Init(inst); return (PyObject *)inst; } ------------------------------------------------------- Date: 2001-Jan-17 08:04 By: fdrake Comment: New version of the patch that's still broken but doesn't conflict with the rich comparisons changes: http://starship.python.net/crew/fdrake/patches/weakref.patch-4 ------------------------------------------------------- Date: 2001-Jan-16 21:35 By: fdrake Comment: Added a new (but broken!) version of the patch that fixes WeakDictionary.get() but doesn't interact properly with GC (appearantly) -- not usable as is: http://starship.python.net/crew/fdrake/patches/weakref.patch-3 Neil made the mistake of volunteering to look at the current problem, so assigning to him. (Thanks!) ------------------------------------------------------- Date: 2001-Jan-16 19:39 By: tim_one Comment: Just mentioning a general scenario in which weak keys are the bee's knees: sometimes you want to add attributes to objects dynamically, in ways the original class author(s -- may cut across many classes! even non-instance objects; or objects from extension modules that don't support setattr) never anticipated. Like maybe a German translation of the object's docstrings; or a list of JPEG contents referenced by a URLish object; or a table of usage statistics on methods and functions; etc. Then it's natural to use the conceptual attr name as the name of a dict instead, and write attr[object] = whatever instead of object.attr = whatever There's no point keeping the "whatever" around when the object goes away, but a regular dict makes the object and its "whatever" immortal. A dict with weak keys is exactly on-target. ------------------------------------------------------- Date: 2001-Jan-16 19:14 By: fdrake Comment: I'm not entirely sure why one would want weak keys rather than weak values, but I suspect it has to do with expectations of how the dict will be used in applications. I don't think it would be hard to support both flavors of dictionaries using the primitive reference objects. The constructor does not check that all incoming values are weak because that isn't required. It uses self.update() rather than self.data.update() to perform the inclusion, so any mapping that supports .keys() and .__getitem__() is sufficient. Some additional checking could be done to make sure that all added entries can be created before inserting any of them, offering more atomicity. .get() will be fixed in the next version of the patch; thanks! I've added GC support, but don't have it working quite right. I'm trying to isolate the failure now. ------------------------------------------------------- Date: 2001-Jan-12 14:36 By: loewis Comment: The weak dictionary data type needs more clarification in documentation and implementation. In java.util.WeakHashMap, they keys are weak, not the values (i.e. once the key is forgotten, the entry is cleared). In http://www.handshake.de/~dieter/weakdict.html, the values are weak, but it raises KeyErrors for entries that are collected. The initializer of a weak dict does not check the invariant (all values are weak). get() of a weakdict does not support an optional second parameter. weakref and friends need to participate in garbage collection, as the reference to the callback can create a cycle. ------------------------------------------------------- Date: 2001-Jan-12 11:27 By: fdrake Comment: Updated patch to also support proxy semantics using the same invalidation machinery as the basic weak reference type. The additional code is *heavily* borrowed from Neil Schemenauer. ------------------------------------------------------- Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Wed Jan 31 20:26:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jan 2001 12:26:46 -0800 Subject: [Patches] [Patch #103514] small speedup in Tkinter.Misc._bind Message-ID: <E14O3q2-0007Bp-00@usw-sf-web1.sourceforge.net> Patch #103514 has been updated. Project: python Category: Tkinter Status: Open Submitted by: mfx Assigned to : effbot Summary: small speedup in Tkinter.Misc._bind ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103514&group_id=5470 From noreply@sourceforge.net Wed Jan 31 20:26:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jan 2001 12:26:06 -0800 Subject: [Patches] [Patch #103513] Canvas.py fixes Message-ID: <E14O3pO-0007BW-00@usw-sf-web1.sourceforge.net> Patch #103513 has been updated. Project: python Category: Tkinter Status: Open Submitted by: mfx Assigned to : effbot Summary: Canvas.py fixes ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103513&group_id=5470