From noreply@sourceforge.net Thu Nov 1 04:08:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Oct 2001 20:08:06 -0800 Subject: [Patches] [ python-Patches-476866 ] new improved trace.py Message-ID: Patches item #476866, was opened at 2001-10-31 10:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476866&group_id=5470 Category: Demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zooko Ozoko (zooko) >Assigned to: Skip Montanaro (montanaro) Summary: new improved trace.py Initial Comment: trace.py didn't work for me with Python 2.2a4+, possibly due to me misunderstanding how to use it. In any case this version is substantially rewritten, uses the debugger hooks that were introduced in Python 2.1(?), and has a simpler (in my opinion) interface. Also there are some new features like "countfuncs" mode which is faster than "count" mode and reports only a list of funcs that were invoked. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-31 20:08 Message: Logged In: YES user_id=6380 Skip, what do you think of this? In addition, I think there needs to e a doc string explaining what the --count and --report options do, and how the --file option figures. I am completely unable to understand how these interoperate. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476866&group_id=5470 From noreply@sourceforge.net Thu Nov 1 04:13:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Oct 2001 20:13:38 -0800 Subject: [Patches] [ python-Patches-477059 ] __del__ on new classes vs. GC Message-ID: Patches item #477059, was opened at 2001-10-31 20:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477059&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Neil Schemenauer (nascheme) Summary: __del__ on new classes vs. GC Initial Comment: Neil, excuse me for the assignment. You can reassign this to Tim if you don't have time; I know *I* won't get to it in time for 2.2b2. I recently added __del__ for new-style classes, but I believe this would require the same kind of exception from the GC code as classic instances with a __del__ handler. Of course, it's a bit more difficult since *any* heap-based type can have a __del__ handler... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477059&group_id=5470 From noreply@sourceforge.net Thu Nov 1 06:13:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Oct 2001 22:13:15 -0800 Subject: [Patches] [ python-Patches-477059 ] __del__ on new classes vs. GC Message-ID: Patches item #477059, was opened at 2001-10-31 20:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477059&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Neil Schemenauer (nascheme) Summary: __del__ on new classes vs. GC Initial Comment: Neil, excuse me for the assignment. You can reassign this to Tim if you don't have time; I know *I* won't get to it in time for 2.2b2. I recently added __del__ for new-style classes, but I believe this would require the same kind of exception from the GC code as classic instances with a __del__ handler. Of course, it's a bit more difficult since *any* heap-based type can have a __del__ handler... ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-10-31 22:13 Message: Logged In: YES user_id=31435 Guido, I expect this is shallow, confined to move_finalizers (). It's looking for objects that both (a) have a "__del__" attr, and (b) pass PyInstance_Check(). An instance of a new-style class with __del__ passes the former test but not the latter, and I believe that's all the repair needed (but am blanking out on exactly what should be checked instead -- it will occur to me overnight -- I assume the existing PyInstance_Check is really just trying to avoid the expense of general PyObject_HasAttr when the latter has no chance of succeeding). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477059&group_id=5470 From noreply@sourceforge.net Thu Nov 1 14:26:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Nov 2001 06:26:47 -0800 Subject: [Patches] [ python-Patches-477059 ] __del__ on new classes vs. GC Message-ID: Patches item #477059, was opened at 2001-10-31 20:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477059&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Neil Schemenauer (nascheme) Summary: __del__ on new classes vs. GC Initial Comment: Neil, excuse me for the assignment. You can reassign this to Tim if you don't have time; I know *I* won't get to it in time for 2.2b2. I recently added __del__ for new-style classes, but I believe this would require the same kind of exception from the GC code as classic instances with a __del__ handler. Of course, it's a bit more difficult since *any* heap-based type can have a __del__ handler... ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-01 06:26 Message: Logged In: YES user_id=6380 Thanks -- I thought it would probably shallow but wasn't sure. I've fixed this now. Do I understand correctly that objects with a __del__ attribute are not GC'ed at all (if part of a cycle)? Isn't that sad? Shouldn't we at least attempt to recover the memory without calling the finalizers? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-31 22:13 Message: Logged In: YES user_id=31435 Guido, I expect this is shallow, confined to move_finalizers (). It's looking for objects that both (a) have a "__del__" attr, and (b) pass PyInstance_Check(). An instance of a new-style class with __del__ passes the former test but not the latter, and I believe that's all the repair needed (but am blanking out on exactly what should be checked instead -- it will occur to me overnight -- I assume the existing PyInstance_Check is really just trying to avoid the expense of general PyObject_HasAttr when the latter has no chance of succeeding). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477059&group_id=5470 From noreply@sourceforge.net Thu Nov 1 15:12:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Nov 2001 07:12:04 -0800 Subject: [Patches] [ python-Patches-477161 ] New "access" keyword for mmap Message-ID: Patches item #477161, was opened at 2001-11-01 07:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477161&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jay T Miller (jaytmiller) Assigned to: Nobody/Anonymous (nobody) Summary: New "access" keyword for mmap Initial Comment: The attached patch adds a new keyword parameter to mmap which provides a platform independent way of asking for 3 basic kinds of mmaps: readonly, write-through, and copy-on-write. For now, platform independent means UNIX and Win32. A readonly mmap creates a true readonly section of the process memory map, but python level access is guarded so that attempts to write the section (or fetch a writeable buffer) raise a ValueError exception. A readonly mmap is not resizeable. A write-through memory map is both readable and writeable, and updates to the memory are reflected onto the underlying file. A copy-on-write memory map is both readable and writeable, but updates to the memory are *not* reflected on the underlying file. A copy-on-write mmap is not resizeable. The patch modifies mmapodule.c, libmmap.tex, and test_mmap.py. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477161&group_id=5470 From noreply@sourceforge.net Thu Nov 1 15:12:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Nov 2001 07:12:16 -0800 Subject: [Patches] [ python-Patches-477162 ] New "access" keyword for mmap Message-ID: Patches item #477162, was opened at 2001-11-01 07:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477162&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jay T Miller (jaytmiller) Assigned to: Nobody/Anonymous (nobody) Summary: New "access" keyword for mmap Initial Comment: The attached patch adds a new keyword parameter to mmap which provides a platform independent way of asking for 3 basic kinds of mmaps: readonly, write-through, and copy-on-write. For now, platform independent means UNIX and Win32. A readonly mmap creates a true readonly section of the process memory map, but python level access is guarded so that attempts to write the section (or fetch a writeable buffer) raise a ValueError exception. A readonly mmap is not resizeable. A write-through memory map is both readable and writeable, and updates to the memory are reflected onto the underlying file. A copy-on-write memory map is both readable and writeable, but updates to the memory are *not* reflected on the underlying file. A copy-on-write mmap is not resizeable. The patch modifies mmapodule.c, libmmap.tex, and test_mmap.py. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477162&group_id=5470 From noreply@sourceforge.net Thu Nov 1 15:50:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Nov 2001 07:50:07 -0800 Subject: [Patches] [ python-Patches-477059 ] __del__ on new classes vs. GC Message-ID: Patches item #477059, was opened at 2001-10-31 20:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477059&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Neil Schemenauer (nascheme) Summary: __del__ on new classes vs. GC Initial Comment: Neil, excuse me for the assignment. You can reassign this to Tim if you don't have time; I know *I* won't get to it in time for 2.2b2. I recently added __del__ for new-style classes, but I believe this would require the same kind of exception from the GC code as classic instances with a __del__ handler. Of course, it's a bit more difficult since *any* heap-based type can have a __del__ handler... ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-11-01 07:50 Message: Logged In: YES user_id=35752 This is not too serious of a problem and shouldn't be hard to fix. If we don't do anything then the result will be that unreachable new-style classes will get tp_clear called on them even if they have __del__ methods. As Tim suggests, fixing this should be a matter of removing some PyInstance_Check tests. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-01 06:26 Message: Logged In: YES user_id=6380 Thanks -- I thought it would probably shallow but wasn't sure. I've fixed this now. Do I understand correctly that objects with a __del__ attribute are not GC'ed at all (if part of a cycle)? Isn't that sad? Shouldn't we at least attempt to recover the memory without calling the finalizers? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-31 22:13 Message: Logged In: YES user_id=31435 Guido, I expect this is shallow, confined to move_finalizers (). It's looking for objects that both (a) have a "__del__" attr, and (b) pass PyInstance_Check(). An instance of a new-style class with __del__ passes the former test but not the latter, and I believe that's all the repair needed (but am blanking out on exactly what should be checked instead -- it will occur to me overnight -- I assume the existing PyInstance_Check is really just trying to avoid the expense of general PyObject_HasAttr when the latter has no chance of succeeding). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477059&group_id=5470 From noreply@sourceforge.net Thu Nov 1 16:16:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Nov 2001 08:16:39 -0800 Subject: [Patches] [ python-Patches-477059 ] __del__ on new classes vs. GC Message-ID: Patches item #477059, was opened at 2001-10-31 20:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477059&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) >Assigned to: Tim Peters (tim_one) Summary: __del__ on new classes vs. GC Initial Comment: Neil, excuse me for the assignment. You can reassign this to Tim if you don't have time; I know *I* won't get to it in time for 2.2b2. I recently added __del__ for new-style classes, but I believe this would require the same kind of exception from the GC code as classic instances with a __del__ handler. Of course, it's a bit more difficult since *any* heap-based type can have a __del__ handler... ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-01 08:16 Message: Logged In: YES user_id=6380 I'll leave this in your & Tim's capable hands. I don't see any proof that tp_clear is being called; or maybe there's no tp_clear for new-style instances. I ran this script: import gc class C(object): def __del__(self): print "C.__del__" class X(object): def __del__(self): print "X.__del__" a = C() a.x = X() b = C() b.x = X() a.b = b b.a = a del a, b gc.collect() Before the change I checked in this morning (but after adding __del__, obviously), this printed X.__del__ C.__del__ C.__del__ X.__del__ Now it prints nothing. I somehow had expected this X.__del__ X.__del__ since the X instanes are not contributing to the cycle -- they are merely hanging off its sides. I probably misunderstand something. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-11-01 07:50 Message: Logged In: YES user_id=35752 This is not too serious of a problem and shouldn't be hard to fix. If we don't do anything then the result will be that unreachable new-style classes will get tp_clear called on them even if they have __del__ methods. As Tim suggests, fixing this should be a matter of removing some PyInstance_Check tests. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-01 06:26 Message: Logged In: YES user_id=6380 Thanks -- I thought it would probably shallow but wasn't sure. I've fixed this now. Do I understand correctly that objects with a __del__ attribute are not GC'ed at all (if part of a cycle)? Isn't that sad? Shouldn't we at least attempt to recover the memory without calling the finalizers? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-31 22:13 Message: Logged In: YES user_id=31435 Guido, I expect this is shallow, confined to move_finalizers (). It's looking for objects that both (a) have a "__del__" attr, and (b) pass PyInstance_Check(). An instance of a new-style class with __del__ passes the former test but not the latter, and I believe that's all the repair needed (but am blanking out on exactly what should be checked instead -- it will occur to me overnight -- I assume the existing PyInstance_Check is really just trying to avoid the expense of general PyObject_HasAttr when the latter has no chance of succeeding). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477059&group_id=5470 From noreply@sourceforge.net Thu Nov 1 16:30:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Nov 2001 08:30:27 -0800 Subject: [Patches] [ python-Patches-477059 ] __del__ on new classes vs. GC Message-ID: Patches item #477059, was opened at 2001-10-31 20:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477059&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) >Assigned to: Neil Schemenauer (nascheme) Summary: __del__ on new classes vs. GC Initial Comment: Neil, excuse me for the assignment. You can reassign this to Tim if you don't have time; I know *I* won't get to it in time for 2.2b2. I recently added __del__ for new-style classes, but I believe this would require the same kind of exception from the GC code as classic instances with a __del__ handler. Of course, it's a bit more difficult since *any* heap-based type can have a __del__ handler... ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-11-01 08:30 Message: Logged In: YES user_id=35752 Anything with a finalizer (i.e. __del__ method) or reachable from a finalizer does not get tp_clear called on it. We discussed this at length when the GC was being implemented. I don't think anything has changed since then but I'm open to more discussion. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-01 08:16 Message: Logged In: YES user_id=6380 I'll leave this in your & Tim's capable hands. I don't see any proof that tp_clear is being called; or maybe there's no tp_clear for new-style instances. I ran this script: import gc class C(object): def __del__(self): print "C.__del__" class X(object): def __del__(self): print "X.__del__" a = C() a.x = X() b = C() b.x = X() a.b = b b.a = a del a, b gc.collect() Before the change I checked in this morning (but after adding __del__, obviously), this printed X.__del__ C.__del__ C.__del__ X.__del__ Now it prints nothing. I somehow had expected this X.__del__ X.__del__ since the X instanes are not contributing to the cycle -- they are merely hanging off its sides. I probably misunderstand something. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-11-01 07:50 Message: Logged In: YES user_id=35752 This is not too serious of a problem and shouldn't be hard to fix. If we don't do anything then the result will be that unreachable new-style classes will get tp_clear called on them even if they have __del__ methods. As Tim suggests, fixing this should be a matter of removing some PyInstance_Check tests. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-01 06:26 Message: Logged In: YES user_id=6380 Thanks -- I thought it would probably shallow but wasn't sure. I've fixed this now. Do I understand correctly that objects with a __del__ attribute are not GC'ed at all (if part of a cycle)? Isn't that sad? Shouldn't we at least attempt to recover the memory without calling the finalizers? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-31 22:13 Message: Logged In: YES user_id=31435 Guido, I expect this is shallow, confined to move_finalizers (). It's looking for objects that both (a) have a "__del__" attr, and (b) pass PyInstance_Check(). An instance of a new-style class with __del__ passes the former test but not the latter, and I believe that's all the repair needed (but am blanking out on exactly what should be checked instead -- it will occur to me overnight -- I assume the existing PyInstance_Check is really just trying to avoid the expense of general PyObject_HasAttr when the latter has no chance of succeeding). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477059&group_id=5470 From noreply@sourceforge.net Thu Nov 1 16:39:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Nov 2001 08:39:08 -0800 Subject: [Patches] [ python-Patches-477059 ] __del__ on new classes vs. GC Message-ID: Patches item #477059, was opened at 2001-10-31 20:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477059&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Neil Schemenauer (nascheme) Summary: __del__ on new classes vs. GC Initial Comment: Neil, excuse me for the assignment. You can reassign this to Tim if you don't have time; I know *I* won't get to it in time for 2.2b2. I recently added __del__ for new-style classes, but I believe this would require the same kind of exception from the GC code as classic instances with a __del__ handler. Of course, it's a bit more difficult since *any* heap-based type can have a __del__ handler... ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-01 08:39 Message: Logged In: YES user_id=6380 I guess I misunderstood what you said before. Never mind. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-11-01 08:30 Message: Logged In: YES user_id=35752 Anything with a finalizer (i.e. __del__ method) or reachable from a finalizer does not get tp_clear called on it. We discussed this at length when the GC was being implemented. I don't think anything has changed since then but I'm open to more discussion. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-01 08:16 Message: Logged In: YES user_id=6380 I'll leave this in your & Tim's capable hands. I don't see any proof that tp_clear is being called; or maybe there's no tp_clear for new-style instances. I ran this script: import gc class C(object): def __del__(self): print "C.__del__" class X(object): def __del__(self): print "X.__del__" a = C() a.x = X() b = C() b.x = X() a.b = b b.a = a del a, b gc.collect() Before the change I checked in this morning (but after adding __del__, obviously), this printed X.__del__ C.__del__ C.__del__ X.__del__ Now it prints nothing. I somehow had expected this X.__del__ X.__del__ since the X instanes are not contributing to the cycle -- they are merely hanging off its sides. I probably misunderstand something. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-11-01 07:50 Message: Logged In: YES user_id=35752 This is not too serious of a problem and shouldn't be hard to fix. If we don't do anything then the result will be that unreachable new-style classes will get tp_clear called on them even if they have __del__ methods. As Tim suggests, fixing this should be a matter of removing some PyInstance_Check tests. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-01 06:26 Message: Logged In: YES user_id=6380 Thanks -- I thought it would probably shallow but wasn't sure. I've fixed this now. Do I understand correctly that objects with a __del__ attribute are not GC'ed at all (if part of a cycle)? Isn't that sad? Shouldn't we at least attempt to recover the memory without calling the finalizers? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-31 22:13 Message: Logged In: YES user_id=31435 Guido, I expect this is shallow, confined to move_finalizers (). It's looking for objects that both (a) have a "__del__" attr, and (b) pass PyInstance_Check(). An instance of a new-style class with __del__ passes the former test but not the latter, and I believe that's all the repair needed (but am blanking out on exactly what should be checked instead -- it will occur to me overnight -- I assume the existing PyInstance_Check is really just trying to avoid the expense of general PyObject_HasAttr when the latter has no chance of succeeding). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477059&group_id=5470 From noreply@sourceforge.net Thu Nov 1 16:45:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Nov 2001 08:45:13 -0800 Subject: [Patches] [ python-Patches-477059 ] __del__ on new classes vs. GC Message-ID: Patches item #477059, was opened at 2001-10-31 20:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477059&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Neil Schemenauer (nascheme) Summary: __del__ on new classes vs. GC Initial Comment: Neil, excuse me for the assignment. You can reassign this to Tim if you don't have time; I know *I* won't get to it in time for 2.2b2. I recently added __del__ for new-style classes, but I believe this would require the same kind of exception from the GC code as classic instances with a __del__ handler. Of course, it's a bit more difficult since *any* heap-based type can have a __del__ handler... ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-11-01 08:45 Message: Logged In: YES user_id=35752 We seem to have our messages passing each other in flight. :-) In your example you don't see X.__del__ because the C instances are never freed. We can't call tp_clear on either of the C instances because we can't choose an ordering that ensures their __del__ methods will work. For example, if we clear "a" first but b.__del__ uses some attributes of "a" then we will get an exception. I suppose we could have an option that says "call tp_clear on unreachable objects even if they have finalizers". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-01 08:39 Message: Logged In: YES user_id=6380 I guess I misunderstood what you said before. Never mind. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-11-01 08:30 Message: Logged In: YES user_id=35752 Anything with a finalizer (i.e. __del__ method) or reachable from a finalizer does not get tp_clear called on it. We discussed this at length when the GC was being implemented. I don't think anything has changed since then but I'm open to more discussion. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-01 08:16 Message: Logged In: YES user_id=6380 I'll leave this in your & Tim's capable hands. I don't see any proof that tp_clear is being called; or maybe there's no tp_clear for new-style instances. I ran this script: import gc class C(object): def __del__(self): print "C.__del__" class X(object): def __del__(self): print "X.__del__" a = C() a.x = X() b = C() b.x = X() a.b = b b.a = a del a, b gc.collect() Before the change I checked in this morning (but after adding __del__, obviously), this printed X.__del__ C.__del__ C.__del__ X.__del__ Now it prints nothing. I somehow had expected this X.__del__ X.__del__ since the X instanes are not contributing to the cycle -- they are merely hanging off its sides. I probably misunderstand something. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-11-01 07:50 Message: Logged In: YES user_id=35752 This is not too serious of a problem and shouldn't be hard to fix. If we don't do anything then the result will be that unreachable new-style classes will get tp_clear called on them even if they have __del__ methods. As Tim suggests, fixing this should be a matter of removing some PyInstance_Check tests. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-01 06:26 Message: Logged In: YES user_id=6380 Thanks -- I thought it would probably shallow but wasn't sure. I've fixed this now. Do I understand correctly that objects with a __del__ attribute are not GC'ed at all (if part of a cycle)? Isn't that sad? Shouldn't we at least attempt to recover the memory without calling the finalizers? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-31 22:13 Message: Logged In: YES user_id=31435 Guido, I expect this is shallow, confined to move_finalizers (). It's looking for objects that both (a) have a "__del__" attr, and (b) pass PyInstance_Check(). An instance of a new-style class with __del__ passes the former test but not the latter, and I believe that's all the repair needed (but am blanking out on exactly what should be checked instead -- it will occur to me overnight -- I assume the existing PyInstance_Check is really just trying to avoid the expense of general PyObject_HasAttr when the latter has no chance of succeeding). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477059&group_id=5470 From noreply@sourceforge.net Thu Nov 1 17:03:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Nov 2001 09:03:28 -0800 Subject: [Patches] [ python-Patches-477059 ] __del__ on new classes vs. GC Message-ID: Patches item #477059, was opened at 2001-10-31 20:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477059&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Neil Schemenauer (nascheme) Summary: __del__ on new classes vs. GC Initial Comment: Neil, excuse me for the assignment. You can reassign this to Tim if you don't have time; I know *I* won't get to it in time for 2.2b2. I recently added __del__ for new-style classes, but I believe this would require the same kind of exception from the GC code as classic instances with a __del__ handler. Of course, it's a bit more difficult since *any* heap-based type can have a __del__ handler... ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-11-01 09:03 Message: Logged In: YES user_id=31435 In Guido's example, if we assume the cycle will never ever get broken by the user, then reclaiming the X instances would be cool: we know they're trash, and they're not themselves in a cycle. The rub is that it's a bad assumption -- despite that the cycle is unreachable, it can still be gotten at, by the user, via gc's list of unreclaimable trash. My model for what people should do is: 1. Don't create cycles with __del__ methods. 2. If you do, cleam 'em up yourself (and gc exposes the unreclaimable cycles, so that's quite doable even *after* the cycles become "unreachable"). So long as we expose unreclaimable cycles, nothing in a cycle is *truly* unreachable, and that makes deleting the X instances by magic dangerous (the user may break the cycle themself, and a destructor in one of the cycle members may need to access an intact X). ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-11-01 08:45 Message: Logged In: YES user_id=35752 We seem to have our messages passing each other in flight. :-) In your example you don't see X.__del__ because the C instances are never freed. We can't call tp_clear on either of the C instances because we can't choose an ordering that ensures their __del__ methods will work. For example, if we clear "a" first but b.__del__ uses some attributes of "a" then we will get an exception. I suppose we could have an option that says "call tp_clear on unreachable objects even if they have finalizers". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-01 08:39 Message: Logged In: YES user_id=6380 I guess I misunderstood what you said before. Never mind. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-11-01 08:30 Message: Logged In: YES user_id=35752 Anything with a finalizer (i.e. __del__ method) or reachable from a finalizer does not get tp_clear called on it. We discussed this at length when the GC was being implemented. I don't think anything has changed since then but I'm open to more discussion. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-01 08:16 Message: Logged In: YES user_id=6380 I'll leave this in your & Tim's capable hands. I don't see any proof that tp_clear is being called; or maybe there's no tp_clear for new-style instances. I ran this script: import gc class C(object): def __del__(self): print "C.__del__" class X(object): def __del__(self): print "X.__del__" a = C() a.x = X() b = C() b.x = X() a.b = b b.a = a del a, b gc.collect() Before the change I checked in this morning (but after adding __del__, obviously), this printed X.__del__ C.__del__ C.__del__ X.__del__ Now it prints nothing. I somehow had expected this X.__del__ X.__del__ since the X instanes are not contributing to the cycle -- they are merely hanging off its sides. I probably misunderstand something. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-11-01 07:50 Message: Logged In: YES user_id=35752 This is not too serious of a problem and shouldn't be hard to fix. If we don't do anything then the result will be that unreachable new-style classes will get tp_clear called on them even if they have __del__ methods. As Tim suggests, fixing this should be a matter of removing some PyInstance_Check tests. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-01 06:26 Message: Logged In: YES user_id=6380 Thanks -- I thought it would probably shallow but wasn't sure. I've fixed this now. Do I understand correctly that objects with a __del__ attribute are not GC'ed at all (if part of a cycle)? Isn't that sad? Shouldn't we at least attempt to recover the memory without calling the finalizers? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-31 22:13 Message: Logged In: YES user_id=31435 Guido, I expect this is shallow, confined to move_finalizers (). It's looking for objects that both (a) have a "__del__" attr, and (b) pass PyInstance_Check(). An instance of a new-style class with __del__ passes the former test but not the latter, and I believe that's all the repair needed (but am blanking out on exactly what should be checked instead -- it will occur to me overnight -- I assume the existing PyInstance_Check is really just trying to avoid the expense of general PyObject_HasAttr when the latter has no chance of succeeding). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477059&group_id=5470 From noreply@sourceforge.net Thu Nov 1 19:49:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Nov 2001 11:49:47 -0800 Subject: [Patches] [ python-Patches-477059 ] __del__ on new classes vs. GC Message-ID: Patches item #477059, was opened at 2001-10-31 20:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477059&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Neil Schemenauer (nascheme) Summary: __del__ on new classes vs. GC Initial Comment: Neil, excuse me for the assignment. You can reassign this to Tim if you don't have time; I know *I* won't get to it in time for 2.2b2. I recently added __del__ for new-style classes, but I believe this would require the same kind of exception from the GC code as classic instances with a __del__ handler. Of course, it's a bit more difficult since *any* heap-based type can have a __del__ handler... ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-01 11:49 Message: Logged In: YES user_id=6380 Neil, thanks for fixing my broken checkin. I think it still needs a documentation change: the meaning of the variable gc.garbage has changed. In a discussion before lunch, Tim suggested that when Python exits (or better, in Py_Finalize()) a check could be made if there is any garbage in gc.garbage, and if so, a warning about this should be printed to stderr. That seems a nice feature. In that same discussion, I realized that the module cleanup behavior (where all globals in a module are set to None when the module object is deallocated) is probably no longer necessary now that we have GC. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-01 09:03 Message: Logged In: YES user_id=31435 In Guido's example, if we assume the cycle will never ever get broken by the user, then reclaiming the X instances would be cool: we know they're trash, and they're not themselves in a cycle. The rub is that it's a bad assumption -- despite that the cycle is unreachable, it can still be gotten at, by the user, via gc's list of unreclaimable trash. My model for what people should do is: 1. Don't create cycles with __del__ methods. 2. If you do, cleam 'em up yourself (and gc exposes the unreclaimable cycles, so that's quite doable even *after* the cycles become "unreachable"). So long as we expose unreclaimable cycles, nothing in a cycle is *truly* unreachable, and that makes deleting the X instances by magic dangerous (the user may break the cycle themself, and a destructor in one of the cycle members may need to access an intact X). ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-11-01 08:45 Message: Logged In: YES user_id=35752 We seem to have our messages passing each other in flight. :-) In your example you don't see X.__del__ because the C instances are never freed. We can't call tp_clear on either of the C instances because we can't choose an ordering that ensures their __del__ methods will work. For example, if we clear "a" first but b.__del__ uses some attributes of "a" then we will get an exception. I suppose we could have an option that says "call tp_clear on unreachable objects even if they have finalizers". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-01 08:39 Message: Logged In: YES user_id=6380 I guess I misunderstood what you said before. Never mind. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-11-01 08:30 Message: Logged In: YES user_id=35752 Anything with a finalizer (i.e. __del__ method) or reachable from a finalizer does not get tp_clear called on it. We discussed this at length when the GC was being implemented. I don't think anything has changed since then but I'm open to more discussion. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-01 08:16 Message: Logged In: YES user_id=6380 I'll leave this in your & Tim's capable hands. I don't see any proof that tp_clear is being called; or maybe there's no tp_clear for new-style instances. I ran this script: import gc class C(object): def __del__(self): print "C.__del__" class X(object): def __del__(self): print "X.__del__" a = C() a.x = X() b = C() b.x = X() a.b = b b.a = a del a, b gc.collect() Before the change I checked in this morning (but after adding __del__, obviously), this printed X.__del__ C.__del__ C.__del__ X.__del__ Now it prints nothing. I somehow had expected this X.__del__ X.__del__ since the X instanes are not contributing to the cycle -- they are merely hanging off its sides. I probably misunderstand something. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-11-01 07:50 Message: Logged In: YES user_id=35752 This is not too serious of a problem and shouldn't be hard to fix. If we don't do anything then the result will be that unreachable new-style classes will get tp_clear called on them even if they have __del__ methods. As Tim suggests, fixing this should be a matter of removing some PyInstance_Check tests. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-01 06:26 Message: Logged In: YES user_id=6380 Thanks -- I thought it would probably shallow but wasn't sure. I've fixed this now. Do I understand correctly that objects with a __del__ attribute are not GC'ed at all (if part of a cycle)? Isn't that sad? Shouldn't we at least attempt to recover the memory without calling the finalizers? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-31 22:13 Message: Logged In: YES user_id=31435 Guido, I expect this is shallow, confined to move_finalizers (). It's looking for objects that both (a) have a "__del__" attr, and (b) pass PyInstance_Check(). An instance of a new-style class with __del__ passes the former test but not the latter, and I believe that's all the repair needed (but am blanking out on exactly what should be checked instead -- it will occur to me overnight -- I assume the existing PyInstance_Check is really just trying to avoid the expense of general PyObject_HasAttr when the latter has no chance of succeeding). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477059&group_id=5470 From noreply@sourceforge.net Thu Nov 1 23:08:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Nov 2001 15:08:04 -0800 Subject: [Patches] [ python-Patches-477330 ] add __slot_docs__ and __slot_types__ Message-ID: Patches item #477330, was opened at 2001-11-01 15:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477330&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael McLay (mclay) Assigned to: Nobody/Anonymous (nobody) Summary: add __slot_docs__ and __slot_types__ Initial Comment: The slot members defined using__slots__ cannot be assigned doc strings in the current implementation. This patch adds the ability to attach doc strings to a slot member by assigning a dictionary to the __slot_docs__ class variable. >>> class B(object): __slots__ = ['a','b','c'] __slot_docs__ = {'a':"the a docstring",'b':"the b doc string"} __slot_types__ = {'a':(int,str), 'c':int, } >>> B.a.__doc__ 'the a docstring' >>> The __slot_types__ class variable adds an optional type constraint for the slot. If a dictionary with a type or list of types is associated with a member name then the isinstance() method will be called on that member when the get and set methods for the member are called. >>> class B(object): __slots__ = ['a','b','c'] __slot_docs__ = {'a':"the a docstring",'b':"the b doc string"} __slot_types__ = {'a':(int,str), 'c':int, } def __getattribute__(self,name): print "help please", name return object.__getattribute__(self, name) >>> class B(object): __slots__ = ['a','b','c'] __slot_docs__ = {'a':"the a docstring",'b':"the b doc string"} __slot_types__ = {'a':(int,str), 'c':int, } >>> b = B() >>> b.a Traceback (most recent call last): File "", line 1, in ? b.a TypeError: The value of B.a is of type . This is not one of the defined slot_types >>> b.a = 4 >>> b.a 4 >>> b.a = 34.3 Traceback (most recent call last): File "", line 1, in ? b.a = 34.3 TypeError: The type of is not one of the defined slot_types for B.a >>> b.b >>> b.b = 3 >>> b.b = 34.2 >>> b.b 34.200000000000003 >>> b.a = "fish" >>> b.a 'fish' >>> ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477330&group_id=5470 From noreply@sourceforge.net Thu Nov 1 23:50:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Nov 2001 15:50:47 -0800 Subject: [Patches] [ python-Patches-477336 ] hmac module bugfixes and testsuite Message-ID: Patches item #477336, was opened at 2001-11-01 15:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477336&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Häring (ghaering) Assigned to: Nobody/Anonymous (nobody) Summary: hmac module bugfixes and testsuite Initial Comment: This is a followup to A.M. Kuchling's patch #476612. SF doesn't allow me to upload files there, so here's a new patch. It includes - his fixes wrt to PEP 247 compliance for the hmac module. - a fix for the copy method of the HMAC class; this one was totally broken - an extensive PyUnit based testsuite for the hmac module; the check with the test vectors was also moved from hmac.py to test_hmac.py ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477336&group_id=5470 From noreply@sourceforge.net Thu Nov 1 23:54:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Nov 2001 15:54:53 -0800 Subject: [Patches] [ python-Patches-476612 ] Make md5/sha/hmac match PEP 247 Message-ID: Patches item #476612, was opened at 2001-10-30 18:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476612&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Make md5/sha/hmac match PEP 247 Initial Comment: This patch makes the interfaces of the md5, sha, and hmac modules match that described in PEP 247. For md5 and sha, the patch just adds digest_size attributes (in addition to the existing digestsize :(). For hmac it does the same, and also makes the .copy() method work. The patch to hmac.py should be reviewed by Gerhard Haring; the other bits of the patch are trivial and just need a quick skim from someone to catch any dopey thinkos. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2001-11-01 15:54 Message: Logged In: YES user_id=163326 I've reviewed the hmac changes. Unfortunately, the copy method was more broken than you thought ;-) I've fixed this in patch #477336 and also submitted an extensive testsuite for hmac there. This patch also contains your changes to hmac.py. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-10-30 18:44 Message: Logged In: YES user_id=11375 Attaching Lib/test/test_pep247.py, which checks the three included hashing modules for compliance with PEP247. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476612&group_id=5470 From noreply@sourceforge.net Fri Nov 2 03:50:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Nov 2001 19:50:16 -0800 Subject: [Patches] [ python-Patches-471120 ] Upgraded Tix.py Message-ID: Patches item #471120, was opened at 2001-10-14 14:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471120&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Upgraded Tix.py Initial Comment: One minor bugfix to DisplayStyle.cget Improved doc strings. Placeholder classes for classes still to be wrapped. ---------------------------------------------------------------------- >Comment By: Internet Discovery (idiscovery) Date: 2001-11-01 19:50 Message: Logged In: YES user_id=33229 The removal of the entry in item_cget is a mistake. Specifically, delete the following lines from the patch: *************** *** 730,736 **** c = self.tk.call(self._w, 'info', 'selection') return self.tk.splitlist(c) ! def item_cget(self, entry, col, opt): return self.tk.call(self._w, 'item', 'cget', entry, col, opt) def item_configure(self, entry, col, cnf={}, **kw): --- 944,950 ---- c = self.tk.call(self._w, 'info', 'selection') return self.tk.splitlist(c) ! def item_cget(self, col, opt): return self.tk.call(self._w, 'item', 'cget', entry, col, opt) I think this patch just fills in gaps rather than adding new features. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-19 05:37 Message: Logged In: YES user_id=6380 I agree this can go in after 2.2b1. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-19 03:41 Message: Logged In: YES user_id=21627 Why does this patch remove the "entry" argument to item_cget? Note that it missed the 2.2b1 branch creation; since it adds new features, it is not clear whether this can go into 2.2 still (IMO it should). ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-10-18 13:27 Message: Logged In: YES user_id=33229 New Tix.py as diff -c 3 new classes wrapped, and tix command added. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-15 12:41 Message: Logged In: YES user_id=21627 Could you please provide the patch as a context (-c) or unified (-u) diff? Also, could you please base it on the latest version of Tix.py (1.4)? Please have a look at http://python.sourceforge.net/sf-faq.html for details. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471120&group_id=5470 From noreply@sourceforge.net Fri Nov 2 09:11:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 02 Nov 2001 01:11:16 -0800 Subject: [Patches] [ python-Patches-471120 ] Upgraded Tix.py Message-ID: Patches item #471120, was opened at 2001-10-14 14:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471120&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Internet Discovery (idiscovery) >Assigned to: Martin v. Löwis (loewis) Summary: Upgraded Tix.py Initial Comment: One minor bugfix to DisplayStyle.cget Improved doc strings. Placeholder classes for classes still to be wrapped. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-11-01 19:50 Message: Logged In: YES user_id=33229 The removal of the entry in item_cget is a mistake. Specifically, delete the following lines from the patch: *************** *** 730,736 **** c = self.tk.call(self._w, 'info', 'selection') return self.tk.splitlist(c) ! def item_cget(self, entry, col, opt): return self.tk.call(self._w, 'item', 'cget', entry, col, opt) def item_configure(self, entry, col, cnf={}, **kw): --- 944,950 ---- c = self.tk.call(self._w, 'info', 'selection') return self.tk.splitlist(c) ! def item_cget(self, col, opt): return self.tk.call(self._w, 'item', 'cget', entry, col, opt) I think this patch just fills in gaps rather than adding new features. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-19 05:37 Message: Logged In: YES user_id=6380 I agree this can go in after 2.2b1. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-19 03:41 Message: Logged In: YES user_id=21627 Why does this patch remove the "entry" argument to item_cget? Note that it missed the 2.2b1 branch creation; since it adds new features, it is not clear whether this can go into 2.2 still (IMO it should). ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-10-18 13:27 Message: Logged In: YES user_id=33229 New Tix.py as diff -c 3 new classes wrapped, and tix command added. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-15 12:41 Message: Logged In: YES user_id=21627 Could you please provide the patch as a context (-c) or unified (-u) diff? Also, could you please base it on the latest version of Tix.py (1.4)? Please have a look at http://python.sourceforge.net/sf-faq.html for details. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471120&group_id=5470 From noreply@sourceforge.net Fri Nov 2 14:02:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 02 Nov 2001 06:02:49 -0800 Subject: [Patches] [ python-Patches-449973 ] Useful call method on base class. Message-ID: Patches item #449973, was opened at 2001-08-10 18:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449973&group_id=5470 Category: XML Group: None >Status: Closed >Resolution: Wont Fix Priority: 3 Submitted By: Paul Prescod (prescod) Assigned to: Fredrik Lundh (effbot) Summary: Useful call method on base class. Initial Comment: Most XML-RPC servers out there use a call method that dispatches XML-RPC method names to Python methods automatically. Because this behaviour is so common, I think it should be default behaviour. There will be a few cases where this behaviour is NOT appropriate but neither is the current behaviour. i.e. I am trying to reduce the necessity to subclass call, not completely remove it. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-10-18 11:38 Message: Logged In: YES user_id=38376 The xmlrpcserver module is deprecated (and will probably be removed in 2.2 final). Use SimpleXMLRPCServer instead. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-19 12:01 Message: Logged In: YES user_id=21627 Why is it desirable to pass the method name as the first argument? Why are the other arguments not passed as *args? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449973&group_id=5470 From noreply@sourceforge.net Fri Nov 2 14:15:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 02 Nov 2001 06:15:22 -0800 Subject: [Patches] [ python-Patches-477162 ] New "access" keyword for mmap Message-ID: Patches item #477162, was opened at 2001-11-01 07:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477162&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jay T Miller (jaytmiller) Assigned to: Nobody/Anonymous (nobody) >Summary: New "access" keyword for mmap Initial Comment: The attached patch adds a new keyword parameter to mmap which provides a platform independent way of asking for 3 basic kinds of mmaps: readonly, write-through, and copy-on-write. For now, platform independent means UNIX and Win32. A readonly mmap creates a true readonly section of the process memory map, but python level access is guarded so that attempts to write the section (or fetch a writeable buffer) raise a ValueError exception. A readonly mmap is not resizeable. A write-through memory map is both readable and writeable, and updates to the memory are reflected onto the underlying file. A copy-on-write memory map is both readable and writeable, but updates to the memory are *not* reflected on the underlying file. A copy-on-write mmap is not resizeable. The patch modifies mmapodule.c, libmmap.tex, and test_mmap.py. ---------------------------------------------------------------------- >Comment By: Jay T Miller (jaytmiller) Date: 2001-11-02 06:15 Message: Logged In: YES user_id=320512 My apologies. Patch #477162 is a duplicate of #477161. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477162&group_id=5470 From noreply@sourceforge.net Fri Nov 2 19:26:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 02 Nov 2001 11:26:32 -0800 Subject: [Patches] [ python-Patches-473749 ] compile under OS/2 VA C++ Message-ID: Patches item #473749, was opened at 2001-10-22 12:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473749&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Muller (mikemuller) Assigned to: Nobody/Anonymous (nobody) Summary: compile under OS/2 VA C++ Initial Comment: This is the minimal set of changes I found necessary to get the latest Python CVS image built under OS/2 Visual Age C++. I'm pretty sure that some of these changes will conflict with changes submitted by Andrew MacIntyre for OS/2 EMX. If his changes are checked in before mine, I'd be happy to resolve the conflicts and resubmit this patch. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-11-02 11:26 Message: Logged In: YES user_id=21627 The patch looks fine to me. A few comments: - Why did you drop Tkinter support? - The symbol list in python.def is way too short. Essentially, every function that has a DL_IMPORT in Include/* must be listed in the .def file (or, if not - why is the .def file necessary in the first place?) For example, all the Unicode functions are missing. ---------------------------------------------------------------------- Comment By: Michael Muller (mikemuller) Date: 2001-10-30 10:46 Message: Logged In: YES user_id=353708 1) "#ifdef __BEOS__" vs. "#if defined(__BEOS_)" This is not necessary. I was under the mistaken impression that #ifdef ... #elif caused problems under VAC++. 3) positive case first I agree. I have posted another patch which addresses these issues. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2001-10-30 04:50 Message: Logged In: YES user_id=250749 1) in Modules/socketmodule.c, is changing "#ifdef __BEOS__" to "#if defined(__BEOS__)" absolutely necessary? While I would also do this, others view such apparently cosmetic changes with suspicion. 2) the changes to the files in PC/os2vacpp look OK. 3) in Python/bltinmodule.c, I would have suggested using #if #else #endif rather than #if ! #else #endif Negated #ifdefs seem to be considerably in the minority in the Python source tree AFAICS. 4) change to Python/importdl.h is OK as its in an #ifdef OS2 The changes noted in 2) & 4) look good to go. Feedback from anyone else about the stylistics noted in 1) & 3)? ---------------------------------------------------------------------- Comment By: Michael Muller (mikemuller) Date: 2001-10-26 05:37 Message: Logged In: YES user_id=353708 Resubmitted to resolve conflict with changes to bltinmodule.c ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473749&group_id=5470 From noreply@sourceforge.net Fri Nov 2 20:01:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 02 Nov 2001 12:01:09 -0800 Subject: [Patches] [ python-Patches-477336 ] hmac module bugfixes and testsuite Message-ID: Patches item #477336, was opened at 2001-11-01 15:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477336&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Häring (ghaering) >Assigned to: A.M. Kuchling (akuchling) Summary: hmac module bugfixes and testsuite Initial Comment: This is a followup to A.M. Kuchling's patch #476612. SF doesn't allow me to upload files there, so here's a new patch. It includes - his fixes wrt to PEP 247 compliance for the hmac module. - a fix for the copy method of the HMAC class; this one was totally broken - an extensive PyUnit based testsuite for the hmac module; the check with the test vectors was also moved from hmac.py to test_hmac.py ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-11-02 12:01 Message: Logged In: YES user_id=11375 I'll review this patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477336&group_id=5470 From noreply@sourceforge.net Fri Nov 2 20:12:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 02 Nov 2001 12:12:15 -0800 Subject: [Patches] [ python-Patches-476612 ] Make md5/sha/hmac match PEP 247 Message-ID: Patches item #476612, was opened at 2001-10-30 18:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476612&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) >Assigned to: Neil Schemenauer (nascheme) Summary: Make md5/sha/hmac match PEP 247 Initial Comment: This patch makes the interfaces of the md5, sha, and hmac modules match that described in PEP 247. For md5 and sha, the patch just adds digest_size attributes (in addition to the existing digestsize :(). For hmac it does the same, and also makes the .copy() method work. The patch to hmac.py should be reviewed by Gerhard Haring; the other bits of the patch are trivial and just need a quick skim from someone to catch any dopey thinkos. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-11-02 12:12 Message: Logged In: YES user_id=11375 Randomly assigning to Neil for a quick skim. (Don't bother proofreading the hmac.py changes; the original author has a different patch.) ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2001-11-01 15:54 Message: Logged In: YES user_id=163326 I've reviewed the hmac changes. Unfortunately, the copy method was more broken than you thought ;-) I've fixed this in patch #477336 and also submitted an extensive testsuite for hmac there. This patch also contains your changes to hmac.py. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-10-30 18:44 Message: Logged In: YES user_id=11375 Attaching Lib/test/test_pep247.py, which checks the three included hashing modules for compliance with PEP247. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476612&group_id=5470 From noreply@sourceforge.net Fri Nov 2 21:27:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 02 Nov 2001 13:27:40 -0800 Subject: [Patches] [ python-Patches-477336 ] hmac module bugfixes and testsuite Message-ID: Patches item #477336, was opened at 2001-11-01 15:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477336&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Häring (ghaering) Assigned to: A.M. Kuchling (akuchling) Summary: hmac module bugfixes and testsuite Initial Comment: This is a followup to A.M. Kuchling's patch #476612. SF doesn't allow me to upload files there, so here's a new patch. It includes - his fixes wrt to PEP 247 compliance for the hmac module. - a fix for the copy method of the HMAC class; this one was totally broken - an extensive PyUnit based testsuite for the hmac module; the check with the test vectors was also moved from hmac.py to test_hmac.py ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-11-02 13:27 Message: Logged In: YES user_id=11375 The patch looks good. One minor thing: after the patch, hmac.py's if __name__ == "__main__" tries to call the non-existent test() function; I'll simply delete it. Checking in this patch will have to wait until #476612 gets checked in. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-11-02 12:01 Message: Logged In: YES user_id=11375 I'll review this patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477336&group_id=5470 From noreply@sourceforge.net Fri Nov 2 21:30:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 02 Nov 2001 13:30:07 -0800 Subject: [Patches] [ python-Patches-476612 ] Make md5/sha/hmac match PEP 247 Message-ID: Patches item #476612, was opened at 2001-10-30 18:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476612&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) >Assigned to: A.M. Kuchling (akuchling) Summary: Make md5/sha/hmac match PEP 247 Initial Comment: This patch makes the interfaces of the md5, sha, and hmac modules match that described in PEP 247. For md5 and sha, the patch just adds digest_size attributes (in addition to the existing digestsize :(). For hmac it does the same, and also makes the .copy() method work. The patch to hmac.py should be reviewed by Gerhard Haring; the other bits of the patch are trivial and just need a quick skim from someone to catch any dopey thinkos. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-11-02 13:30 Message: Logged In: YES user_id=35752 Looks good to me. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-11-02 12:12 Message: Logged In: YES user_id=11375 Randomly assigning to Neil for a quick skim. (Don't bother proofreading the hmac.py changes; the original author has a different patch.) ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2001-11-01 15:54 Message: Logged In: YES user_id=163326 I've reviewed the hmac changes. Unfortunately, the copy method was more broken than you thought ;-) I've fixed this in patch #477336 and also submitted an extensive testsuite for hmac there. This patch also contains your changes to hmac.py. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-10-30 18:44 Message: Logged In: YES user_id=11375 Attaching Lib/test/test_pep247.py, which checks the three included hashing modules for compliance with PEP247. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476612&group_id=5470 From noreply@sourceforge.net Fri Nov 2 21:35:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 02 Nov 2001 13:35:35 -0800 Subject: [Patches] [ python-Patches-473749 ] compile under OS/2 VA C++ Message-ID: Patches item #473749, was opened at 2001-10-22 12:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473749&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Muller (mikemuller) Assigned to: Nobody/Anonymous (nobody) Summary: compile under OS/2 VA C++ Initial Comment: This is the minimal set of changes I found necessary to get the latest Python CVS image built under OS/2 Visual Age C++. I'm pretty sure that some of these changes will conflict with changes submitted by Andrew MacIntyre for OS/2 EMX. If his changes are checked in before mine, I'd be happy to resolve the conflicts and resubmit this patch. ---------------------------------------------------------------------- >Comment By: Michael Muller (mikemuller) Date: 2001-11-02 13:35 Message: Logged In: YES user_id=353708 > - Why did you drop Tkinter support? Because AFAIK it doesn't work. I asked Jeff Rush about this back in the 1.5.2 days, and I think he said that he had gotten it to compile but was not able to run it. I had similar experiences linking directly against the Tcl/Tk libraries that have been distributed for OS/2. I have just sent him a note to confirm this. I have released 1.5.1 and 1.5.2 versions of Tkinter for OS/2 based on heavily hacked versions of the EMX Tcl/Tk port and of _tkinter.c itself. I'd like to see it back in the main build, but I don't really have the time to make that happen right now, so I hope to distribute Tkinter-OS/2 seperately again for 2.1.1 (and probably 2.2 as well). > - The symbol list in python.def is way too short. As I said, this was the minimal set of changes necessary to compile. When I came up with an "unresolved external" linking python and PGen, I added the unresolved function name to the def file. What I'd like to do (and have been experimenting with in 2.1.1) is to generate the def file automatically from the object modules. However, it seemed to me that restructuring the makefile goes way beyond the minimal changes necessary to get the build working again. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-02 11:26 Message: Logged In: YES user_id=21627 The patch looks fine to me. A few comments: - Why did you drop Tkinter support? - The symbol list in python.def is way too short. Essentially, every function that has a DL_IMPORT in Include/* must be listed in the .def file (or, if not - why is the .def file necessary in the first place?) For example, all the Unicode functions are missing. ---------------------------------------------------------------------- Comment By: Michael Muller (mikemuller) Date: 2001-10-30 10:46 Message: Logged In: YES user_id=353708 1) "#ifdef __BEOS__" vs. "#if defined(__BEOS_)" This is not necessary. I was under the mistaken impression that #ifdef ... #elif caused problems under VAC++. 3) positive case first I agree. I have posted another patch which addresses these issues. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2001-10-30 04:50 Message: Logged In: YES user_id=250749 1) in Modules/socketmodule.c, is changing "#ifdef __BEOS__" to "#if defined(__BEOS__)" absolutely necessary? While I would also do this, others view such apparently cosmetic changes with suspicion. 2) the changes to the files in PC/os2vacpp look OK. 3) in Python/bltinmodule.c, I would have suggested using #if #else #endif rather than #if ! #else #endif Negated #ifdefs seem to be considerably in the minority in the Python source tree AFAICS. 4) change to Python/importdl.h is OK as its in an #ifdef OS2 The changes noted in 2) & 4) look good to go. Feedback from anyone else about the stylistics noted in 1) & 3)? ---------------------------------------------------------------------- Comment By: Michael Muller (mikemuller) Date: 2001-10-26 05:37 Message: Logged In: YES user_id=353708 Resubmitted to resolve conflict with changes to bltinmodule.c ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473749&group_id=5470 From noreply@sourceforge.net Fri Nov 2 21:47:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 02 Nov 2001 13:47:29 -0800 Subject: [Patches] [ python-Patches-476612 ] Make md5/sha/hmac match PEP 247 Message-ID: Patches item #476612, was opened at 2001-10-30 18:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476612&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: A.M. Kuchling (akuchling) Summary: Make md5/sha/hmac match PEP 247 Initial Comment: This patch makes the interfaces of the md5, sha, and hmac modules match that described in PEP 247. For md5 and sha, the patch just adds digest_size attributes (in addition to the existing digestsize :(). For hmac it does the same, and also makes the .copy() method work. The patch to hmac.py should be reviewed by Gerhard Haring; the other bits of the patch are trivial and just need a quick skim from someone to catch any dopey thinkos. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-11-02 13:47 Message: Logged In: YES user_id=11375 Thanks! Checked in... ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-11-02 13:30 Message: Logged In: YES user_id=35752 Looks good to me. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-11-02 12:12 Message: Logged In: YES user_id=11375 Randomly assigning to Neil for a quick skim. (Don't bother proofreading the hmac.py changes; the original author has a different patch.) ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2001-11-01 15:54 Message: Logged In: YES user_id=163326 I've reviewed the hmac changes. Unfortunately, the copy method was more broken than you thought ;-) I've fixed this in patch #477336 and also submitted an extensive testsuite for hmac there. This patch also contains your changes to hmac.py. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-10-30 18:44 Message: Logged In: YES user_id=11375 Attaching Lib/test/test_pep247.py, which checks the three included hashing modules for compliance with PEP247. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476612&group_id=5470 From noreply@sourceforge.net Fri Nov 2 21:50:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 02 Nov 2001 13:50:41 -0800 Subject: [Patches] [ python-Patches-477336 ] hmac module bugfixes and testsuite Message-ID: Patches item #477336, was opened at 2001-11-01 15:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477336&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gerhard Häring (ghaering) Assigned to: A.M. Kuchling (akuchling) Summary: hmac module bugfixes and testsuite Initial Comment: This is a followup to A.M. Kuchling's patch #476612. SF doesn't allow me to upload files there, so here's a new patch. It includes - his fixes wrt to PEP 247 compliance for the hmac module. - a fix for the copy method of the HMAC class; this one was totally broken - an extensive PyUnit based testsuite for the hmac module; the check with the test vectors was also moved from hmac.py to test_hmac.py ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-11-02 13:50 Message: Logged In: YES user_id=11375 Checked in as test_hmac.py rev. 1.2 and hmac.py rev. 1.3 ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-11-02 13:27 Message: Logged In: YES user_id=11375 The patch looks good. One minor thing: after the patch, hmac.py's if __name__ == "__main__" tries to call the non-existent test() function; I'll simply delete it. Checking in this patch will have to wait until #476612 gets checked in. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-11-02 12:01 Message: Logged In: YES user_id=11375 I'll review this patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477336&group_id=5470 From noreply@sourceforge.net Fri Nov 2 21:51:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 02 Nov 2001 13:51:15 -0800 Subject: [Patches] [ python-Patches-467650 ] Add some --without-* options to setup.py Message-ID: Patches item #467650, was opened at 2001-10-03 14:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467650&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Ward (gward) Assigned to: A.M. Kuchling (akuchling) Summary: Add some --without-* options to setup.py Initial Comment: setup.py is a little too brittle in that it hardcodes paths like /usr/local, /usr/local/ssl/lib, etc. It also tends to assume that if a libssl.a exists in the filesystem, it can be linked against. If /usr/local is broken, incomplete, incompatible, or what-have-you, this can really screw things up. In the absence of the right solution (finish my autoconf-in-python implementation), this patch is a band-aid fix. It adds --without-usrlocal and --without-ssl options to the custom build_ext command used in Python's setup.py. detect_modules() respects these options in a fairly obvious way. Andrew, I'm assigning this to you because you wrote this setup script in the first place. Don't check it in yet; I'm going to bring this up on python-dev and see what everyone things. There are a other ways to do this. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-11-02 13:51 Message: Logged In: YES user_id=11375 Greg, did you get any reactions to this patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467650&group_id=5470 From noreply@sourceforge.net Fri Nov 2 23:49:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 02 Nov 2001 15:49:32 -0800 Subject: [Patches] [ python-Patches-471120 ] Upgraded Tix.py Message-ID: Patches item #471120, was opened at 2001-10-14 14:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471120&group_id=5470 Category: Tkinter Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Martin v. Löwis (loewis) Summary: Upgraded Tix.py Initial Comment: One minor bugfix to DisplayStyle.cget Improved doc strings. Placeholder classes for classes still to be wrapped. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-11-02 15:49 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as Tix.py 1.5 and NEWS 1.306. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-11-01 19:50 Message: Logged In: YES user_id=33229 The removal of the entry in item_cget is a mistake. Specifically, delete the following lines from the patch: *************** *** 730,736 **** c = self.tk.call(self._w, 'info', 'selection') return self.tk.splitlist(c) ! def item_cget(self, entry, col, opt): return self.tk.call(self._w, 'item', 'cget', entry, col, opt) def item_configure(self, entry, col, cnf={}, **kw): --- 944,950 ---- c = self.tk.call(self._w, 'info', 'selection') return self.tk.splitlist(c) ! def item_cget(self, col, opt): return self.tk.call(self._w, 'item', 'cget', entry, col, opt) I think this patch just fills in gaps rather than adding new features. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-19 05:37 Message: Logged In: YES user_id=6380 I agree this can go in after 2.2b1. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-19 03:41 Message: Logged In: YES user_id=21627 Why does this patch remove the "entry" argument to item_cget? Note that it missed the 2.2b1 branch creation; since it adds new features, it is not clear whether this can go into 2.2 still (IMO it should). ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-10-18 13:27 Message: Logged In: YES user_id=33229 New Tix.py as diff -c 3 new classes wrapped, and tix command added. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-15 12:41 Message: Logged In: YES user_id=21627 Could you please provide the patch as a context (-c) or unified (-u) diff? Also, could you please base it on the latest version of Tix.py (1.4)? Please have a look at http://python.sourceforge.net/sf-faq.html for details. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471120&group_id=5470 From noreply@sourceforge.net Fri Nov 2 23:59:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 02 Nov 2001 15:59:57 -0800 Subject: [Patches] [ python-Patches-474169 ] Fix for OS/2 popen Message-ID: Patches item #474169, was opened at 2001-10-23 10:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=474169&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Michael Muller (mikemuller) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for OS/2 popen Initial Comment: This is a fix for a long-standing bug in the OS/2 implementation of popen(). It definitely is a problem under the Visual Age build: it may also be a problem under the EMX build for similar reasons. The C library fdopen() function tries to lock an internal mutex semaphore. If this is performed in a critical section (as it currently is) and another thread already owns the mutex, the entire python process locks up into a deadly embrace: the fdopen thread is waiting on the semaphore and all other threads are waiting for the fdopen thread to exit the critical section. The fix is simple: just move the fdopen() out of the critical section. The only thing that needs to be there is the dup() and async_system() calls. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-11-02 15:59 Message: Logged In: YES user_id=21627 Thanks for the patch, applied as posixmodule.c 2.207. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2001-10-30 04:22 Message: Logged In: YES user_id=250749 +1 on this, on the basis that:- 1) the changes are only to a section of code in Modules/posixmodule.c included in an #ifdef PYOS_OS2; 2) Michael appears to have a reasonable grasp of the platform specific issue; and is the only VAC++ person handy at the moment; 3) this patch won't have any significant affect on the popen support for the EMX/GCC port to OS/2, which will be #ifdef'ed separately. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=474169&group_id=5470 From noreply@sourceforge.net Sat Nov 3 00:00:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 02 Nov 2001 16:00:48 -0800 Subject: [Patches] [ python-Patches-477162 ] New "access" keyword for mmap Message-ID: Patches item #477162, was opened at 2001-11-01 07:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477162&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Jay T Miller (jaytmiller) Assigned to: Nobody/Anonymous (nobody) >Summary: New "access" keyword for mmap Initial Comment: The attached patch adds a new keyword parameter to mmap which provides a platform independent way of asking for 3 basic kinds of mmaps: readonly, write-through, and copy-on-write. For now, platform independent means UNIX and Win32. A readonly mmap creates a true readonly section of the process memory map, but python level access is guarded so that attempts to write the section (or fetch a writeable buffer) raise a ValueError exception. A readonly mmap is not resizeable. A write-through memory map is both readable and writeable, and updates to the memory are reflected onto the underlying file. A copy-on-write memory map is both readable and writeable, but updates to the memory are *not* reflected on the underlying file. A copy-on-write mmap is not resizeable. The patch modifies mmapodule.c, libmmap.tex, and test_mmap.py. ---------------------------------------------------------------------- Comment By: Jay T Miller (jaytmiller) Date: 2001-11-02 06:15 Message: Logged In: YES user_id=320512 My apologies. Patch #477162 is a duplicate of #477161. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477162&group_id=5470 From noreply@sourceforge.net Sat Nov 3 00:09:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 02 Nov 2001 16:09:00 -0800 Subject: [Patches] [ python-Patches-477161 ] New "access" keyword for mmap Message-ID: Patches item #477161, was opened at 2001-11-01 07:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477161&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jay T Miller (jaytmiller) Assigned to: Nobody/Anonymous (nobody) >Summary: New "access" keyword for mmap Initial Comment: The attached patch adds a new keyword parameter to mmap which provides a platform independent way of asking for 3 basic kinds of mmaps: readonly, write-through, and copy-on-write. For now, platform independent means UNIX and Win32. A readonly mmap creates a true readonly section of the process memory map, but python level access is guarded so that attempts to write the section (or fetch a writeable buffer) raise a ValueError exception. A readonly mmap is not resizeable. A write-through memory map is both readable and writeable, and updates to the memory are reflected onto the underlying file. A copy-on-write memory map is both readable and writeable, but updates to the memory are *not* reflected on the underlying file. A copy-on-write mmap is not resizeable. The patch modifies mmapodule.c, libmmap.tex, and test_mmap.py. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-11-02 16:09 Message: Logged In: YES user_id=21627 Since this patch introduces a significant new feature, I'd recommend to postpone it until after 2.2. The patch itself looks ok, but the following improvements should be made: - indentation is incorrect, please see PEP 7. - the documentation has some typos, ACCES_ -> ACCESS_ - if possible, the documentation should indicate that the additional parameters are new to Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477161&group_id=5470 From noreply@sourceforge.net Sat Nov 3 00:13:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 02 Nov 2001 16:13:07 -0800 Subject: [Patches] [ python-Patches-477330 ] add __slot_docs__ and __slot_types__ Message-ID: Patches item #477330, was opened at 2001-11-01 15:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477330&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael McLay (mclay) Assigned to: Nobody/Anonymous (nobody) Summary: add __slot_docs__ and __slot_types__ Initial Comment: The slot members defined using__slots__ cannot be assigned doc strings in the current implementation. This patch adds the ability to attach doc strings to a slot member by assigning a dictionary to the __slot_docs__ class variable. >>> class B(object): __slots__ = ['a','b','c'] __slot_docs__ = {'a':"the a docstring",'b':"the b doc string"} __slot_types__ = {'a':(int,str), 'c':int, } >>> B.a.__doc__ 'the a docstring' >>> The __slot_types__ class variable adds an optional type constraint for the slot. If a dictionary with a type or list of types is associated with a member name then the isinstance() method will be called on that member when the get and set methods for the member are called. >>> class B(object): __slots__ = ['a','b','c'] __slot_docs__ = {'a':"the a docstring",'b':"the b doc string"} __slot_types__ = {'a':(int,str), 'c':int, } def __getattribute__(self,name): print "help please", name return object.__getattribute__(self, name) >>> class B(object): __slots__ = ['a','b','c'] __slot_docs__ = {'a':"the a docstring",'b':"the b doc string"} __slot_types__ = {'a':(int,str), 'c':int, } >>> b = B() >>> b.a Traceback (most recent call last): File "", line 1, in ? b.a TypeError: The value of B.a is of type . This is not one of the defined slot_types >>> b.a = 4 >>> b.a 4 >>> b.a = 34.3 Traceback (most recent call last): File "", line 1, in ? b.a = 34.3 TypeError: The type of is not one of the defined slot_types for B.a >>> b.b >>> b.b = 3 >>> b.b = 34.2 >>> b.b 34.200000000000003 >>> b.a = "fish" >>> b.a 'fish' >>> ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-11-02 16:13 Message: Logged In: YES user_id=21627 -1. I think there should be proper syntax for slots, which should include support for doc strings. The "optional static typing" part should be coordinated with PEP 245. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477330&group_id=5470 From noreply@sourceforge.net Sat Nov 3 05:14:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 02 Nov 2001 21:14:00 -0800 Subject: [Patches] [ python-Patches-477330 ] add __slot_docs__ and __slot_types__ Message-ID: Patches item #477330, was opened at 2001-11-01 15:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477330&group_id=5470 Category: Core (C code) Group: None Status: Open >Resolution: Postponed Priority: 5 Submitted By: Michael McLay (mclay) Assigned to: Nobody/Anonymous (nobody) Summary: add __slot_docs__ and __slot_types__ Initial Comment: The slot members defined using__slots__ cannot be assigned doc strings in the current implementation. This patch adds the ability to attach doc strings to a slot member by assigning a dictionary to the __slot_docs__ class variable. >>> class B(object): __slots__ = ['a','b','c'] __slot_docs__ = {'a':"the a docstring",'b':"the b doc string"} __slot_types__ = {'a':(int,str), 'c':int, } >>> B.a.__doc__ 'the a docstring' >>> The __slot_types__ class variable adds an optional type constraint for the slot. If a dictionary with a type or list of types is associated with a member name then the isinstance() method will be called on that member when the get and set methods for the member are called. >>> class B(object): __slots__ = ['a','b','c'] __slot_docs__ = {'a':"the a docstring",'b':"the b doc string"} __slot_types__ = {'a':(int,str), 'c':int, } def __getattribute__(self,name): print "help please", name return object.__getattribute__(self, name) >>> class B(object): __slots__ = ['a','b','c'] __slot_docs__ = {'a':"the a docstring",'b':"the b doc string"} __slot_types__ = {'a':(int,str), 'c':int, } >>> b = B() >>> b.a Traceback (most recent call last): File "", line 1, in ? b.a TypeError: The value of B.a is of type . This is not one of the defined slot_types >>> b.a = 4 >>> b.a 4 >>> b.a = 34.3 Traceback (most recent call last): File "", line 1, in ? b.a = 34.3 TypeError: The type of is not one of the defined slot_types for B.a >>> b.b >>> b.b = 3 >>> b.b = 34.2 >>> b.b 34.200000000000003 >>> b.a = "fish" >>> b.a 'fish' >>> ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-11-02 21:14 Message: Logged In: YES user_id=31435 In Guido's absence (he's on leave the rest of November), I'm Postponing this. Feature cutoff for 2.2 has already occurred, and we've got all we can do (esp. in Guido's absence!) to finish what's already there. I don't even have time to mention that a patch without doc and test case changes is dead on arrival, let alone time to think about it. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-02 16:13 Message: Logged In: YES user_id=21627 -1. I think there should be proper syntax for slots, which should include support for doc strings. The "optional static typing" part should be coordinated with PEP 245. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477330&group_id=5470 From noreply@sourceforge.net Sat Nov 3 10:52:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 03 Nov 2001 02:52:14 -0800 Subject: [Patches] [ python-Patches-477750 ] Use METH_ constants in Modules Message-ID: Patches item #477750, was opened at 2001-11-03 02:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477750&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Jeremy Hylton (jhylton) Summary: Use METH_ constants in Modules Initial Comment: This patch addes METH_OLDARGS and METH_VARARGS into every method table (except for curses, for which a separate patch is upcoming). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477750&group_id=5470 From noreply@sourceforge.net Sat Nov 3 10:56:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 03 Nov 2001 02:56:03 -0800 Subject: [Patches] [ python-Patches-477752 ] Drop old-style getargs from curses Message-ID: Patches item #477752, was opened at 2001-11-03 02:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477752&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Jeremy Hylton (jhylton) Summary: Drop old-style getargs from curses Initial Comment: This patch converts _cursesmodule and _curses_panel into using ParseTuple, METH_VARARGS, METH_NOARGS, and METH_O throughout. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477752&group_id=5470 From noreply@sourceforge.net Sat Nov 3 10:56:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 03 Nov 2001 02:56:39 -0800 Subject: [Patches] [ python-Patches-477750 ] Use METH_ constants in Modules Message-ID: Patches item #477750, was opened at 2001-11-03 02:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477750&group_id=5470 >Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Jeremy Hylton (jhylton) Summary: Use METH_ constants in Modules Initial Comment: This patch addes METH_OLDARGS and METH_VARARGS into every method table (except for curses, for which a separate patch is upcoming). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477750&group_id=5470 From noreply@sourceforge.net Sat Nov 3 13:01:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 03 Nov 2001 05:01:27 -0800 Subject: [Patches] [ python-Patches-473002 ] Update Demo/tix tixwidgets.py et al. Message-ID: Patches item #473002, was opened at 2001-10-19 21:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473002&group_id=5470 Category: Demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Internet Discovery (idiscovery) >Assigned to: Martin v. Löwis (loewis) Summary: Update Demo/tix tixwidgets.py et al. Initial Comment: Updated README and INSTALL for Python 2.1 and tcl 8.3 Removed hardcoded fonts and colors so it will use the natve color scheme. Rewritten tixwidgets.py to make Demo a real class, and to fix a problem under Windows that was leaving undestroyed pythonw.exe running after exit. Added two new samples: DirList and DirTree. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473002&group_id=5470 From noreply@sourceforge.net Sat Nov 3 14:23:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 03 Nov 2001 06:23:15 -0800 Subject: [Patches] [ python-Patches-477161 ] New "access" keyword for mmap Message-ID: Patches item #477161, was opened at 2001-11-01 07:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477161&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jay T Miller (jaytmiller) Assigned to: Nobody/Anonymous (nobody) >Summary: New "access" keyword for mmap Initial Comment: The attached patch adds a new keyword parameter to mmap which provides a platform independent way of asking for 3 basic kinds of mmaps: readonly, write-through, and copy-on-write. For now, platform independent means UNIX and Win32. A readonly mmap creates a true readonly section of the process memory map, but python level access is guarded so that attempts to write the section (or fetch a writeable buffer) raise a ValueError exception. A readonly mmap is not resizeable. A write-through memory map is both readable and writeable, and updates to the memory are reflected onto the underlying file. A copy-on-write memory map is both readable and writeable, but updates to the memory are *not* reflected on the underlying file. A copy-on-write mmap is not resizeable. The patch modifies mmapodule.c, libmmap.tex, and test_mmap.py. ---------------------------------------------------------------------- >Comment By: Jay T Miller (jaytmiller) Date: 2001-11-03 06:23 Message: Logged In: YES user_id=320512 I'll make the improvements pronto. The patch only exposes minor new functionality on Win32 (it's already exposed on UNIX) and should be fully backwards compatible; There is no requirement to use the new optional keyword. Is there any chance for 2.2? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-02 16:09 Message: Logged In: YES user_id=21627 Since this patch introduces a significant new feature, I'd recommend to postpone it until after 2.2. The patch itself looks ok, but the following improvements should be made: - indentation is incorrect, please see PEP 7. - the documentation has some typos, ACCES_ -> ACCESS_ - if possible, the documentation should indicate that the additional parameters are new to Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477161&group_id=5470 From noreply@sourceforge.net Sat Nov 3 16:20:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 03 Nov 2001 08:20:06 -0800 Subject: [Patches] [ python-Patches-476866 ] new improved trace.py Message-ID: Patches item #476866, was opened at 2001-10-31 10:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476866&group_id=5470 Category: Demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Skip Montanaro (montanaro) Summary: new improved trace.py Initial Comment: trace.py didn't work for me with Python 2.2a4+, possibly due to me misunderstanding how to use it. In any case this version is substantially rewritten, uses the debugger hooks that were introduced in Python 2.1(?), and has a simpler (in my opinion) interface. Also there are some new features like "countfuncs" mode which is faster than "count" mode and reports only a list of funcs that were invoked. ---------------------------------------------------------------------- >Comment By: Zooko Ozoko (zooko) Date: 2001-11-03 08:20 Message: Logged In: YES user_id=52562 I'll be happy to add doco about --count, --report, and --file after I return from the O'Reilly p2p conference. (i.e. more than a week from now). Regards, Zooko ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-31 20:08 Message: Logged In: YES user_id=6380 Skip, what do you think of this? In addition, I think there needs to e a doc string explaining what the --count and --report options do, and how the --file option figures. I am completely unable to understand how these interoperate. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476866&group_id=5470 From noreply@sourceforge.net Sat Nov 3 16:40:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 03 Nov 2001 08:40:21 -0800 Subject: [Patches] [ python-Patches-476866 ] new improved trace.py Message-ID: Patches item #476866, was opened at 2001-10-31 10:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476866&group_id=5470 Category: Demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Skip Montanaro (montanaro) Summary: new improved trace.py Initial Comment: trace.py didn't work for me with Python 2.2a4+, possibly due to me misunderstanding how to use it. In any case this version is substantially rewritten, uses the debugger hooks that were introduced in Python 2.1(?), and has a simpler (in my opinion) interface. Also there are some new features like "countfuncs" mode which is faster than "count" mode and reports only a list of funcs that were invoked. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2001-11-03 08:40 Message: Logged In: YES user_id=44345 I'm going to be in Europe on business for the next two weeks. I should have a fair amount of dead time in my hotel room. I'll try to take a look at it then. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-11-03 08:20 Message: Logged In: YES user_id=52562 I'll be happy to add doco about --count, --report, and --file after I return from the O'Reilly p2p conference. (i.e. more than a week from now). Regards, Zooko ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-31 20:08 Message: Logged In: YES user_id=6380 Skip, what do you think of this? In addition, I think there needs to e a doc string explaining what the --count and --report options do, and how the --file option figures. I am completely unable to understand how these interoperate. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476866&group_id=5470 From noreply@sourceforge.net Sat Nov 3 19:04:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 03 Nov 2001 11:04:11 -0800 Subject: [Patches] [ python-Patches-467650 ] Add some --without-* options to setup.py Message-ID: Patches item #467650, was opened at 2001-10-03 14:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467650&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Ward (gward) Assigned to: A.M. Kuchling (akuchling) Summary: Add some --without-* options to setup.py Initial Comment: setup.py is a little too brittle in that it hardcodes paths like /usr/local, /usr/local/ssl/lib, etc. It also tends to assume that if a libssl.a exists in the filesystem, it can be linked against. If /usr/local is broken, incomplete, incompatible, or what-have-you, this can really screw things up. In the absence of the right solution (finish my autoconf-in-python implementation), this patch is a band-aid fix. It adds --without-usrlocal and --without-ssl options to the custom build_ext command used in Python's setup.py. detect_modules() respects these options in a fairly obvious way. Andrew, I'm assigning this to you because you wrote this setup script in the first place. Don't check it in yet; I'm going to bring this up on python-dev and see what everyone things. There are a other ways to do this. ---------------------------------------------------------------------- >Comment By: Greg Ward (gward) Date: 2001-11-03 11:04 Message: Logged In: YES user_id=14422 Martin von Loewis really didn't like this idea: http://mail.python.org/pipermail/python-dev/2001-October/017746.html In retrospect, I think he's right. I also think that hardcoding /usr/local into setup.py is sub-optimal, but fixing it right would be a lot of work. Sigh. Editing Modules/Setup.local now seems to work for me, so I think this patch can safely be refused. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-11-02 13:51 Message: Logged In: YES user_id=11375 Greg, did you get any reactions to this patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467650&group_id=5470 From noreply@sourceforge.net Sat Nov 3 19:59:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 03 Nov 2001 11:59:56 -0800 Subject: [Patches] [ python-Patches-477059 ] __del__ on new classes vs. GC Message-ID: Patches item #477059, was opened at 2001-10-31 20:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477059&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Neil Schemenauer (nascheme) Summary: __del__ on new classes vs. GC Initial Comment: Neil, excuse me for the assignment. You can reassign this to Tim if you don't have time; I know *I* won't get to it in time for 2.2b2. I recently added __del__ for new-style classes, but I believe this would require the same kind of exception from the GC code as classic instances with a __del__ handler. Of course, it's a bit more difficult since *any* heap-based type can have a __del__ handler... ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-11-03 11:59 Message: Logged In: YES user_id=31435 I added docs and news about the change to gc.garbage, in Doc/lib/libgc.tex; new revision: 1.6 Misc/NEWS; new revision: 1.308 So I'm closing this patch; the other stuff in Guido's comments should get filed as feature requests. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-01 11:49 Message: Logged In: YES user_id=6380 Neil, thanks for fixing my broken checkin. I think it still needs a documentation change: the meaning of the variable gc.garbage has changed. In a discussion before lunch, Tim suggested that when Python exits (or better, in Py_Finalize()) a check could be made if there is any garbage in gc.garbage, and if so, a warning about this should be printed to stderr. That seems a nice feature. In that same discussion, I realized that the module cleanup behavior (where all globals in a module are set to None when the module object is deallocated) is probably no longer necessary now that we have GC. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-01 09:03 Message: Logged In: YES user_id=31435 In Guido's example, if we assume the cycle will never ever get broken by the user, then reclaiming the X instances would be cool: we know they're trash, and they're not themselves in a cycle. The rub is that it's a bad assumption -- despite that the cycle is unreachable, it can still be gotten at, by the user, via gc's list of unreclaimable trash. My model for what people should do is: 1. Don't create cycles with __del__ methods. 2. If you do, cleam 'em up yourself (and gc exposes the unreclaimable cycles, so that's quite doable even *after* the cycles become "unreachable"). So long as we expose unreclaimable cycles, nothing in a cycle is *truly* unreachable, and that makes deleting the X instances by magic dangerous (the user may break the cycle themself, and a destructor in one of the cycle members may need to access an intact X). ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-11-01 08:45 Message: Logged In: YES user_id=35752 We seem to have our messages passing each other in flight. :-) In your example you don't see X.__del__ because the C instances are never freed. We can't call tp_clear on either of the C instances because we can't choose an ordering that ensures their __del__ methods will work. For example, if we clear "a" first but b.__del__ uses some attributes of "a" then we will get an exception. I suppose we could have an option that says "call tp_clear on unreachable objects even if they have finalizers". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-01 08:39 Message: Logged In: YES user_id=6380 I guess I misunderstood what you said before. Never mind. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-11-01 08:30 Message: Logged In: YES user_id=35752 Anything with a finalizer (i.e. __del__ method) or reachable from a finalizer does not get tp_clear called on it. We discussed this at length when the GC was being implemented. I don't think anything has changed since then but I'm open to more discussion. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-01 08:16 Message: Logged In: YES user_id=6380 I'll leave this in your & Tim's capable hands. I don't see any proof that tp_clear is being called; or maybe there's no tp_clear for new-style instances. I ran this script: import gc class C(object): def __del__(self): print "C.__del__" class X(object): def __del__(self): print "X.__del__" a = C() a.x = X() b = C() b.x = X() a.b = b b.a = a del a, b gc.collect() Before the change I checked in this morning (but after adding __del__, obviously), this printed X.__del__ C.__del__ C.__del__ X.__del__ Now it prints nothing. I somehow had expected this X.__del__ X.__del__ since the X instanes are not contributing to the cycle -- they are merely hanging off its sides. I probably misunderstand something. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-11-01 07:50 Message: Logged In: YES user_id=35752 This is not too serious of a problem and shouldn't be hard to fix. If we don't do anything then the result will be that unreachable new-style classes will get tp_clear called on them even if they have __del__ methods. As Tim suggests, fixing this should be a matter of removing some PyInstance_Check tests. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-01 06:26 Message: Logged In: YES user_id=6380 Thanks -- I thought it would probably shallow but wasn't sure. I've fixed this now. Do I understand correctly that objects with a __del__ attribute are not GC'ed at all (if part of a cycle)? Isn't that sad? Shouldn't we at least attempt to recover the memory without calling the finalizers? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-31 22:13 Message: Logged In: YES user_id=31435 Guido, I expect this is shallow, confined to move_finalizers (). It's looking for objects that both (a) have a "__del__" attr, and (b) pass PyInstance_Check(). An instance of a new-style class with __del__ passes the former test but not the latter, and I believe that's all the repair needed (but am blanking out on exactly what should be checked instead -- it will occur to me overnight -- I assume the existing PyInstance_Check is really just trying to avoid the expense of general PyObject_HasAttr when the latter has no chance of succeeding). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477059&group_id=5470 From noreply@sourceforge.net Sun Nov 4 11:53:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 04 Nov 2001 03:53:03 -0800 Subject: [Patches] [ python-Patches-477161 ] New "access" keyword for mmap Message-ID: Patches item #477161, was opened at 2001-11-01 07:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477161&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jay T Miller (jaytmiller) Assigned to: Nobody/Anonymous (nobody) >Summary: New "access" keyword for mmap Initial Comment: The attached patch adds a new keyword parameter to mmap which provides a platform independent way of asking for 3 basic kinds of mmaps: readonly, write-through, and copy-on-write. For now, platform independent means UNIX and Win32. A readonly mmap creates a true readonly section of the process memory map, but python level access is guarded so that attempts to write the section (or fetch a writeable buffer) raise a ValueError exception. A readonly mmap is not resizeable. A write-through memory map is both readable and writeable, and updates to the memory are reflected onto the underlying file. A copy-on-write memory map is both readable and writeable, but updates to the memory are *not* reflected on the underlying file. A copy-on-write mmap is not resizeable. The patch modifies mmapodule.c, libmmap.tex, and test_mmap.py. ---------------------------------------------------------------------- >Comment By: Jay T Miller (jaytmiller) Date: 2001-11-04 03:53 Message: Logged In: YES user_id=320512 I created a 2nd generation patch which addresses the following: 1. mmapmodule.c is indented according to PEP-7. 2. documentation typos are corrected and the prose is more direct. 3. exception class for readonly access violations changed from ValueError to TypeError. (Thanks Tim!) ---------------------------------------------------------------------- Comment By: Jay T Miller (jaytmiller) Date: 2001-11-03 06:23 Message: Logged In: YES user_id=320512 I'll make the improvements pronto. The patch only exposes minor new functionality on Win32 (it's already exposed on UNIX) and should be fully backwards compatible; There is no requirement to use the new optional keyword. Is there any chance for 2.2? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-02 16:09 Message: Logged In: YES user_id=21627 Since this patch introduces a significant new feature, I'd recommend to postpone it until after 2.2. The patch itself looks ok, but the following improvements should be made: - indentation is incorrect, please see PEP 7. - the documentation has some typos, ACCES_ -> ACCESS_ - if possible, the documentation should indicate that the additional parameters are new to Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477161&group_id=5470 From noreply@sourceforge.net Mon Nov 5 02:40:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 04 Nov 2001 18:40:57 -0800 Subject: [Patches] [ python-Patches-473749 ] compile under OS/2 VA C++ Message-ID: Patches item #473749, was opened at 2001-10-22 12:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473749&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Muller (mikemuller) >Assigned to: Tim Peters (tim_one) Summary: compile under OS/2 VA C++ Initial Comment: This is the minimal set of changes I found necessary to get the latest Python CVS image built under OS/2 Visual Age C++. I'm pretty sure that some of these changes will conflict with changes submitted by Andrew MacIntyre for OS/2 EMX. If his changes are checked in before mine, I'd be happy to resolve the conflicts and resubmit this patch. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-11-04 18:40 Message: Logged In: YES user_id=31435 Assigned to me. ---------------------------------------------------------------------- Comment By: Michael Muller (mikemuller) Date: 2001-11-02 13:35 Message: Logged In: YES user_id=353708 > - Why did you drop Tkinter support? Because AFAIK it doesn't work. I asked Jeff Rush about this back in the 1.5.2 days, and I think he said that he had gotten it to compile but was not able to run it. I had similar experiences linking directly against the Tcl/Tk libraries that have been distributed for OS/2. I have just sent him a note to confirm this. I have released 1.5.1 and 1.5.2 versions of Tkinter for OS/2 based on heavily hacked versions of the EMX Tcl/Tk port and of _tkinter.c itself. I'd like to see it back in the main build, but I don't really have the time to make that happen right now, so I hope to distribute Tkinter-OS/2 seperately again for 2.1.1 (and probably 2.2 as well). > - The symbol list in python.def is way too short. As I said, this was the minimal set of changes necessary to compile. When I came up with an "unresolved external" linking python and PGen, I added the unresolved function name to the def file. What I'd like to do (and have been experimenting with in 2.1.1) is to generate the def file automatically from the object modules. However, it seemed to me that restructuring the makefile goes way beyond the minimal changes necessary to get the build working again. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-02 11:26 Message: Logged In: YES user_id=21627 The patch looks fine to me. A few comments: - Why did you drop Tkinter support? - The symbol list in python.def is way too short. Essentially, every function that has a DL_IMPORT in Include/* must be listed in the .def file (or, if not - why is the .def file necessary in the first place?) For example, all the Unicode functions are missing. ---------------------------------------------------------------------- Comment By: Michael Muller (mikemuller) Date: 2001-10-30 10:46 Message: Logged In: YES user_id=353708 1) "#ifdef __BEOS__" vs. "#if defined(__BEOS_)" This is not necessary. I was under the mistaken impression that #ifdef ... #elif caused problems under VAC++. 3) positive case first I agree. I have posted another patch which addresses these issues. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2001-10-30 04:50 Message: Logged In: YES user_id=250749 1) in Modules/socketmodule.c, is changing "#ifdef __BEOS__" to "#if defined(__BEOS__)" absolutely necessary? While I would also do this, others view such apparently cosmetic changes with suspicion. 2) the changes to the files in PC/os2vacpp look OK. 3) in Python/bltinmodule.c, I would have suggested using #if #else #endif rather than #if ! #else #endif Negated #ifdefs seem to be considerably in the minority in the Python source tree AFAICS. 4) change to Python/importdl.h is OK as its in an #ifdef OS2 The changes noted in 2) & 4) look good to go. Feedback from anyone else about the stylistics noted in 1) & 3)? ---------------------------------------------------------------------- Comment By: Michael Muller (mikemuller) Date: 2001-10-26 05:37 Message: Logged In: YES user_id=353708 Resubmitted to resolve conflict with changes to bltinmodule.c ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473749&group_id=5470 From noreply@sourceforge.net Mon Nov 5 02:48:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 04 Nov 2001 18:48:10 -0800 Subject: [Patches] [ python-Patches-473749 ] compile under OS/2 VA C++ Message-ID: Patches item #473749, was opened at 2001-10-22 12:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473749&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Michael Muller (mikemuller) Assigned to: Tim Peters (tim_one) Summary: compile under OS/2 VA C++ Initial Comment: This is the minimal set of changes I found necessary to get the latest Python CVS image built under OS/2 Visual Age C++. I'm pretty sure that some of these changes will conflict with changes submitted by Andrew MacIntyre for OS/2 EMX. If his changes are checked in before mine, I'd be happy to resolve the conflicts and resubmit this patch. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-11-04 18:48 Message: Logged In: YES user_id=31435 Patch accepted, with thanks, and checked in: Modules/socketmodule.c; new revision: 1.193 PC/os2vacpp/config.c; new revision: 1.7 PC/os2vacpp/makefile; new revision: 1.5 PC/os2vacpp/pyconfig.h; new revision: 1.3 PC/os2vacpp/python.def; new revision: 1.4 Python/bltinmodule.c; new revision: 2.244 Python/importdl.h; new revision: 2.17 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-04 18:40 Message: Logged In: YES user_id=31435 Assigned to me. ---------------------------------------------------------------------- Comment By: Michael Muller (mikemuller) Date: 2001-11-02 13:35 Message: Logged In: YES user_id=353708 > - Why did you drop Tkinter support? Because AFAIK it doesn't work. I asked Jeff Rush about this back in the 1.5.2 days, and I think he said that he had gotten it to compile but was not able to run it. I had similar experiences linking directly against the Tcl/Tk libraries that have been distributed for OS/2. I have just sent him a note to confirm this. I have released 1.5.1 and 1.5.2 versions of Tkinter for OS/2 based on heavily hacked versions of the EMX Tcl/Tk port and of _tkinter.c itself. I'd like to see it back in the main build, but I don't really have the time to make that happen right now, so I hope to distribute Tkinter-OS/2 seperately again for 2.1.1 (and probably 2.2 as well). > - The symbol list in python.def is way too short. As I said, this was the minimal set of changes necessary to compile. When I came up with an "unresolved external" linking python and PGen, I added the unresolved function name to the def file. What I'd like to do (and have been experimenting with in 2.1.1) is to generate the def file automatically from the object modules. However, it seemed to me that restructuring the makefile goes way beyond the minimal changes necessary to get the build working again. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-02 11:26 Message: Logged In: YES user_id=21627 The patch looks fine to me. A few comments: - Why did you drop Tkinter support? - The symbol list in python.def is way too short. Essentially, every function that has a DL_IMPORT in Include/* must be listed in the .def file (or, if not - why is the .def file necessary in the first place?) For example, all the Unicode functions are missing. ---------------------------------------------------------------------- Comment By: Michael Muller (mikemuller) Date: 2001-10-30 10:46 Message: Logged In: YES user_id=353708 1) "#ifdef __BEOS__" vs. "#if defined(__BEOS_)" This is not necessary. I was under the mistaken impression that #ifdef ... #elif caused problems under VAC++. 3) positive case first I agree. I have posted another patch which addresses these issues. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2001-10-30 04:50 Message: Logged In: YES user_id=250749 1) in Modules/socketmodule.c, is changing "#ifdef __BEOS__" to "#if defined(__BEOS__)" absolutely necessary? While I would also do this, others view such apparently cosmetic changes with suspicion. 2) the changes to the files in PC/os2vacpp look OK. 3) in Python/bltinmodule.c, I would have suggested using #if #else #endif rather than #if ! #else #endif Negated #ifdefs seem to be considerably in the minority in the Python source tree AFAICS. 4) change to Python/importdl.h is OK as its in an #ifdef OS2 The changes noted in 2) & 4) look good to go. Feedback from anyone else about the stylistics noted in 1) & 3)? ---------------------------------------------------------------------- Comment By: Michael Muller (mikemuller) Date: 2001-10-26 05:37 Message: Logged In: YES user_id=353708 Resubmitted to resolve conflict with changes to bltinmodule.c ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473749&group_id=5470 From noreply@sourceforge.net Mon Nov 5 03:10:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 04 Nov 2001 19:10:42 -0800 Subject: [Patches] [ python-Patches-477161 ] New "access" keyword for mmap Message-ID: Patches item #477161, was opened at 2001-11-01 07:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477161&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jay T Miller (jaytmiller) >Assigned to: Barry Warsaw (bwarsaw) >Summary: New "access" keyword for mmap Initial Comment: The attached patch adds a new keyword parameter to mmap which provides a platform independent way of asking for 3 basic kinds of mmaps: readonly, write-through, and copy-on-write. For now, platform independent means UNIX and Win32. A readonly mmap creates a true readonly section of the process memory map, but python level access is guarded so that attempts to write the section (or fetch a writeable buffer) raise a ValueError exception. A readonly mmap is not resizeable. A write-through memory map is both readable and writeable, and updates to the memory are reflected onto the underlying file. A copy-on-write memory map is both readable and writeable, but updates to the memory are *not* reflected on the underlying file. A copy-on-write mmap is not resizeable. The patch modifies mmapodule.c, libmmap.tex, and test_mmap.py. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-11-04 19:10 Message: Logged In: YES user_id=31435 Assigned to Barry in his Release Manager role: accept or postpone? I don't count it as "new feature" -- this is exposing what the platform mmap does, and it was always a flaw (if not a bug) that the Windows implementation didn't expose all the functionality exposed on Unix (Windows can handle it, it seems the original author(s) just didn't realize that). ---------------------------------------------------------------------- Comment By: Jay T Miller (jaytmiller) Date: 2001-11-04 03:53 Message: Logged In: YES user_id=320512 I created a 2nd generation patch which addresses the following: 1. mmapmodule.c is indented according to PEP-7. 2. documentation typos are corrected and the prose is more direct. 3. exception class for readonly access violations changed from ValueError to TypeError. (Thanks Tim!) ---------------------------------------------------------------------- Comment By: Jay T Miller (jaytmiller) Date: 2001-11-03 06:23 Message: Logged In: YES user_id=320512 I'll make the improvements pronto. The patch only exposes minor new functionality on Win32 (it's already exposed on UNIX) and should be fully backwards compatible; There is no requirement to use the new optional keyword. Is there any chance for 2.2? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-02 16:09 Message: Logged In: YES user_id=21627 Since this patch introduces a significant new feature, I'd recommend to postpone it until after 2.2. The patch itself looks ok, but the following improvements should be made: - indentation is incorrect, please see PEP 7. - the documentation has some typos, ACCES_ -> ACCESS_ - if possible, the documentation should indicate that the additional parameters are new to Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477161&group_id=5470 From noreply@sourceforge.net Mon Nov 5 08:16:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 05 Nov 2001 00:16:41 -0800 Subject: [Patches] [ python-Patches-476814 ] foreign-platform newline support Message-ID: Patches item #476814, was opened at 2001-10-31 08:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476814&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) >Assigned to: Jack Jansen (jackjansen) Summary: foreign-platform newline support Initial Comment: This patch enables Python to interpret all known newline conventions, CR, LF or CRLF, on all platforms. This support is enabled by configuring with --with-universal-newlines (so by default it is off, and everything should behave as usual). With universal newline support enabled two things happen: - When importing or otherwise parsing .py files any newline convention is accepted. - Python code can pass a new "t" mode parameter to open() which reads files with any newline convention. "t" cannot be combined with any other mode flags like "w" or "+", for obvious reasons. File objects have a new attribute "newlines" which contains the type of newlines encountered in the file (or None when no newline has been seen, or "mixed" if there were various types of newlines). Also included is a test script which tests both file I/O and parsing. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-11-05 00:16 Message: Logged In: YES user_id=31435 It would be better if get_line just called Py_UniversalNewlineFgets (when appropriate) instead of duplicating its logic inline. Py_UniversalNewlineFgets and Py_UniversalNewlineFread should deal with releasing the global lock themselves -- the correct granularity for lock release/reacquire is around the C-level input routines (esp. for fread). The new routines never check for I/O errors! Why not? It seems essential. The new Fgets checks for EOF at the end of the loop instead of the top. This is surprising, and I stared a long time in vain trying to guess why. Setting newlinetypes |= NEWLINE_CR; immediately after seeing an '\r' would be as fast (instead of waiting to see EOF and then inferring the prior existence of '\r' indirectly from the state of the skipnextlf flag). Speaking of which , the fobj tests in the inner loop waste cycles. Set the local flag vrbls whether or not fobj is NULL. When you're *out* of the inner loop you can simply decline to store the new masks when fobj is NULL (and you're already doing the latter anyway). A test and branch inside the loop is much more expensive than or'ing in a flag bit inside the loop, ditto harder to understand. Floating the univ_newline test out of the loop (and duplicating the loop body, one way for univ_newline true and the other for it false) would also save a test and branch on every character. Doing fread one character at a time is very inefficient. Since you know you need to obtain n characters in the end, and that these transformations require reading at least n characters, you could very profitably read n characters in one gulp at the start, then switch to k at a time where k is the number of \r\n pairs seen since the last fread call. This is easier to code than it sounds . It would be fine by me if you included (and initialized) the new file-object fields all the time, whether or not universal newlines are configured. I'd rather waste a few bytes in a file object than see #ifdefs spread thru the code. I'll be damned if I can think of a quick way to do this stuff on Windows -- native Windows fgets() is still the only Windows handle we have on avoiding crushing thread overhead inside MS's C library. I'll think some more about it (the thrust still being to eliminate the 't' mode flag, as whined about on Python-Dev). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-31 09:38 Message: Logged In: YES user_id=6380 Tim, can you review this or pass it on to someone else who has time? Jack developed this patch after a discussion in which I was involved in some of the design, but I won't have time to look at it until December. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476814&group_id=5470 From noreply@sourceforge.net Mon Nov 5 13:48:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 05 Nov 2001 05:48:58 -0800 Subject: [Patches] [ python-Patches-467650 ] Add some --without-* options to setup.py Message-ID: Patches item #467650, was opened at 2001-10-03 14:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467650&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Greg Ward (gward) Assigned to: A.M. Kuchling (akuchling) Summary: Add some --without-* options to setup.py Initial Comment: setup.py is a little too brittle in that it hardcodes paths like /usr/local, /usr/local/ssl/lib, etc. It also tends to assume that if a libssl.a exists in the filesystem, it can be linked against. If /usr/local is broken, incomplete, incompatible, or what-have-you, this can really screw things up. In the absence of the right solution (finish my autoconf-in-python implementation), this patch is a band-aid fix. It adds --without-usrlocal and --without-ssl options to the custom build_ext command used in Python's setup.py. detect_modules() respects these options in a fairly obvious way. Andrew, I'm assigning this to you because you wrote this setup script in the first place. Don't check it in yet; I'm going to bring this up on python-dev and see what everyone things. There are a other ways to do this. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-11-05 05:48 Message: Logged In: YES user_id=11375 Rejecting this patch on Greg's say-so. ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2001-11-03 11:04 Message: Logged In: YES user_id=14422 Martin von Loewis really didn't like this idea: http://mail.python.org/pipermail/python-dev/2001-October/017746.html In retrospect, I think he's right. I also think that hardcoding /usr/local into setup.py is sub-optimal, but fixing it right would be a lot of work. Sigh. Editing Modules/Setup.local now seems to work for me, so I think this patch can safely be refused. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-11-02 13:51 Message: Logged In: YES user_id=11375 Greg, did you get any reactions to this patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467650&group_id=5470 From noreply@sourceforge.net Mon Nov 5 17:28:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 05 Nov 2001 09:28:52 -0800 Subject: [Patches] [ python-Patches-478374 ] __class_init__ method for classes Message-ID: Patches item #478374, was opened at 2001-11-05 09:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=478374&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: __class_init__ method for classes Initial Comment: ExtensionClass did include a __class_init__ class- method, which has been called at the end of class creation. I've uploaded a (simple minded) patch to fileobject.c, which implements the same behaviour for new style classes. It is simple minded because it only iterates over the tp_base member and not over tp_bases. Any chance this could be included in Python 2.2? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=478374&group_id=5470 From jose@sferacarta.com Tue Nov 6 09:52:23 2001 From: jose@sferacarta.com (jose) Date: Tue, 06 Nov 2001 10:52:23 +0100 Subject: [Patches] Having a builtin exit function in python Message-ID: <3BE7B2D7.3080605@sferacarta.com> Hi, I don't know if this is the right mailing list to send this message, anyway, I'm having the following problem and maybe I'm not the only one. I think this interest every else programming with curses or slang. As you know these libraries change the terminal to the raw mode, and if your program aborts before it restores the terminal mode, the EOF character is changed. Take a look... Python 2.0 (#3, Nov 3 2000, 13:02:11) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "copyright", "credits" or "license" for more information. >>> quit 'Use Ctrl-D (i.e. EOF) to exit.' >>> ^D File "", line 1 ^ SyntaxError: invalid syntax >>> exit 'Use Ctrl-D (i.e. EOF) to exit.' >>> import sys >>> sys.exit(0) ----------------------------------------------------------------------- How to solve this problem: Why not to print the way to exit from python in like this... Python 2.0 (#3, Nov 3 2000, 13:02:11) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "copyright", "credits" or "license" for more information. Type quit() or Ctrl-D (i.e. EOF) to exit. and modify site.py like this... # Define new built-ins 'quit' and 'exit'. # These are simply strings that display a hint on how to exit. #if os.sep == ':': # exit = 'Use Cmd-Q to exit.' #elif os.sep == '\\': # exit = 'Use Ctrl-Z plus Return to exit.' #else: # exit = 'Use Ctrl-D (i.e. EOF) to exit.' import __builtin__ __builtin__.exit = __builtin__.quit = sys.exit #del exit I think it whould be very useful to have a builtin function quit() or exit() to avoid to import the sys module to exit from python. site.py already imports sys module, why I have to import it again? I modified site.py in my system. What about to have this modify in the official release? Best regards Jose Soares From noreply@sourceforge.net Tue Nov 6 13:23:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 06 Nov 2001 05:23:49 -0800 Subject: [Patches] [ python-Patches-478654 ] Add Choose_Directory -> tkFileDialog Message-ID: Patches item #478654, was opened at 2001-11-06 05:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=478654&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Benjamin Schollnick (bscholln) Assigned to: Nobody/Anonymous (nobody) Summary: Add Choose_Directory -> tkFileDialog Initial Comment: Via TkFileDialog we already have the ability to choose file(s), and other objects in Tk Windows... But we have no way to choose a directory without patching the code.... class Directory (_Dialog): command = "tk_chooseDirectory" def choose_directory (**options): return apply(Directory, (), options).show() Added into the tkFileDialog module, will allow us to add this functionality... dir = tkFileDialog.choose_directory() This is needed, to allow installers, etc, to be coded via python in a completely GUI manner, without add- on's, etc. My understanding is, depending on the Tkinter level, the underlying Tkinter code maybe windows dependant. But from the quick glance I made in c.l.tcl, it appears that in the latest version of Tkinter, it's platform neutral. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=478654&group_id=5470 From noreply@sourceforge.net Wed Nov 7 15:08:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 07 Nov 2001 07:08:17 -0800 Subject: [Patches] [ python-Patches-476047 ] Zip importing; do NOT install Message-ID: Patches item #476047, was opened at 2001-10-29 08:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476047&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: James C. Ahlstrom (ahlstromjc) Assigned to: Nobody/Anonymous (nobody) Summary: Zip importing; do NOT install Initial Comment: Here is the zip importing implementation. Do not install, just look at it. A known bug is that a sys.path item "/A/arch.zip/Lib" fails. Patch is against 2.2a3. JimA ---------------------------------------------------------------------- >Comment By: James C. Ahlstrom (ahlstromjc) Date: 2001-11-07 07:08 Message: Logged In: YES user_id=64929 I have attached a second version of the patches to import.c. Do not install this either, but it is closer. The major change is the use of os.listdir() to list the files in directories, and the use of the resultant dictionary entries to speed up imports. Highly interesting is the use of Python module os.listdir() as part of the import process. This means that any Python module could be used as well, thus making possible the replacement of import.c by a custom importer after a boot phase. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-10-30 12:11 Message: Logged In: YES user_id=31392 I wonder if it would be better to do more of the work at the C level, rather than passing everything up to Python. The tuples that describe the ZIP file contents could be C structs and the actual retrieval could be written in C. I suspect it is worthwhile, since our goal is to make imports faster. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476047&group_id=5470 From noreply@sourceforge.net Wed Nov 7 22:39:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 07 Nov 2001 14:39:36 -0800 Subject: [Patches] [ python-Patches-478654 ] Add Choose_Directory -> tkFileDialog Message-ID: Patches item #478654, was opened at 2001-11-06 05:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=478654&group_id=5470 Category: Tkinter Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Benjamin Schollnick (bscholln) Assigned to: Nobody/Anonymous (nobody) Summary: Add Choose_Directory -> tkFileDialog Initial Comment: Via TkFileDialog we already have the ability to choose file(s), and other objects in Tk Windows... But we have no way to choose a directory without patching the code.... class Directory (_Dialog): command = "tk_chooseDirectory" def choose_directory (**options): return apply(Directory, (), options).show() Added into the tkFileDialog module, will allow us to add this functionality... dir = tkFileDialog.choose_directory() This is needed, to allow installers, etc, to be coded via python in a completely GUI manner, without add- on's, etc. My understanding is, depending on the Tkinter level, the underlying Tkinter code maybe windows dependant. But from the quick glance I made in c.l.tcl, it appears that in the latest version of Tkinter, it's platform neutral. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-11-07 14:39 Message: Logged In: YES user_id=21627 Thanks for the patch, applied as tkFileDialog.py 1.3, NEWS 1.310. Notice that I exported the convenience function as "askdirectory". ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=478654&group_id=5470 From noreply@sourceforge.net Wed Nov 7 22:43:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 07 Nov 2001 14:43:35 -0800 Subject: [Patches] [ python-Patches-474532 ] avoid resizes in _PyString_Resize() Message-ID: Patches item #474532, was opened at 2001-10-24 09:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=474532&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Markus F.X.J. Oberhumer (mfx) Assigned to: Nobody/Anonymous (nobody) Summary: avoid resizes in _PyString_Resize() Initial Comment: The patch below (against CVS 2001-10-24) avoids unnecessary calls to PyObject_REALLOC in _PyString_Resize if the size of the string does not change. When running the regression test with this patch on my Linux machine it shows that 53339 out of 323003 resizes can be avoided - this is more than 15%. Additionally I've added sanity checks in _PyStringResize to test for virgin values of ob_shash and ob_sinterned. Better safe than sorry. Markus --- Markus.F.X.J. Oberhumer --- author of PySol ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-11-07 14:43 Message: Logged In: YES user_id=21627 I recommend to reject this patch. If pymalloc is ever enabled by default, it will definitely find out that this is a noop fairly quickly. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-24 15:15 Message: Logged In: YES user_id=31435 Hmm. I'm asking about speed, and you're counting how many calls are made. Not the same thing. I expect a production- quality realloc is doing its own "it's the same size -- I'm done" early-out test, in which case adding a new test to Python every time costs more every time, but the only payback is saving the dirt-cheap realloc calls. It would be much more interesting (to me) to determine why useless calls to _PyString_Resize() are getting made so often in PySol, and optimize those away instead. ---------------------------------------------------------------------- Comment By: Markus F.X.J. Oberhumer (mfx) Date: 2001-10-24 14:54 Message: Logged In: YES user_id=12151 Well, the motivation is that I came across this is that I'm playing around with some malloc implementation where a realloc() is relatively expensive. For some other statistics, starting up and playing PySol for about one minute gives 7400 out of 15800 resizes with the same size, so in this case the gain is almost 50%... And the acutal speed cost is just one "if". The two other checks were only added because they are obviously missing (or maybe _PyString_Resize should reset ob_shash and ob_interned). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-24 12:05 Message: Logged In: YES user_id=31435 Markus, why do you care how ofen realloc is called? More importantly, why should we ? This would be more interesting if you had evidence of a measurable, significant speedup. The test suite runs a lot of peculiar code, and I've got no reason to believe that the 15% difference you saw running that is typical, or even enough to make up for the new costs of the additional failure tests you added here. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=474532&group_id=5470 From noreply@sourceforge.net Thu Nov 8 13:22:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Nov 2001 05:22:05 -0800 Subject: [Patches] [ python-Patches-479551 ] fix complex() with 2 string args Message-ID: Patches item #479551, was opened at 2001-11-08 05:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479551&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: fix complex() with 2 string args Initial Comment: reported on c.l.py >>> complex ("1", "1") (1+0j) >From my reading of the docs, this should fail. Patch does this, adds test case. Assigned to Fred, largely at random. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479551&group_id=5470 From noreply@sourceforge.net Thu Nov 8 15:13:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Nov 2001 07:13:10 -0800 Subject: [Patches] [ python-Patches-479551 ] fix complex() with 2 string args Message-ID: Patches item #479551, was opened at 2001-11-08 05:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479551&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: fix complex() with 2 string args Initial Comment: reported on c.l.py >>> complex ("1", "1") (1+0j) >From my reading of the docs, this should fail. Patch does this, adds test case. Assigned to Fred, largely at random. ---------------------------------------------------------------------- Comment By: Grant Griffin (dspguru) Date: 2001-11-08 07:13 Message: Logged In: YES user_id=70844 I agree with the discussion on c.l.py as to the interpretation of the docs, so it sounds like Michael's patch is a good thing. However, along with the patch, I'd like to see the docs clarified a little. Specifically, it would be nice if the docs stated that the imaginary part (if any) can be specified as part of the string using the standard "j" suffix: ActivePython 2.1.1, build 212 (ActiveState) >>> complex('1+1j') (1+1j) This feature appears to be the reason that a separate imaginary argument was disallowed in the string case, so spelling that aspect out will help people understand (and therefore remember) the rules on this. =g2 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479551&group_id=5470 From noreply@sourceforge.net Thu Nov 8 15:19:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Nov 2001 07:19:45 -0800 Subject: [Patches] [ python-Patches-479615 ] Fast-path for interned string compares Message-ID: Patches item #479615, was opened at 2001-11-08 07:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479615&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: M.-A. Lemburg (lemburg) Summary: Fast-path for interned string compares Initial Comment: This patch adds a fast-path for comparing equality of interned strings. The patch boosts performance for comparing identical string objects by some 20% on my machine while not causing any noticable slow-down for other operations (according to tests done with pybench). More infos and benchmarks later... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479615&group_id=5470 From noreply@sourceforge.net Thu Nov 8 15:26:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Nov 2001 07:26:38 -0800 Subject: [Patches] [ python-Patches-479615 ] Fast-path for interned string compares Message-ID: Patches item #479615, was opened at 2001-11-08 07:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479615&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: M.-A. Lemburg (lemburg) Summary: Fast-path for interned string compares Initial Comment: This patch adds a fast-path for comparing equality of interned strings. The patch boosts performance for comparing identical string objects by some 20% on my machine while not causing any noticable slow-down for other operations (according to tests done with pybench). More infos and benchmarks later... ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-08 07:26 Message: Logged In: YES user_id=38388 Output from pybench comparing today's CVS Python with patch (eqpython) and without patch (stdpython): PYBENCH 1.0 Benchmark: eqpython.bench (rounds=10, warp=20) Tests: per run per oper. diff *) ------------------------------------------------------------------------ BuiltinFunctionCalls: 125.55 ms 0.98 us -1.68% BuiltinMethodLookup: 180.10 ms 0.34 us +1.75% CompareFloats: 107.30 ms 0.24 us +2.04% CompareFloatsIntegers: 185.15 ms 0.41 us -0.05% CompareIntegers: 163.50 ms 0.18 us -1.77% CompareInternedStrings: 79.50 ms 0.16 us -20.78% ^^^^^^^^^^^^^^^^^^^^ This is the interesting line :-) ^^^^^^^^^^^^^^^^^^^^^^^^^^ CompareLongs: 110.25 ms 0.24 us +0.09% CompareStrings: 143.40 ms 0.29 us +2.14% CompareUnicode: 118.00 ms 0.31 us +1.68% ConcatStrings: 189.55 ms 1.26 us -1.61% ConcatUnicode: 226.55 ms 1.51 us +1.34% CreateInstances: 202.35 ms 4.82 us -1.87% CreateStringsWithConcat: 221.00 ms 1.11 us +0.45% CreateUnicodeWithConcat: 240.00 ms 1.20 us +1.27% DictCreation: 213.25 ms 1.42 us +0.47% DictWithFloatKeys: 263.50 ms 0.44 us +1.15% DictWithIntegerKeys: 158.50 ms 0.26 us -1.86% DictWithStringKeys: 147.60 ms 0.25 us +0.75% ForLoops: 144.90 ms 14.49 us -4.64% IfThenElse: 174.15 ms 0.26 us -0.00% ListSlicing: 88.80 ms 25.37 us -1.11% NestedForLoops: 136.95 ms 0.39 us +3.01% NormalClassAttribute: 177.80 ms 0.30 us -2.68% NormalInstanceAttribute: 166.85 ms 0.28 us -0.54% PythonFunctionCalls: 152.20 ms 0.92 us +1.40% PythonMethodCalls: 133.70 ms 1.78 us +1.60% Recursion: 119.45 ms 9.56 us +0.04% SecondImport: 124.65 ms 4.99 us -6.03% SecondPackageImport: 130.70 ms 5.23 us -5.73% SecondSubmoduleImport: 161.65 ms 6.47 us -5.88% SimpleComplexArithmetic: 245.50 ms 1.12 us +2.08% SimpleDictManipulation: 108.50 ms 0.36 us +0.05% SimpleFloatArithmetic: 125.80 ms 0.23 us +0.84% SimpleIntFloatArithmetic: 128.50 ms 0.19 us -1.46% SimpleIntegerArithmetic: 128.45 ms 0.19 us -0.77% SimpleListManipulation: 159.15 ms 0.59 us -5.32% SimpleLongArithmetic: 189.55 ms 1.15 us +2.65% SmallLists: 293.70 ms 1.15 us -5.26% SmallTuples: 230.00 ms 0.96 us +0.44% SpecialClassAttribute: 175.70 ms 0.29 us -2.79% SpecialInstanceAttribute: 199.70 ms 0.33 us -1.55% StringMappings: 196.85 ms 1.56 us -2.48% StringPredicates: 133.00 ms 0.48 us -8.28% StringSlicing: 165.45 ms 0.95 us -3.47% TryExcept: 193.60 ms 0.13 us +0.57% TryRaiseExcept: 175.40 ms 11.69 us +0.69% TupleSlicing: 156.85 ms 1.49 us -0.00% UnicodeMappings: 175.90 ms 9.77 us +1.76% UnicodePredicates: 141.35 ms 0.63 us +0.78% UnicodeProperties: 184.35 ms 0.92 us -2.10% UnicodeSlicing: 179.45 ms 1.03 us -1.10% ------------------------------------------------------------------------ Average round time: 9855.00 ms -1.13% *) measured against: stdpython.bench (rounds=10, warp=20) As you can see, the rest of the results don't change much and the ones that do indicate some additional benefit gained by the patch. All slow-downs are way below the noise limit of around 5-10% (depending the platforms/machine/compiler). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479615&group_id=5470 From noreply@sourceforge.net Thu Nov 8 15:31:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Nov 2001 07:31:52 -0800 Subject: [Patches] [ python-Patches-479551 ] fix complex() with 2 string args Message-ID: Patches item #479551, was opened at 2001-11-08 05:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479551&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: fix complex() with 2 string args Initial Comment: reported on c.l.py >>> complex ("1", "1") (1+0j) >From my reading of the docs, this should fail. Patch does this, adds test case. Assigned to Fred, largely at random. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2001-11-08 07:31 Message: Logged In: YES user_id=44345 I have a slightly different patch. If the first arg is not a string, the second arg can't be a string. The current implementation raises a TypeError with a not entirely comprehensible message, so I added a special case to catch that. Also, my test cases are in test_complex.py instead of test_b1.py and I have some doc changes. (God, I just *loooove* the new diff-mode in XEmacs 21.4. Ya gotta try it -- if you're not a vi-head, that is!) ---------------------------------------------------------------------- Comment By: Grant Griffin (dspguru) Date: 2001-11-08 07:13 Message: Logged In: YES user_id=70844 I agree with the discussion on c.l.py as to the interpretation of the docs, so it sounds like Michael's patch is a good thing. However, along with the patch, I'd like to see the docs clarified a little. Specifically, it would be nice if the docs stated that the imaginary part (if any) can be specified as part of the string using the standard "j" suffix: ActivePython 2.1.1, build 212 (ActiveState) >>> complex('1+1j') (1+1j) This feature appears to be the reason that a separate imaginary argument was disallowed in the string case, so spelling that aspect out will help people understand (and therefore remember) the rules on this. =g2 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479551&group_id=5470 From noreply@sourceforge.net Thu Nov 8 15:47:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Nov 2001 07:47:22 -0800 Subject: [Patches] [ python-Patches-479551 ] fix complex() with 2 string args Message-ID: Patches item #479551, was opened at 2001-11-08 05:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479551&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: fix complex() with 2 string args Initial Comment: reported on c.l.py >>> complex ("1", "1") (1+0j) >From my reading of the docs, this should fail. Patch does this, adds test case. Assigned to Fred, largely at random. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-11-08 07:47 Message: Logged In: YES user_id=6656 Agree with your changes to complexobject.c, though they're not v. different from mine. Your tests reproduce what's in test_b1.py so are probably redunant. I don't think you can read the current docs with your head screwed on and get the wrong idea, but am willing to defer to Fred on that one... What does XEmacs 21.4's diff-mode do that GNU Emacs 21.1's doesn't? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-11-08 07:31 Message: Logged In: YES user_id=44345 I have a slightly different patch. If the first arg is not a string, the second arg can't be a string. The current implementation raises a TypeError with a not entirely comprehensible message, so I added a special case to catch that. Also, my test cases are in test_complex.py instead of test_b1.py and I have some doc changes. (God, I just *loooove* the new diff-mode in XEmacs 21.4. Ya gotta try it -- if you're not a vi-head, that is!) ---------------------------------------------------------------------- Comment By: Grant Griffin (dspguru) Date: 2001-11-08 07:13 Message: Logged In: YES user_id=70844 I agree with the discussion on c.l.py as to the interpretation of the docs, so it sounds like Michael's patch is a good thing. However, along with the patch, I'd like to see the docs clarified a little. Specifically, it would be nice if the docs stated that the imaginary part (if any) can be specified as part of the string using the standard "j" suffix: ActivePython 2.1.1, build 212 (ActiveState) >>> complex('1+1j') (1+1j) This feature appears to be the reason that a separate imaginary argument was disallowed in the string case, so spelling that aspect out will help people understand (and therefore remember) the rules on this. =g2 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479551&group_id=5470 From noreply@sourceforge.net Thu Nov 8 16:02:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Nov 2001 08:02:42 -0800 Subject: [Patches] [ python-Patches-479551 ] fix complex() with 2 string args Message-ID: Patches item #479551, was opened at 2001-11-08 05:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479551&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: fix complex() with 2 string args Initial Comment: reported on c.l.py >>> complex ("1", "1") (1+0j) >From my reading of the docs, this should fail. Patch does this, adds test case. Assigned to Fred, largely at random. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2001-11-08 08:02 Message: Logged In: YES user_id=44345 Yeah, I didn't think they were that different. I had already completed (but not completed testing) my patch when I saw your c.l.py patch. Once I completed testing I simple wrapped it up and uploaded it. I figure Fred can merge our two versions as well as we can. ;-) (As for diff-mode, it's likely the same thing as in Emacs 21.1, but XEmacs 21.1 didn't have a diff mode at all, so I was quite surprised the other day after upgrading to XEmacs 21.4 when I visited a .diff file and had it pop into diff-mode. Today, to create my complex patch, I just cvs diff'd the entire Python tree, edited the file in diff-mode and used M-k/M-n to migrate around, deleting the stuff unrelated to this patch. I didn't have to figure out what lines to cut. When I deleted the last chunk for a particular file it automatically zapped the file's header as well. I was in diff heaven... ;-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-11-08 07:47 Message: Logged In: YES user_id=6656 Agree with your changes to complexobject.c, though they're not v. different from mine. Your tests reproduce what's in test_b1.py so are probably redunant. I don't think you can read the current docs with your head screwed on and get the wrong idea, but am willing to defer to Fred on that one... What does XEmacs 21.4's diff-mode do that GNU Emacs 21.1's doesn't? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-11-08 07:31 Message: Logged In: YES user_id=44345 I have a slightly different patch. If the first arg is not a string, the second arg can't be a string. The current implementation raises a TypeError with a not entirely comprehensible message, so I added a special case to catch that. Also, my test cases are in test_complex.py instead of test_b1.py and I have some doc changes. (God, I just *loooove* the new diff-mode in XEmacs 21.4. Ya gotta try it -- if you're not a vi-head, that is!) ---------------------------------------------------------------------- Comment By: Grant Griffin (dspguru) Date: 2001-11-08 07:13 Message: Logged In: YES user_id=70844 I agree with the discussion on c.l.py as to the interpretation of the docs, so it sounds like Michael's patch is a good thing. However, along with the patch, I'd like to see the docs clarified a little. Specifically, it would be nice if the docs stated that the imaginary part (if any) can be specified as part of the string using the standard "j" suffix: ActivePython 2.1.1, build 212 (ActiveState) >>> complex('1+1j') (1+1j) This feature appears to be the reason that a separate imaginary argument was disallowed in the string case, so spelling that aspect out will help people understand (and therefore remember) the rules on this. =g2 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479551&group_id=5470 From noreply@sourceforge.net Thu Nov 8 18:00:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Nov 2001 10:00:10 -0800 Subject: [Patches] [ python-Patches-479551 ] fix complex() with 2 string args Message-ID: Patches item #479551, was opened at 2001-11-08 05:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479551&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: fix complex() with 2 string args Initial Comment: reported on c.l.py >>> complex ("1", "1") (1+0j) >From my reading of the docs, this should fail. Patch does this, adds test case. Assigned to Fred, largely at random. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-11-08 10:00 Message: Logged In: YES user_id=31435 Note that 2.2 complex also accepts keyword "real" and "imag" arguments; if we're changing the docs anyway, may as well sneak that in too. BTW, I'm really surprised nobody complained about this : >>> complex(1, 1j) 0j >>> Alas, that's "a feature". ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-11-08 08:02 Message: Logged In: YES user_id=44345 Yeah, I didn't think they were that different. I had already completed (but not completed testing) my patch when I saw your c.l.py patch. Once I completed testing I simple wrapped it up and uploaded it. I figure Fred can merge our two versions as well as we can. ;-) (As for diff-mode, it's likely the same thing as in Emacs 21.1, but XEmacs 21.1 didn't have a diff mode at all, so I was quite surprised the other day after upgrading to XEmacs 21.4 when I visited a .diff file and had it pop into diff-mode. Today, to create my complex patch, I just cvs diff'd the entire Python tree, edited the file in diff-mode and used M-k/M-n to migrate around, deleting the stuff unrelated to this patch. I didn't have to figure out what lines to cut. When I deleted the last chunk for a particular file it automatically zapped the file's header as well. I was in diff heaven... ;-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-11-08 07:47 Message: Logged In: YES user_id=6656 Agree with your changes to complexobject.c, though they're not v. different from mine. Your tests reproduce what's in test_b1.py so are probably redunant. I don't think you can read the current docs with your head screwed on and get the wrong idea, but am willing to defer to Fred on that one... What does XEmacs 21.4's diff-mode do that GNU Emacs 21.1's doesn't? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-11-08 07:31 Message: Logged In: YES user_id=44345 I have a slightly different patch. If the first arg is not a string, the second arg can't be a string. The current implementation raises a TypeError with a not entirely comprehensible message, so I added a special case to catch that. Also, my test cases are in test_complex.py instead of test_b1.py and I have some doc changes. (God, I just *loooove* the new diff-mode in XEmacs 21.4. Ya gotta try it -- if you're not a vi-head, that is!) ---------------------------------------------------------------------- Comment By: Grant Griffin (dspguru) Date: 2001-11-08 07:13 Message: Logged In: YES user_id=70844 I agree with the discussion on c.l.py as to the interpretation of the docs, so it sounds like Michael's patch is a good thing. However, along with the patch, I'd like to see the docs clarified a little. Specifically, it would be nice if the docs stated that the imaginary part (if any) can be specified as part of the string using the standard "j" suffix: ActivePython 2.1.1, build 212 (ActiveState) >>> complex('1+1j') (1+1j) This feature appears to be the reason that a separate imaginary argument was disallowed in the string case, so spelling that aspect out will help people understand (and therefore remember) the rules on this. =g2 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479551&group_id=5470 From noreply@sourceforge.net Thu Nov 8 22:57:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Nov 2001 14:57:57 -0800 Subject: [Patches] [ python-Patches-479796 ] Patch for Bug #411612 Message-ID: Patches item #479796, was opened at 2001-11-08 14:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479796&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bryan Fordham (bfordham) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for Bug #411612 Initial Comment: Bug #411612 is the problem that the QUERY_STRING is not checked if the form action=="POST". This is a little patch to add the query string if it's there. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479796&group_id=5470 From noreply@sourceforge.net Fri Nov 9 07:10:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Nov 2001 23:10:14 -0800 Subject: [Patches] [ python-Patches-479898 ] Multibyte string on string::string_print Message-ID: Patches item #479898, was opened at 2001-11-08 23:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479898&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Multibyte string on string::string_print Initial Comment: Many multibyte language users are difficult to see native characters on list or dictionary and etc. This patch allows printing multibyte on UNIX98- compatible machines; mbtowc() is ISO/IEC 9899:1990 standard C-API function. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479898&group_id=5470 From noreply@sourceforge.net Fri Nov 9 08:04:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Nov 2001 00:04:00 -0800 Subject: [Patches] [ python-Patches-478374 ] __class_init__ method for classes Message-ID: Patches item #478374, was opened at 2001-11-05 09:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=478374&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: __class_init__ method for classes Initial Comment: ExtensionClass did include a __class_init__ class- method, which has been called at the end of class creation. I've uploaded a (simple minded) patch to fileobject.c, which implements the same behaviour for new style classes. It is simple minded because it only iterates over the tp_base member and not over tp_bases. Any chance this could be included in Python 2.2? ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2001-11-09 00:04 Message: Logged In: YES user_id=11105 The simple minded approach is probably totally wrong, a better one seems to be to call the __init_class__ class method (if one is found) from within object_init. The attached file object_init.txt contains this patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=478374&group_id=5470 From newsletters@the-financial-news.org Fri Nov 9 15:15:38 2001 From: newsletters@the-financial-news.org (The Financial News) Date: Fri, 9 Nov 2001 16:15:38 +0100 Subject: [Patches] Production Mini-plants in mobile containers Message-ID: This is a multi-part message in MIME format --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The Financial News, November 2001 Production Mini-plants in mobile containers =22...Science Network will supply to countries and developing regions the technology and the necessary support for the production in series of Mini-plants in mobile=20containers (40-foot). The Mini-plant system is designed in such a way that all the production machinery is fixed on the platform of the container, with all wiring,=20piping, and installation parts; that is to say, they are fully equipped... and the mini-plant is ready for production.=22 More than 700 portable production systems: Bakeries, Steel Nails, Welding Electrodes, Tire Retreading, Reinforcement Bar Bending for Construction Framework,=20Sheeting for Roofing, Ceilings and Fa=E7ades, Plated Drums, Aluminum Buckets, Injected Polypropylene Housewares, Pressed Melamine Items (Glasses, Cups,=20Plates, Mugs, etc.), Mufflers, Construction Electrically Welded Mesh, Plastic Bags and Packaging, Mobile units of medical assistance, Sanitary Material,=20Hypodermic Syringes, Hemostatic Clamps, etc.=20 For more information: Mini-plants in mobile containers By Steven P. Leibacher, The Financial News, Editor ------------------------------------------------------------------------- If you received this in error or would like to be removed from our list, please return us indicating: remove or un-subscribe in 'subject' field, Thanks. Editor =A9 2001 The Financial News. All rights reserved. --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The Financial News, November 2001

