From noreply@sourceforge.net Mon Oct 1 01:51:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 30 Sep 2001 17:51:29 -0700 Subject: [Patches] [ python-Patches-462628 ] NNTPLib supports saving BODY to a file Message-ID: Patches item #462628, was opened at 2001-09-18 11:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462628&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Travers Naran (tnaran) Assigned to: Nobody/Anonymous (nobody) Summary: NNTPLib supports saving BODY to a file Initial Comment: I modified nntplib so the body method can accept an optional second parameter pointing to a filehandle or filename (string). This way, really long body articles can be stored to disk instead of kept in memory. The way I made the modification should make it easy to extend this functionality to other extended return methods. ---------------------------------------------------------------------- >Comment By: Travers Naran (tnaran) Date: 2001-09-30 17:51 Message: Logged In: YES user_id=326902 OK, I've made the requested changes. It returns an empty list ([]) when using a file, and I've tested the three variations of the call: no file parameter (returns a list of lines), a string file parameter (returns an empty list and creates a file and closes it), and a file object (returns an empty list, uses the file object w/o closing it). I've moved the critical file opening/closing to getlongresp (). This should make it trivial to extend the other long response commands should the need arise. I've also updated the documentation. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-30 11:58 Message: Logged In: YES user_id=6380 Ah, the one-liner syndrome. :-) Better take it out, and make sure to explicitly close the file in case you pass a filename (on the other hand, when an open file is passed, definitely *don't* close it). ---------------------------------------------------------------------- Comment By: Travers Naran (tnaran) Date: 2001-09-28 20:19 Message: Logged In: YES user_id=326902 I thought so too until I wrote this line in my NewsProwler program: response, dummy1, id, body = nntp.body(str (article_index),tempfile.TemporaryFile()) Now true, one could use: body = tempFile.TemporaryFile() response, dummy1, id, dummy2 = nntp.body(str (article_index),body) # or don't return the 4th parameter at all response, dummy1, id = nntp.body(str(article_index),body) But I thought preserving the semantic meaning of the return would be nice (the 4th parameter representing the article body). To be honest, I'm not wed to this convention. I'm more than willing to change it to whatever you think is best. I'm just happy I can contribute something! :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-28 06:41 Message: Logged In: YES user_id=6380 Much better. Question though: what's the point of returning the open file? Wouldn't it make more sense to return an empty list, which the caller could ignore? ---------------------------------------------------------------------- Comment By: Travers Naran (tnaran) Date: 2001-09-27 18:13 Message: Logged In: YES user_id=326902 I've made the requested changes. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-24 08:38 Message: Logged In: YES user_id=6380 Thanks. The patch is missing two things before it can be accepted: change to docstrings explaining the new argument, and changes to the documentation (Doc/lib/libnntplib.tex). If you don't know LaTeX, just imitate what you see there and our LaTeX expert will fix it up -- however you have to write the documentation yourself. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462628&group_id=5470 From noreply@sourceforge.net Mon Oct 1 03:51:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 30 Sep 2001 19:51:09 -0700 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: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) 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: 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 Mon Oct 1 11:10:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 03:10:28 -0700 Subject: [Patches] [ python-Patches-426880 ] Tkinter Listbox missing methods Message-ID: Patches item #426880, was opened at 2001-05-24 00:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=426880&group_id=5470 Category: Tkinter Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fredrik Lundh (effbot) Summary: Tkinter Listbox missing methods Initial Comment: Both the itemconfigure and the itemcget methods are missing in the current Tkinter so here they are..... ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-10-01 03:10 Message: Logged In: YES user_id=21627 I've implemented both and committed the change as Tkinter.py 1.158. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-07-02 13:12 Message: Logged In: YES user_id=38376 is it just me, or is the patch file missing? (shouldn't be that hard to create my own version of the patch, though... I'll keep this one open as a reminder) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=426880&group_id=5470 From noreply@sourceforge.net Mon Oct 1 14:12:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 06:12:26 -0700 Subject: [Patches] [ python-Patches-426880 ] Tkinter Listbox missing methods Message-ID: Patches item #426880, was opened at 2001-05-24 00:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=426880&group_id=5470 Category: Tkinter Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fredrik Lundh (effbot) Summary: Tkinter Listbox missing methods Initial Comment: Both the itemconfigure and the itemcget methods are missing in the current Tkinter so here they are..... ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-01 06:12 Message: Logged In: YES user_id=6380 Martin, itemcget and itemconfigure were already present in the Listbox class, just not at their proper place in the alphabet. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-10-01 03:10 Message: Logged In: YES user_id=21627 I've implemented both and committed the change as Tkinter.py 1.158. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-07-02 13:12 Message: Logged In: YES user_id=38376 is it just me, or is the patch file missing? (shouldn't be that hard to create my own version of the patch, though... I'll keep this one open as a reminder) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=426880&group_id=5470 From noreply@sourceforge.net Mon Oct 1 15:09:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 07:09:42 -0700 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: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) 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: 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 Mon Oct 1 16:02:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 08:02:24 -0700 Subject: [Patches] [ python-Patches-466628 ] Doc changes for doctest patch (#466616) Message-ID: Patches item #466628, was opened at 2001-09-30 14:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466628&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Hochberg (tim-hochberg) >Assigned to: Tim Peters (tim_one) Summary: Doc changes for doctest patch (#466616) Initial Comment: Documentation changes that accompany patch #466616, "Exclude imported items from doctest". See that patch for details, but here is a summary: With this patch, functions and classes that have been imported into a module are not scanned for docstrings to test by testmod. These tests frequently fail because they end up using the wrong globals. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-01 08:02 Message: Logged In: YES user_id=3066 Assigned to Tim for content review and approval. Tim, you can either check it in yourself or assign back to me for markup/editorial review and checkin. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466628&group_id=5470 From noreply@sourceforge.net Mon Oct 1 16:24:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 08:24:07 -0700 Subject: [Patches] [ python-Patches-465298 ] Fix for xmlrpclib's recursive dump Message-ID: Patches item #465298, was opened at 2001-09-26 10:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=465298&group_id=5470 Category: Library (Lib) Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Mihai Ibanescu (misa) >Assigned to: Nobody/Anonymous (nobody) Summary: Fix for xmlrpclib's recursive dump Initial Comment: A perfectly valid case: p = [] a = [p, p] print xmlrpclib.dumps((a,)) xmlrpclib is fooled by having the same container object twice, even if it's not a recursive data structure. ---------------------------------------------------------------------- >Comment By: Mihai Ibanescu (misa) Date: 2001-10-01 08:24 Message: Logged In: YES user_id=205865 Just to follow up your tim.py: On a Linux box, it's about 2.2 times slower for the lists implementation. While I have not tested this, it turns out my guts were right at some point: if you run it for 5-item collections, lists are faster. I still think in this particular case lists should be used, since the depth will in seldom cases exceed 5 (think about it, how often do you have a list inside a list inside a dictionary inside a dictionary inside a list? :-) Anyway, I'm really happy we have a fix for it. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-30 13:17 Message: Logged In: YES user_id=21627 Thanks for the patch and the discussion. The modified patch has been committed as xmlrpclib 1.8. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-30 10:28 Message: Logged In: YES user_id=21627 Please have a look at the attached tim.py; it shows that for a 20-element set, finding an element that is not in the set is significantly slower when lists are used compared to sets. Using 2.2a4, on a Solaris machine, lists turn out to be three times slower than dictionaries. I'll revise this patch to use dictionaries. ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2001-09-27 12:08 Message: Logged In: YES user_id=205865 I think you're right, I only have to pop the last element. See the last patch. I was too lazy to count. That's why a second opinion is always welcome. Now, about the list vs dictionary performance: it is true for large collections that a dictionary performs better than a list. Now, look at how this list is used. It's the depth. How deep do you think the data structure would be? 10? 20? I doubt that lists vs. dictionaries for < 100 makes any difference whatsoever. Yes, the complexity works against the patch, but as you know complexity makes sense asimptotically. For small values (and I really doubt the depth exceeds 5 in the first place), lists should work just as well. Anyway, check the last patch and then it's your call. You got the idea, you know what I wanted from the patch and you can easily change the list back to a dictionary if you think performance would be affected. I personally doubt that. Good work, you helped me a lot to clean the patch. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-27 11:48 Message: Logged In: YES user_id=21627 The patch looks good, except that it still has a performance bottleneck: The recursion test now has linear complexity (i in self.memo), whereas using a dict would give you nearly-constant complexity (self.memo.has_key(i)). I see that you use the list's "ordered" property for popping an arbitrary amount of elements. However, I cannot see why this is necessary: Isn't it an invariant that you always pop exactly one element, and that this element is always "self"? ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2001-09-27 11:21 Message: Logged In: YES user_id=205865 Okay, the patch was broken. I was working on the wrong tree and generated the patch against the wrong version. The second patch fixes this but it still uses the sloppy list-creation stuff. Please have a look at the third patch. Now I am really using a stack and performance-wise it should be much better. It also makes the change more local. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-26 13:46 Message: Logged In: YES user_id=21627 I have a number of comments on this patch: - please reread your patch carefully. E.g. why did you change 'use the "dumps" method' into 'use "dumps" method'? - It appears that all dump methods now require the additional memo argument. For this implementation strategy, it appears that argument should not be optional. - Please analyse the performance properties of this implementation strategy. It appears that you create a new list for each container. Instead, it seems better to use a dictionary as a set, adding the ids every time you descend into the container, and removing it when you are done. That would be a much smaller change also. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=465298&group_id=5470 From noreply@sourceforge.net Mon Oct 1 16:44:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 08:44:19 -0700 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: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Barry Warsaw (bwarsaw) 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-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 Mon Oct 1 16:37:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 08:37:09 -0700 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: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) 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: 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 Mon Oct 1 16:48:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 08:48:40 -0700 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: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Barry Warsaw (bwarsaw) 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: 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 Mon Oct 1 17:07:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 09:07:21 -0700 Subject: [Patches] [ python-Patches-466877 ] SIGBREAK is missing from signal module Message-ID: Patches item #466877, was opened at 2001-10-01 09:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466877&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steven Scott (progoth) Assigned to: Nobody/Anonymous (nobody) Summary: SIGBREAK is missing from signal module Initial Comment: I didn't know if this belonged in Core or Modules. It's a trivial change, but I needed it for a project I was working on. I couldn't find any mention of using SIGBREAK with python online, so maybe it's not supported? It seems to work fine in the tests I've done, although they were nothing extensive. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466877&group_id=5470 From noreply@sourceforge.net Mon Oct 1 17:19:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 09:19:40 -0700 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: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Barry Warsaw (bwarsaw) 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-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 Mon Oct 1 17:22:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 09:22:15 -0700 Subject: [Patches] [ python-Patches-466877 ] SIGBREAK is missing from signal module Message-ID: Patches item #466877, was opened at 2001-10-01 09:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466877&group_id=5470 >Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steven Scott (progoth) Assigned to: Nobody/Anonymous (nobody) Summary: SIGBREAK is missing from signal module Initial Comment: I didn't know if this belonged in Core or Modules. It's a trivial change, but I needed it for a project I was working on. I couldn't find any mention of using SIGBREAK with python online, so maybe it's not supported? It seems to work fine in the tests I've done, although they were nothing extensive. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-01 09:22 Message: Logged In: YES user_id=6380 What is SIGBREAK? I don't see it in the Linux man page for signal(7). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466877&group_id=5470 From noreply@sourceforge.net Mon Oct 1 17:38:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 09:38:24 -0700 Subject: [Patches] [ python-Patches-466877 ] SIGBREAK is missing from signal module Message-ID: Patches item #466877, was opened at 2001-10-01 09:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466877&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steven Scott (progoth) Assigned to: Nobody/Anonymous (nobody) Summary: SIGBREAK is missing from signal module Initial Comment: I didn't know if this belonged in Core or Modules. It's a trivial change, but I needed it for a project I was working on. I couldn't find any mention of using SIGBREAK with python online, so maybe it's not supported? It seems to work fine in the tests I've done, although they were nothing extensive. ---------------------------------------------------------------------- >Comment By: Steven Scott (progoth) Date: 2001-10-01 09:38 Message: Logged In: YES user_id=61663 unfortunately I work in a windows-only shop, and that's what I'm doing this for. I was trying my hardest to figure out how to catch a CTRL-Break and not just a CTRL-C, and I looked in microsoft's signals.h and saw SIGBREAK. I assume it's a windows only thing. I'm not really up on all the windows stuff, but apparently CTRL-Break is a way to take things down harder, I don't know, kill -9 for dos, or something. it doesn't raise a KeyboardException (I'm doing this with python 1.5, but the patch is against CVS), but it does allow the signal handler to be called in lieu of exiting the interpreter. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-01 09:22 Message: Logged In: YES user_id=6380 What is SIGBREAK? I don't see it in the Linux man page for signal(7). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466877&group_id=5470 From noreply@sourceforge.net Mon Oct 1 18:05:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 10:05:00 -0700 Subject: [Patches] [ python-Patches-426880 ] Tkinter Listbox missing methods Message-ID: Patches item #426880, was opened at 2001-05-24 00:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=426880&group_id=5470 Category: Tkinter Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fredrik Lundh (effbot) Summary: Tkinter Listbox missing methods Initial Comment: Both the itemconfigure and the itemcget methods are missing in the current Tkinter so here they are..... ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-10-01 10:05 Message: Logged In: YES user_id=21627 Ok, I've reverted the change. I somehow assumed that these methoded where belonging to a different class :-( ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-01 06:12 Message: Logged In: YES user_id=6380 Martin, itemcget and itemconfigure were already present in the Listbox class, just not at their proper place in the alphabet. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-10-01 03:10 Message: Logged In: YES user_id=21627 I've implemented both and committed the change as Tkinter.py 1.158. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-07-02 13:12 Message: Logged In: YES user_id=38376 is it just me, or is the patch file missing? (shouldn't be that hard to create my own version of the patch, though... I'll keep this one open as a reminder) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=426880&group_id=5470 From noreply@sourceforge.net Mon Oct 1 17:44:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 09:44:19 -0700 Subject: [Patches] [ python-Patches-466877 ] SIGBREAK is missing from signal module Message-ID: Patches item #466877, was opened at 2001-10-01 09:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466877&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steven Scott (progoth) Assigned to: Nobody/Anonymous (nobody) Summary: SIGBREAK is missing from signal module Initial Comment: I didn't know if this belonged in Core or Modules. It's a trivial change, but I needed it for a project I was working on. I couldn't find any mention of using SIGBREAK with python online, so maybe it's not supported? It seems to work fine in the tests I've done, although they were nothing extensive. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-01 09:44 Message: Logged In: YES user_id=6380 Aha. Can you actually catch SIGBREAK? (If so, it's not quite kill -9 :-) This might be useful -- we might want to set the default handler for SIGBREAK that does the same thing as the SIGINT handler. ---------------------------------------------------------------------- Comment By: Steven Scott (progoth) Date: 2001-10-01 09:38 Message: Logged In: YES user_id=61663 unfortunately I work in a windows-only shop, and that's what I'm doing this for. I was trying my hardest to figure out how to catch a CTRL-Break and not just a CTRL-C, and I looked in microsoft's signals.h and saw SIGBREAK. I assume it's a windows only thing. I'm not really up on all the windows stuff, but apparently CTRL-Break is a way to take things down harder, I don't know, kill -9 for dos, or something. it doesn't raise a KeyboardException (I'm doing this with python 1.5, but the patch is against CVS), but it does allow the signal handler to be called in lieu of exiting the interpreter. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-01 09:22 Message: Logged In: YES user_id=6380 What is SIGBREAK? I don't see it in the Linux man page for signal(7). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466877&group_id=5470 From noreply@sourceforge.net Mon Oct 1 18:27:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 10:27:24 -0700 Subject: [Patches] [ python-Patches-466877 ] SIGBREAK is missing from signal module Message-ID: Patches item #466877, was opened at 2001-10-01 09:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466877&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steven Scott (progoth) >Assigned to: Tim Peters (tim_one) Summary: SIGBREAK is missing from signal module Initial Comment: I didn't know if this belonged in Core or Modules. It's a trivial change, but I needed it for a project I was working on. I couldn't find any mention of using SIGBREAK with python online, so maybe it's not supported? It seems to work fine in the tests I've done, although they were nothing extensive. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-10-01 10:27 Message: Logged In: YES user_id=31435 Yes to everything : SIGBREAK is unique to Windows, you can catch it, the default handler calls ExitProcess(), and Python should support it. Assigned to me, but I'm not in favor of changing its default handler: if a process has gone wild, killing it via Task Manager is Draconian (that's like os._exit() -- no cleanup at all is done). ExitProcess() at least attempts to clean up shared OS resources correctly, and since Python has already hijacked Ctrl+C (whose default handler also calls ExitProcess()), Ctrl+Break is the only "semi-clean panic shutdown" gimmick left to the user. It's good to let the user override that, but Python shouldn't presume to change all of Windows default behaviors to make Unix geeks feel more at home <0.9 wink>. ---------------------------------------------------------------------- Comment By: Steven Scott (progoth) Date: 2001-10-01 09:52 Message: Logged In: YES user_id=61663 haha I guess I'm not really up on all the unix stuff either:) so yeah, you can catch it, it would probably be useful to have it handled the same as SIGINT, and throw the KeyboardInterrupt exception. Or maybe it shouldn't be the same, I would worry about how other people are using it, but since the issue hasn't even arisen until now... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-01 09:44 Message: Logged In: YES user_id=6380 Aha. Can you actually catch SIGBREAK? (If so, it's not quite kill -9 :-) This might be useful -- we might want to set the default handler for SIGBREAK that does the same thing as the SIGINT handler. ---------------------------------------------------------------------- Comment By: Steven Scott (progoth) Date: 2001-10-01 09:38 Message: Logged In: YES user_id=61663 unfortunately I work in a windows-only shop, and that's what I'm doing this for. I was trying my hardest to figure out how to catch a CTRL-Break and not just a CTRL-C, and I looked in microsoft's signals.h and saw SIGBREAK. I assume it's a windows only thing. I'm not really up on all the windows stuff, but apparently CTRL-Break is a way to take things down harder, I don't know, kill -9 for dos, or something. it doesn't raise a KeyboardException (I'm doing this with python 1.5, but the patch is against CVS), but it does allow the signal handler to be called in lieu of exiting the interpreter. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-01 09:22 Message: Logged In: YES user_id=6380 What is SIGBREAK? I don't see it in the Linux man page for signal(7). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466877&group_id=5470 From noreply@sourceforge.net Mon Oct 1 18:39:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 10:39:26 -0700 Subject: [Patches] [ python-Patches-466877 ] SIGBREAK is missing from signal module Message-ID: Patches item #466877, was opened at 2001-10-01 09:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466877&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steven Scott (progoth) Assigned to: Tim Peters (tim_one) Summary: SIGBREAK is missing from signal module Initial Comment: I didn't know if this belonged in Core or Modules. It's a trivial change, but I needed it for a project I was working on. I couldn't find any mention of using SIGBREAK with python online, so maybe it's not supported? It seems to work fine in the tests I've done, although they were nothing extensive. ---------------------------------------------------------------------- >Comment By: Steven Scott (progoth) Date: 2001-10-01 10:39 Message: Logged In: YES user_id=61663 sounds good to me...just a way to handle the signal is beyond adequate. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-01 10:27 Message: Logged In: YES user_id=31435 Yes to everything : SIGBREAK is unique to Windows, you can catch it, the default handler calls ExitProcess(), and Python should support it. Assigned to me, but I'm not in favor of changing its default handler: if a process has gone wild, killing it via Task Manager is Draconian (that's like os._exit() -- no cleanup at all is done). ExitProcess() at least attempts to clean up shared OS resources correctly, and since Python has already hijacked Ctrl+C (whose default handler also calls ExitProcess()), Ctrl+Break is the only "semi-clean panic shutdown" gimmick left to the user. It's good to let the user override that, but Python shouldn't presume to change all of Windows default behaviors to make Unix geeks feel more at home <0.9 wink>. ---------------------------------------------------------------------- Comment By: Steven Scott (progoth) Date: 2001-10-01 09:52 Message: Logged In: YES user_id=61663 haha I guess I'm not really up on all the unix stuff either:) so yeah, you can catch it, it would probably be useful to have it handled the same as SIGINT, and throw the KeyboardInterrupt exception. Or maybe it shouldn't be the same, I would worry about how other people are using it, but since the issue hasn't even arisen until now... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-01 09:44 Message: Logged In: YES user_id=6380 Aha. Can you actually catch SIGBREAK? (If so, it's not quite kill -9 :-) This might be useful -- we might want to set the default handler for SIGBREAK that does the same thing as the SIGINT handler. ---------------------------------------------------------------------- Comment By: Steven Scott (progoth) Date: 2001-10-01 09:38 Message: Logged In: YES user_id=61663 unfortunately I work in a windows-only shop, and that's what I'm doing this for. I was trying my hardest to figure out how to catch a CTRL-Break and not just a CTRL-C, and I looked in microsoft's signals.h and saw SIGBREAK. I assume it's a windows only thing. I'm not really up on all the windows stuff, but apparently CTRL-Break is a way to take things down harder, I don't know, kill -9 for dos, or something. it doesn't raise a KeyboardException (I'm doing this with python 1.5, but the patch is against CVS), but it does allow the signal handler to be called in lieu of exiting the interpreter. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-01 09:22 Message: Logged In: YES user_id=6380 What is SIGBREAK? I don't see it in the Linux man page for signal(7). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466877&group_id=5470 From noreply@sourceforge.net Mon Oct 1 19:01:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 11:01:37 -0700 Subject: [Patches] [ python-Patches-466877 ] SIGBREAK is missing from signal module Message-ID: Patches item #466877, was opened at 2001-10-01 09:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466877&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Steven Scott (progoth) Assigned to: Tim Peters (tim_one) Summary: SIGBREAK is missing from signal module Initial Comment: I didn't know if this belonged in Core or Modules. It's a trivial change, but I needed it for a project I was working on. I couldn't find any mention of using SIGBREAK with python online, so maybe it's not supported? It seems to work fine in the tests I've done, although they were nothing extensive. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-10-01 11:01 Message: Logged In: YES user_id=31435 Accepted the patch (thanks!) and applied it, for 2.2b1: Misc/ACKS; new revision: 1.115 Misc/NEWS; new revision: 1.265 Modules/signalmodule.c; new revision: 2.60 ---------------------------------------------------------------------- Comment By: Steven Scott (progoth) Date: 2001-10-01 10:39 Message: Logged In: YES user_id=61663 sounds good to me...just a way to handle the signal is beyond adequate. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-01 10:27 Message: Logged In: YES user_id=31435 Yes to everything : SIGBREAK is unique to Windows, you can catch it, the default handler calls ExitProcess(), and Python should support it. Assigned to me, but I'm not in favor of changing its default handler: if a process has gone wild, killing it via Task Manager is Draconian (that's like os._exit() -- no cleanup at all is done). ExitProcess() at least attempts to clean up shared OS resources correctly, and since Python has already hijacked Ctrl+C (whose default handler also calls ExitProcess()), Ctrl+Break is the only "semi-clean panic shutdown" gimmick left to the user. It's good to let the user override that, but Python shouldn't presume to change all of Windows default behaviors to make Unix geeks feel more at home <0.9 wink>. ---------------------------------------------------------------------- Comment By: Steven Scott (progoth) Date: 2001-10-01 09:52 Message: Logged In: YES user_id=61663 haha I guess I'm not really up on all the unix stuff either:) so yeah, you can catch it, it would probably be useful to have it handled the same as SIGINT, and throw the KeyboardInterrupt exception. Or maybe it shouldn't be the same, I would worry about how other people are using it, but since the issue hasn't even arisen until now... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-01 09:44 Message: Logged In: YES user_id=6380 Aha. Can you actually catch SIGBREAK? (If so, it's not quite kill -9 :-) This might be useful -- we might want to set the default handler for SIGBREAK that does the same thing as the SIGINT handler. ---------------------------------------------------------------------- Comment By: Steven Scott (progoth) Date: 2001-10-01 09:38 Message: Logged In: YES user_id=61663 unfortunately I work in a windows-only shop, and that's what I'm doing this for. I was trying my hardest to figure out how to catch a CTRL-Break and not just a CTRL-C, and I looked in microsoft's signals.h and saw SIGBREAK. I assume it's a windows only thing. I'm not really up on all the windows stuff, but apparently CTRL-Break is a way to take things down harder, I don't know, kill -9 for dos, or something. it doesn't raise a KeyboardException (I'm doing this with python 1.5, but the patch is against CVS), but it does allow the signal handler to be called in lieu of exiting the interpreter. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-01 09:22 Message: Logged In: YES user_id=6380 What is SIGBREAK? I don't see it in the Linux man page for signal(7). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466877&group_id=5470 From noreply@sourceforge.net Mon Oct 1 20:51:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 12:51:25 -0700 Subject: [Patches] [ python-Patches-466353 ] Py_HUGE_VAL on BeOS for Intel Message-ID: Patches item #466353, was opened at 2001-09-29 04:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466353&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: Py_HUGE_VAL on BeOS for Intel Initial Comment: *** Python-2.2a4/Include/pyport.h~ Thu Sep 6 07:36:55 2001 --- Python-2.2a4/Include/pyport.h Sat Sep 29 19:50:51 2001 *************** *** 236,246 **** --- 236,251 ---- * defined to be the largest positive finite rather than infinity. We need * the std-conforming infinity meaning (provided the platform has one!). */ + #if defined(__BEOS__) && defined(__INTEL__) + /* On BeOS for Intel, INFINITY is defined as float. */ + #define Py_HUGE_VAL HUGE_VAL + #else #ifdef INFINITY #define Py_HUGE_VAL INFINITY #else #define Py_HUGE_VAL HUGE_VAL #endif + #endif /* defined(__BEOS__) && defined(__INTEL__) */ /* Py_OVERFLOWED(X) * Return 1 iff a libm function overflowed. Set errno to 0 before calling On BeOS for Intel, INFINITY is defined as float, and HUGE_VAL is defined as double. This patch is mandatory; with the original pyport.h, "gcc -O" emits internal errors in compilation of Objects/floatobject.c and Objects/longobject.c. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-10-01 12:51 Message: Logged In: YES user_id=31435 Thanks for the followup! That's one messy expansion for INFINITY. I checked in the explicit cast to double, for 2.2b1: Include/pyport.h; new revision: 2.37 But you should still report the internal compiler errors to your compiler supplier. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-09-30 07:45 Message: Logged In: NO >Question: What (exactly) do INFINITY and HUGE_VAL expand >to on this platform? (As above, that INFINITY is "a float" >doesn't explain anything.) #define __HUGE_VAL_bytes { 0, 0, 0, 0, 0, 0, 0xf0, 0x7f } #define __huge_val_t union { unsigned char __c[8]; double __d; } #define HUGE_VAL (((__huge_val_t) { __c: __HUGE_VAL_bytes }).__d) #define __HUGE_VALF_bytes { 0, 0, 0x80, 0x7f } #define __huge_valf_t union { unsigned char __c[4]; float __f; } #define HUGE_VALF (((__huge_valf_t) { __c: __HUGE_VALF_bytes }).__f) #define INFINITY HUGE_VALF >Another question: do the compiler errors go away if the >original Python is replaced by > >#define Py_HUGE_VAL ((double)INFINITY) > >? Yes, they do. Thank you! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-29 09:46 Message: Logged In: YES user_id=31435 Python doesn't use Py_HUGE_VAL for anything except floating- point equality testing against a double, and unary minus (Python doesn't pick apart the bits, or do anything else potentially platform-dependent with it), so a float infinity should be fine (the compiler should simply promote it to double in the places Python uses it, same as any other float used in a double context). Have you reported this as a gcc bug ("internal errors" are compiler bugs)? One problem with your #ifdef is that it will live forever, even after the gcc bug is fixed. Another problem is that I see no reason to believe that a compiler bug is unique to a specific operating system -- in which case the #ifdef doesn't really solve the problem. Therefore I'm extremely reluctant to accept this idea. A general autoconf test setting a (say) CANT_USE_INFINITY_FOR_HUGEVAL symbol when the platform compiler demonstrably screws up would be a good solution. Question: What (exactly) do INFINITY and HUGE_VAL expand to on this platform? (As above, that INFINITY is "a float" doesn't explain anything.) Another question: do the compiler errors go away if the original Python is replaced by #define Py_HUGE_VAL ((double)INFINITY) ? That is, if an explicit cast is enough to fix this, that's by far the simplest approach. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466353&group_id=5470 From noreply@sourceforge.net Mon Oct 1 17:52:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 09:52:10 -0700 Subject: [Patches] [ python-Patches-466877 ] SIGBREAK is missing from signal module Message-ID: Patches item #466877, was opened at 2001-10-01 09:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466877&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steven Scott (progoth) Assigned to: Nobody/Anonymous (nobody) Summary: SIGBREAK is missing from signal module Initial Comment: I didn't know if this belonged in Core or Modules. It's a trivial change, but I needed it for a project I was working on. I couldn't find any mention of using SIGBREAK with python online, so maybe it's not supported? It seems to work fine in the tests I've done, although they were nothing extensive. ---------------------------------------------------------------------- >Comment By: Steven Scott (progoth) Date: 2001-10-01 09:52 Message: Logged In: YES user_id=61663 haha I guess I'm not really up on all the unix stuff either:) so yeah, you can catch it, it would probably be useful to have it handled the same as SIGINT, and throw the KeyboardInterrupt exception. Or maybe it shouldn't be the same, I would worry about how other people are using it, but since the issue hasn't even arisen until now... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-01 09:44 Message: Logged In: YES user_id=6380 Aha. Can you actually catch SIGBREAK? (If so, it's not quite kill -9 :-) This might be useful -- we might want to set the default handler for SIGBREAK that does the same thing as the SIGINT handler. ---------------------------------------------------------------------- Comment By: Steven Scott (progoth) Date: 2001-10-01 09:38 Message: Logged In: YES user_id=61663 unfortunately I work in a windows-only shop, and that's what I'm doing this for. I was trying my hardest to figure out how to catch a CTRL-Break and not just a CTRL-C, and I looked in microsoft's signals.h and saw SIGBREAK. I assume it's a windows only thing. I'm not really up on all the windows stuff, but apparently CTRL-Break is a way to take things down harder, I don't know, kill -9 for dos, or something. it doesn't raise a KeyboardException (I'm doing this with python 1.5, but the patch is against CVS), but it does allow the signal handler to be called in lieu of exiting the interpreter. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-01 09:22 Message: Logged In: YES user_id=6380 What is SIGBREAK? I don't see it in the Linux man page for signal(7). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466877&group_id=5470 From noreply@sourceforge.net Mon Oct 1 23:30:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 15:30:51 -0700 Subject: [Patches] [ python-Patches-460532 ] minidom.Node.text(), per TODO Message-ID: Patches item #460532, was opened at 2001-09-10 18:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460532&group_id=5470 Category: XML Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Chip Salzenberg (chip) Assigned to: Nobody/Anonymous (nobody) Summary: minidom.Node.text(), per TODO Initial Comment: The TODO list for the minidom includes "more convenience methods for text and entities". Well, here's a text() method I've found helpful. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-10-01 15:30 Message: Logged In: YES user_id=21627 Since there have been no further comments speaking in favour of this patch, I close this as rejected. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-11 08:04 Message: Logged In: YES user_id=21627 I'm tempted to reject this, since it is not in the DOM specification. I believe the remark in the TODO list referred to convenience functions defined in DOM level 2, most of which have been implemented already. If a text function was implemented, I feel it should have the semantics of the XPath text() node test. If you want to see this patch integrated, I recommend discussing it on xml-sig first. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460532&group_id=5470 From noreply@sourceforge.net Mon Oct 1 23:36:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 15:36:43 -0700 Subject: [Patches] [ python-Patches-466451 ] popen fix for multiple quoted arguments Message-ID: Patches item #466451, was opened at 2001-09-29 17:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466451&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) >Assigned to: Mark Hammond (mhammond) Summary: popen fix for multiple quoted arguments Initial Comment: In a Windows version of Python, try the following: os.popen('".read() cmd.exe will misinterpret the command string because it strips the first and last quote in the command string (cmd.exe /? for details). This patch does a few things: 1. it encloses the command string sent to cmd.exe in quotes and uses the /S switch 2. if the shell is not command.com or cmd.exe, it passes the -c switch to the shell (this makes popen work if the user's shell is bash, sh, etc.) 3. changes the variables s1, s2 and s3 to cmdPath, completeCmd and cmdArgs ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-10-01 15:36 Message: Logged In: YES user_id=31435 Assigned to MarkH for further pondering. I like giving vrbls useful names The rest seems highly dubious: + Catering to non-MS shells ("-c" vs "/C") is a fine idea, but what about 4DOS or 4NT, or other non-MS shells that also expect /C? It looks like this patch will kill people using them. - It's not backwards compatible regardless of shell (as Brian pointed out). - It's surprising to anyone who has read the cmd docs and expects cmd.exe to work as documented (by MS). - Since it's unique to Python's popen, a command string that works for popen() may break if passed to os.system() instead, and vice versa, and maybe for os.startfile() too. Other things bug me, but I'll stop there . The MS shells are a godawful mess, and it would really be nice to supply a rational x-platform "virtual shell" syntax (as Tcl does for its "exec" cmd). Short of that, I'm not sure a collection of inconsistent and undocumented hacks is actually progress; as is, Python's behavior is at least predictable from reading the MS docs and/or playing with C programs under MSVC. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-30 13:11 Message: Logged In: YES user_id=108973 Mark understands the issue; I've already talked to him about this. Another thing that I should have noted is that this patch does NOT ensure backwards compatibility. Any scripts that manually quote their command strings, to work around this problem, will break. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-30 11:46 Message: Logged In: YES user_id=6380 Tim, whaddayathink? Or is this for Mark? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466451&group_id=5470 From noreply@sourceforge.net Mon Oct 1 23:41:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 15:41:30 -0700 Subject: [Patches] [ python-Patches-450265 ] OS/2 + EMX port - PC directory files Message-ID: Patches item #450265, was opened at 2001-08-12 04:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450265&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Nobody/Anonymous (nobody) Summary: OS/2 + EMX port - PC directory files Initial Comment: The attached patch contains all the changes to the PC directory in the source tree between Python 2.1.1 and the 010812 release of the OS/2+EMX port. This comprises changes to PC/getpathp.c and a new subdirectory, PC/os2emx, which contains the Makefile, config.[ch], dlfcn.[ch], dllentry.c, python DLL .DEF file and a copy of the port's README.os2emx. At the moment, building dynamic modules is still handled by the supplied Makefile, rather than a DistUtils setup.py script. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-10-01 15:41 Message: Logged In: YES user_id=21627 What kind of action would you like to see on this code? In the areas where it changes existing code, there are some questionable chunks, which I would not like to see in Python: - removal of comments - change of control logic without giving a rationale. E.g. there was an explicit comment /* If we have no values, we dont need a ';' */ Your patch changes this to give a ; in all cases. Why? Why is the addition of a terminating null in wprogpath removed? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-12 07:45 Message: Logged In: YES user_id=6380 Andrew, your patch attachment didn't work. Please try again, making sure you check the "file upload checkbox". ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450265&group_id=5470 From noreply@sourceforge.net Mon Oct 1 23:59:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 15:59:37 -0700 Subject: [Patches] [ python-Patches-450267 ] OS/2+EMX port - changes to Python core Message-ID: Patches item #450267, was opened at 2001-08-12 04:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450267&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Nobody/Anonymous (nobody) Summary: OS/2+EMX port - changes to Python core Initial Comment: The attached patch incorporates the changes to the source tree between Python 2.1.1 and the 010812 release of the OS/2+EMX port. It includes changes to files in Include/, Modules/, Objects/ and Python/. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-10-01 15:59 Message: Logged In: YES user_id=21627 Please review this patch carefully again, asking in each case whether this chunk *really* belongs to this patch. Do so by asking "is it specific to the port of Python to os2emx?" There are some changes that are desirable, but are unrelated (like the whitespace changes in PyThread_down_sema). Please submit those in a separate patch. There are also changes that don't belong here at all, like the inclusion of a Modules/Setup. If you are revising this patch, you may also split it into a part that is absolutely necessary, and a part that is nice-to-have. E.g. the termios changes are probably system-specific, but I guess the port would work well without them. Without going in small steps, it seems that we won't move at all. You may consider making use of your checkin permissions for uncritical operations. If you need help in CVS operations, please let me know. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2001-08-13 06:21 Message: Logged In: YES user_id=250749 Thanks for the feedback. At this stage of the game, I'd prefer to work with a "supervisor" rather than take on CVS commit privs, though I realise that "supervisors" are a scarce resource. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-12 07:53 Message: Logged In: YES user_id=6380 Hi Andrew, Thanks for the patches. There's a lot of code (here and in the two previous patches). I'm going to see if we can give you CVS commit permission so you can apply the changes yourself. Note that commit permission (if you get it) doesn't mean that the patch is automatically approved -- I've seen some changes in your diffs that look questionable. You probably know which ones. :-) In general, the guidelines are that you can make changes freely (a) in code you own because it's in a file or directory that's specific to your port; (b) in code specific to your port that's inside #ifdefs for your port (this includes adding); (c) to fix an *obvious* small typo or buglet that bothers your compiler (example: if your compiler warns about an unused variable, feel free to delete it, as long as the unusedness isn't dependent on an #ifdef). For other changes we all appreciate it if you discuss them on python-dev or on the SF patch manager first. Oh, and if you ever check something in that breaks the build on another platform or causes the test suite to fail, people will demand very quick remedies or the checkin will be reversed. :-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450267&group_id=5470 From noreply@sourceforge.net Tue Oct 2 00:24:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 16:24:45 -0700 Subject: [Patches] [ python-Patches-466616 ] Exclude imported items from doctest Message-ID: Patches item #466616, was opened at 2001-09-30 13:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466616&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Hochberg (tim-hochberg) >Assigned to: Tim Peters (tim_one) Summary: Exclude imported items from doctest Initial Comment: With this patch, functions and classes that have been imported into a module are not scanned for docstrings to test by testmod. These tests frequently fail because they end up using the wrong globals. The method used to test whether a function or class is from a given module _does_ work with Jython (tested on 2.1a3). However, the current CVS version of doctest doesn't work with Jython, so I tested this with the a version of doctest from python 2.1 that had the same mods that are in the enclosed patch. Tests were added to the docstring of Tester.rundict to assure that the exclusion works properly. An update to the library documentation for doctest will be posted "real soon now". ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-10-01 16:24 Message: Logged In: YES user_id=31435 Thanks, Tim! I assigned this to me. I'm afraid Jython has some catching up to do so that the new "do the right thing with future-stmt imports in simulated shells" tricks work there too. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466616&group_id=5470 From noreply@sourceforge.net Tue Oct 2 01:43:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 17:43:52 -0700 Subject: [Patches] [ python-Patches-466451 ] popen fix for multiple quoted arguments Message-ID: Patches item #466451, was opened at 2001-09-29 17:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466451&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Mark Hammond (mhammond) Summary: popen fix for multiple quoted arguments Initial Comment: In a Windows version of Python, try the following: os.popen('".read() cmd.exe will misinterpret the command string because it strips the first and last quote in the command string (cmd.exe /? for details). This patch does a few things: 1. it encloses the command string sent to cmd.exe in quotes and uses the /S switch 2. if the shell is not command.com or cmd.exe, it passes the -c switch to the shell (this makes popen work if the user's shell is bash, sh, etc.) 3. changes the variables s1, s2 and s3 to cmdPath, completeCmd and cmdArgs ---------------------------------------------------------------------- >Comment By: Brian Quinlan (bquinlan) Date: 2001-10-01 17:43 Message: Logged In: YES user_id=108973 Tim, I don't disagree with your first point; without specific knowledge of each shell, you really have to guess what the correct shell arguments format is. There are two ways that we can work around that: 1. remove those two lines of code in my patch that do the special case 2. special case bash and sh (at least bash please) and use /C for the other cases I disagree with everything else :-) The command: bash "ls" "/usr/bin" will NOT work on UNIX. Just like typing: cmd /c "copy" "c:\..." "c:\..." won't work. So the UNIX popen implementation must be doing the moral equivalent of quoting the entire command string. So the current behavior is suprising and inconsistent accross platforms. I don't think that we can do anything with regards to backwards compatibility but I think that the cost/benifit favours fixing the problem i.e. accepting my patch :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-01 15:36 Message: Logged In: YES user_id=31435 Assigned to MarkH for further pondering. I like giving vrbls useful names The rest seems highly dubious: + Catering to non-MS shells ("-c" vs "/C") is a fine idea, but what about 4DOS or 4NT, or other non-MS shells that also expect /C? It looks like this patch will kill people using them. - It's not backwards compatible regardless of shell (as Brian pointed out). - It's surprising to anyone who has read the cmd docs and expects cmd.exe to work as documented (by MS). - Since it's unique to Python's popen, a command string that works for popen() may break if passed to os.system() instead, and vice versa, and maybe for os.startfile() too. Other things bug me, but I'll stop there . The MS shells are a godawful mess, and it would really be nice to supply a rational x-platform "virtual shell" syntax (as Tcl does for its "exec" cmd). Short of that, I'm not sure a collection of inconsistent and undocumented hacks is actually progress; as is, Python's behavior is at least predictable from reading the MS docs and/or playing with C programs under MSVC. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-30 13:11 Message: Logged In: YES user_id=108973 Mark understands the issue; I've already talked to him about this. Another thing that I should have noted is that this patch does NOT ensure backwards compatibility. Any scripts that manually quote their command strings, to work around this problem, will break. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-30 11:46 Message: Logged In: YES user_id=6380 Tim, whaddayathink? Or is this for Mark? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466451&group_id=5470 From noreply@sourceforge.net Tue Oct 2 02:56:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 18:56:35 -0700 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: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) 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: 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 Tue Oct 2 03:12:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 19:12:16 -0700 Subject: [Patches] [ python-Patches-466451 ] popen fix for multiple quoted arguments Message-ID: Patches item #466451, was opened at 2001-09-29 17:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466451&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Mark Hammond (mhammond) Summary: popen fix for multiple quoted arguments Initial Comment: In a Windows version of Python, try the following: os.popen('".read() cmd.exe will misinterpret the command string because it strips the first and last quote in the command string (cmd.exe /? for details). This patch does a few things: 1. it encloses the command string sent to cmd.exe in quotes and uses the /S switch 2. if the shell is not command.com or cmd.exe, it passes the -c switch to the shell (this makes popen work if the user's shell is bash, sh, etc.) 3. changes the variables s1, s2 and s3 to cmdPath, completeCmd and cmdArgs ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-10-01 19:12 Message: Logged In: YES user_id=31435 Special-casing bash instead (+ other shells known to need it) to use -c would be fine. I *expect* os.system and os.popen to work differently across platforms, because both depend crucially on the platform shell spawned to crack the cmdline. Tcl's "exec" (which I mentioned before) has the only good solution to this I'm aware of, via getting the platform shells out of the equation entirely (even on Unix). Python does nothing of the sort, and the more undocumented tricks are stuffed into it, the more baffling it gets when things go wrong (as they often will, and especially on Windows). I didn't understand the point to noting that bash "ls" "/usr/bin" won't work on Unix. Neither will bash ls /usr/bin The quotes are irrelevant here, yes? Python isn't adding quotes to things, or deleting them, anyway. Note that if you write your own copy.bat, command /c "copy" "whatever1" "whatever2" does work fine on Win9x (command.com). It doesn't work with the Windows copy solely because copy is a command.com builtin -- and you can't hide arbitrary platform crap like that from users either. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-01 17:43 Message: Logged In: YES user_id=108973 Tim, I don't disagree with your first point; without specific knowledge of each shell, you really have to guess what the correct shell arguments format is. There are two ways that we can work around that: 1. remove those two lines of code in my patch that do the special case 2. special case bash and sh (at least bash please) and use /C for the other cases I disagree with everything else :-) The command: bash "ls" "/usr/bin" will NOT work on UNIX. Just like typing: cmd /c "copy" "c:\..." "c:\..." won't work. So the UNIX popen implementation must be doing the moral equivalent of quoting the entire command string. So the current behavior is suprising and inconsistent accross platforms. I don't think that we can do anything with regards to backwards compatibility but I think that the cost/benifit favours fixing the problem i.e. accepting my patch :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-01 15:36 Message: Logged In: YES user_id=31435 Assigned to MarkH for further pondering. I like giving vrbls useful names The rest seems highly dubious: + Catering to non-MS shells ("-c" vs "/C") is a fine idea, but what about 4DOS or 4NT, or other non-MS shells that also expect /C? It looks like this patch will kill people using them. - It's not backwards compatible regardless of shell (as Brian pointed out). - It's surprising to anyone who has read the cmd docs and expects cmd.exe to work as documented (by MS). - Since it's unique to Python's popen, a command string that works for popen() may break if passed to os.system() instead, and vice versa, and maybe for os.startfile() too. Other things bug me, but I'll stop there . The MS shells are a godawful mess, and it would really be nice to supply a rational x-platform "virtual shell" syntax (as Tcl does for its "exec" cmd). Short of that, I'm not sure a collection of inconsistent and undocumented hacks is actually progress; as is, Python's behavior is at least predictable from reading the MS docs and/or playing with C programs under MSVC. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-30 13:11 Message: Logged In: YES user_id=108973 Mark understands the issue; I've already talked to him about this. Another thing that I should have noted is that this patch does NOT ensure backwards compatibility. Any scripts that manually quote their command strings, to work around this problem, will break. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-30 11:46 Message: Logged In: YES user_id=6380 Tim, whaddayathink? Or is this for Mark? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466451&group_id=5470 From noreply@sourceforge.net Tue Oct 2 03:51:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 19:51:04 -0700 Subject: [Patches] [ python-Patches-466451 ] popen fix for multiple quoted arguments Message-ID: Patches item #466451, was opened at 2001-09-29 17:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466451&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Mark Hammond (mhammond) Summary: popen fix for multiple quoted arguments Initial Comment: In a Windows version of Python, try the following: os.popen('".read() cmd.exe will misinterpret the command string because it strips the first and last quote in the command string (cmd.exe /? for details). This patch does a few things: 1. it encloses the command string sent to cmd.exe in quotes and uses the /S switch 2. if the shell is not command.com or cmd.exe, it passes the -c switch to the shell (this makes popen work if the user's shell is bash, sh, etc.) 3. changes the variables s1, s2 and s3 to cmdPath, completeCmd and cmdArgs ---------------------------------------------------------------------- >Comment By: Brian Quinlan (bquinlan) Date: 2001-10-01 19:51 Message: Logged In: YES user_id=108973 Sorry, I was sloppy about my point (I missed the -c switch). Here is dump from my UNIX box: [93:~] brian% sh -c "ls" "/usr" Desktop Documents Movies Pictures Sites bash-2.05 Dev Library Music Public Wolf MP Test setiathome [93:~] brian% sh -c ""ls" "/usr"" bin lib local share include libexec sbin standalone [93:~] brian% python [...] >>> import os >>> os.popen("ls /usr").read() 'bin\ninclude\nlib\nlibexec\nlocal\nsbin\nshare\nstandalone\ n' You will notice that the results from Python are inline with the quoted invocation of sh -c. And "man popen" on my box says that "This command is passed to /bin/sh using the - c flag;..." so presumably popen is quoting the arguments (Windows _popen doesn't though, I checked). And I didn't change the COMMAND.COM behavior - I think that it is a special case that is too broken to fix and will, with any luck, will die soon. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-01 19:12 Message: Logged In: YES user_id=31435 Special-casing bash instead (+ other shells known to need it) to use -c would be fine. I *expect* os.system and os.popen to work differently across platforms, because both depend crucially on the platform shell spawned to crack the cmdline. Tcl's "exec" (which I mentioned before) has the only good solution to this I'm aware of, via getting the platform shells out of the equation entirely (even on Unix). Python does nothing of the sort, and the more undocumented tricks are stuffed into it, the more baffling it gets when things go wrong (as they often will, and especially on Windows). I didn't understand the point to noting that bash "ls" "/usr/bin" won't work on Unix. Neither will bash ls /usr/bin The quotes are irrelevant here, yes? Python isn't adding quotes to things, or deleting them, anyway. Note that if you write your own copy.bat, command /c "copy" "whatever1" "whatever2" does work fine on Win9x (command.com). It doesn't work with the Windows copy solely because copy is a command.com builtin -- and you can't hide arbitrary platform crap like that from users either. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-01 17:43 Message: Logged In: YES user_id=108973 Tim, I don't disagree with your first point; without specific knowledge of each shell, you really have to guess what the correct shell arguments format is. There are two ways that we can work around that: 1. remove those two lines of code in my patch that do the special case 2. special case bash and sh (at least bash please) and use /C for the other cases I disagree with everything else :-) The command: bash "ls" "/usr/bin" will NOT work on UNIX. Just like typing: cmd /c "copy" "c:\..." "c:\..." won't work. So the UNIX popen implementation must be doing the moral equivalent of quoting the entire command string. So the current behavior is suprising and inconsistent accross platforms. I don't think that we can do anything with regards to backwards compatibility but I think that the cost/benifit favours fixing the problem i.e. accepting my patch :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-01 15:36 Message: Logged In: YES user_id=31435 Assigned to MarkH for further pondering. I like giving vrbls useful names The rest seems highly dubious: + Catering to non-MS shells ("-c" vs "/C") is a fine idea, but what about 4DOS or 4NT, or other non-MS shells that also expect /C? It looks like this patch will kill people using them. - It's not backwards compatible regardless of shell (as Brian pointed out). - It's surprising to anyone who has read the cmd docs and expects cmd.exe to work as documented (by MS). - Since it's unique to Python's popen, a command string that works for popen() may break if passed to os.system() instead, and vice versa, and maybe for os.startfile() too. Other things bug me, but I'll stop there . The MS shells are a godawful mess, and it would really be nice to supply a rational x-platform "virtual shell" syntax (as Tcl does for its "exec" cmd). Short of that, I'm not sure a collection of inconsistent and undocumented hacks is actually progress; as is, Python's behavior is at least predictable from reading the MS docs and/or playing with C programs under MSVC. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-30 13:11 Message: Logged In: YES user_id=108973 Mark understands the issue; I've already talked to him about this. Another thing that I should have noted is that this patch does NOT ensure backwards compatibility. Any scripts that manually quote their command strings, to work around this problem, will break. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-30 11:46 Message: Logged In: YES user_id=6380 Tim, whaddayathink? Or is this for Mark? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466451&group_id=5470 From noreply@sourceforge.net Tue Oct 2 04:55:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 20:55:30 -0700 Subject: [Patches] [ python-Patches-466616 ] Exclude imported items from doctest Message-ID: Patches item #466616, was opened at 2001-09-30 13:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466616&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tim Hochberg (tim-hochberg) Assigned to: Tim Peters (tim_one) Summary: Exclude imported items from doctest Initial Comment: With this patch, functions and classes that have been imported into a module are not scanned for docstrings to test by testmod. These tests frequently fail because they end up using the wrong globals. The method used to test whether a function or class is from a given module _does_ work with Jython (tested on 2.1a3). However, the current CVS version of doctest doesn't work with Jython, so I tested this with the a version of doctest from python 2.1 that had the same mods that are in the enclosed patch. Tests were added to the docstring of Tester.rundict to assure that the exclusion works properly. An update to the library documentation for doctest will be posted "real soon now". ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-10-01 20:55 Message: Logged In: YES user_id=31435 Nice work, Tim. I checked this in after fiddling the tests for "is a function" and "is a class" (here and elsewhere in doctest) -- that's not as simple in 2.2 as it used to be, and doctest wasn't smart enough without the patch either (although you probably wouldn't notice without testing new- style classes). Lib/doctest.py; new revision: 1.18 Lib/test/test_pyclbr.py; new revision: 1.5 Misc/NEWS; new revision: 1.266 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-01 16:24 Message: Logged In: YES user_id=31435 Thanks, Tim! I assigned this to me. I'm afraid Jython has some catching up to do so that the new "do the right thing with future-stmt imports in simulated shells" tricks work there too. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466616&group_id=5470 From noreply@sourceforge.net Tue Oct 2 05:30:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Oct 2001 21:30:43 -0700 Subject: [Patches] [ python-Patches-466616 ] Exclude imported items from doctest Message-ID: Patches item #466616, was opened at 2001-09-30 13:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466616&group_id=5470 Category: Library (Lib) Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Tim Hochberg (tim-hochberg) Assigned to: Tim Peters (tim_one) Summary: Exclude imported items from doctest Initial Comment: With this patch, functions and classes that have been imported into a module are not scanned for docstrings to test by testmod. These tests frequently fail because they end up using the wrong globals. The method used to test whether a function or class is from a given module _does_ work with Jython (tested on 2.1a3). However, the current CVS version of doctest doesn't work with Jython, so I tested this with the a version of doctest from python 2.1 that had the same mods that are in the enclosed patch. Tests were added to the docstring of Tester.rundict to assure that the exclusion works properly. An update to the library documentation for doctest will be posted "real soon now". ---------------------------------------------------------------------- >Comment By: Tim Hochberg (tim-hochberg) Date: 2001-10-01 21:30 Message: Logged In: YES user_id=294744 Great to here it, but... Arghhh! Somewhere in preparing the patch and moving back and forth between CVS and 2.1 I dropped a line from the patch. And it's the line that actually makes it work. I'm too tired to prepare a patch tonight, but rundict should be invoked as "f, t = tester.rundict(m.__dict__, name, m)" in testmod (the 'm' is added). Otherwise the patch doesn't really do anything in normal usage, which is silly. Sigh. I can prepare a patch tomorrow if you like. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-01 20:55 Message: Logged In: YES user_id=31435 Nice work, Tim. I checked this in after fiddling the tests for "is a function" and "is a class" (here and elsewhere in doctest) -- that's not as simple in 2.2 as it used to be, and doctest wasn't smart enough without the patch either (although you probably wouldn't notice without testing new- style classes). Lib/doctest.py; new revision: 1.18 Lib/test/test_pyclbr.py; new revision: 1.5 Misc/NEWS; new revision: 1.266 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-01 16:24 Message: Logged In: YES user_id=31435 Thanks, Tim! I assigned this to me. I'm afraid Jython has some catching up to do so that the new "do the right thing with future-stmt imports in simulated shells" tricks work there too. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466616&group_id=5470 From noreply@sourceforge.net Tue Oct 2 14:14:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Oct 2001 06:14:15 -0700 Subject: [Patches] [ python-Patches-466616 ] Exclude imported items from doctest Message-ID: Patches item #466616, was opened at 2001-09-30 13:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466616&group_id=5470 Category: Library (Lib) Group: None >Status: Open Resolution: Fixed Priority: 5 Submitted By: Tim Hochberg (tim-hochberg) Assigned to: Tim Peters (tim_one) Summary: Exclude imported items from doctest Initial Comment: With this patch, functions and classes that have been imported into a module are not scanned for docstrings to test by testmod. These tests frequently fail because they end up using the wrong globals. The method used to test whether a function or class is from a given module _does_ work with Jython (tested on 2.1a3). However, the current CVS version of doctest doesn't work with Jython, so I tested this with the a version of doctest from python 2.1 that had the same mods that are in the enclosed patch. Tests were added to the docstring of Tester.rundict to assure that the exclusion works properly. An update to the library documentation for doctest will be posted "real soon now". ---------------------------------------------------------------------- Comment By: Tim Hochberg (tim-hochberg) Date: 2001-10-01 21:30 Message: Logged In: YES user_id=294744 Great to here it, but... Arghhh! Somewhere in preparing the patch and moving back and forth between CVS and 2.1 I dropped a line from the patch. And it's the line that actually makes it work. I'm too tired to prepare a patch tonight, but rundict should be invoked as "f, t = tester.rundict(m.__dict__, name, m)" in testmod (the 'm' is added). Otherwise the patch doesn't really do anything in normal usage, which is silly. Sigh. I can prepare a patch tomorrow if you like. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-01 20:55 Message: Logged In: YES user_id=31435 Nice work, Tim. I checked this in after fiddling the tests for "is a function" and "is a class" (here and elsewhere in doctest) -- that's not as simple in 2.2 as it used to be, and doctest wasn't smart enough without the patch either (although you probably wouldn't notice without testing new- style classes). Lib/doctest.py; new revision: 1.18 Lib/test/test_pyclbr.py; new revision: 1.5 Misc/NEWS; new revision: 1.266 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-01 16:24 Message: Logged In: YES user_id=31435 Thanks, Tim! I assigned this to me. I'm afraid Jython has some catching up to do so that the new "do the right thing with future-stmt imports in simulated shells" tricks work there too. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466616&group_id=5470 From noreply@sourceforge.net Tue Oct 2 22:01:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Oct 2001 14:01:49 -0700 Subject: [Patches] [ python-Patches-466628 ] Doc changes for doctest patch (#466616) Message-ID: Patches item #466628, was opened at 2001-09-30 14:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466628&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Tim Hochberg (tim-hochberg) Assigned to: Tim Peters (tim_one) Summary: Doc changes for doctest patch (#466616) Initial Comment: Documentation changes that accompany patch #466616, "Exclude imported items from doctest". See that patch for details, but here is a summary: With this patch, functions and classes that have been imported into a module are not scanned for docstrings to test by testmod. These tests frequently fail because they end up using the wrong globals. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-10-02 14:01 Message: Logged In: YES user_id=31435 Accepted and checked in for 2.2b1, Doc/lib/libdoctest.tex; new revision: 1.9 Fred, this consisted mostly of deleting text, so there's not much for you to worry about. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-01 08:02 Message: Logged In: YES user_id=3066 Assigned to Tim for content review and approval. Tim, you can either check it in yourself or assign back to me for markup/editorial review and checkin. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466628&group_id=5470 From noreply@sourceforge.net Tue Oct 2 22:10:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Oct 2001 14:10:02 -0700 Subject: [Patches] [ python-Patches-415226 ] new base class for binary packaging Message-ID: Patches item #415226, was opened at 2001-04-10 12:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415226&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Alexander (mwa) Assigned to: A.M. Kuchling (akuchling) Summary: new base class for binary packaging Initial Comment: bdist_packager.py provides an abstract base class for bdist commands. It provides easy access to all the PEP 241 metadata fields, plus "revision" for the package revision and installation scripts for preinstall, postinstall preremove, and postremove. That covers the base characteristics of all the package managers that I'm familiar with. If anyone can think of any others, let me know, otherwise additional extensions would be implemented in the specific packager's commands. I would, however, discourage _requiring_ any additional fields. It would be nice if by simply supplying the PEP241 metadata under the [bdist_packager] section all subclassed packagers worked with no further effort. It also has rudimentary relocation support by including a --no-autorelocate option. The bdist_packager is also where I see creating seperate binary packages for sub-packages supported. My need for that is much less than my desire for it right now, so I didn't give it much thought as I wrote it. I'd be delighted to hear any comments and suggestions on how to approach sub-packaging, though. ---------------------------------------------------------------------- >Comment By: Mark Alexander (mwa) Date: 2001-10-02 14:10 Message: Logged In: YES user_id=12810 Regarding script code: The preinstall, postinstall, etc. scripts are hooked into the package manager specific subclasses. It's the responsibility of the specific class to "do the right thing". For *NIX package managers, this is usually script code, although changing the help text to be more informative isn't a problem. More specifically, using python scripts under pkgtool and sdux would fail. Install scripts are not executed, they're sourced (in some wierd fashion I've yet to identify). Theoretically, using a shell script to find the python interpreter by querying the package manager and calling it with either -i or a runtime created script should work fine. This is intended as a class for instantiating new bdist commands with full support for pep 241. Current bdist commands do their own thing, and they do it very differently. I'd rather see this put in as a migration path than shut down bdist commands that function just fine on their own. Eventual adoption of a standard abstract base would mean that module authors could provide all metadata in a standard format, and distutils would be able to create binary packages for systems the author doesn't have access to. This works for Solaris pkgtool and HP-UX SDUX. All three patches can be included with ZERO side effects on any other aspect of Distutils. I'm really kind of curious why they're not integrated yet so other's can try them out. ---------------------------------------------------------------------- Comment By: david arnold (dja) Date: 2001-09-20 02:08 Message: Logged In: YES user_id=78574 i recently struck a case where i wanted the ability to run a post-install script on Windows (from a bdist_wininst-produced package). while i agree with what seems to be the basic intention of this patch, wouldn't it be more useful to have the various scripts run by the Python interpreter, rather than Bourne shell (which is extremely seldom available on Windows, MacOS, etc) ? i went looking for the source of the .exe file embedded in the wininst command, but couldn't find it. does anyone know where it lives? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-06-06 22:33 Message: Logged In: YES user_id=21627 Shouldn't the patch also modify the existing bdist commands to use this as a base class? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415226&group_id=5470 From noreply@sourceforge.net Tue Oct 2 23:31:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Oct 2001 15:31:52 -0700 Subject: [Patches] [ python-Patches-466616 ] Exclude imported items from doctest Message-ID: Patches item #466616, was opened at 2001-09-30 13:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466616&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Tim Hochberg (tim-hochberg) Assigned to: Tim Peters (tim_one) Summary: Exclude imported items from doctest Initial Comment: With this patch, functions and classes that have been imported into a module are not scanned for docstrings to test by testmod. These tests frequently fail because they end up using the wrong globals. The method used to test whether a function or class is from a given module _does_ work with Jython (tested on 2.1a3). However, the current CVS version of doctest doesn't work with Jython, so I tested this with the a version of doctest from python 2.1 that had the same mods that are in the enclosed patch. Tests were added to the docstring of Tester.rundict to assure that the exclusion works properly. An update to the library documentation for doctest will be posted "real soon now". ---------------------------------------------------------------------- >Comment By: Tim Hochberg (tim-hochberg) Date: 2001-10-02 15:31 Message: Logged In: YES user_id=294744 I meant great to _hear_ it. Anyway, I'm uploading a patch against against _current_ CVS (after tim_one's update) that fixes the unpatched line and adds a test for it in the rundict docstring. (That was the only place I could think to put it without replicating all of the new.module stuff). ---------------------------------------------------------------------- Comment By: Tim Hochberg (tim-hochberg) Date: 2001-10-01 21:30 Message: Logged In: YES user_id=294744 Great to here it, but... Arghhh! Somewhere in preparing the patch and moving back and forth between CVS and 2.1 I dropped a line from the patch. And it's the line that actually makes it work. I'm too tired to prepare a patch tonight, but rundict should be invoked as "f, t = tester.rundict(m.__dict__, name, m)" in testmod (the 'm' is added). Otherwise the patch doesn't really do anything in normal usage, which is silly. Sigh. I can prepare a patch tomorrow if you like. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-01 20:55 Message: Logged In: YES user_id=31435 Nice work, Tim. I checked this in after fiddling the tests for "is a function" and "is a class" (here and elsewhere in doctest) -- that's not as simple in 2.2 as it used to be, and doctest wasn't smart enough without the patch either (although you probably wouldn't notice without testing new- style classes). Lib/doctest.py; new revision: 1.18 Lib/test/test_pyclbr.py; new revision: 1.5 Misc/NEWS; new revision: 1.266 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-01 16:24 Message: Logged In: YES user_id=31435 Thanks, Tim! I assigned this to me. I'm afraid Jython has some catching up to do so that the new "do the right thing with future-stmt imports in simulated shells" tricks work there too. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466616&group_id=5470 From noreply@sourceforge.net Tue Oct 2 23:48:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Oct 2001 15:48:05 -0700 Subject: [Patches] [ python-Patches-466616 ] Exclude imported items from doctest Message-ID: Patches item #466616, was opened at 2001-09-30 13:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466616&group_id=5470 Category: Library (Lib) Group: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Tim Hochberg (tim-hochberg) Assigned to: Tim Peters (tim_one) Summary: Exclude imported items from doctest Initial Comment: With this patch, functions and classes that have been imported into a module are not scanned for docstrings to test by testmod. These tests frequently fail because they end up using the wrong globals. The method used to test whether a function or class is from a given module _does_ work with Jython (tested on 2.1a3). However, the current CVS version of doctest doesn't work with Jython, so I tested this with the a version of doctest from python 2.1 that had the same mods that are in the enclosed patch. Tests were added to the docstring of Tester.rundict to assure that the exclusion works properly. An update to the library documentation for doctest will be posted "real soon now". ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-10-02 15:48 Message: Logged In: YES user_id=31435 Closed again, after applying the new patch, Lib/doctest.py; new revision: 1.19 ---------------------------------------------------------------------- Comment By: Tim Hochberg (tim-hochberg) Date: 2001-10-02 15:31 Message: Logged In: YES user_id=294744 I meant great to _hear_ it. Anyway, I'm uploading a patch against against _current_ CVS (after tim_one's update) that fixes the unpatched line and adds a test for it in the rundict docstring. (That was the only place I could think to put it without replicating all of the new.module stuff). ---------------------------------------------------------------------- Comment By: Tim Hochberg (tim-hochberg) Date: 2001-10-01 21:30 Message: Logged In: YES user_id=294744 Great to here it, but... Arghhh! Somewhere in preparing the patch and moving back and forth between CVS and 2.1 I dropped a line from the patch. And it's the line that actually makes it work. I'm too tired to prepare a patch tonight, but rundict should be invoked as "f, t = tester.rundict(m.__dict__, name, m)" in testmod (the 'm' is added). Otherwise the patch doesn't really do anything in normal usage, which is silly. Sigh. I can prepare a patch tomorrow if you like. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-01 20:55 Message: Logged In: YES user_id=31435 Nice work, Tim. I checked this in after fiddling the tests for "is a function" and "is a class" (here and elsewhere in doctest) -- that's not as simple in 2.2 as it used to be, and doctest wasn't smart enough without the patch either (although you probably wouldn't notice without testing new- style classes). Lib/doctest.py; new revision: 1.18 Lib/test/test_pyclbr.py; new revision: 1.5 Misc/NEWS; new revision: 1.266 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-01 16:24 Message: Logged In: YES user_id=31435 Thanks, Tim! I assigned this to me. I'm afraid Jython has some catching up to do so that the new "do the right thing with future-stmt imports in simulated shells" tricks work there too. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466616&group_id=5470 From noreply@sourceforge.net Wed Oct 3 06:48:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Oct 2001 22:48:29 -0700 Subject: [Patches] [ python-Patches-466451 ] popen fix for multiple quoted arguments Message-ID: Patches item #466451, was opened at 2001-09-29 17:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466451&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Mark Hammond (mhammond) Summary: popen fix for multiple quoted arguments Initial Comment: In a Windows version of Python, try the following: os.popen('".read() cmd.exe will misinterpret the command string because it strips the first and last quote in the command string (cmd.exe /? for details). This patch does a few things: 1. it encloses the command string sent to cmd.exe in quotes and uses the /S switch 2. if the shell is not command.com or cmd.exe, it passes the -c switch to the shell (this makes popen work if the user's shell is bash, sh, etc.) 3. changes the variables s1, s2 and s3 to cmdPath, completeCmd and cmdArgs ---------------------------------------------------------------------- >Comment By: Brian Quinlan (bquinlan) Date: 2001-10-02 22:48 Message: Logged In: YES user_id=108973 How about this as an alternate implementation: if we are running on a Windows version that should have cmd.exe, we just execute that and ignore COMSPEC? Notice how popen on UNIX runs sh, not your prefered shell. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-01 19:51 Message: Logged In: YES user_id=108973 Sorry, I was sloppy about my point (I missed the -c switch). Here is dump from my UNIX box: [93:~] brian% sh -c "ls" "/usr" Desktop Documents Movies Pictures Sites bash-2.05 Dev Library Music Public Wolf MP Test setiathome [93:~] brian% sh -c ""ls" "/usr"" bin lib local share include libexec sbin standalone [93:~] brian% python [...] >>> import os >>> os.popen("ls /usr").read() 'bin\ninclude\nlib\nlibexec\nlocal\nsbin\nshare\nstandalone\ n' You will notice that the results from Python are inline with the quoted invocation of sh -c. And "man popen" on my box says that "This command is passed to /bin/sh using the - c flag;..." so presumably popen is quoting the arguments (Windows _popen doesn't though, I checked). And I didn't change the COMMAND.COM behavior - I think that it is a special case that is too broken to fix and will, with any luck, will die soon. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-01 19:12 Message: Logged In: YES user_id=31435 Special-casing bash instead (+ other shells known to need it) to use -c would be fine. I *expect* os.system and os.popen to work differently across platforms, because both depend crucially on the platform shell spawned to crack the cmdline. Tcl's "exec" (which I mentioned before) has the only good solution to this I'm aware of, via getting the platform shells out of the equation entirely (even on Unix). Python does nothing of the sort, and the more undocumented tricks are stuffed into it, the more baffling it gets when things go wrong (as they often will, and especially on Windows). I didn't understand the point to noting that bash "ls" "/usr/bin" won't work on Unix. Neither will bash ls /usr/bin The quotes are irrelevant here, yes? Python isn't adding quotes to things, or deleting them, anyway. Note that if you write your own copy.bat, command /c "copy" "whatever1" "whatever2" does work fine on Win9x (command.com). It doesn't work with the Windows copy solely because copy is a command.com builtin -- and you can't hide arbitrary platform crap like that from users either. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-01 17:43 Message: Logged In: YES user_id=108973 Tim, I don't disagree with your first point; without specific knowledge of each shell, you really have to guess what the correct shell arguments format is. There are two ways that we can work around that: 1. remove those two lines of code in my patch that do the special case 2. special case bash and sh (at least bash please) and use /C for the other cases I disagree with everything else :-) The command: bash "ls" "/usr/bin" will NOT work on UNIX. Just like typing: cmd /c "copy" "c:\..." "c:\..." won't work. So the UNIX popen implementation must be doing the moral equivalent of quoting the entire command string. So the current behavior is suprising and inconsistent accross platforms. I don't think that we can do anything with regards to backwards compatibility but I think that the cost/benifit favours fixing the problem i.e. accepting my patch :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-01 15:36 Message: Logged In: YES user_id=31435 Assigned to MarkH for further pondering. I like giving vrbls useful names The rest seems highly dubious: + Catering to non-MS shells ("-c" vs "/C") is a fine idea, but what about 4DOS or 4NT, or other non-MS shells that also expect /C? It looks like this patch will kill people using them. - It's not backwards compatible regardless of shell (as Brian pointed out). - It's surprising to anyone who has read the cmd docs and expects cmd.exe to work as documented (by MS). - Since it's unique to Python's popen, a command string that works for popen() may break if passed to os.system() instead, and vice versa, and maybe for os.startfile() too. Other things bug me, but I'll stop there . The MS shells are a godawful mess, and it would really be nice to supply a rational x-platform "virtual shell" syntax (as Tcl does for its "exec" cmd). Short of that, I'm not sure a collection of inconsistent and undocumented hacks is actually progress; as is, Python's behavior is at least predictable from reading the MS docs and/or playing with C programs under MSVC. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-30 13:11 Message: Logged In: YES user_id=108973 Mark understands the issue; I've already talked to him about this. Another thing that I should have noted is that this patch does NOT ensure backwards compatibility. Any scripts that manually quote their command strings, to work around this problem, will break. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-30 11:46 Message: Logged In: YES user_id=6380 Tim, whaddayathink? Or is this for Mark? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466451&group_id=5470 From noreply@sourceforge.net Wed Oct 3 11:20:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Oct 2001 03:20:35 -0700 Subject: [Patches] [ python-Patches-467455 ] Enhanced environment variables Message-ID: Patches item #467455, was opened at 2001-10-03 03:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467455&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Toby Dickenson (htrd) Assigned to: Nobody/Anonymous (nobody) Summary: Enhanced environment variables Initial Comment: python supports the -d -O and -v command line switches by incrementing the Py_DebugFlag, Py_OptimizeFlag and Py_VerboseFlag. It is also possible to set Py_VerboseFlag etc using environment variables. The logic is currently: if env.var. set and non-empty: if flag is zero: set flag to 1 However it is not possible to use environment variables to set the flags to a value greater than one. This patch changes to logic to: if env.var. set and non-empty: if env.var. is an integer: set flag to that integer if flag is zero: set flag to 1 Under this patch, anyone currently using PYTHONVERBOSE=yes will get the same output as before. PYTHONVERBNOSE=2 will generate more verbosity than before. The only unusual case that the following three are still all equivalent: PYTHONVERBOSE=yespleas PYTHONVERBOSE=1 PYTHONVERBOSE=0 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467455&group_id=5470 From noreply@sourceforge.net Wed Oct 3 11:34:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Oct 2001 03:34:13 -0700 Subject: [Patches] [ python-Patches-416704 ] More robust freeze Message-ID: Patches item #416704, was opened at 2001-04-17 07:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416704&group_id=5470 Category: None Group: None Status: Open Resolution: Out of Date Priority: 5 Submitted By: Toby Dickenson (htrd) Assigned to: Guido van Rossum (gvanrossum) Summary: More robust freeze Initial Comment: This patch addresses three issues, all relating to robustness of frozen programs. Specifically, this patch allows explicit and complete control over which modules may be loaded from source on the filesystem of the host system where the frozen program is run, and which may not. Without this patch it is impossible to create a non- trivial frozen program which will *never* load a module from source on the filesystem. 1. A patch to correct bug #404545 (frozen package import uses wrong files). Under this change, submodules of a frozen package must themselves be frozen modules. Previously, the import machinery may also try to import submodules from curiously named files (packagename.modulename.py) from directories in sys.path 2. A patch to add an extra command line option -E to freeze.py, which forces freeze to terminate with an error message if there are modules that it can not locate. If this switch is not specified then the default behaviour is unchanged: modules which can not be found by freeze will not be included in the frozen program, and the import machinery will try to load them from source on sys.path when the frozen program is run. In practice we have found that a missing module is probably an error (and it is a fairly frequent error too!). The -E switch can be used to detect this error; any missing modules will cause freeze.py to fail. In the rare case of a frozen module importing a non- frozen one (ie one which should be loaded from source when the program is run), the non-frozen module must be excluded from the freeze using the -x option. 3. A patch to add an extra command line option -X to freeze.py, which indicates that a specified module is excluded from the freeze, and also that the frozen program should not try to load the module from sys.path when it is imported. Importing the specified module will always trigger an ImportError. This is useful if a module used by a frozen program can optionally use a submodule... try: import optional_submodule except ImportError: pass It may be preferable for the frozen program's behaviour to not depend on whether optional_submodule happens to be installed on the host system, and that the 'import optional_submodule' should always fail with an ImportError. This can be achieved using the '- X optional_submodule' command line switch to freeze.py This is implemented by including the excluded module in the frozen imports table (_PyImport_FrozenModules), with the code pointer set to NULL. ---------------------------------------------------------------------- >Comment By: Toby Dickenson (htrd) Date: 2001-10-03 03:34 Message: Logged In: YES user_id=46460 Attached is an updated patch against the current CVS. I have verified each aspect of this patch with Py_VerboseFlag set to 2, so that import.c traces out which files it is checking during the import process. (Im not aware of an easy way to set Py_VerboseFlag to 2 in a frozen program.... Ive added a new patch #467455 to enhance the PYTHONVERBOSE environment variable to support this) I can confirm that the current CVS (rougly 2.2a4) still demonstrates the problem from bug #404545. The details are slightly different to my original bug report; Im not sure if this is due to an incidental change in python since 1.5.2, or if I messed up that bug report. Anyway, using PyVerbose=2 clearly shows that before this patch it is looking for files it shouldnt (and it uses those files if they exist). After this patch, it definitely only looks for the right files. The other aspect of this patch, adding -E and -X to freeze.py, is exactly as before. ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-09-10 07:20 Message: Logged In: YES user_id=46460 OK, I should get round to this soon. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 08:50 Message: Logged In: YES user_id=6380 I'm willing to look at this, but right now the patch doesn't apply cleanly. From the headers in the diff file it looks like you're patching an early beta for 2.0. If you can rework this for current CVS or Python 2.2a2 or 2.2a3, that would be great. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-06-07 15:26 Message: Logged In: YES user_id=21627 Why is this assigned to Mark? I cannot see anything windows-specific in it. Mark, if you are not interested in reviewing this patch, I recommend to unassign this from yourself. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416704&group_id=5470 From noreply@sourceforge.net Wed Oct 3 11:37:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Oct 2001 03:37:11 -0700 Subject: [Patches] [ python-Patches-416704 ] More robust freeze Message-ID: Patches item #416704, was opened at 2001-04-17 07:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416704&group_id=5470 Category: None Group: None Status: Open Resolution: Out of Date Priority: 5 Submitted By: Toby Dickenson (htrd) Assigned to: Guido van Rossum (gvanrossum) Summary: More robust freeze Initial Comment: This patch addresses three issues, all relating to robustness of frozen programs. Specifically, this patch allows explicit and complete control over which modules may be loaded from source on the filesystem of the host system where the frozen program is run, and which may not. Without this patch it is impossible to create a non- trivial frozen program which will *never* load a module from source on the filesystem. 1. A patch to correct bug #404545 (frozen package import uses wrong files). Under this change, submodules of a frozen package must themselves be frozen modules. Previously, the import machinery may also try to import submodules from curiously named files (packagename.modulename.py) from directories in sys.path 2. A patch to add an extra command line option -E to freeze.py, which forces freeze to terminate with an error message if there are modules that it can not locate. If this switch is not specified then the default behaviour is unchanged: modules which can not be found by freeze will not be included in the frozen program, and the import machinery will try to load them from source on sys.path when the frozen program is run. In practice we have found that a missing module is probably an error (and it is a fairly frequent error too!). The -E switch can be used to detect this error; any missing modules will cause freeze.py to fail. In the rare case of a frozen module importing a non- frozen one (ie one which should be loaded from source when the program is run), the non-frozen module must be excluded from the freeze using the -x option. 3. A patch to add an extra command line option -X to freeze.py, which indicates that a specified module is excluded from the freeze, and also that the frozen program should not try to load the module from sys.path when it is imported. Importing the specified module will always trigger an ImportError. This is useful if a module used by a frozen program can optionally use a submodule... try: import optional_submodule except ImportError: pass It may be preferable for the frozen program's behaviour to not depend on whether optional_submodule happens to be installed on the host system, and that the 'import optional_submodule' should always fail with an ImportError. This can be achieved using the '- X optional_submodule' command line switch to freeze.py This is implemented by including the excluded module in the frozen imports table (_PyImport_FrozenModules), with the code pointer set to NULL. ---------------------------------------------------------------------- >Comment By: Toby Dickenson (htrd) Date: 2001-10-03 03:37 Message: Logged In: YES user_id=46460 Once again, including the patch this time. ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-10-03 03:34 Message: Logged In: YES user_id=46460 Attached is an updated patch against the current CVS. I have verified each aspect of this patch with Py_VerboseFlag set to 2, so that import.c traces out which files it is checking during the import process. (Im not aware of an easy way to set Py_VerboseFlag to 2 in a frozen program.... Ive added a new patch #467455 to enhance the PYTHONVERBOSE environment variable to support this) I can confirm that the current CVS (rougly 2.2a4) still demonstrates the problem from bug #404545. The details are slightly different to my original bug report; Im not sure if this is due to an incidental change in python since 1.5.2, or if I messed up that bug report. Anyway, using PyVerbose=2 clearly shows that before this patch it is looking for files it shouldnt (and it uses those files if they exist). After this patch, it definitely only looks for the right files. The other aspect of this patch, adding -E and -X to freeze.py, is exactly as before. ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-09-10 07:20 Message: Logged In: YES user_id=46460 OK, I should get round to this soon. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 08:50 Message: Logged In: YES user_id=6380 I'm willing to look at this, but right now the patch doesn't apply cleanly. From the headers in the diff file it looks like you're patching an early beta for 2.0. If you can rework this for current CVS or Python 2.2a2 or 2.2a3, that would be great. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-06-07 15:26 Message: Logged In: YES user_id=21627 Why is this assigned to Mark? I cannot see anything windows-specific in it. Mark, if you are not interested in reviewing this patch, I recommend to unassign this from yourself. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416704&group_id=5470 From noreply@sourceforge.net Wed Oct 3 11:39:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Oct 2001 03:39:28 -0700 Subject: [Patches] [ python-Patches-416704 ] More robust freeze Message-ID: Patches item #416704, was opened at 2001-04-17 07:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416704&group_id=5470 Category: None Group: None Status: Open Resolution: Out of Date Priority: 5 Submitted By: Toby Dickenson (htrd) Assigned to: Guido van Rossum (gvanrossum) Summary: More robust freeze Initial Comment: This patch addresses three issues, all relating to robustness of frozen programs. Specifically, this patch allows explicit and complete control over which modules may be loaded from source on the filesystem of the host system where the frozen program is run, and which may not. Without this patch it is impossible to create a non- trivial frozen program which will *never* load a module from source on the filesystem. 1. A patch to correct bug #404545 (frozen package import uses wrong files). Under this change, submodules of a frozen package must themselves be frozen modules. Previously, the import machinery may also try to import submodules from curiously named files (packagename.modulename.py) from directories in sys.path 2. A patch to add an extra command line option -E to freeze.py, which forces freeze to terminate with an error message if there are modules that it can not locate. If this switch is not specified then the default behaviour is unchanged: modules which can not be found by freeze will not be included in the frozen program, and the import machinery will try to load them from source on sys.path when the frozen program is run. In practice we have found that a missing module is probably an error (and it is a fairly frequent error too!). The -E switch can be used to detect this error; any missing modules will cause freeze.py to fail. In the rare case of a frozen module importing a non- frozen one (ie one which should be loaded from source when the program is run), the non-frozen module must be excluded from the freeze using the -x option. 3. A patch to add an extra command line option -X to freeze.py, which indicates that a specified module is excluded from the freeze, and also that the frozen program should not try to load the module from sys.path when it is imported. Importing the specified module will always trigger an ImportError. This is useful if a module used by a frozen program can optionally use a submodule... try: import optional_submodule except ImportError: pass It may be preferable for the frozen program's behaviour to not depend on whether optional_submodule happens to be installed on the host system, and that the 'import optional_submodule' should always fail with an ImportError. This can be achieved using the '- X optional_submodule' command line switch to freeze.py This is implemented by including the excluded module in the frozen imports table (_PyImport_FrozenModules), with the code pointer set to NULL. ---------------------------------------------------------------------- >Comment By: Toby Dickenson (htrd) Date: 2001-10-03 03:39 Message: Logged In: YES user_id=46460 Still no patch there. Maybe this time? ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-10-03 03:37 Message: Logged In: YES user_id=46460 Once again, including the patch this time. ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-10-03 03:34 Message: Logged In: YES user_id=46460 Attached is an updated patch against the current CVS. I have verified each aspect of this patch with Py_VerboseFlag set to 2, so that import.c traces out which files it is checking during the import process. (Im not aware of an easy way to set Py_VerboseFlag to 2 in a frozen program.... Ive added a new patch #467455 to enhance the PYTHONVERBOSE environment variable to support this) I can confirm that the current CVS (rougly 2.2a4) still demonstrates the problem from bug #404545. The details are slightly different to my original bug report; Im not sure if this is due to an incidental change in python since 1.5.2, or if I messed up that bug report. Anyway, using PyVerbose=2 clearly shows that before this patch it is looking for files it shouldnt (and it uses those files if they exist). After this patch, it definitely only looks for the right files. The other aspect of this patch, adding -E and -X to freeze.py, is exactly as before. ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-09-10 07:20 Message: Logged In: YES user_id=46460 OK, I should get round to this soon. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 08:50 Message: Logged In: YES user_id=6380 I'm willing to look at this, but right now the patch doesn't apply cleanly. From the headers in the diff file it looks like you're patching an early beta for 2.0. If you can rework this for current CVS or Python 2.2a2 or 2.2a3, that would be great. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-06-07 15:26 Message: Logged In: YES user_id=21627 Why is this assigned to Mark? I cannot see anything windows-specific in it. Mark, if you are not interested in reviewing this patch, I recommend to unassign this from yourself. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416704&group_id=5470 From noreply@sourceforge.net Wed Oct 3 12:55:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Oct 2001 04:55:24 -0700 Subject: [Patches] [ python-Patches-466451 ] popen fix for multiple quoted arguments Message-ID: Patches item #466451, was opened at 2001-09-29 17:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466451&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Mark Hammond (mhammond) Summary: popen fix for multiple quoted arguments Initial Comment: In a Windows version of Python, try the following: os.popen('".read() cmd.exe will misinterpret the command string because it strips the first and last quote in the command string (cmd.exe /? for details). This patch does a few things: 1. it encloses the command string sent to cmd.exe in quotes and uses the /S switch 2. if the shell is not command.com or cmd.exe, it passes the -c switch to the shell (this makes popen work if the user's shell is bash, sh, etc.) 3. changes the variables s1, s2 and s3 to cmdPath, completeCmd and cmdArgs ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-03 04:55 Message: Logged In: YES user_id=6380 +1 ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-02 22:48 Message: Logged In: YES user_id=108973 How about this as an alternate implementation: if we are running on a Windows version that should have cmd.exe, we just execute that and ignore COMSPEC? Notice how popen on UNIX runs sh, not your prefered shell. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-01 19:51 Message: Logged In: YES user_id=108973 Sorry, I was sloppy about my point (I missed the -c switch). Here is dump from my UNIX box: [93:~] brian% sh -c "ls" "/usr" Desktop Documents Movies Pictures Sites bash-2.05 Dev Library Music Public Wolf MP Test setiathome [93:~] brian% sh -c ""ls" "/usr"" bin lib local share include libexec sbin standalone [93:~] brian% python [...] >>> import os >>> os.popen("ls /usr").read() 'bin\ninclude\nlib\nlibexec\nlocal\nsbin\nshare\nstandalone\ n' You will notice that the results from Python are inline with the quoted invocation of sh -c. And "man popen" on my box says that "This command is passed to /bin/sh using the - c flag;..." so presumably popen is quoting the arguments (Windows _popen doesn't though, I checked). And I didn't change the COMMAND.COM behavior - I think that it is a special case that is too broken to fix and will, with any luck, will die soon. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-01 19:12 Message: Logged In: YES user_id=31435 Special-casing bash instead (+ other shells known to need it) to use -c would be fine. I *expect* os.system and os.popen to work differently across platforms, because both depend crucially on the platform shell spawned to crack the cmdline. Tcl's "exec" (which I mentioned before) has the only good solution to this I'm aware of, via getting the platform shells out of the equation entirely (even on Unix). Python does nothing of the sort, and the more undocumented tricks are stuffed into it, the more baffling it gets when things go wrong (as they often will, and especially on Windows). I didn't understand the point to noting that bash "ls" "/usr/bin" won't work on Unix. Neither will bash ls /usr/bin The quotes are irrelevant here, yes? Python isn't adding quotes to things, or deleting them, anyway. Note that if you write your own copy.bat, command /c "copy" "whatever1" "whatever2" does work fine on Win9x (command.com). It doesn't work with the Windows copy solely because copy is a command.com builtin -- and you can't hide arbitrary platform crap like that from users either. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-01 17:43 Message: Logged In: YES user_id=108973 Tim, I don't disagree with your first point; without specific knowledge of each shell, you really have to guess what the correct shell arguments format is. There are two ways that we can work around that: 1. remove those two lines of code in my patch that do the special case 2. special case bash and sh (at least bash please) and use /C for the other cases I disagree with everything else :-) The command: bash "ls" "/usr/bin" will NOT work on UNIX. Just like typing: cmd /c "copy" "c:\..." "c:\..." won't work. So the UNIX popen implementation must be doing the moral equivalent of quoting the entire command string. So the current behavior is suprising and inconsistent accross platforms. I don't think that we can do anything with regards to backwards compatibility but I think that the cost/benifit favours fixing the problem i.e. accepting my patch :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-01 15:36 Message: Logged In: YES user_id=31435 Assigned to MarkH for further pondering. I like giving vrbls useful names The rest seems highly dubious: + Catering to non-MS shells ("-c" vs "/C") is a fine idea, but what about 4DOS or 4NT, or other non-MS shells that also expect /C? It looks like this patch will kill people using them. - It's not backwards compatible regardless of shell (as Brian pointed out). - It's surprising to anyone who has read the cmd docs and expects cmd.exe to work as documented (by MS). - Since it's unique to Python's popen, a command string that works for popen() may break if passed to os.system() instead, and vice versa, and maybe for os.startfile() too. Other things bug me, but I'll stop there . The MS shells are a godawful mess, and it would really be nice to supply a rational x-platform "virtual shell" syntax (as Tcl does for its "exec" cmd). Short of that, I'm not sure a collection of inconsistent and undocumented hacks is actually progress; as is, Python's behavior is at least predictable from reading the MS docs and/or playing with C programs under MSVC. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-30 13:11 Message: Logged In: YES user_id=108973 Mark understands the issue; I've already talked to him about this. Another thing that I should have noted is that this patch does NOT ensure backwards compatibility. Any scripts that manually quote their command strings, to work around this problem, will break. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-30 11:46 Message: Logged In: YES user_id=6380 Tim, whaddayathink? Or is this for Mark? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466451&group_id=5470 From noreply@sourceforge.net Wed Oct 3 14:51:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Oct 2001 06:51:23 -0700 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: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) 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: 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 Wed Oct 3 14:55:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Oct 2001 06:55:40 -0700 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: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) 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: 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 Wed Oct 3 19:18:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Oct 2001 11:18:02 -0700 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: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Barry Warsaw (bwarsaw) 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: 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 Wed Oct 3 19:26:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Oct 2001 11:26:58 -0700 Subject: [Patches] [ python-Patches-467580 ] ConfigParser.getboolean(): FALSE, TRUE. Message-ID: Patches item #467580, was opened at 2001-10-03 11:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467580&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: ConfigParser.getboolean(): FALSE, TRUE. Initial Comment: This patch allows ConfigParser.getboolean() to interpret TRUE, FALSE, YES, NO, ON and OFF insteaf just '0' and '1'. While just allowing '0' and '1' sounds more correct users ofetn demand to use more descriptive directives in configuration files. Instead of forcing every programmer do brew his own solution a system should include the batteries for this. http://c0re.jp/c0de/misc/ConfigParser-bool.patch This little patch allows Pythons ConfigParser.getboolean() to interpret TRUE, FALSE, YES, NO, ON and OFF insteaf just '0' and '1'. --drt@un.bewaff.net - http://c0re.jp/ --- ConfigParser.py Wed Oct 3 16:31:43 2001 +++ ConfigParser.py Wed Oct 3 16:33:18 2001 @@ -69,8 +69,9 @@ like get(), but convert value to a float getboolean(section, options) - like get(), but convert value to a boolean (currently defined as 0 or - 1, only) + like get(), but convert value to a boolean (currently case insensitive + defined as 0, FALSE, NO or OFF for 0 or 1, TRUE, YES, ON for 1). + Returns an int. remove_section(section) remove the given file section and all its options @@ -314,11 +315,12 @@ return self.__get(section, string.atof, option) def getboolean(self, section, option): - v = self.get(section, option) - val = int(v) - if val not in (0, 1): + states = {'1': 1, 'YES': 1, 'TRUE': 1, 'ON': 1, + '0': 0, 'NO': 0, 'FALSE': 0, 'OFF': 0} + v = self.get(section, option) + if not states.has_key(v.upper()): raise ValueError, 'Not a boolean: %s' % v - return val + return states[v.upper()] def optionxform(self, optionstr): return optionstr.lower() ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467580&group_id=5470 From noreply@sourceforge.net Wed Oct 3 22:58:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Oct 2001 14:58:50 -0700 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. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467650&group_id=5470 From noreply@sourceforge.net Thu Oct 4 20:59:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Oct 2001 12:59:35 -0700 Subject: [Patches] [ python-Patches-467580 ] ConfigParser.getboolean(): FALSE, TRUE. Message-ID: Patches item #467580, was opened at 2001-10-03 11:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467580&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Guido van Rossum (gvanrossum) >Summary: ConfigParser.getboolean(): FALSE, TRUE. Initial Comment: This patch allows ConfigParser.getboolean() to interpret TRUE, FALSE, YES, NO, ON and OFF insteaf just '0' and '1'. While just allowing '0' and '1' sounds more correct users ofetn demand to use more descriptive directives in configuration files. Instead of forcing every programmer do brew his own solution a system should include the batteries for this. http://c0re.jp/c0de/misc/ConfigParser-bool.patch This little patch allows Pythons ConfigParser.getboolean() to interpret TRUE, FALSE, YES, NO, ON and OFF insteaf just '0' and '1'. --drt@un.bewaff.net - http://c0re.jp/ --- ConfigParser.py Wed Oct 3 16:31:43 2001 +++ ConfigParser.py Wed Oct 3 16:33:18 2001 @@ -69,8 +69,9 @@ like get(), but convert value to a float getboolean(section, options) - like get(), but convert value to a boolean (currently defined as 0 or - 1, only) + like get(), but convert value to a boolean (currently case insensitive + defined as 0, FALSE, NO or OFF for 0 or 1, TRUE, YES, ON for 1). + Returns an int. remove_section(section) remove the given file section and all its options @@ -314,11 +315,12 @@ return self.__get(section, string.atof, option) def getboolean(self, section, option): - v = self.get(section, option) - val = int(v) - if val not in (0, 1): + states = {'1': 1, 'YES': 1, 'TRUE': 1, 'ON': 1, + '0': 0, 'NO': 0, 'FALSE': 0, 'OFF': 0} + v = self.get(section, option) + if not states.has_key(v.upper()): raise ValueError, 'Not a boolean: %s' % v - return val + return states[v.upper()] def optionxform(self, optionstr): return optionstr.lower() ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-04 12:59 Message: Logged In: YES user_id=6380 Nice. Applied to CVS. Would you mind giving your name so we can update the Misc/ACKS file? Also, would you mind providing updates to the docs and to the test suite? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467580&group_id=5470 From noreply@sourceforge.net Thu Oct 4 22:39:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Oct 2001 14:39:43 -0700 Subject: [Patches] [ python-Patches-460737 ] Some mac modules should go Message-ID: Patches item #460737, was opened at 2001-09-11 13:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460737&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Some mac modules should go Initial Comment: Some of the Macintosh modules are so outdated that they should probably not even be listen in the depraceted section but be removed altogether: libmactcp libmacdnr libmacconsole I'll leave removing them to you, I have no idea whether more needs to be done than taking them out of mac.tex and removing them. I'll check in some other fixes directly. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-10-04 14:39 Message: Logged In: YES user_id=45365 They're long long long dead. They've been included in the "unsupported" section of source distributions but they weren't part of MacPython builds for the last couple of years, so listing them as depracated would only confuse things, I guess. Just remove them. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-09-28 12:16 Message: Logged In: YES user_id=3066 Are these really no longer used? (Including by third-party code?) I'd rather add deprecation warnings to these if you plan to eventually remove them. Assign back to me with response. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460737&group_id=5470 From noreply@sourceforge.net Fri Oct 5 05:37:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Oct 2001 21:37:50 -0700 Subject: [Patches] [ python-Patches-468169 ] fix for bug #448951 (re group handling) Message-ID: Patches item #468169, was opened at 2001-10-04 21:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468169&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Nobody/Anonymous (nobody) Summary: fix for bug #448951 (re group handling) Initial Comment: Well, it seems I can't add files to bugs I didn't post, so here is the patch for bug #448951. It passes all existing re tests and adds new ones to test this bug (and related possibilities). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468169&group_id=5470 From noreply@sourceforge.net Fri Oct 5 08:53:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Oct 2001 00:53:56 -0700 Subject: [Patches] [ python-Patches-466451 ] popen fix for multiple quoted arguments Message-ID: Patches item #466451, was opened at 2001-09-29 17:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466451&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Mark Hammond (mhammond) Summary: popen fix for multiple quoted arguments Initial Comment: In a Windows version of Python, try the following: os.popen('".read() cmd.exe will misinterpret the command string because it strips the first and last quote in the command string (cmd.exe /? for details). This patch does a few things: 1. it encloses the command string sent to cmd.exe in quotes and uses the /S switch 2. if the shell is not command.com or cmd.exe, it passes the -c switch to the shell (this makes popen work if the user's shell is bash, sh, etc.) 3. changes the variables s1, s2 and s3 to cmdPath, completeCmd and cmdArgs ---------------------------------------------------------------------- >Comment By: Brian Quinlan (bquinlan) Date: 2001-10-05 00:53 Message: Logged In: YES user_id=108973 OK, here is a version of popen for Windows that always uses cmd.exe on WinNT and always uses COMMAND.COM on Win9x. I have tested the W9x code path on my W2K box but not on a real W9x box. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-03 04:55 Message: Logged In: YES user_id=6380 +1 ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-02 22:48 Message: Logged In: YES user_id=108973 How about this as an alternate implementation: if we are running on a Windows version that should have cmd.exe, we just execute that and ignore COMSPEC? Notice how popen on UNIX runs sh, not your prefered shell. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-01 19:51 Message: Logged In: YES user_id=108973 Sorry, I was sloppy about my point (I missed the -c switch). Here is dump from my UNIX box: [93:~] brian% sh -c "ls" "/usr" Desktop Documents Movies Pictures Sites bash-2.05 Dev Library Music Public Wolf MP Test setiathome [93:~] brian% sh -c ""ls" "/usr"" bin lib local share include libexec sbin standalone [93:~] brian% python [...] >>> import os >>> os.popen("ls /usr").read() 'bin\ninclude\nlib\nlibexec\nlocal\nsbin\nshare\nstandalone\ n' You will notice that the results from Python are inline with the quoted invocation of sh -c. And "man popen" on my box says that "This command is passed to /bin/sh using the - c flag;..." so presumably popen is quoting the arguments (Windows _popen doesn't though, I checked). And I didn't change the COMMAND.COM behavior - I think that it is a special case that is too broken to fix and will, with any luck, will die soon. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-01 19:12 Message: Logged In: YES user_id=31435 Special-casing bash instead (+ other shells known to need it) to use -c would be fine. I *expect* os.system and os.popen to work differently across platforms, because both depend crucially on the platform shell spawned to crack the cmdline. Tcl's "exec" (which I mentioned before) has the only good solution to this I'm aware of, via getting the platform shells out of the equation entirely (even on Unix). Python does nothing of the sort, and the more undocumented tricks are stuffed into it, the more baffling it gets when things go wrong (as they often will, and especially on Windows). I didn't understand the point to noting that bash "ls" "/usr/bin" won't work on Unix. Neither will bash ls /usr/bin The quotes are irrelevant here, yes? Python isn't adding quotes to things, or deleting them, anyway. Note that if you write your own copy.bat, command /c "copy" "whatever1" "whatever2" does work fine on Win9x (command.com). It doesn't work with the Windows copy solely because copy is a command.com builtin -- and you can't hide arbitrary platform crap like that from users either. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-01 17:43 Message: Logged In: YES user_id=108973 Tim, I don't disagree with your first point; without specific knowledge of each shell, you really have to guess what the correct shell arguments format is. There are two ways that we can work around that: 1. remove those two lines of code in my patch that do the special case 2. special case bash and sh (at least bash please) and use /C for the other cases I disagree with everything else :-) The command: bash "ls" "/usr/bin" will NOT work on UNIX. Just like typing: cmd /c "copy" "c:\..." "c:\..." won't work. So the UNIX popen implementation must be doing the moral equivalent of quoting the entire command string. So the current behavior is suprising and inconsistent accross platforms. I don't think that we can do anything with regards to backwards compatibility but I think that the cost/benifit favours fixing the problem i.e. accepting my patch :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-01 15:36 Message: Logged In: YES user_id=31435 Assigned to MarkH for further pondering. I like giving vrbls useful names The rest seems highly dubious: + Catering to non-MS shells ("-c" vs "/C") is a fine idea, but what about 4DOS or 4NT, or other non-MS shells that also expect /C? It looks like this patch will kill people using them. - It's not backwards compatible regardless of shell (as Brian pointed out). - It's surprising to anyone who has read the cmd docs and expects cmd.exe to work as documented (by MS). - Since it's unique to Python's popen, a command string that works for popen() may break if passed to os.system() instead, and vice versa, and maybe for os.startfile() too. Other things bug me, but I'll stop there . The MS shells are a godawful mess, and it would really be nice to supply a rational x-platform "virtual shell" syntax (as Tcl does for its "exec" cmd). Short of that, I'm not sure a collection of inconsistent and undocumented hacks is actually progress; as is, Python's behavior is at least predictable from reading the MS docs and/or playing with C programs under MSVC. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-30 13:11 Message: Logged In: YES user_id=108973 Mark understands the issue; I've already talked to him about this. Another thing that I should have noted is that this patch does NOT ensure backwards compatibility. Any scripts that manually quote their command strings, to work around this problem, will break. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-30 11:46 Message: Logged In: YES user_id=6380 Tim, whaddayathink? Or is this for Mark? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466451&group_id=5470 From noreply@sourceforge.net Fri Oct 5 13:23:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Oct 2001 05:23:04 -0700 Subject: [Patches] [ python-Patches-468169 ] fix for bug #448951 (re group handling) Message-ID: Patches item #468169, was opened at 2001-10-04 21:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468169&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) >Assigned to: Fredrik Lundh (effbot) Summary: fix for bug #448951 (re group handling) Initial Comment: Well, it seems I can't add files to bugs I didn't post, so here is the patch for bug #448951. It passes all existing re tests and adds new ones to test this bug (and related possibilities). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468169&group_id=5470 From noreply@sourceforge.net Fri Oct 5 14:07:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Oct 2001 06:07:49 -0700 Subject: [Patches] [ python-Patches-466451 ] popen fix for multiple quoted arguments Message-ID: Patches item #466451, was opened at 2001-09-29 17:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466451&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) >Assigned to: Tim Peters (tim_one) Summary: popen fix for multiple quoted arguments Initial Comment: In a Windows version of Python, try the following: os.popen('".read() cmd.exe will misinterpret the command string because it strips the first and last quote in the command string (cmd.exe /? for details). This patch does a few things: 1. it encloses the command string sent to cmd.exe in quotes and uses the /S switch 2. if the shell is not command.com or cmd.exe, it passes the -c switch to the shell (this makes popen work if the user's shell is bash, sh, etc.) 3. changes the variables s1, s2 and s3 to cmdPath, completeCmd and cmdArgs ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-05 00:53 Message: Logged In: YES user_id=108973 OK, here is a version of popen for Windows that always uses cmd.exe on WinNT and always uses COMMAND.COM on Win9x. I have tested the W9x code path on my W2K box but not on a real W9x box. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-03 04:55 Message: Logged In: YES user_id=6380 +1 ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-02 22:48 Message: Logged In: YES user_id=108973 How about this as an alternate implementation: if we are running on a Windows version that should have cmd.exe, we just execute that and ignore COMSPEC? Notice how popen on UNIX runs sh, not your prefered shell. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-01 19:51 Message: Logged In: YES user_id=108973 Sorry, I was sloppy about my point (I missed the -c switch). Here is dump from my UNIX box: [93:~] brian% sh -c "ls" "/usr" Desktop Documents Movies Pictures Sites bash-2.05 Dev Library Music Public Wolf MP Test setiathome [93:~] brian% sh -c ""ls" "/usr"" bin lib local share include libexec sbin standalone [93:~] brian% python [...] >>> import os >>> os.popen("ls /usr").read() 'bin\ninclude\nlib\nlibexec\nlocal\nsbin\nshare\nstandalone\ n' You will notice that the results from Python are inline with the quoted invocation of sh -c. And "man popen" on my box says that "This command is passed to /bin/sh using the - c flag;..." so presumably popen is quoting the arguments (Windows _popen doesn't though, I checked). And I didn't change the COMMAND.COM behavior - I think that it is a special case that is too broken to fix and will, with any luck, will die soon. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-01 19:12 Message: Logged In: YES user_id=31435 Special-casing bash instead (+ other shells known to need it) to use -c would be fine. I *expect* os.system and os.popen to work differently across platforms, because both depend crucially on the platform shell spawned to crack the cmdline. Tcl's "exec" (which I mentioned before) has the only good solution to this I'm aware of, via getting the platform shells out of the equation entirely (even on Unix). Python does nothing of the sort, and the more undocumented tricks are stuffed into it, the more baffling it gets when things go wrong (as they often will, and especially on Windows). I didn't understand the point to noting that bash "ls" "/usr/bin" won't work on Unix. Neither will bash ls /usr/bin The quotes are irrelevant here, yes? Python isn't adding quotes to things, or deleting them, anyway. Note that if you write your own copy.bat, command /c "copy" "whatever1" "whatever2" does work fine on Win9x (command.com). It doesn't work with the Windows copy solely because copy is a command.com builtin -- and you can't hide arbitrary platform crap like that from users either. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-01 17:43 Message: Logged In: YES user_id=108973 Tim, I don't disagree with your first point; without specific knowledge of each shell, you really have to guess what the correct shell arguments format is. There are two ways that we can work around that: 1. remove those two lines of code in my patch that do the special case 2. special case bash and sh (at least bash please) and use /C for the other cases I disagree with everything else :-) The command: bash "ls" "/usr/bin" will NOT work on UNIX. Just like typing: cmd /c "copy" "c:\..." "c:\..." won't work. So the UNIX popen implementation must be doing the moral equivalent of quoting the entire command string. So the current behavior is suprising and inconsistent accross platforms. I don't think that we can do anything with regards to backwards compatibility but I think that the cost/benifit favours fixing the problem i.e. accepting my patch :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-01 15:36 Message: Logged In: YES user_id=31435 Assigned to MarkH for further pondering. I like giving vrbls useful names The rest seems highly dubious: + Catering to non-MS shells ("-c" vs "/C") is a fine idea, but what about 4DOS or 4NT, or other non-MS shells that also expect /C? It looks like this patch will kill people using them. - It's not backwards compatible regardless of shell (as Brian pointed out). - It's surprising to anyone who has read the cmd docs and expects cmd.exe to work as documented (by MS). - Since it's unique to Python's popen, a command string that works for popen() may break if passed to os.system() instead, and vice versa, and maybe for os.startfile() too. Other things bug me, but I'll stop there . The MS shells are a godawful mess, and it would really be nice to supply a rational x-platform "virtual shell" syntax (as Tcl does for its "exec" cmd). Short of that, I'm not sure a collection of inconsistent and undocumented hacks is actually progress; as is, Python's behavior is at least predictable from reading the MS docs and/or playing with C programs under MSVC. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-30 13:11 Message: Logged In: YES user_id=108973 Mark understands the issue; I've already talked to him about this. Another thing that I should have noted is that this patch does NOT ensure backwards compatibility. Any scripts that manually quote their command strings, to work around this problem, will break. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-30 11:46 Message: Logged In: YES user_id=6380 Tim, whaddayathink? Or is this for Mark? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466451&group_id=5470 From noreply@sourceforge.net Fri Oct 5 14:40:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Oct 2001 06:40:56 -0700 Subject: [Patches] [ python-Patches-467580 ] ConfigParser.getboolean(): FALSE, TRUE. Message-ID: Patches item #467580, was opened at 2001-10-03 11:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467580&group_id=5470 Category: Library (Lib) Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: ConfigParser.getboolean(): FALSE, TRUE. Initial Comment: This patch allows ConfigParser.getboolean() to interpret TRUE, FALSE, YES, NO, ON and OFF insteaf just '0' and '1'. While just allowing '0' and '1' sounds more correct users ofetn demand to use more descriptive directives in configuration files. Instead of forcing every programmer do brew his own solution a system should include the batteries for this. http://c0re.jp/c0de/misc/ConfigParser-bool.patch This little patch allows Pythons ConfigParser.getboolean() to interpret TRUE, FALSE, YES, NO, ON and OFF insteaf just '0' and '1'. --drt@un.bewaff.net - http://c0re.jp/ --- ConfigParser.py Wed Oct 3 16:31:43 2001 +++ ConfigParser.py Wed Oct 3 16:33:18 2001 @@ -69,8 +69,9 @@ like get(), but convert value to a float getboolean(section, options) - like get(), but convert value to a boolean (currently defined as 0 or - 1, only) + like get(), but convert value to a boolean (currently case insensitive + defined as 0, FALSE, NO or OFF for 0 or 1, TRUE, YES, ON for 1). + Returns an int. remove_section(section) remove the given file section and all its options @@ -314,11 +315,12 @@ return self.__get(section, string.atof, option) def getboolean(self, section, option): - v = self.get(section, option) - val = int(v) - if val not in (0, 1): + states = {'1': 1, 'YES': 1, 'TRUE': 1, 'ON': 1, + '0': 0, 'NO': 0, 'FALSE': 0, 'OFF': 0} + v = self.get(section, option) + if not states.has_key(v.upper()): raise ValueError, 'Not a boolean: %s' % v - return val + return states[v.upper()] def optionxform(self, optionstr): return optionstr.lower() ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-10-05 06:40 Message: Logged In: NO Name: Doobee R. Tzeck Docs/Tests: will follow shortly. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-04 12:59 Message: Logged In: YES user_id=6380 Nice. Applied to CVS. Would you mind giving your name so we can update the Misc/ACKS file? Also, would you mind providing updates to the docs and to the test suite? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467580&group_id=5470 From noreply@sourceforge.net Fri Oct 5 17:47:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Oct 2001 09:47:34 -0700 Subject: [Patches] [ python-Patches-460737 ] Some mac modules should go Message-ID: Patches item #460737, was opened at 2001-09-11 13:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460737&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Some mac modules should go Initial Comment: Some of the Macintosh modules are so outdated that they should probably not even be listen in the depraceted section but be removed altogether: libmactcp libmacdnr libmacconsole I'll leave removing them to you, I have no idea whether more needs to be done than taking them out of mac.tex and removing them. I'll check in some other fixes directly. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-05 09:47 Message: Logged In: YES user_id=3066 Changes made in Doc/mac/mac.tex revision 1.9; removed Doc/mac/libmacconsole.tex, Doc/mac/libmacdnr.tex, and Doc/mac/libmactcp.tec. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-10-04 14:39 Message: Logged In: YES user_id=45365 They're long long long dead. They've been included in the "unsupported" section of source distributions but they weren't part of MacPython builds for the last couple of years, so listing them as depracated would only confuse things, I guess. Just remove them. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-09-28 12:16 Message: Logged In: YES user_id=3066 Are these really no longer used? (Including by third-party code?) I'd rather add deprecation warnings to these if you plan to eventually remove them. Assign back to me with response. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460737&group_id=5470 From noreply@sourceforge.net Fri Oct 5 17:58:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Oct 2001 09:58:49 -0700 Subject: [Patches] [ python-Patches-468347 ] mask signals for non-main pthreads Message-ID: Patches item #468347, was opened at 2001-10-05 09:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468347&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Lowe (jasonlowe) Assigned to: Nobody/Anonymous (nobody) Summary: mask signals for non-main pthreads Initial Comment: This patch updates Python/thread_pthread.h to mask all signals for any thread created. This will keep all signals masked for any thread that isn't the initial thread. For Solaris and Linux, the two platforms I was able to test it on, it solves bug #465673 (pthreads need signal protection) and probably will solve bug #219772 (Interactive InterPreter+ Thread -> core dump at exit). I'd be great if this could get some testing on other platforms, especially HP-UX pre 11.00 and post 11.00, as I had to make some guesses for the DCE thread case. AIX is also a concern as I saw some mention of using sigthreadmask() as a pthread_sigmask() equivalent, but this patch doesn't use sigthreadmask(). I don't have access to AIX. Note that thread_pthread.h.orig in this patch is the unmodified version from the Python2.1 release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468347&group_id=5470 From noreply@sourceforge.net Fri Oct 5 19:40:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Oct 2001 11:40:05 -0700 Subject: [Patches] [ python-Patches-466451 ] popen fix for multiple quoted arguments Message-ID: Patches item #466451, was opened at 2001-09-29 17:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466451&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) >Assigned to: Mark Hammond (mhammond) Summary: popen fix for multiple quoted arguments Initial Comment: In a Windows version of Python, try the following: os.popen('".read() cmd.exe will misinterpret the command string because it strips the first and last quote in the command string (cmd.exe /? for details). This patch does a few things: 1. it encloses the command string sent to cmd.exe in quotes and uses the /S switch 2. if the shell is not command.com or cmd.exe, it passes the -c switch to the shell (this makes popen work if the user's shell is bash, sh, etc.) 3. changes the variables s1, s2 and s3 to cmdPath, completeCmd and cmdArgs ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-10-05 11:40 Message: Logged In: YES user_id=31435 Back to Mark -- still want his take on this. My take: Guido also seems attracted to the Unixish purity of insisting on a specific shell, but because the MS shells suck I am not. People pay good money to get replacement shells (line 4NT) on Windows, and we're going to break their Python code if we don't respect COMSPEC, as MS system () and _popen() respect it (and as Python *has* respected it so far). The difference between Unix and Windows is that /bin/sh is adequate to all tasks, just a little feature-starved compared to some of the alternatives. But the std Windows shells are inadequate, and MS goes out of its way to let users plug in alternatives. In the absence of Python supplying its own adequate shell (as Tcl does), so it goes. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-05 00:53 Message: Logged In: YES user_id=108973 OK, here is a version of popen for Windows that always uses cmd.exe on WinNT and always uses COMMAND.COM on Win9x. I have tested the W9x code path on my W2K box but not on a real W9x box. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-03 04:55 Message: Logged In: YES user_id=6380 +1 ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-02 22:48 Message: Logged In: YES user_id=108973 How about this as an alternate implementation: if we are running on a Windows version that should have cmd.exe, we just execute that and ignore COMSPEC? Notice how popen on UNIX runs sh, not your prefered shell. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-01 19:51 Message: Logged In: YES user_id=108973 Sorry, I was sloppy about my point (I missed the -c switch). Here is dump from my UNIX box: [93:~] brian% sh -c "ls" "/usr" Desktop Documents Movies Pictures Sites bash-2.05 Dev Library Music Public Wolf MP Test setiathome [93:~] brian% sh -c ""ls" "/usr"" bin lib local share include libexec sbin standalone [93:~] brian% python [...] >>> import os >>> os.popen("ls /usr").read() 'bin\ninclude\nlib\nlibexec\nlocal\nsbin\nshare\nstandalone\ n' You will notice that the results from Python are inline with the quoted invocation of sh -c. And "man popen" on my box says that "This command is passed to /bin/sh using the - c flag;..." so presumably popen is quoting the arguments (Windows _popen doesn't though, I checked). And I didn't change the COMMAND.COM behavior - I think that it is a special case that is too broken to fix and will, with any luck, will die soon. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-01 19:12 Message: Logged In: YES user_id=31435 Special-casing bash instead (+ other shells known to need it) to use -c would be fine. I *expect* os.system and os.popen to work differently across platforms, because both depend crucially on the platform shell spawned to crack the cmdline. Tcl's "exec" (which I mentioned before) has the only good solution to this I'm aware of, via getting the platform shells out of the equation entirely (even on Unix). Python does nothing of the sort, and the more undocumented tricks are stuffed into it, the more baffling it gets when things go wrong (as they often will, and especially on Windows). I didn't understand the point to noting that bash "ls" "/usr/bin" won't work on Unix. Neither will bash ls /usr/bin The quotes are irrelevant here, yes? Python isn't adding quotes to things, or deleting them, anyway. Note that if you write your own copy.bat, command /c "copy" "whatever1" "whatever2" does work fine on Win9x (command.com). It doesn't work with the Windows copy solely because copy is a command.com builtin -- and you can't hide arbitrary platform crap like that from users either. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-01 17:43 Message: Logged In: YES user_id=108973 Tim, I don't disagree with your first point; without specific knowledge of each shell, you really have to guess what the correct shell arguments format is. There are two ways that we can work around that: 1. remove those two lines of code in my patch that do the special case 2. special case bash and sh (at least bash please) and use /C for the other cases I disagree with everything else :-) The command: bash "ls" "/usr/bin" will NOT work on UNIX. Just like typing: cmd /c "copy" "c:\..." "c:\..." won't work. So the UNIX popen implementation must be doing the moral equivalent of quoting the entire command string. So the current behavior is suprising and inconsistent accross platforms. I don't think that we can do anything with regards to backwards compatibility but I think that the cost/benifit favours fixing the problem i.e. accepting my patch :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-01 15:36 Message: Logged In: YES user_id=31435 Assigned to MarkH for further pondering. I like giving vrbls useful names The rest seems highly dubious: + Catering to non-MS shells ("-c" vs "/C") is a fine idea, but what about 4DOS or 4NT, or other non-MS shells that also expect /C? It looks like this patch will kill people using them. - It's not backwards compatible regardless of shell (as Brian pointed out). - It's surprising to anyone who has read the cmd docs and expects cmd.exe to work as documented (by MS). - Since it's unique to Python's popen, a command string that works for popen() may break if passed to os.system() instead, and vice versa, and maybe for os.startfile() too. Other things bug me, but I'll stop there . The MS shells are a godawful mess, and it would really be nice to supply a rational x-platform "virtual shell" syntax (as Tcl does for its "exec" cmd). Short of that, I'm not sure a collection of inconsistent and undocumented hacks is actually progress; as is, Python's behavior is at least predictable from reading the MS docs and/or playing with C programs under MSVC. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-09-30 13:11 Message: Logged In: YES user_id=108973 Mark understands the issue; I've already talked to him about this. Another thing that I should have noted is that this patch does NOT ensure backwards compatibility. Any scripts that manually quote their command strings, to work around this problem, will break. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-30 11:46 Message: Logged In: YES user_id=6380 Tim, whaddayathink? Or is this for Mark? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466451&group_id=5470 From _вилла_@e-mail.ru Fri Oct 5 19:28:04 2001 From: _вилла_@e-mail.ru (Villa) Date: Fri, 5 Oct 2001 22:28:04 +0400 Subject: [Patches] =?windows-1251?Q?=CF=F0=EE=E4=E0=E5=F2=F1=FF_=E2=E8=EB=EB=E0_=ED=E0_=E1=E5=F0=E5=E3=F3_=EE=EA=E5=E0=ED=E0?= Message-ID: <214022001105518284308@e-mail.ru> Продается вилла на Сейшелах в 20-ти метрах от Индийского океана. 200 кв.м. 0,15 Га. Мебель, сигнализация, прислуга. Лучший климат на Земле (круглый год темп. воздуха и воды 28°)! Московское время. Прямой безвизовый перелет Аэрофлотом. Если Вы заинтересовались этим предложением и хотите получить более подробную информацию, пошлите пустое письмо по адресу: seych@dr.com. При этом в поле "Тема" обязательно укажите: "Пришлите подробную информацию". From noreply@sourceforge.net Fri Oct 5 21:23:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Oct 2001 13:23:41 -0700 Subject: [Patches] [ python-Patches-468394 ] Allow xmlrpclib to handle long ints Message-ID: Patches item #468394, was opened at 2001-10-05 13:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468394&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Allow xmlrpclib to handle long ints Initial Comment: xmlrpclib currently raises an exception when passed a long int, even if it int(N) doesn't raise OverflowError. The attached patch adds a dump_long method to the Marshaller class. It makes no attempt to recover from an out-of-range long, letting the user catch the resulting OverflowError. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468394&group_id=5470 From noreply@sourceforge.net Fri Oct 5 21:24:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Oct 2001 13:24:49 -0700 Subject: [Patches] [ python-Patches-468394 ] Allow xmlrpclib to handle long ints Message-ID: Patches item #468394, was opened at 2001-10-05 13:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468394&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Allow xmlrpclib to handle long ints Initial Comment: xmlrpclib currently raises an exception when passed a long int, even if it int(N) doesn't raise OverflowError. The attached patch adds a dump_long method to the Marshaller class. It makes no attempt to recover from an out-of-range long, letting the user catch the resulting OverflowError. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2001-10-05 13:24 Message: Logged In: YES user_id=44345 Damn... Something seems amiss with Opera's file upload capability. It's a short patch, included here: *** /tmp/skip/xmlrpclib.py.~1.11~ Fri Oct 5 15:14:45 2001 --- /tmp/skip/xmlrpclib.py Fri Oct 5 15:14:45 2001 *************** *** 464,469 **** --- 464,474 ---- self.write("%s\n" % value) dispatch[IntType] = dump_int + def dump_long(self, value): + val = int(value) + self.write("%s\n" % val) + dispatch[LongType] = dump_long + def dump_double(self, value): self.write("%s\n" % value) dispatch[FloatType] = dump_double ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468394&group_id=5470 From noreply@sourceforge.net Fri Oct 5 23:02:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Oct 2001 15:02:40 -0700 Subject: [Patches] [ python-Patches-467580 ] ConfigParser.getboolean(): FALSE, TRUE. Message-ID: Patches item #467580, was opened at 2001-10-03 11:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467580&group_id=5470 Category: Library (Lib) Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: ConfigParser.getboolean(): FALSE, TRUE. Initial Comment: This patch allows ConfigParser.getboolean() to interpret TRUE, FALSE, YES, NO, ON and OFF insteaf just '0' and '1'. While just allowing '0' and '1' sounds more correct users ofetn demand to use more descriptive directives in configuration files. Instead of forcing every programmer do brew his own solution a system should include the batteries for this. http://c0re.jp/c0de/misc/ConfigParser-bool.patch This little patch allows Pythons ConfigParser.getboolean() to interpret TRUE, FALSE, YES, NO, ON and OFF insteaf just '0' and '1'. --drt@un.bewaff.net - http://c0re.jp/ --- ConfigParser.py Wed Oct 3 16:31:43 2001 +++ ConfigParser.py Wed Oct 3 16:33:18 2001 @@ -69,8 +69,9 @@ like get(), but convert value to a float getboolean(section, options) - like get(), but convert value to a boolean (currently defined as 0 or - 1, only) + like get(), but convert value to a boolean (currently case insensitive + defined as 0, FALSE, NO or OFF for 0 or 1, TRUE, YES, ON for 1). + Returns an int. remove_section(section) remove the given file section and all its options @@ -314,11 +315,12 @@ return self.__get(section, string.atof, option) def getboolean(self, section, option): - v = self.get(section, option) - val = int(v) - if val not in (0, 1): + states = {'1': 1, 'YES': 1, 'TRUE': 1, 'ON': 1, + '0': 0, 'NO': 0, 'FALSE': 0, 'OFF': 0} + v = self.get(section, option) + if not states.has_key(v.upper()): raise ValueError, 'Not a boolean: %s' % v - return val + return states[v.upper()] def optionxform(self, optionstr): return optionstr.lower() ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-10-05 15:02 Message: Logged In: NO The missing documentation - untested since i had no TeX at hand. http://c0re.jp/c0de/misc/ConfigParser-bool-doc.patch This patch adds Documentation to my ConfigParser-bool patch like GvR requested. See http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467580&group_id=5470 for further enlightenment. --drt@un.bewaff.net - http://c0re.jp/ ? ConfigParser-bool-doc.patch Index: Doc/lib/libcfgparser.tex =================================================================== RCS file: /cvsroot/python/python/dist/src/Doc/lib/libcfgparser.tex,v retrieving revision 1.18 diff -c -r1.18 libcfgparser.tex *** Doc/lib/libcfgparser.tex 2001/10/01 17:04:10 1.18 --- Doc/lib/libcfgparser.tex 2001/10/05 21:46:51 *************** *** 163,171 **** \begin{methoddesc}{getboolean}{section, option} A convenience method which coerces the \var{option} in the specified ! \var{section} to a Boolean value. Note that the only accepted values ! for the option are \samp{0} and \samp{1}, any others will raise ! \exception{ValueError}. \end{methoddesc} \begin{methoddesc}{set}{section, option, value} --- 163,173 ---- \begin{methoddesc}{getboolean}{section, option} A convenience method which coerces the \var{option} in the specified ! \var{section} to a Boolean value. \samp{0}, \samp{FALSE}, \samp{NO} ! and \samp{OFF} will return \samp{0} while \samp{1}, \samp{TRUE}, ! \samp{YES} and \samp{ON} will return \samp{1}, any others will raise ! \exception{ValueError}. The interpretation of the textual values is ! case insensitive. \end{methoddesc} \begin{methoddesc}{set}{section, option, value} ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-10-05 06:40 Message: Logged In: NO Name: Doobee R. Tzeck Docs/Tests: will follow shortly. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-04 12:59 Message: Logged In: YES user_id=6380 Nice. Applied to CVS. Would you mind giving your name so we can update the Misc/ACKS file? Also, would you mind providing updates to the docs and to the test suite? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467580&group_id=5470 From noreply@sourceforge.net Sat Oct 6 00:09:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Oct 2001 16:09:56 -0700 Subject: [Patches] [ python-Patches-467580 ] ConfigParser.getboolean(): FALSE, TRUE. Message-ID: Patches item #467580, was opened at 2001-10-03 11:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467580&group_id=5470 Category: Library (Lib) Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: ConfigParser.getboolean(): FALSE, TRUE. Initial Comment: This patch allows ConfigParser.getboolean() to interpret TRUE, FALSE, YES, NO, ON and OFF insteaf just '0' and '1'. While just allowing '0' and '1' sounds more correct users ofetn demand to use more descriptive directives in configuration files. Instead of forcing every programmer do brew his own solution a system should include the batteries for this. http://c0re.jp/c0de/misc/ConfigParser-bool.patch This little patch allows Pythons ConfigParser.getboolean() to interpret TRUE, FALSE, YES, NO, ON and OFF insteaf just '0' and '1'. --drt@un.bewaff.net - http://c0re.jp/ --- ConfigParser.py Wed Oct 3 16:31:43 2001 +++ ConfigParser.py Wed Oct 3 16:33:18 2001 @@ -69,8 +69,9 @@ like get(), but convert value to a float getboolean(section, options) - like get(), but convert value to a boolean (currently defined as 0 or - 1, only) + like get(), but convert value to a boolean (currently case insensitive + defined as 0, FALSE, NO or OFF for 0 or 1, TRUE, YES, ON for 1). + Returns an int. remove_section(section) remove the given file section and all its options @@ -314,11 +315,12 @@ return self.__get(section, string.atof, option) def getboolean(self, section, option): - v = self.get(section, option) - val = int(v) - if val not in (0, 1): + states = {'1': 1, 'YES': 1, 'TRUE': 1, 'ON': 1, + '0': 0, 'NO': 0, 'FALSE': 0, 'OFF': 0} + v = self.get(section, option) + if not states.has_key(v.upper()): raise ValueError, 'Not a boolean: %s' % v - return val + return states[v.upper()] def optionxform(self, optionstr): return optionstr.lower() ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-10-05 16:09 Message: Logged In: NO Is submitting here the right way or should I have opened a new patch for this? Nevertheless: http://c0re.jp/c0de/misc/ConfigParser-bool-test.patch This patch adds testing to my ConfigParser-bool patch like GvR requested. See http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467580&group_id=5470 for further enlightenment. --drt@un.bewaff.net - http://c0re.jp/ Index: Lib/test/test_cfgparser.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_cfgparser.py,v retrieving revision 1.8 diff -c -r1.8 test_cfgparser.py *** Lib/test/test_cfgparser.py 2001/07/06 17:22:48 1.8 --- Lib/test/test_cfgparser.py 2001/10/05 23:00:49 *************** *** 78,89 **** verify(cf.get("MySection", "Option") == "first line\nsecond line") def interpolation(src): print "Testing value interpolation..." cf = ConfigParser.ConfigParser({"getname": "%(__name__)s"}) sio = StringIO.StringIO(src) cf.readfp(sio) ! verify(cf.get("Foo", "getname") == "Foo") verify(cf.get("Foo", "bar") == "something with interpolation (1 step)") verify(cf.get("Foo", "bar9") == "something with lots of interpolation (9 steps)") --- 78,108 ---- verify(cf.get("MySection", "Option") == "first line\nsecond line") + def boolean(src): + print "Testing interpretation of boolean Values..." + cf = ConfigParser.ConfigParser() + sio = StringIO.StringIO(src) + cf.readfp(sio) + for x in range(1, 5): + verify(cf.getboolean('BOOLTEST', 't%d' % (x)) == 1) + for x in range(1, 5): + verify(cf.getboolean('BOOLTEST', 'f%d' % (x)) == 0) + for x in range(1, 5): + try: + cf.getboolean('BOOLTEST', 'e%d' % (x)) + except ValueError: + pass + else: + raise TestFailed( + "getboolean() failed to report a non boolean value") + + def interpolation(src): print "Testing value interpolation..." cf = ConfigParser.ConfigParser({"getname": "%(__name__)s"}) sio = StringIO.StringIO(src) cf.readfp(sio) ! verify(cf.get("Foo", "getname") == "Foo") verify(cf.get("Foo", "bar") == "something with interpolation (1 step)") verify(cf.get("Foo", "bar9") == "something with lots of interpolation (9 steps)") *************** *** 180,185 **** --- 199,222 ---- foo[de]=Deutsch """) case_sensitivity() + boolean(r""" + [BOOLTEST] + T1=1 + T2=TRUE + T3=True + T4=oN + T5=yes + F1=0 + F2=FALSE + F3=False + F4=oFF + F5=nO + E1=2 + E2=foo + E3=-1 + E4=0.1 + E5=FALSE AND MORE + """) interpolation(r""" [Foo] bar=something %(with1)s interpolation (1 step) Index: Lib/test/output/test_cfgparser =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/output/test_cfgparser,v retrieving revision 1.4 diff -c -r1.4 test_cfgparser *** Lib/test/output/test_cfgparser 2001/02/26 21:55:34 1.4 --- Lib/test/output/test_cfgparser 2001/10/05 23:00:54 *************** *** 1,6 **** --- 1,7 ---- test_cfgparser Testing basic accessors... Testing case sensitivity... + Testing interpretation of boolean Values... Testing value interpolation... Testing parse errors... Testing query interface... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-10-05 15:02 Message: Logged In: NO The missing documentation - untested since i had no TeX at hand. http://c0re.jp/c0de/misc/ConfigParser-bool-doc.patch This patch adds Documentation to my ConfigParser-bool patch like GvR requested. See http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467580&group_id=5470 for further enlightenment. --drt@un.bewaff.net - http://c0re.jp/ ? ConfigParser-bool-doc.patch Index: Doc/lib/libcfgparser.tex =================================================================== RCS file: /cvsroot/python/python/dist/src/Doc/lib/libcfgparser.tex,v retrieving revision 1.18 diff -c -r1.18 libcfgparser.tex *** Doc/lib/libcfgparser.tex 2001/10/01 17:04:10 1.18 --- Doc/lib/libcfgparser.tex 2001/10/05 21:46:51 *************** *** 163,171 **** \begin{methoddesc}{getboolean}{section, option} A convenience method which coerces the \var{option} in the specified ! \var{section} to a Boolean value. Note that the only accepted values ! for the option are \samp{0} and \samp{1}, any others will raise ! \exception{ValueError}. \end{methoddesc} \begin{methoddesc}{set}{section, option, value} --- 163,173 ---- \begin{methoddesc}{getboolean}{section, option} A convenience method which coerces the \var{option} in the specified ! \var{section} to a Boolean value. \samp{0}, \samp{FALSE}, \samp{NO} ! and \samp{OFF} will return \samp{0} while \samp{1}, \samp{TRUE}, ! \samp{YES} and \samp{ON} will return \samp{1}, any others will raise ! \exception{ValueError}. The interpretation of the textual values is ! case insensitive. \end{methoddesc} \begin{methoddesc}{set}{section, option, value} ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-10-05 06:40 Message: Logged In: NO Name: Doobee R. Tzeck Docs/Tests: will follow shortly. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-04 12:59 Message: Logged In: YES user_id=6380 Nice. Applied to CVS. Would you mind giving your name so we can update the Misc/ACKS file? Also, would you mind providing updates to the docs and to the test suite? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467580&group_id=5470 From dariob@millic.com.ar Sat Oct 6 01:19:08 2001 From: dariob@millic.com.ar (dariob@millic.com.ar) Date: Fri, 05 Oct 2001 21:19:08 -0300 Subject: [Patches] VCD Y MP3. Message-ID: <0523e39160006a1MAIL1@smtp1.millic.com.ar> This is a Multipart MIME message. ------=_NextPart_000_001__2778995_76748,43 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit ------=_NextPart_000_001__2778995_76748,43 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 PGh0bWw+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1MYW5ndWFnZSIg Y29udGVudD0iZXMiPg0KPG1ldGEgbmFtZT0iR0VORVJBVE9SIiBjb250ZW50PSJNaWNyb3Nv ZnQgRnJvbnRQYWdlIDUuMCI+DQo8bWV0YSBuYW1lPSJQcm9nSWQiIGNvbnRlbnQ9IkZyb250 UGFnZS5FZGl0b3IuRG9jdW1lbnQiPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBl IiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9d2luZG93cy0xMjUyIj4NCjx0aXRsZT5Q YWdpbmEgbnVldmEgMTwvdGl0bGU+DQo8L2hlYWQ+DQoNCjxib2R5Pg0KDQo8dGFibGUgaGVp Z2h0PSI4MSIgY2VsbFNwYWNpbmc9IjAiIGNlbGxQYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIg YmdDb2xvcj0iIzAwMDAwMCIgYm9yZGVyPSIwIj4NCiAgPGZvbnQgZmFjZT0iQXJpYWwsIEhl bHZldGljYSwgc2Fucy1zZXJpZiIgY29sb3I9IiMwMDgwZmYiIHNpemU9IjQiPjxiPg0KICA8 Y2FwdGlvbj48Zm9udCBmYWNlPSJUYWhvbWEiIGNvbG9yPSIjZmYwMDAwIiBzaXplPSI2Ij48 c3Ryb25nPqGhoaEgTk8gVEUgUE9ERVMgDQogIFBFUkRFUiBFU1RBIE9QT1JUVU5JREFEISEh ITwvc3Ryb25nPjwvZm9udD4gPHN0cm9uZz4NCiAgPGZvbnQgZmFjZT0iVGFob21hIiBjb2xv cj0iIzAwMDBmZiIgc2l6ZT0iNSI+PGZvbnQgc2l6ZT0iNSIgZmFjZT0iVGFob21hIj4NCiAg RVNDVUNIQSA8L2ZvbnQ+PC9mb250Pjwvc3Ryb25nPjxmb250IHNpemU9IisyIiBjb2xvcj0i IzAwMDBmZiIgZmFjZT0iVGFob21hIj4NCiAgTdpTSUNBIE1QMyBFTiBUVSBBVVRPLCBDQVNB LCBDQU1JTkFORE8gTyBFTiBET05ERSBQUkVGSUVSQVMsPC9mb250PjxzdHJvbmc+PGZvbnQg ZmFjZT0iVGFob21hIiBjb2xvcj0iIzAwMDBmZiIgc2l6ZT0iNSI+PGZvbnQgc2l6ZT0iNSIg ZmFjZT0iVGFob21hIj4NCiAgWSBNSVJBIExBUyBNRUpPUkVTIDwvZm9udD48Zm9udCBzaXpl PSI1IiBmYWNlPSJUYWhvbWEiPg0KICBQRUzNQ1VMQVMgRU4gRUwgVFYgREUgVFUgQ0FTQS48 L2ZvbnQ+PC9mb250Pjwvc3Ryb25nPg0KICA8Zm9udCBmYWNlPSJUYWhvbWEiIGNvbG9yPSIj MDAwMGZmIiBzaXplPSI1Ij48c3Ryb25nPjx1PlPaUEVSIE9GRVJUQSBFTiBMQSANCiAgUFVF UlRBIERFIFRVIENBU0E8L3U+PC9zdHJvbmc+PC9mb250PjwvYj48L2ZvbnQ+DQogIDxwIGFs aWduPSJjZW50ZXIiPg0KICA8Zm9udCBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNl cmlmIiBjb2xvcj0iIzAwODBmZiIgc2l6ZT0iNCI+PGI+TG8gTWVqb3IgDQogIGRlbCBNZXJj YWRvIGEgUHJlY2lvIGRlIExPQ09TPC9iPjwvZm9udD48L3A+DQogIDwvY2FwdGlvbj4NCiAg PHRyPg0KICAgIDx0ZCBoZWlnaHQ9IjgxIj4NCiAgICA8dGFibGUgY2VsbFNwYWNpbmc9IjAi IGNlbGxQYWRkaW5nPSI2IiB3aWR0aD0iMTAwJSIgYm9yZGVyPSIwIiBoZWlnaHQ9IjcxIj4N CiAgICAgIDx0cj4NCiAgICAgICAgPHRkIHdpZHRoPSI1MyUiIGhlaWdodD0iNTkiPg0KICAg ICAgICA8dGFibGUgY2VsbFNwYWNpbmc9IjAiIGNlbGxQYWRkaW5nPSIzIiB3aWR0aD0iMTAw JSIgYmdDb2xvcj0iIzAwODAwMCIgYm9yZGVyPSIwIj4NCiAgICAgICAgICA8dHI+DQogICAg ICAgICAgICA8dGQgd2lkdGg9IjEwMCUiPg0KICAgICAgICAgICAgPHAgc3R5bGU9IndvcmQt c3BhY2luZzogMHB4OyBtYXJnaW4tbGVmdDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFy Z2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiA2cHgiIGFsaWduPSJjZW50ZXIiPg0KICAg ICAgICAgICAgPGZvbnQgZmFjZT0iQXJpYWwgQmxhY2siIGNvbG9yPSIjZmZmZjAwIj5PZmVy dGEgbGltaXRhZGEsIGhhc3RhIA0KICAgICAgICAgICAgYWdvdGFyIFN0b2NrLjwvZm9udD48 L3A+DQogICAgICAgICAgICA8cCBzdHlsZT0id29yZC1zcGFjaW5nOiAwcHg7IG1hcmdpbi1s ZWZ0OiAwcHg7IG1hcmdpbi1yaWdodDogMHB4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1i b3R0b206IDZweCIgYWxpZ249ImNlbnRlciI+DQogICAgICAgICAgICA8Yj48Zm9udCBmYWNl PSJBcmlhbCIgY29sb3I9IiNmZmZmMDAiIHNpemU9IjIiPk11Y2hvcyB5YSBsbyB0aWVuZW4s IA0KICAgICAgICAgICAgZXN0YSBvcG9ydHVuaWRhZCBubyBzZSByZXBldGly4SB5IGxhcyB1 bmlkYWRlcyBzZSBlc3RhbiBhY2FiYW5kbywgbm8gDQogICAgICAgICAgICBzZSB2ZW5kZSBw b3Igb3RybyBtZWRpbywgaGF6IHR1IG9mZXJ0YSBwdWVzIG1h8WFuYSBwdWVkZSBzZXIgdGFy ZGUuPC9mb250PjwvYj48L3RkPg0KICAgICAgICAgIDwvdHI+DQogICAgICAgIDwvdGFibGU+ DQogICAgICAgIDwvdGQ+DQogICAgICA8L3RyPg0KICAgIDwvdGFibGU+DQogICAgPC90ZD4N CiAgPC90cj4NCjwvdGFibGU+DQo8dGFibGUgaGVpZ2h0PSIxNTQiIGNlbGxTcGFjaW5nPSIw IiBjZWxsUGFkZGluZz0iMCIgd2lkdGg9IjU4NCIgYm9yZGVyPSIwIj4NCiAgPHRyPg0KICAg IDx0ZCB2QWxpZ249InRvcCIgd2lkdGg9IjI3MSIgaGVpZ2h0PSIxNTQiPg0KICAgIDx0YWJs ZSBoZWlnaHQ9IjQxNSIgY2VsbFNwYWNpbmc9IjAiIGNlbGxQYWRkaW5nPSIwIiB3aWR0aD0i MjA3IiBib3JkZXI9IjAiPg0KICAgICAgPHRyPg0KICAgICAgICA8dGQgd2lkdGg9IjE5NyIg aGVpZ2h0PSI0MTUiPg0KICAgICAgICA8dGFibGUgYm9yZGVyQ29sb3I9IiMwMDgwZmYiIGhl aWdodD0iMzQxIiBjZWxsU3BhY2luZz0iMCIgY2VsbFBhZGRpbmc9IjAiIHdpZHRoPSIxMDAl IiBib3JkZXI9IjIiPg0KICAgICAgICAgIDx0cj4NCiAgICAgICAgICAgIDx0ZCB3aWR0aD0i MTAwJSIgaGVpZ2h0PSIzMSI+DQogICAgICAgICAgICA8dGFibGUgY2VsbFNwYWNpbmc9IjAi IGNlbGxQYWRkaW5nPSI1IiB3aWR0aD0iMTAwJSIgYmdDb2xvcj0iIzAwODBmZiIgYm9yZGVy PSIwIj4NCiAgICAgICAgICAgICAgPHRyPg0KICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0i MTAwJSI+PGZvbnQgZmFjZT0iVGFob21hIiBjb2xvcj0iI2ZmZmZmZiIgc2l6ZT0iMyI+DQog ICAgICAgICAgICAgICAgPGI+Q2FyYWN0ZXLtc3RpY2FzPC9iPjwvZm9udD48L3RkPg0KICAg ICAgICAgICAgICA8L3RyPg0KICAgICAgICAgICAgPC90YWJsZT4NCiAgICAgICAgICAgIDwv dGQ+DQogICAgICAgICAgPC90cj4NCiAgICAgICAgICA8dHI+DQogICAgICAgICAgICA8dGQg d2lkdGg9IjEwMCUiIGhlaWdodD0iMzA2Ij4NCiAgICAgICAgICAgIDx0YWJsZSBoZWlnaHQ9 IjMwMiIgY2VsbFNwYWNpbmc9IjAiIGNlbGxQYWRkaW5nPSI1IiB3aWR0aD0iMTAwJSIgYm9y ZGVyPSIwIj4NCiAgICAgICAgICAgICAgPHRyPg0KICAgICAgICAgICAgICAgIDx0ZCB3aWR0 aD0iMTAwJSIgaGVpZ2h0PSIyOTYiPg0KICAgICAgICAgICAgICAgIDx0YWJsZSBjZWxsU3Bh Y2luZz0iMCIgY2VsbFBhZGRpbmc9IjAiIHdpZHRoPSIxMDAlIiBib3JkZXI9IjAiPg0KICAg ICAgICAgICAgICAgICAgPHRyPg0KICAgICAgICAgICAgICAgICAgICA8dGQgd2lkdGg9IjEw MCUiPg0KICAgICAgICAgICAgICAgICAgICA8cCBzdHlsZT0id29yZC1zcGFjaW5nOiAwcHg7 IG1hcmdpbi1sZWZ0OiAwcHg7IG1hcmdpbi1yaWdodDogMHB4OyBtYXJnaW4tdG9wOiAwcHg7 IG1hcmdpbi1ib3R0b206IDVweCI+DQogICAgICAgICAgICAgICAgICAgIDxmb250IGZhY2U9 IlRhaG9tYSIgY29sb3I9IiMwMDgwZmYiIHNpemU9IjIiPjxiPlVuaWNvIGVuIA0KICAgICAg ICAgICAgICAgICAgICBBcmdlbnRpbmEgcXVlIGxlZSBjZCBjb24gTVAzIHkgYWRlbWFzIGxl ZSBWQ0QgY29uIHNhbGlkYSBkZSANCiAgICAgICAgICAgICAgICAgICAgdmlkZW8geSBhdWRp byBvIHNlYSBxdWUmbmJzcDtzZSB2ZW4gZW4gZWwgdGVsZXZpc29yLCBlcyBsbyB1bHRpbW8g DQogICAgICAgICAgICAgICAgICAgIGVuIHRlY25vbG9naWEgcGFyYSBtcDMgeSB2Y2Q8L2I+ PC9mb250PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgc3R5bGU9IndvcmQtc3BhY2lu ZzogMHB4OyBtYXJnaW4tbGVmdDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLXRv cDogMHB4OyBtYXJnaW4tYm90dG9tOiA1cHgiPg0KICAgICAgICAgICAgICAgICAgICA8Zm9u dCBmYWNlPSJUYWhvbWEiIGNvbG9yPSIjMDA4MGZmIiBzaXplPSIyIj48Yj5FbCANCiAgICAg ICAgICAgICAgICAgICAgcmVwcm9kdWN0b3IgZGUgTVAzIHkgVkNEIGluY2x1eWU6PC9iPjwv Zm9udD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIHN0eWxlPSJ3b3JkLXNwYWNpbmc6 IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi10b3A6 IDBweDsgbWFyZ2luLWJvdHRvbTogNXB4Ij4NCiAgICAgICAgICAgICAgICAgICAgPGZvbnQg ZmFjZT0iVGFob21hIiBjb2xvcj0iIzAwODBmZiIgc2l6ZT0iMiI+PGI+LSBDb250cm9sIA0K ICAgICAgICAgICAgICAgICAgICByZW1vdG8gaW5hbGFtYnJpY288L2I+PC9mb250PjwvcD4N CiAgICAgICAgICAgICAgICAgICAgPHAgc3R5bGU9IndvcmQtc3BhY2luZzogMHB4OyBtYXJn aW4tbGVmdDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJn aW4tYm90dG9tOiA1cHgiPg0KICAgICAgICAgICAgICAgICAgICA8Zm9udCBmYWNlPSJUYWhv bWEiIGNvbG9yPSIjMDA4MGZmIiBzaXplPSIyIj48Yj4tIEJhdGVyaWFzIA0KICAgICAgICAg ICAgICAgICAgICAoUGlsYXMpIFJlY2FyZ2FibGVzIExpdGl1bTwvYj48L2ZvbnQ+PC9wPg0K ICAgICAgICAgICAgICAgICAgICA8cCBzdHlsZT0id29yZC1zcGFjaW5nOiAwcHg7IG1hcmdp bi1sZWZ0OiAwcHg7IG1hcmdpbi1yaWdodDogMHB4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdp bi1ib3R0b206IDVweCI+DQogICAgICAgICAgICAgICAgICAgIDxmb250IGZhY2U9IlRhaG9t YSIgY29sb3I9IiMwMDgwZmYiIHNpemU9IjIiPjxiPi0gQ2FibGVzIGRlIA0KICAgICAgICAg ICAgICAgICAgICBBdWRpbyB5IGRlIFZpZGVvPC9iPjwvZm9udD48L3A+DQogICAgICAgICAg ICAgICAgICAgIDxwIHN0eWxlPSJ3b3JkLXNwYWNpbmc6IDBweDsgbWFyZ2luLWxlZnQ6IDBw eDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTog NXB4Ij4NCiAgICAgICAgICAgICAgICAgICAgPGZvbnQgZmFjZT0iVGFob21hIiBjb2xvcj0i IzAwODBmZiIgc2l6ZT0iMiI+PGI+LSBBdWRpZm9ubzwvYj48L2ZvbnQ+PC9wPg0KICAgICAg ICAgICAgICAgICAgICA8cCBzdHlsZT0id29yZC1zcGFjaW5nOiAwcHg7IG1hcmdpbi1sZWZ0 OiAwcHg7IG1hcmdpbi1yaWdodDogMHB4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0 b206IDVweCI+DQogICAgICAgICAgICAgICAgICAgIDxmb250IGZhY2U9IlRhaG9tYSIgY29s b3I9IiMwMDgwZmYiIHNpemU9IjIiPjxiPi0gTWFudWFsIGRlIA0KICAgICAgICAgICAgICAg ICAgICBpbnN0cnVjY2lvbjwvYj48L2ZvbnQ+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8 cCBzdHlsZT0id29yZC1zcGFjaW5nOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7IG1hcmdpbi1y aWdodDogMHB4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDVweCI+DQogICAg ICAgICAgICAgICAgICAgIDxmb250IGZhY2U9IlRhaG9tYSIgY29sb3I9IiMwMDgwZmYiIHNp emU9IjIiPjxiPi0gDQogICAgICAgICAgICAgICAgICAgIFRyYW5zZm9ybWFkb3I8L2I+PC9m b250PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgc3R5bGU9IndvcmQtc3BhY2luZzog MHB4OyBtYXJnaW4tbGVmdDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLXRvcDog MHB4OyBtYXJnaW4tYm90dG9tOiA1cHgiPg0KICAgICAgICAgICAgICAgICAgICA8Zm9udCBm YWNlPSJUYWhvbWEiIGNvbG9yPSIjMDA4MGZmIiBzaXplPSIyIj48Yj4tIENhcmdhZG9yPC9i PjwvZm9udD48L3RkPg0KICAgICAgICAgICAgICAgICAgPC90cj4NCiAgICAgICAgICAgICAg ICA8L3RhYmxlPg0KICAgICAgICAgICAgICAgIDwvdGQ+DQogICAgICAgICAgICAgIDwvdHI+ DQogICAgICAgICAgICA8L3RhYmxlPg0KICAgICAgICAgICAgPC90ZD4NCiAgICAgICAgICA8 L3RyPg0KICAgICAgICA8L3RhYmxlPg0KICAgICAgICA8L3RkPg0KICAgICAgPC90cj4NCiAg ICA8L3RhYmxlPg0KICAgIDwvdGQ+DQogICAgPHRkIHdpZHRoPSIzMjciIGhlaWdodD0iMTU0 Ij4NCiAgICA8dGFibGUgY2VsbFNwYWNpbmc9IjAiIGNlbGxQYWRkaW5nPSIwIiB3aWR0aD0i MTAwJSIgYm9yZGVyPSIwIj4NCiAgICAgIDx0cj4NCiAgICAgICAgPHRkIHdpZHRoPSIxMDAl Ij4NCiAgICAgICAgPHRhYmxlIGNlbGxTcGFjaW5nPSIwIiBjZWxsUGFkZGluZz0iMCIgd2lk dGg9IjEwMCUiIGJvcmRlcj0iMCI+DQogICAgICAgICAgPHRyPg0KICAgICAgICAgICAgPHRk IHdpZHRoPSI3MiUiPg0KICAgICAgICAgICAgPGltZyBoZWlnaHQ9IjIxMiIgc3JjPSJodHRw Oi8vaW1hZ2Vob3N0LmF1Y3Rpb253YXRjaC5jb20vcHJldmlldy9jYy9jY29ycmVhL21wdHJl cDUuanBnIiB3aWR0aD0iMjIyIiBib3JkZXI9IjAiPjwvdGQ+DQogICAgICAgICAgICA8dGQg d2lkdGg9IjI4JSI+DQogICAgICAgICAgICA8dGFibGUgY2VsbFNwYWNpbmc9IjAiIGNlbGxQ YWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIgYm9yZGVyPSIwIj4NCiAgICAgICAgICAgICAgPHRy Pg0KICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0iMTAwJSI+DQogICAgICAgICAgICAgICAg PGltZyBzcmM9Imh0dHA6Ly9pbWFnZWhvc3QuYXVjdGlvbndhdGNoLmNvbS9wcmV2aWV3L2Nj L2Njb3JyZWEvbXB0cmVwMS5qcGciIHdpZHRoPSIxMjYiIGJvcmRlcj0iMCI+PC90ZD4NCiAg ICAgICAgICAgICAgPC90cj4NCiAgICAgICAgICAgICAgPHRyPg0KICAgICAgICAgICAgICAg IDx0ZCB3aWR0aD0iMTAwJSI+DQogICAgICAgICAgICAgICAgPGltZyBzcmM9Imh0dHA6Ly9p bWFnZWhvc3QuYXVjdGlvbndhdGNoLmNvbS9wcmV2aWV3L2NjL2Njb3JyZWEvbXB0cmVwMi5q cGciIHdpZHRoPSIxMjYiIGJvcmRlcj0iMCI+PC90ZD4NCiAgICAgICAgICAgICAgPC90cj4N CiAgICAgICAgICAgICAgPHRyPg0KICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0iMTAwJSI+ DQogICAgICAgICAgICAgICAgPGltZyBzcmM9Imh0dHA6Ly9pbWFnZWhvc3QuYXVjdGlvbndh dGNoLmNvbS9wcmV2aWV3L2NjL2Njb3JyZWEvbXB0cmVwNy5qcGciIHdpZHRoPSIxMjYiIGJv cmRlcj0iMCI+PC90ZD4NCiAgICAgICAgICAgICAgPC90cj4NCiAgICAgICAgICAgICAgPHRy Pg0KICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0iMTAwJSI+DQogICAgICAgICAgICAgICAg PGltZyBzcmM9Imh0dHA6Ly9pbWFnZWhvc3QuYXVjdGlvbndhdGNoLmNvbS9wcmV2aWV3L2Nj L2Njb3JyZWEvbXB0cmVwOC5qcGciIHdpZHRoPSIxMjYiIGJvcmRlcj0iMCI+PC90ZD4NCiAg ICAgICAgICAgICAgPC90cj4NCiAgICAgICAgICAgIDwvdGFibGU+DQogICAgICAgICAgICA8 L3RkPg0KICAgICAgICAgIDwvdHI+DQogICAgICAgIDwvdGFibGU+DQogICAgICAgIDwvdGQ+ DQogICAgICA8L3RyPg0KICAgICAgPHRyPg0KICAgICAgICA8dGQgd2lkdGg9IjEwMCUiPg0K ICAgICAgICA8dGFibGUgY2VsbFNwYWNpbmc9IjAiIGNlbGxQYWRkaW5nPSIwIiB3aWR0aD0i MTAwJSIgYm9yZGVyPSIwIj4NCiAgICAgICAgICA8dHI+DQogICAgICAgICAgICA8dGQgd2lk dGg9IjUwJSI+DQogICAgICAgICAgICA8aW1nIGhlaWdodD0iMTMyIiBzcmM9Imh0dHA6Ly9p bWFnZWhvc3QuYXVjdGlvbndhdGNoLmNvbS9wcmV2aWV3L2NjL2Njb3JyZWEvbXB0cmVwMy5q cGciIHdpZHRoPSIxNjMiIGJvcmRlcj0iMCI+PC90ZD4NCiAgICAgICAgICAgIDx0ZCB3aWR0 aD0iNTAlIj4NCiAgICAgICAgICAgIDxpbWcgaGVpZ2h0PSIxMzMiIHNyYz0iaHR0cDovL2lt YWdlaG9zdC5hdWN0aW9ud2F0Y2guY29tL3ByZXZpZXcvY2MvY2NvcnJlYS9tcHRyZXA2Lmpw ZyIgd2lkdGg9IjE2OCIgYm9yZGVyPSIwIj48L3RkPg0KICAgICAgICAgIDwvdHI+DQogICAg ICAgIDwvdGFibGU+DQogICAgICAgIDwvdGQ+DQogICAgICA8L3RyPg0KICAgIDwvdGFibGU+ DQogICAgPC90ZD4NCiAgPC90cj4NCjwvdGFibGU+DQo8dGFibGUgaGVpZ2h0PSI0MCIgY2Vs bFNwYWNpbmc9IjAiIGNlbGxQYWRkaW5nPSIwIiB3aWR0aD0iNTg0IiBib3JkZXI9IjAiPg0K ICA8dHI+DQogICAgPHRkIGhlaWdodD0iNDAiPg0KICAgIDx0YWJsZSBjZWxsU3BhY2luZz0i MCIgY2VsbFBhZGRpbmc9IjAiIHdpZHRoPSIxMDAlIiBib3JkZXI9IjAiPg0KICAgICAgPHRy Pg0KICAgICAgICA8dGQgd2lkdGg9IjEwMCUiPg0KICAgICAgICA8dGFibGUgY2VsbFNwYWNp bmc9IjAiIGNlbGxQYWRkaW5nPSI1IiB3aWR0aD0iMTAwJSIgYmdDb2xvcj0iIzAwODBmZiIg Ym9yZGVyPSIwIj4NCiAgICAgICAgICA8dHI+DQogICAgICAgICAgICA8dGQgd2lkdGg9IjEw MCUiPjxiPjxmb250IGZhY2U9IlRhaG9tYSIgY29sb3I9IiNmZmZmZmYiIHNpemU9IjMiPg0K ICAgICAgICAgICAgRXNwZWNpZmljYWNpb25lcyB0ZWNuaWNhczwvZm9udD48L2I+PC90ZD4N CiAgICAgICAgICA8L3RyPg0KICAgICAgICA8L3RhYmxlPg0KICAgICAgICA8L3RkPg0KICAg ICAgPC90cj4NCiAgICAgIDx0cj4NCiAgICAgICAgPHRkIHdpZHRoPSIxMDAlIj4NCiAgICAg ICAgPHRhYmxlIGNlbGxTcGFjaW5nPSIwIiBjZWxsUGFkZGluZz0iNSIgd2lkdGg9IjEwMCUi IGJvcmRlcj0iMCI+DQogICAgICAgICAgPHRyPg0KICAgICAgICAgICAgPHRkIHdpZHRoPSI1 MCUiPjxiPjxmb250IGZhY2U9IlRhaG9tYSIgY29sb3I9IiMwMDgwZmYiIHNpemU9IjIiPg0K ICAgICAgICAgICAgU3Vtc3VuZyBMZW5zPGJyPg0KICAgICAgICAgICAgU29ueSBTZXJ2byBz eXN0ZW08YnI+DQogICAgICAgICAgICBTdXBwb3J0IFJlZ3VsYXIgQXVkaW8sIE1QMyxWQ0Qs RFZDRCw4MCBtaW4gQ0QtUixDRC1SVyBhbmQgOCBjbSBDRC1SIA0KICAgICAgICAgICAgZGlz Yzxicj4NCiAgICAgICAgICAgIGNvbXBhdGlibGUgVkNEIDIuMCwzLjAgYW5kIERWQ0QgZGlz Yzxicj4NCiAgICAgICAgICAgIDYgViBwb3dlciBvdXRwdXQ8YnI+DQogICAgICAgICAgICBi dWlsZC1pbiByZWNoYXJnZWFibGUgbGl0aGl1bSBiYXR0ZXJ5PGJyPg0KICAgICAgICAgICAg Q29uc3VtcHRpb24gb2YgYmF0dGVyeSAoc2kgZXMgcXVlIG5vIGxhIG9yaWdpbmFsKSAyLjUg LSAzIGhvdXJzIGZvciANCiAgICAgICAgICAgIE1QMyBkaXNjPGJyPg0KICAgICAgICAgICAg MS41IC0gMiBob3VycyBmb3IgVkNEIGRpc2M8YnI+DQombmJzcDs8L2ZvbnQ+PC9iPjwvdGQ+ DQogICAgICAgICAgICA8dGQgd2lkdGg9IjUwJSI+PGI+PGZvbnQgZmFjZT0iVGFob21hIiBj b2xvcj0iIzAwODBmZiIgc2l6ZT0iMiI+DQogICAgICAgICAgICBBY2Nlc3Nvcmllczo8YnI+ DQogICAgICAgICAgICBQb3dlciBzdXBwbHkoMTAwViAtIDI0MFYpPGJyPg0KICAgICAgICAg ICAgSW5zdHJ1Y3Rpb24gbWFudWFsPGJyPg0KICAgICAgICAgICAgRWFycGhvbmU8YnI+DQog ICAgICAgICAgICBSZWNoYXJnZWFibGUgTGl0aGl1bSBiYXR0ZXJpZXM8YnI+DQogICAgICAg ICAgICBBL1YgQ2FibGU8YnI+DQogICAgICAgICAgICBSZW1vdGUgY29udHJvbDxicj4NCiAg ICAgICAgICAgIEVzdGFzIHNvbiBsYXMgbm9ybWFzIGEgbGFzIHF1ZSBzZSBzb21ldGllcm9u IHkgcGFzYXJvbiBlc3RvIGF2YWxhIGxhIA0KICAgICAgICAgICAgY2FsaWRhZDxicj4NCiAg ICAgICAgICAgIGFwcHJvdmFsOiBGQ0MsIFVMLCBGREEsIENFLCBDQ0VFPC9mb250PjwvYj48 L3RkPg0KICAgICAgICAgIDwvdHI+DQogICAgICAgIDwvdGFibGU+DQogICAgICAgIDwvdGQ+ DQogICAgICA8L3RyPg0KICAgIDwvdGFibGU+DQogICAgPGRpdiBhbGlnbj0iY2VudGVyIj4N CiAgICAgIDxmb250IGZhY2U9IlRhaG9tYSIgc2l6ZT0iNSI+PHN0cm9uZz5Db24gbGEgY29t cHJhIGRlbCBT+nBlciBEaXNjbWFuIHRlIA0KICAgICAgbGxldmFzIGRlIHJlZ2FsbyA8L3N0 cm9uZz48L2ZvbnQ+DQogICAgPC9kaXY+DQogICAgPGRpdiBhbGlnbj0iY2VudGVyIj4NCiAg ICAgIDxmb250IGZhY2U9IlRhaG9tYSIgc2l6ZT0iNSI+PHN0cm9uZz51bmEgcOlsaWN1bGEg eSB1biBDRCBkZSBtcDMgYSANCiAgICAgIGVsZWNjafNuLjwvc3Ryb25nPjwvZm9udD48L2Rp dj4NCiAgICA8ZGl2IGFsaWduPSJjZW50ZXIiPg0KICAgICAgPGRpdiBhbGlnbj0iY2VudGVy Ij4NCiAgICAgICAgPGZvbnQgZmFjZT0iVGFob21hIiBjb2xvcj0iIzgwMDA4MCIgc2l6ZT0i NSI+PHN0cm9uZz4oTk8gVEUgUE9ERVMgUFJJVkFSIA0KICAgICAgICBERSBMQVMgTUVKT1JF UyBDT1NBUyk8L3N0cm9uZz48L2ZvbnQ+PC9kaXY+DQogICAgPC9kaXY+DQogICAgPC90ZD4N CiAgPC90cj4NCjwvdGFibGU+DQo8cD48Zm9udCBzaXplPSIrMiIgY29sb3I9IiM4MDAwODAi IGZhY2U9IlRhaG9tYSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IA0KRU5WSU9TIEEgVE9ETyBFTCBQQUlTPC9mb250PjwvcD4NCjxw Pjxmb250IHNpemU9IisyIiBjb2xvcj0iIzgwMDA4MCIgZmFjZT0iVGFob21hIj5QQVJBIE1B UyANCklORk9STUFDSU9OIFNPTE8gRU5WSUEgVU4gTUFJTCBBPC9mb250PjxzdHJvbmc+PGZv bnQgZmFjZT0iVGFob21hIiBzaXplPSI1IiBjb2xvcj0iIzgwMDA4MCI+DQo8YSBocmVmPSJt YWlsdG86ZGFyaW9iZXJAc3BlZWR5LmNvbS5hciI+ZGFyaW9iZXJAc3BlZWR5LmNvbS5hcjwv YT48L2ZvbnQ+PC9zdHJvbmc+PC9wPg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4= ------=_NextPart_000_001__2778995_76748,43-- From noreply@sourceforge.net Sat Oct 6 02:59:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Oct 2001 18:59:34 -0700 Subject: [Patches] [ python-Patches-468457 ] Minor changes to sre.Scanner Message-ID: Patches item #468457, was opened at 2001-10-05 18:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468457&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Minor changes to sre.Scanner Initial Comment: I've been experimenting with sre.Scanner as a token generator for the spark parser. The following patch makes three changes. The first I believe is a bug fix (though perhaps I am not using the Scanner class as expected); the other two are enhancement suggestions: 1) In my experience with the current sre.Scanner, if the first pattern in the lexicon matches, an exception is raised because match.lastindex == None (and so cannot be used as an index into the lexicon list). I think this is because the first pattern's subgroup id equals 0. Changing the subgroup setup loop so that the group ids start with 1 eliminates this exception. 2) I needed to use case-insensitive matching for the tokens, and adding (?i) to the patterns didn't work. I believe that to get the pattern compiled using flags, they have to be set in the sre_parse.Pattern object which is allocated in Scanner.__init__; this will not happen with the current Scanner because the calls to sre_parse.parse(phrase) don't have access to the top-level Pattern object, so they can't set the flags in it. I added an optional flags parameter to the Scanner class's constructor which allows setting global flags for compilation of the lexicon patterns. 3) Looking in _sre.c, I found the internal scanner object, which allows repeated matching over a string. This object looks ready-made for this kind of scanning, so I changed Scanner.scan to use it. I've marked each change line with the number of the change (1, 2, or 3) with which it is associated. As for docs and tests, I'm not sure what (if anything) to add, since none exist for the current Scanner class. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468457&group_id=5470 From noreply@sourceforge.net Sat Oct 6 03:06:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Oct 2001 19:06:57 -0700 Subject: [Patches] [ python-Patches-467580 ] ConfigParser.getboolean(): FALSE, TRUE. Message-ID: Patches item #467580, was opened at 2001-10-03 11:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467580&group_id=5470 Category: Library (Lib) Group: None >Status: Open Resolution: Accepted Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ConfigParser.getboolean(): FALSE, TRUE. Initial Comment: This patch allows ConfigParser.getboolean() to interpret TRUE, FALSE, YES, NO, ON and OFF insteaf just '0' and '1'. While just allowing '0' and '1' sounds more correct users ofetn demand to use more descriptive directives in configuration files. Instead of forcing every programmer do brew his own solution a system should include the batteries for this. http://c0re.jp/c0de/misc/ConfigParser-bool.patch This little patch allows Pythons ConfigParser.getboolean() to interpret TRUE, FALSE, YES, NO, ON and OFF insteaf just '0' and '1'. --drt@un.bewaff.net - http://c0re.jp/ --- ConfigParser.py Wed Oct 3 16:31:43 2001 +++ ConfigParser.py Wed Oct 3 16:33:18 2001 @@ -69,8 +69,9 @@ like get(), but convert value to a float getboolean(section, options) - like get(), but convert value to a boolean (currently defined as 0 or - 1, only) + like get(), but convert value to a boolean (currently case insensitive + defined as 0, FALSE, NO or OFF for 0 or 1, TRUE, YES, ON for 1). + Returns an int. remove_section(section) remove the given file section and all its options @@ -314,11 +315,12 @@ return self.__get(section, string.atof, option) def getboolean(self, section, option): - v = self.get(section, option) - val = int(v) - if val not in (0, 1): + states = {'1': 1, 'YES': 1, 'TRUE': 1, 'ON': 1, + '0': 0, 'NO': 0, 'FALSE': 0, 'OFF': 0} + v = self.get(section, option) + if not states.has_key(v.upper()): raise ValueError, 'Not a boolean: %s' % v - return val + return states[v.upper()] def optionxform(self, optionstr): return optionstr.lower() ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-05 19:06 Message: Logged In: YES user_id=6380 Reopened and asigned to Fred, who deals with docs... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-10-05 16:09 Message: Logged In: NO Is submitting here the right way or should I have opened a new patch for this? Nevertheless: http://c0re.jp/c0de/misc/ConfigParser-bool-test.patch This patch adds testing to my ConfigParser-bool patch like GvR requested. See http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467580&group_id=5470 for further enlightenment. --drt@un.bewaff.net - http://c0re.jp/ Index: Lib/test/test_cfgparser.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_cfgparser.py,v retrieving revision 1.8 diff -c -r1.8 test_cfgparser.py *** Lib/test/test_cfgparser.py 2001/07/06 17:22:48 1.8 --- Lib/test/test_cfgparser.py 2001/10/05 23:00:49 *************** *** 78,89 **** verify(cf.get("MySection", "Option") == "first line\nsecond line") def interpolation(src): print "Testing value interpolation..." cf = ConfigParser.ConfigParser({"getname": "%(__name__)s"}) sio = StringIO.StringIO(src) cf.readfp(sio) ! verify(cf.get("Foo", "getname") == "Foo") verify(cf.get("Foo", "bar") == "something with interpolation (1 step)") verify(cf.get("Foo", "bar9") == "something with lots of interpolation (9 steps)") --- 78,108 ---- verify(cf.get("MySection", "Option") == "first line\nsecond line") + def boolean(src): + print "Testing interpretation of boolean Values..." + cf = ConfigParser.ConfigParser() + sio = StringIO.StringIO(src) + cf.readfp(sio) + for x in range(1, 5): + verify(cf.getboolean('BOOLTEST', 't%d' % (x)) == 1) + for x in range(1, 5): + verify(cf.getboolean('BOOLTEST', 'f%d' % (x)) == 0) + for x in range(1, 5): + try: + cf.getboolean('BOOLTEST', 'e%d' % (x)) + except ValueError: + pass + else: + raise TestFailed( + "getboolean() failed to report a non boolean value") + + def interpolation(src): print "Testing value interpolation..." cf = ConfigParser.ConfigParser({"getname": "%(__name__)s"}) sio = StringIO.StringIO(src) cf.readfp(sio) ! verify(cf.get("Foo", "getname") == "Foo") verify(cf.get("Foo", "bar") == "something with interpolation (1 step)") verify(cf.get("Foo", "bar9") == "something with lots of interpolation (9 steps)") *************** *** 180,185 **** --- 199,222 ---- foo[de]=Deutsch """) case_sensitivity() + boolean(r""" + [BOOLTEST] + T1=1 + T2=TRUE + T3=True + T4=oN + T5=yes + F1=0 + F2=FALSE + F3=False + F4=oFF + F5=nO + E1=2 + E2=foo + E3=-1 + E4=0.1 + E5=FALSE AND MORE + """) interpolation(r""" [Foo] bar=something %(with1)s interpolation (1 step) Index: Lib/test/output/test_cfgparser =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/output/test_cfgparser,v retrieving revision 1.4 diff -c -r1.4 test_cfgparser *** Lib/test/output/test_cfgparser 2001/02/26 21:55:34 1.4 --- Lib/test/output/test_cfgparser 2001/10/05 23:00:54 *************** *** 1,6 **** --- 1,7 ---- test_cfgparser Testing basic accessors... Testing case sensitivity... + Testing interpretation of boolean Values... Testing value interpolation... Testing parse errors... Testing query interface... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-10-05 15:02 Message: Logged In: NO The missing documentation - untested since i had no TeX at hand. http://c0re.jp/c0de/misc/ConfigParser-bool-doc.patch This patch adds Documentation to my ConfigParser-bool patch like GvR requested. See http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467580&group_id=5470 for further enlightenment. --drt@un.bewaff.net - http://c0re.jp/ ? ConfigParser-bool-doc.patch Index: Doc/lib/libcfgparser.tex =================================================================== RCS file: /cvsroot/python/python/dist/src/Doc/lib/libcfgparser.tex,v retrieving revision 1.18 diff -c -r1.18 libcfgparser.tex *** Doc/lib/libcfgparser.tex 2001/10/01 17:04:10 1.18 --- Doc/lib/libcfgparser.tex 2001/10/05 21:46:51 *************** *** 163,171 **** \begin{methoddesc}{getboolean}{section, option} A convenience method which coerces the \var{option} in the specified ! \var{section} to a Boolean value. Note that the only accepted values ! for the option are \samp{0} and \samp{1}, any others will raise ! \exception{ValueError}. \end{methoddesc} \begin{methoddesc}{set}{section, option, value} --- 163,173 ---- \begin{methoddesc}{getboolean}{section, option} A convenience method which coerces the \var{option} in the specified ! \var{section} to a Boolean value. \samp{0}, \samp{FALSE}, \samp{NO} ! and \samp{OFF} will return \samp{0} while \samp{1}, \samp{TRUE}, ! \samp{YES} and \samp{ON} will return \samp{1}, any others will raise ! \exception{ValueError}. The interpretation of the textual values is ! case insensitive. \end{methoddesc} \begin{methoddesc}{set}{section, option, value} ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-10-05 06:40 Message: Logged In: NO Name: Doobee R. Tzeck Docs/Tests: will follow shortly. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-04 12:59 Message: Logged In: YES user_id=6380 Nice. Applied to CVS. Would you mind giving your name so we can update the Misc/ACKS file? Also, would you mind providing updates to the docs and to the test suite? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467580&group_id=5470 From noreply@sourceforge.net Sat Oct 6 23:02:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 06 Oct 2001 15:02:05 -0700 Subject: [Patches] [ python-Patches-468647 ] Fix exception propagation in asyncore Message-ID: Patches item #468647, was opened at 2001-10-06 15:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468647&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cesar Eduardo Barros (cesarb) Assigned to: Nobody/Anonymous (nobody) Summary: Fix exception propagation in asyncore Initial Comment: KeyError exceptions from a handle_error method are not propagated, while any other exceptions are. This is clearly not intentional. The attached patch fixes it. The patch is against CVS asyncore.py 1.20. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468647&group_id=5470 From noreply@sourceforge.net Sat Oct 6 23:11:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 06 Oct 2001 15:11:47 -0700 Subject: [Patches] [ python-Patches-468647 ] Fix exception propagation in asyncore Message-ID: Patches item #468647, was opened at 2001-10-06 15:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468647&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cesar Eduardo Barros (cesarb) Assigned to: Nobody/Anonymous (nobody) Summary: Fix exception propagation in asyncore Initial Comment: KeyError exceptions from a handle_error method are not propagated, while any other exceptions are. This is clearly not intentional. The attached patch fixes it. The patch is against CVS asyncore.py 1.20. ---------------------------------------------------------------------- >Comment By: Cesar Eduardo Barros (cesarb) Date: 2001-10-06 15:11 Message: Logged In: YES user_id=57799 The first patch was bogus. Please apply the second one instead. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468647&group_id=5470 From noreply@sourceforge.net Sun Oct 7 00:42:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 06 Oct 2001 16:42:54 -0700 Subject: [Patches] [ python-Patches-468662 ] Allow jython to complete test_grammar Message-ID: Patches item #468662, was opened at 2001-10-06 16:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468662&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Jeremy Hylton (jhylton) Summary: Allow jython to complete test_grammar Initial Comment: The values in jython's co_varnames is a little different then CPython. So far we have decided not to fix this in jython because it looses valuable information about the argument which is difficult to recreate at a later point. the patch will accept the co_varnames values that jython uses as valid values. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468662&group_id=5470 From noreply@sourceforge.net Sun Oct 7 13:33:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 07 Oct 2001 05:33:16 -0700 Subject: [Patches] [ python-Patches-468662 ] Allow jython to complete test_grammar Message-ID: Patches item #468662, was opened at 2001-10-06 16:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468662&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Jeremy Hylton (jhylton) Summary: Allow jython to complete test_grammar Initial Comment: The values in jython's co_varnames is a little different then CPython. So far we have decided not to fix this in jython because it looses valuable information about the argument which is difficult to recreate at a later point. the patch will accept the co_varnames values that jython uses as valid values. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-07 05:33 Message: Logged In: YES user_id=6380 Jeremy, if you don't have time for this, let me do it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468662&group_id=5470 From noreply@sourceforge.net Sun Oct 7 17:29:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 07 Oct 2001 09:29:20 -0700 Subject: [Patches] [ python-Patches-468805 ] Embed invisibly Message-ID: Patches item #468805, was opened at 2001-10-07 09:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468805&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexandre Parenteau (aubonbeurre) Assigned to: Jack Jansen (jackjansen) Summary: Embed invisibly Initial Comment: Abstract: Application that want to embed Python have often their own menu bar and stdin/stdout console scheme. The current MacPython does not allow to bypass the SIOUX console with a user defined one. This patch gives the ability for a client application which embeds Python to silently defines a console handler to be used by Python. In macglue.h: /* from pyGUSISIOUX.cp */ typedef long (*PyWriteHandler)(char *buffer, long n); typedef long (*PyReadHandler)(char *buffer, long n); void PyMac_SetConsoleHandler(PyReadHandler stdinH, PyWriteHandler stdoutH, PyWriteHandler stderrH); ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468805&group_id=5470 From noreply@sourceforge.net Mon Oct 8 03:28:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 07 Oct 2001 19:28:37 -0700 Subject: [Patches] [ python-Patches-468898 ] allow programmer to initialize random.py Message-ID: Patches item #468898, was opened at 2001-10-07 19:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468898&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 4 Submitted By: Skip Montanaro (montanaro) Assigned to: Tim Peters (tim_one) Summary: allow programmer to initialize random.py Initial Comment: While debugging some other problems today, I noticed this code in random.Random.random: # This part is thread-unsafe: # BEGIN CRITICAL SECTION x, y, z = self._seed x = (171 * x) % 30269 y = (172 * y) % 30307 z = (170 * z) % 30323 self._seed = x, y, z # END CRITICAL SECTION In my own code that uses threads, I was easily able to subclass random.Random to provide thread safety for the limited range of functions I call in the module: class Random(random.Random): def __init__(self, x=None): self.lock = threading.RLock() random.Random.__init__(self, x) def random(self): self.lock.acquire() r = random.Random.random(self) self.lock.release() return r Unfortunately, I have calls to random.choice, random.random and random.shuffle scattered far and wide throughout my code. Rather than try to modify all the places where I call random module functions I just hit it with this hammer: def init_random(self): _inst = Random() print "installing", _inst, "as RNG" random.seed = _inst.seed random.random = _inst.random random.uniform = _inst.uniform random.randint = _inst.randint ... init_random() Now I (think I) can use the module-level functions I need in a thread-safe way, but my code is more tightly coupled to the random module's implementation than I'd like. I propose that the code in the random module that initializes the random module's functions be encapsulated in an init function similar that above. The attached patch provides this hook... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468898&group_id=5470 From noreply@sourceforge.net Mon Oct 8 05:37:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 07 Oct 2001 21:37:31 -0700 Subject: [Patches] [ python-Patches-468898 ] allow programmer to initialize random.py Message-ID: Patches item #468898, was opened at 2001-10-07 19:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468898&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Rejected Priority: 4 Submitted By: Skip Montanaro (montanaro) >Assigned to: Nobody/Anonymous (nobody) Summary: allow programmer to initialize random.py Initial Comment: While debugging some other problems today, I noticed this code in random.Random.random: # This part is thread-unsafe: # BEGIN CRITICAL SECTION x, y, z = self._seed x = (171 * x) % 30269 y = (172 * y) % 30307 z = (170 * z) % 30323 self._seed = x, y, z # END CRITICAL SECTION In my own code that uses threads, I was easily able to subclass random.Random to provide thread safety for the limited range of functions I call in the module: class Random(random.Random): def __init__(self, x=None): self.lock = threading.RLock() random.Random.__init__(self, x) def random(self): self.lock.acquire() r = random.Random.random(self) self.lock.release() return r Unfortunately, I have calls to random.choice, random.random and random.shuffle scattered far and wide throughout my code. Rather than try to modify all the places where I call random module functions I just hit it with this hammer: def init_random(self): _inst = Random() print "installing", _inst, "as RNG" random.seed = _inst.seed random.random = _inst.random random.uniform = _inst.uniform random.randint = _inst.randint ... init_random() Now I (think I) can use the module-level functions I need in a thread-safe way, but my code is more tightly coupled to the random module's implementation than I'd like. I propose that the code in the random module that initializes the random module's functions be encapsulated in an init function similar that above. The attached patch provides this hook... ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-10-07 21:37 Message: Logged In: YES user_id=31435 Skip, sorry, I reject this idea. Follow the categorical imperative here: if two people got it into their heads to change the semantics of random's exported functions, at least one of them is guaranteed to get screwed (and more likely both, depending on the relative times at which they try tricking the module -- and since your new module init function isn't threadsafe either, in the end they may get a mixture of both stored into random.py's globals!). As the docs say, the exported functions are not designed to be threadsafe -- that's life, they're just a convenience for casual users. What you've got here is a hack that works for your particular application, but doesn't scale beyond that. If it works for your app today, fine, but it's too brittle for the std library. I personally advise to bite the bullet and modify your call sites to use an explicitly safe random generator. Read the docs for the .jumpahead() method for one safe and efficient (no locks) way to make that work. Beyond that, it would be good if we had a threadsafe modern random() coded in C under the covers. Then nobody would need hacks. The period of the Wichmann-Hill generator has also become too small relative to current machine speeds. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468898&group_id=5470 From noreply@sourceforge.net Mon Oct 8 18:13:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 08 Oct 2001 10:13:36 -0700 Subject: [Patches] [ python-Patches-467580 ] ConfigParser.getboolean(): FALSE, TRUE. Message-ID: Patches item #467580, was opened at 2001-10-03 11:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467580&group_id=5470 Category: Library (Lib) Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ConfigParser.getboolean(): FALSE, TRUE. Initial Comment: This patch allows ConfigParser.getboolean() to interpret TRUE, FALSE, YES, NO, ON and OFF insteaf just '0' and '1'. While just allowing '0' and '1' sounds more correct users ofetn demand to use more descriptive directives in configuration files. Instead of forcing every programmer do brew his own solution a system should include the batteries for this. http://c0re.jp/c0de/misc/ConfigParser-bool.patch This little patch allows Pythons ConfigParser.getboolean() to interpret TRUE, FALSE, YES, NO, ON and OFF insteaf just '0' and '1'. --drt@un.bewaff.net - http://c0re.jp/ --- ConfigParser.py Wed Oct 3 16:31:43 2001 +++ ConfigParser.py Wed Oct 3 16:33:18 2001 @@ -69,8 +69,9 @@ like get(), but convert value to a float getboolean(section, options) - like get(), but convert value to a boolean (currently defined as 0 or - 1, only) + like get(), but convert value to a boolean (currently case insensitive + defined as 0, FALSE, NO or OFF for 0 or 1, TRUE, YES, ON for 1). + Returns an int. remove_section(section) remove the given file section and all its options @@ -314,11 +315,12 @@ return self.__get(section, string.atof, option) def getboolean(self, section, option): - v = self.get(section, option) - val = int(v) - if val not in (0, 1): + states = {'1': 1, 'YES': 1, 'TRUE': 1, 'ON': 1, + '0': 0, 'NO': 0, 'FALSE': 0, 'OFF': 0} + v = self.get(section, option) + if not states.has_key(v.upper()): raise ValueError, 'Not a boolean: %s' % v - return val + return states[v.upper()] def optionxform(self, optionstr): return optionstr.lower() ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-08 10:13 Message: Logged In: YES user_id=3066 Documentation updated in Doc/lib/libcfgparser.tex revision 1.19. Test suite updated in Lib/test/test_cfgparser.py revision 1.9. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-05 19:06 Message: Logged In: YES user_id=6380 Reopened and asigned to Fred, who deals with docs... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-10-05 16:09 Message: Logged In: NO Is submitting here the right way or should I have opened a new patch for this? Nevertheless: http://c0re.jp/c0de/misc/ConfigParser-bool-test.patch This patch adds testing to my ConfigParser-bool patch like GvR requested. See http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467580&group_id=5470 for further enlightenment. --drt@un.bewaff.net - http://c0re.jp/ Index: Lib/test/test_cfgparser.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_cfgparser.py,v retrieving revision 1.8 diff -c -r1.8 test_cfgparser.py *** Lib/test/test_cfgparser.py 2001/07/06 17:22:48 1.8 --- Lib/test/test_cfgparser.py 2001/10/05 23:00:49 *************** *** 78,89 **** verify(cf.get("MySection", "Option") == "first line\nsecond line") def interpolation(src): print "Testing value interpolation..." cf = ConfigParser.ConfigParser({"getname": "%(__name__)s"}) sio = StringIO.StringIO(src) cf.readfp(sio) ! verify(cf.get("Foo", "getname") == "Foo") verify(cf.get("Foo", "bar") == "something with interpolation (1 step)") verify(cf.get("Foo", "bar9") == "something with lots of interpolation (9 steps)") --- 78,108 ---- verify(cf.get("MySection", "Option") == "first line\nsecond line") + def boolean(src): + print "Testing interpretation of boolean Values..." + cf = ConfigParser.ConfigParser() + sio = StringIO.StringIO(src) + cf.readfp(sio) + for x in range(1, 5): + verify(cf.getboolean('BOOLTEST', 't%d' % (x)) == 1) + for x in range(1, 5): + verify(cf.getboolean('BOOLTEST', 'f%d' % (x)) == 0) + for x in range(1, 5): + try: + cf.getboolean('BOOLTEST', 'e%d' % (x)) + except ValueError: + pass + else: + raise TestFailed( + "getboolean() failed to report a non boolean value") + + def interpolation(src): print "Testing value interpolation..." cf = ConfigParser.ConfigParser({"getname": "%(__name__)s"}) sio = StringIO.StringIO(src) cf.readfp(sio) ! verify(cf.get("Foo", "getname") == "Foo") verify(cf.get("Foo", "bar") == "something with interpolation (1 step)") verify(cf.get("Foo", "bar9") == "something with lots of interpolation (9 steps)") *************** *** 180,185 **** --- 199,222 ---- foo[de]=Deutsch """) case_sensitivity() + boolean(r""" + [BOOLTEST] + T1=1 + T2=TRUE + T3=True + T4=oN + T5=yes + F1=0 + F2=FALSE + F3=False + F4=oFF + F5=nO + E1=2 + E2=foo + E3=-1 + E4=0.1 + E5=FALSE AND MORE + """) interpolation(r""" [Foo] bar=something %(with1)s interpolation (1 step) Index: Lib/test/output/test_cfgparser =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/output/test_cfgparser,v retrieving revision 1.4 diff -c -r1.4 test_cfgparser *** Lib/test/output/test_cfgparser 2001/02/26 21:55:34 1.4 --- Lib/test/output/test_cfgparser 2001/10/05 23:00:54 *************** *** 1,6 **** --- 1,7 ---- test_cfgparser Testing basic accessors... Testing case sensitivity... + Testing interpretation of boolean Values... Testing value interpolation... Testing parse errors... Testing query interface... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-10-05 15:02 Message: Logged In: NO The missing documentation - untested since i had no TeX at hand. http://c0re.jp/c0de/misc/ConfigParser-bool-doc.patch This patch adds Documentation to my ConfigParser-bool patch like GvR requested. See http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467580&group_id=5470 for further enlightenment. --drt@un.bewaff.net - http://c0re.jp/ ? ConfigParser-bool-doc.patch Index: Doc/lib/libcfgparser.tex =================================================================== RCS file: /cvsroot/python/python/dist/src/Doc/lib/libcfgparser.tex,v retrieving revision 1.18 diff -c -r1.18 libcfgparser.tex *** Doc/lib/libcfgparser.tex 2001/10/01 17:04:10 1.18 --- Doc/lib/libcfgparser.tex 2001/10/05 21:46:51 *************** *** 163,171 **** \begin{methoddesc}{getboolean}{section, option} A convenience method which coerces the \var{option} in the specified ! \var{section} to a Boolean value. Note that the only accepted values ! for the option are \samp{0} and \samp{1}, any others will raise ! \exception{ValueError}. \end{methoddesc} \begin{methoddesc}{set}{section, option, value} --- 163,173 ---- \begin{methoddesc}{getboolean}{section, option} A convenience method which coerces the \var{option} in the specified ! \var{section} to a Boolean value. \samp{0}, \samp{FALSE}, \samp{NO} ! and \samp{OFF} will return \samp{0} while \samp{1}, \samp{TRUE}, ! \samp{YES} and \samp{ON} will return \samp{1}, any others will raise ! \exception{ValueError}. The interpretation of the textual values is ! case insensitive. \end{methoddesc} \begin{methoddesc}{set}{section, option, value} ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-10-05 06:40 Message: Logged In: NO Name: Doobee R. Tzeck Docs/Tests: will follow shortly. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-04 12:59 Message: Logged In: YES user_id=6380 Nice. Applied to CVS. Would you mind giving your name so we can update the Misc/ACKS file? Also, would you mind providing updates to the docs and to the test suite? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467580&group_id=5470 From noreply@sourceforge.net Tue Oct 9 08:40:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Oct 2001 00:40:12 -0700 Subject: [Patches] [ python-Patches-468647 ] Fix exception propagation in asyncore Message-ID: Patches item #468647, was opened at 2001-10-06 15:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468647&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cesar Eduardo Barros (cesarb) >Assigned to: Martin v. Lцwis (loewis) Summary: Fix exception propagation in asyncore Initial Comment: KeyError exceptions from a handle_error method are not propagated, while any other exceptions are. This is clearly not intentional. The attached patch fixes it. The patch is against CVS asyncore.py 1.20. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-10-09 00:40 Message: Logged In: YES user_id=21627 The patch looks good to me. ---------------------------------------------------------------------- Comment By: Cesar Eduardo Barros (cesarb) Date: 2001-10-06 15:11 Message: Logged In: YES user_id=57799 The first patch was bogus. Please apply the second one instead. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468647&group_id=5470 From noreply@sourceforge.net Tue Oct 9 08:42:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Oct 2001 00:42:39 -0700 Subject: [Patches] [ python-Patches-468394 ] Allow xmlrpclib to handle long ints Message-ID: Patches item #468394, was opened at 2001-10-05 13:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468394&group_id=5470 Category: Library (Lib) Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Skip Montanaro (montanaro) Summary: Allow xmlrpclib to handle long ints Initial Comment: xmlrpclib currently raises an exception when passed a long int, even if it int(N) doesn't raise OverflowError. The attached patch adds a dump_long method to the Marshaller class. It makes no attempt to recover from an out-of-range long, letting the user catch the resulting OverflowError. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-10-09 00:42 Message: Logged In: YES user_id=21627 The patch looks good to me. Please apply it. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-10-05 13:24 Message: Logged In: YES user_id=44345 Damn... Something seems amiss with Opera's file upload capability. It's a short patch, included here: *** /tmp/skip/xmlrpclib.py.~1.11~ Fri Oct 5 15:14:45 2001 --- /tmp/skip/xmlrpclib.py Fri Oct 5 15:14:45 2001 *************** *** 464,469 **** --- 464,474 ---- self.write("%s\n" % value) dispatch[IntType] = dump_int + def dump_long(self, value): + val = int(value) + self.write("%s\n" % val) + dispatch[LongType] = dump_long + def dump_double(self, value): self.write("%s\n" % value) dispatch[FloatType] = dump_double ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468394&group_id=5470 From noreply@sourceforge.net Tue Oct 9 09:48:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Oct 2001 01:48:17 -0700 Subject: [Patches] [ python-Patches-468394 ] Allow xmlrpclib to handle long ints Message-ID: Patches item #468394, was opened at 2001-10-05 13:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468394&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: Allow xmlrpclib to handle long ints Initial Comment: xmlrpclib currently raises an exception when passed a long int, even if it int(N) doesn't raise OverflowError. The attached patch adds a dump_long method to the Marshaller class. It makes no attempt to recover from an out-of-range long, letting the user catch the resulting OverflowError. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-10-09 01:48 Message: Logged In: YES user_id=21627 When committing the patch, please add a line to the History: in the file ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-10-09 00:42 Message: Logged In: YES user_id=21627 The patch looks good to me. Please apply it. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-10-05 13:24 Message: Logged In: YES user_id=44345 Damn... Something seems amiss with Opera's file upload capability. It's a short patch, included here: *** /tmp/skip/xmlrpclib.py.~1.11~ Fri Oct 5 15:14:45 2001 --- /tmp/skip/xmlrpclib.py Fri Oct 5 15:14:45 2001 *************** *** 464,469 **** --- 464,474 ---- self.write("%s\n" % value) dispatch[IntType] = dump_int + def dump_long(self, value): + val = int(value) + self.write("%s\n" % val) + dispatch[LongType] = dump_long + def dump_double(self, value): self.write("%s\n" % value) dispatch[FloatType] = dump_double ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468394&group_id=5470 From noreply@sourceforge.net Tue Oct 9 11:15:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Oct 2001 03:15:07 -0700 Subject: [Patches] [ python-Patches-468647 ] Fix exception propagation in asyncore Message-ID: Patches item #468647, was opened at 2001-10-06 15:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468647&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Cesar Eduardo Barros (cesarb) Assigned to: Martin v. Lцwis (loewis) Summary: Fix exception propagation in asyncore Initial Comment: KeyError exceptions from a handle_error method are not propagated, while any other exceptions are. This is clearly not intentional. The attached patch fixes it. The patch is against CVS asyncore.py 1.20. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-10-09 03:15 Message: Logged In: YES user_id=21627 Thanks for the patch, I have applied it as asyncore.py 1.21. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-10-09 00:40 Message: Logged In: YES user_id=21627 The patch looks good to me. ---------------------------------------------------------------------- Comment By: Cesar Eduardo Barros (cesarb) Date: 2001-10-06 15:11 Message: Logged In: YES user_id=57799 The first patch was bogus. Please apply the second one instead. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468647&group_id=5470 From noreply@sourceforge.net Tue Oct 9 13:30:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Oct 2001 05:30:08 -0700 Subject: [Patches] [ python-Patches-469517 ] Info about rpcgen compilers in Demo/rpc. Message-ID: Patches item #469517, was opened at 2001-10-09 05:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=469517&group_id=5470 Category: Demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Еstrand (astrand) Assigned to: Nobody/Anonymous (nobody) Summary: Info about rpcgen compilers in Demo/rpc. Initial Comment: The files in Demo/rpc claims there is no RPC compiler for Python. This is not true any longer. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=469517&group_id=5470 From noreply@sourceforge.net Wed Oct 10 02:36:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Oct 2001 18:36:50 -0700 Subject: [Patches] [ python-Patches-468662 ] Allow jython to complete test_grammar Message-ID: Patches item #468662, was opened at 2001-10-06 16:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468662&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Jeremy Hylton (jhylton) Summary: Allow jython to complete test_grammar Initial Comment: The values in jython's co_varnames is a little different then CPython. So far we have decided not to fix this in jython because it looses valuable information about the argument which is difficult to recreate at a later point. the patch will accept the co_varnames values that jython uses as valid values. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-10-09 18:36 Message: Logged In: YES user_id=31392 This seems fine to me. I can't believe the CPython behavior is something we want to call part of the language's standard behavior . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-07 05:33 Message: Logged In: YES user_id=6380 Jeremy, if you don't have time for this, let me do it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468662&group_id=5470 From noreply@sourceforge.net Wed Oct 10 16:29:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Oct 2001 08:29:40 -0700 Subject: [Patches] [ python-Patches-469910 ] Bugfix for imaplib for macintosh Message-ID: Patches item #469910, was opened at 2001-10-10 08:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=469910&group_id=5470 Category: Library (Lib) Group: 2.0.1 bugfix Status: Open Resolution: None Priority: 5 Submitted By: Alfonso Baciero (alczj) Assigned to: Nobody/Anonymous (nobody) Summary: Bugfix for imaplib for macintosh Initial Comment: When you try to connect to a imap server with a macintosh, you get an error: >>> >>> import imaplib >>> M = imaplib.IMAP4('imapserver') Traceback (most recent call last): File "", line 1, in ? File "Macintosh HD:Applications (Mac OS 9):Python 2.1.1:Lib:imaplib.py", line 168, in __init__ self._simple_command(cap) File "Macintosh HD:Applications (Mac OS 9):Python 2.1.1:Lib:imaplib.py", line 844, in _simple_command return self._command_complete(name, apply(self._command, (name,) + args)) File "Macintosh HD:Applications (Mac OS 9):Python 2.1.1:Lib:imaplib.py", line 676, in _command_complete raise self.abort('command: %s => %s' % (name, val)) * CAPABILITY IMAP4 IMAP4REV1 NAMESPACE IDLE SCAN SORT MAILBOX-REFERRALS LOGIN-REFERRALS AUTH=LOGIN THREAD=ORDEREDSUBJEC' >>> That is because the file associated to the socket created by IMAP4 object is not binary, and that is a problem with end lines in macintosh. When I changed the file mode to binary it works: ------- start patch----------------------- *** imaplib.py Wed Oct 10 17:12:37 2001 --- imaplib-old.py Wed Oct 10 17:12:03 2001 *************** *** 207,213 **** """ self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.sock.connect((self.host, self.port)) ! self.file = self.sock.makefile('rb') def read(self, size): --- 207,213 ---- """ self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.sock.connect((self.host, self.port)) ! self.file = self.sock.makefile('r') def read(self, size): --------end of patch ----------- With linux, the new imaplib works too, but I have not tested it in other platforms, Alfonso Baciero. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=469910&group_id=5470 From noreply@sourceforge.net Wed Oct 10 18:05:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Oct 2001 10:05:37 -0700 Subject: [Patches] [ python-Patches-469910 ] Bugfix for imaplib for macintosh Message-ID: Patches item #469910, was opened at 2001-10-10 08:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=469910&group_id=5470 Category: Library (Lib) Group: 2.0.1 bugfix Status: Open Resolution: None Priority: 5 Submitted By: Alfonso Baciero (alczj) Assigned to: Nobody/Anonymous (nobody) Summary: Bugfix for imaplib for macintosh Initial Comment: When you try to connect to a imap server with a macintosh, you get an error: >>> >>> import imaplib >>> M = imaplib.IMAP4('imapserver') Traceback (most recent call last): File "", line 1, in ? File "Macintosh HD:Applications (Mac OS 9):Python 2.1.1:Lib:imaplib.py", line 168, in __init__ self._simple_command(cap) File "Macintosh HD:Applications (Mac OS 9):Python 2.1.1:Lib:imaplib.py", line 844, in _simple_command return self._command_complete(name, apply(self._command, (name,) + args)) File "Macintosh HD:Applications (Mac OS 9):Python 2.1.1:Lib:imaplib.py", line 676, in _command_complete raise self.abort('command: %s => %s' % (name, val)) * CAPABILITY IMAP4 IMAP4REV1 NAMESPACE IDLE SCAN SORT MAILBOX-REFERRALS LOGIN-REFERRALS AUTH=LOGIN THREAD=ORDEREDSUBJEC' >>> That is because the file associated to the socket created by IMAP4 object is not binary, and that is a problem with end lines in macintosh. When I changed the file mode to binary it works: ------- start patch----------------------- *** imaplib.py Wed Oct 10 17:12:37 2001 --- imaplib-old.py Wed Oct 10 17:12:03 2001 *************** *** 207,213 **** """ self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.sock.connect((self.host, self.port)) ! self.file = self.sock.makefile('rb') def read(self, size): --- 207,213 ---- """ self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.sock.connect((self.host, self.port)) ! self.file = self.sock.makefile('r') def read(self, size): --------end of patch ----------- With linux, the new imaplib works too, but I have not tested it in other platforms, Alfonso Baciero. ---------------------------------------------------------------------- Comment By: Alfonso Baciero (alczj) Date: 2001-10-10 10:05 Message: Logged In: YES user_id=346109 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=469910&group_id=5470 From noreply@sourceforge.net Thu Oct 11 15:51:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Oct 2001 07:51:03 -0700 Subject: [Patches] [ python-Patches-470254 ] check for xmlrpc ints/longs > 32 bits Message-ID: Patches item #470254, was opened at 2001-10-11 07:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470254&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: check for xmlrpc ints/longs > 32 bits Initial Comment: This patch to xmlrpclib checks ints and long ints when converting to make sure they are within the valid range of ints that XML-RPC can handle. It also adds a couple extra test cases. Can somebody with a machine whose int size is > 32 bits check this? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470254&group_id=5470 From noreply@sourceforge.net Thu Oct 11 17:08:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Oct 2001 09:08:40 -0700 Subject: [Patches] [ python-Patches-414391 ] Inplace optimization for binary ops Message-ID: Patches item #414391, was opened at 2001-04-06 13:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414391&group_id=5470 Category: Core (C code) Group: None Status: Closed Resolution: None Priority: 5 Submitted By: Robin Thomas (robin900) >Assigned to: Jeremy Hylton (jhylton) Summary: Inplace optimization for binary ops Initial Comment: The idea behind this patch: >>> x = range(100) + [1,2,3] + range(90) creates *five* list objects before binding the fifth list object to x. Four of the five objects are discarded. Or: >>> x = range(100) + [2] creates three list objects and discards two. How can we make this more efficient? The implementation overview: When the Python VM POP()s two objects from the stack when doing a BINARY_* opcode, the frame owns one reference to each object. If the left operand object (second one popped) has a reference count of 1, then the object is only reachable by the VM in this frame. Since the VM will DECREF() the object after completing the binary operation and thus discard it, why not do the in-place version of the binary operation? This makes the above example more efficient (by making only three list objects and two list objects, respectively). Any questions, mail me or post to python-list, where the patch and other discussion is present. The patch posted to python-list is against 2.1b1 release. On Mon Apr 09, I will create a cvs diff against current tree and upload here on Sourceforge. ---------------------------------------------------------------------- Comment By: Robin Thomas (robin900) Date: 2001-04-23 12:50 Message: Logged In: YES user_id=127529 closing patch since it's not relevant to current development. ---------------------------------------------------------------------- Comment By: Robin Thomas (robin900) Date: 2001-04-11 18:00 Message: Logged In: YES user_id=127529 The performance stats are bad: a loss (on my Solaris Sparc) of ~180 pystones/sec. Sigh. I'm posting the patch anyway, so that if others find it useful and wish to revive, it will be here. ---------------------------------------------------------------------- Comment By: Robin Thomas (robin900) Date: 2001-04-11 08:21 Message: Logged In: YES user_id=127529 Yes, I'll upload; I never wanted to to go hunting for the patch! :) Some colleagues and I have gathered performance stats on the patch. List concat/repeat is 15-25% faster, but ops on built-in numerics are 1-2% slower. Using Python "make test" to measure the distribution of ops/types, it's almost a wash: ops on built-in numerics are about 10 times more common than list concat/repeat. However, we don't want this patch to be list-specific; the original need was for a general hook so that extension types and user-defined classes could take advantage of the in-place optimization without doing fancy dancing in their own code. Thus, the patch will include a README with our performance and survey findings, and we'll leave the issue open for debate. Expect a patch upload today or tomorrow. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:29 Message: Logged In: YES user_id=6380 Sorry, I don't have the resources to search c.l.py. Can you please upload your patch here? The file uploads should work fine if you check the checkbox above the Browse button. This won't go into 2.1, obviously, so a patch against 2.1 when it is released (expected 4/16/01) would work too. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414391&group_id=5470 From noreply@sourceforge.net Thu Oct 11 17:08:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Oct 2001 09:08:40 -0700 Subject: [Patches] [ python-Patches-460554 ] Fix asyncore.dispatcher.__repr__ Message-ID: Patches item #460554, was opened at 2001-09-10 19:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460554&group_id=5470 Category: Modules Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Cesar Eduardo Barros (cesarb) >Assigned to: Jeremy Hylton (jhylton) Summary: Fix asyncore.dispatcher.__repr__ Initial Comment: This patch fixes a bug that caused the __repr__ method in asyncore.dispatcher to fail when self.addr was a tuple. If it is accepted, you might also think of removing the "import types" line and using type(()) instead of types.TupleType; the types module is used only in that line. The patch is relative to version 1.17 of asyncore.py ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-11 08:14 Message: Logged In: YES user_id=21627 Thanks for the patch, I have committed it as asyncore.py 1.18. Using type(()) is not recommended, since types.TupleType is more explicit. If anything, this could be changed to if type(self.addr) == tuple: or isinstance(self.addr, tuple). However, such a change, if desirable, should be made throughout the library. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460554&group_id=5470 From noreply@sourceforge.net Thu Oct 11 17:08:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Oct 2001 09:08:40 -0700 Subject: [Patches] [ python-Patches-461321 ] Fix timeout=None in asyncore.py Message-ID: Patches item #461321, was opened at 2001-09-13 13:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461321&group_id=5470 Category: Library (Lib) Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Cesar Eduardo Barros (cesarb) >Assigned to: Jeremy Hylton (jhylton) Summary: Fix timeout=None in asyncore.py Initial Comment: This patch makes poll2 and poll3 in asyncore.py work when the timeout argument is None instead of a number. The patch is against CVS 1.18 ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-19 10:32 Message: Logged In: YES user_id=21627 Thanks for the patch. I have committed it as asyncore 1.19. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=461321&group_id=5470 From noreply@sourceforge.net Thu Oct 11 17:10:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Oct 2001 09:10:04 -0700 Subject: [Patches] [ python-Patches-452239 ] cPickle patch for bug 451547 Message-ID: Patches item #452239, was opened at 2001-08-17 14:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452239&group_id=5470 Category: Modules Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Gordon B. McMillan (gmcm) >Assigned to: Jeremy Hylton (jhylton) Summary: cPickle patch for bug 451547 Initial Comment: This patch attempts to do to cPickle what Guido did for pickle.py v 1.50. That is: save_global tries importing the module, and fetching the name from the module. If that fails, or the returned object is not the same one we started with, it raises a PicklingError. (All this so pickling a lambda will fail at save time, rather than load time). Modules/cPickle.c is current CVS from view cvs. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 14:22 Message: Logged In: YES user_id=6380 Thanks! Works like a charm. Checked in as cPickle.c 2.63. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452239&group_id=5470 From noreply@sourceforge.net Thu Oct 11 17:12:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Oct 2001 09:12:01 -0700 Subject: [Patches] [ python-Patches-452110 ] socketmodule ssl: server & thread Message-ID: Patches item #452110, was opened at 2001-08-17 08:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452110&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None >Priority: 5 Submitted By: Jozef Hatala (jhatala) >Assigned to: Jeremy Hylton (jhylton) >Summary: socketmodule ssl: server & thread Initial Comment: Simple enhancement to the SSL support in module socket : - support for writing SSL servers (as well as clients) - Py_*_ALLOW_THREADS arround blocking calls to openssl - rsa temp key to work with older export netscape - renamed attribute server to peer This patch allows for powerfull application servers like the following one to be accessed with "netscape https://localhost:1443/" from socket import * p=socket(AF_INET,SOCK_STREAM) p.bind(('localhost',1443)) p.listen(1) while 1 : s,a = p.accept() c = sslserver(s,'server.key','server.crt') print "They said:", c.read() c.write('HTTP/1.0 200 OK\r\n') c.write('Content-Type: text/plain\r\n\r\n** Hi! **') c.close() TODO: a kind of makefile() on the ssl object like on a socket would be welcome. Have fun, jh ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:17 Message: Logged In: YES user_id=6380 Nice, but where's the documentation? (Thanks for the docstrings though!) And the test suite? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452110&group_id=5470 From noreply@sourceforge.net Thu Oct 11 17:13:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Oct 2001 09:13:43 -0700 Subject: [Patches] [ python-Patches-452110 ] socketmodule ssl: server & thread Message-ID: Patches item #452110, was opened at 2001-08-17 08:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452110&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jozef Hatala (jhatala) Assigned to: Jeremy Hylton (jhylton) Summary: socketmodule ssl: server & thread Initial Comment: Simple enhancement to the SSL support in module socket : - support for writing SSL servers (as well as clients) - Py_*_ALLOW_THREADS arround blocking calls to openssl - rsa temp key to work with older export netscape - renamed attribute server to peer This patch allows for powerfull application servers like the following one to be accessed with "netscape https://localhost:1443/" from socket import * p=socket(AF_INET,SOCK_STREAM) p.bind(('localhost',1443)) p.listen(1) while 1 : s,a = p.accept() c = sslserver(s,'server.key','server.crt') print "They said:", c.read() c.write('HTTP/1.0 200 OK\r\n') c.write('Content-Type: text/plain\r\n\r\n** Hi! **') c.close() TODO: a kind of makefile() on the ssl object like on a socket would be welcome. Have fun, jh ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-10-11 09:13 Message: Logged In: YES user_id=31392 Jozef-- are you going to contribute tests and documentation? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:17 Message: Logged In: YES user_id=6380 Nice, but where's the documentation? (Thanks for the docstrings though!) And the test suite? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452110&group_id=5470 From noreply@sourceforge.net Thu Oct 11 17:14:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Oct 2001 09:14:19 -0700 Subject: [Patches] [ python-Patches-462759 ] socketmodule.c: SSL bugfixes Message-ID: Patches item #462759, was opened at 2001-09-18 21:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462759&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 7 Submitted By: Gerhard Hдring (ghaering) >Assigned to: Jeremy Hylton (jhylton) Summary: socketmodule.c: SSL bugfixes Initial Comment: This patch fixes the following bugs: #461358: SSL constructor/destructor bugs #461353: SSL write doesn't check return codes #461350: SSL support crashes python It also adds more reliable error checking to the SSL methods. And it tries to clean up the code by removing unused variables, for example. I'm an OpenSSL newbie myself, so a code review definitely won't hurt. I'll also try myself if I can talk some OpenSSL experts into reviewing it. As for testcases, Python currently doesn't offer server-side SSL functionality, so any serious client-server testing isn't possible at the moment. I'm also unsure whether patch #452110, that adds this should be added in the current form. I'd rather see a seperate new sslmodule.c that implements something largely interface compatible with socketmodule.c, i. e. with .recv(), .makefile() and all the rest. This would, however, require a serious effort. I doubt that a new SSL implementation could be implemented in a stable way for Python 2.2. The new sslmodule.c could be a combination of the above mentioned patch, the BSD-licensed Python-OpenSSL modules and perhaps some of the current code. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462759&group_id=5470 From noreply@sourceforge.net Thu Oct 11 17:46:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Oct 2001 09:46:38 -0700 Subject: [Patches] [ python-Patches-462759 ] socketmodule.c: SSL bugfixes Message-ID: Patches item #462759, was opened at 2001-09-18 21:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462759&group_id=5470 Category: Modules Group: None Status: Open >Resolution: Accepted Priority: 7 Submitted By: Gerhard Hдring (ghaering) Assigned to: Jeremy Hylton (jhylton) Summary: socketmodule.c: SSL bugfixes Initial Comment: This patch fixes the following bugs: #461358: SSL constructor/destructor bugs #461353: SSL write doesn't check return codes #461350: SSL support crashes python It also adds more reliable error checking to the SSL methods. And it tries to clean up the code by removing unused variables, for example. I'm an OpenSSL newbie myself, so a code review definitely won't hurt. I'll also try myself if I can talk some OpenSSL experts into reviewing it. As for testcases, Python currently doesn't offer server-side SSL functionality, so any serious client-server testing isn't possible at the moment. I'm also unsure whether patch #452110, that adds this should be added in the current form. I'd rather see a seperate new sslmodule.c that implements something largely interface compatible with socketmodule.c, i. e. with .recv(), .makefile() and all the rest. This would, however, require a serious effort. I doubt that a new SSL implementation could be implemented in a stable way for Python 2.2. The new sslmodule.c could be a combination of the above mentioned patch, the BSD-licensed Python-OpenSSL modules and perhaps some of the current code. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-10-11 09:46 Message: Logged In: YES user_id=31392 I'm sorry I forgot about this patch. It covers a lot of the same ground that I covered in yesterday's changes to socketmodule.c. I'll work on applying the rest of the changes relative to the current version of socketmodule.c. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462759&group_id=5470 From noreply@sourceforge.net Thu Oct 11 18:24:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Oct 2001 10:24:00 -0700 Subject: [Patches] [ python-Patches-462759 ] socketmodule.c: SSL bugfixes Message-ID: Patches item #462759, was opened at 2001-09-18 21:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462759&group_id=5470 Category: Modules Group: None >Status: Closed Resolution: Accepted Priority: 7 Submitted By: Gerhard Hдring (ghaering) Assigned to: Jeremy Hylton (jhylton) Summary: socketmodule.c: SSL bugfixes Initial Comment: This patch fixes the following bugs: #461358: SSL constructor/destructor bugs #461353: SSL write doesn't check return codes #461350: SSL support crashes python It also adds more reliable error checking to the SSL methods. And it tries to clean up the code by removing unused variables, for example. I'm an OpenSSL newbie myself, so a code review definitely won't hurt. I'll also try myself if I can talk some OpenSSL experts into reviewing it. As for testcases, Python currently doesn't offer server-side SSL functionality, so any serious client-server testing isn't possible at the moment. I'm also unsure whether patch #452110, that adds this should be added in the current form. I'd rather see a seperate new sslmodule.c that implements something largely interface compatible with socketmodule.c, i. e. with .recv(), .makefile() and all the rest. This would, however, require a serious effort. I doubt that a new SSL implementation could be implemented in a stable way for Python 2.2. The new sslmodule.c could be a combination of the above mentioned patch, the BSD-licensed Python-OpenSSL modules and perhaps some of the current code. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-10-11 09:46 Message: Logged In: YES user_id=31392 I'm sorry I forgot about this patch. It covers a lot of the same ground that I covered in yesterday's changes to socketmodule.c. I'll work on applying the rest of the changes relative to the current version of socketmodule.c. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462759&group_id=5470 From noreply@sourceforge.net Thu Oct 11 19:42:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Oct 2001 11:42:33 -0700 Subject: [Patches] [ python-Patches-470254 ] check for xmlrpc ints/longs > 32 bits Message-ID: Patches item #470254, was opened at 2001-10-11 07:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470254&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: check for xmlrpc ints/longs > 32 bits Initial Comment: This patch to xmlrpclib checks ints and long ints when converting to make sure they are within the valid range of ints that XML-RPC can handle. It also adds a couple extra test cases. Can somebody with a machine whose int size is > 32 bits check this? ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-10-11 11:42 Message: Logged In: YES user_id=21627 Are you sure this is the right patch? It has nothing to do with ints and longs, but re-introduces _cgi_escape using a toplevel "import as" instead... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470254&group_id=5470 From noreply@sourceforge.net Thu Oct 11 20:14:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Oct 2001 12:14:12 -0700 Subject: [Patches] [ python-Patches-469910 ] Bugfix for imaplib for macintosh Message-ID: Patches item #469910, was opened at 2001-10-10 08:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=469910&group_id=5470 Category: Library (Lib) Group: 2.0.1 bugfix Status: Open Resolution: None Priority: 5 Submitted By: Alfonso Baciero (alczj) Assigned to: Nobody/Anonymous (nobody) Summary: Bugfix for imaplib for macintosh Initial Comment: When you try to connect to a imap server with a macintosh, you get an error: >>> >>> import imaplib >>> M = imaplib.IMAP4('imapserver') Traceback (most recent call last): File "", line 1, in ? File "Macintosh HD:Applications (Mac OS 9):Python 2.1.1:Lib:imaplib.py", line 168, in __init__ self._simple_command(cap) File "Macintosh HD:Applications (Mac OS 9):Python 2.1.1:Lib:imaplib.py", line 844, in _simple_command return self._command_complete(name, apply(self._command, (name,) + args)) File "Macintosh HD:Applications (Mac OS 9):Python 2.1.1:Lib:imaplib.py", line 676, in _command_complete raise self.abort('command: %s => %s' % (name, val)) * CAPABILITY IMAP4 IMAP4REV1 NAMESPACE IDLE SCAN SORT MAILBOX-REFERRALS LOGIN-REFERRALS AUTH=LOGIN THREAD=ORDEREDSUBJEC' >>> That is because the file associated to the socket created by IMAP4 object is not binary, and that is a problem with end lines in macintosh. When I changed the file mode to binary it works: ------- start patch----------------------- *** imaplib.py Wed Oct 10 17:12:37 2001 --- imaplib-old.py Wed Oct 10 17:12:03 2001 *************** *** 207,213 **** """ self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.sock.connect((self.host, self.port)) ! self.file = self.sock.makefile('rb') def read(self, size): --- 207,213 ---- """ self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.sock.connect((self.host, self.port)) ! self.file = self.sock.makefile('r') def read(self, size): --------end of patch ----------- With linux, the new imaplib works too, but I have not tested it in other platforms, Alfonso Baciero. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-10-11 12:14 Message: Logged In: YES user_id=21627 The patch looks fine to me. In a binary stream (such as an LDAP connection), using readline (i.e. C fgets) seems risky, since end-of-line characters are really only meaningful in text mode. However, it appears that it should still work on any implementation where \n indicates ASCII LF in binary mode (i.e. on any implementation that uses ASCII, which is a prerequisite in Python, anyway). If somebody thinks this is a problem, IMAP4.readline needs to be rewritten to look for the line delimiter CRLF itself. BTW, how did you issue the "canned response"? ---------------------------------------------------------------------- Comment By: Alfonso Baciero (alczj) Date: 2001-10-10 10:05 Message: Logged In: YES user_id=346109 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=469910&group_id=5470 From noreply@sourceforge.net Thu Oct 11 20:26:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Oct 2001 12:26:56 -0700 Subject: [Patches] [ python-Patches-469517 ] Info about rpcgen compilers in Demo/rpc. Message-ID: Patches item #469517, was opened at 2001-10-09 05:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=469517&group_id=5470 Category: Demos and tools Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Peter Еstrand (astrand) Assigned to: Nobody/Anonymous (nobody) Summary: Info about rpcgen compilers in Demo/rpc. Initial Comment: The files in Demo/rpc claims there is no RPC compiler for Python. This is not true any longer. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-10-11 12:26 Message: Logged In: YES user_id=21627 Thanks for the patch, applied as README 1.5 and mountclient.py 1.8. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=469517&group_id=5470 From noreply@sourceforge.net Thu Oct 11 22:34:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Oct 2001 14:34:37 -0700 Subject: [Patches] [ python-Patches-470393 ] Add missing marshal function Message-ID: Patches item #470393, was opened at 2001-10-11 14:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470393&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: James C. Ahlstrom (ahlstromjc) Assigned to: Nobody/Anonymous (nobody) Summary: Add missing marshal function Initial Comment: In Include/, marshal.h declares both PyMarshal_ReadLongFromFile() and PyMarshal_ReadShortFromFile(), but the second is missing from marshal.c. Here is the patch: *** marshal.old Thu Oct 11 17:27:09 2001 --- marshal.c Thu Oct 11 17:27:24 2001 *************** *** 635,640 **** --- 635,648 ---- } } + int + PyMarshal_ReadShortFromFile(FILE *fp) + { + RFILE rf; + rf.fp = fp; + return r_short(&rf); + } + long PyMarshal_ReadLongFromFile(FILE *fp) { ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470393&group_id=5470 From noreply@sourceforge.net Thu Oct 11 22:36:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Oct 2001 14:36:36 -0700 Subject: [Patches] [ python-Patches-470394 ] Fix keyword arguments with wrapper funcs Message-ID: Patches item #470394, was opened at 2001-10-11 14:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470394&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Fix keyword arguments with wrapper funcs Initial Comment: What summary says. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470394&group_id=5470 From noreply@sourceforge.net Thu Oct 11 22:38:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Oct 2001 14:38:48 -0700 Subject: [Patches] [ python-Patches-470394 ] Fix keyword arguments with wrapper funcs Message-ID: Patches item #470394, was opened at 2001-10-11 14:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470394&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Fix keyword arguments with wrapper funcs Initial Comment: What summary says. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-10-11 14:38 Message: Logged In: NO Aaargh, sourceforge patch upload is broken. Please get the patch at http://people.redhat.com/people/sopwith/python-wrapkwargs.patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470394&group_id=5470 From noreply@sourceforge.net Fri Oct 12 00:51:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Oct 2001 16:51:45 -0700 Subject: [Patches] [ python-Patches-470433 ] Python shouldn't clobber TCL_LIBRARY Message-ID: Patches item #470433, was opened at 2001-10-11 16:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470433&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Python shouldn't clobber TCL_LIBRARY Initial Comment: Python shouldn't clobber TCL_LIBRARY and TK_LIBRARY if they already exist. It means that a given Python executable, or any executable frozn from it will only work with the installed Tk/Tcl. This is especially a problem when the installed Tk is broke (Active state build 210). The patch is to FixTk.py, and you can safely look for Tix too in case that becomes a part of standard distributions in the future. import sys, os, _tkinter ver = str(_tkinter.TCL_VERSION) for t in "tcl", "tk", "tix": if not os.environ.haskey(t.upper() + "_LIBRARY"): v = os.path.join(sys.prefix, "tcl", t+ver) if os.path.exists(os.path.join(v, "tclIndex")): os.environ[t.upper() + "_LIBRARY"] = v ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470433&group_id=5470 From noreply@sourceforge.net Fri Oct 12 01:50:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Oct 2001 17:50:54 -0700 Subject: [Patches] [ python-Patches-470433 ] Python shouldn't clobber TCL_LIBRARY Message-ID: Patches item #470433, was opened at 2001-10-11 16:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470433&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Python shouldn't clobber TCL_LIBRARY Initial Comment: Python shouldn't clobber TCL_LIBRARY and TK_LIBRARY if they already exist. It means that a given Python executable, or any executable frozn from it will only work with the installed Tk/Tcl. This is especially a problem when the installed Tk is broke (Active state build 210). The patch is to FixTk.py, and you can safely look for Tix too in case that becomes a part of standard distributions in the future. import sys, os, _tkinter ver = str(_tkinter.TCL_VERSION) for t in "tcl", "tk", "tix": if not os.environ.haskey(t.upper() + "_LIBRARY"): v = os.path.join(sys.prefix, "tcl", t+ver) if os.path.exists(os.path.join(v, "tclIndex")): os.environ[t.upper() + "_LIBRARY"] = v ---------------------------------------------------------------------- >Comment By: Internet Discovery (idiscovery) Date: 2001-10-11 17:50 Message: Logged In: YES user_id=33229 Sorry, that should be: import sys, os, _tkinter ver = str(_tkinter.TCL_VERSION) for t in "tcl", "tk", "tix": try: v = os.environ[t.upper() + "_LIBRARY"] except KeyError: v = os.path.join(sys.prefix, "tcl", t+ver) if os.path.exists(os.path.join(v, "tclIndex")): os.environ[t.upper() + "_LIBRARY"] = v ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470433&group_id=5470 From noreply@sourceforge.net Fri Oct 12 01:58:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Oct 2001 17:58:36 -0700 Subject: [Patches] [ python-Patches-470433 ] Python shouldn't clobber TCL_LIBRARY Message-ID: Patches item #470433, was opened at 2001-10-11 16:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470433&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Internet Discovery (idiscovery) >Assigned to: Fredrik Lundh (effbot) Summary: Python shouldn't clobber TCL_LIBRARY Initial Comment: Python shouldn't clobber TCL_LIBRARY and TK_LIBRARY if they already exist. It means that a given Python executable, or any executable frozn from it will only work with the installed Tk/Tcl. This is especially a problem when the installed Tk is broke (Active state build 210). The patch is to FixTk.py, and you can safely look for Tix too in case that becomes a part of standard distributions in the future. import sys, os, _tkinter ver = str(_tkinter.TCL_VERSION) for t in "tcl", "tk", "tix": if not os.environ.haskey(t.upper() + "_LIBRARY"): v = os.path.join(sys.prefix, "tcl", t+ver) if os.path.exists(os.path.join(v, "tclIndex")): os.environ[t.upper() + "_LIBRARY"] = v ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-10-11 17:58 Message: Logged In: YES user_id=31435 Assigned to /F, who is the only person I ever met who even knew these envars existed . ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-10-11 17:50 Message: Logged In: YES user_id=33229 Sorry, that should be: import sys, os, _tkinter ver = str(_tkinter.TCL_VERSION) for t in "tcl", "tk", "tix": try: v = os.environ[t.upper() + "_LIBRARY"] except KeyError: v = os.path.join(sys.prefix, "tcl", t+ver) if os.path.exists(os.path.join(v, "tclIndex")): os.environ[t.upper() + "_LIBRARY"] = v ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470433&group_id=5470 From noreply@sourceforge.net Fri Oct 12 10:58:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Oct 2001 02:58:00 -0700 Subject: [Patches] [ python-Patches-470394 ] Fix keyword arguments with wrapper funcs Message-ID: Patches item #470394, was opened at 2001-10-11 14:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470394&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Fix keyword arguments with wrapper funcs Initial Comment: What summary says. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-10-12 02:58 Message: Logged In: YES user_id=21627 Please resubmit the patch, using the following procedure: - log into SF. This is a prerequisite for modifiying your uploads later - set the check box on "Check to Upload & Attach File" - give some description of what problem the patch solves. The URL you've given is invalid; there is no /people on people.redhat.com. Leaving that out, http://people.redhat.com/sopwith/python-wrapkwargs.patch returns an empty file. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-10-11 14:38 Message: Logged In: NO Aaargh, sourceforge patch upload is broken. Please get the patch at http://people.redhat.com/people/sopwith/python-wrapkwargs.patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470394&group_id=5470 From ash@docono.org Fri Oct 12 12:46:35 2001 From: ash@docono.org (DoCoNo) Date: Fri, 12 Oct 2001 20:46:35 +0900 (JST) Subject: [Patches] =?ISO-2022-JP?B?GyRCPTVLdiROJCpBWjpaJDUkLCQ3GyhC?= Message-ID: <20011012114635.7135C8FCFE@mail.docono.org> $B:#=5$N!V$*$+$:!W$O"-$3$N%5%$%H$G3Z$7$s$G$M!*(B http://www.justinmail.net/testpage/gate/gate.htm $B$G$b#1#8:ML$K~$O?)$Y$A$c%@%a!*(B From noreply@sourceforge.net Fri Oct 12 15:03:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Oct 2001 07:03:28 -0700 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: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Guido van Rossum (gvanrossum) 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. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470578&group_id=5470 From noreply@sourceforge.net Fri Oct 12 15:05:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Oct 2001 07:05:39 -0700 Subject: [Patches] [ python-Patches-470433 ] Python shouldn't clobber TCL_LIBRARY Message-ID: Patches item #470433, was opened at 2001-10-11 16:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470433&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Internet Discovery (idiscovery) >Assigned to: Guido van Rossum (gvanrossum) Summary: Python shouldn't clobber TCL_LIBRARY Initial Comment: Python shouldn't clobber TCL_LIBRARY and TK_LIBRARY if they already exist. It means that a given Python executable, or any executable frozn from it will only work with the installed Tk/Tcl. This is especially a problem when the installed Tk is broke (Active state build 210). The patch is to FixTk.py, and you can safely look for Tix too in case that becomes a part of standard distributions in the future. import sys, os, _tkinter ver = str(_tkinter.TCL_VERSION) for t in "tcl", "tk", "tix": if not os.environ.haskey(t.upper() + "_LIBRARY"): v = os.path.join(sys.prefix, "tcl", t+ver) if os.path.exists(os.path.join(v, "tclIndex")): os.environ[t.upper() + "_LIBRARY"] = v ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-12 07:05 Message: Logged In: YES user_id=6380 Reassigned to the author of said code. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-11 17:58 Message: Logged In: YES user_id=31435 Assigned to /F, who is the only person I ever met who even knew these envars existed . ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-10-11 17:50 Message: Logged In: YES user_id=33229 Sorry, that should be: import sys, os, _tkinter ver = str(_tkinter.TCL_VERSION) for t in "tcl", "tk", "tix": try: v = os.environ[t.upper() + "_LIBRARY"] except KeyError: v = os.path.join(sys.prefix, "tcl", t+ver) if os.path.exists(os.path.join(v, "tclIndex")): os.environ[t.upper() + "_LIBRARY"] = v ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470433&group_id=5470 From noreply@sourceforge.net Fri Oct 12 16:13:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Oct 2001 08:13:39 -0700 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.
---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470607&group_id=5470 From noreply@sourceforge.net Fri Oct 12 16:39:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Oct 2001 08:39:48 -0700 Subject: [Patches] [ python-Patches-470614 ] PyMarshal_ReadFileFromLong() Message-ID: Patches item #470614, was opened at 2001-10-12 08:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470614&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: James C. Ahlstrom (ahlstromjc) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: PyMarshal_ReadFileFromLong() Initial Comment: Here is some documentation for marshal. long PyMarshal_ReadLongFromFile(FILE *fp) Read four bytes from an open file pointer, and return a long. The file bytes are in little-endian order; the least significant byte is first. The long is considered to be signed. That is, if the 4-byte long is negative, and if the size of a native long is more than four bytes, the long is sign extended. int PyMarshal_ReadShortFromFile(FILE *fp) The same as PyMarshal_ReadLongFromFile(), but read two bytes, sign extend, and return an int. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470614&group_id=5470 From noreply@sourceforge.net Fri Oct 12 16:54:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Oct 2001 08:54:27 -0700 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: 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 Fri Oct 12 18:04:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Oct 2001 10:04:00 -0700 Subject: [Patches] [ python-Patches-470433 ] Python shouldn't clobber TCL_LIBRARY Message-ID: Patches item #470433, was opened at 2001-10-11 16:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470433&group_id=5470 Category: Tkinter Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Guido van Rossum (gvanrossum) Summary: Python shouldn't clobber TCL_LIBRARY Initial Comment: Python shouldn't clobber TCL_LIBRARY and TK_LIBRARY if they already exist. It means that a given Python executable, or any executable frozn from it will only work with the installed Tk/Tcl. This is especially a problem when the installed Tk is broke (Active state build 210). The patch is to FixTk.py, and you can safely look for Tix too in case that becomes a part of standard distributions in the future. import sys, os, _tkinter ver = str(_tkinter.TCL_VERSION) for t in "tcl", "tk", "tix": if not os.environ.haskey(t.upper() + "_LIBRARY"): v = os.path.join(sys.prefix, "tcl", t+ver) if os.path.exists(os.path.join(v, "tclIndex")): os.environ[t.upper() + "_LIBRARY"] = v ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-12 10:04 Message: Logged In: YES user_id=6380 Checked in as FixTk.py, rev 1.5. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-12 07:05 Message: Logged In: YES user_id=6380 Reassigned to the author of said code. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-11 17:58 Message: Logged In: YES user_id=31435 Assigned to /F, who is the only person I ever met who even knew these envars existed . ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-10-11 17:50 Message: Logged In: YES user_id=33229 Sorry, that should be: import sys, os, _tkinter ver = str(_tkinter.TCL_VERSION) for t in "tcl", "tk", "tix": try: v = os.environ[t.upper() + "_LIBRARY"] except KeyError: v = os.path.join(sys.prefix, "tcl", t+ver) if os.path.exists(os.path.join(v, "tclIndex")): os.environ[t.upper() + "_LIBRARY"] = v ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470433&group_id=5470 From noreply@sourceforge.net Fri Oct 12 18:09:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Oct 2001 10:09:27 -0700 Subject: [Patches] [ python-Patches-470254 ] check for xmlrpc ints/longs > 32 bits Message-ID: Patches item #470254, was opened at 2001-10-11 07:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470254&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: check for xmlrpc ints/longs > 32 bits Initial Comment: This patch to xmlrpclib checks ints and long ints when converting to make sure they are within the valid range of ints that XML-RPC can handle. It also adds a couple extra test cases. Can somebody with a machine whose int size is > 32 bits check this? ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2001-10-12 10:09 Message: Logged In: YES user_id=44345 Oops. Too many diff files with similar names. Try this one. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-10-11 11:42 Message: Logged In: YES user_id=21627 Are you sure this is the right patch? It has nothing to do with ints and longs, but re-introduces _cgi_escape using a toplevel "import as" instead... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470254&group_id=5470 From noreply@sourceforge.net Fri Oct 12 20:35:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Oct 2001 12:35:01 -0700 Subject: [Patches] [ python-Patches-470680 ] Clean output of __repr__ in asyncore Message-ID: Patches item #470680, was opened at 2001-10-12 12:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470680&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cesar Eduardo Barros (cesarb) Assigned to: Nobody/Anonymous (nobody) Summary: Clean output of __repr__ in asyncore Initial Comment: This changes the following in asyncore.dispatcher.__repr__: - Removes double space when status is empty - Adds 0x in front of hex address to be more like classes with no __repr__ - Adds module name in front of class name to be more like classes with no __repr__ Patch against asyncore.py 1.21 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470680&group_id=5470 From noreply@sourceforge.net Fri Oct 12 21:36:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Oct 2001 13:36:23 -0700 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: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) >Assigned to: M.-A. Lemburg (lemburg) 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: 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 Fri Oct 12 21:40:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Oct 2001 13:40:53 -0700 Subject: [Patches] [ python-Patches-468347 ] mask signals for non-main pthreads Message-ID: Patches item #468347, was opened at 2001-10-05 09:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468347&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Lowe (jasonlowe) >Assigned to: Guido van Rossum (gvanrossum) Summary: mask signals for non-main pthreads Initial Comment: This patch updates Python/thread_pthread.h to mask all signals for any thread created. This will keep all signals masked for any thread that isn't the initial thread. For Solaris and Linux, the two platforms I was able to test it on, it solves bug #465673 (pthreads need signal protection) and probably will solve bug #219772 (Interactive InterPreter+ Thread -> core dump at exit). I'd be great if this could get some testing on other platforms, especially HP-UX pre 11.00 and post 11.00, as I had to make some guesses for the DCE thread case. AIX is also a concern as I saw some mention of using sigthreadmask() as a pthread_sigmask() equivalent, but this patch doesn't use sigthreadmask(). I don't have access to AIX. Note that thread_pthread.h.orig in this patch is the unmodified version from the Python2.1 release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468347&group_id=5470 From noreply@sourceforge.net Fri Oct 12 22:49:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Oct 2001 14:49:26 -0700 Subject: [Patches] [ python-Patches-468347 ] mask signals for non-main pthreads Message-ID: Patches item #468347, was opened at 2001-10-05 09:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468347&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jason Lowe (jasonlowe) Assigned to: Guido van Rossum (gvanrossum) Summary: mask signals for non-main pthreads Initial Comment: This patch updates Python/thread_pthread.h to mask all signals for any thread created. This will keep all signals masked for any thread that isn't the initial thread. For Solaris and Linux, the two platforms I was able to test it on, it solves bug #465673 (pthreads need signal protection) and probably will solve bug #219772 (Interactive InterPreter+ Thread -> core dump at exit). I'd be great if this could get some testing on other platforms, especially HP-UX pre 11.00 and post 11.00, as I had to make some guesses for the DCE thread case. AIX is also a concern as I saw some mention of using sigthreadmask() as a pthread_sigmask() equivalent, but this patch doesn't use sigthreadmask(). I don't have access to AIX. Note that thread_pthread.h.orig in this patch is the unmodified version from the Python2.1 release. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-12 14:49 Message: Logged In: YES user_id=6380 As you said, the patch was out of date. Normally that would be enough to ask you to resubmit it relative to the current CVS, but it was too easy. I've checked this in as thread_pthread.h rev 2.33 now, so that it gets maximal exposure when the 2.2b1 release goes out next week. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468347&group_id=5470 From noreply@sourceforge.net Fri Oct 12 23:06:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Oct 2001 15:06:26 -0700 Subject: [Patches] [ python-Patches-464992 ] Fix abstract isinstance Message-ID: Patches item #464992, was opened at 2001-09-25 15:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=464992&group_id=5470 Category: Core (C code) Group: None Status: Open >Resolution: Out of Date Priority: 5 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Neil Schemenauer (nascheme) Summary: Fix abstract isinstance Initial Comment: The built-in isinstance function is still broken when used on extension classes. For example: >>> from ExtensionClass import Base >>> class Super: ... pass ... >>> isinstance(Super(), Base) Traceback (most recent call last): File "", line 1, in ? TypeError: isinstance() arg 2 must be a class or type isinstance() should allow any object as the first argument and a class, a type, or something with a __bases__ tuple attribute for the second argument. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-12 15:06 Message: Logged In: YES user_id=6380 I apologize. Somehow I thought this was a bugh report rather than a patch, and put off looking at it. When I found the patch, it was out of date. Can you rework the patch? You might as well check it in as long as the test suite still works, so we get this in time for 2.2b1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=464992&group_id=5470 From noreply@sourceforge.net Fri Oct 12 23:16:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Oct 2001 15:16:44 -0700 Subject: [Patches] [ python-Patches-467455 ] Enhanced environment variables Message-ID: Patches item #467455, was opened at 2001-10-03 03:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467455&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Toby Dickenson (htrd) >Assigned to: Guido van Rossum (gvanrossum) Summary: Enhanced environment variables Initial Comment: python supports the -d -O and -v command line switches by incrementing the Py_DebugFlag, Py_OptimizeFlag and Py_VerboseFlag. It is also possible to set Py_VerboseFlag etc using environment variables. The logic is currently: if env.var. set and non-empty: if flag is zero: set flag to 1 However it is not possible to use environment variables to set the flags to a value greater than one. This patch changes to logic to: if env.var. set and non-empty: if env.var. is an integer: set flag to that integer if flag is zero: set flag to 1 Under this patch, anyone currently using PYTHONVERBOSE=yes will get the same output as before. PYTHONVERBNOSE=2 will generate more verbosity than before. The only unusual case that the following three are still all equivalent: PYTHONVERBOSE=yespleas PYTHONVERBOSE=1 PYTHONVERBOSE=0 ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-12 15:16 Message: Logged In: YES user_id=6380 Thanks. Applied as pythonrun.c rev 2.149. Note that your patch receives a C-minus for style: - indented 4 spaces - no space after comma - no space between "if" and "(" - no spaces around operators Normally I would have sent it back for that, but I'm in a forgiving mood today. :-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=467455&group_id=5470 From noreply@sourceforge.net Fri Oct 12 23:42:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Oct 2001 15:42:55 -0700 Subject: [Patches] [ python-Patches-470680 ] Clean output of __repr__ in asyncore Message-ID: Patches item #470680, was opened at 2001-10-12 12:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470680&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Cesar Eduardo Barros (cesarb) Assigned to: Nobody/Anonymous (nobody) Summary: Clean output of __repr__ in asyncore Initial Comment: This changes the following in asyncore.dispatcher.__repr__: - Removes double space when status is empty - Adds 0x in front of hex address to be more like classes with no __repr__ - Adds module name in front of class name to be more like classes with no __repr__ Patch against asyncore.py 1.21 ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-10-12 15:42 Message: Logged In: YES user_id=21627 Thanks for the patch. I have applied a similar patch achieving the same effect for the normal case, not touching the "failed" case (asyncore 1.22). Could you ever produce the failed case in real life? If so, we should rather work on not having that fail. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470680&group_id=5470 From noreply@sourceforge.net Sat Oct 13 00:19:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Oct 2001 16:19:20 -0700 Subject: [Patches] [ python-Patches-470680 ] Clean output of __repr__ in asyncore Message-ID: Patches item #470680, was opened at 2001-10-12 12:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470680&group_id=5470 Category: Library (Lib) Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Cesar Eduardo Barros (cesarb) Assigned to: Nobody/Anonymous (nobody) Summary: Clean output of __repr__ in asyncore Initial Comment: This changes the following in asyncore.dispatcher.__repr__: - Removes double space when status is empty - Adds 0x in front of hex address to be more like classes with no __repr__ - Adds module name in front of class name to be more like classes with no __repr__ Patch against asyncore.py 1.21 ---------------------------------------------------------------------- >Comment By: Cesar Eduardo Barros (cesarb) Date: 2001-10-12 16:19 Message: Logged In: YES user_id=57799 Well, I got the failed case before 1.18 (Patch #460554: Properly test for tuples). This happens whenever self.addr can't be converted to %s:%d (which could happen with exotic protocols). So, I think you should change the 'failed' case too. To test, just set self.addr to something invalid (self.addr=1, for instance), and do a repr. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-10-12 15:42 Message: Logged In: YES user_id=21627 Thanks for the patch. I have applied a similar patch achieving the same effect for the normal case, not touching the "failed" case (asyncore 1.22). Could you ever produce the failed case in real life? If so, we should rather work on not having that fail. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470680&group_id=5470 From noreply@sourceforge.net Sat Oct 13 01:38:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Oct 2001 17:38:58 -0700 Subject: [Patches] [ python-Patches-470744 ] More cleanup of __repr__ in asyncore Message-ID: Patches item #470744, was opened at 2001-10-12 17:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470744&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cesar Eduardo Barros (cesarb) Assigned to: Nobody/Anonymous (nobody) Summary: More cleanup of __repr__ in asyncore Initial Comment: This patch removes the ugly 'repr failed' special case in asyncore.dispatcher.__repr__ that happens when self.addr is invalid. - Instead of checking if it's a tuple, just go ahead and catch the TypeError if it isn't (or if it has strange contents). This also removes the import for types. - If it isn't a valid tuple, just do a repr on it. It's probably some alien network protocol with wierd adresses. - I can't see how self.addr can cause a NameError, since it's a class attribute. That was probably historical cruft. Removed. This complements python-Patches-470680 (Clean output of __repr__ in asyncore) which was partially commited as 1.22. This patch is against asyncore.py 1.22. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470744&group_id=5470 From Keila - Curitiba - Pr" Olб! Veja meu site pessoal no "Tripod.com.br". Basta clicar no endereзo abaixo. GARANTO SER SUI-GENERIS - CLIQUE ABAIXO: http://pastorinha.tripod.com.br/seminarista Mais de 61.000 internautas visitaram a PG., existe 7 Бlbuns: Se vocк quiser, por favor, indique minha Home Page, a outros Internautas. Mais detalhes, se comunique, passe um e-mail, que responderei brevemente. Dentro da Home Page, ao lado das fotos, vocк poderб saber muito mais sobre mim! Obrigada. e-mail: pastorinha@ieg.com.br Beijos:- Keila - Curitiba - Pr - Podes falar comigo, direto dela. Brevemente uma Carta Aberta. http://pastorinha.tripod.com.br/seminarista "Esta mensagem й enviada com a complacкncia da nova legislaзгo sobre correio eletrфnico, Seзгo 301, Parбgrafo (a) (2) (c) Decreto S. 1618, Tнtulo Terceiro aprovado pelo "105є Congresso Base das Normativas Internacionais sobre o SPAM". Este E-mail nгo poderб ser considerado SPAM quando incluir uma forma de ser removido. Para ser removido de futuros correios, simplesmente responda indicando no Assunto: REMOVER" From noreply@sourceforge.net Sun Oct 14 05:46:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Oct 2001 21:46:41 -0700 Subject: [Patches] [ python-Patches-470614 ] PyMarshal_ReadFileFromLong() Message-ID: Patches item #470614, was opened at 2001-10-12 08:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470614&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: James C. Ahlstrom (ahlstromjc) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: PyMarshal_ReadFileFromLong() Initial Comment: Here is some documentation for marshal. long PyMarshal_ReadLongFromFile(FILE *fp) Read four bytes from an open file pointer, and return a long. The file bytes are in little-endian order; the least significant byte is first. The long is considered to be signed. That is, if the 4-byte long is negative, and if the size of a native long is more than four bytes, the long is sign extended. int PyMarshal_ReadShortFromFile(FILE *fp) The same as PyMarshal_ReadLongFromFile(), but read two bytes, sign extend, and return an int. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-13 21:46 Message: Logged In: YES user_id=3066 The error reporting behavior of these functions is questionable at best; perhaps something that can clearly distinguish between errors and negative numbers makes more sense? Anyway, I've checked in docs for what is currently there as Doc/api/utilities.tex revision 1.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470614&group_id=5470 From noreply@sourceforge.net Sun Oct 14 22:18:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Oct 2001 14:18:49 -0700 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. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471120&group_id=5470 From noreply@sourceforge.net Mon Oct 15 11:04:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Oct 2001 03:04:34 -0700 Subject: [Patches] [ python-Patches-469910 ] Bugfix for imaplib for macintosh Message-ID: Patches item #469910, was opened at 2001-10-10 08:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=469910&group_id=5470 Category: Library (Lib) Group: 2.0.1 bugfix Status: Open Resolution: None Priority: 5 Submitted By: Alfonso Baciero (alczj) Assigned to: Nobody/Anonymous (nobody) Summary: Bugfix for imaplib for macintosh Initial Comment: When you try to connect to a imap server with a macintosh, you get an error: >>> >>> import imaplib >>> M = imaplib.IMAP4('imapserver') Traceback (most recent call last): File "", line 1, in ? File "Macintosh HD:Applications (Mac OS 9):Python 2.1.1:Lib:imaplib.py", line 168, in __init__ self._simple_command(cap) File "Macintosh HD:Applications (Mac OS 9):Python 2.1.1:Lib:imaplib.py", line 844, in _simple_command return self._command_complete(name, apply(self._command, (name,) + args)) File "Macintosh HD:Applications (Mac OS 9):Python 2.1.1:Lib:imaplib.py", line 676, in _command_complete raise self.abort('command: %s => %s' % (name, val)) * CAPABILITY IMAP4 IMAP4REV1 NAMESPACE IDLE SCAN SORT MAILBOX-REFERRALS LOGIN-REFERRALS AUTH=LOGIN THREAD=ORDEREDSUBJEC' >>> That is because the file associated to the socket created by IMAP4 object is not binary, and that is a problem with end lines in macintosh. When I changed the file mode to binary it works: ------- start patch----------------------- *** imaplib.py Wed Oct 10 17:12:37 2001 --- imaplib-old.py Wed Oct 10 17:12:03 2001 *************** *** 207,213 **** """ self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.sock.connect((self.host, self.port)) ! self.file = self.sock.makefile('rb') def read(self, size): --- 207,213 ---- """ self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.sock.connect((self.host, self.port)) ! self.file = self.sock.makefile('r') def read(self, size): --------end of patch ----------- With linux, the new imaplib works too, but I have not tested it in other platforms, Alfonso Baciero. ---------------------------------------------------------------------- >Comment By: Alfonso Baciero (alczj) Date: 2001-10-15 03:04 Message: Logged In: YES user_id=346109 I don't think I have to say any more about the patch. About the canned response issue, when I posted the patch, I didnґt upload the patch as file. Later I uploaded the patch file and I think that I put the canned response menu to Missing Upload (I now realize that I had not to do that). Sorry by the delay in my response but I haven't been able to connect to internet before. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-10-11 12:14 Message: Logged In: YES user_id=21627 The patch looks fine to me. In a binary stream (such as an LDAP connection), using readline (i.e. C fgets) seems risky, since end-of-line characters are really only meaningful in text mode. However, it appears that it should still work on any implementation where \n indicates ASCII LF in binary mode (i.e. on any implementation that uses ASCII, which is a prerequisite in Python, anyway). If somebody thinks this is a problem, IMAP4.readline needs to be rewritten to look for the line delimiter CRLF itself. BTW, how did you issue the "canned response"? ---------------------------------------------------------------------- Comment By: Alfonso Baciero (alczj) Date: 2001-10-10 10:05 Message: Logged In: YES user_id=346109 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=469910&group_id=5470 From noreply@sourceforge.net Mon Oct 15 14:46:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Oct 2001 06:46:26 -0700 Subject: [Patches] [ python-Patches-469910 ] Bugfix for imaplib for macintosh Message-ID: Patches item #469910, was opened at 2001-10-10 08:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=469910&group_id=5470 Category: Library (Lib) Group: 2.0.1 bugfix >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Alfonso Baciero (alczj) >Assigned to: Guido van Rossum (gvanrossum) Summary: Bugfix for imaplib for macintosh Initial Comment: When you try to connect to a imap server with a macintosh, you get an error: >>> >>> import imaplib >>> M = imaplib.IMAP4('imapserver') Traceback (most recent call last): File "", line 1, in ? File "Macintosh HD:Applications (Mac OS 9):Python 2.1.1:Lib:imaplib.py", line 168, in __init__ self._simple_command(cap) File "Macintosh HD:Applications (Mac OS 9):Python 2.1.1:Lib:imaplib.py", line 844, in _simple_command return self._command_complete(name, apply(self._command, (name,) + args)) File "Macintosh HD:Applications (Mac OS 9):Python 2.1.1:Lib:imaplib.py", line 676, in _command_complete raise self.abort('command: %s => %s' % (name, val)) * CAPABILITY IMAP4 IMAP4REV1 NAMESPACE IDLE SCAN SORT MAILBOX-REFERRALS LOGIN-REFERRALS AUTH=LOGIN THREAD=ORDEREDSUBJEC' >>> That is because the file associated to the socket created by IMAP4 object is not binary, and that is a problem with end lines in macintosh. When I changed the file mode to binary it works: ------- start patch----------------------- *** imaplib.py Wed Oct 10 17:12:37 2001 --- imaplib-old.py Wed Oct 10 17:12:03 2001 *************** *** 207,213 **** """ self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.sock.connect((self.host, self.port)) ! self.file = self.sock.makefile('rb') def read(self, size): --- 207,213 ---- """ self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.sock.connect((self.host, self.port)) ! self.file = self.sock.makefile('r') def read(self, size): --------end of patch ----------- With linux, the new imaplib works too, but I have not tested it in other platforms, Alfonso Baciero. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-15 06:46 Message: Logged In: YES user_id=6380 I think using readline on a binary-opened file is fine, so I've applied this now. I gues he saw the canned response menu because he's an admin for another SF project. I've seen weirdnesses like this before (some submitters can close their own bug report, very confusing). ---------------------------------------------------------------------- Comment By: Alfonso Baciero (alczj) Date: 2001-10-15 03:04 Message: Logged In: YES user_id=346109 I don't think I have to say any more about the patch. About the canned response issue, when I posted the patch, I didnґt upload the patch as file. Later I uploaded the patch file and I think that I put the canned response menu to Missing Upload (I now realize that I had not to do that). Sorry by the delay in my response but I haven't been able to connect to internet before. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-10-11 12:14 Message: Logged In: YES user_id=21627 The patch looks fine to me. In a binary stream (such as an LDAP connection), using readline (i.e. C fgets) seems risky, since end-of-line characters are really only meaningful in text mode. However, it appears that it should still work on any implementation where \n indicates ASCII LF in binary mode (i.e. on any implementation that uses ASCII, which is a prerequisite in Python, anyway). If somebody thinks this is a problem, IMAP4.readline needs to be rewritten to look for the line delimiter CRLF itself. BTW, how did you issue the "canned response"? ---------------------------------------------------------------------- Comment By: Alfonso Baciero (alczj) Date: 2001-10-10 10:05 Message: Logged In: YES user_id=346109 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=469910&group_id=5470 From noreply@sourceforge.net Mon Oct 15 17:12:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Oct 2001 09:12:41 -0700 Subject: [Patches] [ python-Patches-469910 ] Bugfix for imaplib for macintosh Message-ID: Patches item #469910, was opened at 2001-10-10 08:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=469910&group_id=5470 Category: Library (Lib) Group: 2.0.1 bugfix Status: Closed Resolution: Accepted Priority: 5 Submitted By: Alfonso Baciero (alczj) Assigned to: Guido van Rossum (gvanrossum) Summary: Bugfix for imaplib for macintosh Initial Comment: When you try to connect to a imap server with a macintosh, you get an error: >>> >>> import imaplib >>> M = imaplib.IMAP4('imapserver') Traceback (most recent call last): File "", line 1, in ? File "Macintosh HD:Applications (Mac OS 9):Python 2.1.1:Lib:imaplib.py", line 168, in __init__ self._simple_command(cap) File "Macintosh HD:Applications (Mac OS 9):Python 2.1.1:Lib:imaplib.py", line 844, in _simple_command return self._command_complete(name, apply(self._command, (name,) + args)) File "Macintosh HD:Applications (Mac OS 9):Python 2.1.1:Lib:imaplib.py", line 676, in _command_complete raise self.abort('command: %s => %s' % (name, val)) * CAPABILITY IMAP4 IMAP4REV1 NAMESPACE IDLE SCAN SORT MAILBOX-REFERRALS LOGIN-REFERRALS AUTH=LOGIN THREAD=ORDEREDSUBJEC' >>> That is because the file associated to the socket created by IMAP4 object is not binary, and that is a problem with end lines in macintosh. When I changed the file mode to binary it works: ------- start patch----------------------- *** imaplib.py Wed Oct 10 17:12:37 2001 --- imaplib-old.py Wed Oct 10 17:12:03 2001 *************** *** 207,213 **** """ self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.sock.connect((self.host, self.port)) ! self.file = self.sock.makefile('rb') def read(self, size): --- 207,213 ---- """ self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.sock.connect((self.host, self.port)) ! self.file = self.sock.makefile('r') def read(self, size): --------end of patch ----------- With linux, the new imaplib works too, but I have not tested it in other platforms, Alfonso Baciero. ---------------------------------------------------------------------- >Comment By: Alfonso Baciero (alczj) Date: 2001-10-15 09:12 Message: Logged In: YES user_id=346109 In addition to the canned response menu, I see other menus in this patch tracker: "assigned to", "status" and so on. And I am not admin in any project: in fact, I opened the SF account to submit this bug! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-15 06:46 Message: Logged In: YES user_id=6380 I think using readline on a binary-opened file is fine, so I've applied this now. I gues he saw the canned response menu because he's an admin for another SF project. I've seen weirdnesses like this before (some submitters can close their own bug report, very confusing). ---------------------------------------------------------------------- Comment By: Alfonso Baciero (alczj) Date: 2001-10-15 03:04 Message: Logged In: YES user_id=346109 I don't think I have to say any more about the patch. About the canned response issue, when I posted the patch, I didnґt upload the patch as file. Later I uploaded the patch file and I think that I put the canned response menu to Missing Upload (I now realize that I had not to do that). Sorry by the delay in my response but I haven't been able to connect to internet before. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-10-11 12:14 Message: Logged In: YES user_id=21627 The patch looks fine to me. In a binary stream (such as an LDAP connection), using readline (i.e. C fgets) seems risky, since end-of-line characters are really only meaningful in text mode. However, it appears that it should still work on any implementation where \n indicates ASCII LF in binary mode (i.e. on any implementation that uses ASCII, which is a prerequisite in Python, anyway). If somebody thinks this is a problem, IMAP4.readline needs to be rewritten to look for the line delimiter CRLF itself. BTW, how did you issue the "canned response"? ---------------------------------------------------------------------- Comment By: Alfonso Baciero (alczj) Date: 2001-10-10 10:05 Message: Logged In: YES user_id=346109 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=469910&group_id=5470 From noreply@sourceforge.net Mon Oct 15 17:24:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Oct 2001 09:24:06 -0700 Subject: [Patches] [ python-Patches-469910 ] Bugfix for imaplib for macintosh Message-ID: Patches item #469910, was opened at 2001-10-10 08:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=469910&group_id=5470 Category: Library (Lib) Group: 2.0.1 bugfix Status: Closed Resolution: Accepted Priority: 5 Submitted By: Alfonso Baciero (alczj) Assigned to: Guido van Rossum (gvanrossum) Summary: Bugfix for imaplib for macintosh Initial Comment: When you try to connect to a imap server with a macintosh, you get an error: >>> >>> import imaplib >>> M = imaplib.IMAP4('imapserver') Traceback (most recent call last): File "", line 1, in ? File "Macintosh HD:Applications (Mac OS 9):Python 2.1.1:Lib:imaplib.py", line 168, in __init__ self._simple_command(cap) File "Macintosh HD:Applications (Mac OS 9):Python 2.1.1:Lib:imaplib.py", line 844, in _simple_command return self._command_complete(name, apply(self._command, (name,) + args)) File "Macintosh HD:Applications (Mac OS 9):Python 2.1.1:Lib:imaplib.py", line 676, in _command_complete raise self.abort('command: %s => %s' % (name, val)) * CAPABILITY IMAP4 IMAP4REV1 NAMESPACE IDLE SCAN SORT MAILBOX-REFERRALS LOGIN-REFERRALS AUTH=LOGIN THREAD=ORDEREDSUBJEC' >>> That is because the file associated to the socket created by IMAP4 object is not binary, and that is a problem with end lines in macintosh. When I changed the file mode to binary it works: ------- start patch----------------------- *** imaplib.py Wed Oct 10 17:12:37 2001 --- imaplib-old.py Wed Oct 10 17:12:03 2001 *************** *** 207,213 **** """ self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.sock.connect((self.host, self.port)) ! self.file = self.sock.makefile('rb') def read(self, size): --- 207,213 ---- """ self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.sock.connect((self.host, self.port)) ! self.file = self.sock.makefile('r') def read(self, size): --------end of patch ----------- With linux, the new imaplib works too, but I have not tested it in other platforms, Alfonso Baciero. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-15 09:24 Message: Logged In: YES user_id=6380 Bizarre. I've submitted a bug report to SF. Their permission checking must do a reduction of the userid modulo 2**16 or so. :-( ---------------------------------------------------------------------- Comment By: Alfonso Baciero (alczj) Date: 2001-10-15 09:12 Message: Logged In: YES user_id=346109 In addition to the canned response menu, I see other menus in this patch tracker: "assigned to", "status" and so on. And I am not admin in any project: in fact, I opened the SF account to submit this bug! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-15 06:46 Message: Logged In: YES user_id=6380 I think using readline on a binary-opened file is fine, so I've applied this now. I gues he saw the canned response menu because he's an admin for another SF project. I've seen weirdnesses like this before (some submitters can close their own bug report, very confusing). ---------------------------------------------------------------------- Comment By: Alfonso Baciero (alczj) Date: 2001-10-15 03:04 Message: Logged In: YES user_id=346109 I don't think I have to say any more about the patch. About the canned response issue, when I posted the patch, I didnґt upload the patch as file. Later I uploaded the patch file and I think that I put the canned response menu to Missing Upload (I now realize that I had not to do that). Sorry by the delay in my response but I haven't been able to connect to internet before. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-10-11 12:14 Message: Logged In: YES user_id=21627 The patch looks fine to me. In a binary stream (such as an LDAP connection), using readline (i.e. C fgets) seems risky, since end-of-line characters are really only meaningful in text mode. However, it appears that it should still work on any implementation where \n indicates ASCII LF in binary mode (i.e. on any implementation that uses ASCII, which is a prerequisite in Python, anyway). If somebody thinks this is a problem, IMAP4.readline needs to be rewritten to look for the line delimiter CRLF itself. BTW, how did you issue the "canned response"? ---------------------------------------------------------------------- Comment By: Alfonso Baciero (alczj) Date: 2001-10-10 10:05 Message: Logged In: YES user_id=346109 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=469910&group_id=5470 From noreply@sourceforge.net Mon Oct 15 19:25:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Oct 2001 11:25:58 -0700 Subject: [Patches] [ python-Patches-471400 ] quopri.py fix: escape single-dot lines Message-ID: Patches item #471400, was opened at 2001-10-15 11:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471400&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Hildebrand (jdhildeb) Assigned to: Nobody/Anonymous (nobody) Summary: quopri.py fix: escape single-dot lines Initial Comment: This is a patch against the CVS (head) version of quopri.py, which ensures that the encoding never outputs lines which consist of a single dot '.' (as recommended by RFC 2049), since this can cause parts of messages to get dropped when they are submitted via SMTP or via /usr/lib/sendmail. The patch fixes this problem by encoding the '.' as '=2E' if it occurs on a line by itself. In previous versions of quopri.py, line wrapping due to the 76 character limit could cause single-dot lines to be created; this does not appear to be a problem in the current version because the line length is calculated differently. However, a '.' on a line by itself may appear in the input, so this case still needs to be handled. --- /tmp/quopri.py Mon Oct 15 12:50:43 2001 +++ quopri.py Mon Oct 15 13:06:10 2001 @@ -61,6 +61,8 @@ # that trailing character encoded. if s and s[-1:] in ' \t': output.write(s[:-1] + quote(s[-1]) + lineEnd) + elif s == '.': + output.write( quote(s) + lineEnd) else: output.write(s + lineEnd) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471400&group_id=5470 From noreply@sourceforge.net Mon Oct 15 19:44:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Oct 2001 11:44:58 -0700 Subject: [Patches] [ python-Patches-471400 ] quopri.py fix: escape single-dot lines Message-ID: Patches item #471400, was opened at 2001-10-15 11:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471400&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jason Hildebrand (jdhildeb) >Assigned to: Guido van Rossum (gvanrossum) Summary: quopri.py fix: escape single-dot lines Initial Comment: This is a patch against the CVS (head) version of quopri.py, which ensures that the encoding never outputs lines which consist of a single dot '.' (as recommended by RFC 2049), since this can cause parts of messages to get dropped when they are submitted via SMTP or via /usr/lib/sendmail. The patch fixes this problem by encoding the '.' as '=2E' if it occurs on a line by itself. In previous versions of quopri.py, line wrapping due to the 76 character limit could cause single-dot lines to be created; this does not appear to be a problem in the current version because the line length is calculated differently. However, a '.' on a line by itself may appear in the input, so this case still needs to be handled. --- /tmp/quopri.py Mon Oct 15 12:50:43 2001 +++ quopri.py Mon Oct 15 13:06:10 2001 @@ -61,6 +61,8 @@ # that trailing character encoded. if s and s[-1:] in ' \t': output.write(s[:-1] + quote(s[-1]) + lineEnd) + elif s == '.': + output.write( quote(s) + lineEnd) else: output.write(s + lineEnd) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-15 11:44 Message: Logged In: YES user_id=6380 Thanks! Applied to CVS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471400&group_id=5470 From noreply@sourceforge.net Mon Oct 15 20:00:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Oct 2001 12:00:09 -0700 Subject: [Patches] [ python-Patches-471421 ] conditional expression (if-then-else) Message-ID: Patches item #471421, was opened at 2001-10-15 11:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471421&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: conditional expression (if-then-else) Initial Comment: Here's an implementation of conditional expressions of the form if then else It's hairier than expected because I'm trying to require you to put parentheses around it in some cases but not in others. This still lacking: - a PEP to motivate and explain it - documentation - tests - needed changes to Modules/parsermodule.c After applying this patch, you must regenerate the grammar; the Unix Makefile and the current CVS version of the Windows project file do this automatically. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471421&group_id=5470 From noreply@sourceforge.net Mon Oct 15 20:22:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Oct 2001 12:22:17 -0700 Subject: [Patches] [ python-Patches-471421 ] conditional expression (if-then-else) Message-ID: Patches item #471421, was opened at 2001-10-15 11:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471421&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: conditional expression (if-then-else) Initial Comment: Here's an implementation of conditional expressions of the form if then else It's hairier than expected because I'm trying to require you to put parentheses around it in some cases but not in others. This still lacking: - a PEP to motivate and explain it - documentation - tests - needed changes to Modules/parsermodule.c After applying this patch, you must regenerate the grammar; the Unix Makefile and the current CVS version of the Windows project file do this automatically. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-10-15 12:22 Message: Logged In: YES user_id=31435 FYI, the grammar is not regenerated by magic on Windows. I very recently checked in Parser/grammar.mak (a Windows nmake file), which you can use "by hand" (read the comments at the top of the file) to regenerate the grammar if you know that's needed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471421&group_id=5470 From noreply@sourceforge.net Mon Oct 15 20:34:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Oct 2001 12:34:26 -0700 Subject: [Patches] [ python-Patches-471421 ] conditional expression (if-then-else) Message-ID: Patches item #471421, was opened at 2001-10-15 11:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471421&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: conditional expression (if-then-else) Initial Comment: Here's an implementation of conditional expressions of the form if then else It's hairier than expected because I'm trying to require you to put parentheses around it in some cases but not in others. This still lacking: - a PEP to motivate and explain it - documentation - tests - needed changes to Modules/parsermodule.c After applying this patch, you must regenerate the grammar; the Unix Makefile and the current CVS version of the Windows project file do this automatically. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-10-15 12:34 Message: Logged In: YES user_id=21627 Would the grammar become simpler if the syntax was if then else fi ? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-15 12:22 Message: Logged In: YES user_id=31435 FYI, the grammar is not regenerated by magic on Windows. I very recently checked in Parser/grammar.mak (a Windows nmake file), which you can use "by hand" (read the comments at the top of the file) to regenerate the grammar if you know that's needed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471421&group_id=5470 From noreply@sourceforge.net Mon Oct 15 20:41:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Oct 2001 12:41:11 -0700 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: 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 Mon Oct 15 20:44:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Oct 2001 12:44:22 -0700 Subject: [Patches] [ python-Patches-471421 ] conditional expression (if-then-else) Message-ID: Patches item #471421, was opened at 2001-10-15 11:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471421&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: conditional expression (if-then-else) Initial Comment: Here's an implementation of conditional expressions of the form if then else It's hairier than expected because I'm trying to require you to put parentheses around it in some cases but not in others. This still lacking: - a PEP to motivate and explain it - documentation - tests - needed changes to Modules/parsermodule.c After applying this patch, you must regenerate the grammar; the Unix Makefile and the current CVS version of the Windows project file do this automatically. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-10-15 12:44 Message: Logged In: YES user_id=31435 Martin, I don't think so. "The problem" is ensuring the parser can distinguish a conditional expression from an if statement, as they both begin with "if". A left paren rules out an if-statement. If the conditional expression *began* with "fi", no problem . ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-10-15 12:34 Message: Logged In: YES user_id=21627 Would the grammar become simpler if the syntax was if then else fi ? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-15 12:22 Message: Logged In: YES user_id=31435 FYI, the grammar is not regenerated by magic on Windows. I very recently checked in Parser/grammar.mak (a Windows nmake file), which you can use "by hand" (read the comments at the top of the file) to regenerate the grammar if you know that's needed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471421&group_id=5470 From noreply@sourceforge.net Mon Oct 15 20:47:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Oct 2001 12:47:25 -0700 Subject: [Patches] [ python-Patches-471421 ] conditional expression (if-then-else) Message-ID: Patches item #471421, was opened at 2001-10-15 11:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471421&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: conditional expression (if-then-else) Initial Comment: Here's an implementation of conditional expressions of the form if then else It's hairier than expected because I'm trying to require you to put parentheses around it in some cases but not in others. This still lacking: - a PEP to motivate and explain it - documentation - tests - needed changes to Modules/parsermodule.c After applying this patch, you must regenerate the grammar; the Unix Makefile and the current CVS version of the Windows project file do this automatically. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-15 12:47 Message: Logged In: YES user_id=6380 The 'fi' would disambiguate binary operators following the else part. But I find it very unpythonic: we don't have Algol-68 style reversed closing keywords anywhere else, and when you squint you don't see the structure. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-15 12:44 Message: Logged In: YES user_id=31435 Martin, I don't think so. "The problem" is ensuring the parser can distinguish a conditional expression from an if statement, as they both begin with "if". A left paren rules out an if-statement. If the conditional expression *began* with "fi", no problem . ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-10-15 12:34 Message: Logged In: YES user_id=21627 Would the grammar become simpler if the syntax was if then else fi ? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-15 12:22 Message: Logged In: YES user_id=31435 FYI, the grammar is not regenerated by magic on Windows. I very recently checked in Parser/grammar.mak (a Windows nmake file), which you can use "by hand" (read the comments at the top of the file) to regenerate the grammar if you know that's needed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471421&group_id=5470 From noreply@sourceforge.net Mon Oct 15 21:04:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Oct 2001 13:04:40 -0700 Subject: [Patches] [ python-Patches-471421 ] conditional expression (if-then-else) Message-ID: Patches item #471421, was opened at 2001-10-15 11:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471421&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: conditional expression (if-then-else) Initial Comment: Here's an implementation of conditional expressions of the form if then else It's hairier than expected because I'm trying to require you to put parentheses around it in some cases but not in others. This still lacking: - a PEP to motivate and explain it - documentation - tests - needed changes to Modules/parsermodule.c After applying this patch, you must regenerate the grammar; the Unix Makefile and the current CVS version of the Windows project file do this automatically. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-15 13:04 Message: Logged In: YES user_id=6380 Somthing to think about: should this support 'elif'? Like this: p = if x==1 then 'one' elif x==2 then 'two' elif x==3 then 'three' else 'many' With the current patch that would have to be written using ugly extra parentheses: p = if x==1 then '1' else (if x==2 then '2' else (if x==3 then '3' else '*')) It would be easy enough to allow these parentheses to be omitted: just change the conditional to 'if' test 'then' test 'else' (test | conditional). Allowing 'elif' might then not be needed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-15 12:47 Message: Logged In: YES user_id=6380 The 'fi' would disambiguate binary operators following the else part. But I find it very unpythonic: we don't have Algol-68 style reversed closing keywords anywhere else, and when you squint you don't see the structure. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-15 12:44 Message: Logged In: YES user_id=31435 Martin, I don't think so. "The problem" is ensuring the parser can distinguish a conditional expression from an if statement, as they both begin with "if". A left paren rules out an if-statement. If the conditional expression *began* with "fi", no problem . ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-10-15 12:34 Message: Logged In: YES user_id=21627 Would the grammar become simpler if the syntax was if then else fi ? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-15 12:22 Message: Logged In: YES user_id=31435 FYI, the grammar is not regenerated by magic on Windows. I very recently checked in Parser/grammar.mak (a Windows nmake file), which you can use "by hand" (read the comments at the top of the file) to regenerate the grammar if you know that's needed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471421&group_id=5470 From noreply@sourceforge.net Mon Oct 15 21:50:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Oct 2001 13:50:29 -0700 Subject: [Patches] [ python-Patches-471421 ] conditional expression (if-then-else) Message-ID: Patches item #471421, was opened at 2001-10-15 11:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471421&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: conditional expression (if-then-else) Initial Comment: Here's an implementation of conditional expressions of the form if then else It's hairier than expected because I'm trying to require you to put parentheses around it in some cases but not in others. This still lacking: - a PEP to motivate and explain it - documentation - tests - needed changes to Modules/parsermodule.c After applying this patch, you must regenerate the grammar; the Unix Makefile and the current CVS version of the Windows project file do this automatically. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-10-15 13:50 Message: Logged In: YES user_id=31435 About elif, I channeled you as leaving it out deliberately . A long chain of these is probably crying out for a dict lookup instead: p = {1: 'one', 2: 'two', 3: 'three'}.get(x, 'many') where the dict literal wouldn't really be written inline. Short of adding elif, though (OK by me), the "extra" parens needed using "else if" instead must go. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-15 13:04 Message: Logged In: YES user_id=6380 Somthing to think about: should this support 'elif'? Like this: p = if x==1 then 'one' elif x==2 then 'two' elif x==3 then 'three' else 'many' With the current patch that would have to be written using ugly extra parentheses: p = if x==1 then '1' else (if x==2 then '2' else (if x==3 then '3' else '*')) It would be easy enough to allow these parentheses to be omitted: just change the conditional to 'if' test 'then' test 'else' (test | conditional). Allowing 'elif' might then not be needed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-15 12:47 Message: Logged In: YES user_id=6380 The 'fi' would disambiguate binary operators following the else part. But I find it very unpythonic: we don't have Algol-68 style reversed closing keywords anywhere else, and when you squint you don't see the structure. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-15 12:44 Message: Logged In: YES user_id=31435 Martin, I don't think so. "The problem" is ensuring the parser can distinguish a conditional expression from an if statement, as they both begin with "if". A left paren rules out an if-statement. If the conditional expression *began* with "fi", no problem . ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-10-15 12:34 Message: Logged In: YES user_id=21627 Would the grammar become simpler if the syntax was if then else fi ? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-15 12:22 Message: Logged In: YES user_id=31435 FYI, the grammar is not regenerated by magic on Windows. I very recently checked in Parser/grammar.mak (a Windows nmake file), which you can use "by hand" (read the comments at the top of the file) to regenerate the grammar if you know that's needed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471421&group_id=5470 From noreply@sourceforge.net Mon Oct 15 21:53:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Oct 2001 13:53:13 -0700 Subject: [Patches] [ python-Patches-469910 ] Bugfix for imaplib for macintosh Message-ID: Patches item #469910, was opened at 2001-10-10 08:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=469910&group_id=5470 Category: Library (Lib) Group: 2.0.1 bugfix Status: Closed Resolution: Accepted Priority: 5 Submitted By: Alfonso Baciero (alczj) Assigned to: Guido van Rossum (gvanrossum) Summary: Bugfix for imaplib for macintosh Initial Comment: When you try to connect to a imap server with a macintosh, you get an error: >>> >>> import imaplib >>> M = imaplib.IMAP4('imapserver') Traceback (most recent call last): File "", line 1, in ? File "Macintosh HD:Applications (Mac OS 9):Python 2.1.1:Lib:imaplib.py", line 168, in __init__ self._simple_command(cap) File "Macintosh HD:Applications (Mac OS 9):Python 2.1.1:Lib:imaplib.py", line 844, in _simple_command return self._command_complete(name, apply(self._command, (name,) + args)) File "Macintosh HD:Applications (Mac OS 9):Python 2.1.1:Lib:imaplib.py", line 676, in _command_complete raise self.abort('command: %s => %s' % (name, val)) * CAPABILITY IMAP4 IMAP4REV1 NAMESPACE IDLE SCAN SORT MAILBOX-REFERRALS LOGIN-REFERRALS AUTH=LOGIN THREAD=ORDEREDSUBJEC' >>> That is because the file associated to the socket created by IMAP4 object is not binary, and that is a problem with end lines in macintosh. When I changed the file mode to binary it works: ------- start patch----------------------- *** imaplib.py Wed Oct 10 17:12:37 2001 --- imaplib-old.py Wed Oct 10 17:12:03 2001 *************** *** 207,213 **** """ self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.sock.connect((self.host, self.port)) ! self.file = self.sock.makefile('rb') def read(self, size): --- 207,213 ---- """ self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.sock.connect((self.host, self.port)) ! self.file = self.sock.makefile('r') def read(self, size): --------end of patch ----------- With linux, the new imaplib works too, but I have not tested it in other platforms, Alfonso Baciero. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-15 13:53 Message: Logged In: YES user_id=6380 It turns out to be a feature: the original submitter has the same power over a tracker item as the project admin. We never stop learning. :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-15 09:24 Message: Logged In: YES user_id=6380 Bizarre. I've submitted a bug report to SF. Their permission checking must do a reduction of the userid modulo 2**16 or so. :-( ---------------------------------------------------------------------- Comment By: Alfonso Baciero (alczj) Date: 2001-10-15 09:12 Message: Logged In: YES user_id=346109 In addition to the canned response menu, I see other menus in this patch tracker: "assigned to", "status" and so on. And I am not admin in any project: in fact, I opened the SF account to submit this bug! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-15 06:46 Message: Logged In: YES user_id=6380 I think using readline on a binary-opened file is fine, so I've applied this now. I gues he saw the canned response menu because he's an admin for another SF project. I've seen weirdnesses like this before (some submitters can close their own bug report, very confusing). ---------------------------------------------------------------------- Comment By: Alfonso Baciero (alczj) Date: 2001-10-15 03:04 Message: Logged In: YES user_id=346109 I don't think I have to say any more about the patch. About the canned response issue, when I posted the patch, I didnґt upload the patch as file. Later I uploaded the patch file and I think that I put the canned response menu to Missing Upload (I now realize that I had not to do that). Sorry by the delay in my response but I haven't been able to connect to internet before. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-10-11 12:14 Message: Logged In: YES user_id=21627 The patch looks fine to me. In a binary stream (such as an LDAP connection), using readline (i.e. C fgets) seems risky, since end-of-line characters are really only meaningful in text mode. However, it appears that it should still work on any implementation where \n indicates ASCII LF in binary mode (i.e. on any implementation that uses ASCII, which is a prerequisite in Python, anyway). If somebody thinks this is a problem, IMAP4.readline needs to be rewritten to look for the line delimiter CRLF itself. BTW, how did you issue the "canned response"? ---------------------------------------------------------------------- Comment By: Alfonso Baciero (alczj) Date: 2001-10-10 10:05 Message: Logged In: YES user_id=346109 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=469910&group_id=5470 From noreply@sourceforge.net Mon Oct 15 22:01:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Oct 2001 14:01:36 -0700 Subject: [Patches] [ python-Patches-471421 ] conditional expression (if-then-else) Message-ID: Patches item #471421, was opened at 2001-10-15 11:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471421&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: conditional expression (if-then-else) Initial Comment: Here's an implementation of conditional expressions of the form if then else It's hairier than expected because I'm trying to require you to put parentheses around it in some cases but not in others. This still lacking: - a PEP to motivate and explain it - documentation - tests - needed changes to Modules/parsermodule.c After applying this patch, you must regenerate the grammar; the Unix Makefile and the current CVS version of the Windows project file do this automatically. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-15 14:01 Message: Logged In: YES user_id=6380 OK, conditional-2.txt is a patch that includes the paren-less "else if", as well as the graminit.[ch] diffs. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-15 13:50 Message: Logged In: YES user_id=31435 About elif, I channeled you as leaving it out deliberately . A long chain of these is probably crying out for a dict lookup instead: p = {1: 'one', 2: 'two', 3: 'three'}.get(x, 'many') where the dict literal wouldn't really be written inline. Short of adding elif, though (OK by me), the "extra" parens needed using "else if" instead must go. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-15 13:04 Message: Logged In: YES user_id=6380 Somthing to think about: should this support 'elif'? Like this: p = if x==1 then 'one' elif x==2 then 'two' elif x==3 then 'three' else 'many' With the current patch that would have to be written using ugly extra parentheses: p = if x==1 then '1' else (if x==2 then '2' else (if x==3 then '3' else '*')) It would be easy enough to allow these parentheses to be omitted: just change the conditional to 'if' test 'then' test 'else' (test | conditional). Allowing 'elif' might then not be needed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-15 12:47 Message: Logged In: YES user_id=6380 The 'fi' would disambiguate binary operators following the else part. But I find it very unpythonic: we don't have Algol-68 style reversed closing keywords anywhere else, and when you squint you don't see the structure. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-15 12:44 Message: Logged In: YES user_id=31435 Martin, I don't think so. "The problem" is ensuring the parser can distinguish a conditional expression from an if statement, as they both begin with "if". A left paren rules out an if-statement. If the conditional expression *began* with "fi", no problem . ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-10-15 12:34 Message: Logged In: YES user_id=21627 Would the grammar become simpler if the syntax was if then else fi ? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-15 12:22 Message: Logged In: YES user_id=31435 FYI, the grammar is not regenerated by magic on Windows. I very recently checked in Parser/grammar.mak (a Windows nmake file), which you can use "by hand" (read the comments at the top of the file) to regenerate the grammar if you know that's needed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471421&group_id=5470 From noreply@sourceforge.net Tue Oct 16 11:21:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Oct 2001 03:21:39 -0700 Subject: [Patches] [ python-Patches-452110 ] socketmodule ssl: server & thread Message-ID: Patches item #452110, was opened at 2001-08-17 08:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452110&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jozef Hatala (jhatala) Assigned to: Jeremy Hylton (jhylton) Summary: socketmodule ssl: server & thread Initial Comment: Simple enhancement to the SSL support in module socket : - support for writing SSL servers (as well as clients) - Py_*_ALLOW_THREADS arround blocking calls to openssl - rsa temp key to work with older export netscape - renamed attribute server to peer This patch allows for powerfull application servers like the following one to be accessed with "netscape https://localhost:1443/" from socket import * p=socket(AF_INET,SOCK_STREAM) p.bind(('localhost',1443)) p.listen(1) while 1 : s,a = p.accept() c = sslserver(s,'server.key','server.crt') print "They said:", c.read() c.write('HTTP/1.0 200 OK\r\n') c.write('Content-Type: text/plain\r\n\r\n** Hi! **') c.close() TODO: a kind of makefile() on the ssl object like on a socket would be welcome. Have fun, jh ---------------------------------------------------------------------- >Comment By: Jozef Hatala (jhatala) Date: 2001-10-16 03:21 Message: Logged In: YES user_id=300564 I'll submit a simple test with certificates and an enhanced patch for 2.2a2 (does not patch cleanly any more) soon (this week) [time and inet access issues]. I haven't written any doc. There was none for ssl. I know that is no excuse... Does some-one volonotere? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-10-11 09:13 Message: Logged In: YES user_id=31392 Jozef-- are you going to contribute tests and documentation? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:17 Message: Logged In: YES user_id=6380 Nice, but where's the documentation? (Thanks for the docstrings though!) And the test suite? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452110&group_id=5470 From noreply@sourceforge.net Tue Oct 16 17:05:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Oct 2001 09:05:01 -0700 Subject: [Patches] [ python-Patches-452110 ] socketmodule ssl: server & thread Message-ID: Patches item #452110, was opened at 2001-08-17 08:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452110&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jozef Hatala (jhatala) Assigned to: Jeremy Hylton (jhylton) Summary: socketmodule ssl: server & thread Initial Comment: Simple enhancement to the SSL support in module socket : - support for writing SSL servers (as well as clients) - Py_*_ALLOW_THREADS arround blocking calls to openssl - rsa temp key to work with older export netscape - renamed attribute server to peer This patch allows for powerfull application servers like the following one to be accessed with "netscape https://localhost:1443/" from socket import * p=socket(AF_INET,SOCK_STREAM) p.bind(('localhost',1443)) p.listen(1) while 1 : s,a = p.accept() c = sslserver(s,'server.key','server.crt') print "They said:", c.read() c.write('HTTP/1.0 200 OK\r\n') c.write('Content-Type: text/plain\r\n\r\n** Hi! **') c.close() TODO: a kind of makefile() on the ssl object like on a socket would be welcome. Have fun, jh ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-10-16 09:05 Message: Logged In: YES user_id=31392 If you can provide test cases, I'll provide documentation. But hurry, if we don't get this done this week, we may miss Python 2.2. ---------------------------------------------------------------------- Comment By: Jozef Hatala (jhatala) Date: 2001-10-16 03:21 Message: Logged In: YES user_id=300564 I'll submit a simple test with certificates and an enhanced patch for 2.2a2 (does not patch cleanly any more) soon (this week) [time and inet access issues]. I haven't written any doc. There was none for ssl. I know that is no excuse... Does some-one volonotere? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-10-11 09:13 Message: Logged In: YES user_id=31392 Jozef-- are you going to contribute tests and documentation? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:17 Message: Logged In: YES user_id=6380 Nice, but where's the documentation? (Thanks for the docstrings though!) And the test suite? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452110&group_id=5470 From noreply@sourceforge.net Tue Oct 16 20:49:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Oct 2001 12:49:24 -0700 Subject: [Patches] [ python-Patches-471839 ] Bug when extensions import extensions Message-ID: Patches item #471839, was opened at 2001-10-16 12:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471839&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Shane Hathaway (hathawsh) Assigned to: Nobody/Anonymous (nobody) Summary: Bug when extensions import extensions Initial Comment: When an extension imports another extension in its initXXX() function, the variable _Py_PackageContext is prematurely reset to NULL. If the outer extension then calls Py_InitModule(), the extension is installed in sys.modules without its package name. The manifestation of this bug is a "SystemError: _PyImport_FixupExtension: module . not loaded". To fix this, importdl.c just needs to retain the old value of _Py_PackageContext and restore it after the initXXX() method is called. The attached patch does this. This patch applies to Python 2.1.1 and the current CVS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471839&group_id=5470 From noreply@sourceforge.net Tue Oct 16 21:01:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Oct 2001 13:01:21 -0700 Subject: [Patches] [ python-Patches-471839 ] Bug when extensions import extensions Message-ID: Patches item #471839, was opened at 2001-10-16 12:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471839&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Shane Hathaway (hathawsh) >Assigned to: Guido van Rossum (gvanrossum) Summary: Bug when extensions import extensions Initial Comment: When an extension imports another extension in its initXXX() function, the variable _Py_PackageContext is prematurely reset to NULL. If the outer extension then calls Py_InitModule(), the extension is installed in sys.modules without its package name. The manifestation of this bug is a "SystemError: _PyImport_FixupExtension: module . not loaded". To fix this, importdl.c just needs to retain the old value of _Py_PackageContext and restore it after the initXXX() method is called. The attached patch does this. This patch applies to Python 2.1.1 and the current CVS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471839&group_id=5470 From noreply@sourceforge.net Tue Oct 16 21:07:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Oct 2001 13:07:43 -0700 Subject: [Patches] [ python-Patches-471839 ] Bug when extensions import extensions Message-ID: Patches item #471839, was opened at 2001-10-16 12:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471839&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Shane Hathaway (hathawsh) Assigned to: Guido van Rossum (gvanrossum) Summary: Bug when extensions import extensions Initial Comment: When an extension imports another extension in its initXXX() function, the variable _Py_PackageContext is prematurely reset to NULL. If the outer extension then calls Py_InitModule(), the extension is installed in sys.modules without its package name. The manifestation of this bug is a "SystemError: _PyImport_FixupExtension: module . not loaded". To fix this, importdl.c just needs to retain the old value of _Py_PackageContext and restore it after the initXXX() method is called. The attached patch does this. This patch applies to Python 2.1.1 and the current CVS. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-16 13:07 Message: Logged In: YES user_id=6380 Thanks! Fixed in CVS, importdl.c rev 2.69. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471839&group_id=5470 From noreply@sourceforge.net Tue Oct 16 21:09:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Oct 2001 13:09:28 -0700 Subject: [Patches] [ python-Patches-471421 ] conditional expression (if-then-else) Message-ID: Patches item #471421, was opened at 2001-10-15 11:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471421&group_id=5470 Category: Core (C code) Group: None Status: Open >Resolution: Later >Priority: 3 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: conditional expression (if-then-else) Initial Comment: Here's an implementation of conditional expressions of the form if then else It's hairier than expected because I'm trying to require you to put parentheses around it in some cases but not in others. This still lacking: - a PEP to motivate and explain it - documentation - tests - needed changes to Modules/parsermodule.c After applying this patch, you must regenerate the grammar; the Unix Makefile and the current CVS version of the Windows project file do this automatically. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-16 13:09 Message: Logged In: YES user_id=6380 The more I think about this, the less I like it -- mostly because I cannot find decent examples in the std library that would benefit from this... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-15 14:01 Message: Logged In: YES user_id=6380 OK, conditional-2.txt is a patch that includes the paren-less "else if", as well as the graminit.[ch] diffs. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-15 13:50 Message: Logged In: YES user_id=31435 About elif, I channeled you as leaving it out deliberately . A long chain of these is probably crying out for a dict lookup instead: p = {1: 'one', 2: 'two', 3: 'three'}.get(x, 'many') where the dict literal wouldn't really be written inline. Short of adding elif, though (OK by me), the "extra" parens needed using "else if" instead must go. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-15 13:04 Message: Logged In: YES user_id=6380 Somthing to think about: should this support 'elif'? Like this: p = if x==1 then 'one' elif x==2 then 'two' elif x==3 then 'three' else 'many' With the current patch that would have to be written using ugly extra parentheses: p = if x==1 then '1' else (if x==2 then '2' else (if x==3 then '3' else '*')) It would be easy enough to allow these parentheses to be omitted: just change the conditional to 'if' test 'then' test 'else' (test | conditional). Allowing 'elif' might then not be needed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-15 12:47 Message: Logged In: YES user_id=6380 The 'fi' would disambiguate binary operators following the else part. But I find it very unpythonic: we don't have Algol-68 style reversed closing keywords anywhere else, and when you squint you don't see the structure. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-15 12:44 Message: Logged In: YES user_id=31435 Martin, I don't think so. "The problem" is ensuring the parser can distinguish a conditional expression from an if statement, as they both begin with "if". A left paren rules out an if-statement. If the conditional expression *began* with "fi", no problem . ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-10-15 12:34 Message: Logged In: YES user_id=21627 Would the grammar become simpler if the syntax was if then else fi ? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-15 12:22 Message: Logged In: YES user_id=31435 FYI, the grammar is not regenerated by magic on Windows. I very recently checked in Parser/grammar.mak (a Windows nmake file), which you can use "by hand" (read the comments at the top of the file) to regenerate the grammar if you know that's needed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471421&group_id=5470 From noreply@sourceforge.net Tue Oct 16 21:15:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Oct 2001 13:15:43 -0700 Subject: [Patches] [ python-Patches-403753 ] zlib decompress; uncontrollable memory usage Message-ID: Patches item #403753, was opened at 2001-02-12 08:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403753&group_id=5470 Category: Modules Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Toby Dickenson (htrd) Assigned to: Jeremy Hylton (jhylton) Summary: zlib decompress; uncontrollable memory usage Initial Comment: zlib's decompress method will allocate as much memory as is needed to hold the decompressed output. The length of the output buffer may be very much larger than the length of the input buffer, and the python code calling the decompress method has no other way to control how much memory is allocated. In experimentation, I seen decompress generate output that is 1000 times larger than its input These characteristics may make the decompress method unsuitable for handling data obtained from untrusted sources (for example, in a http proxy which implements gzip encoding) since it may be vulnerable to a denial of service attack. A malicious user could construct a moderately sized input which forces 'decompress' to try to allocate too much memory. This patch adds a new method, decompress_incremental, which allows the caller to specify the maximum size of the output. This method returns the excess input, in addition to the decompressed output. It is possible to solve this problem without a patch: If input is fed to the decompressor a few tens of bytes at a time, memory usage will surge by (at most) a few tens of kilobytes. Such a process is a kludge, and much less efficient that the approach used in this patch. (Ive not been able to test the documentation patch; I hope its ok) (This patch also includes the change from Patch #103748) ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-10-16 13:15 Message: Logged In: YES user_id=31392 Indeed, looks like a good feature. Patch is fine with a few little changes. I'll check it in. ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-09-25 02:44 Message: Logged In: YES user_id=46460 The patch from titus (added by loewis) looks good ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-09-25 02:43 Message: Logged In: YES user_id=46460 The patch from titus (added by loewis) looks good ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-09-25 02:41 Message: Logged In: YES user_id=46460 The patch from titus (added by loewis) looks good ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-09-24 23:42 Message: Logged In: YES user_id=23486 I have integrated this patch into the latest Python CVS tree, with a few additional modifications. * added spaces into the documentation patch & verified that doc building works; * fixed problem where the 'unconsumed_tail' attribute returned was *actually* the unused_data attribute; this was caused by indiscriminate cutting & pasting ;). * put in a few additional comments and fixed the code for 80 cols. It doesn't look like I can submit an attachment with this comment (?); I will e-mail it to both loewis & htrd. ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-09-10 07:18 Message: Logged In: YES user_id=46460 I volunteer to update it ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-07 10:03 Message: Logged In: YES user_id=21627 Since this patch has been sitting around for such a long time, it eventually got outdated, due to the conflicting MT patch. Any volunteers to update it? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-06-04 13:55 Message: Logged In: YES user_id=21627 The patch looks good to me; I recommend to approve it. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-04-10 10:52 Message: Logged In: YES user_id=11375 I've let this patch gather dust long enough. Unassigning so that someone else can review it. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2001-04-07 00:20 Message: Logged In: YES user_id=413 as a side note. I believe I implemented a python workaround for this problem by just decompressing data in small chunks (4k at a time) using a decompressor object. see the mojonation project on sourceforge if you're curious. (specifically, in the mojonation evil module, look at common/mojoutil.py for function named safe_zlib_decompress). Regardless, I like thie idea of this patch. It would be good to have that in the main API and documentation for simplicity. (and because there are too many programmers out there who don't realize potential denial of service issues on their own...) ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-02-22 04:50 Message: New patch implementing a new optional parameter to .decompress, and a new attribute .unconsumed_tail ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-02-22 03:42 Message: Waaah - that last comment should be 'cant' not 'can' ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-02-22 03:40 Message: We can reuse .unused_data without introducing an ambiguity. I will prepare a patch that uses a new attribute .unconsumed_tail ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-02-21 11:32 Message: Doesn't .unused_data serve much the same purpose, though? So that even with a maximum size, .decompress() always returns a string, and .unused_data would contain the unprocessed data. ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-02-21 06:00 Message: I did consider that.... An extra change that you didnt mention is the need for a different return value. Currently .decompress() always returns a string. The new method in my patch returns a tuple containing the same string, and an integer specifying how many bytes were consumed from the input. Overloading return values based on an optional parameter seems a little hairy to me, but I would be happy to change the patch if that is your preferred option. I also considered (and rejected) the possibility of adding an optional max-size argument to .decompress() as you suggest, but raising an exception if this limit is exceeded. This avoids the need for an extra return value, but looses out on flexibility. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-02-20 18:48 Message: Rather than introducing a new method, why not just add an optional maxlen argument to .decompress(). I think the changes would be: * add 'int maxlen=-1;' * add "...|i" ... ,&maxlen to the argument parsing * if maxlen != -1, length = maxlen else length = DEFAULTALLOC; * Add '&& maxlen==-1' to the while loop. (Use the current CVS; I just checked in a patch rearranging the zlib module a bit.) Do you want to make those changes and resubmit the patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403753&group_id=5470 From noreply@sourceforge.net Tue Oct 16 21:18:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Oct 2001 13:18:51 -0700 Subject: [Patches] [ python-Patches-452266 ] thread.kill_thread Message-ID: Patches item #452266, was opened at 2001-08-17 17:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470 Category: Core (C code) Group: None Status: Open >Resolution: Later >Priority: 3 Submitted By: Jason Petrone (jpetrone) Assigned to: Guido van Rossum (gvanrossum) Summary: thread.kill_thread Initial Comment: Function to unsafely kill a thread. Implementations are included for posix and nt. If what I have looks reasonable I will add other platforms + docs. I've read Guido's usenet posts on this and understand the reasons against it, but I still think it might be worth having. Thread implementations like the ones in Java and win32 allow it with the caveat that it could result in deadlock, corrupted data, unclaimed resources, bodily harm, etc. Note that it also changes start_new_thread to return the id for the new thread. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-16 13:18 Message: Logged In: YES user_id=6380 I'm tempted to just close this now, but I'll leave it open to see if others have any comments. Basically, the only thread kill that I fell comfortable with would be one that raises an exception. This is easy if the thread is executing Python bytecodes: just check a global flag every once in a while. But the interesting part is when the thread is blocked in something like a socket recv() call, and there the only way to kill it on Unix is to send a signal to the thread -- and on Windows I don't know how to do it. In addition, I've just applied a patch that turns off signals in threads other than the main thread, because in general Python doesn't like signals being delivered to other threads. I'm sorry, Jason -- you did a decent amount of research on this one, but still more is required... ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-19 10:52 Message: Logged In: YES user_id=21627 One note on killing threads: Part of working "safely" would be that any reference to objects that the thread currently holds is released when the thread is killed. That essentially requires that all C stack frames perform the appropriate Py_DECREFs, which is not feasible through the thread kill mechanisms of the thread libraries (AFAIK). Instead, a Python exception is about the only approach that has a chance of working "safely". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-22 01:21 Message: Logged In: YES user_id=6380 Sending SIGINT may be easy, but that only covers the Unix side. Also, catching it requires more work, interfering with the existing signal handling, so this becomes A Project. (So, yes, the hard part is getting Python to process signals out of the main thread.) Thanks for the new patch! This is a step in the right direction. It came too late to be reviewed for 2.2a2, but I'll try to get it into 2.2a3. ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-08-20 21:21 Message: Logged In: YES user_id=71210 Sending SIGINT to a thread is pretty easy. Is the hard part of killing a thread with signals getting python to process signals outside of the main thread? At any rate, I'm attaching a new patch that returns the thread id from start_new_thread, without any of the kill_thread() stuff. It includes a change to libthread.tex. For platforms I don't really know I just had them return -1 on failure and 0 on success so they at least run. o Solaris, pthreads, pth - returns thread id, tested o NT - returns thread id, (should work, haven't tested after removing kill) o SGI, BeOS - returns thread id, untested o wince, OS/2, LWP, cthread, foobar - returns -1 on failure, 0 on success ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-20 06:01 Message: Logged In: YES user_id=6380 Thanks to Tim for jogging my memory. I think an interruption facility should be a way to send an exception to a thread, similar to KeyboardInterrupt -- the thread can then decide what to do (and since exceptions can happen anyway, the safety guarantee is not violated -- if the application doesn't release locks on exceptions, it is already unsafe). One problem is that it's probably most important to be able to stop a thread while it's blocked for I/O (a socket connect() or recv() from a non-responding host is a typical example). Unfortunately, the only way to do that on Unix is to send a real signal to the thread. On Windows, I have no idea. Note that part of this patch would still be useful: start_new_thread() should return a thread-id. ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-08-19 20:21 Message: Logged In: YES user_id=71210 While I would very much like to have full interruption functionality, I'm not sure how easily it could be done on all platforms. At the least it would be nice to have SOME sort of thread signalling. What guarantees about safety should python make? I've considered trying to add cleanup handlers to release interpreter locks and such, but didn't feel like putting that much effort into a patch that would likely be rejected anyway. I will look into adding cleanup routines if we can establish some requirements. I think I can do it in pthreads pretty easily. Dunno how easy the rest will be. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-19 14:24 Message: Logged In: YES user_id=31435 I've never called TerminateThread() on Win32, and given the dire wngs about it in the MS docs, never will. IMO Python shouldn't be in this business unless it can guarantee to do it safely. But it can't, so -1 from me. Java did get out of this business: What Java has that Python lacks (follow the link) is a way to "interrupt" a thread, and there's nothing that was possible with thread.stop() that isn't possible by building on interruption (although the places where people really want this are places where thread.stop() never worked anyway -- Java never had a gimmick as Draconian as Win32's TerminateThread() -- Java's thread.stop() was "stop if you can, but there are many reasons you may not be able to"). I'd be +1 on a thread interruption facility for Python, which amounts to a way to raise an exception in a different thread. But like Java's facility, it couldn't always guarantee the target thread would respond. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:27 Message: Logged In: YES user_id=6380 Assigned to Tim for review of the Windows code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:01 Message: Logged In: YES user_id=6380 I'm +0 with this, so it can go in if people really want it. (Though isn't this deprecated in Java?) The patch looks very thorough. Some concerns: - Patches for Doc/lib/libthread.tex (don't have to be perfect LaTeX, but must document new functionality). - For other OS thread implementations (e.g. pth, solaris, beos, os2) the thread ID returned by the thread module is always zero. - Some pthread implementations seem to have an issue that the thread-id as we calculate it is not necessarily unique, due to the opaqueness of the pthread_t structure. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470 From noreply@sourceforge.net Tue Oct 16 21:22:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Oct 2001 13:22:27 -0700 Subject: [Patches] [ python-Patches-448305 ] Additions to the C API Message-ID: Patches item #448305, was opened at 2001-08-05 19:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448305&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: Later >Priority: 3 Submitted By: Frederic Giacometti (giacometti) Assigned to: Guido van Rossum (gvanrossum) Summary: Additions to the C API Initial Comment: I'm not sure a PEP is required for this patch, but these functions are pre-requisiste for two other PEP in the pipe... I have not always had easy access to news posting, so I'll be the happier this can go through without all the PEP overhead, otherwise, I'll try to follow up the PEP. I'm submitting this as a PEP in the same time, to the Director of PEP Affairs, as indicated in the PEP meta PEP 000 (barry), with a reference to this patch (file attached). Frederic Giacometti --------------------------- PEP XXX: Additions to the C API fred@arakne.com (Frederic Giacometti) Abstract This PEP defines a couple of C functions. The first two functions are for raising exceptions with multiple arguments; the third one is for calling a method when an arg tuple is given; and the other ones programmatically define sys.path and the optimization level in embedded python context, before initialization of the global Python engine. Copyright: This document is published under the Open Publication License. Specification: PyObject* PyErr_RaiseArgs( PyObject* exctype, PyObject* args) Raise the exception created by applying args to exctype. This is equivalent to the Python expression raise apply( exctype, args). Always set the error state and return NULL. PyObject* PyErr_Raise( PyObject* exctype, char const* format, ...) This function is similar to PyErr_RaiseArgs(), but defines the arguments using the same convention as Py_BuildValue(). Always set the error state and return NULL. PyObject* PyObject_CallMethodArgs( PyObject* o, char const* method, PyObject* args) Call the method named 'method' with arguments given by the tuple args, using for args the same convention as PyObject_CallObject(). This is the equivalent of the Python expression o.method( args). Note that special method names, such as __add__(), __getitem__(), and so on are not supported. The specific abstract-object routines for these must be used. void Py_SetPythonPath( char const* path) This function should be called before Py_Initialize() is called for the first time, if it is called at all. It defines the PYTHONPATH value to be used by the interpreter. Calling Py_SetPythonPath() will override the PYTHONPATH value from the environment. The argument should be NULL, or point to a zero-terminated character string which will not change for the duration of the program's execution. char const* Py_GetPythonPath() If Py_SetPythonPath() was never called, getenv( "PYTHONPATH") is returned, otherwise the argument of Py_SetPythonPath() is returned. The returned string points into static storage. void Py_SetOptimizeLevel( int level) This function should be called before Py_Initialize() is called for the first time. Legal optimization levels are listed below. \begin{tableii}{c|l}{character}{Character}{Meaning} \lineii{0}{No optimization (use \code{.pyc} files by default)} \lineii{1}{Same as \code{python -O}} \lineii{2}{Same as \code{python -OO}} \end{tableii} int Py_GetOptimizeLevel() Return the interpreter optimization level. Reference Implementation: See attached patch (concatenation of 2 patch files). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-16 13:22 Message: Logged In: YES user_id=6380 lowering the priority -- Frederic hasn't replied in two weeks. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-27 11:29 Message: Logged In: YES user_id=6380 Reopened - this patch looks chaotic, but I think all pieces are actually there. Feedback: General: it would have been better to submit separate patches for each feature. I also wish you would upload a fixed patch rather than include patches in comments. PyError_RaiseArgs - This doesn't differ enough from PyErr_SetObject, if it differs at all -- it just instantiates the exception earlier. I don't think that the PyErr_Raise* API provides sufficient added benefits to warrant deprecating the old calls. Also, it's a *feature* that the exception isn't instantiated right away -- this saves time when it is caught and thrown away in C code later, as often happens. PyError_Raise - this may be useful, we're just considering something like this. PyErr_SetPythonPath, Py_GetPythonPath - why can't you just use setenv()? Py_Set/GetOptimizeLevel - IMO these are not needed, you can just set the global variable Py_OptimizeFlag yourself. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-25 15:07 Message: Logged In: YES user_id=93657 Too bad Guido gets personal here against me. This was certainly a very reasonable and pertinent patch, without anything in it than its intent. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-25 06:30 Message: Logged In: YES user_id=6380 Given Frederic's attitude elsewhere, I'm closing this; it's unlikely that we'll ever get a reasonable patch. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-14 15:32 Message: Logged In: YES user_id=12800 It's not clear to me that adding a couple of C API functions requires a PEP. I'm assigning to Guido for BDFL pronouncement. Guido should probably also decide on the patches themselves. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-08-09 15:36 Message: Logged In: YES user_id=93657 A) Direct code replacement. Here is a non-exhaustive list of occurences: pythonrun.c-2.1:1242 w = Py_BuildValue("(sO)", msg, v); Py_XDECREF(v); PyErr_SetObject(errtype, w); Py_XDECREF(w); --> PyErr_Raise( errtype, "sO", msg, v); Py_XDECREF( v); errors.c:towards 303 and 350: if (filename != NULL) v = Py_BuildValue("(iss)", err, s, filename); else v = Py_BuildValue("(is)", err, s); if (v != NULL) { PyErr_SetObject(PyExc_WindowsError, v); Py_DECREF(v); --> if (filename) PyErr_Raise( Pyexc_WindowsError, "iss", err, s, filename) else PyErr_Raise( ..., "is", err, s); compile.c: 421 w = Py_BuildValue("(OO)", v, t); if (w == NULL) goto exit; PyErr_SetObject(exc, w); --> PyErr_Raise( exc, "OO", v, t) Modules/socketmodules.c:361 v = Py_BuildValue("(is)", myerrorcode, outbuf); if (v != NULL) { PyErr_SetObject(PySocket_Error, v); Py_DECREF(v); } return NULL; --> return PyErr_Raise( PySocketError, "is", myerrorcode, outbuf); posixmodule.c:441 v = Py_BuildValue("(is)", code, text); if (v != NULL) { PyErr_SetObject(PyExc_OSError, v); Py_DECREF(v); } return NULL; /* Signal to Python that an Exception is Pending */ --> return PyErr_Raise( PyExc_OSError, "is", code, text); ..... B) Other use of PyErr_Raise* in the current code base: ---------------------------------------------- As of today, there are 3 functions for raising a new exception: - PyErr_SetString (1118 occurences) - PyErr_Format (158 occurences) - PyErr_SetObject (48 occurences) PyErr_Raise( exctype, "O", obj) would replace PyErr_SetObject( exctype, obj) PyErr_Raise( exctype, "s", msg) would replace PyErr_SetString( exctype, msg) PyErr_SetObject and PyErr_SetString could then both be deprecated, in cases the arg is not already an instance of the exception... Here is some explaination: Historically, Python was first working with string exceptions, only. Structured object-oriented exceptions were introduced only towards the 1.5 releases, I think (very approximately - I've only used python 1.5.1 or later...). It is not also also how the current API works with exception whose __init__ require more than two args, and process them. If you want to raise an exception with an __init__ that has to or more args, there is presently no clear way of doing it; this is where i created the PyErr_Raise* functions. There is also the case where one would define an exception which does not accept a string object as __init__ argument... PyErr_SetString would create problem there too. Furthermore, the exact semantics and workings of PyErr_Object are not clear, with regard to the type of the object passed (this is fine when the object is already an instance of the exception class, but when it is not an instance of the exception class, huum). Use of PyErr_Raise would clarify this... ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-08-09 14:37 Message: Logged In: YES user_id=93657 1) Patch for PyErr_Raise: I manually edited the patch file, since I had the ImportNotFound changes with it. The entire patch is in cdiff file attached to http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448488&group_id=5470 Meanwhile, I'm pasting below the missing section. 2) I'm going to make a quick search on the existing base for replacement opportunities. 3) CallMethodArgs vs. CallMethodArgs with keywords: The main reason is that the implementation relies on the exsiting PyObject_CallObject function, with does not take keyword args... However, your remark is relevant, and two other functions would be needed to complete the call interface: PyObject_CallObjectWithKW and PyObject_CallMethodArgsWithKW... I'd say that use of keyword arg from the C API is unusual; since I've never needed them, I haven't implemented them... Index: Python/errors.c =================================================================== RCS file: /cvs/python/Python/Python/errors.c,v retrieving revision 1.1.1.1 diff -c -r1.1.1.1 errors.c *** Python/errors.c 2001/05/27 15:36:36 1.1.1.1 --- Python/errors.c 2001/06/05 16:11:16 *************** *** 514,519 **** --- 514,571 ---- } + PyObject* PyErr_RaiseArgs( PyObject* exctype, PyObject* args) + { + PyObject* exception; + exception = PyObject_CallObject( exctype, args); + if (! exception) return NULL; + PyErr_SetObject( exctype, exception); + return NULL; + } + + PyObject* PyErr_Raise( PyObject* exctype, char const* format, ...) + { + PyObject* args = NULL, *result = NULL; + va_list va; + + va_start( va, format); + args = format ? Py_VaBuildValue( (char*)format, va) : PyTuple_New(0); + va_end(va); + + if (! args) goto Finally; + if (! PyTuple_Check( args)) { + PyObject* newargs; + newargs = PyTuple_New( 1); + if (! newargs) goto Finally; + PyTuple_SET_ITEM( newargs, 0, args); + args = newargs; + } + + result = PyErr_RaiseArgs( exctype, args); + Finally: + Py_XDECREF(args); + return result; + } + PyObject * PyErr_NewException(char *name, PyObject *base, PyObject *dict) { ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-07 22:16 Message: Logged In: YES user_id=21627 It seems that your patch is somewhat confused: It contains fragments of the SetPythonPath code, but fails to include the implementation of PyErr_Raise[Args]. I think the patch should also identify the places in the code that could make use of the offered simplifications (and change them to the new API), to get an impression of how general this API is. I'm +1 on the _Raise functions and -0 on the CallMethodArgs (why does it not support keyword arguments?). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448305&group_id=5470 From noreply@sourceforge.net Tue Oct 16 21:33:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Oct 2001 13:33:10 -0700 Subject: [Patches] [ python-Patches-452266 ] thread.kill_thread Message-ID: Patches item #452266, was opened at 2001-08-17 17:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: Later Priority: 3 Submitted By: Jason Petrone (jpetrone) Assigned to: Guido van Rossum (gvanrossum) Summary: thread.kill_thread Initial Comment: Function to unsafely kill a thread. Implementations are included for posix and nt. If what I have looks reasonable I will add other platforms + docs. I've read Guido's usenet posts on this and understand the reasons against it, but I still think it might be worth having. Thread implementations like the ones in Java and win32 allow it with the caveat that it could result in deadlock, corrupted data, unclaimed resources, bodily harm, etc. Note that it also changes start_new_thread to return the id for the new thread. ---------------------------------------------------------------------- >Comment By: Jason Petrone (jpetrone) Date: 2001-10-16 13:33 Message: Logged In: YES user_id=71210 I agree, throwing an exception is the only Right Way to do it. Throwing it in Python code isn't really that useful, its when a thread is IO blocked that it is really important. I know how to do this with pthreads, but I don't know any way to do it under windows. The vast majority of the patch was to return the thread id from start_new_thread, so if that goes in I didn't really waste any time on this. Besides, I finally broke down and converted the socket code that inspired me to write this to non-blocking IO anyway. Its ugly, but at least its safe. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-16 13:18 Message: Logged In: YES user_id=6380 I'm tempted to just close this now, but I'll leave it open to see if others have any comments. Basically, the only thread kill that I fell comfortable with would be one that raises an exception. This is easy if the thread is executing Python bytecodes: just check a global flag every once in a while. But the interesting part is when the thread is blocked in something like a socket recv() call, and there the only way to kill it on Unix is to send a signal to the thread -- and on Windows I don't know how to do it. In addition, I've just applied a patch that turns off signals in threads other than the main thread, because in general Python doesn't like signals being delivered to other threads. I'm sorry, Jason -- you did a decent amount of research on this one, but still more is required... ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-19 10:52 Message: Logged In: YES user_id=21627 One note on killing threads: Part of working "safely" would be that any reference to objects that the thread currently holds is released when the thread is killed. That essentially requires that all C stack frames perform the appropriate Py_DECREFs, which is not feasible through the thread kill mechanisms of the thread libraries (AFAIK). Instead, a Python exception is about the only approach that has a chance of working "safely". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-22 01:21 Message: Logged In: YES user_id=6380 Sending SIGINT may be easy, but that only covers the Unix side. Also, catching it requires more work, interfering with the existing signal handling, so this becomes A Project. (So, yes, the hard part is getting Python to process signals out of the main thread.) Thanks for the new patch! This is a step in the right direction. It came too late to be reviewed for 2.2a2, but I'll try to get it into 2.2a3. ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-08-20 21:21 Message: Logged In: YES user_id=71210 Sending SIGINT to a thread is pretty easy. Is the hard part of killing a thread with signals getting python to process signals outside of the main thread? At any rate, I'm attaching a new patch that returns the thread id from start_new_thread, without any of the kill_thread() stuff. It includes a change to libthread.tex. For platforms I don't really know I just had them return -1 on failure and 0 on success so they at least run. o Solaris, pthreads, pth - returns thread id, tested o NT - returns thread id, (should work, haven't tested after removing kill) o SGI, BeOS - returns thread id, untested o wince, OS/2, LWP, cthread, foobar - returns -1 on failure, 0 on success ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-20 06:01 Message: Logged In: YES user_id=6380 Thanks to Tim for jogging my memory. I think an interruption facility should be a way to send an exception to a thread, similar to KeyboardInterrupt -- the thread can then decide what to do (and since exceptions can happen anyway, the safety guarantee is not violated -- if the application doesn't release locks on exceptions, it is already unsafe). One problem is that it's probably most important to be able to stop a thread while it's blocked for I/O (a socket connect() or recv() from a non-responding host is a typical example). Unfortunately, the only way to do that on Unix is to send a real signal to the thread. On Windows, I have no idea. Note that part of this patch would still be useful: start_new_thread() should return a thread-id. ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-08-19 20:21 Message: Logged In: YES user_id=71210 While I would very much like to have full interruption functionality, I'm not sure how easily it could be done on all platforms. At the least it would be nice to have SOME sort of thread signalling. What guarantees about safety should python make? I've considered trying to add cleanup handlers to release interpreter locks and such, but didn't feel like putting that much effort into a patch that would likely be rejected anyway. I will look into adding cleanup routines if we can establish some requirements. I think I can do it in pthreads pretty easily. Dunno how easy the rest will be. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-19 14:24 Message: Logged In: YES user_id=31435 I've never called TerminateThread() on Win32, and given the dire wngs about it in the MS docs, never will. IMO Python shouldn't be in this business unless it can guarantee to do it safely. But it can't, so -1 from me. Java did get out of this business: What Java has that Python lacks (follow the link) is a way to "interrupt" a thread, and there's nothing that was possible with thread.stop() that isn't possible by building on interruption (although the places where people really want this are places where thread.stop() never worked anyway -- Java never had a gimmick as Draconian as Win32's TerminateThread() -- Java's thread.stop() was "stop if you can, but there are many reasons you may not be able to"). I'd be +1 on a thread interruption facility for Python, which amounts to a way to raise an exception in a different thread. But like Java's facility, it couldn't always guarantee the target thread would respond. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:27 Message: Logged In: YES user_id=6380 Assigned to Tim for review of the Windows code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:01 Message: Logged In: YES user_id=6380 I'm +0 with this, so it can go in if people really want it. (Though isn't this deprecated in Java?) The patch looks very thorough. Some concerns: - Patches for Doc/lib/libthread.tex (don't have to be perfect LaTeX, but must document new functionality). - For other OS thread implementations (e.g. pth, solaris, beos, os2) the thread ID returned by the thread module is always zero. - Some pthread implementations seem to have an issue that the thread-id as we calculate it is not necessarily unique, due to the opaqueness of the pthread_t structure. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470 From noreply@sourceforge.net Tue Oct 16 21:35:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Oct 2001 13:35:38 -0700 Subject: [Patches] [ python-Patches-424475 ] Speed-up tp_compare usage Message-ID: Patches item #424475, was opened at 2001-05-16 01:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424475&group_id=5470 Category: Core (C code) Group: None Status: Open >Resolution: Remind Priority: 5 Submitted By: Martin v. Lцwis (loewis) Assigned to: Guido van Rossum (gvanrossum) Summary: Speed-up tp_compare usage Initial Comment: This patch tries to optimize PyObject_RichCompare for the common case of objects with equal types which support tp_compare. It gives a speed-up of roughly 7% for comparing strings in a loop. The patch also gives type objects a tp_compare function, so that they can make use of the improvement. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-16 13:35 Message: Logged In: YES user_id=6380 I've applied the recommended doc change. Reminder: in 2.3, we should actually check the return value of tp_compare and reject values outside [-1, 1]. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-16 02:58 Message: Logged In: YES user_id=21627 The instance-tp-compare-is-special assumption was introduced with rich comparisons. Currently, it is nowhere specified that tp_compare *must* return -1/0/1, so for other types, 2 may well mean "one is larger than the other". In fact, in Py 2.1, string_compare would return Py_CHARMASK(*a->ob_sval) - Py_CHARMASK(*b->ob_sval) if the first two letters of the string were different. It is probably ok to tighten this up, but in a phased manner: First (in 2.2), document that the return type really is {-1,0,1}; then (in 2.3) extend the documentation to cover +2 as well, and perhaps even -2 (exception). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-16 01:05 Message: Logged In: YES user_id=6380 Thanks for the quick fix. I'll check it in, because I want to commit some other changes to the same file. I still feel uneasy about the PyInstance_Check(). Shouldn't all types be allowed to return 2 from their tp_compare slot? (In general, the type/class unification makes me feel uneasy with *any* PyInstance_Check() special cases.) ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-16 00:43 Message: Logged In: YES user_id=21627 It appears that do_cmp does not take into account the special calling semantics of tp_compare for instances. The attached cmp.diff fixes this case. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-15 13:51 Message: Logged In: YES user_id=6380 I have to reopen this, because I've encountered a bug (I think). Take a trivial class: class C: pass and compare two instances of it: cmp(C(), C()) In Python 2.1.1 and before, this returned the same as cmp(id(C()), id(C())) but currently it always returns the value 2! This 2 is supposed to be an internal value that should never be returned. I am not 100% sure that it is this patch that's at fault, but I selectively rolled the object.c part of this patch back, and then it started doing the right thing again. I'm going to check in a test that verifies the correct behavior. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-06-09 00:40 Message: Logged In: YES user_id=21627 Committed as object.c 2.132, typeobject.c 2.17, UserList.py 1.17. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-06-07 13:19 Message: Logged In: YES user_id=31435 Accepted and assigned back to Martin. This is too valuable to quibble over. Note that when calling a tp_compare slot, this kind of thing: . c = (*f)(v, w); . if (PyErr_Occurred()) is better spelled: . c = (*f)(v, w); . if (c < 0 && Py_Err_Occurred()) ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-05-21 09:57 Message: Logged In: YES user_id=21627 The revised patch prefers tp_compare over tp_richcompare in do_cmp if both are available. It also restores UserList.__cmp__ from deprecation. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424475&group_id=5470 From noreply@sourceforge.net Tue Oct 16 21:35:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Oct 2001 13:35:47 -0700 Subject: [Patches] [ python-Patches-424475 ] Speed-up tp_compare usage Message-ID: Patches item #424475, was opened at 2001-05-16 01:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424475&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: Remind >Priority: 3 Submitted By: Martin v. Lцwis (loewis) Assigned to: Guido van Rossum (gvanrossum) Summary: Speed-up tp_compare usage Initial Comment: This patch tries to optimize PyObject_RichCompare for the common case of objects with equal types which support tp_compare. It gives a speed-up of roughly 7% for comparing strings in a loop. The patch also gives type objects a tp_compare function, so that they can make use of the improvement. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-16 13:35 Message: Logged In: YES user_id=6380 I've applied the recommended doc change. Reminder: in 2.3, we should actually check the return value of tp_compare and reject values outside [-1, 1]. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-16 02:58 Message: Logged In: YES user_id=21627 The instance-tp-compare-is-special assumption was introduced with rich comparisons. Currently, it is nowhere specified that tp_compare *must* return -1/0/1, so for other types, 2 may well mean "one is larger than the other". In fact, in Py 2.1, string_compare would return Py_CHARMASK(*a->ob_sval) - Py_CHARMASK(*b->ob_sval) if the first two letters of the string were different. It is probably ok to tighten this up, but in a phased manner: First (in 2.2), document that the return type really is {-1,0,1}; then (in 2.3) extend the documentation to cover +2 as well, and perhaps even -2 (exception). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-16 01:05 Message: Logged In: YES user_id=6380 Thanks for the quick fix. I'll check it in, because I want to commit some other changes to the same file. I still feel uneasy about the PyInstance_Check(). Shouldn't all types be allowed to return 2 from their tp_compare slot? (In general, the type/class unification makes me feel uneasy with *any* PyInstance_Check() special cases.) ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-16 00:43 Message: Logged In: YES user_id=21627 It appears that do_cmp does not take into account the special calling semantics of tp_compare for instances. The attached cmp.diff fixes this case. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-15 13:51 Message: Logged In: YES user_id=6380 I have to reopen this, because I've encountered a bug (I think). Take a trivial class: class C: pass and compare two instances of it: cmp(C(), C()) In Python 2.1.1 and before, this returned the same as cmp(id(C()), id(C())) but currently it always returns the value 2! This 2 is supposed to be an internal value that should never be returned. I am not 100% sure that it is this patch that's at fault, but I selectively rolled the object.c part of this patch back, and then it started doing the right thing again. I'm going to check in a test that verifies the correct behavior. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-06-09 00:40 Message: Logged In: YES user_id=21627 Committed as object.c 2.132, typeobject.c 2.17, UserList.py 1.17. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-06-07 13:19 Message: Logged In: YES user_id=31435 Accepted and assigned back to Martin. This is too valuable to quibble over. Note that when calling a tp_compare slot, this kind of thing: . c = (*f)(v, w); . if (PyErr_Occurred()) is better spelled: . c = (*f)(v, w); . if (c < 0 && Py_Err_Occurred()) ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-05-21 09:57 Message: Logged In: YES user_id=21627 The revised patch prefers tp_compare over tp_richcompare in do_cmp if both are available. It also restores UserList.__cmp__ from deprecation. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424475&group_id=5470 From noreply@sourceforge.net Tue Oct 16 21:36:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Oct 2001 13:36:21 -0700 Subject: [Patches] [ python-Patches-410471 ] linuxaudiodev lacks Py_BEGIN/END_THREAD Message-ID: Patches item #410471, was opened at 2001-03-21 22:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410471&group_id=5470 Category: Modules Group: None >Status: Closed Resolution: Out of Date Priority: 3 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: linuxaudiodev lacks Py_BEGIN/END_THREAD Initial Comment: The system calls in the linuxaudiodev module need to be wrapped with: Py_BEGIN_ALLOW_THREADS Py_END_ALLOW_THREADS so that audio I/O can occur async/multithreaded. I'm including a patch to fix this, for Python 2.0. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-16 13:36 Message: Logged In: YES user_id=6380 CLosed without prejudice. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 09:29 Message: Logged In: YES user_id=6380 I tried applying this patch but it got several failed hunks -- no surprise since it was for Python 2.0. I'll leave it open for another month (until 9 Sept 2001) and if someone hasn't provided a patch that works with current CVS by then, I'll close it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 08:23 Message: Logged In: YES user_id=6380 Good catch. I hesitate to fix this so close to the 2.1 release. I've also recategorized it as a patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410471&group_id=5470 From noreply@sourceforge.net Tue Oct 16 21:36:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Oct 2001 13:36:44 -0700 Subject: [Patches] [ python-Patches-413087 ] support for Borland C++ compiler Message-ID: Patches item #413087, was opened at 2001-04-02 03:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413087&group_id=5470 Category: Build Group: None >Status: Closed Resolution: Out of Date Priority: 3 Submitted By: janez jere (janezj) Assigned to: Guido van Rossum (gvanrossum) Summary: support for Borland C++ compiler Initial Comment: Some minor changes are required to compile source with BCB 5. If patch will be accepted I will submit ky script, (written in a popular scripting language) which produces makefiles. Patch is not so elegant as it should be, because config.h is not used as it should be, just see the mess in posixmodule.c. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-16 13:36 Message: Logged In: YES user_id=6380 Closed without prejudice. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 09:30 Message: Logged In: YES user_id=6380 I'm still waiting for a patch in context diff format. The submitter has until Sept. 9, 2001 to provide a new patch. If I see no action then, I'll close and reject it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:34 Message: Logged In: YES user_id=6380 I'm sorry, we don't accept plain diffs any more, certainly not for this much code. Can you please submit a context diff? I've a feeling that this might be applied for Python 2.1 if it doesn't break any code -- the changes seem simple enough. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413087&group_id=5470 From noreply@sourceforge.net Tue Oct 16 21:38:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Oct 2001 13:38:22 -0700 Subject: [Patches] [ python-Patches-471852 ] getattr with default catches too much Message-ID: Patches item #471852, was opened at 2001-10-16 13:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471852&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: getattr with default catches too much Initial Comment: getattr.__doc__ sez: ''' getattr(object, name[, default]) -> value Get a named attribute from an object; getattr(x, 'y') is equivalent to x.y. When a default argument is given, it is returned when the attribute doesn't exist; without it, an exception is raised in that case. ''' What really happens is that, when given a default, getattr catches *all* exceptions. In addition to the generally poor practice of silently catching all exceptions, the documentation implies that only AttributeError is caught. I think getattr should be changed to catch only AttributeError, and the documentation changed to: ''' Get a named attribute from an object. getattr(x, 'y') is equivalent to x.y. When a default argument is given, it is returned when 'x' raises an AttributeError. ''' If the patch is rejected, I suggest the docstring be changed to: ''' Get a named attribute from an object. getattr(x, 'y') is equivalent to x.y. If getattr is given a default and 'x' raises an exception, it will catch the exception and return the default. Note that any exception will be caught, not just AttributeError, which can hide bugs if 'x' is a class with a __getattr__ method. ''' *** Python/bltinmodule.c Tue Oct 16 13:14:54 2001 --- Python/bltinmodule.c.old Tue Oct 16 13:14:49 2001 *************** *** 619,627 **** return NULL; } result = PyObject_GetAttr(v, name); ! if (result == NULL && dflt != NULL ! && PyErr_ExceptionMatches(PyExc_AttributeError)) ! { PyErr_Clear(); Py_INCREF(dflt); result = dflt; --- 619,625 ---- return NULL; } result = PyObject_GetAttr(v, name); ! if (result == NULL && dflt != NULL) { PyErr_Clear(); Py_INCREF(dflt); result = dflt; ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471852&group_id=5470 From noreply@sourceforge.net Tue Oct 16 21:41:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Oct 2001 13:41:08 -0700 Subject: [Patches] [ python-Patches-403753 ] zlib decompress; uncontrollable memory usage Message-ID: Patches item #403753, was opened at 2001-02-12 08:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403753&group_id=5470 Category: Modules Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Toby Dickenson (htrd) Assigned to: Jeremy Hylton (jhylton) Summary: zlib decompress; uncontrollable memory usage Initial Comment: zlib's decompress method will allocate as much memory as is needed to hold the decompressed output. The length of the output buffer may be very much larger than the length of the input buffer, and the python code calling the decompress method has no other way to control how much memory is allocated. In experimentation, I seen decompress generate output that is 1000 times larger than its input These characteristics may make the decompress method unsuitable for handling data obtained from untrusted sources (for example, in a http proxy which implements gzip encoding) since it may be vulnerable to a denial of service attack. A malicious user could construct a moderately sized input which forces 'decompress' to try to allocate too much memory. This patch adds a new method, decompress_incremental, which allows the caller to specify the maximum size of the output. This method returns the excess input, in addition to the decompressed output. It is possible to solve this problem without a patch: If input is fed to the decompressor a few tens of bytes at a time, memory usage will surge by (at most) a few tens of kilobytes. Such a process is a kludge, and much less efficient that the approach used in this patch. (Ive not been able to test the documentation patch; I hope its ok) (This patch also includes the change from Patch #103748) ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-10-16 13:41 Message: Logged In: YES user_id=31392 Committed with mods as libzlib.tex 1.27 test_zlib.py 1.15 test_zlib 1.5 zlibmodule.c 2.44 ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-10-16 13:15 Message: Logged In: YES user_id=31392 Indeed, looks like a good feature. Patch is fine with a few little changes. I'll check it in. ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-09-25 02:44 Message: Logged In: YES user_id=46460 The patch from titus (added by loewis) looks good ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-09-25 02:43 Message: Logged In: YES user_id=46460 The patch from titus (added by loewis) looks good ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-09-25 02:41 Message: Logged In: YES user_id=46460 The patch from titus (added by loewis) looks good ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-09-24 23:42 Message: Logged In: YES user_id=23486 I have integrated this patch into the latest Python CVS tree, with a few additional modifications. * added spaces into the documentation patch & verified that doc building works; * fixed problem where the 'unconsumed_tail' attribute returned was *actually* the unused_data attribute; this was caused by indiscriminate cutting & pasting ;). * put in a few additional comments and fixed the code for 80 cols. It doesn't look like I can submit an attachment with this comment (?); I will e-mail it to both loewis & htrd. ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-09-10 07:18 Message: Logged In: YES user_id=46460 I volunteer to update it ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-07 10:03 Message: Logged In: YES user_id=21627 Since this patch has been sitting around for such a long time, it eventually got outdated, due to the conflicting MT patch. Any volunteers to update it? ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-06-04 13:55 Message: Logged In: YES user_id=21627 The patch looks good to me; I recommend to approve it. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-04-10 10:52 Message: Logged In: YES user_id=11375 I've let this patch gather dust long enough. Unassigning so that someone else can review it. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2001-04-07 00:20 Message: Logged In: YES user_id=413 as a side note. I believe I implemented a python workaround for this problem by just decompressing data in small chunks (4k at a time) using a decompressor object. see the mojonation project on sourceforge if you're curious. (specifically, in the mojonation evil module, look at common/mojoutil.py for function named safe_zlib_decompress). Regardless, I like thie idea of this patch. It would be good to have that in the main API and documentation for simplicity. (and because there are too many programmers out there who don't realize potential denial of service issues on their own...) ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-02-22 04:50 Message: New patch implementing a new optional parameter to .decompress, and a new attribute .unconsumed_tail ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-02-22 03:42 Message: Waaah - that last comment should be 'cant' not 'can' ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-02-22 03:40 Message: We can reuse .unused_data without introducing an ambiguity. I will prepare a patch that uses a new attribute .unconsumed_tail ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-02-21 11:32 Message: Doesn't .unused_data serve much the same purpose, though? So that even with a maximum size, .decompress() always returns a string, and .unused_data would contain the unprocessed data. ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-02-21 06:00 Message: I did consider that.... An extra change that you didnt mention is the need for a different return value. Currently .decompress() always returns a string. The new method in my patch returns a tuple containing the same string, and an integer specifying how many bytes were consumed from the input. Overloading return values based on an optional parameter seems a little hairy to me, but I would be happy to change the patch if that is your preferred option. I also considered (and rejected) the possibility of adding an optional max-size argument to .decompress() as you suggest, but raising an exception if this limit is exceeded. This avoids the need for an extra return value, but looses out on flexibility. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-02-20 18:48 Message: Rather than introducing a new method, why not just add an optional maxlen argument to .decompress(). I think the changes would be: * add 'int maxlen=-1;' * add "...|i" ... ,&maxlen to the argument parsing * if maxlen != -1, length = maxlen else length = DEFAULTALLOC; * Add '&& maxlen==-1' to the while loop. (Use the current CVS; I just checked in a patch rearranging the zlib module a bit.) Do you want to make those changes and resubmit the patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403753&group_id=5470 From noreply@sourceforge.net Tue Oct 16 22:14:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Oct 2001 14:14:15 -0700 Subject: [Patches] [ python-Patches-452266 ] thread.kill_thread Message-ID: Patches item #452266, was opened at 2001-08-17 17:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: Later Priority: 3 Submitted By: Jason Petrone (jpetrone) Assigned to: Guido van Rossum (gvanrossum) Summary: thread.kill_thread Initial Comment: Function to unsafely kill a thread. Implementations are included for posix and nt. If what I have looks reasonable I will add other platforms + docs. I've read Guido's usenet posts on this and understand the reasons against it, but I still think it might be worth having. Thread implementations like the ones in Java and win32 allow it with the caveat that it could result in deadlock, corrupted data, unclaimed resources, bodily harm, etc. Note that it also changes start_new_thread to return the id for the new thread. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-16 14:14 Message: Logged In: YES user_id=6380 OK, I've checked in the patch to return the thread ID, in time for beta 1. We'll see how it goes! (I noticed some platforms don't calculate a thread ID but return 0 -- won't this be a problem?) ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-10-16 13:33 Message: Logged In: YES user_id=71210 I agree, throwing an exception is the only Right Way to do it. Throwing it in Python code isn't really that useful, its when a thread is IO blocked that it is really important. I know how to do this with pthreads, but I don't know any way to do it under windows. The vast majority of the patch was to return the thread id from start_new_thread, so if that goes in I didn't really waste any time on this. Besides, I finally broke down and converted the socket code that inspired me to write this to non-blocking IO anyway. Its ugly, but at least its safe. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-16 13:18 Message: Logged In: YES user_id=6380 I'm tempted to just close this now, but I'll leave it open to see if others have any comments. Basically, the only thread kill that I fell comfortable with would be one that raises an exception. This is easy if the thread is executing Python bytecodes: just check a global flag every once in a while. But the interesting part is when the thread is blocked in something like a socket recv() call, and there the only way to kill it on Unix is to send a signal to the thread -- and on Windows I don't know how to do it. In addition, I've just applied a patch that turns off signals in threads other than the main thread, because in general Python doesn't like signals being delivered to other threads. I'm sorry, Jason -- you did a decent amount of research on this one, but still more is required... ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-19 10:52 Message: Logged In: YES user_id=21627 One note on killing threads: Part of working "safely" would be that any reference to objects that the thread currently holds is released when the thread is killed. That essentially requires that all C stack frames perform the appropriate Py_DECREFs, which is not feasible through the thread kill mechanisms of the thread libraries (AFAIK). Instead, a Python exception is about the only approach that has a chance of working "safely". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-22 01:21 Message: Logged In: YES user_id=6380 Sending SIGINT may be easy, but that only covers the Unix side. Also, catching it requires more work, interfering with the existing signal handling, so this becomes A Project. (So, yes, the hard part is getting Python to process signals out of the main thread.) Thanks for the new patch! This is a step in the right direction. It came too late to be reviewed for 2.2a2, but I'll try to get it into 2.2a3. ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-08-20 21:21 Message: Logged In: YES user_id=71210 Sending SIGINT to a thread is pretty easy. Is the hard part of killing a thread with signals getting python to process signals outside of the main thread? At any rate, I'm attaching a new patch that returns the thread id from start_new_thread, without any of the kill_thread() stuff. It includes a change to libthread.tex. For platforms I don't really know I just had them return -1 on failure and 0 on success so they at least run. o Solaris, pthreads, pth - returns thread id, tested o NT - returns thread id, (should work, haven't tested after removing kill) o SGI, BeOS - returns thread id, untested o wince, OS/2, LWP, cthread, foobar - returns -1 on failure, 0 on success ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-20 06:01 Message: Logged In: YES user_id=6380 Thanks to Tim for jogging my memory. I think an interruption facility should be a way to send an exception to a thread, similar to KeyboardInterrupt -- the thread can then decide what to do (and since exceptions can happen anyway, the safety guarantee is not violated -- if the application doesn't release locks on exceptions, it is already unsafe). One problem is that it's probably most important to be able to stop a thread while it's blocked for I/O (a socket connect() or recv() from a non-responding host is a typical example). Unfortunately, the only way to do that on Unix is to send a real signal to the thread. On Windows, I have no idea. Note that part of this patch would still be useful: start_new_thread() should return a thread-id. ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-08-19 20:21 Message: Logged In: YES user_id=71210 While I would very much like to have full interruption functionality, I'm not sure how easily it could be done on all platforms. At the least it would be nice to have SOME sort of thread signalling. What guarantees about safety should python make? I've considered trying to add cleanup handlers to release interpreter locks and such, but didn't feel like putting that much effort into a patch that would likely be rejected anyway. I will look into adding cleanup routines if we can establish some requirements. I think I can do it in pthreads pretty easily. Dunno how easy the rest will be. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-19 14:24 Message: Logged In: YES user_id=31435 I've never called TerminateThread() on Win32, and given the dire wngs about it in the MS docs, never will. IMO Python shouldn't be in this business unless it can guarantee to do it safely. But it can't, so -1 from me. Java did get out of this business: What Java has that Python lacks (follow the link) is a way to "interrupt" a thread, and there's nothing that was possible with thread.stop() that isn't possible by building on interruption (although the places where people really want this are places where thread.stop() never worked anyway -- Java never had a gimmick as Draconian as Win32's TerminateThread() -- Java's thread.stop() was "stop if you can, but there are many reasons you may not be able to"). I'd be +1 on a thread interruption facility for Python, which amounts to a way to raise an exception in a different thread. But like Java's facility, it couldn't always guarantee the target thread would respond. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:27 Message: Logged In: YES user_id=6380 Assigned to Tim for review of the Windows code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:01 Message: Logged In: YES user_id=6380 I'm +0 with this, so it can go in if people really want it. (Though isn't this deprecated in Java?) The patch looks very thorough. Some concerns: - Patches for Doc/lib/libthread.tex (don't have to be perfect LaTeX, but must document new functionality). - For other OS thread implementations (e.g. pth, solaris, beos, os2) the thread ID returned by the thread module is always zero. - Some pthread implementations seem to have an issue that the thread-id as we calculate it is not necessarily unique, due to the opaqueness of the pthread_t structure. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470 From noreply@sourceforge.net Tue Oct 16 22:14:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Oct 2001 14:14:59 -0700 Subject: [Patches] [ python-Patches-452266 ] thread.kill_thread Message-ID: Patches item #452266, was opened at 2001-08-17 17:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470 Category: Core (C code) Group: None >Status: Closed Resolution: Later Priority: 3 Submitted By: Jason Petrone (jpetrone) Assigned to: Guido van Rossum (gvanrossum) Summary: thread.kill_thread Initial Comment: Function to unsafely kill a thread. Implementations are included for posix and nt. If what I have looks reasonable I will add other platforms + docs. I've read Guido's usenet posts on this and understand the reasons against it, but I still think it might be worth having. Thread implementations like the ones in Java and win32 allow it with the caveat that it could result in deadlock, corrupted data, unclaimed resources, bodily harm, etc. Note that it also changes start_new_thread to return the id for the new thread. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-16 14:14 Message: Logged In: YES user_id=6380 PS please open a new patch when you have something -- this patch is full. I'm closing it now. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-16 14:14 Message: Logged In: YES user_id=6380 OK, I've checked in the patch to return the thread ID, in time for beta 1. We'll see how it goes! (I noticed some platforms don't calculate a thread ID but return 0 -- won't this be a problem?) ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-10-16 13:33 Message: Logged In: YES user_id=71210 I agree, throwing an exception is the only Right Way to do it. Throwing it in Python code isn't really that useful, its when a thread is IO blocked that it is really important. I know how to do this with pthreads, but I don't know any way to do it under windows. The vast majority of the patch was to return the thread id from start_new_thread, so if that goes in I didn't really waste any time on this. Besides, I finally broke down and converted the socket code that inspired me to write this to non-blocking IO anyway. Its ugly, but at least its safe. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-16 13:18 Message: Logged In: YES user_id=6380 I'm tempted to just close this now, but I'll leave it open to see if others have any comments. Basically, the only thread kill that I fell comfortable with would be one that raises an exception. This is easy if the thread is executing Python bytecodes: just check a global flag every once in a while. But the interesting part is when the thread is blocked in something like a socket recv() call, and there the only way to kill it on Unix is to send a signal to the thread -- and on Windows I don't know how to do it. In addition, I've just applied a patch that turns off signals in threads other than the main thread, because in general Python doesn't like signals being delivered to other threads. I'm sorry, Jason -- you did a decent amount of research on this one, but still more is required... ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-19 10:52 Message: Logged In: YES user_id=21627 One note on killing threads: Part of working "safely" would be that any reference to objects that the thread currently holds is released when the thread is killed. That essentially requires that all C stack frames perform the appropriate Py_DECREFs, which is not feasible through the thread kill mechanisms of the thread libraries (AFAIK). Instead, a Python exception is about the only approach that has a chance of working "safely". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-22 01:21 Message: Logged In: YES user_id=6380 Sending SIGINT may be easy, but that only covers the Unix side. Also, catching it requires more work, interfering with the existing signal handling, so this becomes A Project. (So, yes, the hard part is getting Python to process signals out of the main thread.) Thanks for the new patch! This is a step in the right direction. It came too late to be reviewed for 2.2a2, but I'll try to get it into 2.2a3. ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-08-20 21:21 Message: Logged In: YES user_id=71210 Sending SIGINT to a thread is pretty easy. Is the hard part of killing a thread with signals getting python to process signals outside of the main thread? At any rate, I'm attaching a new patch that returns the thread id from start_new_thread, without any of the kill_thread() stuff. It includes a change to libthread.tex. For platforms I don't really know I just had them return -1 on failure and 0 on success so they at least run. o Solaris, pthreads, pth - returns thread id, tested o NT - returns thread id, (should work, haven't tested after removing kill) o SGI, BeOS - returns thread id, untested o wince, OS/2, LWP, cthread, foobar - returns -1 on failure, 0 on success ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-20 06:01 Message: Logged In: YES user_id=6380 Thanks to Tim for jogging my memory. I think an interruption facility should be a way to send an exception to a thread, similar to KeyboardInterrupt -- the thread can then decide what to do (and since exceptions can happen anyway, the safety guarantee is not violated -- if the application doesn't release locks on exceptions, it is already unsafe). One problem is that it's probably most important to be able to stop a thread while it's blocked for I/O (a socket connect() or recv() from a non-responding host is a typical example). Unfortunately, the only way to do that on Unix is to send a real signal to the thread. On Windows, I have no idea. Note that part of this patch would still be useful: start_new_thread() should return a thread-id. ---------------------------------------------------------------------- Comment By: Jason Petrone (jpetrone) Date: 2001-08-19 20:21 Message: Logged In: YES user_id=71210 While I would very much like to have full interruption functionality, I'm not sure how easily it could be done on all platforms. At the least it would be nice to have SOME sort of thread signalling. What guarantees about safety should python make? I've considered trying to add cleanup handlers to release interpreter locks and such, but didn't feel like putting that much effort into a patch that would likely be rejected anyway. I will look into adding cleanup routines if we can establish some requirements. I think I can do it in pthreads pretty easily. Dunno how easy the rest will be. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-19 14:24 Message: Logged In: YES user_id=31435 I've never called TerminateThread() on Win32, and given the dire wngs about it in the MS docs, never will. IMO Python shouldn't be in this business unless it can guarantee to do it safely. But it can't, so -1 from me. Java did get out of this business: What Java has that Python lacks (follow the link) is a way to "interrupt" a thread, and there's nothing that was possible with thread.stop() that isn't possible by building on interruption (although the places where people really want this are places where thread.stop() never worked anyway -- Java never had a gimmick as Draconian as Win32's TerminateThread() -- Java's thread.stop() was "stop if you can, but there are many reasons you may not be able to"). I'd be +1 on a thread interruption facility for Python, which amounts to a way to raise an exception in a different thread. But like Java's facility, it couldn't always guarantee the target thread would respond. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:27 Message: Logged In: YES user_id=6380 Assigned to Tim for review of the Windows code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:01 Message: Logged In: YES user_id=6380 I'm +0 with this, so it can go in if people really want it. (Though isn't this deprecated in Java?) The patch looks very thorough. Some concerns: - Patches for Doc/lib/libthread.tex (don't have to be perfect LaTeX, but must document new functionality). - For other OS thread implementations (e.g. pth, solaris, beos, os2) the thread ID returned by the thread module is always zero. - Some pthread implementations seem to have an issue that the thread-id as we calculate it is not necessarily unique, due to the opaqueness of the pthread_t structure. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470 From noreply@sourceforge.net Tue Oct 16 22:32:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Oct 2001 14:32:13 -0700 Subject: [Patches] [ python-Patches-471852 ] getattr with default catches too much Message-ID: Patches item #471852, was opened at 2001-10-16 13:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471852&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Guido van Rossum (gvanrossum) Summary: getattr with default catches too much Initial Comment: getattr.__doc__ sez: ''' getattr(object, name[, default]) -> value Get a named attribute from an object; getattr(x, 'y') is equivalent to x.y. When a default argument is given, it is returned when the attribute doesn't exist; without it, an exception is raised in that case. ''' What really happens is that, when given a default, getattr catches *all* exceptions. In addition to the generally poor practice of silently catching all exceptions, the documentation implies that only AttributeError is caught. I think getattr should be changed to catch only AttributeError, and the documentation changed to: ''' Get a named attribute from an object. getattr(x, 'y') is equivalent to x.y. When a default argument is given, it is returned when 'x' raises an AttributeError. ''' If the patch is rejected, I suggest the docstring be changed to: ''' Get a named attribute from an object. getattr(x, 'y') is equivalent to x.y. If getattr is given a default and 'x' raises an exception, it will catch the exception and return the default. Note that any exception will be caught, not just AttributeError, which can hide bugs if 'x' is a class with a __getattr__ method. ''' *** Python/bltinmodule.c Tue Oct 16 13:14:54 2001 --- Python/bltinmodule.c.old Tue Oct 16 13:14:49 2001 *************** *** 619,627 **** return NULL; } result = PyObject_GetAttr(v, name); ! if (result == NULL && dflt != NULL ! && PyErr_ExceptionMatches(PyExc_AttributeError)) ! { PyErr_Clear(); Py_INCREF(dflt); result = dflt; --- 619,625 ---- return NULL; } result = PyObject_GetAttr(v, name); ! if (result == NULL && dflt != NULL) { PyErr_Clear(); Py_INCREF(dflt); result = dflt; ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-16 14:32 Message: Logged In: YES user_id=6380 Thanks! Good catch. What's your name (for the Misc/ACKS file)? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471852&group_id=5470 From noreply@sourceforge.net Tue Oct 16 22:35:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Oct 2001 14:35:54 -0700 Subject: [Patches] [ python-Patches-416704 ] More robust freeze Message-ID: Patches item #416704, was opened at 2001-04-17 07:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416704&group_id=5470 Category: None Group: None Status: Open Resolution: Out of Date >Priority: 7 Submitted By: Toby Dickenson (htrd) Assigned to: Guido van Rossum (gvanrossum) Summary: More robust freeze Initial Comment: This patch addresses three issues, all relating to robustness of frozen programs. Specifically, this patch allows explicit and complete control over which modules may be loaded from source on the filesystem of the host system where the frozen program is run, and which may not. Without this patch it is impossible to create a non- trivial frozen program which will *never* load a module from source on the filesystem. 1. A patch to correct bug #404545 (frozen package import uses wrong files). Under this change, submodules of a frozen package must themselves be frozen modules. Previously, the import machinery may also try to import submodules from curiously named files (packagename.modulename.py) from directories in sys.path 2. A patch to add an extra command line option -E to freeze.py, which forces freeze to terminate with an error message if there are modules that it can not locate. If this switch is not specified then the default behaviour is unchanged: modules which can not be found by freeze will not be included in the frozen program, and the import machinery will try to load them from source on sys.path when the frozen program is run. In practice we have found that a missing module is probably an error (and it is a fairly frequent error too!). The -E switch can be used to detect this error; any missing modules will cause freeze.py to fail. In the rare case of a frozen module importing a non- frozen one (ie one which should be loaded from source when the program is run), the non-frozen module must be excluded from the freeze using the -x option. 3. A patch to add an extra command line option -X to freeze.py, which indicates that a specified module is excluded from the freeze, and also that the frozen program should not try to load the module from sys.path when it is imported. Importing the specified module will always trigger an ImportError. This is useful if a module used by a frozen program can optionally use a submodule... try: import optional_submodule except ImportError: pass It may be preferable for the frozen program's behaviour to not depend on whether optional_submodule happens to be installed on the host system, and that the 'import optional_submodule' should always fail with an ImportError. This can be achieved using the '- X optional_submodule' command line switch to freeze.py This is implemented by including the excluded module in the frozen imports table (_PyImport_FrozenModules), with the code pointer set to NULL. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-16 14:35 Message: Logged In: YES user_id=6380 I'll try to look at this now! ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-10-03 03:39 Message: Logged In: YES user_id=46460 Still no patch there. Maybe this time? ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-10-03 03:37 Message: Logged In: YES user_id=46460 Once again, including the patch this time. ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-10-03 03:34 Message: Logged In: YES user_id=46460 Attached is an updated patch against the current CVS. I have verified each aspect of this patch with Py_VerboseFlag set to 2, so that import.c traces out which files it is checking during the import process. (Im not aware of an easy way to set Py_VerboseFlag to 2 in a frozen program.... Ive added a new patch #467455 to enhance the PYTHONVERBOSE environment variable to support this) I can confirm that the current CVS (rougly 2.2a4) still demonstrates the problem from bug #404545. The details are slightly different to my original bug report; Im not sure if this is due to an incidental change in python since 1.5.2, or if I messed up that bug report. Anyway, using PyVerbose=2 clearly shows that before this patch it is looking for files it shouldnt (and it uses those files if they exist). After this patch, it definitely only looks for the right files. The other aspect of this patch, adding -E and -X to freeze.py, is exactly as before. ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-09-10 07:20 Message: Logged In: YES user_id=46460 OK, I should get round to this soon. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 08:50 Message: Logged In: YES user_id=6380 I'm willing to look at this, but right now the patch doesn't apply cleanly. From the headers in the diff file it looks like you're patching an early beta for 2.0. If you can rework this for current CVS or Python 2.2a2 or 2.2a3, that would be great. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-06-07 15:26 Message: Logged In: YES user_id=21627 Why is this assigned to Mark? I cannot see anything windows-specific in it. Mark, if you are not interested in reviewing this patch, I recommend to unassign this from yourself. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416704&group_id=5470 From noreply@sourceforge.net Tue Oct 16 23:44:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Oct 2001 15:44:20 -0700 Subject: [Patches] [ python-Patches-471894 ] Makefile installs pydoc incorrectly Message-ID: Patches item #471894, was opened at 2001-10-16 15:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471894&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Makefile installs pydoc incorrectly Initial Comment: The 2.2.1 Makefile installs the pydoc program incorrectly. The Makefile calls setup.py to install various modules and miscellanea. This script also installs pydoc at /usr/local/pydoc. The bug is that pydoc is *always* installed in /usr/local, regardless of what install directory might have been preferred. Here is a patch to Makefile which fixes the problem: --- Makefile Tue Oct 16 14:52:41 2001 +++ ../../Makefile Tue Oct 16 14:50:58 2001 @@ -718,7 +718,13 @@ # Install the dynamically loadable modules # This goes into $(exec_prefix) sharedinstall: + # The distributed Makefile doesn't pass -- install-scripts to setup.py, thus causing setup.py + # to assume that it should put its executable scripts (specifically the pydoc program) into + # /usr/local, instead of where we want things. We overcome this by explicitly specifying the + # --install-scripts option to setup.py. This is hard to figure out; the best place to see the + # possible options to setup.py is ./Lib/distutils/commands/install.py. PYTHONPATH= ./$(PYTHON) $(srcdir)/setup.py install \ + --install-scripts=$(BINDIR) \ --install-platlib=$(DESTSHARED) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471894&group_id=5470 From noreply@sourceforge.net Tue Oct 16 23:53:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Oct 2001 15:53:10 -0700 Subject: [Patches] [ python-Patches-471852 ] getattr with default catches too much Message-ID: Patches item #471852, was opened at 2001-10-16 13:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471852&group_id=5470 Category: Core (C code) Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: getattr with default catches too much Initial Comment: getattr.__doc__ sez: ''' getattr(object, name[, default]) -> value Get a named attribute from an object; getattr(x, 'y') is equivalent to x.y. When a default argument is given, it is returned when the attribute doesn't exist; without it, an exception is raised in that case. ''' What really happens is that, when given a default, getattr catches *all* exceptions. In addition to the generally poor practice of silently catching all exceptions, the documentation implies that only AttributeError is caught. I think getattr should be changed to catch only AttributeError, and the documentation changed to: ''' Get a named attribute from an object. getattr(x, 'y') is equivalent to x.y. When a default argument is given, it is returned when 'x' raises an AttributeError. ''' If the patch is rejected, I suggest the docstring be changed to: ''' Get a named attribute from an object. getattr(x, 'y') is equivalent to x.y. If getattr is given a default and 'x' raises an exception, it will catch the exception and return the default. Note that any exception will be caught, not just AttributeError, which can hide bugs if 'x' is a class with a __getattr__ method. ''' *** Python/bltinmodule.c Tue Oct 16 13:14:54 2001 --- Python/bltinmodule.c.old Tue Oct 16 13:14:49 2001 *************** *** 619,627 **** return NULL; } result = PyObject_GetAttr(v, name); ! if (result == NULL && dflt != NULL ! && PyErr_ExceptionMatches(PyExc_AttributeError)) ! { PyErr_Clear(); Py_INCREF(dflt); result = dflt; --- 619,625 ---- return NULL; } result = PyObject_GetAttr(v, name); ! if (result == NULL && dflt != NULL) { PyErr_Clear(); Py_INCREF(dflt); result = dflt; ---------------------------------------------------------------------- Comment By: Quinn Dunkan (qdunkan) Date: 2001-10-16 15:53 Message: Logged In: YES user_id=351299 Finally got an SF account since it doesn't seem want to let me followup otherwise. Quinn Dunkan ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-16 14:32 Message: Logged In: YES user_id=6380 Thanks! Good catch. What's your name (for the Misc/ACKS file)? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471852&group_id=5470 From noreply@sourceforge.net Wed Oct 17 07:27:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Oct 2001 23:27:34 -0700 Subject: [Patches] [ python-Patches-471894 ] Makefile installs pydoc incorrectly Message-ID: Patches item #471894, was opened at 2001-10-16 15:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471894&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Guido van Rossum (gvanrossum) Summary: Makefile installs pydoc incorrectly Initial Comment: The 2.2.1 Makefile installs the pydoc program incorrectly. The Makefile calls setup.py to install various modules and miscellanea. This script also installs pydoc at /usr/local/pydoc. The bug is that pydoc is *always* installed in /usr/local, regardless of what install directory might have been preferred. Here is a patch to Makefile which fixes the problem: --- Makefile Tue Oct 16 14:52:41 2001 +++ ../../Makefile Tue Oct 16 14:50:58 2001 @@ -718,7 +718,13 @@ # Install the dynamically loadable modules # This goes into $(exec_prefix) sharedinstall: + # The distributed Makefile doesn't pass -- install-scripts to setup.py, thus causing setup.py + # to assume that it should put its executable scripts (specifically the pydoc program) into + # /usr/local, instead of where we want things. We overcome this by explicitly specifying the + # --install-scripts option to setup.py. This is hard to figure out; the best place to see the + # possible options to setup.py is ./Lib/distutils/commands/install.py. PYTHONPATH= ./$(PYTHON) $(srcdir)/setup.py install \ + --install-scripts=$(BINDIR) \ --install-platlib=$(DESTSHARED) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-16 23:27 Message: Logged In: YES user_id=6380 Thanks! I've fixed this in the 2.2 CVS. What's your name? (For Misc/ACKS) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471894&group_id=5470 From noreply@sourceforge.net Wed Oct 17 07:31:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Oct 2001 23:31:17 -0700 Subject: [Patches] [ python-Patches-471975 ] xmlrpclib failure Message-ID: Patches item #471975, was opened at 2001-10-16 23:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471975&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: James Rucker (jamesrucker) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib failure Initial Comment: This bug has been reported earlier (issue #446912), but the earlier patch provided (as admitted by the author) introduces major unnecessary overhead and also, according to the author, may not work. I've provided a very simple fix (6 additional lines), which seems to be in line with the design of the code. From my reading, the source of the problem looks more like an oversight than a real design hole or flaw. The problem again is that objects that appear more than once in the input to xmlrpclib.Marshaller.dumps() are thought to be evidence of recursion. The reason this occurs is because the mechanism that tracks the occurence of container objects (as it descends the chain of container objects) neglects to remove from it's map those objects on the way back up. The fix is to perform proper cleanup, removing from 'memo' container objects, which are no longer part of the context. With the fix, the following works (it breaks under existing code): import xmlrpclib m = xmlrpclib.Marshaller() a = ['1'] b = [a,a] m.dumps(b) and the following still fails (which is correct behavior): a = [1]; a.append(a) m.dumps(a) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471975&group_id=5470 From noreply@sourceforge.net Wed Oct 17 07:42:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Oct 2001 23:42:10 -0700 Subject: [Patches] [ python-Patches-471975 ] xmlrpclib failure Message-ID: Patches item #471975, was opened at 2001-10-16 23:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471975&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: James Rucker (jamesrucker) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib failure Initial Comment: This bug has been reported earlier (issue #446912), but the earlier patch provided (as admitted by the author) introduces major unnecessary overhead and also, according to the author, may not work. I've provided a very simple fix (6 additional lines), which seems to be in line with the design of the code. From my reading, the source of the problem looks more like an oversight than a real design hole or flaw. The problem again is that objects that appear more than once in the input to xmlrpclib.Marshaller.dumps() are thought to be evidence of recursion. The reason this occurs is because the mechanism that tracks the occurence of container objects (as it descends the chain of container objects) neglects to remove from it's map those objects on the way back up. The fix is to perform proper cleanup, removing from 'memo' container objects, which are no longer part of the context. With the fix, the following works (it breaks under existing code): import xmlrpclib m = xmlrpclib.Marshaller() a = ['1'] b = [a,a] m.dumps(b) and the following still fails (which is correct behavior): a = [1]; a.append(a) m.dumps(a) ---------------------------------------------------------------------- >Comment By: James Rucker (jamesrucker) Date: 2001-10-16 23:42 Message: Logged In: YES user_id=351540 I just noticed misa's patch #465298. Looks like it was not used and the issue closed; forgive me if I'm misreading. In any case, I just wanted to point out my oversight before someone else did. Presuming that the issue still doesn't have a suitable fix, I'll leave the issue open. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471975&group_id=5470 From noreply@sourceforge.net Wed Oct 17 09:56:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Oct 2001 01:56:46 -0700 Subject: [Patches] [ python-Patches-470744 ] More cleanup of __repr__ in asyncore Message-ID: Patches item #470744, was opened at 2001-10-12 17:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470744&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cesar Eduardo Barros (cesarb) >Assigned to: Martin v. Lцwis (loewis) Summary: More cleanup of __repr__ in asyncore Initial Comment: This patch removes the ugly 'repr failed' special case in asyncore.dispatcher.__repr__ that happens when self.addr is invalid. - Instead of checking if it's a tuple, just go ahead and catch the TypeError if it isn't (or if it has strange contents). This also removes the import for types. - If it isn't a valid tuple, just do a repr on it. It's probably some alien network protocol with wierd adresses. - I can't see how self.addr can cause a NameError, since it's a class attribute. That was probably historical cruft. Removed. This complements python-Patches-470680 (Clean output of __repr__ in asyncore) which was partially commited as 1.22. This patch is against asyncore.py 1.22. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470744&group_id=5470 From noreply@sourceforge.net Wed Oct 17 13:30:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Oct 2001 05:30:13 -0700 Subject: [Patches] [ python-Patches-446912 ] Recursive object detection in xmlrpclib Message-ID: Patches item #446912, was opened at 2001-08-01 12:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446912&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Alex Coventry (alex_coventry) Assigned to: Fredrik Lundh (effbot) Summary: Recursive object detection in xmlrpclib Initial Comment: The current implementation of xmlrpclib.Marshaller is a little inaccurate, in that it identifies as recursive any container object that has more than one reference to a given object. E.g. >>> import xmlrpclib >>> m = xmlrpclib.Marshaller() >>> a = (1,) >>> m.dumps((a, a)) Traceback (most recent call last): File "", line 1, in ? File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 393, in dumps self.__dump(v) File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 406, in __dump f(self, value) File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 438, in dump_array self.__dump(v) File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 406, in __dump f(self, value) File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 434, in dump_array self.container(value) File "/scratch2/alex/lib/python2.2/xmlrpclib.py", line 430, in container raise TypeError, "cannot marshal recursive data structures" TypeError: cannot marshal recursive data structures >>> The attached patch corrects this by first getting the reference graph of the object to be marshalled, and topsort'ing it to check that it's not cyclic. I'm not sure whether this is better behaviour than the current implementation's, as it could lead to massive duplication in the xml response that gets generated. However, at least the error message "cannot marshal recursive data" should be changed if the current implementation is left unchanged, as it misleadingly implies that the object it was passed is recursive. The attached testing script works with python from the CVS repository. A bunch of other tests are failing, but I don't think they're related to xmlrpc. HTH. Alex. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-10-17 05:30 Message: Logged In: YES user_id=21627 Fixed with xmlrpclib.py 1.8. ---------------------------------------------------------------------- Comment By: Alex Coventry (alex_coventry) Date: 2001-08-02 08:12 Message: Logged In: YES user_id=49686 So I can't delete the old files, which makes sense. Please disregard them. ---------------------------------------------------------------------- Comment By: Alex Coventry (alex_coventry) Date: 2001-08-02 08:09 Message: Logged In: YES user_id=49686 There were errors in my code for iterating over the object to be marshalled. I'm deleting the old versions and submitting new patch and test files. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446912&group_id=5470 From noreply@sourceforge.net Wed Oct 17 13:35:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Oct 2001 05:35:07 -0700 Subject: [Patches] [ python-Patches-471975 ] xmlrpclib failure Message-ID: Patches item #471975, was opened at 2001-10-16 23:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471975&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: James Rucker (jamesrucker) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib failure Initial Comment: This bug has been reported earlier (issue #446912), but the earlier patch provided (as admitted by the author) introduces major unnecessary overhead and also, according to the author, may not work. I've provided a very simple fix (6 additional lines), which seems to be in line with the design of the code. From my reading, the source of the problem looks more like an oversight than a real design hole or flaw. The problem again is that objects that appear more than once in the input to xmlrpclib.Marshaller.dumps() are thought to be evidence of recursion. The reason this occurs is because the mechanism that tracks the occurence of container objects (as it descends the chain of container objects) neglects to remove from it's map those objects on the way back up. The fix is to perform proper cleanup, removing from 'memo' container objects, which are no longer part of the context. With the fix, the following works (it breaks under existing code): import xmlrpclib m = xmlrpclib.Marshaller() a = ['1'] b = [a,a] m.dumps(b) and the following still fails (which is correct behavior): a = [1]; a.append(a) m.dumps(a) ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-10-17 05:35 Message: Logged In: YES user_id=21627 The patch in #465298 was indeed not applied as-is, however, a simplified version of this patch was checked in as xmlrpclib.py 1.8, as my comment from 2001-09-30 22:17 indicates; /F then has revised this code once more in 1.10. So this has been already fixed, sorry for the duplication of work. When providing patches, please always produce context (-c) or unified (-u) diffs; that makes it easier to integrate the patch even if the file has been changed (xmlrpclib has seen a number of changes since 2.2a4). ---------------------------------------------------------------------- Comment By: James Rucker (jamesrucker) Date: 2001-10-16 23:42 Message: Logged In: YES user_id=351540 I just noticed misa's patch #465298. Looks like it was not used and the issue closed; forgive me if I'm misreading. In any case, I just wanted to point out my oversight before someone else did. Presuming that the issue still doesn't have a suitable fix, I'll leave the issue open. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471975&group_id=5470 From noreply@sourceforge.net Wed Oct 17 15:43:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Oct 2001 07:43:56 -0700 Subject: [Patches] [ python-Patches-452110 ] socketmodule ssl: server & thread Message-ID: Patches item #452110, was opened at 2001-08-17 08:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452110&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jozef Hatala (jhatala) Assigned to: Jeremy Hylton (jhylton) Summary: socketmodule ssl: server & thread Initial Comment: Simple enhancement to the SSL support in module socket : - support for writing SSL servers (as well as clients) - Py_*_ALLOW_THREADS arround blocking calls to openssl - rsa temp key to work with older export netscape - renamed attribute server to peer This patch allows for powerfull application servers like the following one to be accessed with "netscape https://localhost:1443/" from socket import * p=socket(AF_INET,SOCK_STREAM) p.bind(('localhost',1443)) p.listen(1) while 1 : s,a = p.accept() c = sslserver(s,'server.key','server.crt') print "They said:", c.read() c.write('HTTP/1.0 200 OK\r\n') c.write('Content-Type: text/plain\r\n\r\n** Hi! **') c.close() TODO: a kind of makefile() on the ssl object like on a socket would be welcome. Have fun, jh ---------------------------------------------------------------------- >Comment By: Jozef Hatala (jhatala) Date: 2001-10-17 07:43 Message: Logged In: YES user_id=300564 This patch now against Python 2.2a3 contains: SSL server support (SSL_accept) [as before] additionally: allow threads around getaddrinfo &Co. more verbose exc messages (for failures in ssl() and sslserver()) methods recv and send on ssl object as equivalents of read and write. methods makefile on ssl object (a look-alike and does no dup!) a client/server test (depends on os.fork()) ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-10-16 09:05 Message: Logged In: YES user_id=31392 If you can provide test cases, I'll provide documentation. But hurry, if we don't get this done this week, we may miss Python 2.2. ---------------------------------------------------------------------- Comment By: Jozef Hatala (jhatala) Date: 2001-10-16 03:21 Message: Logged In: YES user_id=300564 I'll submit a simple test with certificates and an enhanced patch for 2.2a2 (does not patch cleanly any more) soon (this week) [time and inet access issues]. I haven't written any doc. There was none for ssl. I know that is no excuse... Does some-one volonotere? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-10-11 09:13 Message: Logged In: YES user_id=31392 Jozef-- are you going to contribute tests and documentation? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:17 Message: Logged In: YES user_id=6380 Nice, but where's the documentation? (Thanks for the docstrings though!) And the test suite? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452110&group_id=5470 From noreply@sourceforge.net Wed Oct 17 21:33:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Oct 2001 13:33:05 -0700 Subject: [Patches] [ python-Patches-470254 ] check for xmlrpc ints/longs > 32 bits Message-ID: Patches item #470254, was opened at 2001-10-11 07:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470254&group_id=5470 Category: Library (Lib) Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Skip Montanaro (montanaro) Summary: check for xmlrpc ints/longs > 32 bits Initial Comment: This patch to xmlrpclib checks ints and long ints when converting to make sure they are within the valid range of ints that XML-RPC can handle. It also adds a couple extra test cases. Can somebody with a machine whose int size is > 32 bits check this? ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-10-17 13:33 Message: Logged In: YES user_id=21627 The patch looks fine, please install it. As before, update the changelog at the file top. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-10-12 10:09 Message: Logged In: YES user_id=44345 Oops. Too many diff files with similar names. Try this one. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-10-11 11:42 Message: Logged In: YES user_id=21627 Are you sure this is the right patch? It has nothing to do with ints and longs, but re-introduces _cgi_escape using a toplevel "import as" instead... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470254&group_id=5470 From noreply@sourceforge.net Wed Oct 17 23:54:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Oct 2001 15:54:33 -0700 Subject: [Patches] [ python-Patches-470254 ] check for xmlrpc ints/longs > 32 bits Message-ID: Patches item #470254, was opened at 2001-10-11 07:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470254&group_id=5470 Category: Library (Lib) Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: check for xmlrpc ints/longs > 32 bits Initial Comment: This patch to xmlrpclib checks ints and long ints when converting to make sure they are within the valid range of ints that XML-RPC can handle. It also adds a couple extra test cases. Can somebody with a machine whose int size is > 32 bits check this? ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2001-10-17 15:54 Message: Logged In: YES user_id=44345 checked in as v 1.14 ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-10-17 13:33 Message: Logged In: YES user_id=21627 The patch looks fine, please install it. As before, update the changelog at the file top. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-10-12 10:09 Message: Logged In: YES user_id=44345 Oops. Too many diff files with similar names. Try this one. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-10-11 11:42 Message: Logged In: YES user_id=21627 Are you sure this is the right patch? It has nothing to do with ints and longs, but re-introduces _cgi_escape using a toplevel "import as" instead... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470254&group_id=5470 From noreply@sourceforge.net Thu Oct 18 04:19:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Oct 2001 20:19:54 -0700 Subject: [Patches] [ python-Patches-464992 ] Fix abstract isinstance Message-ID: Patches item #464992, was opened at 2001-09-25 15:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=464992&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Neil Schemenauer (nascheme) Summary: Fix abstract isinstance Initial Comment: The built-in isinstance function is still broken when used on extension classes. For example: >>> from ExtensionClass import Base >>> class Super: ... pass ... >>> isinstance(Super(), Base) Traceback (most recent call last): File "", line 1, in ? TypeError: isinstance() arg 2 must be a class or type isinstance() should allow any object as the first argument and a class, a type, or something with a __bases__ tuple attribute for the second argument. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-10-17 20:19 Message: Logged In: YES user_id=35752 Checked in as abstract.c 2.85. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-12 15:06 Message: Logged In: YES user_id=6380 I apologize. Somehow I thought this was a bugh report rather than a patch, and put off looking at it. When I found the patch, it was out of date. Can you rework the patch? You might as well check it in as long as the test suite still works, so we get this in time for 2.2b1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=464992&group_id=5470 From noreply@sourceforge.net Thu Oct 18 12:40:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 04:40:30 -0700 Subject: [Patches] [ python-Patches-470744 ] More cleanup of __repr__ in asyncore Message-ID: Patches item #470744, was opened at 2001-10-12 17:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470744&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Cesar Eduardo Barros (cesarb) Assigned to: Martin v. Lцwis (loewis) Summary: More cleanup of __repr__ in asyncore Initial Comment: This patch removes the ugly 'repr failed' special case in asyncore.dispatcher.__repr__ that happens when self.addr is invalid. - Instead of checking if it's a tuple, just go ahead and catch the TypeError if it isn't (or if it has strange contents). This also removes the import for types. - If it isn't a valid tuple, just do a repr on it. It's probably some alien network protocol with wierd adresses. - I can't see how self.addr can cause a NameError, since it's a class attribute. That was probably historical cruft. Removed. This complements python-Patches-470680 (Clean output of __repr__ in asyncore) which was partially commited as 1.22. This patch is against asyncore.py 1.22. ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-10-18 04:40 Message: Logged In: YES user_id=21627 Thanks, applied as asyncore.py 1.23 (with re-indentation). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470744&group_id=5470 From noreply@sourceforge.net Thu Oct 18 19:38:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 11:38:28 -0700 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: Open Resolution: None >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 Thu Oct 18 19:40:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 11:40:35 -0700 Subject: [Patches] [ python-Patches-419070 ] Fix #416670: register SRE types Message-ID: Patches item #419070, was opened at 2001-04-26 00:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419070&group_id=5470 Category: None Group: None >Status: Closed Resolution: None >Priority: 3 Submitted By: Martin v. Lцwis (loewis) Assigned to: Fredrik Lundh (effbot) Summary: Fix #416670: register SRE types Initial Comment: This patch registers the three SRE types in the copy module as immutable, atomic types. This is not completely correct, since pattern.groupindex is a mutable object (a dictionary). Since nobody *should* change that dictionary, treating it as immutable is sufficient. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2001-10-18 11:40 Message: Logged In: YES user_id=38376 SRE has (almost) grown __copy__ and __deepcopy__ hooks instead. Just need to write some test code before enabling it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419070&group_id=5470 From noreply@sourceforge.net Thu Oct 18 19:48:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 11:48:29 -0700 Subject: [Patches] [ python-Patches-471421 ] conditional expression (if-then-else) Message-ID: Patches item #471421, was opened at 2001-10-15 11:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471421&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: conditional expression (if-then-else) Initial Comment: Here's an implementation of conditional expressions of the form if then else It's hairier than expected because I'm trying to require you to put parentheses around it in some cases but not in others. This still lacking: - a PEP to motivate and explain it - documentation - tests - needed changes to Modules/parsermodule.c After applying this patch, you must regenerate the grammar; the Unix Makefile and the current CVS version of the Windows project file do this automatically. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-16 13:09 Message: Logged In: YES user_id=6380 The more I think about this, the less I like it -- mostly because I cannot find decent examples in the std library that would benefit from this... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-15 14:01 Message: Logged In: YES user_id=6380 OK, conditional-2.txt is a patch that includes the paren-less "else if", as well as the graminit.[ch] diffs. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-15 13:50 Message: Logged In: YES user_id=31435 About elif, I channeled you as leaving it out deliberately . A long chain of these is probably crying out for a dict lookup instead: p = {1: 'one', 2: 'two', 3: 'three'}.get(x, 'many') where the dict literal wouldn't really be written inline. Short of adding elif, though (OK by me), the "extra" parens needed using "else if" instead must go. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-15 13:04 Message: Logged In: YES user_id=6380 Somthing to think about: should this support 'elif'? Like this: p = if x==1 then 'one' elif x==2 then 'two' elif x==3 then 'three' else 'many' With the current patch that would have to be written using ugly extra parentheses: p = if x==1 then '1' else (if x==2 then '2' else (if x==3 then '3' else '*')) It would be easy enough to allow these parentheses to be omitted: just change the conditional to 'if' test 'then' test 'else' (test | conditional). Allowing 'elif' might then not be needed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-15 12:47 Message: Logged In: YES user_id=6380 The 'fi' would disambiguate binary operators following the else part. But I find it very unpythonic: we don't have Algol-68 style reversed closing keywords anywhere else, and when you squint you don't see the structure. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-15 12:44 Message: Logged In: YES user_id=31435 Martin, I don't think so. "The problem" is ensuring the parser can distinguish a conditional expression from an if statement, as they both begin with "if". A left paren rules out an if-statement. If the conditional expression *began* with "fi", no problem . ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-10-15 12:34 Message: Logged In: YES user_id=21627 Would the grammar become simpler if the syntax was if then else fi ? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-15 12:22 Message: Logged In: YES user_id=31435 FYI, the grammar is not regenerated by magic on Windows. I very recently checked in Parser/grammar.mak (a Windows nmake file), which you can use "by hand" (read the comments at the top of the file) to regenerate the grammar if you know that's needed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=471421&group_id=5470 From noreply@sourceforge.net Thu Oct 18 19:52:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 11:52:02 -0700 Subject: [Patches] [ python-Patches-468169 ] fix for bug #448951 (re group handling) Message-ID: Patches item #468169, was opened at 2001-10-04 21:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468169&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Fredrik Lundh (effbot) Summary: fix for bug #448951 (re group handling) Initial Comment: Well, it seems I can't add files to bugs I didn't post, so here is the patch for bug #448951. It passes all existing re tests and adds new ones to test this bug (and related possibilities). ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2001-10-18 11:52 Message: Logged In: YES user_id=38376 it's in. thanks /F ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468169&group_id=5470 From noreply@sourceforge.net Thu Oct 18 19:54:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 11:54:25 -0700 Subject: [Patches] [ python-Patches-416704 ] More robust freeze Message-ID: Patches item #416704, was opened at 2001-04-17 07:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416704&group_id=5470 Category: None Group: None Status: Open Resolution: Out of Date Priority: 7 Submitted By: Toby Dickenson (htrd) Assigned to: Guido van Rossum (gvanrossum) Summary: More robust freeze Initial Comment: This patch addresses three issues, all relating to robustness of frozen programs. Specifically, this patch allows explicit and complete control over which modules may be loaded from source on the filesystem of the host system where the frozen program is run, and which may not. Without this patch it is impossible to create a non- trivial frozen program which will *never* load a module from source on the filesystem. 1. A patch to correct bug #404545 (frozen package import uses wrong files). Under this change, submodules of a frozen package must themselves be frozen modules. Previously, the import machinery may also try to import submodules from curiously named files (packagename.modulename.py) from directories in sys.path 2. A patch to add an extra command line option -E to freeze.py, which forces freeze to terminate with an error message if there are modules that it can not locate. If this switch is not specified then the default behaviour is unchanged: modules which can not be found by freeze will not be included in the frozen program, and the import machinery will try to load them from source on sys.path when the frozen program is run. In practice we have found that a missing module is probably an error (and it is a fairly frequent error too!). The -E switch can be used to detect this error; any missing modules will cause freeze.py to fail. In the rare case of a frozen module importing a non- frozen one (ie one which should be loaded from source when the program is run), the non-frozen module must be excluded from the freeze using the -x option. 3. A patch to add an extra command line option -X to freeze.py, which indicates that a specified module is excluded from the freeze, and also that the frozen program should not try to load the module from sys.path when it is imported. Importing the specified module will always trigger an ImportError. This is useful if a module used by a frozen program can optionally use a submodule... try: import optional_submodule except ImportError: pass It may be preferable for the frozen program's behaviour to not depend on whether optional_submodule happens to be installed on the host system, and that the 'import optional_submodule' should always fail with an ImportError. This can be achieved using the '- X optional_submodule' command line switch to freeze.py This is implemented by including the excluded module in the frozen imports table (_PyImport_FrozenModules), with the code pointer set to NULL. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-18 11:54 Message: Logged In: YES user_id=6380 I checked in the first part (import.c). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-16 14:35 Message: Logged In: YES user_id=6380 I'll try to look at this now! ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-10-03 03:39 Message: Logged In: YES user_id=46460 Still no patch there. Maybe this time? ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-10-03 03:37 Message: Logged In: YES user_id=46460 Once again, including the patch this time. ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-10-03 03:34 Message: Logged In: YES user_id=46460 Attached is an updated patch against the current CVS. I have verified each aspect of this patch with Py_VerboseFlag set to 2, so that import.c traces out which files it is checking during the import process. (Im not aware of an easy way to set Py_VerboseFlag to 2 in a frozen program.... Ive added a new patch #467455 to enhance the PYTHONVERBOSE environment variable to support this) I can confirm that the current CVS (rougly 2.2a4) still demonstrates the problem from bug #404545. The details are slightly different to my original bug report; Im not sure if this is due to an incidental change in python since 1.5.2, or if I messed up that bug report. Anyway, using PyVerbose=2 clearly shows that before this patch it is looking for files it shouldnt (and it uses those files if they exist). After this patch, it definitely only looks for the right files. The other aspect of this patch, adding -E and -X to freeze.py, is exactly as before. ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-09-10 07:20 Message: Logged In: YES user_id=46460 OK, I should get round to this soon. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 08:50 Message: Logged In: YES user_id=6380 I'm willing to look at this, but right now the patch doesn't apply cleanly. From the headers in the diff file it looks like you're patching an early beta for 2.0. If you can rework this for current CVS or Python 2.2a2 or 2.2a3, that would be great. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-06-07 15:26 Message: Logged In: YES user_id=21627 Why is this assigned to Mark? I cannot see anything windows-specific in it. Mark, if you are not interested in reviewing this patch, I recommend to unassign this from yourself. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416704&group_id=5470 From noreply@sourceforge.net Thu Oct 18 20:15:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 12:15:50 -0700 Subject: [Patches] [ python-Patches-416704 ] More robust freeze Message-ID: Patches item #416704, was opened at 2001-04-17 07:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416704&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: Toby Dickenson (htrd) Assigned to: Guido van Rossum (gvanrossum) Summary: More robust freeze Initial Comment: This patch addresses three issues, all relating to robustness of frozen programs. Specifically, this patch allows explicit and complete control over which modules may be loaded from source on the filesystem of the host system where the frozen program is run, and which may not. Without this patch it is impossible to create a non- trivial frozen program which will *never* load a module from source on the filesystem. 1. A patch to correct bug #404545 (frozen package import uses wrong files). Under this change, submodules of a frozen package must themselves be frozen modules. Previously, the import machinery may also try to import submodules from curiously named files (packagename.modulename.py) from directories in sys.path 2. A patch to add an extra command line option -E to freeze.py, which forces freeze to terminate with an error message if there are modules that it can not locate. If this switch is not specified then the default behaviour is unchanged: modules which can not be found by freeze will not be included in the frozen program, and the import machinery will try to load them from source on sys.path when the frozen program is run. In practice we have found that a missing module is probably an error (and it is a fairly frequent error too!). The -E switch can be used to detect this error; any missing modules will cause freeze.py to fail. In the rare case of a frozen module importing a non- frozen one (ie one which should be loaded from source when the program is run), the non-frozen module must be excluded from the freeze using the -x option. 3. A patch to add an extra command line option -X to freeze.py, which indicates that a specified module is excluded from the freeze, and also that the frozen program should not try to load the module from sys.path when it is imported. Importing the specified module will always trigger an ImportError. This is useful if a module used by a frozen program can optionally use a submodule... try: import optional_submodule except ImportError: pass It may be preferable for the frozen program's behaviour to not depend on whether optional_submodule happens to be installed on the host system, and that the 'import optional_submodule' should always fail with an ImportError. This can be achieved using the '- X optional_submodule' command line switch to freeze.py This is implemented by including the excluded module in the frozen imports table (_PyImport_FrozenModules), with the code pointer set to NULL. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-18 12:15 Message: Logged In: YES user_id=6380 Thanks. All checked in! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-18 11:54 Message: Logged In: YES user_id=6380 I checked in the first part (import.c). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-16 14:35 Message: Logged In: YES user_id=6380 I'll try to look at this now! ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-10-03 03:39 Message: Logged In: YES user_id=46460 Still no patch there. Maybe this time? ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-10-03 03:37 Message: Logged In: YES user_id=46460 Once again, including the patch this time. ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-10-03 03:34 Message: Logged In: YES user_id=46460 Attached is an updated patch against the current CVS. I have verified each aspect of this patch with Py_VerboseFlag set to 2, so that import.c traces out which files it is checking during the import process. (Im not aware of an easy way to set Py_VerboseFlag to 2 in a frozen program.... Ive added a new patch #467455 to enhance the PYTHONVERBOSE environment variable to support this) I can confirm that the current CVS (rougly 2.2a4) still demonstrates the problem from bug #404545. The details are slightly different to my original bug report; Im not sure if this is due to an incidental change in python since 1.5.2, or if I messed up that bug report. Anyway, using PyVerbose=2 clearly shows that before this patch it is looking for files it shouldnt (and it uses those files if they exist). After this patch, it definitely only looks for the right files. The other aspect of this patch, adding -E and -X to freeze.py, is exactly as before. ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-09-10 07:20 Message: Logged In: YES user_id=46460 OK, I should get round to this soon. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 08:50 Message: Logged In: YES user_id=6380 I'm willing to look at this, but right now the patch doesn't apply cleanly. From the headers in the diff file it looks like you're patching an early beta for 2.0. If you can rework this for current CVS or Python 2.2a2 or 2.2a3, that would be great. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-06-07 15:26 Message: Logged In: YES user_id=21627 Why is this assigned to Mark? I cannot see anything windows-specific in it. Mark, if you are not interested in reviewing this patch, I recommend to unassign this from yourself. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416704&group_id=5470 From noreply@sourceforge.net Thu Oct 18 20:17:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 12:17:26 -0700 Subject: [Patches] [ python-Patches-472523 ] Reminder: 2.3 should check tp_compare Message-ID: Patches item #472523, was opened at 2001-10-18 12:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=472523&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 2 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: Reminder: 2.3 should check tp_compare Initial Comment: In 2.3, the outcome of tp_compare should be required to be -1, 0 or 1; other values should be considered *illegal*. (In 2.2, the docs were changed to stress this but for backwards compatibility this isn't enforced.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=472523&group_id=5470 From noreply@sourceforge.net Thu Oct 18 20:21:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 12:21:07 -0700 Subject: [Patches] [ python-Patches-424475 ] Speed-up tp_compare usage Message-ID: Patches item #424475, was opened at 2001-05-16 01:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424475&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Martin v. Lцwis (loewis) Assigned to: Guido van Rossum (gvanrossum) Summary: Speed-up tp_compare usage Initial Comment: This patch tries to optimize PyObject_RichCompare for the common case of objects with equal types which support tp_compare. It gives a speed-up of roughly 7% for comparing strings in a loop. The patch also gives type objects a tp_compare function, so that they can make use of the improvement. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-18 12:21 Message: Logged In: YES user_id=6380 Closing this; I've opened a separate bug for the 2.3 reminder. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-16 13:35 Message: Logged In: YES user_id=6380 I've applied the recommended doc change. Reminder: in 2.3, we should actually check the return value of tp_compare and reject values outside [-1, 1]. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-16 02:58 Message: Logged In: YES user_id=21627 The instance-tp-compare-is-special assumption was introduced with rich comparisons. Currently, it is nowhere specified that tp_compare *must* return -1/0/1, so for other types, 2 may well mean "one is larger than the other". In fact, in Py 2.1, string_compare would return Py_CHARMASK(*a->ob_sval) - Py_CHARMASK(*b->ob_sval) if the first two letters of the string were different. It is probably ok to tighten this up, but in a phased manner: First (in 2.2), document that the return type really is {-1,0,1}; then (in 2.3) extend the documentation to cover +2 as well, and perhaps even -2 (exception). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-16 01:05 Message: Logged In: YES user_id=6380 Thanks for the quick fix. I'll check it in, because I want to commit some other changes to the same file. I still feel uneasy about the PyInstance_Check(). Shouldn't all types be allowed to return 2 from their tp_compare slot? (In general, the type/class unification makes me feel uneasy with *any* PyInstance_Check() special cases.) ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-16 00:43 Message: Logged In: YES user_id=21627 It appears that do_cmp does not take into account the special calling semantics of tp_compare for instances. The attached cmp.diff fixes this case. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-15 13:51 Message: Logged In: YES user_id=6380 I have to reopen this, because I've encountered a bug (I think). Take a trivial class: class C: pass and compare two instances of it: cmp(C(), C()) In Python 2.1.1 and before, this returned the same as cmp(id(C()), id(C())) but currently it always returns the value 2! This 2 is supposed to be an internal value that should never be returned. I am not 100% sure that it is this patch that's at fault, but I selectively rolled the object.c part of this patch back, and then it started doing the right thing again. I'm going to check in a test that verifies the correct behavior. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-06-09 00:40 Message: Logged In: YES user_id=21627 Committed as object.c 2.132, typeobject.c 2.17, UserList.py 1.17. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-06-07 13:19 Message: Logged In: YES user_id=31435 Accepted and assigned back to Martin. This is too valuable to quibble over. Note that when calling a tp_compare slot, this kind of thing: . c = (*f)(v, w); . if (PyErr_Occurred()) is better spelled: . c = (*f)(v, w); . if (c < 0 && Py_Err_Occurred()) ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-05-21 09:57 Message: Logged In: YES user_id=21627 The revised patch prefers tp_compare over tp_richcompare in do_cmp if both are available. It also restores UserList.__cmp__ from deprecation. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=424475&group_id=5470 From noreply@sourceforge.net Thu Oct 18 20:24:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 12:24:20 -0700 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: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) >Assigned to: Guido van Rossum (gvanrossum) 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: 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 Oct 18 21:27:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 13:27:33 -0700 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-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 Thu Oct 18 21:35:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 13:35:09 -0700 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: Open >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: 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 Oct 18 21:40:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 13:40:28 -0700 Subject: [Patches] [ python-Patches-472555 ] Remove trailing common in enumeration Message-ID: Patches item #472555, was opened at 2001-10-18 13:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=472555&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Remove trailing common in enumeration Initial Comment: Trying to get Python-2.2a4 built on an AIX machine, the xlc compiler didn't like the trailing comma for the enumeration in Python/ceval.c, line 471. The following trivial fix let the compiler continue. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=472555&group_id=5470 From noreply@sourceforge.net Thu Oct 18 21:47:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 13:47:38 -0700 Subject: [Patches] [ python-Patches-472555 ] Remove trailing common in enumeration Message-ID: Patches item #472555, was opened at 2001-10-18 13:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=472555&group_id=5470 >Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Tim Peters (tim_one) Summary: Remove trailing common in enumeration Initial Comment: Trying to get Python-2.2a4 built on an AIX machine, the xlc compiler didn't like the trailing comma for the enumeration in Python/ceval.c, line 471. The following trivial fix let the compiler continue. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-10-18 13:47 Message: Logged In: YES user_id=31435 No patch was attached, but I assume you mean the trailing comma after WHY_YIELD. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=472555&group_id=5470 From noreply@sourceforge.net Thu Oct 18 21:50:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 13:50:42 -0700 Subject: [Patches] [ python-Patches-472555 ] Remove trailing common in enumeration Message-ID: Patches item #472555, was opened at 2001-10-18 13:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=472555&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: Remove trailing common in enumeration Initial Comment: Trying to get Python-2.2a4 built on an AIX machine, the xlc compiler didn't like the trailing comma for the enumeration in Python/ceval.c, line 471. The following trivial fix let the compiler continue. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-10-18 13:50 Message: Logged In: YES user_id=31435 Removed the trailing comma, in Python/ceval.c; new revision: 2.287 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-18 13:47 Message: Logged In: YES user_id=31435 No patch was attached, but I assume you mean the trailing comma after WHY_YIELD. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=472555&group_id=5470 From noreply@sourceforge.net Thu Oct 18 23:34:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 15:34:46 -0700 Subject: [Patches] [ python-Patches-472593 ] Changing the preferences mechanism Message-ID: Patches item #472593, was opened at 2001-10-18 15:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=472593&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexandre Parenteau (aubonbeurre) Assigned to: Jack Jansen (jackjansen) Summary: Changing the preferences mechanism Initial Comment: Proposal to enhance MacPython preferences: ------------------------------------------ - Motivation : when embedding MacPython in MacCvs, I realized the way MacPython is storing the preferences in a solid Mac handle is a serious problem for MacCvs in order to use several versions of MacPython, and still being able to control the MacPython resources. - The patch : it is not complete, it is *only* a proposal for an under mechanism which stores individually "Persistent" values, or values which have the ability to be retained/loaded/saved accross several MacPython sessions. - The C side: example: defining a new persistent value is as simple as: static CPersistentInt version("version", POPT_VERSION_CURRENT); The value gets automatically linked to all the other persistent values so they can be loaded and stored all together. There are a set of pre-defined types of persistent values (int, bool, string) - The Python side : I have included a sample testpersistent.py which illustrates how the script can access, load, store the values. Note : the C++ implementation is just for convenience and RTTI is not used. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=472593&group_id=5470 From noreply@sourceforge.net Thu Oct 18 23:47:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 15:47:22 -0700 Subject: [Patches] [ python-Patches-421709 ] Access { thread id : frame } dict Message-ID: Patches item #421709, was opened at 2001-05-05 13:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421709&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: John D. Heintz (jheintz) Assigned to: Barry Warsaw (bwarsaw) Summary: Access { thread id : frame } dict Initial Comment: This patch adds a new function sys._getframes() that returns a dictionary mapping from thread id to current frame object. This is very useful when diagnosing deadlock issues in Python code. The new C code function is purely additive except for modifying the PyThreadState struct (adding a long thread_ident) and modifying PyThreadState_New() function to set this new long. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-10-18 15:47 Message: Logged In: YES user_id=12800 In keeping with Martin's last comment, I'm closing this patch. If the issues brought up are addressed, we can re-evaluate it for Python 2.3. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-16 12:02 Message: Logged In: YES user_id=21627 I propose to close this patch if it is not updated by Oct 1, 2001. If it is not updated by the time the last alpha is released, it probably has no chance to go into Python 2.2. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-06-05 01:00 Message: Logged In: YES user_id=21627 There is a difference between these two functions. _getframe is not an official API; inspect.currentframe is the official API. It seems that your function is meant to be used via sys, so it would be public there. In any case, I also think that the sys._getframe doc string should not talk about intended uses - if anything, it should mention what function to call instead. ---------------------------------------------------------------------- Comment By: John D. Heintz (jheintz) Date: 2001-06-04 10:52 Message: Logged In: YES user_id=20438 Martin: I agree with you on the documentation issue and will look into the tuple size issue you raised. The docstring is modeled on the sys._getframe() function so I figured it would be sufficient to follow the leader. (I think that both sys._getframe() and sys._getframes() should be part of the public api for the sys module by the way.) ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-06-04 10:28 Message: Logged In: YES user_id=21627 I think the patch could use some more documentation, e.g. as a patch to Doc/lib/libsys.tex. E.g. what are the tuples that are put into the dictionaries? Also, isn't there a problem with the tuple size? The patch allocates tuples of size 0, but then puts things into index 0. Is there any kind of test case for this code? Finally, I don't think the docstring should say that the function is for internal and specialized purposes only (what specialized purposes, anyway), if you think its primary use is in diagnosing deadlocks. It should only document what the function does, not what you intend it to use for. For these reasons, I also think its name should not start with an underscore. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421709&group_id=5470 From noreply@sourceforge.net Thu Oct 18 23:50:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 15:50:46 -0700 Subject: [Patches] [ python-Patches-423140 ] adds encode- and decodestring to quopri Message-ID: Patches item #423140, was opened at 2001-05-10 12:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423140&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Aluo Nowu (etoffi) Assigned to: Barry Warsaw (bwarsaw) Summary: adds encode- and decodestring to quopri Initial Comment: i added this to match base64.py ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-10-18 15:50 Message: Logged In: YES user_id=12800 These have already been added to quopri, using in fact cStringIO as Martin suggests, but also using the new binascii functions a2b_qp() and b2a_qp() if available. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-16 03:07 Message: Logged In: YES user_id=21627 I recommend to approve this patch. It might be worthwhile to use cStringIO if available. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 22:23 Message: Logged In: YES user_id=3066 Assigned to Barry since the new APIs in base64 are his invention. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=423140&group_id=5470 From noreply@sourceforge.net Thu Oct 18 23:53:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 15:53:03 -0700 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: Open 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: 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 Oct 18 23:55:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 15:55:47 -0700 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: None Status: Open Resolution: None 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: 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 Oct 19 00:01:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 16:01:28 -0700 Subject: [Patches] [ python-Patches-445433 ] a getPart method for mimetools.Message Message-ID: Patches item #445433, was opened at 2001-07-27 23:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445433&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) >Assigned to: Guido van Rossum (gvanrossum) Summary: a getPart method for mimetools.Message Initial Comment: This is a getPart method for the mimetools.Message class. The code comes from the roundup project (roundup.sf.net) ... it seems odd that mimetools.Message doesn't provide this out-of-the-box. Anyway, it's simple enough. There is a unit test for this code in the roundup test directory. class Message(mimetools.Message): def getPart(self) boundary = self.getparam('boundary') mid, end = '--'+boundary, '--'+boundary+'--' s = cStringIO.StringIO() while 1: line = self.fp.readline() if not line: break if line.strip() in (mid, end): break s.write(line) if not s.getvalue().strip(): return None s.seek(0) return Message(s) ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-10-18 16:01 Message: Logged In: YES user_id=12800 A bigger question is whether we should continue to support mimetool now that the email package is part of the standard library? email's Message class supports this via its get_payload() method. Should we deprecate mimetools for Python 2.2? Assigning to Guido for his opinion. Note that other candidates for deprecation include MimeWriter and mimify (although the latter has support for being run as a command line script -- I wonder if anybody actually uses that?). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=445433&group_id=5470 From noreply@sourceforge.net Fri Oct 19 02:01:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 18:01:11 -0700 Subject: [Patches] [ python-Patches-407764 ] allow whitespace lines for doctest tests Message-ID: Patches item #407764, was opened at 2001-03-11 13:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407764&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Trent Mick (tmick) Assigned to: Trent Mick (tmick) Summary: allow whitespace lines for doctest tests Initial Comment: Currently doctest.py does not allow individual tests to have all-whitespace output lines. This patch proposes a fix for this. With this patch a leading '.' on a doctest output line, if and only if the tests are indented, will signal that following whitespace *is* the expected output. For example, currently this cannot be doctest'ed """ >>> print "\nhello\n" hello >>> """ But with this patch *this* can be: # file test_doctest.py """ >>> print "\nhello\n" . hello . >>> """ def _test(): import doctest, test_doctest return doctest.testmod(test_doctest) if __name__ == "__main__": _test() ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-18 18:01 Message: Logged In: YES user_id=6380 Why not just close this as Rejected? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-06-04 11:32 Message: Logged In: YES user_id=31435 Should have assigned this back to Trent months ago. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-16 21:04 Message: Logged In: YES user_id=31435 Trent, yuck. doctests are primarily documentation, and there's nothing about "." that suggests-- let alone screams --"ah, this line is really a blank line, not the period that it sure looks like". Too confusing. I'd be happy with this if it *screamed* "blank line", though! For example, accept as meaning it's really a blank line. In that case, though, note that: 1. The restriction about blank lines is documented in both doctest's docstrings and in the Library Manual, so this would also need doc changes in both places. and 2. doctest is self-testing, i.e. the standard test for doctest simply runs doctest on doctest. So in the very same place you document your blank line convention in the doctest docstring, you should also include an executable doctest example in the docstring. Then the standard test_doctest.py will verify that it works exactly as advertised forever more. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2001-03-11 13:40 Message: Logged In: YES user_id=34892 Grrr, the code I put in the comment is supposed to be indented of course. I will attach the test_doctest.py to clarify. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407764&group_id=5470 From noreply@sourceforge.net Fri Oct 19 02:10:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 18:10:42 -0700 Subject: [Patches] [ python-Patches-460805 ] Support for unsetenv() Message-ID: Patches item #460805, was opened at 2001-09-11 21:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Gonnerman (solomoriah) Assigned to: Thomas Wouters (twouters) Summary: Support for unsetenv() Initial Comment: The attached patch files implement os.unsetenv() for Python 2.1 and 2.2a3. os.py is extended to call unsetenv() when _Environ.__delitem__ is called. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-18 18:10 Message: Logged In: YES user_id=6380 Unassigned from Thomas. Thomas is too busy for patches. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-09-30 15:35 Message: Logged In: NO Then we should also switch to os.setenv instead of os.putenv (providing putenv for b/w compat, with a warning). --Guido ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-30 15:01 Message: Logged In: YES user_id=21627 A couple of comments: - standards conformance: unsetenv is in the latest drafts for IEEE 1003.1 (posix), so it will appear in all relevant standards soon (posix, single unix). BTW, Posix will chose setenv over putenv. - can't be done otherwise: not true. You can certainly clear it from os.environ, and pass that to os.execve. - code bloat: this will be requested over and over again, see bug #465467. - emulating it by setting an empty string: please no. Silently doing something that the user has not requested is not good. I'd rather prefer __delitem__ to raise an exception if the system does not support deleting environment variables. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-09-14 06:37 Message: Logged In: YES user_id=34209 Yes, that was my point: better clear it than leave it. It's the closest approximation we have, and it's better than nothing. I guess I'm also a certified and card-bearing old-timer :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-14 06:25 Message: Logged In: YES user_id=6380 On the other hand, setting to "" is better than nothing, and I believe that (because unset isn't universally supported in shells either) defensive programming takes an empty environment variable the same as an absent one. That's certainly how I've learned to use getenv(). But maybe that qualifies me as an oldtimer. :-) ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-14 04:58 Message: Logged In: YES user_id=321948 I didn't fake unsetenv() on all platforms because it's not really "fake". putenv(key, "") actually removes the given environment variable on Win32 ('nt') and I think on OS/2 and DOS as well. On Unix platforms it does not, and I feel it's a mistake to have unsetenv() and not have it actually work. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-09-14 02:34 Message: Logged In: YES user_id=34209 You don't have to submit a patch for 2.1, 2.1.1 was the final 2.1 release, and a patch like this would never make it into a patch release anyway. The unsetenv function looks good. The os.py changes don't make a whole lot of sense, however. Why not fake unsetenv on all platforms ? It's a simple matter of a 'hasattr()'. Setting the environment variable to an empty string on delete is more preferable than the current behaviour, I think. We could also fake it in C, though that means the other platform modules that aren't build from posix.c (riscos, macos, etc). ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-13 20:36 Message: Logged In: YES user_id=321948 You asked for it... attached now is an updated patchfile set for 2.1 and 2.2 with unsetenv() bindings for Windows; I defined unsetenv(key) in terms of putenv(key, "") if os.name is 'os2', 'nt', or 'dos' (I'm pretty sure that's right for DOS if anyone can build the rest of Python for that platform; I'm not so sure about OS/2). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-13 09:33 Message: Logged In: YES user_id=6380 Excellent, Thomas. I was waiting for someone to champion this. I hope you don't mind that I assigned it to you. Go ahead and review the code and decide what to do! ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-09-13 08:50 Message: Logged In: YES user_id=34209 Sorry, Guido, but I have to agree with Chris here. You *can't* do without unsetenv. Setting the environment variable to an empty string is not the same as removing it. unsetenv() appeared in BSD4.3, so it is a lot more standard than, say, LFS support, or some of the other functions we define in the posix module. It's easy to test for, it introduces no problems wrt. prototypes or such, and it provides functionality that's not available otherwise. Unsetting environment variables can't be done portably, but we can't do it *at all* right now. Making 'del' work the expected way (by using unsetenv, or faking it using os.putenv(key, "") seems very useful to me -- in fact, I was suprised os.environ didn't already do that! I definately do not see this as code bloat. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-13 08:36 Message: Logged In: YES user_id=6380 Lots of speculation there, but no motivation beyond "it's not Pythonic". IMO it's very Pythonic not to provide features that are rarely needed and can easily be done without. But who am I to judge. :-) If you give me a patch that implemens "del os.environ[key]" by calling os.putenv(key, ""), I'll accept it in a jiffy. ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 21:08 Message: Logged In: YES user_id=321948 Ouch. It's in AT&T/USL/SCO Unix AFAIK, it's in NetBSD and GNU libc for sure, and the other BSD's also I believe; Win32 provides a different way to do it, but there is a way. I think Solaris has it also but I can't easily check. De facto standards are important too. As for the bloat argument, my patch adds a tiny function to posixmodule and a tiny method to os._Environ (in the Unix version only at this point); my Python 2.1 interpreter gained a couple hundred bytes. Code bloat is when you add unnecessary features to a module. Python has *no other way* to remove an environment variable so that child processes don't see it, so Python's behavior is broken. It is IMHO not Pythonic to have del os.environ["HOME"] (for instance) not work correctly. From the perspective of the calling module, there is no longer a HOME variable, but called processes will still see it. It's true, you can set the variable to a null string, but this isn't the same thing and might not satisfy some secure programming requirements. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 18:31 Message: Logged In: YES user_id=6380 Code bloat. If it's not important enough to standardize in POSIX (or one of the other standards), why should we add it? GNU code is infamous for always including more features, needed or not. If you're cynical, this is part of a Microsoft-like "buy-in" strategy (code developed for GNU libc doesn't work anywhere else). ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 18:20 Message: Logged In: YES user_id=321948 By the way, I found the following note in the man pages for NetBSD: The functions setenv() and unsetenv() appeared in Version 7 AT&T UNIX. so it appears, standard or not, that most real Unix systems should have it. Regarding the minimal utility argument, I don't currently have a use for it, but it came up on the mailing list so I wrote it. It's recommended, when writing sysadmin tools which call other programs, to "clean up" the environment so that only known-safe values are in there before calling the externals. ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 18:14 Message: Logged In: YES user_id=321948 Well, the only place I know of that it is standardized is in GNU libc. That's not entirely the point, though. 1) If you do 'del os.environ["SOMEVAR"]' you remove SOMEVAR from the copy of the environment but not from the real environment. This behavior IMHO is broken. 2) It's true, many OS's don't have unsetenv(). However, my patch falls back to the *current* behavior if unsetenv() is not available. In other words, this doesn't break Python any more than it's already broken, and it's a net gain for operating systems that *do* have unsetenv(). I figure if some gain and none lose, why not do it? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 06:38 Message: Logged In: YES user_id=6380 Can you point to where unsetenv is standardized? I'm worried that it's not available on standard-conforming Unix systems, and since it's of marginal utility at best, I'm not sure what the point is to add it -- unless there's a clear standard that ensures its existence. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 From noreply@sourceforge.net Fri Oct 19 02:19:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 18:19:01 -0700 Subject: [Patches] [ python-Patches-443759 ] Add Interface to readline's add_history Message-ID: Patches item #443759, was opened at 2001-07-23 04:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443759&group_id=5470 Category: Modules Group: None >Status: Closed Resolution: Accepted Priority: 3 Submitted By: Moshe Zadka (moshez) >Assigned to: Guido van Rossum (gvanrossum) Summary: Add Interface to readline's add_history Initial Comment: There is a function in GNU readline called add_history, which is used to manage the history list. Though Python uses this function internally, it does not expose it to the Python programmer. This patch adds direct interface to this function with documentation. This could be used by friendly modules to "seed" the history with commands. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-18 18:19 Message: Logged In: YES user_id=6380 I lost my patience and checked this in. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-07 09:58 Message: Logged In: YES user_id=21627 This patch looks perfect to me. Please check it in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443759&group_id=5470 From noreply@sourceforge.net Fri Oct 19 02:32:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 18:32:28 -0700 Subject: [Patches] [ python-Patches-407764 ] allow whitespace lines for doctest tests Message-ID: Patches item #407764, was opened at 2001-03-11 13:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407764&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Trent Mick (tmick) >Assigned to: Nobody/Anonymous (nobody) Summary: allow whitespace lines for doctest tests Initial Comment: Currently doctest.py does not allow individual tests to have all-whitespace output lines. This patch proposes a fix for this. With this patch a leading '.' on a doctest output line, if and only if the tests are indented, will signal that following whitespace *is* the expected output. For example, currently this cannot be doctest'ed """ >>> print "\nhello\n" hello >>> """ But with this patch *this* can be: # file test_doctest.py """ >>> print "\nhello\n" . hello . >>> """ def _test(): import doctest, test_doctest return doctest.testmod(test_doctest) if __name__ == "__main__": _test() ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-10-18 18:32 Message: Logged In: YES user_id=31435 Because half a year ago , I was hoping for Trent to update the patch as suggested. Rejected now for lack of hope. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-18 18:01 Message: Logged In: YES user_id=6380 Why not just close this as Rejected? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-06-04 11:32 Message: Logged In: YES user_id=31435 Should have assigned this back to Trent months ago. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-16 21:04 Message: Logged In: YES user_id=31435 Trent, yuck. doctests are primarily documentation, and there's nothing about "." that suggests-- let alone screams --"ah, this line is really a blank line, not the period that it sure looks like". Too confusing. I'd be happy with this if it *screamed* "blank line", though! For example, accept as meaning it's really a blank line. In that case, though, note that: 1. The restriction about blank lines is documented in both doctest's docstrings and in the Library Manual, so this would also need doc changes in both places. and 2. doctest is self-testing, i.e. the standard test for doctest simply runs doctest on doctest. So in the very same place you document your blank line convention in the doctest docstring, you should also include an executable doctest example in the docstring. Then the standard test_doctest.py will verify that it works exactly as advertised forever more. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2001-03-11 13:40 Message: Logged In: YES user_id=34892 Grrr, the code I put in the comment is supposed to be indented of course. I will attach the test_doctest.py to clarify. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=407764&group_id=5470 From noreply@sourceforge.net Fri Oct 19 02:33:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 18:33:14 -0700 Subject: [Patches] [ python-Patches-460805 ] Support for unsetenv() Message-ID: Patches item #460805, was opened at 2001-09-11 21:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 >Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Chris Gonnerman (solomoriah) >Assigned to: Guido van Rossum (gvanrossum) Summary: Support for unsetenv() Initial Comment: The attached patch files implement os.unsetenv() for Python 2.1 and 2.2a3. os.py is extended to call unsetenv() when _Environ.__delitem__ is called. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-18 18:33 Message: Logged In: YES user_id=6380 Checked in, just in time for 2.2b1. Thomas is apparently not paying attention to SourceForge these days. Thanks, Chris! XXX Should we add setenv as an alias to putenv to the os/posix modules, and make that the preferred name? Sounds more consistent to have getenv, setenv, unsetenv than getenv, putenv, unsetenv. :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-18 18:10 Message: Logged In: YES user_id=6380 Unassigned from Thomas. Thomas is too busy for patches. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-09-30 15:35 Message: Logged In: NO Then we should also switch to os.setenv instead of os.putenv (providing putenv for b/w compat, with a warning). --Guido ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-30 15:01 Message: Logged In: YES user_id=21627 A couple of comments: - standards conformance: unsetenv is in the latest drafts for IEEE 1003.1 (posix), so it will appear in all relevant standards soon (posix, single unix). BTW, Posix will chose setenv over putenv. - can't be done otherwise: not true. You can certainly clear it from os.environ, and pass that to os.execve. - code bloat: this will be requested over and over again, see bug #465467. - emulating it by setting an empty string: please no. Silently doing something that the user has not requested is not good. I'd rather prefer __delitem__ to raise an exception if the system does not support deleting environment variables. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-09-14 06:37 Message: Logged In: YES user_id=34209 Yes, that was my point: better clear it than leave it. It's the closest approximation we have, and it's better than nothing. I guess I'm also a certified and card-bearing old-timer :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-14 06:25 Message: Logged In: YES user_id=6380 On the other hand, setting to "" is better than nothing, and I believe that (because unset isn't universally supported in shells either) defensive programming takes an empty environment variable the same as an absent one. That's certainly how I've learned to use getenv(). But maybe that qualifies me as an oldtimer. :-) ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-14 04:58 Message: Logged In: YES user_id=321948 I didn't fake unsetenv() on all platforms because it's not really "fake". putenv(key, "") actually removes the given environment variable on Win32 ('nt') and I think on OS/2 and DOS as well. On Unix platforms it does not, and I feel it's a mistake to have unsetenv() and not have it actually work. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-09-14 02:34 Message: Logged In: YES user_id=34209 You don't have to submit a patch for 2.1, 2.1.1 was the final 2.1 release, and a patch like this would never make it into a patch release anyway. The unsetenv function looks good. The os.py changes don't make a whole lot of sense, however. Why not fake unsetenv on all platforms ? It's a simple matter of a 'hasattr()'. Setting the environment variable to an empty string on delete is more preferable than the current behaviour, I think. We could also fake it in C, though that means the other platform modules that aren't build from posix.c (riscos, macos, etc). ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-13 20:36 Message: Logged In: YES user_id=321948 You asked for it... attached now is an updated patchfile set for 2.1 and 2.2 with unsetenv() bindings for Windows; I defined unsetenv(key) in terms of putenv(key, "") if os.name is 'os2', 'nt', or 'dos' (I'm pretty sure that's right for DOS if anyone can build the rest of Python for that platform; I'm not so sure about OS/2). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-13 09:33 Message: Logged In: YES user_id=6380 Excellent, Thomas. I was waiting for someone to champion this. I hope you don't mind that I assigned it to you. Go ahead and review the code and decide what to do! ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-09-13 08:50 Message: Logged In: YES user_id=34209 Sorry, Guido, but I have to agree with Chris here. You *can't* do without unsetenv. Setting the environment variable to an empty string is not the same as removing it. unsetenv() appeared in BSD4.3, so it is a lot more standard than, say, LFS support, or some of the other functions we define in the posix module. It's easy to test for, it introduces no problems wrt. prototypes or such, and it provides functionality that's not available otherwise. Unsetting environment variables can't be done portably, but we can't do it *at all* right now. Making 'del' work the expected way (by using unsetenv, or faking it using os.putenv(key, "") seems very useful to me -- in fact, I was suprised os.environ didn't already do that! I definately do not see this as code bloat. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-13 08:36 Message: Logged In: YES user_id=6380 Lots of speculation there, but no motivation beyond "it's not Pythonic". IMO it's very Pythonic not to provide features that are rarely needed and can easily be done without. But who am I to judge. :-) If you give me a patch that implemens "del os.environ[key]" by calling os.putenv(key, ""), I'll accept it in a jiffy. ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 21:08 Message: Logged In: YES user_id=321948 Ouch. It's in AT&T/USL/SCO Unix AFAIK, it's in NetBSD and GNU libc for sure, and the other BSD's also I believe; Win32 provides a different way to do it, but there is a way. I think Solaris has it also but I can't easily check. De facto standards are important too. As for the bloat argument, my patch adds a tiny function to posixmodule and a tiny method to os._Environ (in the Unix version only at this point); my Python 2.1 interpreter gained a couple hundred bytes. Code bloat is when you add unnecessary features to a module. Python has *no other way* to remove an environment variable so that child processes don't see it, so Python's behavior is broken. It is IMHO not Pythonic to have del os.environ["HOME"] (for instance) not work correctly. From the perspective of the calling module, there is no longer a HOME variable, but called processes will still see it. It's true, you can set the variable to a null string, but this isn't the same thing and might not satisfy some secure programming requirements. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 18:31 Message: Logged In: YES user_id=6380 Code bloat. If it's not important enough to standardize in POSIX (or one of the other standards), why should we add it? GNU code is infamous for always including more features, needed or not. If you're cynical, this is part of a Microsoft-like "buy-in" strategy (code developed for GNU libc doesn't work anywhere else). ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 18:20 Message: Logged In: YES user_id=321948 By the way, I found the following note in the man pages for NetBSD: The functions setenv() and unsetenv() appeared in Version 7 AT&T UNIX. so it appears, standard or not, that most real Unix systems should have it. Regarding the minimal utility argument, I don't currently have a use for it, but it came up on the mailing list so I wrote it. It's recommended, when writing sysadmin tools which call other programs, to "clean up" the environment so that only known-safe values are in there before calling the externals. ---------------------------------------------------------------------- Comment By: Chris Gonnerman (solomoriah) Date: 2001-09-12 18:14 Message: Logged In: YES user_id=321948 Well, the only place I know of that it is standardized is in GNU libc. That's not entirely the point, though. 1) If you do 'del os.environ["SOMEVAR"]' you remove SOMEVAR from the copy of the environment but not from the real environment. This behavior IMHO is broken. 2) It's true, many OS's don't have unsetenv(). However, my patch falls back to the *current* behavior if unsetenv() is not available. In other words, this doesn't break Python any more than it's already broken, and it's a net gain for operating systems that *do* have unsetenv(). I figure if some gain and none lose, why not do it? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-12 06:38 Message: Logged In: YES user_id=6380 Can you point to where unsetenv is standardized? I'm worried that it's not available on standard-conforming Unix systems, and since it's of marginal utility at best, I'm not sure what the point is to add it -- unless there's a clear standard that ensures its existence. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470 From noreply@sourceforge.net Fri Oct 19 02:42:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 18:42:56 -0700 Subject: [Patches] [ python-Patches-470394 ] Fix keyword arguments with wrapper funcs Message-ID: Patches item #470394, was opened at 2001-10-11 14:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470394&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Guido van Rossum (gvanrossum) Summary: Fix keyword arguments with wrapper funcs Initial Comment: What summary says. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-18 18:42 Message: Logged In: YES user_id=6380 Thanks! I don't know why I didn't notice this patch earlier. :-( Unfortunately, the patch as it stands now causes tons of compiler warnings because most of the wrapper functions aren't declared with the extra argument. I'll think about this. I may put this off until after 2.2b1 is out -- it's clearly a bug fix IMO so won't be affected by the post-beta-1 feature freeze. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-10-12 02:58 Message: Logged In: YES user_id=21627 Please resubmit the patch, using the following procedure: - log into SF. This is a prerequisite for modifiying your uploads later - set the check box on "Check to Upload & Attach File" - give some description of what problem the patch solves. The URL you've given is invalid; there is no /people on people.redhat.com. Leaving that out, http://people.redhat.com/sopwith/python-wrapkwargs.patch returns an empty file. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-10-11 14:38 Message: Logged In: NO Aaargh, sourceforge patch upload is broken. Please get the patch at http://people.redhat.com/people/sopwith/python-wrapkwargs.patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470394&group_id=5470 From noreply@sourceforge.net Fri Oct 19 02:46:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 18:46:50 -0700 Subject: [Patches] [ python-Patches-470393 ] Add missing marshal function Message-ID: Patches item #470393, was opened at 2001-10-11 14:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470393&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: James C. Ahlstrom (ahlstromjc) >Assigned to: Guido van Rossum (gvanrossum) Summary: Add missing marshal function Initial Comment: In Include/, marshal.h declares both PyMarshal_ReadLongFromFile() and PyMarshal_ReadShortFromFile(), but the second is missing from marshal.c. Here is the patch: *** marshal.old Thu Oct 11 17:27:09 2001 --- marshal.c Thu Oct 11 17:27:24 2001 *************** *** 635,640 **** --- 635,648 ---- } } + int + PyMarshal_ReadShortFromFile(FILE *fp) + { + RFILE rf; + rf.fp = fp; + return r_short(&rf); + } + long PyMarshal_ReadLongFromFile(FILE *fp) { ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-18 18:46 Message: Logged In: YES user_id=6380 Thanks! Checked in. (Wasn't there a documentation task related to this too?) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=470393&group_id=5470 From noreply@sourceforge.net Fri Oct 19 02:48:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 18:48:10 -0700 Subject: [Patches] [ python-Patches-468457 ] Minor changes to sre.Scanner Message-ID: Patches item #468457, was opened at 2001-10-05 18:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468457&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) >Assigned to: Fredrik Lundh (effbot) Summary: Minor changes to sre.Scanner Initial Comment: I've been experimenting with sre.Scanner as a token generator for the spark parser. The following patch makes three changes. The first I believe is a bug fix (though perhaps I am not using the Scanner class as expected); the other two are enhancement suggestions: 1) In my experience with the current sre.Scanner, if the first pattern in the lexicon matches, an exception is raised because match.lastindex == None (and so cannot be used as an index into the lexicon list). I think this is because the first pattern's subgroup id equals 0. Changing the subgroup setup loop so that the group ids start with 1 eliminates this exception. 2) I needed to use case-insensitive matching for the tokens, and adding (?i) to the patterns didn't work. I believe that to get the pattern compiled using flags, they have to be set in the sre_parse.Pattern object which is allocated in Scanner.__init__; this will not happen with the current Scanner because the calls to sre_parse.parse(phrase) don't have access to the top-level Pattern object, so they can't set the flags in it. I added an optional flags parameter to the Scanner class's constructor which allows setting global flags for compilation of the lexicon patterns. 3) Looking in _sre.c, I found the internal scanner object, which allows repeated matching over a string. This object looks ready-made for this kind of scanning, so I changed Scanner.scan to use it. I've marked each change line with the number of the change (1, 2, or 3) with which it is associated. As for docs and tests, I'm not sure what (if anything) to add, since none exist for the current Scanner class. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468457&group_id=5470 From noreply@sourceforge.net Fri Oct 19 02:52:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 18:52:01 -0700 Subject: [Patches] [ python-Patches-462628 ] NNTPLib supports saving BODY to a file Message-ID: Patches item #462628, was opened at 2001-09-18 11:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462628&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Travers Naran (tnaran) >Assigned to: Guido van Rossum (gvanrossum) Summary: NNTPLib supports saving BODY to a file Initial Comment: I modified nntplib so the body method can accept an optional second parameter pointing to a filehandle or filename (string). This way, really long body articles can be stored to disk instead of kept in memory. The way I made the modification should make it easy to extend this functionality to other extended return methods. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-18 18:52 Message: Logged In: YES user_id=6380 This was checked on on Oct 1st. Thanks! (More recently, the argument 'fileHandle' was renamed to 'file' since it's not always a file handle and besides, we don't call them that. ;-) ---------------------------------------------------------------------- Comment By: Travers Naran (tnaran) Date: 2001-09-30 17:51 Message: Logged In: YES user_id=326902 OK, I've made the requested changes. It returns an empty list ([]) when using a file, and I've tested the three variations of the call: no file parameter (returns a list of lines), a string file parameter (returns an empty list and creates a file and closes it), and a file object (returns an empty list, uses the file object w/o closing it). I've moved the critical file opening/closing to getlongresp (). This should make it trivial to extend the other long response commands should the need arise. I've also updated the documentation. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-30 11:58 Message: Logged In: YES user_id=6380 Ah, the one-liner syndrome. :-) Better take it out, and make sure to explicitly close the file in case you pass a filename (on the other hand, when an open file is passed, definitely *don't* close it). ---------------------------------------------------------------------- Comment By: Travers Naran (tnaran) Date: 2001-09-28 20:19 Message: Logged In: YES user_id=326902 I thought so too until I wrote this line in my NewsProwler program: response, dummy1, id, body = nntp.body(str (article_index),tempfile.TemporaryFile()) Now true, one could use: body = tempFile.TemporaryFile() response, dummy1, id, dummy2 = nntp.body(str (article_index),body) # or don't return the 4th parameter at all response, dummy1, id = nntp.body(str(article_index),body) But I thought preserving the semantic meaning of the return would be nice (the 4th parameter representing the article body). To be honest, I'm not wed to this convention. I'm more than willing to change it to whatever you think is best. I'm just happy I can contribute something! :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-28 06:41 Message: Logged In: YES user_id=6380 Much better. Question though: what's the point of returning the open file? Wouldn't it make more sense to return an empty list, which the caller could ignore? ---------------------------------------------------------------------- Comment By: Travers Naran (tnaran) Date: 2001-09-27 18:13 Message: Logged In: YES user_id=326902 I've made the requested changes. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-24 08:38 Message: Logged In: YES user_id=6380 Thanks. The patch is missing two things before it can be accepted: change to docstrings explaining the new argument, and changes to the documentation (Doc/lib/libnntplib.tex). If you don't know LaTeX, just imitate what you see there and our LaTeX expert will fix it up -- however you have to write the documentation yourself. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462628&group_id=5470 From noreply@sourceforge.net Fri Oct 19 02:53:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 18:53:45 -0700 Subject: [Patches] [ python-Patches-468394 ] Allow xmlrpclib to handle long ints Message-ID: Patches item #468394, was opened at 2001-10-05 13:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468394&group_id=5470 Category: Library (Lib) Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: Allow xmlrpclib to handle long ints Initial Comment: xmlrpclib currently raises an exception when passed a long int, even if it int(N) doesn't raise OverflowError. The attached patch adds a dump_long method to the Marshaller class. It makes no attempt to recover from an out-of-range long, letting the user catch the resulting OverflowError. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-18 18:53 Message: Logged In: YES user_id=6380 Looks like (something like) this was committed, so I'll close this. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-10-09 01:48 Message: Logged In: YES user_id=21627 When committing the patch, please add a line to the History: in the file ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-10-09 00:42 Message: Logged In: YES user_id=21627 The patch looks good to me. Please apply it. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-10-05 13:24 Message: Logged In: YES user_id=44345 Damn... Something seems amiss with Opera's file upload capability. It's a short patch, included here: *** /tmp/skip/xmlrpclib.py.~1.11~ Fri Oct 5 15:14:45 2001 --- /tmp/skip/xmlrpclib.py Fri Oct 5 15:14:45 2001 *************** *** 464,469 **** --- 464,474 ---- self.write("%s\n" % value) dispatch[IntType] = dump_int + def dump_long(self, value): + val = int(value) + self.write("%s\n" % val) + dispatch[LongType] = dump_long + def dump_double(self, value): self.write("%s\n" % value) dispatch[FloatType] = dump_double ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=468394&group_id=5470 From noreply@sourceforge.net Fri Oct 19 03:05:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 19:05:49 -0700 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: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: M.-A. Lemburg (lemburg) 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: 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 Fri Oct 19 03:09:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 19:09:52 -0700 Subject: [Patches] [ python-Patches-443899 ] Minor fix to gzip.py module. Message-ID: Patches item #443899, was opened at 2001-07-23 12:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443899&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Titus Brown (titus) Assigned to: Jeremy Hylton (jhylton) Summary: Minor fix to gzip.py module. Initial Comment: --- from cStringIO import StringIO from gzip import GzipFile stringFile = StringIO() gzFile = GzipFile("test1", 'wb', 9, stringFile) gzFile.write('howdy there!') r = gzFile.read() --- the above code fragment gave a nonintuitive error response (attribute missing). Now, an exception is raised stating that the file is not opened for reading or writing. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-18 19:09 Message: Logged In: YES user_id=6380 Time to look at this again? ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-08-16 13:33 Message: Logged In: YES user_id=23486 Re: context diff, thanks & sorry for the trouble; my newer patches are being submitted this way. Re: IOError, I wasn't sure which exception to use at the time. I therefore took my cue from other code in the gzip module, which raises a ValueError when self.fileobj is closed. The only IO errors raised in the module are those that pertain to incorrect file formats. I'd be happy to change any and all of the ValueErrors that are raised into IOErrors, but I think the current consistency of errors should be maintained ;). ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-08-16 11:42 Message: Logged In: YES user_id=21627 Please always submit context (-c) or unified (-u) diffs; I've reformatted your patch by retrieving 1.24, applying the patch, updating to the current version, and regenerating the patch. Apart from that, the patch looks fine to me, and I recommend to approve it. One consideration is the exception being raised: Maybe IOError is more appropriate. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2001-08-14 12:15 Message: Logged In: YES user_id=23486 (sorry -- misunderstanding of how the changelog view works) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=443899&group_id=5470 From noreply@sourceforge.net Fri Oct 19 03:10:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 19:10:10 -0700 Subject: [Patches] [ python-Patches-452110 ] socketmodule ssl: server & thread Message-ID: Patches item #452110, was opened at 2001-08-17 08:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452110&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jozef Hatala (jhatala) Assigned to: Jeremy Hylton (jhylton) Summary: socketmodule ssl: server & thread Initial Comment: Simple enhancement to the SSL support in module socket : - support for writing SSL servers (as well as clients) - Py_*_ALLOW_THREADS arround blocking calls to openssl - rsa temp key to work with older export netscape - renamed attribute server to peer This patch allows for powerfull application servers like the following one to be accessed with "netscape https://localhost:1443/" from socket import * p=socket(AF_INET,SOCK_STREAM) p.bind(('localhost',1443)) p.listen(1) while 1 : s,a = p.accept() c = sslserver(s,'server.key','server.crt') print "They said:", c.read() c.write('HTTP/1.0 200 OK\r\n') c.write('Content-Type: text/plain\r\n\r\n** Hi! **') c.close() TODO: a kind of makefile() on the ssl object like on a socket would be welcome. Have fun, jh ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-18 19:10 Message: Logged In: YES user_id=6380 Time to look at this again? ---------------------------------------------------------------------- Comment By: Jozef Hatala (jhatala) Date: 2001-10-17 07:43 Message: Logged In: YES user_id=300564 This patch now against Python 2.2a3 contains: SSL server support (SSL_accept) [as before] additionally: allow threads around getaddrinfo &Co. more verbose exc messages (for failures in ssl() and sslserver()) methods recv and send on ssl object as equivalents of read and write. methods makefile on ssl object (a look-alike and does no dup!) a client/server test (depends on os.fork()) ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-10-16 09:05 Message: Logged In: YES user_id=31392 If you can provide test cases, I'll provide documentation. But hurry, if we don't get this done this week, we may miss Python 2.2. ---------------------------------------------------------------------- Comment By: Jozef Hatala (jhatala) Date: 2001-10-16 03:21 Message: Logged In: YES user_id=300564 I'll submit a simple test with certificates and an enhanced patch for 2.2a2 (does not patch cleanly any more) soon (this week) [time and inet access issues]. I haven't written any doc. There was none for ssl. I know that is no excuse... Does some-one volonotere? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-10-11 09:13 Message: Logged In: YES user_id=31392 Jozef-- are you going to contribute tests and documentation? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 23:17 Message: Logged In: YES user_id=6380 Nice, but where's the documentation? (Thanks for the docstrings though!) And the test suite? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452110&group_id=5470 From noreply@sourceforge.net Fri Oct 19 07:22:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Oct 2001 23:22:52 -0700 Subject: [Patches] [ python-Patches-460751 ] --with-shared: python with shared lib Message-ID: Patches item #460751, was opened at 2001-09-11 14:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460751&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Martin v. Lцwis (loewis) Summary: --with-shared: python with shared lib Initial Comment: As a follow up to patch 400938 (https://sourceforge.net/tracker/?group_id=5470&atid=305470&func=detail&aid=400938), here is an implementation of the --with-shared configure option for building python on Posix systems as a shared library. Building python as shared library is activated with the --with-shared option on ./configure The following points are drawn to particular attention: - A configbuild.py module is generated and placed in the machine-dependent directory. It records most Python/Makefile variables (CC, CFLAG, LDSHARED...), and make them available in Python. - The build has been tested on: Linux2: OK SunOS5: OK IRIX64: Build OK, crash on test (bus error) - Inference with distutils: I found it very difficult understanding the distutil architecture and finding the right points of change; I minimized my interaction there. Furthermore, the availability of the 'configbuild' module overlaps some of the distutils; but 'configbuild' is very easy to use ... - Unresolved symbols: I turned on the symbol checking flags whenever possible, on behalf the its better generating the error on build than at runtime. - configure.in: I only edited the configure Bourne script, and did not bother with configure.in (actually, I deleted it) and its autoconfig/m4 macro comparses. Frederic Giacometti ---------------------------------------------------------------------- >Comment By: Martin v. Lцwis (loewis) Date: 2001-10-18 23:22 Message: Logged In: YES user_id=21627 Now that the 2.2b1 branch has been created, we effectively have a feature freeze. That means that this feature will not appear in 2.2. Since the patch isn't ready yet, I'll reject it. If you (or anybody else) revises this patch for use in Python 2.3, please submit a new patch. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-27 17:37 Message: Logged In: YES user_id=93657 Martin, You should add the following patch, too: =================================================================== RCS file: /mgl/home/fredg/cvs/Python/Lib/distutils/command/build_ext.py,v retrieving revision 1.1.1.1.2.6 retrieving revision 1.1.1.1.2.7 diff -r1.1.1.1.2.6 -r1.1.1.1.2.7 100c100 < self.library_dirs = ['.'] --- > self.library_dirs = ['.', sysconfig.get_config_var( 'LIBDIR')] It is required to build third party modules with distutils. [Actually, I have now 'PLATLIBDIR' instead of 'LIBDIR', so as to differentiate 'platform-independent libdir' from 'platform-specific libdir'.... but I know you don't want to see that here]. Afterhand, I think one would have avoided much of the arguments if the configure.in, Makefile.pre.in and other files associated to the configure/build/install process were commented/documented, structured, and laid out up to "Open Source" standards. Just an idea... Cheers, FG ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-26 03:00 Message: Logged In: YES user_id=21627 I cannot review the patch until I know what chunks of it you mean to submit, and which ones you don't; there are numerous chunks which I will not commit into Python. For the moment, the only thing that is still broken is IPv6 configuration. config.log says configure:4306: checking if --enable-ipv6 is specified configure:4345: gcc -o conftest -g -O2 conftest.c -lpthread -ldl -lthread 1>&5 /var/tmp/ccgOnzLA.o: In function `main': /vol/home-vol1/simulant/loewis/python/dist/src/configure:4337: undefined reference to `socket' So once you've fixed that, please submit a patch that you'd consider final (i.e. completely edited). To simplify further revisions of this final patch, I recommend that you check out a separate Python tree into a fresh directory from CVS, and develop the patch in this directory. This should simplify only including pieces meant to be part of this patch; no editing of the patch would be necessary. If you don't have the disk space for a separate copy, I recommend to use the SourceForge compile farm. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-25 14:53 Message: Logged In: YES user_id=93657 Martin, here is a patch update. - I fixed the missing library problem on bulding statically the main Python. The static build work now. I had not tested it yesterday; I was losing myself in patch/autoconf pb instead. - The configure script is now generated from configure.in, with autoconf. Thanks for your help on this. For the patch division issue, I propose to work in two steps: 1) First the global patch working 2) When the global patch works, I'll edit manually the diff file, and create the independent patch files, as well as will remove what I need to troubleshoot the thing. This work is no small piece of cake (at least for me). Please keep in mind that I patch everything from a Python 2.1.1 branch; which is the one in production, and I'd rather keep the manual editing of the patch to the end, as the last step; especially since this is no straightforward business, technically. Otherwise, yes, I've been maintaining my own branch, fortunately. Thanks, FG ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-25 14:51 Message: Logged In: YES user_id=93657 Martin, here is a patch update. - I fixed the missing library problem on bulding statically the main Python. The static build work now. I had not tested it yesterday; I was losing myself in patch/autoconf pb instead. - The configure script is now generated from configure.in, with autoconf. Thanks for your help on this. For the patch division issue, I propose to work in two steps: 1) First the global patch working 2) When the global patch works, I'll edit manually the diff file, and create the independent patch files, as well as will remove what I need to troubleshoot the thing. This work is no small piece of cake (at least for me). Please keep in mind that I patch everything from a Python 2.1.1 branch; which is the one in production, and I'd rather keep the manual editing of the patch to the end, as the last step; especially since this is no straightforward business, technically. Otherwise, yes, I've been maintaining my own branch, fortunately. Thanks, FG ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-25 06:27 Message: Logged In: YES user_id=6380 Martin, feel free to reject and close this. Frederic's attitude has been impossible to deal with, here and in other cases. Frederic, the real issues here are non-technical -- you appear unable to understand and adapt to the conventions of open source development that almost every other contributor picks up without effort. We don't have the time to educate you -- we've tried and failed. We'll continue to review your patches, but we'll be quick to reject them if you continue to ignour our conventions, which have served Python and the Python community well over the years. Feel free to maintain your own fork of the Python sources -- that may be less of a waste of time for all of us. ---------------------------------------------------------------------- Comment By: Martin v. Lцwis (loewis) Date: 2001-09-25 03:37 Message: Logged In: YES user_id=21627 PLEASE do not put unrelated changes into your patches. What does "--with-shared: python with shared lib" have to do with removing @ prefixes in the makefile???? I'm close to giving up reviewing your patches, and waiting for somebody else to reject them. Likewise, why did you remove the makedepend support? It may be broken, but the objective of this patch has nothing to do with this. Same for reconfigure; to re-run configure with the same options, just invoke 'make'. If you think there is a problem, report a bug. The problem with the generated configure not recognizing --with-shared is that you put the AC_ARG_WITH after the check for build_as_shared into configure.in. Just move the AC_ARG_WITH somewhat up. Never use ld to link on Unix, always use $(CC); otherwise, people will complain that linking in C++ modules will fail. To pass options to the linker using the SunPRO compiler, use the -Wl,