Production Mini-plants in mobile containers

=22...Science Network will supply to countries and developing regions the technology and the necessary support for the production in series of Mini-plants in mobile containers (40-foot). The Mini-plant system is designed in such a way that all the production machinery is fixed on the platform of the container, with all wiring, piping, and installation parts; that is to say, they are fully equipped... and the mini-plant is ready for production.=22

More than 700 portable production systems: Bakeries, Steel Nails, Welding Electrodes, Tire Retreading, Reinforcement Bar Bending for Construction Framework, Sheeting for Roofing, Ceilings and Façades, Plated Drums, Aluminum Buckets, Injected Polypropylene Housewares, Pressed Melamine Items (Glasses, Cups, Plates, Mugs, etc.), Mufflers, Construction Electrically Welded Mesh, Plastic Bags and Packaging, Mobile units of medical assistance, Sanitary Material, Hypodermic Syringes, Hemostatic Clamps, etc.

For more information: Mini-plants in mobile containers

By Steven P. Leibacher, The Financial News, Editor

-------------------------------------------------------------------------
If you received this in error or would like to be removed from our list, please return us indicating: remove or un-subscribe in 'subject' field, Thanks. Editor
© 2001 The Financial News. All rights reserved.


 --=_NextPart_2rfkindysadvnqw3nerasdf-- From noreply@sourceforge.net Fri Nov 9 16:07:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Nov 2001 08:07:58 -0800 Subject: [Patches] [ python-Patches-466352 ] let mailbox.Maildir tag messages as read Message-ID: Patches item #466352, was opened at 2001-09-29 04:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466352&group_id=5470 Category: Library (Lib) >Group: Python 2.3 Status: Open >Resolution: Postponed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: let mailbox.Maildir tag messages as read Initial Comment: http://c0re.jp/c0de/misc/python-maildir2.patch This patch which changes python's mailbox.Maildir class to move processed messages form new/ to cur/. Although not expicity stated in http://cr.yp.to/proto/maildir.html all applications using Maildirs I'm aware of move messages form new/ to cur/ after the first reading of a message. This patch gives you a way to get the same behaviour in python by giving a third parameter to __init__. See mailbox.Maildir.__init__.__doc__ --drt@un.bewaff.net - http://c0re.jp/ --- Lib-orig/mailbox.py Sat Sep 29 13:03:12 2001 +++ Lib/mailbox.py Sat Sep 29 13:36:36 2001 @@ -201,11 +201,16 @@ class Maildir: - # Qmail directory mailbox + # qmail/maildrop directory mailbox + # see http://cr.yp.to/proto/maildir.html - def __init__(self, dirname, factory=rfc822.Message): + def __init__(self, dirname, factory=rfc822.Message, move=0): + '''if you supply the constructor with a third parameter which is + not equal 0, this class will mark all messages, you processed with + next() as read by moving them from new/ to cur/''' self.dirname = dirname self.factory = factory + self.move = move # check for new mail newdir = os.path.join(self.dirname, 'new') @@ -225,6 +230,11 @@ fn = self.boxes[0] del self.boxes[0] fp = open(fn) + if not self.move == 0: + # if the message is considered new, mark it as seen + (head, tail) = os.path.split(fn) + if(head[-3:] == 'new'): + os.rename(fn, os.path.join(head[:-3], 'cur', tail + ':2,S')) return self.factory(fp) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-09 08:07 Message: Logged In: YES user_id=3066 Since this is clearly a new feature for the library and we didn't get to it in time for the Python 2.2 betas, I'm marking this postponed and adding it to the Python 2.3 group. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-10-18 15:55 Message: Logged In: YES user_id=12800 Assigning back to Fred because he was the last person to put his finger on his nose (see him volunteer in his comment of 2001-10-01 below :) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-10-03 11:18 Message: Logged In: NO fdrakes suggestion seems to me like a very sound suggestion. It is a much cleaner general approach than my hacke-to-solve-my actual problem. In my opinion on medium sight Python should support full read and write access to mailboxes, because that are the batteries of mail handling. If there is a good sugestion for an clean interface for that I would be happy to do the Maildir implementation. --drt@un.bewaff.net ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-01 09:19 Message: Logged In: YES user_id=3066 Guido: I understood that part; my comment was unclear. I certainly think the patch as proposed isn't a bad thing, but its only useful for a specific range of applications. Abstracting it differently could make it more widely applicable without adding a lot to the library. I'll make a different proposal, that may work a little better: we can add a new method for all that mailbox formats that represent each message as a separate file, passing in the name of the file. That method is responsible for opening the file and returning the message object (with the default implementation using the registered factory), which next() then returns. An application that needs more than the message object can subclass the mailbox and override that method to do what's needed. That should suffice both for the simple case solved by the patch provided here and many other possible applications as well. If that's reasonable, I'll volunteer to make the patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-01 08:48 Message: Logged In: YES user_id=6380 I'm -0 on this. But Fred, he *did* make it an option unless I misunderstand the "move=0" default arg value. --Guido ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-01 08:44 Message: Logged In: YES user_id=3066 Having this as an option is more reasonable than making it do this by default. It's not at all clear to me that this is the right thing to do; an application may want to search the messages without presenting them to the user, so adding the "seen" flag may not be the right thing. I think it might be better to return a proxy for the message returned by the Message factory which adds methods like get_info() and set_info(s), where s is the new info string. Setting the info string would cause the right renaming to be done. Regardless of mechanism, this would make this module something a little different from the strictly read-only thing it is now. Barry, what do you think? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-30 11:49 Message: Logged In: YES user_id=6380 Fred, what do you think? Is this reasonable? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466352&group_id=5470 From noreply@sourceforge.net Fri Nov 9 16:10:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Nov 2001 08:10:41 -0800 Subject: [Patches] [ python-Patches-409078 ] Doc/lib/libui.tex Message-ID: Patches item #409078, was opened at 2001-03-16 02:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 Category: Documentation Group: None Status: Open Resolution: Later Priority: 4 Submitted By: Internet Discovery (idiscovery) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Doc/lib/libui.tex Initial Comment: Right now, TkInter is in the library reference under Appendix/Undocumented/Frameworks. I think this should come up to be a chapter on User Interface modules. If you agree, here is a starting point for a chapter. The LaTeX may need proofing for the Python macros, as I don't have them installed here. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-09 08:10 Message: Logged In: YES user_id=3066 Status: Some of the material was based Fredrik Lundh's writing and Matt Conway's "Tkinter Life Preserver"; working on getting permissions to use the material before this can be checked in. Without permission, there might not be a chapter on Tk for a while, unless there are volunteers to write new content. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-24 19:18 Message: Logged In: YES user_id=3066 Just a note so this doesn't look like its being ignored: Mike & I have been communicating on working this into material that's closer to being ready for the docs, but it has been slow going simply because neither of us has a lot of time for it right now. Something based on this will be added to the documentation. Mike, would you like to attach the most recent iteration to this patch report on SF so others can review/contribute as well? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-03-29 07:21 Message: Logged In: YES user_id=3066 Mike: you suggested that you could also provide some of the material from your IPC9 paper to flesh out these sections -- do you have time to do the integration, or would someone else need to do it? I see a lot of Tcl code in the paper -- would this be converted to Python as examples? Thanks! ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-20 21:20 Message: Logged In: YES user_id=33229 The "Tix" patches have been resubmitted as #410231, and all of the suggestions here have been incoproated (dynamic loading, package require, Tkinter.Widget.__bases__). But this patch still remains valid even for 2.0.x, as having Tkinter under Appendix/Undocumented/Frameworks is not a good place. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:42 Message: Logged In: YES user_id=33229 Oppen sorry. SF is giving me no data html pages as responses. Anyone else having this problem? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:22 Message: Logged In: YES user_id=21627 Where is the file? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 From noreply@sourceforge.net Fri Nov 9 16:16:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Nov 2001 08:16:36 -0800 Subject: [Patches] [ python-Patches-473265 ] UpdatePairedHandlers nonsensical Message-ID: Patches item #473265, was opened at 2001-10-20 14:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473265&group_id=5470 Category: None Group: None Status: Open >Resolution: Accepted Priority: 7 Submitted By: Martin v. Löwis (loewis) >Assigned to: Martin v. Löwis (loewis) Summary: UpdatePairedHandlers nonsensical Initial Comment: It appears that the implementation of UpdatePairedHandlers is completely non-sensical. To see whether to use the start handler, it tests whether the endHandler is None ??? and to see whether to use the endHandler, it tests the EndElement handler... Unless I'm mistaken, this needs to be fixed ASAP. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-09 08:16 Message: Logged In: YES user_id=3066 Definately; this patch looks good. Please check in & close this patch report. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473265&group_id=5470 From noreply@sourceforge.net Fri Nov 9 17:38:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Nov 2001 09:38:37 -0800 Subject: [Patches] [ python-Patches-478374 ] __class_init__ method for classes Message-ID: Patches item #478374, was opened at 2001-11-05 09:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=478374&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: __class_init__ method for classes Initial Comment: ExtensionClass did include a __class_init__ class- method, which has been called at the end of class creation. I've uploaded a (simple minded) patch to fileobject.c, which implements the same behaviour for new style classes. It is simple minded because it only iterates over the tp_base member and not over tp_bases. Any chance this could be included in Python 2.2? ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2001-11-09 09:38 Message: Logged In: YES user_id=11105 I'll close this, for two reasons: - Neither patch seems working correctly - I can achieve what I want with attribute descriptors This shall teach me not to request new features too early ;- ) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-11-09 00:04 Message: Logged In: YES user_id=11105 The simple minded approach is probably totally wrong, a better one seems to be to call the __init_class__ class method (if one is found) from within object_init. The attached file object_init.txt contains this patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=478374&group_id=5470 From noreply@sourceforge.net Fri Nov 9 17:40:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Nov 2001 09:40:53 -0800 Subject: [Patches] [ python-Patches-478374 ] __class_init__ method for classes Message-ID: Patches item #478374, was opened at 2001-11-05 09:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=478374&group_id=5470 Category: Core (C code) Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: __class_init__ method for classes Initial Comment: ExtensionClass did include a __class_init__ class- method, which has been called at the end of class creation. I've uploaded a (simple minded) patch to fileobject.c, which implements the same behaviour for new style classes. It is simple minded because it only iterates over the tp_base member and not over tp_bases. Any chance this could be included in Python 2.2? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-11-09 09:38 Message: Logged In: YES user_id=11105 I'll close this, for two reasons: - Neither patch seems working correctly - I can achieve what I want with attribute descriptors This shall teach me not to request new features too early ;- ) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-11-09 00:04 Message: Logged In: YES user_id=11105 The simple minded approach is probably totally wrong, a better one seems to be to call the __init_class__ class method (if one is found) from within object_init. The attached file object_init.txt contains this patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=478374&group_id=5470 From noreply@sourceforge.net Fri Nov 9 21:21:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Nov 2001 13:21:10 -0800 Subject: [Patches] [ python-Patches-479898 ] Multibyte string on string::string_print Message-ID: Patches item #479898, was opened at 2001-11-08 23:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479898&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Multibyte string on string::string_print Initial Comment: Many multibyte language users are difficult to see native characters on list or dictionary and etc. This patch allows printing multibyte on UNIX98- compatible machines; mbtowc() is ISO/IEC 9899:1990 standard C-API function. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-11-09 13:21 Message: Logged In: YES user_id=21627 Even though I think this patch is correct in principle, I see a few problems with it: 1. Since it doesn't fix a bug, it probably cannot go into 2.2. 2. There is no autoconf test for mbtowc. You should test this in configure, and then conditionalize your code on HAVE_MBTOWC. 3. There is too much code duplication. Try to find a solution which special-cases the escape codes (\something) only once. For example, you may implement a trivial mbtowc redefinition if mbtowc is not available, and then use mbtowc always. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479898&group_id=5470 From noreply@sourceforge.net Sat Nov 10 13:59:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 10 Nov 2001 05:59:43 -0800 Subject: [Patches] [ python-Patches-473265 ] UpdatePairedHandlers nonsensical Message-ID: Patches item #473265, was opened at 2001-10-20 14:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473265&group_id=5470 Category: None Group: None >Status: Closed Resolution: Accepted Priority: 7 Submitted By: Martin v. Löwis (loewis) Assigned to: Martin v. Löwis (loewis) Summary: UpdatePairedHandlers nonsensical Initial Comment: It appears that the implementation of UpdatePairedHandlers is completely non-sensical. To see whether to use the start handler, it tests whether the endHandler is None ??? and to see whether to use the endHandler, it tests the EndElement handler... Unless I'm mistaken, this needs to be fixed ASAP. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-11-10 05:59 Message: Logged In: YES user_id=21627 Committed as pyexpat.c 2.54. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-09 08:16 Message: Logged In: YES user_id=3066 Definately; this patch looks good. Please check in & close this patch report. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473265&group_id=5470 From noreply@sourceforge.net Sun Nov 11 09:42:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 11 Nov 2001 01:42:41 -0800 Subject: [Patches] [ python-Patches-409078 ] Doc/lib/libui.tex Message-ID: Patches item #409078, was opened at 2001-03-16 02:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 Category: Documentation Group: None Status: Open Resolution: Later Priority: 4 Submitted By: Internet Discovery (idiscovery) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Doc/lib/libui.tex Initial Comment: Right now, TkInter is in the library reference under Appendix/Undocumented/Frameworks. I think this should come up to be a chapter on User Interface modules. If you agree, here is a starting point for a chapter. The LaTeX may need proofing for the Python macros, as I don't have them installed here. ---------------------------------------------------------------------- >Comment By: Internet Discovery (idiscovery) Date: 2001-11-11 01:42 Message: Logged In: YES user_id=33229 This is the updated version of the UI chapter. There's only a line or two from /F's Introduction to Tkinter, if that, so I changed the Tkinter section author to myself, and listed the Intro to Tkinter in the \seealso. I haven't been able to find a valid email for Matt Conway who wrote the Life Preserver, which I had assumed was PD. I still have some ideas for improvements, but this is a starting point. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-09 08:10 Message: Logged In: YES user_id=3066 Status: Some of the material was based Fredrik Lundh's writing and Matt Conway's "Tkinter Life Preserver"; working on getting permissions to use the material before this can be checked in. Without permission, there might not be a chapter on Tk for a while, unless there are volunteers to write new content. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-24 19:18 Message: Logged In: YES user_id=3066 Just a note so this doesn't look like its being ignored: Mike & I have been communicating on working this into material that's closer to being ready for the docs, but it has been slow going simply because neither of us has a lot of time for it right now. Something based on this will be added to the documentation. Mike, would you like to attach the most recent iteration to this patch report on SF so others can review/contribute as well? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-03-29 07:21 Message: Logged In: YES user_id=3066 Mike: you suggested that you could also provide some of the material from your IPC9 paper to flesh out these sections -- do you have time to do the integration, or would someone else need to do it? I see a lot of Tcl code in the paper -- would this be converted to Python as examples? Thanks! ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-20 21:20 Message: Logged In: YES user_id=33229 The "Tix" patches have been resubmitted as #410231, and all of the suggestions here have been incoproated (dynamic loading, package require, Tkinter.Widget.__bases__). But this patch still remains valid even for 2.0.x, as having Tkinter under Appendix/Undocumented/Frameworks is not a good place. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:42 Message: Logged In: YES user_id=33229 Oppen sorry. SF is giving me no data html pages as responses. Anyone else having this problem? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:22 Message: Logged In: YES user_id=21627 Where is the file? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 From noreply@sourceforge.net Sun Nov 11 09:53:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 11 Nov 2001 01:53:38 -0800 Subject: [Patches] [ python-Patches-480562 ] replace __slots__ with addmembers Message-ID: Patches item #480562, was opened at 2001-11-11 01:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480562&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael McLay (mclay) Assigned to: Nobody/Anonymous (nobody) Summary: replace __slots__ with addmembers Initial Comment: This patch replaces the __slots__ syntax in the following example: >>> class B(object): """class B's docstring """ __slots__ = ['a','b','c','d'] The new syntax includes support for docstrings, default values, and optional typechecking (using isinstance). >>> class B(object): """class B's docstring """ a = addmember(types=int, default=56, doc="a docstring") b = addmember(types=int, doc="b's docstring") c = addmember(types=(int,float), default=5.0, doc="c docstring") d = addmember(types=(str,float), default="ham", doc="d docstring") >>> b = B() >>> b.a 56 >>> b.d 'ham' >>> b.b Traceback (most recent call last): File "", line 1, in ? b.b TypeError: The value of B.b is of type 'type'. This is not one of the defined types The addmembers.txt file in the attachment describes the patch in more detail. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480562&group_id=5470 From noreply@sourceforge.net Sun Nov 11 10:21:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 11 Nov 2001 02:21:52 -0800 Subject: [Patches] [ python-Patches-480562 ] replace __slots__ with addmembers Message-ID: Patches item #480562, was opened at 2001-11-11 01:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480562&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael McLay (mclay) Assigned to: Nobody/Anonymous (nobody) Summary: replace __slots__ with addmembers Initial Comment: This patch replaces the __slots__ syntax in the following example: >>> class B(object): """class B's docstring """ __slots__ = ['a','b','c','d'] The new syntax includes support for docstrings, default values, and optional typechecking (using isinstance). >>> class B(object): """class B's docstring """ a = addmember(types=int, default=56, doc="a docstring") b = addmember(types=int, doc="b's docstring") c = addmember(types=(int,float), default=5.0, doc="c docstring") d = addmember(types=(str,float), default="ham", doc="d docstring") >>> b = B() >>> b.a 56 >>> b.d 'ham' >>> b.b Traceback (most recent call last): File "", line 1, in ? b.b TypeError: The value of B.b is of type 'type'. This is not one of the defined types The addmembers.txt file in the attachment describes the patch in more detail. ---------------------------------------------------------------------- >Comment By: Michael McLay (mclay) Date: 2001-11-11 02:21 Message: Logged In: YES user_id=28214 Opps, forgot to check the box for the attachment. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480562&group_id=5470 From noreply@sourceforge.net Sun Nov 11 14:11:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 11 Nov 2001 06:11:09 -0800 Subject: [Patches] [ python-Patches-473002 ] Update Demo/tix tixwidgets.py et al. Message-ID: Patches item #473002, was opened at 2001-10-19 21:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473002&group_id=5470 Category: Demos and tools Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Martin v. Löwis (loewis) Summary: Update Demo/tix tixwidgets.py et al. Initial Comment: Updated README and INSTALL for Python 2.1 and tcl 8.3 Removed hardcoded fonts and colors so it will use the natve color scheme. Rewritten tixwidgets.py to make Demo a real class, and to fix a problem under Windows that was leaving undestroyed pythonw.exe running after exit. Added two new samples: DirList and DirTree. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-11-11 06:11 Message: Logged In: YES user_id=21627 Thanks, committed INSTALL.txt 1.2 README.txt 1.2 tixwidgets.py 1.3 DirList.py 1.1 DirTree.py 1.1 SHList1.py 1.2 SHList2.py 1.2 Notice that I cannot close the SHList1/2 anymore when run from tixwidgets.py; any help appreciated. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473002&group_id=5470 From noreply@sourceforge.net Sun Nov 11 14:33:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 11 Nov 2001 06:33:51 -0800 Subject: [Patches] [ python-Patches-479796 ] Patch for Bug #411612 Message-ID: Patches item #479796, was opened at 2001-11-08 14:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479796&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bryan Fordham (bfordham) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for Bug #411612 Initial Comment: Bug #411612 is the problem that the QUERY_STRING is not checked if the form action=="POST". This is a little patch to add the query string if it's there. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-11-11 06:33 Message: Logged In: YES user_id=21627 Isn't that the same patch as in #411612? Doesn't then the same comment apply: #Quick check: That "fix" does not work. It duplicates #the QUERY_STRING if you use the GET method. Additional #checks are necessary to ensure correct operation. Also, don't use plain diffs; please use context (-c) or unified (-u) diffs instead. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=479796&group_id=5470 From noreply@sourceforge.net Sun Nov 11 16:09:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 11 Nov 2001 08:09:44 -0800 Subject: [Patches] [ python-Patches-473512 ] getopt with GNU style scanning Message-ID: Patches item #473512, was opened at 2001-10-21 14:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473512&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Åstrand (astrand) Assigned to: Nobody/Anonymous (nobody) Summary: getopt with GNU style scanning Initial Comment: Implements GNU style scanning mode. The traditional mode is used if the option string begins with + or if the environment variable POSIXLY_CORRECT is set, just like GNU getopt. Patch includes updated documentation and test. ---------------------------------------------------------------------- >Comment By: Peter Åstrand (astrand) Date: 2001-11-11 08:09 Message: Logged In: YES user_id=344921 The new patch uses a new function, gnu_getopt, instead of changing the default behaviour. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-21 17:37 Message: Logged In: YES user_id=6380 Rejected in this form. We can't suddenly change the default behavior. If you want a way to support GNU style options (which I personally hate, but which I would accept as an option), try adding a different function (e.g. gnu_getopt(...)) or add a flag argument (e.g. getopt(..., gnu=1)). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473512&group_id=5470 From noreply@sourceforge.net Sun Nov 11 21:02:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 11 Nov 2001 13:02:33 -0800 Subject: [Patches] [ python-Patches-470607 ] HTML version of the Idle "documentation" Message-ID: Patches item #470607, was opened at 2001-10-12 08:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470607&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: HTML version of the Idle "documentation" Initial Comment: Idle Help

Features

IDLE has the following features:
  • coded in 100% pure Python, using the Tkinter GUI toolkit (i.e. Tcl/Tk)
  • cross-platform: works on Windows and Unix (on the Mac, there are currently problems with Tcl/Tk)
  • multi-window text editor with multiple undo, Python colorizing and many other features, e.g. smart indent and call tips
  • Python shell window (a.k.a. interactive interpreter)
  • debugger (not complete, but you can set breakpoints, view and step)

Menus

File menu:

New window
create a new editing window
Open...
open an existing file
Open module...
open an existing module (searches sys.path)
Class browser
show classes and methods in current file
Path browser
show sys.path directories, modules, classes and methods
Save
save current window to the associated file (unsaved windows have a * before and after the window title)
Save As...
save current window to new file, which becomes the associated file
Save Copy As...
save current window to different file without changing the associated file
Close
close current window (asks to save if unsaved)
Exit
close all windows and quit IDLE (asks to save if unsaved)

Edit menu:

Undo
Undo last change to current window (max 1000 changes)
Redo
Redo last undone change to current window
Cut
Copy selection into system-wide clipboard; then delete selection
Copy
Copy selection into system-wide clipboard
Paste
Insert system-wide clipboard into window
Select All
Select the entire contents of the edit buffer
Find...
Open a search dialog box with many options
Find again
Repeat last search
Find selection
Search for the string in the selection
Find in Files...
Open a search dialog box for searching files
Replace...
Open a search-and-replace dialog box
Go to line
Ask for a line number and show that line
Indent region
Shift selected lines right 4 spaces
Dedent region
Shift selected lines left 4 spaces
Comment out region
Insert ## in front of selected lines
Uncomment region
Remove leading # or ## from selected lines
Tabify region
Turns leading stretches of spaces into tabs
Untabify region
Turn all tabs into the right number of spaces
Expand word
Expand the word you have typed to match another word in the same buffer; repeat to get a different expansion
Format Paragraph
Reformat the current blank-line-separated paragraph
Import module
Import or reload the current module
Run script
Execute the current file in the __main__ namespace

Windows menu:

Zoom Height
toggles the window between normal size (24x80) and maximum height.
The rest of this menu lists the names of all open windows; select one to bring it to the foreground (deiconifying it if necessary).

Debug menu (in the Python Shell window only):

Go to file/line
look around the insert point for a filename and linenumber, open the file, and show the line.
Open stack viewer
show the stack traceback of the last exception
Debugger toggle
Run commands in the shell under the debugger
JIT Stack viewer toggle
Open stack viewer on traceback

Basic editing and navigation:

  • Backspace deletes to the left; DEL deletes to the right
  • Arrow keys and Page Up/Down to move around
  • Home/End go to begin/end of line
  • Control-Home/End go to begin/end of file
  • Some Emacs bindings may also work, e.g. ^B/^P/^A/^E/^D/^L

Automatic indentation:

After a block-opening statement, the next line is indented by 4 spaces (in the Python Shell window by one tab). After certain keywords (break, return etc.) the next line is dedented. In leading indentation, Backspace deletes up to 4 spaces if they are there. Tab inserts 1-4 spaces (in the Python Shell window one tab). See also the indent/dedent region commands in the edit menu.

Python Shell window:

  • ^C interrupts executing command
  • ^D sends end-of-file; closes window if typed at >>> prompt

Command history:

  • Alt-p retrieves previous command matching what you have typed
  • Alt-n retrieves next
  • Return while on any previous command retrieves that command
  • Alt-/ (Expand word) is also useful here

Syntax colors:

The coloring is applied in a background "thread", so you may occasionally see uncolorized text. To change the color scheme, edit the [Colors] section in config.txt.
Python syntax colors:
Keywords:
orange
Strings :
green
Comments:
red
Definitions:
blue
Shell colors:
Console output:
brown
stdout:
blue
stderr:
dark green
stdin:
black
Command line usage: 
	idle.py [-c command] [-d] [-e] [-s] [-t title] [arg] ...

	-c command  run this command
	-d          enable debugger
	-e          edit mode; arguments are files to be edited
	-s          run $IDLESTARTUP or $PYTHONSTARTUP first
	-t title    set title of shell window

If there are arguments:

  1. If -e is used, arguments are files opened for editing and sys.argv reflects the arguments passed to IDLE itself.
  2. Otherwise, if -c is used, all arguments are placed in sys.argv[1:...], with sys.argv[0] set to '-c'.
  3. Otherwise, if neither -e nor -c is used, the first argument is a script which is executed with the remaining arguments in sys.argv[1:...] and sys.argv[0] set to the script name. If the script name is '-', no script is executed but an interactive Python session is started; the arguments are still available in sys.argv.
---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-11 13:02 Message: Logged In: NO hello ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-12 08:54 Message: Logged In: YES user_id=6380 What do you want us to do with this? Note that IDLE development is going on in the idlefork.sf.net project. You might want to submit it there. And please use the file upload feature. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470607&group_id=5470 From noreply@sourceforge.net Sun Nov 11 22:07:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 11 Nov 2001 14:07:25 -0800 Subject: [Patches] [ python-Patches-480716 ] Support for super subclasses Message-ID: Patches item #480716, was opened at 2001-11-11 14:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480716&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Support for super subclasses Initial Comment: In Python 2.2b1, super is subclassable, however its __get__ (tp_descr_get) method always returns a new instance of super (not of its actual (sub)class). I think if super is to be subclassable, __get__ should return a new instance of the subclass. (I've been experimenting with using super instances to get and set the value of inherited attributes (properties). For this I needed a super subclass with a __setattr__ method. I also wanted to use the autosuper trick (from test_descr.py); that's where I discovered this behavior of __get__). *** typeobject.c.orig Sun Nov 11 13:34:35 2001 --- typeobject.c Sun Nov 11 13:53:02 2001 *************** *** 3887,3900 **** Py_INCREF(self); return self; } ! new = (superobject *)PySuper_Type.tp_new (&PySuper_Type, NULL, NULL); ! if (new == NULL) ! return NULL; ! Py_INCREF(su->type); ! Py_INCREF(obj); ! new->type = su->type; ! new->obj = obj; ! return (PyObject *)new; } static int --- 3887,3905 ---- Py_INCREF(self); return self; } ! if (su->ob_type != &PySuper_Type) ! /* if su is a subclass, call its type */ ! return PyObject_CallFunction((PyObject *)su->ob_type, "OO", su->type, obj); ! else { ! new = (superobject *) PySuper_Type.tp_new(&PySuper_Type, NULL, NULL); ! if (new == NULL) ! return NULL; ! Py_INCREF(su->type); ! Py_INCREF(obj); ! new->type = su->type; ! new->obj = obj; ! return (PyObject *)new; ! } } static int ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480716&group_id=5470 From noreply@sourceforge.net Sun Nov 11 22:12:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 11 Nov 2001 14:12:18 -0800 Subject: [Patches] [ python-Patches-480716 ] Support for super subclasses Message-ID: Patches item #480716, was opened at 2001-11-11 14:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480716&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Support for super subclasses Initial Comment: In Python 2.2b1, super is subclassable, however its __get__ (tp_descr_get) method always returns a new instance of super (not of its actual (sub)class). I think if super is to be subclassable, __get__ should return a new instance of the subclass. (I've been experimenting with using super instances to get and set the value of inherited attributes (properties). For this I needed a super subclass with a __setattr__ method. I also wanted to use the autosuper trick (from test_descr.py); that's where I discovered this behavior of __get__). *** typeobject.c.orig Sun Nov 11 13:34:35 2001 --- typeobject.c Sun Nov 11 13:53:02 2001 *************** *** 3887,3900 **** Py_INCREF(self); return self; } ! new = (superobject *)PySuper_Type.tp_new (&PySuper_Type, NULL, NULL); ! if (new == NULL) ! return NULL; ! Py_INCREF(su->type); ! Py_INCREF(obj); ! new->type = su->type; ! new->obj = obj; ! return (PyObject *)new; } static int --- 3887,3905 ---- Py_INCREF(self); return self; } ! if (su->ob_type != &PySuper_Type) ! /* if su is a subclass, call its type */ ! return PyObject_CallFunction((PyObject *)su->ob_type, "OO", su->type, obj); ! else { ! new = (superobject *) PySuper_Type.tp_new(&PySuper_Type, NULL, NULL); ! if (new == NULL) ! return NULL; ! Py_INCREF(su->type); ! Py_INCREF(obj); ! new->type = su->type; ! new->obj = obj; ! return (PyObject *)new; ! } } static int ---------------------------------------------------------------------- >Comment By: Greg Chapman (glchapman) Date: 2001-11-11 14:12 Message: Logged In: YES user_id=86307 I see that pasting in the patch lost all the formatting; I've reattached it as a file. Also, I generated it using v. 2.117 of typeobject.c. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480716&group_id=5470 From mailsss@getresponse.com Mon Nov 12 02:43:06 2001 From: mailsss@getresponse.com (E-Mailerrr) Date: Sun, 11 Nov 2001 21:43:06 -0500 Subject: [Patches] Ñïèñêè E-Mail àäðåñîâ Ìíîãî è Íåäîðîãî ! Message-ID: Ïðèâåò, (Cyrillic-1251 ) SUPER - ïðåäëîæåíèå! Áàçà E-mail àäðåñîâ. 1 ìèëëèîí 300 òûñÿ÷ àäðåñîâ â âèäå òåêñòîâûõ ôàéëîâ. Àäðåñà - ðóññêîÿçû÷íûå ïîëüçîâàòåëè è îðãàíèçàöèè. Âñå àäðåñà - áåç êàêèõ-ëèáî èíûõ äàííûõ, êðîìå ñàìîãî e-mail àäðåñà. Àäðåñà ÍÅ "çàáèòû" ! À ÒÅÏÅÐÜ ÑÀÌÎÅ ÃËÀÂÍÎÅ : ÍÀÇÎÂÈÒÅ ÑÂÎÞ ÖÅÍÓ, ÇÀ ÊÎÒÎÐÓÞ ÂÛ ÃÎÒÎÂÛ ÏÐÈÎÁÐÅÑÒÈ ÝÒÓ ÁÀÇÓ E-MAIL ÀÄÐÅÑÎÂ, È ÊÎÒÎÐÀß, ÏÎ ÂÀØÅÌÓ ÌÍÅÍÈÞ, ÍÀÑ ÓÑÒÐÎÈÒ ! ! ! Ìû íå çàíèìàåìñÿ ðàññûëêîé, Ìû ëèøü ïðîäàåì ñïèñîê E-Mail àäðåñîâ. Îïëàòà ÒÎËÜÊÎ ïî WebMoney, èëè E-Gold Ìû íå ñîçâàíèâàåìñÿ ïî òåëåôîíó èëè èíûì îáðàçîì. Ìû íå ïðèõîäèì â îôèñû. Âñå îáùåíèå òîëüêî ïî e-mail. Âñå ñïèñêè e-mail àäðåñîâ ïåðåäàþòñÿ òîëüêî ÷åðåç internet. Î íàøåé ïîðÿäî÷íîñòè ìîæåòå íå áåñïîêîèòüñÿ! Àäðåñà ïîëó÷èòå, åñëè íè â äåíü îïëàòû, òî â òå÷åíèå 2-õ äíåé - òî÷íî ! Òåì íå ìåíåå, åñëè ó Âàñ, âñå æå, âîçíèêàþò îïàñåíèÿ è ò.ï. , òî åñòü âîçìîæíîñòü ïîñòåïåííîé ïîêóïêè áàçû (Âû ïëàòèòå ïî WebMoney ÷àñòü ñóììû ñ ïðîòåêöèåé ïëàòåæà, à ïîñëå ïîëó÷åíèÿ ÷àñòè àäðåñîâ ñîîáùàåòå êîä, è ò.ä. ïîêà íå êóïèòå âåñü ñïèñîê). ---------------------------- Íå íàæèìàéòå êíîïêó ðåïëýé è íå ïîñûëàéòå ïóñòûõ ïèñåì. Ñïðîñèòå, åñëè ÷òî-òî õîòèòå óòî÷íèòü è íàçîâèòå ñâîþ öåíó íà ñïèñêè àäðåñîâ. Ñâÿçü ïî e-mail : mlm_info2000@yahoo.com ----------------------------- Âàø àäðåñ áûë óêàçàí íà îäíîì èç ôîðóìîâ, êàê çàïðàøèâàþùèé ïîäîáíóþ èíôîðìàöèþ, ïîýòîìó äàííîå ñîîáùåíèå íå ÿâëÿåòñÿ ñïàìîì. Òåì íå ìåíåå, åñëè Âû æåëàåòå, òî äëÿ îòïèñêè îò ðàññûëêè ïîøëèòå ñîîáùåíèå ñ òåìîé "îòïèñàòü". From noreply@sourceforge.net Mon Nov 12 03:48:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 11 Nov 2001 19:48:22 -0800 Subject: [Patches] [ python-Patches-480769 ] Cygwin _cursesmodule patch Message-ID: Patches item #480769, was opened at 2001-11-11 19:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480769&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Nobody/Anonymous (nobody) Summary: Cygwin _cursesmodule patch Initial Comment: The attached patch re-enables the clean building of _cursesmodule under Cygwin. However, upon running the the regression test, I get the following: test test_curses skipped -- Use of the `curses' resource not enabled so I don't know whether or not _cursesmodule functions properly under Cygwin. Nevertheless, this patch should not affect any other platform and can only improve the situation under Cygwin. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480769&group_id=5470 From noreply@sourceforge.net Mon Nov 12 12:18:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Nov 2001 04:18:10 -0800 Subject: [Patches] [ python-Patches-480769 ] Cygwin _cursesmodule patch Message-ID: Patches item #480769, was opened at 2001-11-11 19:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480769&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Nobody/Anonymous (nobody) Summary: Cygwin _cursesmodule patch Initial Comment: The attached patch re-enables the clean building of _cursesmodule under Cygwin. However, upon running the the regression test, I get the following: test test_curses skipped -- Use of the `curses' resource not enabled so I don't know whether or not _cursesmodule functions properly under Cygwin. Nevertheless, this patch should not affect any other platform and can only improve the situation under Cygwin. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2001-11-12 04:18 Message: Logged In: YES user_id=86216 Please do *not* apply this patch -- at least for the moment. When I submitted this patch, I had some reservations. But due to the impending release of beta 2, I decided to submit it anyway. If interested, see the following mailing list thread for the details: http://www.cygwin.com/ml/cygwin-apps/2001-11/msg00259.html Please put this patch in the pending state. After Cygwin ncurses is updated, I will try building without this patch. If all goes well, then I will request that this patch be closed (without being applied). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480769&group_id=5470 From noreply@sourceforge.net Mon Nov 12 12:27:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Nov 2001 04:27:39 -0800 Subject: [Patches] [ python-Patches-480769 ] Cygwin _cursesmodule patch Message-ID: Patches item #480769, was opened at 2001-11-11 19:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480769&group_id=5470 Category: Modules Group: None >Status: Pending >Resolution: Later Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Nobody/Anonymous (nobody) Summary: Cygwin _cursesmodule patch Initial Comment: The attached patch re-enables the clean building of _cursesmodule under Cygwin. However, upon running the the regression test, I get the following: test test_curses skipped -- Use of the `curses' resource not enabled so I don't know whether or not _cursesmodule functions properly under Cygwin. Nevertheless, this patch should not affect any other platform and can only improve the situation under Cygwin. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-11-12 04:27 Message: Logged In: YES user_id=6656 Whoa! I was just about to check it in... OK, it's set to pending/later. I thought you could twiddle the state of patches you submitted yourself, but it's done now. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-11-12 04:18 Message: Logged In: YES user_id=86216 Please do *not* apply this patch -- at least for the moment. When I submitted this patch, I had some reservations. But due to the impending release of beta 2, I decided to submit it anyway. If interested, see the following mailing list thread for the details: http://www.cygwin.com/ml/cygwin-apps/2001-11/msg00259.html Please put this patch in the pending state. After Cygwin ncurses is updated, I will try building without this patch. If all goes well, then I will request that this patch be closed (without being applied). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480769&group_id=5470 From noreply@sourceforge.net Mon Nov 12 13:30:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Nov 2001 05:30:43 -0800 Subject: [Patches] [ python-Patches-480902 ] allow dumbdbm to reuse space Message-ID: Patches item #480902, was opened at 2001-11-12 05:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480902&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Barry Warsaw (bwarsaw) Summary: allow dumbdbm to reuse space Initial Comment: This patch to dumbdbm does two things: * allows it to reuse holes in the .dat file * provides a somewhat more complete test The first change should be considered only for 2.3. Barry may or may not want to check out the test case rewrite for incorporation into 2.2. Accordingly, I've assigned it to him. Skip ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480902&group_id=5470 From noreply@sourceforge.net Mon Nov 12 16:41:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Nov 2001 08:41:03 -0800 Subject: [Patches] [ python-Patches-480962 ] Implement "setgroups" Message-ID: Patches item #480962, was opened at 2001-11-12 08:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480962&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jesús Cea Avión (jcea) Assigned to: Nobody/Anonymous (nobody) Summary: Implement "setgroups" Initial Comment: Details in https://sourceforge.net/tracker/?func=detail&atid=355470&aid=468116&group_id=5470 Here I send a simple patch. More work is needed in the error reporting sections, But I give the structure and leave the details (fill the gaps) to other developer more confortable with the Python data type exception models. Python 2.2 window is closing. I hope to see this work in 2.2. Hope is the last thing I'll lose :-) The patch is fairly simple, so consider incluiding in Python 2.2. Diff generated from Python 2.1.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480962&group_id=5470 From noreply@sourceforge.net Mon Nov 12 16:42:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Nov 2001 08:42:01 -0800 Subject: [Patches] [ python-Patches-480962 ] Implement "setgroups" Message-ID: Patches item #480962, was opened at 2001-11-12 08:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480962&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jesús Cea Avión (jcea) >Assigned to: Martin v. Löwis (loewis) >Summary: Implement "setgroups" Initial Comment: Details in https://sourceforge.net/tracker/?func=detail&atid=355470&aid=468116&group_id=5470 Here I send a simple patch. More work is needed in the error reporting sections, But I give the structure and leave the details (fill the gaps) to other developer more confortable with the Python data type exception models. Python 2.2 window is closing. I hope to see this work in 2.2. Hope is the last thing I'll lose :-) The patch is fairly simple, so consider incluiding in Python 2.2. Diff generated from Python 2.1.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480962&group_id=5470 From noreply@sourceforge.net Mon Nov 12 17:08:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Nov 2001 09:08:45 -0800 Subject: [Patches] [ python-Patches-480962 ] Implement "setgroups" Message-ID: Patches item #480962, was opened at 2001-11-12 08:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480962&group_id=5470 Category: Library (Lib) Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Jesús Cea Avión (jcea) Assigned to: Martin v. Löwis (loewis) >Summary: Implement "setgroups" Initial Comment: Details in https://sourceforge.net/tracker/?func=detail&atid=355470&aid=468116&group_id=5470 Here I send a simple patch. More work is needed in the error reporting sections, But I give the structure and leave the details (fill the gaps) to other developer more confortable with the Python data type exception models. Python 2.2 window is closing. I hope to see this work in 2.2. Hope is the last thing I'll lose :-) The patch is fairly simple, so consider incluiding in Python 2.2. Diff generated from Python 2.1.1. ---------------------------------------------------------------------- >Comment By: Jesús Cea Avión (jcea) Date: 2001-11-12 09:08 Message: Logged In: YES user_id=97460 Never Mind. You already patched the code, but the email notification never reach me :-( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480962&group_id=5470 From noreply@sourceforge.net Mon Nov 12 21:47:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Nov 2001 13:47:01 -0800 Subject: [Patches] [ python-Patches-481060 ] Patches for OS X for Python 2.1.2 Message-ID: Patches item #481060, was opened at 2001-11-12 13:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481060&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Wolfe (dkwolfe) Assigned to: Jack Jansen (jackjansen) Summary: Patches for OS X for Python 2.1.2 Initial Comment: The following existing 2.2 CVS patches need to be picked up by Python 2.1.2 for Mac OS X v. 10.1: Support for dylib - allow zlib included in OS to be used rather than have to compile and install in / usr/local: /cvsroot/python/python/dist/src/Lib/distutils/ unixccompiler.py,v retrieving revision 1.35 retrieving revision 1.36 diff -c -r1.35 -r1.36 /cvsroot/python/python/dist/src/Lib/distutils/ ccompiler.py,v retrieving revision 1.39 retrieving revision 1.40 diff -c -r1.39 -r1.40 Prevent ncurses from building on OS X: /cvsroot/python/python/dist/src/setup.py,v retrieving revision 1.52 retrieving revision 1.53 diff -c -r1.52 -r1.53 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481060&group_id=5470 From noreply@sourceforge.net Mon Nov 12 22:32:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Nov 2001 14:32:35 -0800 Subject: [Patches] [ python-Patches-481060 ] Patches for Mac OS X for Python 2.1.2 Message-ID: Patches item #481060, was opened at 2001-11-12 13:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481060&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Wolfe (dkwolfe) Assigned to: Jack Jansen (jackjansen) >Summary: Patches for Mac OS X for Python 2.1.2 Initial Comment: The following existing 2.2 CVS patches need to be picked up by Python 2.1.2 for Mac OS X v. 10.1: Support for dylib - allow zlib included in OS to be used rather than have to compile and install in / usr/local: /cvsroot/python/python/dist/src/Lib/distutils/ unixccompiler.py,v retrieving revision 1.35 retrieving revision 1.36 diff -c -r1.35 -r1.36 /cvsroot/python/python/dist/src/Lib/distutils/ ccompiler.py,v retrieving revision 1.39 retrieving revision 1.40 diff -c -r1.39 -r1.40 Prevent ncurses from building on OS X: /cvsroot/python/python/dist/src/setup.py,v retrieving revision 1.52 retrieving revision 1.53 diff -c -r1.52 -r1.53 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481060&group_id=5470 From noreply@sourceforge.net Mon Nov 12 22:33:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Nov 2001 14:33:31 -0800 Subject: [Patches] [ python-Patches-481060 ] dylib & ncurses patches for Mac OS X for Python 2.1.2 Message-ID: Patches item #481060, was opened at 2001-11-12 13:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481060&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Wolfe (dkwolfe) Assigned to: Jack Jansen (jackjansen) >Summary: dylib & ncurses patches for Mac OS X for Python 2.1.2 Initial Comment: The following existing 2.2 CVS patches need to be picked up by Python 2.1.2 for Mac OS X v. 10.1: Support for dylib - allow zlib included in OS to be used rather than have to compile and install in / usr/local: /cvsroot/python/python/dist/src/Lib/distutils/ unixccompiler.py,v retrieving revision 1.35 retrieving revision 1.36 diff -c -r1.35 -r1.36 /cvsroot/python/python/dist/src/Lib/distutils/ ccompiler.py,v retrieving revision 1.39 retrieving revision 1.40 diff -c -r1.39 -r1.40 Prevent ncurses from building on OS X: /cvsroot/python/python/dist/src/setup.py,v retrieving revision 1.52 retrieving revision 1.53 diff -c -r1.52 -r1.53 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481060&group_id=5470 From noreply@sourceforge.net Mon Nov 12 22:34:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Nov 2001 14:34:12 -0800 Subject: [Patches] [ python-Patches-481075 ] Makefile patches for Mac OS X for Python 2.1.2... Message-ID: Patches item #481075, was opened at 2001-11-12 14:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481075&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Wolfe (dkwolfe) Assigned to: Nobody/Anonymous (nobody) >Summary: Makefile patches for Mac OS X for Python 2.1.2... Initial Comment: I'm not a config god, so I'll leave it to someone else to figure out how configuration needs to be changed to incorporate the following changes for Mac OS X 10.1: 1) Assume: ./configure --with-dyld --with-suffix=.x 2) handle BSD header problems by changing Makefile lines OPT= -g -O3 -Wall -Wstrict-prototypes to OPT= -g -O3 -Wall -Wstrict-prototypes -no- cpp-precomp 3) handle two level name spaces for 10.x and 10.0.x - and use bundle loader option vs flat name spaces. LDSHARED= $(CC) $(LDFLAGS) -bundle - undefined suppress BLDSHARED= $(CC) $(LDFLAGS) -bundle - undefined suppress to LDSHARED= $(CC) $(LDFLAGS) -bundle - undefined error -bundle_loader ./python.x BLDSHARED= $(CC) $(LDFLAGS) -bundle - undefined error -bundle_loader ./python.x NOTE: the '.x' in python.x is the suffix entered in the configure command. Also, I've been told the bundle_loader is only used to resolve undefined symbols and there is no likage between the resulting binary and the bundle_loader. Hence, we can rename python.x to python after installation. with the following commands: cd /usr/local/bin/ sudo mv python.x python sudo mv python2.1.x python2.1 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481075&group_id=5470 From noreply@sourceforge.net Mon Nov 12 22:31:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Nov 2001 14:31:50 -0800 Subject: [Patches] [ python-Patches-481075 ] Patches for Mac OS X for Python 2.1.2... Message-ID: Patches item #481075, was opened at 2001-11-12 14:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481075&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Wolfe (dkwolfe) Assigned to: Nobody/Anonymous (nobody) Summary: Patches for Mac OS X for Python 2.1.2... Initial Comment: I'm not a config god, so I'll leave it to someone else to figure out how configuration needs to be changed to incorporate the following changes for Mac OS X 10.1: 1) Assume: ./configure --with-dyld --with-suffix=.x 2) handle BSD header problems by changing Makefile lines OPT= -g -O3 -Wall -Wstrict-prototypes to OPT= -g -O3 -Wall -Wstrict-prototypes -no- cpp-precomp 3) handle two level name spaces for 10.x and 10.0.x - and use bundle loader option vs flat name spaces. LDSHARED= $(CC) $(LDFLAGS) -bundle - undefined suppress BLDSHARED= $(CC) $(LDFLAGS) -bundle - undefined suppress to LDSHARED= $(CC) $(LDFLAGS) -bundle - undefined error -bundle_loader ./python.x BLDSHARED= $(CC) $(LDFLAGS) -bundle - undefined error -bundle_loader ./python.x NOTE: the '.x' in python.x is the suffix entered in the configure command. Also, I've been told the bundle_loader is only used to resolve undefined symbols and there is no likage between the resulting binary and the bundle_loader. Hence, we can rename python.x to python after installation. with the following commands: cd /usr/local/bin/ sudo mv python.x python sudo mv python2.1.x python2.1 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481075&group_id=5470 From noreply@sourceforge.net Mon Nov 12 22:37:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Nov 2001 14:37:53 -0800 Subject: [Patches] [ python-Patches-481080 ] Read Me file Patch for Python 2.1.2 Message-ID: Patches item #481080, was opened at 2001-11-12 14:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481080&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Wolfe (dkwolfe) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Read Me file Patch for Python 2.1.2 Initial Comment: The following paragraph replaces the existing Mac OS X v10.1 paragraph. It assumes that patches 481060 and 481075 are taken. - Dan Mac OS X 10.1: Run configure with ./configure -- with-suffix=.x --with-dyld". This generates executable file: 'python.x' (it cannot be named 'python' on an HFS or HFS+ disk as the file name clashes with directory 'Python'). The makefile is set up to correctly handle two- level namespaces for Mac OS X v10.1 and 10.0.x systems. However, running the prebinding tool on Mac OS X 10.0.x again will cause the tool to break as it cannot handle two level namespaces. The default Mac OS X has a default stacksize of 512K which causes the regular expression tests (RE and SRE) to SEGV. To temporarily increase the stacksize, type 'limit stacksize 2M' in the terminal window before running 'make test'. The test_largefile test will work on HFS+ and UFS filesystem, providing you have enough space and time. After sudo 'make installation', do the following commands: cd /usr/local/bin/ sudo mv python.x python sudo mv python2.1.x python2.1 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481080&group_id=5470 From noreply@sourceforge.net Tue Nov 13 00:04:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Nov 2001 16:04:31 -0800 Subject: [Patches] [ python-Patches-481118 ] 'switch'/'case'/'else' statement Message-ID: Patches item #481118, was opened at 2001-11-12 16:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481118&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 3 Submitted By: Thomas Wouters (twouters) Assigned to: M.-A. Lemburg (lemburg) Summary: 'switch'/'case'/'else' statement Initial Comment: This is a quick hack that adds the 'switch' statement to Python. This is by no means production code, it is *hack* that probably leaks stackentries all over the place. It's simply a proof of concept. I probably won't have time to solidify this anytime soon, so if anyone feels a strong desire for rejection, feel free to grab this and fix it up :) Assigned to MAL because he owns the PEP that mentions something like this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481118&group_id=5470 From noreply@sourceforge.net Tue Nov 13 09:03:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 13 Nov 2001 01:03:04 -0800 Subject: [Patches] [ python-Patches-481225 ] rfc822.Addresslist fails on long addrs Message-ID: Patches item #481225, was opened at 2001-11-13 01:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481225&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ondrej Palkovsky (ondrap) Assigned to: Nobody/Anonymous (nobody) Summary: rfc822.Addresslist fails on long addrs Initial Comment: AddrlistClass.getaddrlist used a recursion method, that's why it failed on very long addresses. This patch narrows the function so that it doesn't use recursion. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481225&group_id=5470 From noreply@sourceforge.net Tue Nov 13 12:46:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 13 Nov 2001 04:46:21 -0800 Subject: [Patches] [ python-Patches-481060 ] dylib & ncurses patches for Mac OS X for Python 2.1.2 Message-ID: Patches item #481060, was opened at 2001-11-12 13:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481060&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Wolfe (dkwolfe) Assigned to: Jack Jansen (jackjansen) Summary: dylib & ncurses patches for Mac OS X for Python 2.1.2 Initial Comment: The following existing 2.2 CVS patches need to be picked up by Python 2.1.2 for Mac OS X v. 10.1: Support for dylib - allow zlib included in OS to be used rather than have to compile and install in / usr/local: /cvsroot/python/python/dist/src/Lib/distutils/ unixccompiler.py,v retrieving revision 1.35 retrieving revision 1.36 diff -c -r1.35 -r1.36 /cvsroot/python/python/dist/src/Lib/distutils/ ccompiler.py,v retrieving revision 1.39 retrieving revision 1.40 diff -c -r1.39 -r1.40 Prevent ncurses from building on OS X: /cvsroot/python/python/dist/src/setup.py,v retrieving revision 1.52 retrieving revision 1.53 diff -c -r1.52 -r1.53 ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-11-13 04:46 Message: Logged In: YES user_id=45365 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481060&group_id=5470 From noreply@sourceforge.net Tue Nov 13 12:54:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 13 Nov 2001 04:54:21 -0800 Subject: [Patches] [ python-Patches-481060 ] dylib & ncurses patches for Mac OS X for Python 2.1.2 Message-ID: Patches item #481060, was opened at 2001-11-12 13:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481060&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Wolfe (dkwolfe) Assigned to: Jack Jansen (jackjansen) Summary: dylib & ncurses patches for Mac OS X for Python 2.1.2 Initial Comment: The following existing 2.2 CVS patches need to be picked up by Python 2.1.2 for Mac OS X v. 10.1: Support for dylib - allow zlib included in OS to be used rather than have to compile and install in / usr/local: /cvsroot/python/python/dist/src/Lib/distutils/ unixccompiler.py,v retrieving revision 1.35 retrieving revision 1.36 diff -c -r1.35 -r1.36 /cvsroot/python/python/dist/src/Lib/distutils/ ccompiler.py,v retrieving revision 1.39 retrieving revision 1.40 diff -c -r1.39 -r1.40 Prevent ncurses from building on OS X: /cvsroot/python/python/dist/src/setup.py,v retrieving revision 1.52 retrieving revision 1.53 diff -c -r1.52 -r1.53 ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-11-13 04:54 Message: Logged In: YES user_id=45365 Dan, ignore that note about the missing patches. I thought there was one that didn't come from the repository, but on looking again I saw all of them come from the repository, so no need to upload something. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-11-13 04:46 Message: Logged In: YES user_id=45365 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481060&group_id=5470 From noreply@sourceforge.net Tue Nov 13 13:00:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 13 Nov 2001 05:00:37 -0800 Subject: [Patches] [ python-Patches-481060 ] dylib & ncurses patches for Mac OS X for Python 2.1.2 Message-ID: Patches item #481060, was opened at 2001-11-12 13:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481060&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Wolfe (dkwolfe) >Assigned to: Anthony Baxter (anthonybaxter) Summary: dylib & ncurses patches for Mac OS X for Python 2.1.2 Initial Comment: The following existing 2.2 CVS patches need to be picked up by Python 2.1.2 for Mac OS X v. 10.1: Support for dylib - allow zlib included in OS to be used rather than have to compile and install in / usr/local: /cvsroot/python/python/dist/src/Lib/distutils/ unixccompiler.py,v retrieving revision 1.35 retrieving revision 1.36 diff -c -r1.35 -r1.36 /cvsroot/python/python/dist/src/Lib/distutils/ ccompiler.py,v retrieving revision 1.39 retrieving revision 1.40 diff -c -r1.39 -r1.40 Prevent ncurses from building on OS X: /cvsroot/python/python/dist/src/setup.py,v retrieving revision 1.52 retrieving revision 1.53 diff -c -r1.52 -r1.53 ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-11-13 05:00 Message: Logged In: YES user_id=45365 Anthony (you _are_ doing 2.1.2, or am I gravely mistaken? Assign back to me if I am:-), these patch suggestions look good to me. If you decide to apply them let me know when you've done so and I'll see whether I can build a 2.1.2 on OSX 10.1. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-11-13 04:54 Message: Logged In: YES user_id=45365 Dan, ignore that note about the missing patches. I thought there was one that didn't come from the repository, but on looking again I saw all of them come from the repository, so no need to upload something. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-11-13 04:46 Message: Logged In: YES user_id=45365 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481060&group_id=5470 From noreply@sourceforge.net Tue Nov 13 20:01:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 13 Nov 2001 12:01:19 -0800 Subject: [Patches] [ python-Patches-477161 ] New "access" keyword for mmap Message-ID: Patches item #477161, was opened at 2001-11-01 07:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477161&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jay T Miller (jaytmiller) >Assigned to: Tim Peters (tim_one) >Summary: New "access" keyword for mmap Initial Comment: The attached patch adds a new keyword parameter to mmap which provides a platform independent way of asking for 3 basic kinds of mmaps: readonly, write-through, and copy-on-write. For now, platform independent means UNIX and Win32. A readonly mmap creates a true readonly section of the process memory map, but python level access is guarded so that attempts to write the section (or fetch a writeable buffer) raise a ValueError exception. A readonly mmap is not resizeable. A write-through memory map is both readable and writeable, and updates to the memory are reflected onto the underlying file. A copy-on-write memory map is both readable and writeable, but updates to the memory are *not* reflected on the underlying file. A copy-on-write mmap is not resizeable. The patch modifies mmapodule.c, libmmap.tex, and test_mmap.py. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-11-13 12:01 Message: Logged In: YES user_id=12800 Although I haven't looked at the patch, I agree with Tim that it would be okay to apply for 2.2 as long as it is completely self-contained in mmap, has documentation and test cases, and imposes no backwards incompatibility. From the comments it seems like all these conditions are met. Assigning back to Tim because I don't know who it was originally assigned to. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-04 19:10 Message: Logged In: YES user_id=31435 Assigned to Barry in his Release Manager role: accept or postpone? I don't count it as "new feature" -- this is exposing what the platform mmap does, and it was always a flaw (if not a bug) that the Windows implementation didn't expose all the functionality exposed on Unix (Windows can handle it, it seems the original author(s) just didn't realize that). ---------------------------------------------------------------------- Comment By: Jay T Miller (jaytmiller) Date: 2001-11-04 03:53 Message: Logged In: YES user_id=320512 I created a 2nd generation patch which addresses the following: 1. mmapmodule.c is indented according to PEP-7. 2. documentation typos are corrected and the prose is more direct. 3. exception class for readonly access violations changed from ValueError to TypeError. (Thanks Tim!) ---------------------------------------------------------------------- Comment By: Jay T Miller (jaytmiller) Date: 2001-11-03 06:23 Message: Logged In: YES user_id=320512 I'll make the improvements pronto. The patch only exposes minor new functionality on Win32 (it's already exposed on UNIX) and should be fully backwards compatible; There is no requirement to use the new optional keyword. Is there any chance for 2.2? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-02 16:09 Message: Logged In: YES user_id=21627 Since this patch introduces a significant new feature, I'd recommend to postpone it until after 2.2. The patch itself looks ok, but the following improvements should be made: - indentation is incorrect, please see PEP 7. - the documentation has some typos, ACCES_ -> ACCESS_ - if possible, the documentation should indicate that the additional parameters are new to Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477161&group_id=5470 From noreply@sourceforge.net Tue Nov 13 20:08:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 13 Nov 2001 12:08:25 -0800 Subject: [Patches] [ python-Patches-470578 ] Fixes to synchronize unicode() and str() Message-ID: Patches item #470578, was opened at 2001-10-12 07:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470578&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Barry Warsaw (bwarsaw) Summary: Fixes to synchronize unicode() and str() Initial Comment: This patch implements what we have discussed on python-dev late in September: str(obj) and unicode(obj) should behave similar, while the old behaviour is retained for unicode(obj, encoding, errors). The patch also adds a new feature with which objects can provide unicode(obj) with input data: the __unicode__ method. Currently no new tp_unicode slot is implemented; this is left as option for the future. Note that PyUnicode_FromEncodedObject() no longer accepts Unicode objects as input. The API name already suggests that Unicode objects do not belong in the list of acceptable objects and the functionality was only needed because PyUnicode_FromEncodedObject() was being used directly by unicode(). The latter was changed in the discussed way: * unicode(obj) calls PyObject_Unicode() * unicode(obj, encoding, errors) calls PyUnicode_FromEncodedObject() One thing left open to discussion is whether to leave the PyUnicode_FromObject() API as a thin API extension on top of PyUnicode_FromEncodedObject() or to turn it into a (macro) alias for PyObject_Unicode() and deprecate it. Doing so would have some surprising consequences though, e.g. u"abc" + 123 would turn out as u"abc123"... Please check and then reassign to me for the checkin. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-11-13 12:08 Message: Logged In: YES user_id=12800 I believe your second patch has already been applied to the 2.2 trunk. I think we can now just close this patch. MAL, please correct me if I'm wrong! ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-10-19 05:07 Message: Logged In: YES user_id=38388 Added patch which includes the docs and additional tests. Barry, please check this patch into the b1 tree and close the patch. Thanks ! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-18 19:05 Message: Logged In: YES user_id=6380 I'm going to check this in, because MAL said he didn't have time before the deadline. MAL, if you have an improvement that cannot wait until after beta 1, check in on the trunk and mail Barry a context diff. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-12 13:36 Message: Logged In: YES user_id=6380 u"abc" + 123 should definitely raise an exception! Please provide a test suite that shows off the new behavior and the differences between old and new behavior. Please provide documentation patches. Without these, I can't really tell whether the patched code works as desired. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470578&group_id=5470 From noreply@sourceforge.net Tue Nov 13 20:16:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 13 Nov 2001 12:16:48 -0800 Subject: [Patches] [ python-Patches-480902 ] allow dumbdbm to reuse space Message-ID: Patches item #480902, was opened at 2001-11-12 05:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480902&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Skip Montanaro (montanaro) Summary: allow dumbdbm to reuse space Initial Comment: This patch to dumbdbm does two things: * allows it to reuse holes in the .dat file * provides a somewhat more complete test The first change should be considered only for 2.3. Barry may or may not want to check out the test case rewrite for incorporation into 2.2. Accordingly, I've assigned it to him. Skip ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-11-13 12:16 Message: Logged In: YES user_id=12800 I've accepted the second half -- the improvement to the test suite -- but as recommended, I'm postponing the first half until Py 2.3. Assigning back to Skip so he'll remember to deal with this again later. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=480902&group_id=5470 From noreply@sourceforge.net Tue Nov 13 23:15:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 13 Nov 2001 15:15:00 -0800 Subject: [Patches] [ python-Patches-477161 ] New "access" keyword for mmap Message-ID: Patches item #477161, was opened at 2001-11-01 07:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477161&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jay T Miller (jaytmiller) Assigned to: Tim Peters (tim_one) >Summary: New "access" keyword for mmap Initial Comment: The attached patch adds a new keyword parameter to mmap which provides a platform independent way of asking for 3 basic kinds of mmaps: readonly, write-through, and copy-on-write. For now, platform independent means UNIX and Win32. A readonly mmap creates a true readonly section of the process memory map, but python level access is guarded so that attempts to write the section (or fetch a writeable buffer) raise a ValueError exception. A readonly mmap is not resizeable. A write-through memory map is both readable and writeable, and updates to the memory are reflected onto the underlying file. A copy-on-write memory map is both readable and writeable, but updates to the memory are *not* reflected on the underlying file. A copy-on-write mmap is not resizeable. The patch modifies mmapodule.c, libmmap.tex, and test_mmap.py. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-11-13 15:15 Message: Logged In: YES user_id=31435 A very complete patch -- thank you, Jay! Accepted and checked in. This will ship with 2.2b2 later this week: Doc/lib/libmmap.tex; new revision: 1.6 Lib/test/test_mmap.py; new revision: 1.18 Lib/test/output/test_mmap; new revision: 1.7 Misc/NEWS; new revision: 1.312 Modules/mmapmodule.c; new revision: 2.34 ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-11-13 12:01 Message: Logged In: YES user_id=12800 Although I haven't looked at the patch, I agree with Tim that it would be okay to apply for 2.2 as long as it is completely self-contained in mmap, has documentation and test cases, and imposes no backwards incompatibility. From the comments it seems like all these conditions are met. Assigning back to Tim because I don't know who it was originally assigned to. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-04 19:10 Message: Logged In: YES user_id=31435 Assigned to Barry in his Release Manager role: accept or postpone? I don't count it as "new feature" -- this is exposing what the platform mmap does, and it was always a flaw (if not a bug) that the Windows implementation didn't expose all the functionality exposed on Unix (Windows can handle it, it seems the original author(s) just didn't realize that). ---------------------------------------------------------------------- Comment By: Jay T Miller (jaytmiller) Date: 2001-11-04 03:53 Message: Logged In: YES user_id=320512 I created a 2nd generation patch which addresses the following: 1. mmapmodule.c is indented according to PEP-7. 2. documentation typos are corrected and the prose is more direct. 3. exception class for readonly access violations changed from ValueError to TypeError. (Thanks Tim!) ---------------------------------------------------------------------- Comment By: Jay T Miller (jaytmiller) Date: 2001-11-03 06:23 Message: Logged In: YES user_id=320512 I'll make the improvements pronto. The patch only exposes minor new functionality on Win32 (it's already exposed on UNIX) and should be fully backwards compatible; There is no requirement to use the new optional keyword. Is there any chance for 2.2? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-02 16:09 Message: Logged In: YES user_id=21627 Since this patch introduces a significant new feature, I'd recommend to postpone it until after 2.2. The patch itself looks ok, but the following improvements should be made: - indentation is incorrect, please see PEP 7. - the documentation has some typos, ACCES_ -> ACCESS_ - if possible, the documentation should indicate that the additional parameters are new to Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477161&group_id=5470 From noreply@sourceforge.net Tue Nov 13 23:24:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 13 Nov 2001 15:24:31 -0800 Subject: [Patches] [ python-Patches-481520 ] System V IPC bindings for python Message-ID: Patches item #481520, was opened at 2001-11-13 15:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481520&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: System V IPC bindings for python Initial Comment: This patch adds System V IPC bindings to python. I submitted it a while ago but it got ignored. The functionality is useful and allows better interoperability. I resubmit it because someone just wrote to me to say they wanted a copy but couldn't find it anyway ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481520&group_id=5470 From noreply@sourceforge.net Wed Nov 14 08:55:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Nov 2001 00:55:01 -0800 Subject: [Patches] [ python-Patches-481520 ] System V IPC bindings for python Message-ID: Patches item #481520, was opened at 2001-11-13 15:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481520&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: System V IPC bindings for python Initial Comment: This patch adds System V IPC bindings to python. I submitted it a while ago but it got ignored. The functionality is useful and allows better interoperability. I resubmit it because someone just wrote to me to say they wanted a copy but couldn't find it anyway ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-14 00:55 Message: Logged In: YES user_id=38388 You seem to have forgotten to attach the patch. In any case, I'd suggest to look into submitting your code to Parnassus. That way people will find it more easily; even if it doesn't get incorporated into the Python core. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481520&group_id=5470 From noreply@sourceforge.net Wed Nov 14 15:13:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Nov 2001 07:13:30 -0800 Subject: [Patches] [ python-Patches-476814 ] foreign-platform newline support Message-ID: Patches item #476814, was opened at 2001-10-31 08:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476814&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) >Assigned to: Tim Peters (tim_one) Summary: foreign-platform newline support Initial Comment: This patch enables Python to interpret all known newline conventions, CR, LF or CRLF, on all platforms. This support is enabled by configuring with --with-universal-newlines (so by default it is off, and everything should behave as usual). With universal newline support enabled two things happen: - When importing or otherwise parsing .py files any newline convention is accepted. - Python code can pass a new "t" mode parameter to open() which reads files with any newline convention. "t" cannot be combined with any other mode flags like "w" or "+", for obvious reasons. File objects have a new attribute "newlines" which contains the type of newlines encountered in the file (or None when no newline has been seen, or "mixed" if there were various types of newlines). Also included is a test script which tests both file I/O and parsing. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-11-14 07:13 Message: Logged In: YES user_id=45365 Here's a new version of the patch. To address your issues one by one: - get_line and Py_UniversalNewlineFgets are too difficult to integrate, at leat, I don't see how I could do it. The storage management of get_line gets in the way. - The global lock comment I don't understand. The Universal... routines are replacements for fgets() and fread(), so have nothing to do with the interpreter lock. - The logic of all three routines (get_line too) has changed and I've put comments in. I hope this addresses some of the points. - If universal_newline is false for a certain PyFileObject we now immedeately take a quick exit via fgets() or fread(). There's also a new test script, that tests some more border cases (like lines longer than 100 characters, and a lone CR just before end of file). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-05 00:16 Message: Logged In: YES user_id=31435 It would be better if get_line just called Py_UniversalNewlineFgets (when appropriate) instead of duplicating its logic inline. Py_UniversalNewlineFgets and Py_UniversalNewlineFread should deal with releasing the global lock themselves -- the correct granularity for lock release/reacquire is around the C-level input routines (esp. for fread). The new routines never check for I/O errors! Why not? It seems essential. The new Fgets checks for EOF at the end of the loop instead of the top. This is surprising, and I stared a long time in vain trying to guess why. Setting newlinetypes |= NEWLINE_CR; immediately after seeing an '\r' would be as fast (instead of waiting to see EOF and then inferring the prior existence of '\r' indirectly from the state of the skipnextlf flag). Speaking of which , the fobj tests in the inner loop waste cycles. Set the local flag vrbls whether or not fobj is NULL. When you're *out* of the inner loop you can simply decline to store the new masks when fobj is NULL (and you're already doing the latter anyway). A test and branch inside the loop is much more expensive than or'ing in a flag bit inside the loop, ditto harder to understand. Floating the univ_newline test out of the loop (and duplicating the loop body, one way for univ_newline true and the other for it false) would also save a test and branch on every character. Doing fread one character at a time is very inefficient. Since you know you need to obtain n characters in the end, and that these transformations require reading at least n characters, you could very profitably read n characters in one gulp at the start, then switch to k at a time where k is the number of \r\n pairs seen since the last fread call. This is easier to code than it sounds . It would be fine by me if you included (and initialized) the new file-object fields all the time, whether or not universal newlines are configured. I'd rather waste a few bytes in a file object than see #ifdefs spread thru the code. I'll be damned if I can think of a quick way to do this stuff on Windows -- native Windows fgets() is still the only Windows handle we have on avoiding crushing thread overhead inside MS's C library. I'll think some more about it (the thrust still being to eliminate the 't' mode flag, as whined about on Python-Dev). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-31 09:38 Message: Logged In: YES user_id=6380 Tim, can you review this or pass it on to someone else who has time? Jack developed this patch after a discussion in which I was involved in some of the design, but I won't have time to look at it until December. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476814&group_id=5470 From noreply@sourceforge.net Wed Nov 14 15:38:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Nov 2001 07:38:57 -0800 Subject: [Patches] [ python-Patches-481718 ] Time module doc string changes. Message-ID: Patches item #481718, was opened at 2001-11-14 07:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481718&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: Time module doc string changes. Initial Comment: Made the doc-strings for time.localtime() and time.gmtime() list the elements of the tuple they return. This is what the os.stat() doc-string does, and it's supremely useful when combined with "pydoc". Also added a newline after the first line of a couple of doc-strings, so that they all have the same format (summary line, blank line, details). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481718&group_id=5470 From noreply@sourceforge.net Wed Nov 14 15:50:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Nov 2001 07:50:45 -0800 Subject: [Patches] [ python-Patches-459442 ] Fix small Tools/bgen problems Message-ID: Patches item #459442, was opened at 2001-09-07 00:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459442&group_id=5470 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Jack Jansen (jackjansen) Summary: Fix small Tools/bgen problems Initial Comment: Fix some small problems with bgen: Remove some (debugging?) print statements. Fix the initialization code for generated types. They are initialized twice, which does not harm, but the code doesn't compile with MSVC 6 in C source code. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-11-14 07:50 Message: Logged In: YES user_id=45365 I fixed the initialization problem. I left the prints in, they could be seen as debug output, but they're really handy, as they provide feedback on what is actually parsed and generated. I.e. if no <-- is printed you know parsing went wrong, and if bgen crashes in the --> process you know where the problem is. If you think these should be optional: reopen the patch (and preferrably supply the code to make the prints optional:-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459442&group_id=5470 From noreply@sourceforge.net Wed Nov 14 16:02:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Nov 2001 08:02:55 -0800 Subject: [Patches] [ python-Patches-458383 ] Start of a bgen tutorial Message-ID: Patches item #458383, was opened at 2001-09-04 06:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458383&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Jack Jansen (jackjansen) Summary: Start of a bgen tutorial Initial Comment: Jack, this is (maybe) a start of a bgen tutorial. It explains some of the things I understand now from bgen. It is not finished, also it uses windows specific examples. I'm requesting comments on the general approach. I have also sent it to you via email, but probably you have not seen it. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-11-14 08:02 Message: Logged In: YES user_id=45365 Thomas, I'm leaving your tutorial in the patch section for now. My reason for this is that you give a nice explanation of how bgen generates code, and how you can then build the module (nifty, that one!), but you skip the whole "front end" bit: how bgen parses your C header files, and how you add support for the various C objects to Python. And in my opinion that is the biggest stumbling block for people starting to work with bgen. I'll try and come up with a framework for a tutorial, if I have something I'll let you know so you can shine your light on it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458383&group_id=5470 From noreply@sourceforge.net Wed Nov 14 22:48:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Nov 2001 14:48:43 -0800 Subject: [Patches] [ python-Patches-409078 ] Doc/lib/libui.tex Message-ID: Patches item #409078, was opened at 2001-03-16 02:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 Category: Documentation Group: None >Status: Pending Resolution: Later >Priority: 6 Submitted By: Internet Discovery (idiscovery) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Doc/lib/libui.tex Initial Comment: Right now, TkInter is in the library reference under Appendix/Undocumented/Frameworks. I think this should come up to be a chapter on User Interface modules. If you agree, here is a starting point for a chapter. The LaTeX may need proofing for the Python macros, as I don't have them installed here. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-14 14:48 Message: Logged In: YES user_id=3066 Per email conversations, it appears that no content from Fredrik Lundh remains in the proposed chapter, so that isn't holding this up. Mike: Is the version of the chapter attached to this report the latest version? (Please respond on SF.) ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-11-11 01:42 Message: Logged In: YES user_id=33229 This is the updated version of the UI chapter. There's only a line or two from /F's Introduction to Tkinter, if that, so I changed the Tkinter section author to myself, and listed the Intro to Tkinter in the \seealso. I haven't been able to find a valid email for Matt Conway who wrote the Life Preserver, which I had assumed was PD. I still have some ideas for improvements, but this is a starting point. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-09 08:10 Message: Logged In: YES user_id=3066 Status: Some of the material was based Fredrik Lundh's writing and Matt Conway's "Tkinter Life Preserver"; working on getting permissions to use the material before this can be checked in. Without permission, there might not be a chapter on Tk for a while, unless there are volunteers to write new content. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-24 19:18 Message: Logged In: YES user_id=3066 Just a note so this doesn't look like its being ignored: Mike & I have been communicating on working this into material that's closer to being ready for the docs, but it has been slow going simply because neither of us has a lot of time for it right now. Something based on this will be added to the documentation. Mike, would you like to attach the most recent iteration to this patch report on SF so others can review/contribute as well? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-03-29 07:21 Message: Logged In: YES user_id=3066 Mike: you suggested that you could also provide some of the material from your IPC9 paper to flesh out these sections -- do you have time to do the integration, or would someone else need to do it? I see a lot of Tcl code in the paper -- would this be converted to Python as examples? Thanks! ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-20 21:20 Message: Logged In: YES user_id=33229 The "Tix" patches have been resubmitted as #410231, and all of the suggestions here have been incoproated (dynamic loading, package require, Tkinter.Widget.__bases__). But this patch still remains valid even for 2.0.x, as having Tkinter under Appendix/Undocumented/Frameworks is not a good place. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:42 Message: Logged In: YES user_id=33229 Oppen sorry. SF is giving me no data html pages as responses. Anyone else having this problem? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:22 Message: Logged In: YES user_id=21627 Where is the file? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 From noreply@sourceforge.net Thu Nov 15 05:24:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Nov 2001 21:24:15 -0800 Subject: [Patches] [ python-Patches-409078 ] Doc/lib/libui.tex Message-ID: Patches item #409078, was opened at 2001-03-16 02:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 Category: Documentation Group: None >Status: Open Resolution: Later Priority: 6 Submitted By: Internet Discovery (idiscovery) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Doc/lib/libui.tex Initial Comment: Right now, TkInter is in the library reference under Appendix/Undocumented/Frameworks. I think this should come up to be a chapter on User Interface modules. If you agree, here is a starting point for a chapter. The LaTeX may need proofing for the Python macros, as I don't have them installed here. ---------------------------------------------------------------------- >Comment By: Internet Discovery (idiscovery) Date: 2001-11-14 21:24 Message: Logged In: YES user_id=33229 Yes this is the latest. As a failsafe, here it is again. Mike. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-14 14:48 Message: Logged In: YES user_id=3066 Per email conversations, it appears that no content from Fredrik Lundh remains in the proposed chapter, so that isn't holding this up. Mike: Is the version of the chapter attached to this report the latest version? (Please respond on SF.) ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-11-11 01:42 Message: Logged In: YES user_id=33229 This is the updated version of the UI chapter. There's only a line or two from /F's Introduction to Tkinter, if that, so I changed the Tkinter section author to myself, and listed the Intro to Tkinter in the \seealso. I haven't been able to find a valid email for Matt Conway who wrote the Life Preserver, which I had assumed was PD. I still have some ideas for improvements, but this is a starting point. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-09 08:10 Message: Logged In: YES user_id=3066 Status: Some of the material was based Fredrik Lundh's writing and Matt Conway's "Tkinter Life Preserver"; working on getting permissions to use the material before this can be checked in. Without permission, there might not be a chapter on Tk for a while, unless there are volunteers to write new content. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-24 19:18 Message: Logged In: YES user_id=3066 Just a note so this doesn't look like its being ignored: Mike & I have been communicating on working this into material that's closer to being ready for the docs, but it has been slow going simply because neither of us has a lot of time for it right now. Something based on this will be added to the documentation. Mike, would you like to attach the most recent iteration to this patch report on SF so others can review/contribute as well? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-03-29 07:21 Message: Logged In: YES user_id=3066 Mike: you suggested that you could also provide some of the material from your IPC9 paper to flesh out these sections -- do you have time to do the integration, or would someone else need to do it? I see a lot of Tcl code in the paper -- would this be converted to Python as examples? Thanks! ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-20 21:20 Message: Logged In: YES user_id=33229 The "Tix" patches have been resubmitted as #410231, and all of the suggestions here have been incoproated (dynamic loading, package require, Tkinter.Widget.__bases__). But this patch still remains valid even for 2.0.x, as having Tkinter under Appendix/Undocumented/Frameworks is not a good place. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:42 Message: Logged In: YES user_id=33229 Oppen sorry. SF is giving me no data html pages as responses. Anyone else having this problem? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:22 Message: Logged In: YES user_id=21627 Where is the file? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 From in657@mail.com Thu Nov 15 08:38:30 2001 From: in657@mail.com (infoMARKET) Date: Thu, 15 Nov 2001 11:38:30 +0300 Subject: [Patches] =?windows-1251?Q?=C2=E0=F8=E8_=ED=EE=E2=FB=E5_=EA=EB=E8=E5=ED=F2=FB_!?= Message-ID: <169320011141583830143@mail.com> Çäðàâñòâóéòå!  ýòîì ïèñüìå: - áàçû äàííûõ ïðåäïðèÿòèé äëÿ êîíòàêòîâ ïî ýëåêòðîííîé ïî÷òå (ï.1); - ïðîãðàììà äëÿ àâòîìàòè÷åñêîé ðàññûëêè ýëåêòðîííîé ïî÷òû (ï.2); - áàçû äàííûõ êðóïíåéøèõ ïðåäïðèÿòèé Ìîñêâû, Ðîññèè, ÑÍà (ï.3); - áàçû äàííûõ ðåãèîíàëüíûõ ïðîìûøëåííûõ ïðåäïðèÿòèé (âñå ðåãèîíû Ðîññèè è ÑÍÃ) (ï.4); - îòðàñëåâûå áàçû äàííûõ ïðåäïðèÿòèé Ìîñêâû (ï.5); - âàøà êîðïîðàòèâíàÿ ýëåêòðîííàÿ ïî÷òà (ï.6). 1. Êîãäà íåîáõîäèìî áûñòðî è ñ ìèíèìàëüíûìè çàòðàòàìè ñîîáùèòü îïðåäåëåííîé öåëåâîé ãðóïïå ïðåäïðèÿòèé êàêóþ-ëèáî èíôîðìàöèþ, íåò íè÷åãî ëó÷øå, ÷åì ñäåëàòü ýòî ïî ýëåêòðîííîé ïî÷òå. Íàøè áàçû äàííûõ ïðåäïðèÿòèé Ìîñêâû, Ðîññèè, ÑÍà ïðåäíàçíà÷åíû ñïåöèàëüíî äëÿ ýòèõ öåëåé. Ïîêóïàÿ èõ, âû ïðèîáðåòàåòå ìîùíåéøèé ìàðêåòèíãîâûé ìåõàíèçì, ïîçâîëÿþùèé ìîìåíòàëüíî ïðèâëåêàòü íîâûõ è íîâûõ êëèåíòîâ. Áàçû ïðåäîñòàâëÿþòñÿ íà êîìïàêò-äèñêå (â ò.÷. ïî ïî÷òå). Ñòîèìîñòü îò $100 äî 300. Ôîðìà îïëàòû ëþáàÿ. Çàêàçû: infmarket@global-mail.ru 2. Ïðîãðàììà "GroupMail" ïðåäíàçíà÷åíà äëÿ îñóùåñòâëåíèÿ ýëåêòðîííûõ ðàññûëîê. Ñòîèìîñòü åå ïðåäîñòàâëåíèÿ $25. Ôîðìà îïëàòû ëþáàÿ. Ïðîãðàììà ïðåäîñòàâëÿåòñÿ íà êîìïàêò-äèñêå (â ò.÷. ïî ïî÷òå) èëè âûñûëàåòñÿ ýëåêòðîííîé ïî÷òîé. Çàêàçû è âîïðîñû: infmarket@global-mail.ru. Âûïîëíÿåì ýëåêòðîííûå ðàññûëêè ïî Âàøåìó çàêàçó. Çàêàçû è âîïðîñû íàïðàâëÿéòå íà àäðåñ infmarket@global-mail.ru. 3. Èìåþòñÿ â ïðîäàæå áàçû äàííûõ ÊÐÓÏÍÅÉØÈÕ ÏÐÅÄÏÐÈßÒÈÉ: "Ïðåäïðèÿòèÿ Ìîñêâû/Ðîññèè/ÑÍà ñ ÷èñëåííîñòüþ øòàòà áîëåå 50/500/1000 ÷åëîâåê". Ñòîèìîñòè ýòèõ áàç äàííûõ îò $15 äî $300. Ôîðìà îïëàòû ëþáàÿ. Áàçû ïðåäîñòàâëÿåòñÿ íà êîìïàêò äèñêå (â ò.÷. ïî ïî÷òå) èëè âûñûëàåòñÿ ýëåêòðîííîé ïî÷òîé. Çàêàçû è âîïðîñû: infmarket@global-mail.ru. 4. Áàçû äàííûõ ðåãèîíàëüíûõ ïðîìûøëåííûõ ïðåäïðèÿòèé (âñå ðåãèîíû Ðîññèè è ÑÍÃ). InfMarket@global-mail.ru. 5. Èìåþòñÿ â ïðîäàæå ñëåäóþùèå îòðàñëåâûå áàçû äàííûõ ïðåäïðèÿòèé Ìîñêâû: - Ïðåäñòàâèòåëüñòâà çàðóáåæíûõ êîìïàíèé, ïîñîëüñòâà; - Ôèíàíñîâûå îðãàíèçàöèè; - Íåäâèæèìîñòü è ñòðîèòåëüñòâî; - Ìåáåëü è äåðåâîîáðàáîòêà; - Âíåøíîñòü, êðàñîòà, îòäûõ; - Ïðîäóêòû ïèòàíèÿ; - Îäåæäà è îáóâü; - Àâòî-ìîòî; - Ïðîìûøëåííîñòü; - Òóðèçì è îòäûõ; - Ìåäèöèíà è Ôàðìàöèÿ; - Ðåêëàìà; - ÑÌÈ. InfMarket@global-mail.ru 6. Âàøà êîðïîðàòèâíàÿ ýëåêòðîííàÿ ïî÷òà. Åñëè ó Âàñ åùå íåò ñîáñòâåííîãî âåá-ñàéòà, ïðè ìèíèìàëüíûõ çàòðàòàõ (ìåíüøå $100 â ãîä!) âû ìîæåòå âñåãî çà 5 ìèíóò: - çàðåãèñòðèðîâàòü äîìåí (àäðåñ âàøåé êîìïàíèè â Èíòåðíåòå) âèäà www.ÂÀØÀ_ÔÈÐÌÀ.ru. Èëè: www.ÂÀØÀ_ÔÈÐÌÀ.com; - ïîëó÷èòü íåîãðàíè÷åííîå (!) êîëè÷åñòâî ýëåêòðîííûõ ÿùèêîâ âèäà èìÿ@ÂÀØÀ_ÔÈÐÌÀ.ru. Âû ñìîæåòå äàòü ëè÷íûé ýëåêòðîííûé ÿùèê êàæäîìó âàøåìó ñîòðóäíèêó èëè îòäåëó. Âûøåîïèñàííîå ìîæíî ñäåëàòü ñ íàøåé ïîìîùüþ â ëþáîé ñòðàíå, ëþáîì ãîðîäå è ïðè ëþáîì ñïîñîáå îïëàòû. Åñëè æå âû ðåøèëè, ÷òî ñàéò âàì óæå íåîáõîäèì, îáðàùàéòåñü ê íàì. Èìåÿ áîëüøîé îïûò â ñîçäàíèè âåá-ñàéòîâ, ìû ìîæåì èçãîòîâèòü âàø âåá-ðåñóðñ ëþáîãî óðîâíÿ ñëîæíîñòè. Ïî ëþáûì âîïðîñàì ïèøèòå íà InfMarket@global-mail.ru. Êîìïàíèÿ InfoMarket From noreply@sourceforge.net Thu Nov 15 17:37:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Nov 2001 09:37:16 -0800 Subject: [Patches] [ python-Patches-409078 ] Doc/lib/libui.tex Message-ID: Patches item #409078, was opened at 2001-03-16 02:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 6 Submitted By: Internet Discovery (idiscovery) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Doc/lib/libui.tex Initial Comment: Right now, TkInter is in the library reference under Appendix/Undocumented/Frameworks. I think this should come up to be a chapter on User Interface modules. If you agree, here is a starting point for a chapter. The LaTeX may need proofing for the Python macros, as I don't have them installed here. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-15 09:37 Message: Logged In: YES user_id=3066 This has been checked in with minor changes from me (mostly markup rather than content). The chapter will be included as part of Python 2.2 beta 2. Thanks Mike! ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-11-14 21:24 Message: Logged In: YES user_id=33229 Yes this is the latest. As a failsafe, here it is again. Mike. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-14 14:48 Message: Logged In: YES user_id=3066 Per email conversations, it appears that no content from Fredrik Lundh remains in the proposed chapter, so that isn't holding this up. Mike: Is the version of the chapter attached to this report the latest version? (Please respond on SF.) ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-11-11 01:42 Message: Logged In: YES user_id=33229 This is the updated version of the UI chapter. There's only a line or two from /F's Introduction to Tkinter, if that, so I changed the Tkinter section author to myself, and listed the Intro to Tkinter in the \seealso. I haven't been able to find a valid email for Matt Conway who wrote the Life Preserver, which I had assumed was PD. I still have some ideas for improvements, but this is a starting point. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-09 08:10 Message: Logged In: YES user_id=3066 Status: Some of the material was based Fredrik Lundh's writing and Matt Conway's "Tkinter Life Preserver"; working on getting permissions to use the material before this can be checked in. Without permission, there might not be a chapter on Tk for a while, unless there are volunteers to write new content. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-24 19:18 Message: Logged In: YES user_id=3066 Just a note so this doesn't look like its being ignored: Mike & I have been communicating on working this into material that's closer to being ready for the docs, but it has been slow going simply because neither of us has a lot of time for it right now. Something based on this will be added to the documentation. Mike, would you like to attach the most recent iteration to this patch report on SF so others can review/contribute as well? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-03-29 07:21 Message: Logged In: YES user_id=3066 Mike: you suggested that you could also provide some of the material from your IPC9 paper to flesh out these sections -- do you have time to do the integration, or would someone else need to do it? I see a lot of Tcl code in the paper -- would this be converted to Python as examples? Thanks! ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-20 21:20 Message: Logged In: YES user_id=33229 The "Tix" patches have been resubmitted as #410231, and all of the suggestions here have been incoproated (dynamic loading, package require, Tkinter.Widget.__bases__). But this patch still remains valid even for 2.0.x, as having Tkinter under Appendix/Undocumented/Frameworks is not a good place. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-03-18 14:42 Message: Logged In: YES user_id=33229 Oppen sorry. SF is giving me no data html pages as responses. Anyone else having this problem? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-18 03:22 Message: Logged In: YES user_id=21627 Where is the file? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409078&group_id=5470 From noreply@sourceforge.net Thu Nov 15 19:37:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Nov 2001 11:37:31 -0800 Subject: [Patches] [ python-Patches-459442 ] Fix small Tools/bgen problems Message-ID: Patches item #459442, was opened at 2001-09-07 00:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459442&group_id=5470 Category: None Group: None Status: Closed Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Jack Jansen (jackjansen) Summary: Fix small Tools/bgen problems Initial Comment: Fix some small problems with bgen: Remove some (debugging?) print statements. Fix the initialization code for generated types. They are initialized twice, which does not harm, but the code doesn't compile with MSVC 6 in C source code. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2001-11-15 11:37 Message: Logged In: YES user_id=11105 Thanks, Jack. The prints are a minor problem, if any. There are, however, other points in bgen which probably should be fixed, but maybe it's too much work because it also has other consequences. bgen exports symbols like int and float, maybe also others which I cannot remember at the moment, which is not good IMO. Do you think these could be changed to c_int and c_float (or whatever names you like)? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-11-14 07:50 Message: Logged In: YES user_id=45365 I fixed the initialization problem. I left the prints in, they could be seen as debug output, but they're really handy, as they provide feedback on what is actually parsed and generated. I.e. if no <-- is printed you know parsing went wrong, and if bgen crashes in the --> process you know where the problem is. If you think these should be optional: reopen the patch (and preferrably supply the code to make the prints optional:-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459442&group_id=5470 From noreply@sourceforge.net Thu Nov 15 21:00:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Nov 2001 13:00:07 -0800 Subject: [Patches] [ python-Patches-459442 ] Fix small Tools/bgen problems Message-ID: Patches item #459442, was opened at 2001-09-07 00:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459442&group_id=5470 Category: None Group: None Status: Closed Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Jack Jansen (jackjansen) Summary: Fix small Tools/bgen problems Initial Comment: Fix some small problems with bgen: Remove some (debugging?) print statements. Fix the initialization code for generated types. They are initialized twice, which does not harm, but the code doesn't compile with MSVC 6 in C source code. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-11-15 13:00 Message: Logged In: YES user_id=45365 Exporting int and float with other names would defeat the point! When the Python code generated from the header file (customarily called something like dlggen.py) is read these names are in scope, and thereby the C int parameters are handled correctly in the glue routines. This is the mechanism by which C type names are mapped to the Python objects that know how to create the glue code for PyArg_ParseTuple and Py_BuildValue (or any other means to get these C objects to/from Python). It does mean that if you want to get at the builtin function "int" from within a begn parser you'll have to use __builtin__.int. This is a bit of a nuisance, but on the other hand I don't the situation will occur often, if at all. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-11-15 11:37 Message: Logged In: YES user_id=11105 Thanks, Jack. The prints are a minor problem, if any. There are, however, other points in bgen which probably should be fixed, but maybe it's too much work because it also has other consequences. bgen exports symbols like int and float, maybe also others which I cannot remember at the moment, which is not good IMO. Do you think these could be changed to c_int and c_float (or whatever names you like)? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-11-14 07:50 Message: Logged In: YES user_id=45365 I fixed the initialization problem. I left the prints in, they could be seen as debug output, but they're really handy, as they provide feedback on what is actually parsed and generated. I.e. if no <-- is printed you know parsing went wrong, and if bgen crashes in the --> process you know where the problem is. If you think these should be optional: reopen the patch (and preferrably supply the code to make the prints optional:-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459442&group_id=5470 From noreply@sourceforge.net Fri Nov 16 10:24:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Nov 2001 02:24:13 -0800 Subject: [Patches] [ python-Patches-482424 ] Add system() lookalike for MPW tools Message-ID: Patches item #482424, was opened at 2001-11-16 02:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=482424&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Add system() lookalike for MPW tools Initial Comment: Daniel Brotsky contributed this routine that can start MPW tools, somewhat similar to os.system() on unix. Add it to the contrib stuff. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=482424&group_id=5470 From noreply@sourceforge.net Sun Nov 18 13:39:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Nov 2001 05:39:20 -0800 Subject: [Patches] [ python-Patches-483059 ] Avoid use of eval() in random.py Message-ID: Patches item #483059, was opened at 2001-11-18 05:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483059&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Nobody/Anonymous (nobody) Summary: Avoid use of eval() in random.py Initial Comment: Calling eval() in the main code of random.py makes the module unnecessary slow on jython and prevent the module from being used in applets. This patch avoids the eval() call by passing the computed value as an argument to _verify(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483059&group_id=5470 From noreply@sourceforge.net Sun Nov 18 15:41:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Nov 2001 07:41:15 -0800 Subject: [Patches] [ python-Patches-483085 ] Include windows default temp dir Message-ID: Patches item #483085, was opened at 2001-11-18 07:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483085&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Emile van Sebille (evansebille) Assigned to: Nobody/Anonymous (nobody) Summary: Include windows default temp dir Initial Comment: Include os.getenv('TEMP') in attempdirs so that temp files by default are created per the environment setting. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483085&group_id=5470 From DoNotReplyByEmail@yahoo.com Mon Nov 19 06:15:42 2001 From: DoNotReplyByEmail@yahoo.com (DoNotReplyByEmail@yahoo.com) Date: Mon, 19 Nov 01 01:15:42 EST Subject: [Patches] >>>ADVERTISE TO 11,295,000 PEOPLE FREE! Message-ID: <3791856948.991306994491@m0.net Received: from dialup-62.215.274.4.dial1.stamford ([62.215.274.4] > Dear patches@python.org, *********************************************************** Would you like to send an Email Advertisement to OVER 11 MILLION PEOPLE DAILY for FREE? *********************************************************** Do you have a product or service to sell? Do you want an extra 100 orders per week? NOTE: (If you do not already have a product or service to sell, we can supply you with one). ========================================================= 1) Let's say you... Sell a $24.95 PRODUCT or SERVICE. 2) Let's say you... Broadcast Email to only 500,000 PEOPLE. 3) Let's say you... Receive JUST 1 ORDER for EVERY 2,500 EMAILS. CALCULATION OF YOUR EARNINGS BASED ON THE ABOVE STATISTICS: [Day 1]: $4,990 [Week 1]: $34,930 [Month 1]: $139,720 ======================================================== To start increasing your sales today, please visit our web site or click the link below. http://www.bigcashtoday.com/package1.htm List Removal Instructions: We hope you enjoyed receiving this message. However, if you'd rather not receive future e-mails of this sort from Internet Specialists, send an email to freeemailsoftware3@excite.com and type "remove" in the "subject" line and you will be removed from any future mailings. We hope you have a great day! Internet Specialists From noreply@sourceforge.net Mon Nov 19 15:46:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Nov 2001 07:46:52 -0800 Subject: [Patches] [ python-Patches-483466 ] Import from Zip Archive Message-ID: Patches item #483466, was opened at 2001-11-19 07:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483466&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: James C. Ahlstrom (ahlstromjc) Assigned to: Nobody/Anonymous (nobody) Summary: Import from Zip Archive Initial Comment: This is the "final" patch to import.c to support imports from zip archives and directory caching using os.listdir(). It replaces patch 476047. It it intended to be part of Python 2.3. There are five files requiring patches, and these are in context diff's in five separate attached files. I have tested this on Linux and Windows 2000. It needs testing on bigendian machines, and those with 64-bit integers. Please complain about bugs, but let me know if you plan to change the code. The documentation for the imp module needs a patch. This is added right after "PY_FROZEN": PY_ZIPFILE The module was found in a zip archive file. BUGS ==== There are a couple of bugs I wasn't sure were worth fixing. Please complain if these are a problem: The use of os.listdir() for normal directory imports makes case_ok() unnecessary, but it was not removed. It might be needed if os.listdir() is missing. There is no problem if os.listdir() doesn't exist, but if it exists, it must perform as documented, and must return both file and directory names in their correct case. The PYTHONCASEOK flag is ineffective. This is a consequence of dictionary name lookup. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483466&group_id=5470 From noreply@sourceforge.net Tue Nov 20 14:00:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Nov 2001 06:00:55 -0800 Subject: [Patches] [ python-Patches-415227 ] Solaris pkgtool bdist command Message-ID: Patches item #415227, was opened at 2001-04-10 12:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415227&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Mark Alexander (mwa) >Assigned to: M.-A. Lemburg (lemburg) Summary: Solaris pkgtool bdist command Initial Comment: The bdist_pktool command is based on bdist_packager and provides support for the Solaris pkgadd and pkgrm commands. In most cases, no additional options beyond the PEP 241 options are required. An exception is if the package name is >9 characters, a --pkg-abrev option is required because that's all pkgtool will handle. It makes listing the packages on the system a pain, but the actual package files produced do match name-version-revision-pyvers.pkg format. By default, bdist_pkgtool provides request, postinstall, preremove, and postremove scripts that will properly relocate modules to the site-packages directory and recompile all .py modules on the target machine. An author can provide a custom request script and either have it auto-relocate by merging the scripts, or inhibit auto-relocation with --no-autorelocate. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-20 06:00 Message: Logged In: YES user_id=38388 Hijacking this patch to take load off of Andrew. This patch should be reviewed after the Python 2.2 feature freeze. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-06 22:39 Message: Logged In: YES user_id=21627 Should there also be some Makefile machinery to create a Solaris package for python itself? There is a 1.6a2 package on sunfreeware; it would surely help if building Solaris packages was supported by the Python core itself. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415227&group_id=5470 From noreply@sourceforge.net Tue Nov 20 14:01:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Nov 2001 06:01:03 -0800 Subject: [Patches] [ python-Patches-415228 ] HP-UX packaging command Message-ID: Patches item #415228, was opened at 2001-04-10 12:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415228&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Mark Alexander (mwa) >Assigned to: M.-A. Lemburg (lemburg) Summary: HP-UX packaging command Initial Comment: The bdist_sdux (SD-UX is HP's packager) command is based on bdist_packager and provides the same functionality as the bdist_pkgtool command, except the resulting packages cannot auto-relocate. Instead, a checkinstall script is included by default that determines of the target machines python installation matches that of the creating machine. If not, it bails out and provides the installer with the correct version of the swinstall command to place it in the proper directory. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-20 06:01 Message: Logged In: YES user_id=38388 Hijacking this patch to take load off of Andrew. This patch should be reviewed after the Python 2.2 feature freeze. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:18 Message: Logged In: YES user_id=6380 Please select the proper category when submitting patches! This is clearly a distutils thing. Assigned to Andrew. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415228&group_id=5470 From noreply@sourceforge.net Tue Nov 20 14:49:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Nov 2001 06:49:23 -0800 Subject: [Patches] [ python-Patches-483466 ] Import from Zip Archive Message-ID: Patches item #483466, was opened at 2001-11-19 07:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483466&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: James C. Ahlstrom (ahlstromjc) Assigned to: Nobody/Anonymous (nobody) Summary: Import from Zip Archive Initial Comment: This is the "final" patch to import.c to support imports from zip archives and directory caching using os.listdir(). It replaces patch 476047. It it intended to be part of Python 2.3. There are five files requiring patches, and these are in context diff's in five separate attached files. I have tested this on Linux and Windows 2000. It needs testing on bigendian machines, and those with 64-bit integers. Please complain about bugs, but let me know if you plan to change the code. The documentation for the imp module needs a patch. This is added right after "PY_FROZEN": PY_ZIPFILE The module was found in a zip archive file. BUGS ==== There are a couple of bugs I wasn't sure were worth fixing. Please complain if these are a problem: The use of os.listdir() for normal directory imports makes case_ok() unnecessary, but it was not removed. It might be needed if os.listdir() is missing. There is no problem if os.listdir() doesn't exist, but if it exists, it must perform as documented, and must return both file and directory names in their correct case. The PYTHONCASEOK flag is ineffective. This is a consequence of dictionary name lookup. ---------------------------------------------------------------------- >Comment By: James C. Ahlstrom (ahlstromjc) Date: 2001-11-20 06:49 Message: Logged In: YES user_id=64929 The zero length string "" is not handled correctly as an item of sys.path. It should mean current directory, but its contents will not be cached. What happens if the current directory changes? Should the new directory be searched, or only the original current directory? I will submit a further patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483466&group_id=5470 From noreply@sourceforge.net Tue Nov 20 17:43:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Nov 2001 09:43:01 -0800 Subject: [Patches] [ python-Patches-483864 ] Pure python version of calendar.weekday Message-ID: Patches item #483864, was opened at 2001-11-20 09:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483864&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Pure python version of calendar.weekday Initial Comment: this version can handle past of 1970, and PURE. but this is not too slower than old one. NetBSD machine on Pentium 90MHz: $ python wday.py 1000 Time Module: 0.641623973846 Pure Python: 0.724056005478 $ python wday.py 10000 Time Module: 6.77021896839 Pure Python: 7.34891104698 Linux machine on Pentium III 800MHz: $ python wday.py 10000 Time Module: 0.611389994621 Pure Python: 0.833150982857 $ python wday.py 100000 Time Module: 6.12289500237 Pure Python: 8.36460494995 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483864&group_id=5470 From noreply@sourceforge.net Tue Nov 20 17:51:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Nov 2001 09:51:06 -0800 Subject: [Patches] [ python-Patches-483864 ] Pure python version of calendar.weekday Message-ID: Patches item #483864, was opened at 2001-11-20 09:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483864&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Pure python version of calendar.weekday Initial Comment: this version can handle past of 1970, and PURE. but this is not too slower than old one. NetBSD machine on Pentium 90MHz: $ python wday.py 1000 Time Module: 0.641623973846 Pure Python: 0.724056005478 $ python wday.py 10000 Time Module: 6.77021896839 Pure Python: 7.34891104698 Linux machine on Pentium III 800MHz: $ python wday.py 10000 Time Module: 0.611389994621 Pure Python: 0.833150982857 $ python wday.py 100000 Time Module: 6.12289500237 Pure Python: 8.36460494995 ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2001-11-20 09:51 Message: Logged In: YES user_id=55188 upper one of two patches is using if - if. another is using and - or. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483864&group_id=5470 From noreply@sourceforge.net Tue Nov 20 23:39:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Nov 2001 15:39:29 -0800 Subject: [Patches] [ python-Patches-483982 ] Python 2.2b2 bdist_wininst crashes Message-ID: Patches item #483982, was opened at 2001-11-20 15:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483982&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tarn Weisner Burton (twburton) Assigned to: A.M. Kuchling (akuchling) Summary: Python 2.2b2 bdist_wininst crashes Initial Comment: The executable created by Python 2.2b2 bdist_wininst crashes on my system. Python 2.1's version works fine. This could just be my system and I can recompile the installer to test that, if that's needed, but after I looked into CVS I noted that it looks like wininst.exe has been checked in as a text file....hmmm I've attached a minimal dist which exhibits to problem. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483982&group_id=5470 From noreply@sourceforge.net Thu Nov 22 00:16:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Nov 2001 16:16:49 -0800 Subject: [Patches] [ python-Patches-483982 ] Python 2.2b2 bdist_wininst crashes Message-ID: Patches item #483982, was opened at 2001-11-20 15:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483982&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tarn Weisner Burton (twburton) Assigned to: A.M. Kuchling (akuchling) Summary: Python 2.2b2 bdist_wininst crashes Initial Comment: The executable created by Python 2.2b2 bdist_wininst crashes on my system. Python 2.1's version works fine. This could just be my system and I can recompile the installer to test that, if that's needed, but after I looked into CVS I noted that it looks like wininst.exe has been checked in as a text file....hmmm I've attached a minimal dist which exhibits to problem. ---------------------------------------------------------------------- >Comment By: Tarn Weisner Burton (twburton) Date: 2001-11-21 16:16 Message: Logged In: YES user_id=21784 Looks like I put this under Patches instead of Bugs. Sorry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483982&group_id=5470 From DoNotReplyByEmail@yahoo.com Thu Nov 22 06:10:15 2001 From: DoNotReplyByEmail@yahoo.com (DoNotReplyByEmail@yahoo.com) Date: Thu, 22 Nov 01 01:10:15 EST Subject: [Patches] >>>ADVERTISE TO 11,295,000 PEOPLE FREE! Message-ID: <3791856948.991306994491@m0.net Received: from dialup-62.215.274.4.dial1.stamford ([62.215.274.4] > Dear patches@python.org, *********************************************************** Would you like to send an Email Advertisement to OVER 11 MILLION PEOPLE DAILY for FREE? *********************************************************** Do you have a product or service to sell? Do you want an extra 100 orders per week? NOTE: (If you do not already have a product or service to sell, we can supply you with one). ========================================================= 1) Let's say you... Sell a $24.95 PRODUCT or SERVICE. 2) Let's say you... Broadcast Email to only 500,000 PEOPLE. 3) Let's say you... Receive JUST 1 ORDER for EVERY 2,500 EMAILS. CALCULATION OF YOUR EARNINGS BASED ON THE ABOVE STATISTICS: [Day 1]: $4,990 [Week 1]: $34,930 [Month 1]: $139,720 ======================================================== To find out more information, Do not respond by email. Instead, Please visit our web site at: http://www.bigcashtoday.com/package1.htm List Removal Instructions: We hope you enjoyed receiving this message. However, if you'd rather not receive future e-mails of this sort from Internet Specialists, send an email to freeemailsoftware3@excite.com and type "remove" in the "subject" line and you will be removed from any future mailings. We hope you have a great day! Internet Specialists From noreply@sourceforge.net Fri Nov 23 12:32:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Nov 2001 04:32:03 -0800 Subject: [Patches] [ python-Patches-484847 ] Support for OS/2 in webbrowser.open(url) Message-ID: Patches item #484847, was opened at 2001-11-23 04:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=484847&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan Schwarzer (sschwarzer) Assigned to: Nobody/Anonymous (nobody) Summary: Support for OS/2 in webbrowser.open(url) Initial Comment: Added rudimentary support for the webbrowser module to launch URLs with Netscape on OS/2 (the there by far most installed browser). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=484847&group_id=5470 From noreply@sourceforge.net Fri Nov 23 21:28:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Nov 2001 13:28:20 -0800 Subject: [Patches] [ python-Patches-484986 ] Add PanedWindow to Demos/tix Message-ID: Patches item #484986, was opened at 2001-11-23 13:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=484986&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Add PanedWindow to Demos/tix Initial Comment: Translate another demo to Python - PanedWindow. Minor changes to Tix.py to add methods to RefHandle, and work around what may be an incompleteness in Tix. Bulletproof tixwidgets.py demo program and fix a longstanding bug in the Scrolled Widgets/ScrolledWindow demo. In all previous versions the image was not showing up in the scrolled window - no problem in the Tcl version of Tix. Please look at the way I fixed this - look for the global variable image1. Perhaps there is a better way of fixing this problem, or else it points towards a problem with Tkinter itself. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=484986&group_id=5470 From noreply@sourceforge.net Sat Nov 24 09:45:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 24 Nov 2001 01:45:14 -0800 Subject: [Patches] [ python-Patches-484847 ] Support for OS/2 in webbrowser.open(url) Message-ID: Patches item #484847, was opened at 2001-11-23 04:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=484847&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan Schwarzer (sschwarzer) Assigned to: Nobody/Anonymous (nobody) Summary: Support for OS/2 in webbrowser.open(url) Initial Comment: Added rudimentary support for the webbrowser module to launch URLs with Netscape on OS/2 (the there by far most installed browser). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-11-24 01:45 Message: Logged In: YES user_id=21627 Why doesn't this use the Netscape class? Is the -remote feature working on OS/2? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=484847&group_id=5470 From noreply@sourceforge.net Sat Nov 24 09:47:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 24 Nov 2001 01:47:26 -0800 Subject: [Patches] [ python-Patches-483059 ] Avoid use of eval() in random.py Message-ID: Patches item #483059, was opened at 2001-11-18 05:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483059&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Nobody/Anonymous (nobody) Summary: Avoid use of eval() in random.py Initial Comment: Calling eval() in the main code of random.py makes the module unnecessary slow on jython and prevent the module from being used in applets. This patch avoids the eval() call by passing the computed value as an argument to _verify(). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-11-24 01:47 Message: Logged In: YES user_id=21627 Can you please indicate whether you want to see this patch in 2.2? I would propose to postpone the patch past 2.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483059&group_id=5470 From noreply@sourceforge.net Sat Nov 24 09:48:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 24 Nov 2001 01:48:43 -0800 Subject: [Patches] [ python-Patches-481718 ] Time module doc string changes. Message-ID: Patches item #481718, was opened at 2001-11-14 07:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481718&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: Time module doc string changes. Initial Comment: Made the doc-strings for time.localtime() and time.gmtime() list the elements of the tuple they return. This is what the os.stat() doc-string does, and it's supremely useful when combined with "pydoc". Also added a newline after the first line of a couple of doc-strings, so that they all have the same format (summary line, blank line, details). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-24 01:48 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481718&group_id=5470 From noreply@sourceforge.net Sat Nov 24 09:51:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 24 Nov 2001 01:51:02 -0800 Subject: [Patches] [ python-Patches-481520 ] System V IPC bindings for python Message-ID: Patches item #481520, was opened at 2001-11-13 15:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481520&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: System V IPC bindings for python Initial Comment: This patch adds System V IPC bindings to python. I submitted it a while ago but it got ignored. The functionality is useful and allows better interoperability. I resubmit it because someone just wrote to me to say they wanted a copy but couldn't find it anyway ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-11-24 01:51 Message: Logged In: YES user_id=21627 Closing the patch, it seems the submitter did not read the follow-ups, and I agree that such code would need to finder broader acceptance before being integrated into the distribution, anyway. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-14 00:55 Message: Logged In: YES user_id=38388 You seem to have forgotten to attach the patch. In any case, I'd suggest to look into submitting your code to Parnassus. That way people will find it more easily; even if it doesn't get incorporated into the Python core. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481520&group_id=5470 From noreply@sourceforge.net Sat Nov 24 10:10:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 24 Nov 2001 02:10:31 -0800 Subject: [Patches] [ python-Patches-473512 ] getopt with GNU style scanning Message-ID: Patches item #473512, was opened at 2001-10-21 14:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473512&group_id=5470 Category: Library (Lib) Group: None Status: Open >Resolution: Postponed Priority: 5 Submitted By: Peter Åstrand (astrand) Assigned to: Nobody/Anonymous (nobody) Summary: getopt with GNU style scanning Initial Comment: Implements GNU style scanning mode. The traditional mode is used if the option string begins with + or if the environment variable POSIXLY_CORRECT is set, just like GNU getopt. Patch includes updated documentation and test. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-11-24 02:10 Message: Logged In: YES user_id=21627 The patch looks good to me. Since it introduces a new feature, it will be postponed after 2.2 (negotiate with the 2.2 release manager if you want to see it included). Notice that it doesn't offer all features of GNU getopt. It doesn't support the getopt_long_only mechanism (where all options are long, even if they have a single - only). Further, it doesn't allow the caller to specify ordering, and it doesn't support the RETURN_IN_ORDER option (which would be difficult to support with the current calling convention, though). I'm not asking that these problems are somehow resolved; they are meant as proposals for improvements only. ---------------------------------------------------------------------- Comment By: Peter Åstrand (astrand) Date: 2001-11-11 08:09 Message: Logged In: YES user_id=344921 The new patch uses a new function, gnu_getopt, instead of changing the default behaviour. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-21 17:37 Message: Logged In: YES user_id=6380 Rejected in this form. We can't suddenly change the default behavior. If you want a way to support GNU style options (which I personally hate, but which I would accept as an option), try adding a different function (e.g. gnu_getopt(...)) or add a flag argument (e.g. getopt(..., gnu=1)). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473512&group_id=5470 From noreply@sourceforge.net Sat Nov 24 13:33:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 24 Nov 2001 05:33:54 -0800 Subject: [Patches] [ python-Patches-483059 ] Avoid use of eval() in random.py Message-ID: Patches item #483059, was opened at 2001-11-18 05:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483059&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Nobody/Anonymous (nobody) Summary: Avoid use of eval() in random.py Initial Comment: Calling eval() in the main code of random.py makes the module unnecessary slow on jython and prevent the module from being used in applets. This patch avoids the eval() call by passing the computed value as an argument to _verify(). ---------------------------------------------------------------------- >Comment By: Finn Bock (bckfnn) Date: 2001-11-24 05:33 Message: Logged In: YES user_id=4201 Post 2.2 is fine. We have already added the patch to jython version of random.py, the patch to CPython is mainly to ensure that the two versions doesn't drift apart. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-24 01:47 Message: Logged In: YES user_id=21627 Can you please indicate whether you want to see this patch in 2.2? I would propose to postpone the patch past 2.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483059&group_id=5470 From noreply@sourceforge.net Sat Nov 24 15:37:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 24 Nov 2001 07:37:44 -0800 Subject: [Patches] [ python-Patches-484847 ] Support for OS/2 in webbrowser.open(url) Message-ID: Patches item #484847, was opened at 2001-11-23 04:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=484847&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan Schwarzer (sschwarzer) Assigned to: Nobody/Anonymous (nobody) Summary: Support for OS/2 in webbrowser.open(url) Initial Comment: Added rudimentary support for the webbrowser module to launch URLs with Netscape on OS/2 (the there by far most installed browser). ---------------------------------------------------------------------- >Comment By: Stefan Schwarzer (sschwarzer) Date: 2001-11-24 07:37 Message: Logged In: YES user_id=383516 The Netscape class doesn't seem to work on OS/2 because the class is too Unix-centric. This works: >>> import os >>> os.system('e:/netscape/program/netscape.exe http://www.python.org/') 0 while this does not: >>> ns = webbrowser.Netscape('e:/netscape/program/netscape.exe') >>> ns.open('http://www.python.org/') SYS0003: The system cannot find the path specified. SYS0003: The system cannot find the path specified. It seems, Netscape on OS/2 is a different thing that the Unix version; e. g. it doesn't understand the Unix options. For example, >>> os.system('e:/netscape/program/netscape.exe -raise http://www.python.org/') 0 "works" but "-raise" seems to be interpreted as an URL; the above call starts Netscape with the (smartbrowsing-generated) URL http://keyword.netscape.com/kwserr.tmpl?kw=%2Draise+http%3A%2F%2Fwww%2Epython%2Eorg%2F Turning "off"(?) smartbrowsing gives http://search.netscape.com/search.psp?cp=clkussrp&charset=UTF-8&search=-raise+http//www.python.org/ which is also not what I want. ;-) -remote doesn't work either. Because of these problems I thought it would be the easiest to use the GenericBrowser class, assuming that most or all of the special functionality of the Netscape class doesn't work. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-24 01:45 Message: Logged In: YES user_id=21627 Why doesn't this use the Netscape class? Is the -remote feature working on OS/2? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=484847&group_id=5470 From noreply@sourceforge.net Sun Nov 25 14:37:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 25 Nov 2001 06:37:12 -0800 Subject: [Patches] [ python-Patches-484847 ] Support for OS/2 in webbrowser.open(url) Message-ID: Patches item #484847, was opened at 2001-11-23 04:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=484847&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Stefan Schwarzer (sschwarzer) Assigned to: Nobody/Anonymous (nobody) Summary: Support for OS/2 in webbrowser.open(url) Initial Comment: Added rudimentary support for the webbrowser module to launch URLs with Netscape on OS/2 (the there by far most installed browser). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-11-25 06:37 Message: Logged In: YES user_id=21627 That fine then. Thanks for the patch, committed as webbrowser.py 1.23, NEWS 1.319. ---------------------------------------------------------------------- Comment By: Stefan Schwarzer (sschwarzer) Date: 2001-11-24 07:37 Message: Logged In: YES user_id=383516 The Netscape class doesn't seem to work on OS/2 because the class is too Unix-centric. This works: >>> import os >>> os.system('e:/netscape/program/netscape.exe http://www.python.org/') 0 while this does not: >>> ns = webbrowser.Netscape('e:/netscape/program/netscape.exe') >>> ns.open('http://www.python.org/') SYS0003: The system cannot find the path specified. SYS0003: The system cannot find the path specified. It seems, Netscape on OS/2 is a different thing that the Unix version; e. g. it doesn't understand the Unix options. For example, >>> os.system('e:/netscape/program/netscape.exe -raise http://www.python.org/') 0 "works" but "-raise" seems to be interpreted as an URL; the above call starts Netscape with the (smartbrowsing-generated) URL http://keyword.netscape.com/kwserr.tmpl?kw=%2Draise+http%3A%2F%2Fwww%2Epython%2Eorg%2F Turning "off"(?) smartbrowsing gives http://search.netscape.com/search.psp?cp=clkussrp&charset=UTF-8&search=-raise+http//www.python.org/ which is also not what I want. ;-) -remote doesn't work either. Because of these problems I thought it would be the easiest to use the GenericBrowser class, assuming that most or all of the special functionality of the Netscape class doesn't work. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-24 01:45 Message: Logged In: YES user_id=21627 Why doesn't this use the Netscape class? Is the -remote feature working on OS/2? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=484847&group_id=5470 From noreply@sourceforge.net Sun Nov 25 15:02:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 25 Nov 2001 07:02:45 -0800 Subject: [Patches] [ python-Patches-484986 ] Add PanedWindow to Demos/tix Message-ID: Patches item #484986, was opened at 2001-11-23 13:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=484986&group_id=5470 Category: Tkinter Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Add PanedWindow to Demos/tix Initial Comment: Translate another demo to Python - PanedWindow. Minor changes to Tix.py to add methods to RefHandle, and work around what may be an incompleteness in Tix. Bulletproof tixwidgets.py demo program and fix a longstanding bug in the Scrolled Widgets/ScrolledWindow demo. In all previous versions the image was not showing up in the scrolled window - no problem in the Tcl version of Tix. Please look at the way I fixed this - look for the global variable image1. Perhaps there is a better way of fixing this problem, or else it points towards a problem with Tkinter itself. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-11-25 07:02 Message: Logged In: YES user_id=21627 Thanks, applied as Tix.py 1.6, tixwidgets.py 1.3, PanedWin.py 1.1, NEWS 1.320. As for image1: It is not necessary to declare a global variable global on the global level; just assign to it (I've left it in the code). I believe keeping it global is necessary because otherwise, the reference to the Image Python object is dropped (_tkinter does not hold a reference), which in turn leads to an invocation of "image delete" inside Tkinter.Image.__del__. The same problem does not show up under Tcl since nobody would even consider deleting the image there, anyway. It probably would be best if Tk would reference-count images. That would mean that you could delete the Tcl image name, while preserving the image object as long as it is used in another widget. Since tixwidgets.py wouldn't win a beauty contest, solving this problem isn't really urgent, IMO. One solution would be to tie the lifetime of the image object to the one of the label, e.g. by saying lbl.image = image1 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=484986&group_id=5470 From noreply@sourceforge.net Sun Nov 25 21:13:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 25 Nov 2001 13:13:22 -0800 Subject: [Patches] [ python-Patches-483059 ] Avoid use of eval() in random.py Message-ID: Patches item #483059, was opened at 2001-11-18 05:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483059&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Finn Bock (bckfnn) >Assigned to: Tim Peters (tim_one) Summary: Avoid use of eval() in random.py Initial Comment: Calling eval() in the main code of random.py makes the module unnecessary slow on jython and prevent the module from being used in applets. This patch avoids the eval() call by passing the computed value as an argument to _verify(). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-11-25 13:13 Message: Logged In: YES user_id=31435 Accepted and closed. It's hard to buy the speed argument, since these are one-shot module initialization costs. But the use of "eval" here was pointless, obscure, and mildly disgusting. python/Lib/random.py; new revision: 1.26 ---------------------------------------------------------------------- Comment By: Finn Bock (bckfnn) Date: 2001-11-24 05:33 Message: Logged In: YES user_id=4201 Post 2.2 is fine. We have already added the patch to jython version of random.py, the patch to CPython is mainly to ensure that the two versions doesn't drift apart. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-24 01:47 Message: Logged In: YES user_id=21627 Can you please indicate whether you want to see this patch in 2.2? I would propose to postpone the patch past 2.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483059&group_id=5470 From noreply@sourceforge.net Mon Nov 26 09:47:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 26 Nov 2001 01:47:58 -0800 Subject: [Patches] [ python-Patches-481718 ] Time module doc string changes. Message-ID: Patches item #481718, was opened at 2001-11-14 07:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481718&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: Time module doc string changes. Initial Comment: Made the doc-strings for time.localtime() and time.gmtime() list the elements of the tuple they return. This is what the os.stat() doc-string does, and it's supremely useful when combined with "pydoc". Also added a newline after the first line of a couple of doc-strings, so that they all have the same format (summary line, blank line, details). ---------------------------------------------------------------------- >Comment By: Sean Reifschneider (jafo) Date: 2001-11-26 01:47 Message: Logged In: YES user_id=81797 The file has been attached. Sorry about that. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-24 01:48 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481718&group_id=5470 From noreply@sourceforge.net Mon Nov 26 12:03:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 26 Nov 2001 04:03:35 -0800 Subject: [Patches] [ python-Patches-485572 ] Distutils -- set runtime library path Message-ID: Patches item #485572, was opened at 2001-11-26 04:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485572&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Everson (reverson) Assigned to: Nobody/Anonymous (nobody) Summary: Distutils -- set runtime library path Initial Comment: The runtime libraries option to Distutils Extension currently fails with gcc (on Linux at least) because, despite what "info gcc" says, gcc -R/run/time/lib/path doesn't get relayed to the loader to set the runtime libraries search path. In order to correctly pass the -R to the loader you need gcc -Wl,-R/run/time/lib/path There is something mentioning the -Wl, option in cygwinccompiler.py but it is commented out. The attached patch works for me on a Linux or Solaris box, but I haven't tested it more extensively than that. It is against $Id: extension.py,v 1.8 2001/03/22 03:48:31 akuchling Exp $ from the python-2.1.1 distribution. Also I'm not sure of the "correct" way of deducing what compiler is being used -- I hope the get_config_var() route is acceptable. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485572&group_id=5470 From noreply@sourceforge.net Mon Nov 26 13:14:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 26 Nov 2001 05:14:18 -0800 Subject: [Patches] [ python-Patches-485572 ] Distutils -- set runtime library path Message-ID: Patches item #485572, was opened at 2001-11-26 04:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485572&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Everson (reverson) >Assigned to: M.-A. Lemburg (lemburg) Summary: Distutils -- set runtime library path Initial Comment: The runtime libraries option to Distutils Extension currently fails with gcc (on Linux at least) because, despite what "info gcc" says, gcc -R/run/time/lib/path doesn't get relayed to the loader to set the runtime libraries search path. In order to correctly pass the -R to the loader you need gcc -Wl,-R/run/time/lib/path There is something mentioning the -Wl, option in cygwinccompiler.py but it is commented out. The attached patch works for me on a Linux or Solaris box, but I haven't tested it more extensively than that. It is against $Id: extension.py,v 1.8 2001/03/22 03:48:31 akuchling Exp $ from the python-2.1.1 distribution. Also I'm not sure of the "correct" way of deducing what compiler is being used -- I hope the get_config_var() route is acceptable. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-26 05:14 Message: Logged In: YES user_id=38388 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485572&group_id=5470 From noreply@sourceforge.net Mon Nov 26 13:15:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 26 Nov 2001 05:15:21 -0800 Subject: [Patches] [ python-Patches-485572 ] Distutils -- set runtime library path Message-ID: Patches item #485572, was opened at 2001-11-26 04:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485572&group_id=5470 Category: None Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Richard Everson (reverson) Assigned to: M.-A. Lemburg (lemburg) Summary: Distutils -- set runtime library path Initial Comment: The runtime libraries option to Distutils Extension currently fails with gcc (on Linux at least) because, despite what "info gcc" says, gcc -R/run/time/lib/path doesn't get relayed to the loader to set the runtime libraries search path. In order to correctly pass the -R to the loader you need gcc -Wl,-R/run/time/lib/path There is something mentioning the -Wl, option in cygwinccompiler.py but it is commented out. The attached patch works for me on a Linux or Solaris box, but I haven't tested it more extensively than that. It is against $Id: extension.py,v 1.8 2001/03/22 03:48:31 akuchling Exp $ from the python-2.1.1 distribution. Also I'm not sure of the "correct" way of deducing what compiler is being used -- I hope the get_config_var() route is acceptable. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-26 05:15 Message: Logged In: YES user_id=38388 I'll look into this after the Python 2.2 feature freeze. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-26 05:14 Message: Logged In: YES user_id=38388 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485572&group_id=5470 From noreply@sourceforge.net Mon Nov 26 13:43:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 26 Nov 2001 05:43:05 -0800 Subject: [Patches] [ python-Patches-485572 ] Distutils -- set runtime library path Message-ID: Patches item #485572, was opened at 2001-11-26 04:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485572&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Richard Everson (reverson) Assigned to: M.-A. Lemburg (lemburg) Summary: Distutils -- set runtime library path Initial Comment: The runtime libraries option to Distutils Extension currently fails with gcc (on Linux at least) because, despite what "info gcc" says, gcc -R/run/time/lib/path doesn't get relayed to the loader to set the runtime libraries search path. In order to correctly pass the -R to the loader you need gcc -Wl,-R/run/time/lib/path There is something mentioning the -Wl, option in cygwinccompiler.py but it is commented out. The attached patch works for me on a Linux or Solaris box, but I haven't tested it more extensively than that. It is against $Id: extension.py,v 1.8 2001/03/22 03:48:31 akuchling Exp $ from the python-2.1.1 distribution. Also I'm not sure of the "correct" way of deducing what compiler is being used -- I hope the get_config_var() route is acceptable. ---------------------------------------------------------------------- >Comment By: Richard Everson (reverson) Date: 2001-11-26 05:43 Message: Logged In: YES user_id=385419 Sorry about the lack of the patch -- I pressed submit too soon. It should now be attached. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-26 05:15 Message: Logged In: YES user_id=38388 I'll look into this after the Python 2.2 feature freeze. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-26 05:14 Message: Logged In: YES user_id=38388 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485572&group_id=5470 From noreply@sourceforge.net Mon Nov 26 21:48:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 26 Nov 2001 13:48:50 -0800 Subject: [Patches] [ python-Patches-485789 ] webbrowser.py: os.pathsep instead of : Message-ID: Patches item #485789, was opened at 2001-11-26 13:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485789&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan Schwarzer (sschwarzer) Assigned to: Nobody/Anonymous (nobody) Summary: webbrowser.py: os.pathsep instead of : Initial Comment: Line 317 (in CVS rev. 1.23) should be _tryorder = os.environ["BROWSER"].split(os.pathsep) instead of _tryorder = os.environ["BROWSER"].split(":") ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485789&group_id=5470 From noreply@sourceforge.net Mon Nov 26 22:04:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 26 Nov 2001 14:04:38 -0800 Subject: [Patches] [ python-Patches-485794 ] calendar.isleap should return 1 not true Message-ID: Patches item #485794, was opened at 2001-11-26 14:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485794&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan Schwarzer (sschwarzer) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: calendar.isleap should return 1 not true Initial Comment: The documentation for calendar.isleap should state the function returns 1, not only true. The documentation says only that calendar.isleap returns true if the year is a leap year. The docstring is more specific and speaks of 1 vs. 0. The latter is convenient for days_in_february = 28 + calendar.isleap(year) However, if the docstring describes only the - possibly changing - implementation you would strictly have to write the much more verbose if calendar.isleap(year): days_in_february = 29 else: days_in_february = 28 (Is the actual interface of calendar.isleap going to change? (I don't think so.)) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485794&group_id=5470 From noreply@sourceforge.net Tue Nov 27 11:16:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 27 Nov 2001 03:16:51 -0800 Subject: [Patches] [ python-Patches-485959 ] Final set of patches to Demo/tix Message-ID: Patches item #485959, was opened at 2001-11-27 03:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485959&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Final set of patches to Demo/tix Initial Comment: Final set of patches to Demo/tix - this should be it for a while. Tix.py: Fixed tix_configure and fixed some of the doc strings. tixwidgets.py: fixed loop, added some more docstrings, and made some progress on the global image1 problem. Look for the code around 'if 0:' - it may point towards a bug in Tkinter. Image class. Also if I can understand this proble, maybe I can solve the long outstanding bug described in Demo/tix/BUG.txt. samples/ Fixed SHList1 and 2 not quiting when run from samples/ and fixed a bug in all of the demos that was leaving zombie pythonw processes under Windows in 2.1.0 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485959&group_id=5470 From noreply@sourceforge.net Tue Nov 27 20:10:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 27 Nov 2001 12:10:16 -0800 Subject: [Patches] [ python-Patches-486079 ] poplib contains unuseable code Message-ID: Patches item #486079, was opened at 2001-11-27 09:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486079&group_id=5470 >Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jon Nelson (jnelson) Assigned to: Nobody/Anonymous (nobody) Summary: poplib contains unuseable code Initial Comment: poplib contains a number of debugging statements, quite useful for debugging, which are turned on via the set_debuglevel function. However, all of the debug statements have been commented out, making it impossible to debug properly. Included is a patch which uncomments the commented code, but does *not* change default behavior. However, if someone issues the set_debuglevel(int N) function, then debugging works, just like the documentation and logic says it should. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:10 Message: Logged In: YES user_id=31435 Recategorized this as a patch. Note that it won't be considered for 2.2 (too late). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486079&group_id=5470 From noreply@sourceforge.net Tue Nov 27 21:54:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 27 Nov 2001 13:54:42 -0800 Subject: [Patches] [ python-Patches-401022 ] Removal of SET_LINENO (experimental) Message-ID: Patches item #401022, was opened at 2000-07-30 16:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401022&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: Out of Date Priority: 5 Submitted By: Vladimir Marangozov (marangoz) >Assigned to: Nobody/Anonymous (nobody) Summary: Removal of SET_LINENO (experimental) Initial Comment: ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-11-27 13:54 Message: Logged In: YES user_id=31435 Unassigned again -- I'm not gonna get to this in this lifetime. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-10 11:51 Message: Logged In: YES user_id=6380 Tim wants to revisit this. It could be the quickest way to a 7% speedup in pystone that we can think of... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-11-13 11:42 Message: Rejected. It's in the archives for reference, but for now, I don't think it's worth spending cycles worrying about this kind of stuff. I'll eventually redesign the entire VM. ---------------------------------------------------------------------- Comment By: Vladimir Marangozov (marangoz) Date: 2000-10-27 04:08 Message: Oops, the last patch update does not contain the f.f_lineno computation in frame_getattr. This is necessary, cf. the following messages: http://www.python.org/pipermail/python-dev/2000-July/014395.html http://www.python.org/pipermail/python-dev/2000-July/014401.html Patch assigned to Guido, for review or further assignment. ---------------------------------------------------------------------- Comment By: Vladimir Marangozov (marangoz) Date: 2000-10-25 17:42 Message: noreply@sourceforge.net wrote: > > Date: 2000-Oct-25 13:56 > By: gvanrossum > > Comment: > Vladimir, are you there? So-so :) I'm a moving target, checking my mail occasionally these days. Luckily, today is one of these days. > > The patch doesn't apply cleanly to the current CVS tree any more... Ah, this one's easy. Here's an update relative to 2.0 final, not CVS. I got some r/w access error trying to update my CVS copy from SF that I have no time to investigate right now... The Web interface still works though :) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-10-25 13:56 Message: Vladimir, are you there? The patch doesn't apply cleanly to the current CVS tree any more... ---------------------------------------------------------------------- Comment By: Vladimir Marangozov (marangoz) Date: 2000-08-03 12:22 Message: Fix missing DECREF on error condition in start_tracing() + some renaming. ---------------------------------------------------------------------- Comment By: Vladimir Marangozov (marangoz) Date: 2000-07-31 10:50 Message: A last tiny fix of the SET_LINENO opcode for better b/w compatibility. Stopping here and entering standby mode for reactions & feedback. PS: the last idea about not duplicating co_code and tweaking the original with CALL_TRACE is a bad one. I remember Guido being against it because co_code could be used elsewhere (copied, written to disk, whatever) and he's right! Better operate on an internal copy created in ceval. ---------------------------------------------------------------------- Comment By: Vladimir Marangozov (marangoz) Date: 2000-07-31 07:57 Message: Another rewrite, making this whole strategy b/w compatible according to the 1st incompatibility point a) described in: http://www.python.org/pipermail/python-dev/2000-July/014364.html Changes: 1. f.f_lineno is computed and updated on f_lineno attribute requests for f, given f.f_lasti. Correctness is ensured because f.f_lasti is updated on *all* attribute accesses (in LOAD_ATTR in the main loop). 2. The standard setup does not generate SET_LINENO, but uses co_lnotab for computing the source line number (e.g. tracebacks) This is equivalent to the actual "python -O". 3. With "python -d", we fall back to the current version of the interpreter (with SET_LINENO) thus making it easy to test whether this patch fully replaces SET_LINENO's behavior. (modulo f->f_lineno accesses from legacy C code, but this is insane). IMO, this version already worths the pain to be truly tested and improved. One improvement is to define a nicer public C API for breakpoints: - PyCode_SetBreakPointAtLine(line) - PyCode_SetBreakPointAtAddr(addr) or similar, which would install a CALL_TRACE opcode in the appropriate location of the copy of co_code. Another idea is to avoid duplicating the entire co_code just for storing the CALL_TRACE opcodes. We can store them in the original and keep a table of breakpoints. Setting the breakpoints would occur whenever the sys.settrace hook is set. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-07-31 06:40 Message: Status set to postponed to indicate that this is still experimental. ---------------------------------------------------------------------- Comment By: Vladimir Marangozov (marangoz) Date: 2000-07-30 18:16 Message: A nit: inline the argfetch in CALL_TRACE and goto the switch, instead of jumping to get_oparg which splits the sequence [fetch opcode, fetch oparg] -- this can slow things down. ---------------------------------------------------------------------- Comment By: Vladimir Marangozov (marangoz) Date: 2000-07-30 16:12 Message: For testing, as discussed on python-dev. For a gentle summary, see: http://www.python.org/pipermail/python-dev/2000-July/014364.html ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401022&group_id=5470 From noreply@sourceforge.net Wed Nov 28 06:45:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 27 Nov 2001 22:45:34 -0800 Subject: [Patches] [ python-Patches-486375 ] Use charset in email.Utils.encode Message-ID: Patches item #486375, was opened at 2001-11-27 22:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486375&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: Use charset in email.Utils.encode Initial Comment: Here's a patch that makes email.Utils.encode actually _use_ its charset parameter. Note: a string is encoded into the specified character set using the 'replace' mode in order to provide high tolerance for missing characters, typical for email applications. The patch also slightly optimizes the code around (cough cough). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486375&group_id=5470 From noreply@sourceforge.net Wed Nov 28 12:04:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 28 Nov 2001 04:04:19 -0800 Subject: [Patches] [ python-Patches-486438 ] makes doctest.testmod() to work Message-ID: Patches item #486438, was opened at 2001-11-28 04:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486438&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Nobody/Anonymous (nobody) Summary: makes doctest.testmod() to work Initial Comment: testmod() can now be called with no arguments, in which case it works on the current module. This is a big convenience for self-testing modules. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486438&group_id=5470 From noreply@sourceforge.net Wed Nov 28 14:19:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 28 Nov 2001 06:19:59 -0800 Subject: [Patches] [ python-Patches-476866 ] new improved trace.py Message-ID: Patches item #476866, was opened at 2001-10-31 10:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476866&group_id=5470 Category: Demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Skip Montanaro (montanaro) Summary: new improved trace.py Initial Comment: trace.py didn't work for me with Python 2.2a4+, possibly due to me misunderstanding how to use it. In any case this version is substantially rewritten, uses the debugger hooks that were introduced in Python 2.1(?), and has a simpler (in my opinion) interface. Also there are some new features like "countfuncs" mode which is faster than "count" mode and reports only a list of funcs that were invoked. ---------------------------------------------------------------------- >Comment By: Zooko Ozoko (zooko) Date: 2001-11-28 06:19 Message: Logged In: YES user_id=52562 Guido: did you see the usage string? I'm looking at it and not seeing how to make it more clear right now. Okay I'll try tweaking it a bit... In Mojo NatioExecution: --help Display this help then exit. --version Output version information then exit. -t,--trace Print each line to sys.stdout before it is executed. -c,--count Count the number of times each line is executed. After the program exits, results are written to the results file if `--file' is given, else to sys.stdout. -r,--report Generate a report from a results file; do not execute any code. `--file' must specify the results file to read. (One of `-t', `-c' or `-r' must be specified) -s,--summary Generate a brief summary for each file. (Can only be used with -c or -r.) I/O: -f,--file= File name for accumulating results over several runs. (No file name means do not archive results) -d,--logdir= Directory to use when writing annotated log files. Log files are the module __name__ with `.` replaced by os.sep and with '.pyl' added. -m,--missing Annotate all executable lines which were not executed with a '>>>>>> '. -R,--no-report Do not generate the annotated reports. Useful if you want to accumulate several over tests. -C,--coverdir= Generate .cover files in this directory Selection: Do not trace or log lines from ... --ignore-module=[string] modules with the given __name__, and submodules of that module --ignore-dir=[string] files in the stated directory (multiple directories can be joined by os.pathsep) The selection options can be listed multiple times to ignore different modules. n CVS: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mojonation/evil/common/trace.py?rev=HEAD&content-type=text/vnd.viewcvs-markup the usage string now looks like this: ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-11-03 08:40 Message: Logged In: YES user_id=44345 I'm going to be in Europe on business for the next two weeks. I should have a fair amount of dead time in my hotel room. I'll try to take a look at it then. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-11-03 08:20 Message: Logged In: YES user_id=52562 I'll be happy to add doco about --count, --report, and --file after I return from the O'Reilly p2p conference. (i.e. more than a week from now). Regards, Zooko ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-31 20:08 Message: Logged In: YES user_id=6380 Skip, what do you think of this? In addition, I think there needs to e a doc string explaining what the --count and --report options do, and how the --file option figures. I am completely unable to understand how these interoperate. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476866&group_id=5470 From noreply@sourceforge.net Wed Nov 28 14:26:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 28 Nov 2001 06:26:59 -0800 Subject: [Patches] [ python-Patches-476866 ] new improved trace.py Message-ID: Patches item #476866, was opened at 2001-10-31 10:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476866&group_id=5470 Category: Demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Skip Montanaro (montanaro) Summary: new improved trace.py Initial Comment: trace.py didn't work for me with Python 2.2a4+, possibly due to me misunderstanding how to use it. In any case this version is substantially rewritten, uses the debugger hooks that were introduced in Python 2.1(?), and has a simpler (in my opinion) interface. Also there are some new features like "countfuncs" mode which is faster than "count" mode and reports only a list of funcs that were invoked. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-28 06:26 Message: Logged In: YES user_id=6380 Well, then it doesn't work. When I do "trace.py --count hello.py", it doesn't print any usage stats to stdout. When I add "--file foo", it writes some binary data to foo. When I then do "trace.py --report --file foo hello.py" I get no output. This is with your version, but Skips version had the same problem. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-11-28 06:19 Message: Logged In: YES user_id=52562 Guido: did you see the usage string? I'm looking at it and not seeing how to make it more clear right now. Okay I'll try tweaking it a bit... In Mojo NatioExecution: --help Display this help then exit. --version Output version information then exit. -t,--trace Print each line to sys.stdout before it is executed. -c,--count Count the number of times each line is executed. After the program exits, results are written to the results file if `--file' is given, else to sys.stdout. -r,--report Generate a report from a results file; do not execute any code. `--file' must specify the results file to read. (One of `-t', `-c' or `-r' must be specified) -s,--summary Generate a brief summary for each file. (Can only be used with -c or -r.) I/O: -f,--file= File name for accumulating results over several runs. (No file name means do not archive results) -d,--logdir= Directory to use when writing annotated log files. Log files are the module __name__ with `.` replaced by os.sep and with '.pyl' added. -m,--missing Annotate all executable lines which were not executed with a '>>>>>> '. -R,--no-report Do not generate the annotated reports. Useful if you want to accumulate several over tests. -C,--coverdir= Generate .cover files in this directory Selection: Do not trace or log lines from ... --ignore-module=[string] modules with the given __name__, and submodules of that module --ignore-dir=[string] files in the stated directory (multiple directories can be joined by os.pathsep) The selection options can be listed multiple times to ignore different modules. n CVS: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mojonation/evil/common/trace.py?rev=HEAD&content-type=text/vnd.viewcvs-markup the usage string now looks like this: ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-11-03 08:40 Message: Logged In: YES user_id=44345 I'm going to be in Europe on business for the next two weeks. I should have a fair amount of dead time in my hotel room. I'll try to take a look at it then. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-11-03 08:20 Message: Logged In: YES user_id=52562 I'll be happy to add doco about --count, --report, and --file after I return from the O'Reilly p2p conference. (i.e. more than a week from now). Regards, Zooko ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-31 20:08 Message: Logged In: YES user_id=6380 Skip, what do you think of this? In addition, I think there needs to e a doc string explaining what the --count and --report options do, and how the --file option figures. I am completely unable to understand how these interoperate. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476866&group_id=5470 From noreply@sourceforge.net Wed Nov 28 15:25:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 28 Nov 2001 07:25:19 -0800 Subject: [Patches] [ python-Patches-476866 ] new improved trace.py Message-ID: Patches item #476866, was opened at 2001-10-31 10:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476866&group_id=5470 Category: Demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Skip Montanaro (montanaro) Summary: new improved trace.py Initial Comment: trace.py didn't work for me with Python 2.2a4+, possibly due to me misunderstanding how to use it. In any case this version is substantially rewritten, uses the debugger hooks that were introduced in Python 2.1(?), and has a simpler (in my opinion) interface. Also there are some new features like "countfuncs" mode which is faster than "count" mode and reports only a list of funcs that were invoked. ---------------------------------------------------------------------- >Comment By: Zooko Ozoko (zooko) Date: 2001-11-28 07:25 Message: Logged In: YES user_id=52562 Uh... Oh yeah, you're right. (I actually use it programmatically and not through the command line.) Okay I don't know *what* it is supposed to do. I'm working on figuring it out right now and I'll submit a patch when done. --Z ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-28 06:26 Message: Logged In: YES user_id=6380 Well, then it doesn't work. When I do "trace.py --count hello.py", it doesn't print any usage stats to stdout. When I add "--file foo", it writes some binary data to foo. When I then do "trace.py --report --file foo hello.py" I get no output. This is with your version, but Skips version had the same problem. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-11-28 06:19 Message: Logged In: YES user_id=52562 Guido: did you see the usage string? I'm looking at it and not seeing how to make it more clear right now. Okay I'll try tweaking it a bit... In Mojo NatioExecution: --help Display this help then exit. --version Output version information then exit. -t,--trace Print each line to sys.stdout before it is executed. -c,--count Count the number of times each line is executed. After the program exits, results are written to the results file if `--file' is given, else to sys.stdout. -r,--report Generate a report from a results file; do not execute any code. `--file' must specify the results file to read. (One of `-t', `-c' or `-r' must be specified) -s,--summary Generate a brief summary for each file. (Can only be used with -c or -r.) I/O: -f,--file= File name for accumulating results over several runs. (No file name means do not archive results) -d,--logdir= Directory to use when writing annotated log files. Log files are the module __name__ with `.` replaced by os.sep and with '.pyl' added. -m,--missing Annotate all executable lines which were not executed with a '>>>>>> '. -R,--no-report Do not generate the annotated reports. Useful if you want to accumulate several over tests. -C,--coverdir= Generate .cover files in this directory Selection: Do not trace or log lines from ... --ignore-module=[string] modules with the given __name__, and submodules of that module --ignore-dir=[string] files in the stated directory (multiple directories can be joined by os.pathsep) The selection options can be listed multiple times to ignore different modules. n CVS: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mojonation/evil/common/trace.py?rev=HEAD&content-type=text/vnd.viewcvs-markup the usage string now looks like this: ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-11-03 08:40 Message: Logged In: YES user_id=44345 I'm going to be in Europe on business for the next two weeks. I should have a fair amount of dead time in my hotel room. I'll try to take a look at it then. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-11-03 08:20 Message: Logged In: YES user_id=52562 I'll be happy to add doco about --count, --report, and --file after I return from the O'Reilly p2p conference. (i.e. more than a week from now). Regards, Zooko ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-31 20:08 Message: Logged In: YES user_id=6380 Skip, what do you think of this? In addition, I think there needs to e a doc string explaining what the --count and --report options do, and how the --file option figures. I am completely unable to understand how these interoperate. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476866&group_id=5470 From noreply@sourceforge.net Wed Nov 28 15:58:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 28 Nov 2001 07:58:17 -0800 Subject: [Patches] [ python-Patches-476866 ] new improved trace.py Message-ID: Patches item #476866, was opened at 2001-10-31 10:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476866&group_id=5470 Category: Demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Skip Montanaro (montanaro) Summary: new improved trace.py Initial Comment: trace.py didn't work for me with Python 2.2a4+, possibly due to me misunderstanding how to use it. In any case this version is substantially rewritten, uses the debugger hooks that were introduced in Python 2.1(?), and has a simpler (in my opinion) interface. Also there are some new features like "countfuncs" mode which is faster than "count" mode and reports only a list of funcs that were invoked. ---------------------------------------------------------------------- >Comment By: Zooko Ozoko (zooko) Date: 2001-11-28 07:58 Message: Logged In: YES user_id=52562 Please look at the latest version: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mojonation/evil/common/trace.py a) do the docs clearly specify the behavior? b) is that the behavior you want? c) does it actually behave like that when you try it? (Works on my machine...) --Z ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-11-28 07:25 Message: Logged In: YES user_id=52562 Uh... Oh yeah, you're right. (I actually use it programmatically and not through the command line.) Okay I don't know *what* it is supposed to do. I'm working on figuring it out right now and I'll submit a patch when done. --Z ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-28 06:26 Message: Logged In: YES user_id=6380 Well, then it doesn't work. When I do "trace.py --count hello.py", it doesn't print any usage stats to stdout. When I add "--file foo", it writes some binary data to foo. When I then do "trace.py --report --file foo hello.py" I get no output. This is with your version, but Skips version had the same problem. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-11-28 06:19 Message: Logged In: YES user_id=52562 Guido: did you see the usage string? I'm looking at it and not seeing how to make it more clear right now. Okay I'll try tweaking it a bit... In Mojo NatioExecution: --help Display this help then exit. --version Output version information then exit. -t,--trace Print each line to sys.stdout before it is executed. -c,--count Count the number of times each line is executed. After the program exits, results are written to the results file if `--file' is given, else to sys.stdout. -r,--report Generate a report from a results file; do not execute any code. `--file' must specify the results file to read. (One of `-t', `-c' or `-r' must be specified) -s,--summary Generate a brief summary for each file. (Can only be used with -c or -r.) I/O: -f,--file= File name for accumulating results over several runs. (No file name means do not archive results) -d,--logdir= Directory to use when writing annotated log files. Log files are the module __name__ with `.` replaced by os.sep and with '.pyl' added. -m,--missing Annotate all executable lines which were not executed with a '>>>>>> '. -R,--no-report Do not generate the annotated reports. Useful if you want to accumulate several over tests. -C,--coverdir= Generate .cover files in this directory Selection: Do not trace or log lines from ... --ignore-module=[string] modules with the given __name__, and submodules of that module --ignore-dir=[string] files in the stated directory (multiple directories can be joined by os.pathsep) The selection options can be listed multiple times to ignore different modules. n CVS: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mojonation/evil/common/trace.py?rev=HEAD&content-type=text/vnd.viewcvs-markup the usage string now looks like this: ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-11-03 08:40 Message: Logged In: YES user_id=44345 I'm going to be in Europe on business for the next two weeks. I should have a fair amount of dead time in my hotel room. I'll try to take a look at it then. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-11-03 08:20 Message: Logged In: YES user_id=52562 I'll be happy to add doco about --count, --report, and --file after I return from the O'Reilly p2p conference. (i.e. more than a week from now). Regards, Zooko ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-31 20:08 Message: Logged In: YES user_id=6380 Skip, what do you think of this? In addition, I think there needs to e a doc string explaining what the --count and --report options do, and how the --file option figures. I am completely unable to understand how these interoperate. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476866&group_id=5470 From noreply@sourceforge.net Wed Nov 28 17:34:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 28 Nov 2001 09:34:02 -0800 Subject: [Patches] [ python-Patches-486438 ] makes doctest.testmod() to work Message-ID: Patches item #486438, was opened at 2001-11-28 04:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486438&group_id=5470 >Category: Library (Lib) Group: None Status: Open >Resolution: Postponed Priority: 5 Submitted By: David Abrahams (david_abrahams) >Assigned to: Tim Peters (tim_one) Summary: makes doctest.testmod() to work Initial Comment: testmod() can now be called with no arguments, in which case it works on the current module. This is a big convenience for self-testing modules. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-11-28 09:34 Message: Logged In: YES user_id=31435 Assigned to me, and Postponed (2.2 is in feature freeze). When resurrected, will try to find Skip's old patch (email'ed?) for this and combine them. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486438&group_id=5470 From noreply@sourceforge.net Wed Nov 28 19:45:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 28 Nov 2001 11:45:34 -0800 Subject: [Patches] [ python-Patches-476866 ] new improved trace.py Message-ID: Patches item #476866, was opened at 2001-10-31 10:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476866&group_id=5470 Category: Demos and tools Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Zooko Ozoko (zooko) >Assigned to: Guido van Rossum (gvanrossum) Summary: new improved trace.py Initial Comment: trace.py didn't work for me with Python 2.2a4+, possibly due to me misunderstanding how to use it. In any case this version is substantially rewritten, uses the debugger hooks that were introduced in Python 2.1(?), and has a simpler (in my opinion) interface. Also there are some new features like "countfuncs" mode which is faster than "count" mode and reports only a list of funcs that were invoked. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-28 11:45 Message: Logged In: YES user_id=6380 Ah, now I finally understand what it is *supposed* to do! I've updated the usage message to clarify that, and checked in the rest of your changes. Since Skip doesn't seem to be interested in this, I've reassigned it to me -- and closed. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-11-28 07:58 Message: Logged In: YES user_id=52562 Please look at the latest version: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mojonation/evil/common/trace.py a) do the docs clearly specify the behavior? b) is that the behavior you want? c) does it actually behave like that when you try it? (Works on my machine...) --Z ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-11-28 07:25 Message: Logged In: YES user_id=52562 Uh... Oh yeah, you're right. (I actually use it programmatically and not through the command line.) Okay I don't know *what* it is supposed to do. I'm working on figuring it out right now and I'll submit a patch when done. --Z ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-28 06:26 Message: Logged In: YES user_id=6380 Well, then it doesn't work. When I do "trace.py --count hello.py", it doesn't print any usage stats to stdout. When I add "--file foo", it writes some binary data to foo. When I then do "trace.py --report --file foo hello.py" I get no output. This is with your version, but Skips version had the same problem. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-11-28 06:19 Message: Logged In: YES user_id=52562 Guido: did you see the usage string? I'm looking at it and not seeing how to make it more clear right now. Okay I'll try tweaking it a bit... In Mojo NatioExecution: --help Display this help then exit. --version Output version information then exit. -t,--trace Print each line to sys.stdout before it is executed. -c,--count Count the number of times each line is executed. After the program exits, results are written to the results file if `--file' is given, else to sys.stdout. -r,--report Generate a report from a results file; do not execute any code. `--file' must specify the results file to read. (One of `-t', `-c' or `-r' must be specified) -s,--summary Generate a brief summary for each file. (Can only be used with -c or -r.) I/O: -f,--file= File name for accumulating results over several runs. (No file name means do not archive results) -d,--logdir= Directory to use when writing annotated log files. Log files are the module __name__ with `.` replaced by os.sep and with '.pyl' added. -m,--missing Annotate all executable lines which were not executed with a '>>>>>> '. -R,--no-report Do not generate the annotated reports. Useful if you want to accumulate several over tests. -C,--coverdir= Generate .cover files in this directory Selection: Do not trace or log lines from ... --ignore-module=[string] modules with the given __name__, and submodules of that module --ignore-dir=[string] files in the stated directory (multiple directories can be joined by os.pathsep) The selection options can be listed multiple times to ignore different modules. n CVS: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mojonation/evil/common/trace.py?rev=HEAD&content-type=text/vnd.viewcvs-markup the usage string now looks like this: ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-11-03 08:40 Message: Logged In: YES user_id=44345 I'm going to be in Europe on business for the next two weeks. I should have a fair amount of dead time in my hotel room. I'll try to take a look at it then. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-11-03 08:20 Message: Logged In: YES user_id=52562 I'll be happy to add doco about --count, --report, and --file after I return from the O'Reilly p2p conference. (i.e. more than a week from now). Regards, Zooko ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-31 20:08 Message: Logged In: YES user_id=6380 Skip, what do you think of this? In addition, I think there needs to e a doc string explaining what the --count and --report options do, and how the --file option figures. I am completely unable to understand how these interoperate. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476866&group_id=5470 From noreply@sourceforge.net Wed Nov 28 20:09:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 28 Nov 2001 12:09:26 -0800 Subject: [Patches] [ python-Patches-486657 ] small edit in ext/ownershipRules.html Message-ID: Patches item #486657, was opened at 2001-11-28 12:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486657&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: small edit in ext/ownershipRules.html Initial Comment: http://python.sourceforge.net/devel-docs/api/listObjects.html This sentence confused me the first time I read it. Suggest change from: "Even if in fact, in some cases, you don't receive a reference to a brand new object, you still receive ownership of the reference." to "Even if the object is not actually brand new, you still receive ownership of the reference." ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486657&group_id=5470 From noreply@sourceforge.net Wed Nov 28 23:11:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 28 Nov 2001 15:11:47 -0800 Subject: [Patches] [ python-Patches-486743 ] remove bad INCREF, propagate exception Message-ID: Patches item #486743, was opened at 2001-11-28 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486743&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: remove bad INCREF, propagate exception Initial Comment: This is my very first foray into the Python interpreter, so please be patient. It looks like to me that this INCREF is wrong since the PyList_Append() will steal the reference. Also I tested it. Current CVS does this: >>> import gc >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1562 >>> len(gc.get_objects()) 1565 >>> len(gc.get_objects()) 1568 >>> len(gc.get_objects()) 1571 >>> len(gc.get_objects()) 1574 and with my patch it does this: >>> import gc >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 In addition I added checks for error return from PyList_Append(), and propagated the exception condition up the callstack. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486743&group_id=5470 From noreply@sourceforge.net Thu Nov 29 00:12:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 28 Nov 2001 16:12:50 -0800 Subject: [Patches] [ python-Patches-486743 ] remove bad INCREF, propagate exception Message-ID: Patches item #486743, was opened at 2001-11-28 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486743&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: remove bad INCREF, propagate exception Initial Comment: This is my very first foray into the Python interpreter, so please be patient. It looks like to me that this INCREF is wrong since the PyList_Append() will steal the reference. Also I tested it. Current CVS does this: >>> import gc >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1562 >>> len(gc.get_objects()) 1565 >>> len(gc.get_objects()) 1568 >>> len(gc.get_objects()) 1571 >>> len(gc.get_objects()) 1574 and with my patch it does this: >>> import gc >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 In addition I added checks for error return from PyList_Append(), and propagated the exception condition up the callstack. ---------------------------------------------------------------------- >Comment By: Zooko Ozoko (zooko) Date: 2001-11-28 16:12 Message: Logged In: YES user_id=52562 Oh, and here is a new version of the patch, which also tests for failure from PyList_New(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486743&group_id=5470 From noreply@sourceforge.net Thu Nov 29 00:30:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 28 Nov 2001 16:30:53 -0800 Subject: [Patches] [ python-Patches-486743 ] remove bad INCREF, propagate exception Message-ID: Patches item #486743, was opened at 2001-11-28 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486743&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: remove bad INCREF, propagate exception Initial Comment: This is my very first foray into the Python interpreter, so please be patient. It looks like to me that this INCREF is wrong since the PyList_Append() will steal the reference. Also I tested it. Current CVS does this: >>> import gc >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1562 >>> len(gc.get_objects()) 1565 >>> len(gc.get_objects()) 1568 >>> len(gc.get_objects()) 1571 >>> len(gc.get_objects()) 1574 and with my patch it does this: >>> import gc >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 In addition I added checks for error return from PyList_Append(), and propagated the exception condition up the callstack. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2001-11-28 16:30 Message: Logged In: YES user_id=413 which file is the patch against? ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-11-28 16:12 Message: Logged In: YES user_id=52562 Oh, and here is a new version of the patch, which also tests for failure from PyList_New(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486743&group_id=5470 From noreply@sourceforge.net Thu Nov 29 00:33:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 28 Nov 2001 16:33:58 -0800 Subject: [Patches] [ python-Patches-486743 ] remove bad INCREF, propagate exception Message-ID: Patches item #486743, was opened at 2001-11-28 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486743&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: remove bad INCREF, propagate exception Initial Comment: This is my very first foray into the Python interpreter, so please be patient. It looks like to me that this INCREF is wrong since the PyList_Append() will steal the reference. Also I tested it. Current CVS does this: >>> import gc >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1562 >>> len(gc.get_objects()) 1565 >>> len(gc.get_objects()) 1568 >>> len(gc.get_objects()) 1571 >>> len(gc.get_objects()) 1574 and with my patch it does this: >>> import gc >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 >>> len(gc.get_objects()) 1559 In addition I added checks for error return from PyList_Append(), and propagated the exception condition up the callstack. ---------------------------------------------------------------------- >Comment By: Zooko Ozoko (zooko) Date: 2001-11-28 16:33 Message: Logged In: YES user_id=52562 Whoops. It is against dist/src/Modules/gcmodule.c ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2001-11-28 16:30 Message: Logged In: YES user_id=413 which file is the patch against? ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-11-28 16:12 Message: Logged In: YES user_id=52562 Oh, and here is a new version of the patch, which also tests for failure from PyList_New(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486743&group_id=5470 From noreply@sourceforge.net Thu Nov 29 07:17:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 28 Nov 2001 23:17:33 -0800 Subject: [Patches] [ python-Patches-486657 ] small edit in ext/ownershipRules.html Message-ID: Patches item #486657, was opened at 2001-11-28 12:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486657&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: small edit in ext/ownershipRules.html Initial Comment: http://python.sourceforge.net/devel-docs/api/listObjects.html This sentence confused me the first time I read it. Suggest change from: "Even if in fact, in some cases, you don't receive a reference to a brand new object, you still receive ownership of the reference." to "Even if the object is not actually brand new, you still receive ownership of the reference." ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-28 23:17 Message: Logged In: YES user_id=3066 Fixed using a wording similar to that suggested in Doc/ext/extending.tex revision 1.8. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486657&group_id=5470 From noreply@sourceforge.net Thu Nov 29 07:25:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 28 Nov 2001 23:25:58 -0800 Subject: [Patches] [ python-Patches-481080 ] Read Me file Patch for Python 2.1.2 Message-ID: Patches item #481080, was opened at 2001-11-12 14:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481080&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Wolfe (dkwolfe) >Assigned to: Jack Jansen (jackjansen) Summary: Read Me file Patch for Python 2.1.2 Initial Comment: The following paragraph replaces the existing Mac OS X v10.1 paragraph. It assumes that patches 481060 and 481075 are taken. - Dan Mac OS X 10.1: Run configure with ./configure -- with-suffix=.x --with-dyld". This generates executable file: 'python.x' (it cannot be named 'python' on an HFS or HFS+ disk as the file name clashes with directory 'Python'). The makefile is set up to correctly handle two- level namespaces for Mac OS X v10.1 and 10.0.x systems. However, running the prebinding tool on Mac OS X 10.0.x again will cause the tool to break as it cannot handle two level namespaces. The default Mac OS X has a default stacksize of 512K which causes the regular expression tests (RE and SRE) to SEGV. To temporarily increase the stacksize, type 'limit stacksize 2M' in the terminal window before running 'make test'. The test_largefile test will work on HFS+ and UFS filesystem, providing you have enough space and time. After sudo 'make installation', do the following commands: cd /usr/local/bin/ sudo mv python.x python sudo mv python2.1.x python2.1 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-28 23:25 Message: Logged In: YES user_id=3066 Assigned to the Mac OS expert for evaluation and integration. Jack, note that this is for the release21-maint branch. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481080&group_id=5470 From noreply@sourceforge.net Thu Nov 29 08:46:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 29 Nov 2001 00:46:55 -0800 Subject: [Patches] [ python-Patches-472825 ] re examples Message-ID: Patches item #472825, was opened at 2001-10-19 08:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=472825&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: re examples Initial Comment: I wrote an example for libre.tex (see attached file). Unfortunately, I was unable to get LaTeX to handle it. I pass it along in case Fred wants to do the grunt work of getting it to work. Once that's taken care of I can use that as a template for adding more examples if you like. Skip ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-29 00:46 Message: Logged In: YES user_id=3066 Accepted, with a variety of changes. Checked in as Doc/lib/libre.tex revision 1.72. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-24 19:35 Message: Logged In: YES user_id=3066 I don't like the use of the bare "list" environment, but I'll worry about that later. I've attached a first cut at a revision, but haven't tested this yet (not running a real O/S at the moment!). I like having additional examples for this module; there are enough corners of the RE syntax that need to be described by example for people to really understand it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=472825&group_id=5470 From noreply@sourceforge.net Thu Nov 29 20:49:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 29 Nov 2001 12:49:30 -0800 Subject: [Patches] [ python-Patches-462296 ] Add attributes to os.stat results Message-ID: Patches item #462296, was opened at 2001-09-17 10:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 Category: Library (Lib) Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Add attributes to os.stat results Initial Comment: See bug #111481, and PEP 0042. Both suggest that the return values for os.{stat,lstat,statvfs,fstatvfs} ought to be struct-like objects rather than simple tuples. With this patch, the os module will modify the aformentioned functions so that their results still obey the previous tuple protocol, but now have read-only attributes as well. In other words, "os.stat('filename')[0]" is now synonymous with "os.stat('filename').st_mode. The patch also modifies test_os.py to test the new behavior. In order to prevent old code from breaking, these new return types extend tuple. They also use the new attribute descriptor interface. (Thanks for PEP-025[23], Guido!) Backward compatibility: Code will only break if it assumes that type(os.stat(...)) == TupleType, or if it assumes that os.stat(...) has no attributes beyond those defined in tuple. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-29 12:49 Message: Logged In: YES user_id=3066 This has been checked in, edited, and checked in again. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-10-18 15:53 Message: Logged In: YES user_id=499 Here's a documentation patch for libos.tex. I don't know the TeX macros well enough to write an analogous one for libtime.tex; fortunately, it should be fairly easy to extrapolate from the included patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-18 13:35 Message: Logged In: YES user_id=6380 Thanks, Nick! Good job. Checked in, just in time for 2.2b1. I'm passing this tracker entry on to Fred for documentation. (Fred, feel free to pester Nick for docs. Nick, feel free to upload approximate patches to Doc/libos.tex and Doc/libtime.tex. :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-18 12:24 Message: Logged In: YES user_id=6380 I'm looking at this now. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-03 06:55 Message: Logged In: YES user_id=6380 Patience, please. I'm behind reviewing this, probably won't have time today either. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-10-03 06:51 Message: Logged In: YES user_id=6656 If this goes in, I'd like to see it used for termios.tc {get,set}attr too. I could probably implement this (but not *right* now...). ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-10-01 18:56 Message: Logged In: YES user_id=499 The fifth all-C (!) version, with changes as suggested by Guido's comments via email. Big changes: This version no longer subclasses tuple. Instead, it creates a general-purpose mechanism for making struct/sequence hybrids in C. It now includes a patch for timemodule.c as well. Shortcomings: (1) As before, macmodule and riscosmodule aren't tested. (2) These new classes don't participate in GC and aren't subclassable. (Famous last words: "I don't think this will matter." :) ) (3) This isn't a brand-new metaclass; it's just a quick bit of C. As such, you can't use this mechanism to create new struct/tuple hybrids from Python. (I claim this isn't a drawback, since it's way easier to reimplement this in python than it is to make it accessible from python.) So, how's *this* one? ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-10-01 08:37 Message: Logged In: YES user_id=499 I've sent my email address to 'guido at python.org'. For reference, it's 'nickm at alum.mit.edu'. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-01 07:09 Message: Logged In: YES user_id=6380 Nick, what's your real email? I have a bunch of feedback related to your use of the new type stuff -- this is uncharted territory for me too, and this SF box is too small to type comfortably. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-30 19:51 Message: Logged In: YES user_id=499 I think this might be the one... or at least, the next-to-last-one. This version of the patch: (1) moves the shared C code into a new module, "_stat", for internal use. (2) updates macmodule and riscosmodule to use the new code. (3) fixes a significant reference leak in previous versions. (4) is immune to the __new__ and __init__ bugs in previous versions. Things to note: (A) I've tried to make sure that my Mac/RISCOS code was correct, but I don't have any way to compile or test it. (B) I'm not sure my use of PyImport_ImportModule is legit. (C) I've allowed users to construct instances of stat_result with < or > 13 arguments. When this happens, attempts to get nonexistant attributes now raise AttributeError. (D) When dealing with Mac.xstat and RISCOS.stat, I chose to keep backward compatibility rather than enforcing the 10-tuple rule in the docs. Because there are new files, I can't make 'cvs diff' get everything. I'm uploading a zip file that contains _statmodule.c, _statmodule.h, and a unified diff. Please let me know if you'd prefer a different format. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-28 07:23 Message: Logged In: YES user_id=6380 Another comment: we should move this to its own file so that other os.stat() implementations (esp. MacOS, maybe RiscOS) that aren't in posixmodule.c can also use it, rather than having to maintain three separate versions of the code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-28 07:18 Message: Logged In: YES user_id=6380 One comment on the patch: beautiful use of the new type stuff, but there's something funky with the constructors going on. It seems that the built-in __new__ (inherited from the tuple class) requires exactly one argument -- a sequence to be tuplified -- but your __init__ requires 13 arguments. So construction by using posix.stat_result(...) always fails. It makes more sense to fix the init routine to require a 13-tuple as argument. I would also recommend overriding the tp_new slot to require a 13-tuple: right now, I can cause an easy core dump as follows: >>> import os >>> a = os.stat_result.__new__(os.stat_result, ()) >>> a.st_ctime Segmentation fault (core dumped) $ ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-27 21:20 Message: Logged In: YES user_id=499 I've fixed it with the suggestions you made, and also 1) Added docstrings 2) Fixed a nasty segfault bug that would be triggered by os.stat("/foo").__class__((10,)).st_size and added tests to keep it from reappearing. I'm not sure I know how to cover Mac and RISCOS properly: riscos.stat returns a 13-element tuple, and is hence already incompatible with posix.stat; whereas mac.{stat|xstat} return differing types. If somebody with experience with these modules could let give me guidance as to the Right Thing, I'll be happy to give it a shot... but my shot isn't likely to be half as good as somebody who knew the modules better. (For example, I don't have the facilities to compile macmodule or riscmodule at all, much less test them.) I'd also be glad to make any changes that would help maintainers of those modules. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-24 01:44 Message: Logged In: YES user_id=21627 The patch looks good to me. Are you willing to revise it one more time to cover all the stat implementations? A few comments on the implementation: - Why do you try to have your type participate in GC? they will never be part of a cycle. If that ever becomes an issue, you probably need to implement a traversal function as well. - I'd avoid declaring PosixStatResult, since the field declarations are misleading. Instead, you should just add the right number of additional in the type declaration. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-21 13:07 Message: Logged In: YES user_id=499 And here's an even better all-C version. (This one doesn't use a dictionary to store optional attributes.) ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-21 11:01 Message: Logged In: YES user_id=499 Well, here's a posixmodule-only, all-C version. If this seems like a good approach, I'll add some better docstrings, move it into whichever module you like, and make riscosmodule.c and macmodule.c use it too. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-19 21:35 Message: Logged In: YES user_id=6380 Or you could put it in modsupport.c, which is already a grab-bag of handy stuff. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-19 11:36 Message: Logged In: YES user_id=21627 There aren't actually so many copies of the module, since posixmodule implements "posix","nt", and "os2". I found alternative implementations in riscosmodule and macmodule. Still, putting the support type into a shared C file is appropriate. I can think of two candidate places: tupleobject.c and fileobject.c. It may be actually worthwhile attempting to share the stat() implementations as well, but that could be an add-on. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-19 11:10 Message: Logged In: YES user_id=499 I'm becoming more and more convinced that doing it in C is the right thing, but I have issue with doing it in the posix module. The stat function is provided on (nearly?) all platforms, and doing it in C will require minor changes to all of these modules. We can probably live with this, but I don't think we should duplicate code between all of the os modules. Is there some other appropriate place to put it in C? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-18 23:52 Message: Logged In: YES user_id=21627 Using posix.stat is common, see http://groups.yahoo.com/group/python-list/message/4349 http://www.washington.edu/computing/training/125/mkdoc.html http://groups.google.com/groups?th=7d7d118fed161e0&seekm=5qdjch%24dci%40nntp6.u.washington.edu for examples. None of these would break with your change, though, since they don't rely on the lenght of the tuple. If you are going to implement the type in C, I'd put it in the posix module. If you are going to implement it in Python (and only use it from the Posix module), making it general-purpose may be desirable. However, a number of things would need to be considered, so a PEP might be appropriate. If that is done, I'd propose an interface like tuple_with_attrs((value-tuple), (tuple-of-field-names), exposed-length-of-tuple)) ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-18 14:11 Message: Logged In: YES user_id=499 Ah! Now I see. I hadn't realized that anybody used the posix module directly. (People really do this?) I'll try to write up a patch in C tonight or tomorrow morning. A couple of questions on which I could use advice: (1) Where is the proper place to put this kind of tuple-with-fields hybrid? Modules? Objects? In a new file or an existing one? (2) Should I try to make it general enough for non-stat use? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-18 00:54 Message: Logged In: YES user_id=21627 The problem with your second and third patch is that it includes an incompatibility for users of posix.stat (and friends), since it changes the siye of the tuple. If you want to continue to return a tuple (as the top-level data structure), you'll break compatibility for applications using the C module directly. An example of code that would be broken is mode, ino, dev, nlink, uid, gid, size, a, c, m = posix.stat(filename) To pass the additional fields, you already need your class _StatResult available in C. You may find a way to define it in Python and use it in C, but that has proven to be very fragile in the past. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-17 18:54 Message: Logged In: YES user_id=6380 Haven't had time to review the patch yet, but the idea of providing a structure with fields that doubles as a tuple is a good one. It's been tried before and can be done in pure Python as well. Regarding the field names: I think the field names should keep their st_ prefix -- IMO this makes the code more recognizable and hence readable. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 17:32 Message: Logged In: YES user_id=499 Here's the revised (*example only*) patch that takes the more portable approach I mention below. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 16:10 Message: Logged In: YES user_id=499 On further consideration, the approach taken in the second (*example only*) patch is indeed too fragile. The C code should not lengthen the tuple arbitrarily and depend on the Python code to decode it; instead, it should return a dictionary of extra fields. I think that this approach uses a minimum of C, is easily maintainable, and very extensible. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 15:53 Message: Logged In: YES user_id=499 Martin: I'm not entirely sure what you mean here; while my patch for extra fields requires a minor chunk of C (to access the struct fields), the rest still works in pure python. I'm attaching this second version for reference. I'm not sure it makes much sense to do this with pure C; it would certainly take a lot more code, with little benefit I can descern. But you're more experienced than I; what am I missing? I agree that the field naming is suboptimal; I was taking my lead from the stat and statvfs modules. If people prefer, we can name the fields whatever we like. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-17 15:24 Message: Logged In: YES user_id=21627 I second the request for supporting additional fields where available. At the same time, it appears unimplementable using pure Python. Consequently, I'd like to see this patch redone in C. The implementation strategy could probably remain the same, i.e. inherit from tuple for best compatibility; add the remaining fields as slots. It may be reasonable to implement attribute access using a custom getattr function, though. I have also my doubts about the naming of the fields. The st_ prefix originates from the time where struct fields were living in the global namespace (i.e. across different structures), so prefixing them for uniqueness was essential. I'm not sure whether we should inherit this into Python... ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2001-09-17 13:58 Message: Logged In: YES user_id=499 BTW, if this gets in, I have another patch that adds support for st_blksize, st_blocks, and st_rdev on platforms that support them. It don't expose these new fields in the tuple, as that would break all the old code that tries to unpack all the fields of the tuple. Instead, these fields are only accessible as attributes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id=5470 From noreply@sourceforge.net Thu Nov 29 22:37:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 29 Nov 2001 14:37:45 -0800 Subject: [Patches] [ python-Patches-487275 ] windows-1251 charset alias Message-ID: Patches item #487275, was opened at 2001-11-29 14:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487275&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: windows-1251 charset alias Initial Comment: Added the 'windows_1251' alias for the 'cp1251' charset. The alias is used extensively on the Internet. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487275&group_id=5470 From noreply@sourceforge.net Fri Nov 30 10:57:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 30 Nov 2001 02:57:52 -0800 Subject: [Patches] [ python-Patches-487455 ] make types.StringTypes a tuple Message-ID: Patches item #487455, was opened at 2001-11-30 02:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487455&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Markus F.X.J. Oberhumer (mfx) Assigned to: Nobody/Anonymous (nobody) Summary: make types.StringTypes a tuple Initial Comment: The small patch below makes types.StringTypes a tuple, so that you can use "isinstance(var, StringTypes)". As StringTypes was introduced in the 2.2 development cycle there should not be any compatibility concerns. Markus --- Lib/types.py Tue Oct 30 06:19:53 2001 +++ Lib/types.py.new Fri Nov 30 11:47:42 2001 @@ -26,9 +26,9 @@ StringType = str try: UnicodeType = unicode - StringTypes = [StringType, UnicodeType] + StringTypes = (StringType, UnicodeType) except NameError: - StringTypes = [StringType] + StringTypes = (StringType,) BufferType = type(buffer('')) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487455&group_id=5470 From noreply@sourceforge.net Fri Nov 30 11:14:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 30 Nov 2001 03:14:38 -0800 Subject: [Patches] [ python-Patches-487458 ] bugfix and extension to Lib/asyncore.py Message-ID: Patches item #487458, was opened at 2001-11-30 03:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487458&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: bugfix and extension to Lib/asyncore.py Initial Comment: fix: asyncore of 2.2b2+ fails to initialize when passed 'sock' is listening. extension(or bugfix?): more flexible handling own map ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487458&group_id=5470 From noreply@sourceforge.net Fri Nov 30 16:41:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 30 Nov 2001 08:41:17 -0800 Subject: [Patches] [ python-Patches-483466 ] Import from Zip Archive Message-ID: Patches item #483466, was opened at 2001-11-19 07:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483466&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: James C. Ahlstrom (ahlstromjc) Assigned to: Nobody/Anonymous (nobody) Summary: Import from Zip Archive Initial Comment: This is the "final" patch to import.c to support imports from zip archives and directory caching using os.listdir(). It replaces patch 476047. It it intended to be part of Python 2.3. There are five files requiring patches, and these are in context diff's in five separate attached files. I have tested this on Linux and Windows 2000. It needs testing on bigendian machines, and those with 64-bit integers. Please complain about bugs, but let me know if you plan to change the code. The documentation for the imp module needs a patch. This is added right after "PY_FROZEN": PY_ZIPFILE The module was found in a zip archive file. BUGS ==== There are a couple of bugs I wasn't sure were worth fixing. Please complain if these are a problem: The use of os.listdir() for normal directory imports makes case_ok() unnecessary, but it was not removed. It might be needed if os.listdir() is missing. There is no problem if os.listdir() doesn't exist, but if it exists, it must perform as documented, and must return both file and directory names in their correct case. The PYTHONCASEOK flag is ineffective. This is a consequence of dictionary name lookup. ---------------------------------------------------------------------- >Comment By: James C. Ahlstrom (ahlstromjc) Date: 2001-11-30 08:41 Message: Logged In: YES user_id=64929 I added newer file versions to implement the changes discussed on python-dev. I still need to patch import.c to properly handle "" and relative paths in sys.path. The current changes are: 1) Creation of sys.path[0] is moved out of PySys_SetArgv() and into Py_GetPath(). Creation of the zip path is also moved into Py_GetPath(), so that all sys.path's are now in Py_GetPath(). 2) sys.path[0] is the absolute path of the Python script being run. For "-c" or an interactive interpreter, it remains "". There are two new Python API functions Py_SetScriptName() and Py_GetScriptName(). These are similar to the existing Py_[GS]etProgramName() functions, and are used for the same purpose, namely passing information to Py_GetPath(). All these functions are arguably hacks which should be replaced with additional arguments to Py_Initialize(). Here is the documentation: char* Py_GetScriptName () Return the script name set with Py_SetScriptName(), or NULL. The returned string points into static storage; the caller should not modify its value. void Py_SetScriptName (char *name) This is similar to Py_SetProgramName(), but tells the interpreter the file name of the Python script being run. This is used by Py_GetPath() to add the directory of the script to sys.path. If name is NULL no script item is added to sys.path. If name is "", the item "" will be added to sys.path, and "" means the current directory. Otherwise the absolute directory path will be added. The argument must point to a string in static storage whose contents will not change for the duration of the program's execution. ---------------------------------------------------------------------- Comment By: James C. Ahlstrom (ahlstromjc) Date: 2001-11-20 06:49 Message: Logged In: YES user_id=64929 The zero length string "" is not handled correctly as an item of sys.path. It should mean current directory, but its contents will not be cached. What happens if the current directory changes? Should the new directory be searched, or only the original current directory? I will submit a further patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483466&group_id=5470 From noreply@sourceforge.net Fri Nov 30 19:12:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 30 Nov 2001 11:12:05 -0800 Subject: [Patches] [ python-Patches-487634 ] Fix for NDEBUG problem and extensions Message-ID: Patches item #487634, was opened at 2001-11-30 11:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487634&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for NDEBUG problem and extensions Initial Comment: Python.h defines NDEBUG if not Py_DEBUG. This causes problems if 3rd party code has #ifdef NDEBUG's and is linked with other code that includes Python.h. See http://mail.python.org/pipermail/python-dev/2001-November/018669.html for more info. This patch simply undef's NDEBUG in Python.h after it includes assert.h if it was not defined before. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487634&group_id=5470