From noreply at sourceforge.net Sat Nov 1 00:35:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 1 00:35:21 2003 Subject: [Patches] [ python-Patches-834015 ] Remove imports of unused modules Message-ID: Patches item #834015, was opened at 2003-11-01 14:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=834015&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: Remove imports of unused modules Initial Comment: This is a patch to remove import statements of unused modules. As far as I've checked, these modules are not used inside the scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=834015&group_id=5470 From noreply at sourceforge.net Sat Nov 1 18:20:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 1 18:20:55 2003 Subject: [Patches] [ python-Patches-599331 ] PEP 269 Implementation Message-ID: Patches item #599331, was opened at 2002-08-23 12:03 Message generated for change (Comment added) made by jriehl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599331&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: Later Priority: 1 Submitted By: Jon Riehl (jriehl) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 269 Implementation Initial Comment: The following are files for the implementation of PEP 269. The primary changes to the core involve moving required pgen modules from the pgen only module list to the Python library module list in Makefile.pre.in. Some of the modules required better memory allocation and management and the corresponding deallocators are in the Python extension module (maybe these should be moved into the pgen modules in Parser). Initially included are two implementations. The first is a basic implementation that follows the PEP API more or less. The second (currently unfinished) implementation provides a more object oriented interface to the extension module. Please note there are some commented out modifications to setup.py as I was unable to build the extension module(s) automagically. For some reason the linker I was using (on a BSD box) complained that it couldn't find the _Py_pgen symbol, even though I verified its existence in the new Python library. Maybe it is checking against an older Python library on the system? Things to be done (as of initial submission) include resolving on a single interface, documenting the one true interface, and finishing any unimplemented routines (such as are found in the OO implementation). In the final integration, a pgenmodule.c file should be added to the Modules directory in the main distribution. ---------------------------------------------------------------------- >Comment By: Jon Riehl (jriehl) Date: 2003-11-01 17:20 Message: Logged In: YES user_id=22448 I am to some extent. I've done several wacky things, namely putting the pgen extension module into my Basil project (basically I think PEP 269 is dead), as well as re-written pgen in "pure" Python (no C extension module calls) The pure Python pgen looks like it will be going into Pypy. I don't know if I am interested in the speed enough to warrant serious analysis of the pgen C extension and the segmentation fault Guido reported. Let me know if you had anything specific in mind. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-31 07:54 Message: Logged In: YES user_id=21627 Jon, are you still interested in taking this further? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-17 10:12 Message: Logged In: YES user_id=6380 I've checked in the changes to the parser and Makefile etc. This means you should be able to distribute pgenmodule.c as a clean extension to Python 2.3. I've decided not to incorporate pgenmodule.c at this time. There are three problems with it as I see it: - The C coding style is really different, and makes it hard to read: 2-space indents instead of tabs, spaces before left parentheses in argument lists, space between * and name in things like "PyObject * name", placement of curly braces, reversal of arguments to comparisons (e.g. "NULL != x"), and long strings of underscores in comments. - The code isn't robust enough: I got a segfault (can't remember after what sequence of events, sorry), and it caused a SystemError (error return without exception set) when the grammar file couldn't be read. - The pgen API seems a bit strange -- some things that I would expect to be methods of AST objects are functions in the pgen module (even when a companion function *is* an AST method). - The unit test doesn't fit in the Python test framework. - I cooked up a little expression grammar and tried to parse a sample string, but all I got was exceptions. I guess I am missing something, but there's no tutorial that explains me how to do things (I was copying the code from test_pgen.py which works :-( ). Nevertheless, thanks for the work so far -- I'm sure at some point pgen will be usable from Python! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 15:44 Message: Logged In: YES user_id=6380 OK, reading the README now... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-05 10:42 Message: Logged In: YES user_id=6380 Closed. Jon, if you're still interested in this, upload something new and reopen the patch (or I can do that). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 11:32 Message: Logged In: YES user_id=6380 Lowering priority until Jon has his next version ready. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-12 23:35 Message: Logged In: YES user_id=6380 Cool. Maybe I'll get to it, maybe not. :-( ---------------------------------------------------------------------- Comment By: Jon Riehl (jriehl) Date: 2002-09-12 13:04 Message: Logged In: YES user_id=22448 Guido, as per my private message, I'll attempt to submit another patch by the end of the month, pending resumption of "work" on the 23rd. Commitment of the memory allocation patch is fine, and any future patches would be against the updated pgen code (I don't have commit permissions, so someone else will have to do this possibly.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-09 07:09 Message: Logged In: YES user_id=6380 I looked a bit, and it's very raw - the author admits that. Jon, are you still working on this? Do you have a more polished version? Maybe we can separate out the memory allocation patches and commit these already? They don't break anything. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 14:44 Message: Logged In: YES user_id=6380 I guess I'm going to hve to look at this to pronounce... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599331&group_id=5470 From noreply at sourceforge.net Sat Nov 1 22:43:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 1 22:43:39 2003 Subject: [Patches] [ python-Patches-832058 ] deprecate or fix buffer object Message-ID: Patches item #832058, was opened at 2003-10-28 23:53 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=832058&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Nobody/Anonymous (nobody) >Summary: deprecate or fix buffer object Initial Comment: This has not been well tested but I don't have time right now. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2003-11-02 03:43 Message: Logged In: YES user_id=35752 Attaching a patch that implements Greg Ewing's idea. Instead of storing the pointer and size to the buffer, the buffer interface is used each time they are needed. Again, not yet well tested. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=832058&group_id=5470 From noreply at sourceforge.net Sun Nov 2 01:42:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 01:42:19 2003 Subject: [Patches] [ python-Patches-834422 ] Implementation PEP 322: Reverse Iteration Message-ID: Patches item #834422, was opened at 2003-11-02 01:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=834422&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Implementation PEP 322: Reverse Iteration Initial Comment: See attached patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=834422&group_id=5470 From noreply at sourceforge.net Sun Nov 2 03:30:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 03:30:21 2003 Subject: [Patches] [ python-Patches-834444 ] add versionadd to new functions Message-ID: Patches item #834444, was opened at 2003-11-02 17:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=834444&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: add versionadd to new functions Initial Comment: "is_" and "is_not" were added to operator module in 2.3, but there's no mention of when these two functions were added in the documentation. I submitted a patch to add the version info about them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=834444&group_id=5470 From noreply at sourceforge.net Sun Nov 2 04:47:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 04:47:20 2003 Subject: [Patches] [ python-Patches-834015 ] Remove imports of unused modules Message-ID: Patches item #834015, was opened at 2003-11-01 00:35 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=834015&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: Remove imports of unused modules Initial Comment: This is a patch to remove import statements of unused modules. As far as I've checked, these modules are not used inside the scripts. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-02 04:47 Message: Logged In: YES user_id=80475 Applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=834015&group_id=5470 From noreply at sourceforge.net Sun Nov 2 04:53:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 04:53:07 2003 Subject: [Patches] [ python-Patches-834444 ] add versionadd to new functions Message-ID: Patches item #834444, was opened at 2003-11-02 03:30 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=834444&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: add versionadd to new functions Initial Comment: "is_" and "is_not" were added to operator module in 2.3, but there's no mention of when these two functions were added in the documentation. I submitted a patch to add the version info about them. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-02 04:53 Message: Logged In: YES user_id=80475 Accepted and applied. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=834444&group_id=5470 From noreply at sourceforge.net Sun Nov 2 13:35:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 13:35:44 2003 Subject: [Patches] [ python-Patches-599331 ] PEP 269 Implementation Message-ID: Patches item #599331, was opened at 2002-08-23 19:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599331&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: Later Priority: 1 Submitted By: Jon Riehl (jriehl) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 269 Implementation Initial Comment: The following are files for the implementation of PEP 269. The primary changes to the core involve moving required pgen modules from the pgen only module list to the Python library module list in Makefile.pre.in. Some of the modules required better memory allocation and management and the corresponding deallocators are in the Python extension module (maybe these should be moved into the pgen modules in Parser). Initially included are two implementations. The first is a basic implementation that follows the PEP API more or less. The second (currently unfinished) implementation provides a more object oriented interface to the extension module. Please note there are some commented out modifications to setup.py as I was unable to build the extension module(s) automagically. For some reason the linker I was using (on a BSD box) complained that it couldn't find the _Py_pgen symbol, even though I verified its existence in the new Python library. Maybe it is checking against an older Python library on the system? Things to be done (as of initial submission) include resolving on a single interface, documenting the one true interface, and finishing any unimplemented routines (such as are found in the OO implementation). In the final integration, a pgenmodule.c file should be added to the Modules directory in the main distribution. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-02 19:35 Message: Logged In: YES user_id=21627 I was wondering what the possible next steps could be. With your current analysis, it appears that 1. declare PEP 269 withdrawn 2. reject this patch would be a possibility. I would want to keep this open only if some volunteer would indicate interest in completing this work. ---------------------------------------------------------------------- Comment By: Jon Riehl (jriehl) Date: 2003-11-02 00:20 Message: Logged In: YES user_id=22448 I am to some extent. I've done several wacky things, namely putting the pgen extension module into my Basil project (basically I think PEP 269 is dead), as well as re-written pgen in "pure" Python (no C extension module calls) The pure Python pgen looks like it will be going into Pypy. I don't know if I am interested in the speed enough to warrant serious analysis of the pgen C extension and the segmentation fault Guido reported. Let me know if you had anything specific in mind. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-31 14:54 Message: Logged In: YES user_id=21627 Jon, are you still interested in taking this further? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-17 17:12 Message: Logged In: YES user_id=6380 I've checked in the changes to the parser and Makefile etc. This means you should be able to distribute pgenmodule.c as a clean extension to Python 2.3. I've decided not to incorporate pgenmodule.c at this time. There are three problems with it as I see it: - The C coding style is really different, and makes it hard to read: 2-space indents instead of tabs, spaces before left parentheses in argument lists, space between * and name in things like "PyObject * name", placement of curly braces, reversal of arguments to comparisons (e.g. "NULL != x"), and long strings of underscores in comments. - The code isn't robust enough: I got a segfault (can't remember after what sequence of events, sorry), and it caused a SystemError (error return without exception set) when the grammar file couldn't be read. - The pgen API seems a bit strange -- some things that I would expect to be methods of AST objects are functions in the pgen module (even when a companion function *is* an AST method). - The unit test doesn't fit in the Python test framework. - I cooked up a little expression grammar and tried to parse a sample string, but all I got was exceptions. I guess I am missing something, but there's no tutorial that explains me how to do things (I was copying the code from test_pgen.py which works :-( ). Nevertheless, thanks for the work so far -- I'm sure at some point pgen will be usable from Python! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 22:44 Message: Logged In: YES user_id=6380 OK, reading the README now... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-05 17:42 Message: Logged In: YES user_id=6380 Closed. Jon, if you're still interested in this, upload something new and reopen the patch (or I can do that). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 18:32 Message: Logged In: YES user_id=6380 Lowering priority until Jon has his next version ready. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-13 06:35 Message: Logged In: YES user_id=6380 Cool. Maybe I'll get to it, maybe not. :-( ---------------------------------------------------------------------- Comment By: Jon Riehl (jriehl) Date: 2002-09-12 20:04 Message: Logged In: YES user_id=22448 Guido, as per my private message, I'll attempt to submit another patch by the end of the month, pending resumption of "work" on the 23rd. Commitment of the memory allocation patch is fine, and any future patches would be against the updated pgen code (I don't have commit permissions, so someone else will have to do this possibly.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-09 14:09 Message: Logged In: YES user_id=6380 I looked a bit, and it's very raw - the author admits that. Jon, are you still working on this? Do you have a more polished version? Maybe we can separate out the memory allocation patches and commit these already? They don't break anything. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 21:44 Message: Logged In: YES user_id=6380 I guess I'm going to hve to look at this to pronounce... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599331&group_id=5470 From noreply at sourceforge.net Mon Nov 3 08:30:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 3 08:31:09 2003 Subject: [Patches] [ python-Patches-787189 ] termios module on IRIX Message-ID: Patches item #787189, was opened at 2003-08-12 06:45 Message generated for change (Comment added) made by poinot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=787189&group_id=5470 Category: Modules Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Marc Poinot (poinot) Assigned to: Nobody/Anonymous (nobody) Summary: termios module on IRIX Initial Comment: The termios.c module includes sys/termios.h in which a CTRL macro is present, but not defined because of the pre-processing switches: #if (_NO_POSIX && _NO_XOPEN4) || _ABIAPI #define CTRL(c) ((c)&037) Then, the sys/ioctl.h is included (at least by termios.c module) and this uses CTRL() macro ! This looks like a problem on the IRIX side, they should be consistent with their own headers. The simplest way I found was to add into termios.c the definition of CTRL: #if defined(__sgi) #define CTRL(c) ((c)&037) #endif Has to be put *before* the #include in Modules/termios.c ---------------------------------------------------------------------- >Comment By: Marc Poinot (poinot) Date: 2003-11-03 13:30 Message: Logged In: YES user_id=28416 I've had a look at /usr/include/standards.h on my SGI, the definition of ABIAPI is located here. I cannot really understand what it is used for (_ABIAPI), but I guess it's something to allow binary compatibility (o32/n32/64) for old libs. The final point is the _ABIAPI *SHOULD NOT* been defined, because it forces the *old* termio structure. Python v2.3 uses the new termio structure, containing c_ospeed and c_ispeed. About termios, the termio(7) man page says: Old termio and termios For compatibility with existing binaries, MIPS ABI programs, and programs that cannot be ported to use the new termio or termios structures, the old interfaces are retained. Existing binaries automatically use the old interfaces. By defining _OLD_TERMIOS at compile time (before including , , or ), the old interfaces are in effect. As a matter of fact, recompiling Python v2.3 with _ABI_SOURCE (i.e. _ABIAPI) fails with the same error on Python termio module (un-patched). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-31 13:01 Message: Logged In: YES user_id=21627 Committed as termios.c 2.37.8.1 and 2.38. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-18 22:09 Message: Logged In: YES user_id=21627 In what cases would _ABIAPI be defined? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=787189&group_id=5470 From noreply at sourceforge.net Mon Nov 3 09:58:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 3 09:58:23 2003 Subject: [Patches] [ python-Patches-515003 ] Added HTTP{,S}ProxyConnection Message-ID: Patches item #515003, was opened at 2002-02-08 16:39 Message generated for change (Comment added) made by misa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=515003&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 3 Submitted By: Mihai Ibanescu (misa) Assigned to: Martin v. L?wis (loewis) Summary: Added HTTP{,S}ProxyConnection Initial Comment: This patch adds HTTP*Connection classes for proxy connections. Authenticated proxies are also supported. One can argue urllib2 already implements this. It does not do HTTPS tunneling through proxies, and this is intended to be lower-level than urllib2. ---------------------------------------------------------------------- >Comment By: Mihai Ibanescu (misa) Date: 2003-11-03 09:58 Message: Logged In: YES user_id=205865 Greg, I agree. I am not proud of the patch anymore - it is a nightmare to maintain. I'll have a look at PEP 268 and explore some other possiblities. So, it's ok with me to close this as WONTFIX until we come up with something better. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2003-10-31 19:25 Message: Logged In: YES user_id=6501 Eek. Following this model, then when we want to add Basic authentication support, then we'll have the following classes: HTTPBasicConnection HTTPSBasicConnection HTTPBasicProxyConnection HTTPSBasicProxyConnection Oh, and what if we want Digest support? Another set of four? But what if we want the connection to support *both* Basic or Digest, depending upon how the server was configured? Let's not forget the client certificates. Oh, and layering DAV capability on this. The point is: adding features by adding classes will produce a combinatoric nightmare. While I certainly agree with the idea of pushing proxy support "down" from urllib(2) into the basic http classes, I'd rather see a design that doesn't require a new class for every feature combination. PEP 268 was the start of an attempt to rationalize the various features around HTTP. Some of the basic feature sets to support: * SSL * various forms of authentication (Basic, Digest, client cert, ...) * WebDAV * Proxy * Proxy auth I'd much rather see proxy features folded right into the connection classes, than to spawn new ones. Even better, I'd suggest picking up PEP 268 and modifying it where "you" (whoever might read this comment) disagree or have further design ideas. (IOW, count me a -1 to the approach suggested by this patch) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-10 20:15 Message: Logged In: YES user_id=33168 Uploading patch from Isaac Salsberg. I removed some more comments. Jeremy (or Martin) can you review this. If it's read, I can check it in. There still needs to be a doc and tests. I'll check if either of the old patches has any. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-01 14:52 Message: Logged In: YES user_id=33168 Isaac, can you send me the patch? nnorwitz@users.sf.net should work ---------------------------------------------------------------------- Comment By: Isaac Salsberg (isalsberg) Date: 2002-12-19 20:54 Message: Logged In: YES user_id=663978 Neal, taht's right, I can not attach a file. I don't think is a good idea to close this patch, because Misa is still working on it to fix some persistence issue. The version I created is based on the current Misa's version, so it has the same persistence problem. It just was adapted to be used with Python 2.2.2. So we need to wait for Misa's final version. I sent the patch to Misa, in case he wants to atach it here meanwhile the last version arrives. Except for persistence, It is working for me in a production environment. Anyway, If You need the patch I can send it. Just give me an email address. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-14 21:09 Message: Logged In: YES user_id=33168 Isaac, I don't believe SF allows you to attach a file to someone else's patch. Please submit a new patch. In the comments for the new patch refer to this patch and indicate if it supercedes this patch (ie, should this patch be closed). Also, it would be nice if you can add a comment to this patch mentioning the new patch number. Thanks! ---------------------------------------------------------------------- Comment By: Isaac Salsberg (isalsberg) Date: 2002-12-14 19:52 Message: Logged In: YES user_id=663978 To make this patch work with the "buggy" IIS using python 2.2 or 2.2.1 with https, You need to install also these 2 patches: 551273 (fix httplib bug with 100 Continue) and 500311 (work around for buggy https servers) Python 2.2.2 by the other hand, has already incorparated those two patches, so You only need to add the HTTP{S} (515003) proxy patch. But since httplib has changed, Misa's diff file will fail. I have created a diff file that works with python 2.2.2, which also includes a new example that works using a certificate file in PEM format. I wanted to attach the file, however I could not find out how :-( ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-11-05 15:56 Message: Logged In: YES user_id=205865 I am having problems with proxying and keepalive connections. Setting to a lower priority until I figure out the documentation. ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-10-07 17:20 Message: Logged In: YES user_id=205865 Boy, two months. Yes, I'll go back to working on the patch. Sorry for the delay. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-07 17:17 Message: Logged In: YES user_id=21627 misa, is a patch forthcoming? ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-07-15 17:37 Message: Logged In: YES user_id=205865 - I agree about the comments. I'll make them reasonable. - one underscore is fine - I intended to have a patch that works with python 1.5, but then again the module itself doesn't run with 1.5 anyway, so good point. - When you make a connection to a server through a proxy, you have to connect to the proxy, but everything else should be the same, i.e. the Host: field has to refer to the server and so on. I wanted to reuse the code from _set_hostport, which saves the host and port in self.host, self.port. Had to do it twice, once for the proxy hostname, once for the server's. _set_hostport takes care of the default port and of the "hostname:port" syntax, which is convenient. I'll put together a patched patch and upload it. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-07-15 17:21 Message: Logged In: YES user_id=31392 The proposed classes seem useful enough, but I would like to make several suggestions for the implementation. - There are too many comments. Comments should only be added when the intent of the code needs to be explained. We definitely don't need one comment for each line of code. The comment in the HTTPS proxy putrequest() is an example of a helpful comment. - Just use a single underscore for private variables. - Please use string methods instead of the string module. - I don't understand the logic of switching the host/port back and forth. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-07-15 16:52 Message: Logged In: YES user_id=31392 I'll take a look. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-07-12 11:46 Message: Logged In: YES user_id=6380 Assigning to Jeremy in the hope that he can provide a review. ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-06-23 23:03 Message: Logged In: YES user_id=205865 The newer patch is generated against the latest CVS tree, and it provides additional documentation. ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-06-11 14:47 Message: Logged In: YES user_id=205865 Sorry, been caught with a zillion of other things to do. I'll try to reorganize it somehow and ask for opinions. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-11 14:42 Message: Logged In: YES user_id=31392 misa-- any progress on this patch? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-01 18:12 Message: Logged In: YES user_id=6380 OK, thanks; I'll wait! ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-03-01 17:58 Message: Logged In: YES user_id=205865 I will add documentation and show the intended usage. urllib* doesn't deal with proxying over SSL (using CONNECT instead of GET/POST). urllib* also use the compatibility classes, HTTP/HTTPS, instead of HTTPConnection (this is not an argument by itself). Thanks for the suggestion. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-01 17:40 Message: Logged In: YES user_id=6380 This patch fails to seduce me. There's no explanation why this would be useful, or how it should be used, and no documentation, and a hint that urllib2 already does this. Maybe you can get someone who's known on python-dev to champion it, if you think it's useful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=515003&group_id=5470 From noreply at sourceforge.net Mon Nov 3 10:52:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 3 10:52:55 2003 Subject: [Patches] [ python-Patches-835100 ] C++ comments invalid in C source files Message-ID: Patches item #835100, was opened at 2003-11-03 06:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=835100&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: The Written Word (Albert Chin) (tww-china) Assigned to: Nobody/Anonymous (nobody) Summary: C++ comments invalid in C source files Initial Comment: The IBM C compiler does not like C++ comments in C source files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=835100&group_id=5470 From noreply at sourceforge.net Mon Nov 3 15:07:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 3 15:07:30 2003 Subject: [Patches] [ python-Patches-835100 ] C++ comments invalid in C source files Message-ID: Patches item #835100, was opened at 2003-11-03 15:52 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=835100&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: The Written Word (Albert Chin) (tww-china) >Assigned to: Gregory P. Smith (greg) Summary: C++ comments invalid in C source files Initial Comment: The IBM C compiler does not like C++ comments in C source files. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-11-03 20:07 Message: Logged In: YES user_id=31392 Python coding standards don't like 'em either. Easy to fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=835100&group_id=5470 From noreply at sourceforge.net Mon Nov 3 16:40:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 3 16:40:23 2003 Subject: [Patches] [ python-Patches-835100 ] C++ comments invalid in C source files Message-ID: Patches item #835100, was opened at 2003-11-03 07:52 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=835100&group_id=5470 Category: Modules Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: The Written Word (Albert Chin) (tww-china) Assigned to: Gregory P. Smith (greg) Summary: C++ comments invalid in C source files Initial Comment: The IBM C compiler does not like C++ comments in C source files. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2003-11-03 13:40 Message: Logged In: YES user_id=413 Applied to both HEAD (2.4cvs) and release23-branch. Could we have the python configure script tell gcc to disallow C++ comments in .c files to catch these mistakes earlier? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-11-03 12:07 Message: Logged In: YES user_id=31392 Python coding standards don't like 'em either. Easy to fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=835100&group_id=5470 From noreply at sourceforge.net Mon Nov 3 17:24:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 3 17:24:38 2003 Subject: [Patches] [ python-Patches-835100 ] C++ comments invalid in C source files Message-ID: Patches item #835100, was opened at 2003-11-03 06:52 Message generated for change (Comment added) made by tww-china You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=835100&group_id=5470 Category: Modules Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: The Written Word (Albert Chin) (tww-china) Assigned to: Gregory P. Smith (greg) Summary: C++ comments invalid in C source files Initial Comment: The IBM C compiler does not like C++ comments in C source files. ---------------------------------------------------------------------- >Comment By: The Written Word (Albert Chin) (tww-china) Date: 2003-11-03 13:24 Message: Logged In: YES user_id=119770 I think -ansi and/or -pedantic will catch it but that might cause other problems. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-11-03 12:40 Message: Logged In: YES user_id=413 Applied to both HEAD (2.4cvs) and release23-branch. Could we have the python configure script tell gcc to disallow C++ comments in .c files to catch these mistakes earlier? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-11-03 11:07 Message: Logged In: YES user_id=31392 Python coding standards don't like 'em either. Easy to fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=835100&group_id=5470 From noreply at sourceforge.net Mon Nov 3 17:24:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 3 17:24:56 2003 Subject: [Patches] [ python-Patches-515003 ] Added HTTP{,S}ProxyConnection Message-ID: Patches item #515003, was opened at 2002-02-08 22:39 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=515003&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Mihai Ibanescu (misa) Assigned to: Martin v. L?wis (loewis) Summary: Added HTTP{,S}ProxyConnection Initial Comment: This patch adds HTTP*Connection classes for proxy connections. Authenticated proxies are also supported. One can argue urllib2 already implements this. It does not do HTTPS tunneling through proxies, and this is intended to be lower-level than urllib2. ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2003-11-03 15:58 Message: Logged In: YES user_id=205865 Greg, I agree. I am not proud of the patch anymore - it is a nightmare to maintain. I'll have a look at PEP 268 and explore some other possiblities. So, it's ok with me to close this as WONTFIX until we come up with something better. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2003-11-01 01:25 Message: Logged In: YES user_id=6501 Eek. Following this model, then when we want to add Basic authentication support, then we'll have the following classes: HTTPBasicConnection HTTPSBasicConnection HTTPBasicProxyConnection HTTPSBasicProxyConnection Oh, and what if we want Digest support? Another set of four? But what if we want the connection to support *both* Basic or Digest, depending upon how the server was configured? Let's not forget the client certificates. Oh, and layering DAV capability on this. The point is: adding features by adding classes will produce a combinatoric nightmare. While I certainly agree with the idea of pushing proxy support "down" from urllib(2) into the basic http classes, I'd rather see a design that doesn't require a new class for every feature combination. PEP 268 was the start of an attempt to rationalize the various features around HTTP. Some of the basic feature sets to support: * SSL * various forms of authentication (Basic, Digest, client cert, ...) * WebDAV * Proxy * Proxy auth I'd much rather see proxy features folded right into the connection classes, than to spawn new ones. Even better, I'd suggest picking up PEP 268 and modifying it where "you" (whoever might read this comment) disagree or have further design ideas. (IOW, count me a -1 to the approach suggested by this patch) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-11 02:15 Message: Logged In: YES user_id=33168 Uploading patch from Isaac Salsberg. I removed some more comments. Jeremy (or Martin) can you review this. If it's read, I can check it in. There still needs to be a doc and tests. I'll check if either of the old patches has any. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-01 20:52 Message: Logged In: YES user_id=33168 Isaac, can you send me the patch? nnorwitz@users.sf.net should work ---------------------------------------------------------------------- Comment By: Isaac Salsberg (isalsberg) Date: 2002-12-20 02:54 Message: Logged In: YES user_id=663978 Neal, taht's right, I can not attach a file. I don't think is a good idea to close this patch, because Misa is still working on it to fix some persistence issue. The version I created is based on the current Misa's version, so it has the same persistence problem. It just was adapted to be used with Python 2.2.2. So we need to wait for Misa's final version. I sent the patch to Misa, in case he wants to atach it here meanwhile the last version arrives. Except for persistence, It is working for me in a production environment. Anyway, If You need the patch I can send it. Just give me an email address. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-15 03:09 Message: Logged In: YES user_id=33168 Isaac, I don't believe SF allows you to attach a file to someone else's patch. Please submit a new patch. In the comments for the new patch refer to this patch and indicate if it supercedes this patch (ie, should this patch be closed). Also, it would be nice if you can add a comment to this patch mentioning the new patch number. Thanks! ---------------------------------------------------------------------- Comment By: Isaac Salsberg (isalsberg) Date: 2002-12-15 01:52 Message: Logged In: YES user_id=663978 To make this patch work with the "buggy" IIS using python 2.2 or 2.2.1 with https, You need to install also these 2 patches: 551273 (fix httplib bug with 100 Continue) and 500311 (work around for buggy https servers) Python 2.2.2 by the other hand, has already incorparated those two patches, so You only need to add the HTTP{S} (515003) proxy patch. But since httplib has changed, Misa's diff file will fail. I have created a diff file that works with python 2.2.2, which also includes a new example that works using a certificate file in PEM format. I wanted to attach the file, however I could not find out how :-( ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-11-05 21:56 Message: Logged In: YES user_id=205865 I am having problems with proxying and keepalive connections. Setting to a lower priority until I figure out the documentation. ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-10-07 23:20 Message: Logged In: YES user_id=205865 Boy, two months. Yes, I'll go back to working on the patch. Sorry for the delay. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-07 23:17 Message: Logged In: YES user_id=21627 misa, is a patch forthcoming? ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-07-15 23:37 Message: Logged In: YES user_id=205865 - I agree about the comments. I'll make them reasonable. - one underscore is fine - I intended to have a patch that works with python 1.5, but then again the module itself doesn't run with 1.5 anyway, so good point. - When you make a connection to a server through a proxy, you have to connect to the proxy, but everything else should be the same, i.e. the Host: field has to refer to the server and so on. I wanted to reuse the code from _set_hostport, which saves the host and port in self.host, self.port. Had to do it twice, once for the proxy hostname, once for the server's. _set_hostport takes care of the default port and of the "hostname:port" syntax, which is convenient. I'll put together a patched patch and upload it. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-07-15 23:21 Message: Logged In: YES user_id=31392 The proposed classes seem useful enough, but I would like to make several suggestions for the implementation. - There are too many comments. Comments should only be added when the intent of the code needs to be explained. We definitely don't need one comment for each line of code. The comment in the HTTPS proxy putrequest() is an example of a helpful comment. - Just use a single underscore for private variables. - Please use string methods instead of the string module. - I don't understand the logic of switching the host/port back and forth. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-07-15 22:52 Message: Logged In: YES user_id=31392 I'll take a look. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-07-12 17:46 Message: Logged In: YES user_id=6380 Assigning to Jeremy in the hope that he can provide a review. ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-06-24 05:03 Message: Logged In: YES user_id=205865 The newer patch is generated against the latest CVS tree, and it provides additional documentation. ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-06-11 20:47 Message: Logged In: YES user_id=205865 Sorry, been caught with a zillion of other things to do. I'll try to reorganize it somehow and ask for opinions. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-11 20:42 Message: Logged In: YES user_id=31392 misa-- any progress on this patch? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-02 00:12 Message: Logged In: YES user_id=6380 OK, thanks; I'll wait! ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-03-01 23:58 Message: Logged In: YES user_id=205865 I will add documentation and show the intended usage. urllib* doesn't deal with proxying over SSL (using CONNECT instead of GET/POST). urllib* also use the compatibility classes, HTTP/HTTPS, instead of HTTPConnection (this is not an argument by itself). Thanks for the suggestion. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-01 23:40 Message: Logged In: YES user_id=6380 This patch fails to seduce me. There's no explanation why this would be useful, or how it should be used, and no documentation, and a hint that urllib2 already does this. Maybe you can get someone who's known on python-dev to champion it, if you think it's useful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=515003&group_id=5470 From noreply at sourceforge.net Tue Nov 4 15:32:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 4 15:32:52 2003 Subject: [Patches] [ python-Patches-515003 ] Added HTTP{,S}ProxyConnection Message-ID: Patches item #515003, was opened at 2002-02-08 15:39 Message generated for change (Comment added) made by isalsberg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=515003&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Closed Resolution: Rejected Priority: 3 Submitted By: Mihai Ibanescu (misa) Assigned to: Martin v. L?wis (loewis) Summary: Added HTTP{,S}ProxyConnection Initial Comment: This patch adds HTTP*Connection classes for proxy connections. Authenticated proxies are also supported. One can argue urllib2 already implements this. It does not do HTTPS tunneling through proxies, and this is intended to be lower-level than urllib2. ---------------------------------------------------------------------- Comment By: Isaac Salsberg (isalsberg) Date: 2003-11-04 14:32 Message: Logged In: YES user_id=663978 Perhaps the patch is not using the best possible model, however is the only python code available that works FINE with proxies using HTTPS. It has been working for me for almost a year. Thank you Misa, if you develop another version, please let me know. ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2003-11-03 08:58 Message: Logged In: YES user_id=205865 Greg, I agree. I am not proud of the patch anymore - it is a nightmare to maintain. I'll have a look at PEP 268 and explore some other possiblities. So, it's ok with me to close this as WONTFIX until we come up with something better. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2003-10-31 18:25 Message: Logged In: YES user_id=6501 Eek. Following this model, then when we want to add Basic authentication support, then we'll have the following classes: HTTPBasicConnection HTTPSBasicConnection HTTPBasicProxyConnection HTTPSBasicProxyConnection Oh, and what if we want Digest support? Another set of four? But what if we want the connection to support *both* Basic or Digest, depending upon how the server was configured? Let's not forget the client certificates. Oh, and layering DAV capability on this. The point is: adding features by adding classes will produce a combinatoric nightmare. While I certainly agree with the idea of pushing proxy support "down" from urllib(2) into the basic http classes, I'd rather see a design that doesn't require a new class for every feature combination. PEP 268 was the start of an attempt to rationalize the various features around HTTP. Some of the basic feature sets to support: * SSL * various forms of authentication (Basic, Digest, client cert, ...) * WebDAV * Proxy * Proxy auth I'd much rather see proxy features folded right into the connection classes, than to spawn new ones. Even better, I'd suggest picking up PEP 268 and modifying it where "you" (whoever might read this comment) disagree or have further design ideas. (IOW, count me a -1 to the approach suggested by this patch) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-10 19:15 Message: Logged In: YES user_id=33168 Uploading patch from Isaac Salsberg. I removed some more comments. Jeremy (or Martin) can you review this. If it's read, I can check it in. There still needs to be a doc and tests. I'll check if either of the old patches has any. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-01 13:52 Message: Logged In: YES user_id=33168 Isaac, can you send me the patch? nnorwitz@users.sf.net should work ---------------------------------------------------------------------- Comment By: Isaac Salsberg (isalsberg) Date: 2002-12-19 19:54 Message: Logged In: YES user_id=663978 Neal, taht's right, I can not attach a file. I don't think is a good idea to close this patch, because Misa is still working on it to fix some persistence issue. The version I created is based on the current Misa's version, so it has the same persistence problem. It just was adapted to be used with Python 2.2.2. So we need to wait for Misa's final version. I sent the patch to Misa, in case he wants to atach it here meanwhile the last version arrives. Except for persistence, It is working for me in a production environment. Anyway, If You need the patch I can send it. Just give me an email address. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-14 20:09 Message: Logged In: YES user_id=33168 Isaac, I don't believe SF allows you to attach a file to someone else's patch. Please submit a new patch. In the comments for the new patch refer to this patch and indicate if it supercedes this patch (ie, should this patch be closed). Also, it would be nice if you can add a comment to this patch mentioning the new patch number. Thanks! ---------------------------------------------------------------------- Comment By: Isaac Salsberg (isalsberg) Date: 2002-12-14 18:52 Message: Logged In: YES user_id=663978 To make this patch work with the "buggy" IIS using python 2.2 or 2.2.1 with https, You need to install also these 2 patches: 551273 (fix httplib bug with 100 Continue) and 500311 (work around for buggy https servers) Python 2.2.2 by the other hand, has already incorparated those two patches, so You only need to add the HTTP{S} (515003) proxy patch. But since httplib has changed, Misa's diff file will fail. I have created a diff file that works with python 2.2.2, which also includes a new example that works using a certificate file in PEM format. I wanted to attach the file, however I could not find out how :-( ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-11-05 14:56 Message: Logged In: YES user_id=205865 I am having problems with proxying and keepalive connections. Setting to a lower priority until I figure out the documentation. ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-10-07 16:20 Message: Logged In: YES user_id=205865 Boy, two months. Yes, I'll go back to working on the patch. Sorry for the delay. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-07 16:17 Message: Logged In: YES user_id=21627 misa, is a patch forthcoming? ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-07-15 16:37 Message: Logged In: YES user_id=205865 - I agree about the comments. I'll make them reasonable. - one underscore is fine - I intended to have a patch that works with python 1.5, but then again the module itself doesn't run with 1.5 anyway, so good point. - When you make a connection to a server through a proxy, you have to connect to the proxy, but everything else should be the same, i.e. the Host: field has to refer to the server and so on. I wanted to reuse the code from _set_hostport, which saves the host and port in self.host, self.port. Had to do it twice, once for the proxy hostname, once for the server's. _set_hostport takes care of the default port and of the "hostname:port" syntax, which is convenient. I'll put together a patched patch and upload it. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-07-15 16:21 Message: Logged In: YES user_id=31392 The proposed classes seem useful enough, but I would like to make several suggestions for the implementation. - There are too many comments. Comments should only be added when the intent of the code needs to be explained. We definitely don't need one comment for each line of code. The comment in the HTTPS proxy putrequest() is an example of a helpful comment. - Just use a single underscore for private variables. - Please use string methods instead of the string module. - I don't understand the logic of switching the host/port back and forth. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-07-15 15:52 Message: Logged In: YES user_id=31392 I'll take a look. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-07-12 10:46 Message: Logged In: YES user_id=6380 Assigning to Jeremy in the hope that he can provide a review. ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-06-23 22:03 Message: Logged In: YES user_id=205865 The newer patch is generated against the latest CVS tree, and it provides additional documentation. ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-06-11 13:47 Message: Logged In: YES user_id=205865 Sorry, been caught with a zillion of other things to do. I'll try to reorganize it somehow and ask for opinions. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-11 13:42 Message: Logged In: YES user_id=31392 misa-- any progress on this patch? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-01 17:12 Message: Logged In: YES user_id=6380 OK, thanks; I'll wait! ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-03-01 16:58 Message: Logged In: YES user_id=205865 I will add documentation and show the intended usage. urllib* doesn't deal with proxying over SSL (using CONNECT instead of GET/POST). urllib* also use the compatibility classes, HTTP/HTTPS, instead of HTTPConnection (this is not an argument by itself). Thanks for the suggestion. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-01 16:40 Message: Logged In: YES user_id=6380 This patch fails to seduce me. There's no explanation why this would be useful, or how it should be used, and no documentation, and a hint that urllib2 already does this. Maybe you can get someone who's known on python-dev to champion it, if you think it's useful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=515003&group_id=5470 From noreply at sourceforge.net Tue Nov 4 16:57:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 4 16:57:48 2003 Subject: [Patches] [ python-Patches-836088 ] Update htmllib to HTML 4.01 Message-ID: Patches item #836088, was opened at 2003-11-04 16:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=836088&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Update htmllib to HTML 4.01 Initial Comment: The attached patch adds methods for all of the HTML 4.01 elements and rearranges things a bit. This version is incomplete. Still to do: * Expand test suite to exercise all the methods. * Change documentation to match. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=836088&group_id=5470 From noreply at sourceforge.net Wed Nov 5 07:13:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 5 07:13:27 2003 Subject: [Patches] [ python-Patches-836434 ] Build changes for AIX Message-ID: Patches item #836434, was opened at 2003-11-05 13:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=836434&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ulrich Berning (uberning) Assigned to: Nobody/Anonymous (nobody) Summary: Build changes for AIX Initial Comment: On AIX the file dynload_aix.c is used to load shared modules. This code uses the load() and loadbind() calls to load and bind a shared module. These functions do not work with C++ extensions. Since AIX 4.2 the dlopen() and dlsym() calls are available and should be used in preference because they also work with C++ modules. The patch changes the configure(.in) script to prefer the usage of dynload_shlib.c when the dlopen() function is available (configure checks this). Another problem is the definition of _XOPEN_SOURCE = 600 in the configure(.in) script. On AIX 4, some typedefs are only available when _XOPEN_SOURCE has a value of 500, but are used even if _XOPEN_SOURCE has another value. This seems to be a bug in the AIX include files. If _XOPEN_SOURCE is undefined, the AIX include files define it with the value 500 and everything works as expected. So the patch sets "define_xopen_source=no" for AIX 4 in configure(.in) The attached patch contains the changes for configure.in and configure but normally only configure.in needs to be patched and then configure should be recreated with autoconf. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=836434&group_id=5470 From noreply at sourceforge.net Wed Nov 5 18:03:54 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 5 18:04:12 2003 Subject: [Patches] [ python-Patches-677887 ] Add traceback.format_exc Message-ID: Patches item #677887, was opened at 2003-01-31 01:10 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677887&group_id=5470 Category: Library (Lib) Group: None >Status: Closed Resolution: Accepted Priority: 4 Submitted By: Neil Schemenauer (nascheme) Assigned to: Neil Schemenauer (nascheme) Summary: Add traceback.format_exc Initial Comment: I sometimes end up wanting this function. I think it compliments print_exc() nicely. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2003-11-05 23:03 Message: Logged In: YES user_id=35752 Checked in with NEWS. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-21 03:09 Message: Logged In: YES user_id=80475 Please post a NEWS item. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-02-12 16:47 Message: Logged In: YES user_id=35752 Argh! Here's the patch. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-10 19:40 Message: Logged In: YES user_id=92689 There's no file attached... ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-02-08 07:39 Message: Logged In: YES user_id=35752 Yes, feel free to reassign. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-07 05:58 Message: Logged In: YES user_id=80475 Did you intend to assign this one to me? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677887&group_id=5470 From noreply at sourceforge.net Wed Nov 5 18:11:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 5 18:12:02 2003 Subject: [Patches] [ python-Patches-836879 ] assert should not generate code if optimized Message-ID: Patches item #836879, was opened at 2003-11-05 23:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=836879&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 4 Submitted By: Neil Schemenauer (nascheme) Assigned to: Jeremy Hylton (jhylton) Summary: assert should not generate code if optimized Initial Comment: The compiler package in Lib still generates code for assert statements, even if -O is specified. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=836879&group_id=5470 From noreply at sourceforge.net Wed Nov 5 18:26:55 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 5 18:27:10 2003 Subject: [Patches] [ python-Patches-832058 ] deprecate or fix buffer object Message-ID: Patches item #832058, was opened at 2003-10-28 23:53 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=832058&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Nobody/Anonymous (nobody) Summary: deprecate or fix buffer object Initial Comment: This has not been well tested but I don't have time right now. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2003-11-05 23:26 Message: Logged In: YES user_id=35752 I've reviewed the code again and I'm more confident that it's correct. It would be good if someone else could review it before I check it in. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-11-02 03:43 Message: Logged In: YES user_id=35752 Attaching a patch that implements Greg Ewing's idea. Instead of storing the pointer and size to the buffer, the buffer interface is used each time they are needed. Again, not yet well tested. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=832058&group_id=5470 From noreply at sourceforge.net Wed Nov 5 20:56:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 5 20:56:27 2003 Subject: [Patches] [ python-Patches-836942 ] Avoid "apply" warnings in "logging", still works in 1.52 Message-ID: Patches item #836942, was opened at 2003-11-05 17:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=836942&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jimmy Retzlaff (jretz) Assigned to: Nobody/Anonymous (nobody) Summary: Avoid "apply" warnings in "logging", still works in 1.52 Initial Comment: Avoid warnings in Python 2.3+ by defining an apply function in terms of the new calling semantics (i.e., *args/**kwargs). If that fails because the new calling semantics are unavailable then leave apply untouched for 1.52 compatibility. eval is used to define the function so the SyntaxError can be caught on versions of Python without the new calling semantics. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=836942&group_id=5470 From noreply at sourceforge.net Thu Nov 6 08:55:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 6 08:55:31 2003 Subject: [Patches] [ python-Patches-834422 ] Implementation PEP 322: Reverse Iteration Message-ID: Patches item #834422, was opened at 2003-11-02 01:42 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=834422&group_id=5470 Category: Core (C code) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Implementation PEP 322: Reverse Iteration Initial Comment: See attached patch. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-06 08:55 Message: Logged In: YES user_id=80475 PEP was conditionally accepted for Py2.4. Patch modified to remove the general __reversed__ hook. Applied patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=834422&group_id=5470 From noreply at sourceforge.net Thu Nov 6 11:20:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 6 11:20:05 2003 Subject: [Patches] [ python-Patches-837322 ] owning, borrowing, stealing clarification Message-ID: Patches item #837322, was opened at 2003-11-06 18:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=837322&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: owning, borrowing, stealing clarification Initial Comment: in Doc/api/intro.tex, 'Reference count details', merging of the second and third sentences with (courtesy of Alex Martelli): Ownership pertains to references, never to objects (objects are not owned: they are always shared). "Owning a reference" means being responsible for calling Py_DECREF on it when the reference is no longer needed. Ownership can also be transferred, meaning that the code that receives ownership of the reference then becomes responsible for eventually decref'ing it when it's no longer needed. Please check the final result; this change is IMO important since it clarifies what ownership is and implies. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=837322&group_id=5470 From noreply at sourceforge.net Thu Nov 6 16:08:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 6 16:08:46 2003 Subject: [Patches] [ python-Patches-837322 ] owning, borrowing, stealing clarification Message-ID: Patches item #837322, was opened at 2003-11-06 17:20 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=837322&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: owning, borrowing, stealing clarification Initial Comment: in Doc/api/intro.tex, 'Reference count details', merging of the second and third sentences with (courtesy of Alex Martelli): Ownership pertains to references, never to objects (objects are not owned: they are always shared). "Owning a reference" means being responsible for calling Py_DECREF on it when the reference is no longer needed. Ownership can also be transferred, meaning that the code that receives ownership of the reference then becomes responsible for eventually decref'ing it when it's no longer needed. Please check the final result; this change is IMO important since it clarifies what ownership is and implies. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-06 22:08 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as intro.tex 1.5 and 1.3.24.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=837322&group_id=5470 From noreply at sourceforge.net Thu Nov 6 16:17:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 6 16:17:48 2003 Subject: [Patches] [ python-Patches-819012 ] Fix for former/latter confusion in Extending documentation Message-ID: Patches item #819012, was opened at 2003-10-07 05:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=819012&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) >Assigned to: Michael Hudson (mwh) Summary: Fix for former/latter confusion in Extending documentation Initial Comment: Section 1.10 ("Reference Counts" in Extending Python) has this: "In C++, the operators new and delete are used with essentially the same meaning and we'll restrict the following discussion to the latter." However, the following discussion uses malloc() and free () (i.e. "the former"), not new and delete. Either this should be corrected to say "the former" (as with the attached one line patch), or the whole section should be corrected to use new and delete. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-06 22:17 Message: Logged In: YES user_id=21627 Assigning to mwh, who introduced this confusion in extending.tex 1.23. I don't think "the former" is more clear, as it might just refer to the keyword "new", as opposed to they keyword "delete", which would be "the latter". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=819012&group_id=5470 From noreply at sourceforge.net Fri Nov 7 06:46:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 7 06:51:46 2003 Subject: [Patches] [ python-Patches-819012 ] Fix for former/latter confusion in Extending documentation Message-ID: Patches item #819012, was opened at 2003-10-07 04:21 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=819012&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Michael Hudson (mwh) Summary: Fix for former/latter confusion in Extending documentation Initial Comment: Section 1.10 ("Reference Counts" in Extending Python) has this: "In C++, the operators new and delete are used with essentially the same meaning and we'll restrict the following discussion to the latter." However, the following discussion uses malloc() and free () (i.e. "the former"), not new and delete. Either this should be corrected to say "the former" (as with the attached one line patch), or the whole section should be corrected to use new and delete. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-11-07 11:46 Message: Logged In: YES user_id=6656 Fixed in revision 1.26 of Doc/ext/extending.tex but by changing the offending text to "restrict the following discussion to the C case." ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-06 21:17 Message: Logged In: YES user_id=21627 Assigning to mwh, who introduced this confusion in extending.tex 1.23. I don't think "the former" is more clear, as it might just refer to the keyword "new", as opposed to they keyword "delete", which would be "the latter". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=819012&group_id=5470 From noreply at sourceforge.net Fri Nov 7 12:25:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 7 12:25:51 2003 Subject: [Patches] [ python-Patches-784231 ] getopt_long_only() Message-ID: Patches item #784231, was opened at 2003-08-06 15:25 Message generated for change (Comment added) made by s3a You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784231&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Souza (s3a) Assigned to: Nobody/Anonymous (nobody) Summary: getopt_long_only() Initial Comment: A getopt_long_only() implementation for the `getopt' module. Note that it has one slight difference from the glibc version, related to the `-W' behavior, in that it _really_ treats `-W foo' _as_ `--foo'; therefore, when `foo' is not a valid long option, this is an error --- rather than returning the option ('-W', 'foo') as though `W:' instead of `W;' had been specified. ---------------------------------------------------------------------- >Comment By: Souza (s3a) Date: 2003-11-07 17:25 Message: Logged In: YES user_id=838988 I shall add a doc/test patch (within some days). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-31 13:08 Message: Logged In: YES user_id=21627 I see no harm in adding this function. However, the patch is incomplete: it lacks changes to Doc/lib/libgetopt.tex. s3a, can you please provide these changes? ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2003-08-28 18:17 Message: Logged In: YES user_id=469548 I'm not sure we want to support this: our new option-parsing library optparse rejects this behavior (see http://python.org/doc/current/lib/optparse-terminology.html), and our gnu_getopt wasn't intended to work exactly like gnu_getopt (see http://python.org/sf/473512). On the other hand, your patch seems to work well, although you should add tests and a documentation patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784231&group_id=5470 From dukanon at yahoo.com.au Sat Nov 8 00:30:39 2003 From: dukanon at yahoo.com.au (Business Marketing) Date: Sat Nov 8 00:27:37 2003 Subject: [Patches] NetMarketing Trade Secrets Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20031108/e58d93a5/attachment.html From noreply at sourceforge.net Sat Nov 8 15:21:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 8 15:22:02 2003 Subject: [Patches] [ python-Patches-838546 ] make pty.fork() allocate a controlling tty Message-ID: Patches item #838546, was opened at 2003-11-08 14:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=838546&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: J Raynor (raynorj) Assigned to: Nobody/Anonymous (nobody) Summary: make pty.fork() allocate a controlling tty Initial Comment: pty.fork() does not allocate a controlling tty on systems that don't have os.forkpty(). The code for pty.fork() tries to use os.forkpty(), and if it isn't available, then it tries to do its work in python, but it doesn't work. The code does setup stdin, stdout, and stderr to use the slave device, but it needs to do an explicit open on the slave device to make it become a controlling tty. This patch is against pty.py from python 2.3, but the same change can be made to pty.py from python 2.2 and it works there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=838546&group_id=5470 From noreply at sourceforge.net Sat Nov 8 16:41:54 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 8 16:42:01 2003 Subject: [Patches] [ python-Patches-762963 ] timemodule.c: Python loses current timezone Message-ID: Patches item #762963, was opened at 2003-06-29 19:18 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762963&group_id=5470 Category: Modules Group: None Status: Open >Resolution: None Priority: 5 Submitted By: Doug Quale (quale) Assigned to: Martin v. L?wis (loewis) Summary: timemodule.c: Python loses current timezone Initial Comment: Python routines in timemodule.c sometimes force glibc to use GMT instead of the correct timezone. I think this is a longstanding bug, but I have only looked at Python 2.2 and 2.33b1. This bug has been reported before (510218) but it was misdiagnosed and closed. It also came up recently in on the python-list (http://aspn.activestate.com/ASPN/Mail/Message/python-list/1564384) where it was also misdiagnosed. Standard C and Python use a struct tm with 9 values. BSD influenced C libraries like glibc have an extra field (tm_gmtoff) that keeps the offset from UTC. BSD-style struct tm values know the correct timezone associated with the time, but Python and Standard C struct tm values don't so they can only assume the current timezone. Ideally Python would always treat stuct tm-style time tuples as being associated with the current timezone. Unfortunately in many cases Python forces glibc to use GMT rather than the current timezone. You can see the problem most graphically with the %z format in strftime(). In the transcript Python incorrectly gives the timezone offset as +0000 even though it gets the timezone name (CDT) correct: $ python2.3 Python 2.3b1+ (#2, Jun 4 2003, 03:03:32) [GCC 3.3 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> now = time.localtime() >>> print now (2003, 6, 29, 20, 3, 52, 6, 180, 1) >>> RFC822 = '%a, %d %b %Y %T %z' >>> print time.strftime(RFC822, now) Sun, 29 Jun 2003 20:03:52 +0000 >>> print time.strftime(RFC822) Sun, 29 Jun 2003 20:05:27 -0500 >>> print time.strftime('%Z', now) CDT The correct timezone is CDT and the correct offset is -0500. Notice that when time.strftime() computes the current time it it gets the correct timezone offset, but when the struct tm tuple is passed in it thinks the timezone offset is 0. (glibc does know that the correct timezone name is CDT even when passed a bad struct tm value, but that's not surprising since the timezone name is not stored in struct tm and it is not computed from timezone offset.) The problem is in the gettmargs() function in timemodule.c. When getmargs() parses a Python tm tuple it leaves the tm_gmtoff field zeroed. This specifically tells glibc that the timezone offset is 0, which is wrong for most people. (BSD libc may also be affected.) This problem does not occur when time_strfrtime() gets the current time itself since that codepath uses a struct tm value directly from the libc localtime(), leaving the tm_gmtoff field intact. Fortunately the fix is almost trivial. A call to mktime() will normalize the fields in the struct tm value, including the tm_gmtoff field. I conditionalized the patch only on HAVE_MKTIME. I'm pretty sure there's an autoconfigure test for tm_gmtoff and it would probably be better to use that. ---------------------------------------------------------------------- Comment By: Doug Quale (quale) Date: 2003-08-21 09:57 Message: Logged In: YES user_id=812266 I have attached a little unittest with two tests showing the problem. I stole some code from Lib/test/test_time.py for the test that checks behavior in the US Eastern timezone. That test won't be run if tzset() isn't available, but this is OK since the only libc's that will show this problem are BSD-inspired and will have tzset(). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-17 14:54 Message: Logged In: YES user_id=80475 Can you attach a unittest that fails before the patch and succeeds afterward? ---------------------------------------------------------------------- Comment By: Doug Quale (quale) Date: 2003-08-09 10:16 Message: Logged In: YES user_id=812266 Martin is right. The call to mktime() in my patch overwrites the tm_isdst field. This field is in the Python time tuple and is correctly set by the code immediately above. I put the call to mktime in the wrong place. Instead of going at the end of the routine it belongs immediately after the memset used to zero the structure. Sorry about this botch. I have attached a corrected patch. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-09 06:00 Message: Logged In: YES user_id=21627 The patch is wrong. It changes the behaviour of time.asctime(time.gmtime(time.time())) which it shouldn't do. The problem is real, though, and might need to be solved by exposing the tm_gmtoff field where available. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-11 16:52 Message: Logged In: YES user_id=80475 Martin, can you diagnose whether this should be closed, applied, or deferred? ---------------------------------------------------------------------- Comment By: Doug Quale (quale) Date: 2003-07-10 11:14 Message: Logged In: YES user_id=812266 The problem isn't in strftime. The problem is in gettmargs() in timemodule.c. Python assumes that broken down time tuples are in the local timezone. The gettmargs() routine in timemodule.c is bugged on GNU libc and possibly other BSD-inspired C libraries. gettmargs() is supposed to take a Python broken down time tuple and convert it to a C struct tm. The Python time tuple is assumed to be in the local time zone, so the struct tm should be in the local timezone also. In glibc, struct tm has timezone fields so each struct tm knows its own timezone. The gettmargs() routine never fills in these extra fields so it always creates a struct tm in GMT. The appropriate behavior would be to set tm_gmtoff to the local timezone offset. My patch fixes gettmargs() to create struct tm's in the local timezone for C libraries that have the tm_gmtoff field in struct tm. As to the docs issue, the Python docs say that other formats may be supported than the ones listed. In reality, strftime() is passed to the underlying C library so the format codes supported are whatever the C library supports. The doc statement "Additional directives may be supported on certain platforms, but only the ones listed here have a meaning standardized by ANSI C" is wrong, or at least not up to date. C99 specifies several strftime format codes that are not listed including %z. I think Tim Smith also mentions this in a Python list posting from earlier this year. In the Python time module, the docs say strftime('format') is the same as strftime('format', localtime()). This is simply broken right now on glibc as has been reported by more than one person: >>> strftime('%z') '-0500' >>> strftime('%z', localtime()) '+0000' This is wrong. Unsupported format specifiers do not have this effect, for example: >>> strftime('%L') '%L' >>> strftime('%L', localtime()) '%L' This behavior is correct. A final note on the patch: I should have looked closer at the timemodule.c source. It already uses the appropriate #ifdef in other places. Instead of #ifdef HAVE_MKTIME my patch should be conditionalized #ifdef HAVE_STRUCT_TM_TM_ZONE. It's kind of amusing to write up this long of a justification for what is essentially a 3 line patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 15:36 Message: Logged In: YES user_id=357491 So the problem is with the %z directive not reporting the proper timezone offset, correct? If you look at http://www.python.org/ dev/doc/devel/lib/module-time.html , though, you will notice that %T is not supported as a directive for strftime or strptime nor has it ever been supported. Same goes for %T although it works in your example. Since the docs do not say that these directives are supported I am closing this patch since it would require altering both strftime and stprtime to support %z on all platforms which this patch does not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762963&group_id=5470 From noreply at sourceforge.net Sun Nov 9 15:40:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 9 15:40:44 2003 Subject: [Patches] [ python-Patches-838910 ] Footnote on bug in Mailbox with Windows text-mode files Message-ID: Patches item #838910, was opened at 2003-11-09 20:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=838910&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rob Alexander (rob_alexander) Assigned to: Nobody/Anonymous (nobody) Summary: Footnote on bug in Mailbox with Windows text-mode files Initial Comment: SourceForge bug 586899 describes a problem with using Mailbox on text-mode files under Windows. A fix is going to be non-trivial, so a documentation change was suggested. This patch adds a footnote to the Mailbox documentation (libmailbox.tex) that warns about the problem and describes the workaround (use binary mode). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=838910&group_id=5470 From noreply at sourceforge.net Mon Nov 10 00:12:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 10 00:12:11 2003 Subject: [Patches] [ python-Patches-839038 ] add getsid() system call Message-ID: Patches item #839038, was opened at 2003-11-09 23:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=839038&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: J Raynor (raynorj) Assigned to: Nobody/Anonymous (nobody) Summary: add getsid() system call Initial Comment: This patch adds the getsid() system call to the os module. The patch modifies the following files: configure.in Modules/posixmodule.c Doc/lib/libos.tex autoconf and autoheader will need to be run after the patch is applied. The patch is against cvs code from Nov 9, 2003, and is a context diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=839038&group_id=5470 From noreply at sourceforge.net Mon Nov 10 01:36:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 10 01:36:48 2003 Subject: [Patches] [ python-Patches-839038 ] add getsid() system call Message-ID: Patches item #839038, was opened at 2003-11-10 06:12 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=839038&group_id=5470 Category: Core (C code) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: J Raynor (raynorj) Assigned to: Nobody/Anonymous (nobody) Summary: add getsid() system call Initial Comment: This patch adds the getsid() system call to the os module. The patch modifies the following files: configure.in Modules/posixmodule.c Doc/lib/libos.tex autoconf and autoheader will need to be run after the patch is applied. The patch is against cvs code from Nov 9, 2003, and is a context diff. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-10 07:36 Message: Logged In: YES user_id=21627 Thanks for the patch, committed as configure 1.430 configure.in 1.440 pyconfig.h.in 1.87 libos.tex 1.131 posixmodule.c 2.308 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=839038&group_id=5470 From noreply at sourceforge.net Mon Nov 10 01:38:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 10 01:38:37 2003 Subject: [Patches] [ python-Patches-838546 ] make pty.fork() allocate a controlling tty Message-ID: Patches item #838546, was opened at 2003-11-08 21:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=838546&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: J Raynor (raynorj) Assigned to: Nobody/Anonymous (nobody) Summary: make pty.fork() allocate a controlling tty Initial Comment: pty.fork() does not allocate a controlling tty on systems that don't have os.forkpty(). The code for pty.fork() tries to use os.forkpty(), and if it isn't available, then it tries to do its work in python, but it doesn't work. The code does setup stdin, stdout, and stderr to use the slave device, but it needs to do an explicit open on the slave device to make it become a controlling tty. This patch is against pty.py from python 2.3, but the same change can be made to pty.py from python 2.2 and it works there. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-10 07:38 Message: Logged In: YES user_id=21627 What systems did you test this on? I remember ttyname returning funny things on some systems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=838546&group_id=5470 From noreply at sourceforge.net Mon Nov 10 01:45:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 10 01:45:42 2003 Subject: [Patches] [ python-Patches-798297 ] imaplib : Add support for the THREAD command Message-ID: Patches item #798297, was opened at 2003-09-01 00:36 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798297&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Yves Dionne (dionney) Assigned to: Nobody/Anonymous (nobody) Summary: imaplib : Add support for the THREAD command Initial Comment: This patch add support for the THREAD IMAP command to the imaplib module. It basicly is a copy of the sort() procedure :) The THREAD command is still not a IETF RFC, but many IMAP server implement it. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-10 07:45 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as libimaplib.tex 1.25 imaplib.py 1.65 ACKS 1.254 NEWS 1.889 As this is a new feature, it cannot be added to 2.3. ---------------------------------------------------------------------- Comment By: Yves Dionne (dionney) Date: 2003-09-01 19:21 Message: Logged In: YES user_id=11733 I've made a new patch that include mods to Doc/lib/libimaplib.tex, as requested. Also, the new patch was made against Python 2.3; the old one was against 2.2.3. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-01 09:05 Message: Logged In: YES user_id=21627 Can you please include a patch to Doc/lib/libimaplib.tex as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798297&group_id=5470 From noreply at sourceforge.net Mon Nov 10 01:47:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 10 01:47:24 2003 Subject: [Patches] [ python-Patches-794400 ] startup file compiler flags Message-ID: Patches item #794400, was opened at 2003-08-25 02:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=794400&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eric Tiedemann (est) Assigned to: Nobody/Anonymous (nobody) Summary: startup file compiler flags Initial Comment: Allow the startup file to modify the compiler flags. This allows you, for example, to have true division automatically in interactive mode. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-10 07:47 Message: Logged In: YES user_id=21627 Eric, are you willing to contribute documentation changes? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-18 12:46 Message: Logged In: YES user_id=21627 I think there should be some documentation changes to document what precisely can be done in the startup code. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2003-09-01 16:15 Message: Logged In: YES user_id=2772 Works for me. It's a simple change, even though some code was moved out of line into a separate static function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=794400&group_id=5470 From noreply at sourceforge.net Mon Nov 10 01:50:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 10 01:50:21 2003 Subject: [Patches] [ python-Patches-804543 ] invalid use of setlocale Message-ID: Patches item #804543, was opened at 2003-09-11 17:46 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804543&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stanislav Brabec (sbrabec) >Assigned to: Martin v. L?wis (loewis) Summary: invalid use of setlocale Initial Comment: char *oldloc=setlocale(LC_CTYPE,NULL); setlocale(LC_CTYPE, "C"); setlocale(LC_CTYPE, oldloc); can cause strange problems. The glibc documentation clearly states, that you must make your own copy of the string. >From glibc docs: setlocale() RETURN VALUE ... This string may be allocated in static storage. ... It means, that subsequent call of setlocale can overwrite this string. And since glibc-2.3 it does. There is a fix. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-09-29 04:19 Message: Logged In: YES user_id=357491 OK, I found that we have our own definition of strdup() that configure.in has used if it is not defined by the C library, so that issue is clear. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-09-29 03:46 Message: Logged In: YES user_id=357491 'C: A Reference Manual' also suggests copying the string in fear of possible mucking with the string that is pointed to by the setlocale() call. Since this has a patch already I am changing this to a patch. And as for the patch, it does use strdup() which is not ANSI C. I know that there a couple of places that do use strdup(), but I am not sure if that is really proper. Requires asking python-dev. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804543&group_id=5470 From noreply at sourceforge.net Mon Nov 10 07:55:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 10 07:56:05 2003 Subject: [Patches] [ python-Patches-794400 ] startup file compiler flags Message-ID: Patches item #794400, was opened at 2003-08-24 19:15 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=794400&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eric Tiedemann (est) Assigned to: Nobody/Anonymous (nobody) Summary: startup file compiler flags Initial Comment: Allow the startup file to modify the compiler flags. This allows you, for example, to have true division automatically in interactive mode. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2003-11-10 06:55 Message: Logged In: YES user_id=2772 I would expect the behavior of $PYTHONSTARTUP to be just like typing the commands in at the interactive prompt, except that the results of the individual expr_statements are not printed. That simply makes the old behavior (__future__ directives ignored) a bug. Instead of writing documentation that is specific "this works, but this doesn't", any remaining details of interpreter state that differ between $PYTHONSTARTUP and entering commands at the interactive prompt should be fixed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-10 00:47 Message: Logged In: YES user_id=21627 Eric, are you willing to contribute documentation changes? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-18 05:46 Message: Logged In: YES user_id=21627 I think there should be some documentation changes to document what precisely can be done in the startup code. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2003-09-01 09:15 Message: Logged In: YES user_id=2772 Works for me. It's a simple change, even though some code was moved out of line into a separate static function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=794400&group_id=5470 From noreply at sourceforge.net Mon Nov 10 20:03:54 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 10 20:04:01 2003 Subject: [Patches] [ python-Patches-838546 ] make pty.fork() allocate a controlling tty Message-ID: Patches item #838546, was opened at 2003-11-08 14:21 Message generated for change (Comment added) made by raynorj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=838546&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: J Raynor (raynorj) Assigned to: Nobody/Anonymous (nobody) Summary: make pty.fork() allocate a controlling tty Initial Comment: pty.fork() does not allocate a controlling tty on systems that don't have os.forkpty(). The code for pty.fork() tries to use os.forkpty(), and if it isn't available, then it tries to do its work in python, but it doesn't work. The code does setup stdin, stdout, and stderr to use the slave device, but it needs to do an explicit open on the slave device to make it become a controlling tty. This patch is against pty.py from python 2.3, but the same change can be made to pty.py from python 2.2 and it works there. ---------------------------------------------------------------------- >Comment By: J Raynor (raynorj) Date: 2003-11-10 19:03 Message: Logged In: YES user_id=904832 This works on aix 5.2, 5.1, and 4.3.3. It also works on hpux 10.20. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-10 00:38 Message: Logged In: YES user_id=21627 What systems did you test this on? I remember ttyname returning funny things on some systems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=838546&group_id=5470 From noreply at sourceforge.net Tue Nov 11 06:41:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 11 06:41:26 2003 Subject: [Patches] [ python-Patches-839877 ] removed unused function(test_glob.py) Message-ID: Patches item #839877, was opened at 2003-11-11 20:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=839877&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: removed unused function(test_glob.py) Initial Comment: test_glob.py has an unused lambda expression inside GlobTests' test_xxx methods. np = lambda *f: norm(self.tempdir, *f) It seems they exist from the initial import of test_glob.py, but as far as I have checked, they have never been used. Please check this patch to get rid of them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=839877&group_id=5470 From noreply at sourceforge.net Thu Nov 13 02:44:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 13 02:44:16 2003 Subject: [Patches] [ python-Patches-804543 ] invalid use of setlocale Message-ID: Patches item #804543, was opened at 2003-09-11 17:46 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804543&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Stanislav Brabec (sbrabec) Assigned to: Martin v. L?wis (loewis) Summary: invalid use of setlocale Initial Comment: char *oldloc=setlocale(LC_CTYPE,NULL); setlocale(LC_CTYPE, "C"); setlocale(LC_CTYPE, oldloc); can cause strange problems. The glibc documentation clearly states, that you must make your own copy of the string. >From glibc docs: setlocale() RETURN VALUE ... This string may be allocated in static storage. ... It means, that subsequent call of setlocale can overwrite this string. And since glibc-2.3 it does. There is a fix. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-13 08:44 Message: Logged In: YES user_id=21627 The patch was slightly outdated, so I have updated it, and committed it as readline.c 2.64.6.1 pythonrun.c 2.195.6.3 readline.c 2.66 pythonrun.c 2.199 ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-09-29 04:19 Message: Logged In: YES user_id=357491 OK, I found that we have our own definition of strdup() that configure.in has used if it is not defined by the C library, so that issue is clear. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-09-29 03:46 Message: Logged In: YES user_id=357491 'C: A Reference Manual' also suggests copying the string in fear of possible mucking with the string that is pointed to by the setlocale() call. Since this has a patch already I am changing this to a patch. And as for the patch, it does use strdup() which is not ANSI C. I know that there a couple of places that do use strdup(), but I am not sure if that is really proper. Requires asking python-dev. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804543&group_id=5470 From noreply at sourceforge.net Thu Nov 13 02:45:58 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 13 02:46:02 2003 Subject: [Patches] [ python-Patches-839877 ] removed unused function(test_glob.py) Message-ID: Patches item #839877, was opened at 2003-11-11 12:41 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=839877&group_id=5470 Category: Tests Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: removed unused function(test_glob.py) Initial Comment: test_glob.py has an unused lambda expression inside GlobTests' test_xxx methods. np = lambda *f: norm(self.tempdir, *f) It seems they exist from the initial import of test_glob.py, but as far as I have checked, they have never been used. Please check this patch to get rid of them. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-13 08:45 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as test_glob.py 1.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=839877&group_id=5470 From noreply at sourceforge.net Thu Nov 13 09:31:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 13 09:31:19 2003 Subject: [Patches] [ python-Patches-841454 ] Cross building python for mingw32 Message-ID: Patches item #841454, was opened at 2003-11-13 15:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=841454&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Ames (yxcv) Assigned to: Nobody/Anonymous (nobody) Summary: Cross building python for mingw32 Initial Comment: At first: I can't follow the submission guidelines because I'm sitting behind a firewall and therefore can't access external cvs repositories. So this patch applies to the release Python-2.3.2 source tarball. Nevertheless I hope, it might be useful for others. The attached patch allows to cross-compile python from linux (and probably cygwin) to mingw32. Some remarks: 1) Python's stock configure.in has no support for cross-compilation. Although I've tried to limit the changes to the minimum necessary for a mingw32 build, I'm certain that the changes break some native build anywhere (I've not even tested a single native build seriously). Some (remaining) problems are: - the use of AC_TRY_RUN - looking for /dev/... files at configuration time - the use of 'uname' (instead of configure's --build commandline switch) - ... 2) I'm proposing to use scons for the build of the core extensions for cross-builds (and have included minimal sconstruct/sconscript files) because I do not dare to change distutils to support cross-compilation as I have only finite time resources and I would certainly break all kinds of stock functionality (if I could do it at all). Although scons doesn't support cross-builds either, it at least doesn't prevent them. This way, it seemed easier to me, YMMV. 3) There are quite a few warnings when compiling. I've only halfheartedly tried to solve a few of them. Even when I use vc6 with the warning level pushed to 4 (which should be more compareable to -Wall), many of them don't show up. OTOH, vc6 seems to be more sloppy anyway. Maybe others can help? 4) I have not yet built core extensions with more complex external dependencies and darwin-specific modules (bsddb, tkinter etc., look at Modules/sconscript for a complete (?) list) 5) 'regrtest.py -l -uall' behaves the same for the mingw32-build as for the vc6-build, iff I don't let gcc optimize the code. At least with the default -O3 and also with -O2, test_import.py crashes on the reload test, because the magic number returned by the marshaller is different from the expected 'pyc_magic' in import.c. I've validated that the @test.pyc contains the valid magic number, but the marshaller changes both 0x0a and 0x0d (the most significant word) into '0xff'. This doesn't happen when I give no -O option at all. I've tried to debug this but lost track in import.c:find_module. Whether this is a textmode vs. binarymode issue (I don't believe so) or some overoptimization of gcc or what not, I wasn't able to determine. Perhaps someone more knowledgeable can help out? 6) I've tried to be as close as possible to the vc6 build. So os.name still is 'nt' and sys.platform still is 'win32'. One major difference is, that allmost all extension modules which are builtin by the vc6 build, are external modules in the mingw32 build. This should be ok for most of them, but it is bad for the 'msvcrt' module because most mingw32 people won't be happy to have a second libmsvcrt.a in their libpath. The module should either be always built in, or should be renamed (to '_msvcrt' or something). I'm not sure what is the right thing. I used the following build environment: - autoconf 2.57 - gcc version 3.3.1 (mingw special 20030804-1) - a native python 2.3.2 with scons 0.93 installed Btw: All of those are in debian's 'testing' (or was it 'unstable'?) branch. Attached is the patch. It is so fat, just because I included config.guess and config.sub which are needed by the patched configure script. Although this form only seems to allow one file to be attached, I will try to send in a xbuild-py.sh script, so that you can see, exactly which commandlines you can use. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=841454&group_id=5470 From noreply at sourceforge.net Thu Nov 13 09:39:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 13 09:39:19 2003 Subject: [Patches] [ python-Patches-841461 ] Differentiation between Builtins and extension classes Message-ID: Patches item #841461, was opened at 2003-11-13 14:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=841461&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Boris Boutillier (bobox) Assigned to: Nobody/Anonymous (nobody) Summary: Differentiation between Builtins and extension classes Initial Comment: Some checks in the C code are done to avoid modification by the user of builtin classes. Unfortunately this also affects C-extension classes. Since addition of the hackcheck, this is more and more difficult to write a not too obscure workaround for extension classes. Moreover the HeapType flag is used far beyond its original purpose, as described in object.h. The proposed change is to add a new flag, "Modifiable" that indicates if the class can be modified by the python user ( ie if he can set attributes, change classes, change bases). Builtins won't have it, heaptype objects will always have it and extension classes can chose. The flag addition is backward compatible, and binary compatible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=841461&group_id=5470 From noreply at sourceforge.net Thu Nov 13 10:54:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 13 10:54:34 2003 Subject: [Patches] [ python-Patches-827559 ] SimpleHTTPServer directory-indexing "bug" fix Message-ID: Patches item #827559, was opened at 2003-10-21 16:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=827559&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Chris Gonnerman (solomoriah) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleHTTPServer directory-indexing "bug" fix Initial Comment: The SimpleHTTPServer.py module, when presented with a URL of the form: http://some.site.com/directory should redirect the browser to: http://some.site.com/directory/ This is evidently a standard behavior of major webservers (Apache and IIS at least). SimpleHTTPServer does not do this, but fortunately it is simple to implement (patch attached, naturally). I am providing a fix for 2.2 but this problem appears to be in earlier versions, and is also in 2.3. This patch appears to work fine for 2.3. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-13 16:54 Message: Logged In: YES user_id=21627 Why is this a bug? SimpleHTTPServer already returns the directory content if only the directory name is given, with or without trailing slash. I believe Apache does that only as an implementation detail, and it is unfortunate that this detail is exposed to clients. So unless you can report a specific problem with the approach taken by SimpleHTTPServer, I'm tempted to reject this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=827559&group_id=5470 From noreply at sourceforge.net Thu Nov 13 12:25:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 13 12:25:24 2003 Subject: [Patches] [ python-Patches-784231 ] getopt_long_only() Message-ID: Patches item #784231, was opened at 2003-08-06 15:25 Message generated for change (Comment added) made by s3a You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784231&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Souza (s3a) Assigned to: Nobody/Anonymous (nobody) Summary: getopt_long_only() Initial Comment: A getopt_long_only() implementation for the `getopt' module. Note that it has one slight difference from the glibc version, related to the `-W' behavior, in that it _really_ treats `-W foo' _as_ `--foo'; therefore, when `foo' is not a valid long option, this is an error --- rather than returning the option ('-W', 'foo') as though `W:' instead of `W;' had been specified. ---------------------------------------------------------------------- >Comment By: Souza (s3a) Date: 2003-11-13 17:25 Message: Logged In: YES user_id=838988 The patch now includes changes to Doc/lib/libgetopt.tex. ---------------------------------------------------------------------- Comment By: Souza (s3a) Date: 2003-11-07 17:25 Message: Logged In: YES user_id=838988 I shall add a doc/test patch (within some days). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-31 13:08 Message: Logged In: YES user_id=21627 I see no harm in adding this function. However, the patch is incomplete: it lacks changes to Doc/lib/libgetopt.tex. s3a, can you please provide these changes? ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2003-08-28 18:17 Message: Logged In: YES user_id=469548 I'm not sure we want to support this: our new option-parsing library optparse rejects this behavior (see http://python.org/doc/current/lib/optparse-terminology.html), and our gnu_getopt wasn't intended to work exactly like gnu_getopt (see http://python.org/sf/473512). On the other hand, your patch seems to work well, although you should add tests and a documentation patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784231&group_id=5470 From noreply at sourceforge.net Thu Nov 13 15:12:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 13 15:12:51 2003 Subject: [Patches] [ python-Patches-780821 ] More robust MSVC6 finder Message-ID: Patches item #780821, was opened at 2003-07-31 12:50 Message generated for change (Comment added) made by pmagwene You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=780821&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Garth T Kidd (gtk) Assigned to: Jeremy Hylton (jhylton) Summary: More robust MSVC6 finder Initial Comment: My VS6 install on XP didn't set the r"Software\Microsoft\Devstudio\6.0\Build System" registry key relied upon by distutils.msvccompiler to find the compiler and linker executable. As a backup to the registry paths, this patch looks up the MSVCDIR environment variable and ensures its basename is appropriate for the Python build version: if self.__version == 6: matchbase = 'vc98' elif self.__version == 7: matchbase = 'vc7' Works fine on my machine, so long as I run VCVARS32.BAT, and fails appropriately if I ran the wrong VCVARS32.BAT by mistake (I have Visual Studio Net 2003 also installed). The patch should be applied to distutils/msvccompiler.py. ---------------------------------------------------------------------- Comment By: Paul Magwene (pmagwene) Date: 2003-11-13 20:12 Message: Logged In: YES user_id=23286 The reliance on registry keys (and ignoring other environment variables) can also cause other headaches. Here's a problem I ran into on a stock Python 2.3 when trying to compile extensions using VC6: I'm using STLport instead of the buggy STL implementation that ships with VC6. To have the STL headers included I put the STL directory at the beginning of the INCLUDE search path in VCVARS32.BAT *and* by setting the appropriate values in the environment variables. With these settings, when I built my Python C++ extension by hand everything worked hunky-dory. However when I tried to use distutils it kept including the old header files. It took me a good 20 minutes of head scratching to realize that distutils was ignoring my environment variables and preferentially grabbing whatever INCLUDE directory was specified in the registry key (even if I ran VCVARS32.bat before compiling). Once I set the registry variable by hand, everything worked ok. Perhaps distutils can be configured to look for environment settings *before* searching out whatever is buried in the registry? --Paul M. ---------------------------------------------------------------------- Comment By: Murray Steele (murraysteele) Date: 2003-10-21 11:10 Message: Logged In: YES user_id=891425 Having come across this problem myself, it seems that MSVC 6 doesn't create the r"Software\Microsoft\Devstudio\6.0\Build System" registry keys until *after* you run the actual Visual Studio IDE. So just doing a plain install and never running the IDE isn't enough. This isn't much of a fix, just some kind of documentation incase it bites some other fumbling developer in the future. Someone somewhere else (http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451285&group_id=5470) suggested using the Environment Variables as well as the registry keys in distutils to check for compiler correctness. Seems like a plan to me. And there is some more chat about this problem here http://sourceforge.net/tracker/?func=detail&atid=305470&aid=614770&group_id=5470 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-01 07:16 Message: Logged In: YES user_id=21627 I'm curious, though, how you installed VS6 without getting the registry settings. Doesn't this mean your installation of VS6 is broken? ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2003-08-01 04:06 Message: Logged In: YES user_id=59803 WARNING: the first patch contains a typo. s/nstring/string/ and you'll be fine. New version attached. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-31 22:09 Message: Logged In: YES user_id=31392 I've desired the same functionality in the past. ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2003-07-31 12:52 Message: Logged In: YES user_id=59803 Whups. The patch didn't attach. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=780821&group_id=5470 From noreply at sourceforge.net Thu Nov 13 18:12:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 13 18:12:23 2003 Subject: [Patches] [ python-Patches-841807 ] One more patch for --enable-shared Message-ID: Patches item #841807, was opened at 2003-11-14 00:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=841807&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ondrej Palkovsky (ondrap) Assigned to: Nobody/Anonymous (nobody) Summary: One more patch for --enable-shared Initial Comment: There is a problem in the Makefile that during 'make install' rewrites the shared library name with the symbolic link, if on the platform they are defined to be the same in the config file. Currently this makes problem on HP-UX. This patch makes the install process first check if the names are the same and creates the link only if they are not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=841807&group_id=5470 From noreply at sourceforge.net Fri Nov 14 00:28:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 14 00:28:38 2003 Subject: [Patches] [ python-Patches-827559 ] SimpleHTTPServer directory-indexing "bug" fix Message-ID: Patches item #827559, was opened at 2003-10-21 14:49 Message generated for change (Comment added) made by solomoriah You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=827559&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Chris Gonnerman (solomoriah) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleHTTPServer directory-indexing "bug" fix Initial Comment: The SimpleHTTPServer.py module, when presented with a URL of the form: http://some.site.com/directory should redirect the browser to: http://some.site.com/directory/ This is evidently a standard behavior of major webservers (Apache and IIS at least). SimpleHTTPServer does not do this, but fortunately it is simple to implement (patch attached, naturally). I am providing a fix for 2.2 but this problem appears to be in earlier versions, and is also in 2.3. This patch appears to work fine for 2.3. ---------------------------------------------------------------------- >Comment By: Chris Gonnerman (solomoriah) Date: 2003-11-14 05:28 Message: Logged In: YES user_id=321948 Oops. Allow me to clarify. Directory names without a trailing slash need to be redirected to the same name with the trailing slash to avoid breaking relative links from the page. I use SimpleHTTPServer to test websites which will be deployed via Apache. Relative links on default directory pages (index.html) are broken using SimpleHTTPServer but work correctly on Apache. This is a de facto standard at least (I haven't read the RFC's but both IE and Mozilla expect this behavior). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-13 15:54 Message: Logged In: YES user_id=21627 Why is this a bug? SimpleHTTPServer already returns the directory content if only the directory name is given, with or without trailing slash. I believe Apache does that only as an implementation detail, and it is unfortunate that this detail is exposed to clients. So unless you can report a specific problem with the approach taken by SimpleHTTPServer, I'm tempted to reject this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=827559&group_id=5470 From noreply at sourceforge.net Fri Nov 14 03:35:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 14 03:35:33 2003 Subject: [Patches] [ python-Patches-841977 ] modulefinder fails to find extension modules in packages Message-ID: Patches item #841977, was opened at 2003-11-14 09:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=841977&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Just van Rossum (jvr) Summary: modulefinder fails to find extension modules in packages Initial Comment: The find_all_submodules() method in modulefinder only looks for *.py, *.pyc, and *.pyo files. Python extension modules are only found if they are referenced in import statements somewhere. This patch uses the actual list from imp.get_suffixes(). Assigning to Just - can you verify that this does the right thing? If needed I can provide a simple program which shows this bug when frozen in py2exe, I assume BundleBuilder would have the same problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=841977&group_id=5470 From noreply at sourceforge.net Fri Nov 14 04:35:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 14 04:35:34 2003 Subject: [Patches] [ python-Patches-841977 ] modulefinder fails to find extension modules in packages Message-ID: Patches item #841977, was opened at 2003-11-14 09:35 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=841977&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) >Assigned to: Thomas Heller (theller) Summary: modulefinder fails to find extension modules in packages Initial Comment: The find_all_submodules() method in modulefinder only looks for *.py, *.pyc, and *.pyo files. Python extension modules are only found if they are referenced in import statements somewhere. This patch uses the actual list from imp.get_suffixes(). Assigning to Just - can you verify that this does the right thing? If needed I can provide a simple program which shows this bug when frozen in py2exe, I assume BundleBuilder would have the same problem. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-11-14 10:35 Message: Logged In: YES user_id=92689 I don't think it's needed to add .pyc and .pyo to the suffixes list: most of the time a .py is needed anyway, and the standard import mechanism doesn't find a module if there's no source and the byte code extension doesn't match the optimization setting. I mean, when running with -O, you'll get an ImportError if there's only a .pyc and vice versa. So the suffixes from imp.get_suffixes() should be enough. Other than that: go ahead and check it in, preferably also in the 2.3 maintainance branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=841977&group_id=5470 From noreply at sourceforge.net Fri Nov 14 05:22:54 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 14 05:23:03 2003 Subject: [Patches] [ python-Patches-841977 ] modulefinder fails to find extension modules in packages Message-ID: Patches item #841977, was opened at 2003-11-14 09:35 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=841977&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: modulefinder fails to find extension modules in packages Initial Comment: The find_all_submodules() method in modulefinder only looks for *.py, *.pyc, and *.pyo files. Python extension modules are only found if they are referenced in import statements somewhere. This patch uses the actual list from imp.get_suffixes(). Assigning to Just - can you verify that this does the right thing? If needed I can provide a simple program which shows this bug when frozen in py2exe, I assume BundleBuilder would have the same problem. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-11-14 11:22 Message: Logged In: YES user_id=11105 Ok, will make this change and check it in. Thanks. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-11-14 10:35 Message: Logged In: YES user_id=92689 I don't think it's needed to add .pyc and .pyo to the suffixes list: most of the time a .py is needed anyway, and the standard import mechanism doesn't find a module if there's no source and the byte code extension doesn't match the optimization setting. I mean, when running with -O, you'll get an ImportError if there's only a .pyc and vice versa. So the suffixes from imp.get_suffixes() should be enough. Other than that: go ahead and check it in, preferably also in the 2.3 maintainance branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=841977&group_id=5470 From noreply at sourceforge.net Fri Nov 14 22:00:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 14 22:01:04 2003 Subject: [Patches] [ python-Patches-842567 ] reflect the removal of mpz Message-ID: Patches item #842567, was opened at 2003-11-15 12:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=842567&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: reflect the removal of mpz Initial Comment: mpz's doc says "This module will be removed in Python 2.3" but Python 2.3 has been released, so it should read: "This module has been removed in Python 2.3" Python 2.3.2 (#1, Oct 9 2003, 12:03:29) Type "help", "copyright", "credits" or "license" for more information. >>> import mpz Traceback (most recent call last): File "", line 1, in ? ImportError: No module named mpz ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=842567&group_id=5470 From noreply at sourceforge.net Sat Nov 15 22:18:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 15 22:18:19 2003 Subject: [Patches] [ python-Patches-842994 ] NameError in the example of sets module Message-ID: Patches item #842994, was opened at 2003-11-16 12:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=842994&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: NameError in the example of sets module Initial Comment: I've just tried Raymon's new and improved sets and tested examples of sets module and found an error in the docs. www.python.org/doc/2.3.2/lib/set-example.html for group in [engineers, programmers, management, employees]: should be: for group in [engineers, programmers, managers, employees]: Since "management" is not defined before, it raises an NameErrror. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=842994&group_id=5470 From noreply at sourceforge.net Sun Nov 16 05:04:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 16 05:04:56 2003 Subject: [Patches] [ python-Patches-843088 ] doc fixes builtin super and string.replace Message-ID: Patches item #843088, was opened at 2003-11-16 10:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=843088&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: doc fixes builtin super and string.replace Initial Comment: - missing comma in builtin super function - rename maxsplit in string.replace to maxreplace. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=843088&group_id=5470 From noreply at sourceforge.net Sun Nov 16 05:23:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 16 05:23:43 2003 Subject: [Patches] [ python-Patches-823775 ] use just built python interp. to build the docs. Message-ID: Patches item #823775, was opened at 2003-10-14 22:58 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=823775&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: use just built python interp. to build the docs. Initial Comment: this patch doesn't change the default behaviour, but does allow passing a PYTHON interpreter for building the docs. Of ycourse you could pass MKHOWTO as well, but then you have to know the environmnet (TEXINPUTS) as well. The "$(shell ...)" construct is already used, so it does not introduce a new incompatibility. [note: I think as the default the just built interpreter should be used to build the docs] ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2003-11-16 10:23 Message: Logged In: YES user_id=60903 attached is the patch for the trunk. I don't see much sense in keeping the uncommented version, because the new definition tries to cover both cases. Maybe Fred could comment what he likes better. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-18 10:11 Message: Logged In: YES user_id=21627 The patch does not apply to the CVS trunk. Please don't remove the unused MKHOWTO line, and please provide separate patches for 2.3 and the trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=823775&group_id=5470 From noreply at sourceforge.net Sun Nov 16 08:41:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 16 08:41:55 2003 Subject: [Patches] [ python-Patches-842994 ] NameError in the example of sets module Message-ID: Patches item #842994, was opened at 2003-11-15 22:18 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=842994&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) >Assigned to: Raymond Hettinger (rhettinger) Summary: NameError in the example of sets module Initial Comment: I've just tried Raymon's new and improved sets and tested examples of sets module and found an error in the docs. www.python.org/doc/2.3.2/lib/set-example.html for group in [engineers, programmers, management, employees]: should be: for group in [engineers, programmers, managers, employees]: Since "management" is not defined before, it raises an NameErrror. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=842994&group_id=5470 From noreply at sourceforge.net Sun Nov 16 08:47:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 16 08:47:13 2003 Subject: [Patches] [ python-Patches-842994 ] NameError in the example of sets module Message-ID: Patches item #842994, was opened at 2003-11-15 22:18 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=842994&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Raymond Hettinger (rhettinger) Summary: NameError in the example of sets module Initial Comment: I've just tried Raymon's new and improved sets and tested examples of sets module and found an error in the docs. www.python.org/doc/2.3.2/lib/set-example.html for group in [engineers, programmers, management, employees]: should be: for group in [engineers, programmers, managers, employees]: Since "management" is not defined before, it raises an NameErrror. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=842994&group_id=5470 From noreply at sourceforge.net Sun Nov 16 09:23:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 16 09:23:58 2003 Subject: [Patches] [ python-Patches-823072 ] add option to NOT use ~/.netrc in nntplib.NNTP() Message-ID: Patches item #823072, was opened at 2003-10-13 22:09 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=823072&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: add option to NOT use ~/.netrc in nntplib.NNTP() Initial Comment: [forwarded from http://bugs.debian.org/215446] It should be possible to circumvent the use of ~/.netrc when calling the nntplib.NNTP() method by adding an addtional parameter. ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2003-11-16 14:23 Message: Logged In: YES user_id=60903 add doc patch ---------------------------------------------------------------------- Comment By: Mike Rovner (mrovner) Date: 2003-10-14 00:29 Message: Logged In: YES user_id=162094 No documentation (http://www.python.org/doc/current/lib/module- nntplib.html) patch provided. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=823072&group_id=5470 From noreply at sourceforge.net Sun Nov 16 22:18:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 16 22:18:28 2003 Subject: [Patches] [ python-Patches-843455 ] Make weakref callbacks play nice in gc Message-ID: Patches item #843455, was opened at 2003-11-16 22:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=843455&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 9 Submitted By: Tim Peters (tim_one) Assigned to: Neil Schemenauer (nascheme) Summary: Make weakref callbacks play nice in gc Initial Comment: See bug 839548. Weakref callbacks attached to objects in dead cycles can see objects that have gone thru tp_clear() now, and can resurrect such objects too. A wide variety of bad things can result, up to and including segfaults. This implements a scheme I detailed on Python-Dev to teach gc about the bad things callbacks can do, still calling them, but ensuring that a callback can't reach any objects on which tp_clear has been invoked. If a callback happens to resurrect an object, tp_clear won't get invoked on the latter object at all by gc. This keeps Python-visible objects wholly sane, and even unsurprising. If this patch is accepted, I'll also check in a plain-text file with a version of the Python-Dev msg explaining the scheme. Neal, I most want your eyeballs on this, since you know the most about gc's design. Please assign to Fred when you're done (whether or not you can make time), because I want his eyeballs on the weakref changes. Two changes were made to the weakref implementation: (1) a new private API function _PyWeakref_HasCallback(), so gc can determine which objects have associated weakref callbacks; and, (2) because objects in cyclic trash don't have refcount 0, I had to remove the refcnt==0 check from PyObject_ClearWeakRefs(). Maybe it would be better to introduce a workalike private function that skipped that one check, and leave the public function alone? When reviewing this, note that it has to be backported to the 2.3 line too: 2.3.2 is the release in which Jim Fulton first saw segfaults in real life. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=843455&group_id=5470 From noreply at sourceforge.net Mon Nov 17 02:38:43 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 17 02:38:47 2003 Subject: [Patches] [ python-Patches-843455 ] Make weakref callbacks play nice in gc Message-ID: Patches item #843455, was opened at 2003-11-16 22:18 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=843455&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 9 Submitted By: Tim Peters (tim_one) >Assigned to: Tim Peters (tim_one) Summary: Make weakref callbacks play nice in gc Initial Comment: See bug 839548. Weakref callbacks attached to objects in dead cycles can see objects that have gone thru tp_clear() now, and can resurrect such objects too. A wide variety of bad things can result, up to and including segfaults. This implements a scheme I detailed on Python-Dev to teach gc about the bad things callbacks can do, still calling them, but ensuring that a callback can't reach any objects on which tp_clear has been invoked. If a callback happens to resurrect an object, tp_clear won't get invoked on the latter object at all by gc. This keeps Python-visible objects wholly sane, and even unsurprising. If this patch is accepted, I'll also check in a plain-text file with a version of the Python-Dev msg explaining the scheme. Neal, I most want your eyeballs on this, since you know the most about gc's design. Please assign to Fred when you're done (whether or not you can make time), because I want his eyeballs on the weakref changes. Two changes were made to the weakref implementation: (1) a new private API function _PyWeakref_HasCallback(), so gc can determine which objects have associated weakref callbacks; and, (2) because objects in cyclic trash don't have refcount 0, I had to remove the refcnt==0 check from PyObject_ClearWeakRefs(). Maybe it would be better to introduce a workalike private function that skipped that one check, and leave the public function alone? When reviewing this, note that it has to be backported to the 2.3 line too: 2.3.2 is the release in which Jim Fulton first saw segfaults in real life. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-11-17 02:38 Message: Logged In: YES user_id=31435 Back to me: I think there's a fundamental flaw here. Despite that it fixes the new test cases, what matters isn't really which objects are reachable from the objects whose deaths trigger callbacks, what matters is which objects are reachable from the callbacks themselves. Those are the ones that must not get tp_clear'ed before the callbacks run. In all the test cases so far, it turned out they were also reachable from the objects whose deaths trigger callbacks, so it seemed to work. But it should be possible to stumble into a tougher case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=843455&group_id=5470 From noreply at sourceforge.net Tue Nov 18 00:52:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 18 00:52:10 2003 Subject: [Patches] [ python-Patches-843455 ] Make weakref callbacks play nice in gc Message-ID: Patches item #843455, was opened at 2003-11-16 22:18 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=843455&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 9 Submitted By: Tim Peters (tim_one) >Assigned to: Neil Schemenauer (nascheme) Summary: Make weakref callbacks play nice in gc Initial Comment: See bug 839548. Weakref callbacks attached to objects in dead cycles can see objects that have gone thru tp_clear() now, and can resurrect such objects too. A wide variety of bad things can result, up to and including segfaults. This implements a scheme I detailed on Python-Dev to teach gc about the bad things callbacks can do, still calling them, but ensuring that a callback can't reach any objects on which tp_clear has been invoked. If a callback happens to resurrect an object, tp_clear won't get invoked on the latter object at all by gc. This keeps Python-visible objects wholly sane, and even unsurprising. If this patch is accepted, I'll also check in a plain-text file with a version of the Python-Dev msg explaining the scheme. Neal, I most want your eyeballs on this, since you know the most about gc's design. Please assign to Fred when you're done (whether or not you can make time), because I want his eyeballs on the weakref changes. Two changes were made to the weakref implementation: (1) a new private API function _PyWeakref_HasCallback(), so gc can determine which objects have associated weakref callbacks; and, (2) because objects in cyclic trash don't have refcount 0, I had to remove the refcnt==0 check from PyObject_ClearWeakRefs(). Maybe it would be better to introduce a workalike private function that skipped that one check, and leave the public function alone? When reviewing this, note that it has to be backported to the 2.3 line too: 2.3.2 is the release in which Jim Fulton first saw segfaults in real life. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-11-18 00:52 Message: Logged In: YES user_id=31435 New patch (clear_first.txt). This implements a scheme of doing tp_clear() on trash weakrefs first, so that their callbacks get disabled. There are subtleties (heh), most discussed on Python-Dev already. Eyeballs, Neal? This no longer changes anything in the weakref implementation, but it does engage in weakref abuse, so I'd like Fred to peer at it too. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-17 02:38 Message: Logged In: YES user_id=31435 Back to me: I think there's a fundamental flaw here. Despite that it fixes the new test cases, what matters isn't really which objects are reachable from the objects whose deaths trigger callbacks, what matters is which objects are reachable from the callbacks themselves. Those are the ones that must not get tp_clear'ed before the callbacks run. In all the test cases so far, it turned out they were also reachable from the objects whose deaths trigger callbacks, so it seemed to work. But it should be possible to stumble into a tougher case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=843455&group_id=5470 From noreply at sourceforge.net Tue Nov 18 11:26:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 18 11:26:48 2003 Subject: [Patches] [ python-Patches-843455 ] Make weakref callbacks play nice in gc Message-ID: Patches item #843455, was opened at 2003-11-17 03:18 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=843455&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 9 Submitted By: Tim Peters (tim_one) Assigned to: Neil Schemenauer (nascheme) Summary: Make weakref callbacks play nice in gc Initial Comment: See bug 839548. Weakref callbacks attached to objects in dead cycles can see objects that have gone thru tp_clear() now, and can resurrect such objects too. A wide variety of bad things can result, up to and including segfaults. This implements a scheme I detailed on Python-Dev to teach gc about the bad things callbacks can do, still calling them, but ensuring that a callback can't reach any objects on which tp_clear has been invoked. If a callback happens to resurrect an object, tp_clear won't get invoked on the latter object at all by gc. This keeps Python-visible objects wholly sane, and even unsurprising. If this patch is accepted, I'll also check in a plain-text file with a version of the Python-Dev msg explaining the scheme. Neal, I most want your eyeballs on this, since you know the most about gc's design. Please assign to Fred when you're done (whether or not you can make time), because I want his eyeballs on the weakref changes. Two changes were made to the weakref implementation: (1) a new private API function _PyWeakref_HasCallback(), so gc can determine which objects have associated weakref callbacks; and, (2) because objects in cyclic trash don't have refcount 0, I had to remove the refcnt==0 check from PyObject_ClearWeakRefs(). Maybe it would be better to introduce a workalike private function that skipped that one check, and leave the public function alone? When reviewing this, note that it has to be backported to the 2.3 line too: 2.3.2 is the release in which Jim Fulton first saw segfaults in real life. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2003-11-18 16:26 Message: Logged In: YES user_id=35752 The patch looks sound. I think it would be cleaner if the weakref object provided a _PyWeakref_ClearRefs() function for the GC to use (that did not mess with the callback). That way the GC could just incref the weakref and call that function. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-18 05:52 Message: Logged In: YES user_id=31435 New patch (clear_first.txt). This implements a scheme of doing tp_clear() on trash weakrefs first, so that their callbacks get disabled. There are subtleties (heh), most discussed on Python-Dev already. Eyeballs, Neal? This no longer changes anything in the weakref implementation, but it does engage in weakref abuse, so I'd like Fred to peer at it too. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-17 07:38 Message: Logged In: YES user_id=31435 Back to me: I think there's a fundamental flaw here. Despite that it fixes the new test cases, what matters isn't really which objects are reachable from the objects whose deaths trigger callbacks, what matters is which objects are reachable from the callbacks themselves. Those are the ones that must not get tp_clear'ed before the callbacks run. In all the test cases so far, it turned out they were also reachable from the objects whose deaths trigger callbacks, so it seemed to work. But it should be possible to stumble into a tougher case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=843455&group_id=5470 From noreply at sourceforge.net Tue Nov 18 11:27:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 18 11:27:33 2003 Subject: [Patches] [ python-Patches-843455 ] Make weakref callbacks play nice in gc Message-ID: Patches item #843455, was opened at 2003-11-17 03:18 Message generated for change (Settings changed) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=843455&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 9 Submitted By: Tim Peters (tim_one) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Make weakref callbacks play nice in gc Initial Comment: See bug 839548. Weakref callbacks attached to objects in dead cycles can see objects that have gone thru tp_clear() now, and can resurrect such objects too. A wide variety of bad things can result, up to and including segfaults. This implements a scheme I detailed on Python-Dev to teach gc about the bad things callbacks can do, still calling them, but ensuring that a callback can't reach any objects on which tp_clear has been invoked. If a callback happens to resurrect an object, tp_clear won't get invoked on the latter object at all by gc. This keeps Python-visible objects wholly sane, and even unsurprising. If this patch is accepted, I'll also check in a plain-text file with a version of the Python-Dev msg explaining the scheme. Neal, I most want your eyeballs on this, since you know the most about gc's design. Please assign to Fred when you're done (whether or not you can make time), because I want his eyeballs on the weakref changes. Two changes were made to the weakref implementation: (1) a new private API function _PyWeakref_HasCallback(), so gc can determine which objects have associated weakref callbacks; and, (2) because objects in cyclic trash don't have refcount 0, I had to remove the refcnt==0 check from PyObject_ClearWeakRefs(). Maybe it would be better to introduce a workalike private function that skipped that one check, and leave the public function alone? When reviewing this, note that it has to be backported to the 2.3 line too: 2.3.2 is the release in which Jim Fulton first saw segfaults in real life. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-11-18 16:26 Message: Logged In: YES user_id=35752 The patch looks sound. I think it would be cleaner if the weakref object provided a _PyWeakref_ClearRefs() function for the GC to use (that did not mess with the callback). That way the GC could just incref the weakref and call that function. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-18 05:52 Message: Logged In: YES user_id=31435 New patch (clear_first.txt). This implements a scheme of doing tp_clear() on trash weakrefs first, so that their callbacks get disabled. There are subtleties (heh), most discussed on Python-Dev already. Eyeballs, Neal? This no longer changes anything in the weakref implementation, but it does engage in weakref abuse, so I'd like Fred to peer at it too. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-17 07:38 Message: Logged In: YES user_id=31435 Back to me: I think there's a fundamental flaw here. Despite that it fixes the new test cases, what matters isn't really which objects are reachable from the objects whose deaths trigger callbacks, what matters is which objects are reachable from the callbacks themselves. Those are the ones that must not get tp_clear'ed before the callbacks run. In all the test cases so far, it turned out they were also reachable from the objects whose deaths trigger callbacks, so it seemed to work. But it should be possible to stumble into a tougher case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=843455&group_id=5470 From noreply at sourceforge.net Tue Nov 18 12:09:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 18 12:09:34 2003 Subject: [Patches] [ python-Patches-843455 ] Make weakref callbacks play nice in gc Message-ID: Patches item #843455, was opened at 2003-11-17 03:18 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=843455&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 9 Submitted By: Tim Peters (tim_one) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Make weakref callbacks play nice in gc Initial Comment: See bug 839548. Weakref callbacks attached to objects in dead cycles can see objects that have gone thru tp_clear() now, and can resurrect such objects too. A wide variety of bad things can result, up to and including segfaults. This implements a scheme I detailed on Python-Dev to teach gc about the bad things callbacks can do, still calling them, but ensuring that a callback can't reach any objects on which tp_clear has been invoked. If a callback happens to resurrect an object, tp_clear won't get invoked on the latter object at all by gc. This keeps Python-visible objects wholly sane, and even unsurprising. If this patch is accepted, I'll also check in a plain-text file with a version of the Python-Dev msg explaining the scheme. Neal, I most want your eyeballs on this, since you know the most about gc's design. Please assign to Fred when you're done (whether or not you can make time), because I want his eyeballs on the weakref changes. Two changes were made to the weakref implementation: (1) a new private API function _PyWeakref_HasCallback(), so gc can determine which objects have associated weakref callbacks; and, (2) because objects in cyclic trash don't have refcount 0, I had to remove the refcnt==0 check from PyObject_ClearWeakRefs(). Maybe it would be better to introduce a workalike private function that skipped that one check, and leave the public function alone? When reviewing this, note that it has to be backported to the 2.3 line too: 2.3.2 is the release in which Jim Fulton first saw segfaults in real life. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2003-11-18 17:09 Message: Logged In: YES user_id=35752 Well, scratch that last idea. After trying to come up with a patch I've concluded that it's not any cleaner. I also tried changing the weakref tp_clear method to not decref the wr_callback attribute. I'm not sure that's any better either since it spreads the subtle code around. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-11-18 16:26 Message: Logged In: YES user_id=35752 The patch looks sound. I think it would be cleaner if the weakref object provided a _PyWeakref_ClearRefs() function for the GC to use (that did not mess with the callback). That way the GC could just incref the weakref and call that function. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-18 05:52 Message: Logged In: YES user_id=31435 New patch (clear_first.txt). This implements a scheme of doing tp_clear() on trash weakrefs first, so that their callbacks get disabled. There are subtleties (heh), most discussed on Python-Dev already. Eyeballs, Neal? This no longer changes anything in the weakref implementation, but it does engage in weakref abuse, so I'd like Fred to peer at it too. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-17 07:38 Message: Logged In: YES user_id=31435 Back to me: I think there's a fundamental flaw here. Despite that it fixes the new test cases, what matters isn't really which objects are reachable from the objects whose deaths trigger callbacks, what matters is which objects are reachable from the callbacks themselves. Those are the ones that must not get tp_clear'ed before the callbacks run. In all the test cases so far, it turned out they were also reachable from the objects whose deaths trigger callbacks, so it seemed to work. But it should be possible to stumble into a tougher case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=843455&group_id=5470 From noreply at sourceforge.net Tue Nov 18 12:41:48 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 18 12:41:57 2003 Subject: [Patches] [ python-Patches-843455 ] Make weakref callbacks play nice in gc Message-ID: Patches item #843455, was opened at 2003-11-16 22:18 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=843455&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 9 Submitted By: Tim Peters (tim_one) >Assigned to: Tim Peters (tim_one) Summary: Make weakref callbacks play nice in gc Initial Comment: See bug 839548. Weakref callbacks attached to objects in dead cycles can see objects that have gone thru tp_clear() now, and can resurrect such objects too. A wide variety of bad things can result, up to and including segfaults. This implements a scheme I detailed on Python-Dev to teach gc about the bad things callbacks can do, still calling them, but ensuring that a callback can't reach any objects on which tp_clear has been invoked. If a callback happens to resurrect an object, tp_clear won't get invoked on the latter object at all by gc. This keeps Python-visible objects wholly sane, and even unsurprising. If this patch is accepted, I'll also check in a plain-text file with a version of the Python-Dev msg explaining the scheme. Neal, I most want your eyeballs on this, since you know the most about gc's design. Please assign to Fred when you're done (whether or not you can make time), because I want his eyeballs on the weakref changes. Two changes were made to the weakref implementation: (1) a new private API function _PyWeakref_HasCallback(), so gc can determine which objects have associated weakref callbacks; and, (2) because objects in cyclic trash don't have refcount 0, I had to remove the refcnt==0 check from PyObject_ClearWeakRefs(). Maybe it would be better to introduce a workalike private function that skipped that one check, and leave the public function alone? When reviewing this, note that it has to be backported to the 2.3 line too: 2.3.2 is the release in which Jim Fulton first saw segfaults in real life. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-11-18 12:41 Message: Logged In: YES user_id=31435 Na, I like that idea a lot! But maybe I didn't fully understand what you meant, so implemented a better idea . Assigned back to me until tests finish and I upload a new patch. Then back to Fred. It appears that gc and weakref internals *have* to know a lot about each other to prevent segfaults (etc), but the rework you suggested allows most of the obscure mucking with weakref internals to live inside the weakref module. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-11-18 12:09 Message: Logged In: YES user_id=35752 Well, scratch that last idea. After trying to come up with a patch I've concluded that it's not any cleaner. I also tried changing the weakref tp_clear method to not decref the wr_callback attribute. I'm not sure that's any better either since it spreads the subtle code around. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-11-18 11:26 Message: Logged In: YES user_id=35752 The patch looks sound. I think it would be cleaner if the weakref object provided a _PyWeakref_ClearRefs() function for the GC to use (that did not mess with the callback). That way the GC could just incref the weakref and call that function. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-18 00:52 Message: Logged In: YES user_id=31435 New patch (clear_first.txt). This implements a scheme of doing tp_clear() on trash weakrefs first, so that their callbacks get disabled. There are subtleties (heh), most discussed on Python-Dev already. Eyeballs, Neal? This no longer changes anything in the weakref implementation, but it does engage in weakref abuse, so I'd like Fred to peer at it too. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-17 02:38 Message: Logged In: YES user_id=31435 Back to me: I think there's a fundamental flaw here. Despite that it fixes the new test cases, what matters isn't really which objects are reachable from the objects whose deaths trigger callbacks, what matters is which objects are reachable from the callbacks themselves. Those are the ones that must not get tp_clear'ed before the callbacks run. In all the test cases so far, it turned out they were also reachable from the objects whose deaths trigger callbacks, so it seemed to work. But it should be possible to stumble into a tougher case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=843455&group_id=5470 From noreply at sourceforge.net Tue Nov 18 13:16:43 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 18 13:17:14 2003 Subject: [Patches] [ python-Patches-843455 ] Make weakref callbacks play nice in gc Message-ID: Patches item #843455, was opened at 2003-11-16 22:18 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=843455&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 9 Submitted By: Tim Peters (tim_one) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Make weakref callbacks play nice in gc Initial Comment: See bug 839548. Weakref callbacks attached to objects in dead cycles can see objects that have gone thru tp_clear() now, and can resurrect such objects too. A wide variety of bad things can result, up to and including segfaults. This implements a scheme I detailed on Python-Dev to teach gc about the bad things callbacks can do, still calling them, but ensuring that a callback can't reach any objects on which tp_clear has been invoked. If a callback happens to resurrect an object, tp_clear won't get invoked on the latter object at all by gc. This keeps Python-visible objects wholly sane, and even unsurprising. If this patch is accepted, I'll also check in a plain-text file with a version of the Python-Dev msg explaining the scheme. Neal, I most want your eyeballs on this, since you know the most about gc's design. Please assign to Fred when you're done (whether or not you can make time), because I want his eyeballs on the weakref changes. Two changes were made to the weakref implementation: (1) a new private API function _PyWeakref_HasCallback(), so gc can determine which objects have associated weakref callbacks; and, (2) because objects in cyclic trash don't have refcount 0, I had to remove the refcnt==0 check from PyObject_ClearWeakRefs(). Maybe it would be better to introduce a workalike private function that skipped that one check, and leave the public function alone? When reviewing this, note that it has to be backported to the 2.3 line too: 2.3.2 is the release in which Jim Fulton first saw segfaults in real life. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-11-18 13:16 Message: Logged In: YES user_id=31435 Assigned to Fred for weakref-abuse review. As Neal suggested, there's a new private _PyWeakref_ClearRef() function that allows most of the obscure weakref fiddling needed by gc to live inside the weakref module. The new patch is clear_first2.txt. I still need to write more tests, and finish writing comments for the tests already in the patch. I hope that none of the C code will need to change again. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-18 12:41 Message: Logged In: YES user_id=31435 Na, I like that idea a lot! But maybe I didn't fully understand what you meant, so implemented a better idea . Assigned back to me until tests finish and I upload a new patch. Then back to Fred. It appears that gc and weakref internals *have* to know a lot about each other to prevent segfaults (etc), but the rework you suggested allows most of the obscure mucking with weakref internals to live inside the weakref module. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-11-18 12:09 Message: Logged In: YES user_id=35752 Well, scratch that last idea. After trying to come up with a patch I've concluded that it's not any cleaner. I also tried changing the weakref tp_clear method to not decref the wr_callback attribute. I'm not sure that's any better either since it spreads the subtle code around. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-11-18 11:26 Message: Logged In: YES user_id=35752 The patch looks sound. I think it would be cleaner if the weakref object provided a _PyWeakref_ClearRefs() function for the GC to use (that did not mess with the callback). That way the GC could just incref the weakref and call that function. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-18 00:52 Message: Logged In: YES user_id=31435 New patch (clear_first.txt). This implements a scheme of doing tp_clear() on trash weakrefs first, so that their callbacks get disabled. There are subtleties (heh), most discussed on Python-Dev already. Eyeballs, Neal? This no longer changes anything in the weakref implementation, but it does engage in weakref abuse, so I'd like Fred to peer at it too. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-17 02:38 Message: Logged In: YES user_id=31435 Back to me: I think there's a fundamental flaw here. Despite that it fixes the new test cases, what matters isn't really which objects are reachable from the objects whose deaths trigger callbacks, what matters is which objects are reachable from the callbacks themselves. Those are the ones that must not get tp_clear'ed before the callbacks run. In all the test cases so far, it turned out they were also reachable from the objects whose deaths trigger callbacks, so it seemed to work. But it should be possible to stumble into a tougher case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=843455&group_id=5470 From noreply at sourceforge.net Tue Nov 18 14:04:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 18 14:04:40 2003 Subject: [Patches] [ python-Patches-843455 ] Make weakref callbacks play nice in gc Message-ID: Patches item #843455, was opened at 2003-11-17 03:18 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=843455&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 9 Submitted By: Tim Peters (tim_one) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Make weakref callbacks play nice in gc Initial Comment: See bug 839548. Weakref callbacks attached to objects in dead cycles can see objects that have gone thru tp_clear() now, and can resurrect such objects too. A wide variety of bad things can result, up to and including segfaults. This implements a scheme I detailed on Python-Dev to teach gc about the bad things callbacks can do, still calling them, but ensuring that a callback can't reach any objects on which tp_clear has been invoked. If a callback happens to resurrect an object, tp_clear won't get invoked on the latter object at all by gc. This keeps Python-visible objects wholly sane, and even unsurprising. If this patch is accepted, I'll also check in a plain-text file with a version of the Python-Dev msg explaining the scheme. Neal, I most want your eyeballs on this, since you know the most about gc's design. Please assign to Fred when you're done (whether or not you can make time), because I want his eyeballs on the weakref changes. Two changes were made to the weakref implementation: (1) a new private API function _PyWeakref_HasCallback(), so gc can determine which objects have associated weakref callbacks; and, (2) because objects in cyclic trash don't have refcount 0, I had to remove the refcnt==0 check from PyObject_ClearWeakRefs(). Maybe it would be better to introduce a workalike private function that skipped that one check, and leave the public function alone? When reviewing this, note that it has to be backported to the 2.3 line too: 2.3.2 is the release in which Jim Fulton first saw segfaults in real life. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2003-11-18 19:04 Message: Logged In: YES user_id=35752 Small nit: the comment "wr_callbacks mutates to contain temporarily-immortal weakref objects abused to hold temporarily immortal callbacks" confused me more than it helped. I was looking around for some trashcan-like pointer swapping. I think you mean that the weakrefs in wr_callbacks are temporarily made immortal so that their callbacks will not be deallocated. After the GC is done tearing things up with tp_clear then they are made mortal again. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-18 18:16 Message: Logged In: YES user_id=31435 Assigned to Fred for weakref-abuse review. As Neal suggested, there's a new private _PyWeakref_ClearRef() function that allows most of the obscure weakref fiddling needed by gc to live inside the weakref module. The new patch is clear_first2.txt. I still need to write more tests, and finish writing comments for the tests already in the patch. I hope that none of the C code will need to change again. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-18 17:41 Message: Logged In: YES user_id=31435 Na, I like that idea a lot! But maybe I didn't fully understand what you meant, so implemented a better idea . Assigned back to me until tests finish and I upload a new patch. Then back to Fred. It appears that gc and weakref internals *have* to know a lot about each other to prevent segfaults (etc), but the rework you suggested allows most of the obscure mucking with weakref internals to live inside the weakref module. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-11-18 17:09 Message: Logged In: YES user_id=35752 Well, scratch that last idea. After trying to come up with a patch I've concluded that it's not any cleaner. I also tried changing the weakref tp_clear method to not decref the wr_callback attribute. I'm not sure that's any better either since it spreads the subtle code around. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-11-18 16:26 Message: Logged In: YES user_id=35752 The patch looks sound. I think it would be cleaner if the weakref object provided a _PyWeakref_ClearRefs() function for the GC to use (that did not mess with the callback). That way the GC could just incref the weakref and call that function. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-18 05:52 Message: Logged In: YES user_id=31435 New patch (clear_first.txt). This implements a scheme of doing tp_clear() on trash weakrefs first, so that their callbacks get disabled. There are subtleties (heh), most discussed on Python-Dev already. Eyeballs, Neal? This no longer changes anything in the weakref implementation, but it does engage in weakref abuse, so I'd like Fred to peer at it too. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-17 07:38 Message: Logged In: YES user_id=31435 Back to me: I think there's a fundamental flaw here. Despite that it fixes the new test cases, what matters isn't really which objects are reachable from the objects whose deaths trigger callbacks, what matters is which objects are reachable from the callbacks themselves. Those are the ones that must not get tp_clear'ed before the callbacks run. In all the test cases so far, it turned out they were also reachable from the objects whose deaths trigger callbacks, so it seemed to work. But it should be possible to stumble into a tougher case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=843455&group_id=5470 From noreply at sourceforge.net Tue Nov 18 14:35:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 18 14:35:42 2003 Subject: [Patches] [ python-Patches-843455 ] Make weakref callbacks play nice in gc Message-ID: Patches item #843455, was opened at 2003-11-16 22:18 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=843455&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 9 Submitted By: Tim Peters (tim_one) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Make weakref callbacks play nice in gc Initial Comment: See bug 839548. Weakref callbacks attached to objects in dead cycles can see objects that have gone thru tp_clear() now, and can resurrect such objects too. A wide variety of bad things can result, up to and including segfaults. This implements a scheme I detailed on Python-Dev to teach gc about the bad things callbacks can do, still calling them, but ensuring that a callback can't reach any objects on which tp_clear has been invoked. If a callback happens to resurrect an object, tp_clear won't get invoked on the latter object at all by gc. This keeps Python-visible objects wholly sane, and even unsurprising. If this patch is accepted, I'll also check in a plain-text file with a version of the Python-Dev msg explaining the scheme. Neal, I most want your eyeballs on this, since you know the most about gc's design. Please assign to Fred when you're done (whether or not you can make time), because I want his eyeballs on the weakref changes. Two changes were made to the weakref implementation: (1) a new private API function _PyWeakref_HasCallback(), so gc can determine which objects have associated weakref callbacks; and, (2) because objects in cyclic trash don't have refcount 0, I had to remove the refcnt==0 check from PyObject_ClearWeakRefs(). Maybe it would be better to introduce a workalike private function that skipped that one check, and leave the public function alone? When reviewing this, note that it has to be backported to the 2.3 line too: 2.3.2 is the release in which Jim Fulton first saw segfaults in real life. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-11-18 14:35 Message: Logged In: YES user_id=31435 That's cool. New patch is clear_first3.txt. Comment changed to """ In the end, then, wr_callbacks consists of cleared weakrefs that are immune from collection. Near the end of gc, after collecting all the cyclic trash, we call release_weakrefs(). That releases our references to the cleared weakrefs, which in turn may trigger callbacks on their callbacks. """ That's no more complicated than it really is . New patch also has more comments in the new tests, and another new test setting up both "safe" and "unsafe" weakref callbacks *on* a weakref callback. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-11-18 14:04 Message: Logged In: YES user_id=35752 Small nit: the comment "wr_callbacks mutates to contain temporarily-immortal weakref objects abused to hold temporarily immortal callbacks" confused me more than it helped. I was looking around for some trashcan-like pointer swapping. I think you mean that the weakrefs in wr_callbacks are temporarily made immortal so that their callbacks will not be deallocated. After the GC is done tearing things up with tp_clear then they are made mortal again. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-18 13:16 Message: Logged In: YES user_id=31435 Assigned to Fred for weakref-abuse review. As Neal suggested, there's a new private _PyWeakref_ClearRef() function that allows most of the obscure weakref fiddling needed by gc to live inside the weakref module. The new patch is clear_first2.txt. I still need to write more tests, and finish writing comments for the tests already in the patch. I hope that none of the C code will need to change again. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-18 12:41 Message: Logged In: YES user_id=31435 Na, I like that idea a lot! But maybe I didn't fully understand what you meant, so implemented a better idea . Assigned back to me until tests finish and I upload a new patch. Then back to Fred. It appears that gc and weakref internals *have* to know a lot about each other to prevent segfaults (etc), but the rework you suggested allows most of the obscure mucking with weakref internals to live inside the weakref module. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-11-18 12:09 Message: Logged In: YES user_id=35752 Well, scratch that last idea. After trying to come up with a patch I've concluded that it's not any cleaner. I also tried changing the weakref tp_clear method to not decref the wr_callback attribute. I'm not sure that's any better either since it spreads the subtle code around. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-11-18 11:26 Message: Logged In: YES user_id=35752 The patch looks sound. I think it would be cleaner if the weakref object provided a _PyWeakref_ClearRefs() function for the GC to use (that did not mess with the callback). That way the GC could just incref the weakref and call that function. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-18 00:52 Message: Logged In: YES user_id=31435 New patch (clear_first.txt). This implements a scheme of doing tp_clear() on trash weakrefs first, so that their callbacks get disabled. There are subtleties (heh), most discussed on Python-Dev already. Eyeballs, Neal? This no longer changes anything in the weakref implementation, but it does engage in weakref abuse, so I'd like Fred to peer at it too. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-17 02:38 Message: Logged In: YES user_id=31435 Back to me: I think there's a fundamental flaw here. Despite that it fixes the new test cases, what matters isn't really which objects are reachable from the objects whose deaths trigger callbacks, what matters is which objects are reachable from the callbacks themselves. Those are the ones that must not get tp_clear'ed before the callbacks run. In all the test cases so far, it turned out they were also reachable from the objects whose deaths trigger callbacks, so it seemed to work. But it should be possible to stumble into a tougher case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=843455&group_id=5470 From noreply at sourceforge.net Tue Nov 18 14:46:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 18 14:47:00 2003 Subject: [Patches] [ python-Patches-794400 ] startup file compiler flags Message-ID: Patches item #794400, was opened at 2003-08-25 02:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=794400&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Eric Tiedemann (est) Assigned to: Nobody/Anonymous (nobody) Summary: startup file compiler flags Initial Comment: Allow the startup file to modify the compiler flags. This allows you, for example, to have true division automatically in interactive mode. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-18 20:46 Message: Logged In: YES user_id=21627 Thanks for the patch; applied as NEWS 1.893 main.c 1.80 ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2003-11-10 13:55 Message: Logged In: YES user_id=2772 I would expect the behavior of $PYTHONSTARTUP to be just like typing the commands in at the interactive prompt, except that the results of the individual expr_statements are not printed. That simply makes the old behavior (__future__ directives ignored) a bug. Instead of writing documentation that is specific "this works, but this doesn't", any remaining details of interpreter state that differ between $PYTHONSTARTUP and entering commands at the interactive prompt should be fixed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-10 07:47 Message: Logged In: YES user_id=21627 Eric, are you willing to contribute documentation changes? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-18 12:46 Message: Logged In: YES user_id=21627 I think there should be some documentation changes to document what precisely can be done in the startup code. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2003-09-01 16:15 Message: Logged In: YES user_id=2772 Works for me. It's a simple change, even though some code was moved out of line into a separate static function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=794400&group_id=5470 From noreply at sourceforge.net Tue Nov 18 14:51:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 18 14:51:27 2003 Subject: [Patches] [ python-Patches-842567 ] reflect the removal of mpz Message-ID: Patches item #842567, was opened at 2003-11-15 04:00 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=842567&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: reflect the removal of mpz Initial Comment: mpz's doc says "This module will be removed in Python 2.3" but Python 2.3 has been released, so it should read: "This module has been removed in Python 2.3" Python 2.3.2 (#1, Oct 9 2003, 12:03:29) Type "help", "copyright", "credits" or "license" for more information. >>> import mpz Traceback (most recent call last): File "", line 1, in ? ImportError: No module named mpz ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-18 20:51 Message: Logged In: YES user_id=21627 I believe the patch is incorrect; the module is still available. The fact that you don't have it probably originates from the fact that you don't have gmp build environment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=842567&group_id=5470 From noreply at sourceforge.net Tue Nov 18 14:54:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 18 14:54:56 2003 Subject: [Patches] [ python-Patches-841807 ] One more patch for --enable-shared Message-ID: Patches item #841807, was opened at 2003-11-14 00:12 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=841807&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Ondrej Palkovsky (ondrap) Assigned to: Nobody/Anonymous (nobody) Summary: One more patch for --enable-shared Initial Comment: There is a problem in the Makefile that during 'make install' rewrites the shared library name with the symbolic link, if on the platform they are defined to be the same in the config file. Currently this makes problem on HP-UX. This patch makes the install process first check if the names are the same and creates the link only if they are not. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-18 20:54 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as Makefile.pre.in 1.136.6.3 and 1.140. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=841807&group_id=5470 From noreply at sourceforge.net Tue Nov 18 15:01:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 18 15:01:37 2003 Subject: [Patches] [ python-Patches-836434 ] Build changes for AIX Message-ID: Patches item #836434, was opened at 2003-11-05 13:13 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=836434&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Ulrich Berning (uberning) Assigned to: Nobody/Anonymous (nobody) Summary: Build changes for AIX Initial Comment: On AIX the file dynload_aix.c is used to load shared modules. This code uses the load() and loadbind() calls to load and bind a shared module. These functions do not work with C++ extensions. Since AIX 4.2 the dlopen() and dlsym() calls are available and should be used in preference because they also work with C++ modules. The patch changes the configure(.in) script to prefer the usage of dynload_shlib.c when the dlopen() function is available (configure checks this). Another problem is the definition of _XOPEN_SOURCE = 600 in the configure(.in) script. On AIX 4, some typedefs are only available when _XOPEN_SOURCE has a value of 500, but are used even if _XOPEN_SOURCE has another value. This seems to be a bug in the AIX include files. If _XOPEN_SOURCE is undefined, the AIX include files define it with the value 500 and everything works as expected. So the patch sets "define_xopen_source=no" for AIX 4 in configure(.in) The attached patch contains the changes for configure.in and configure but normally only configure.in needs to be patched and then configure should be recreated with autoconf. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-18 21:01 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as configure 1.416.4.11 configure.in 1.427.4.10 configure 1.431 configure.in 1.441 In the future, please omit the configure part of the patch, as autoconf has to be run, anyway. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=836434&group_id=5470 From noreply at sourceforge.net Tue Nov 18 14:49:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 18 15:02:30 2003 Subject: [Patches] [ python-Patches-843088 ] doc fixes builtin super and string.replace Message-ID: Patches item #843088, was opened at 2003-11-16 11:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=843088&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: doc fixes builtin super and string.replace Initial Comment: - missing comma in builtin super function - rename maxsplit in string.replace to maxreplace. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-18 20:49 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as libfuncs.tex 1.143.8.7 libstring.tex 1.52.8.1 libfuncs.tex 1.153 libstring.tex 1.53 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=843088&group_id=5470 From noreply at sourceforge.net Tue Nov 18 15:08:43 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 18 15:08:47 2003 Subject: [Patches] [ python-Patches-755677 ] 755617: better docs for os.chmod Message-ID: Patches item #755677, was opened at 2003-06-17 05:35 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755677&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Christopher Blunck (blunck2) Assigned to: Martin v. L?wis (loewis) Summary: 755617: better docs for os.chmod Initial Comment: As per the discussion thread on c.l.p and summarized by Matthew Shomphe ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-18 21:08 Message: Logged In: YES user_id=21627 I'm rejecting the patch on ground that it does not actually fix the bug. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-18 11:43 Message: Logged In: YES user_id=21627 blunck2, are you willing to revise the patch in the indicated direction, i.e. document the real semantics of os.chmod on Windows, while keeping the material which primarily applies to Unix? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-20 18:04 Message: Logged In: YES user_id=21627 I don't think that patch fixes the bug - IMO, the description of mode gets worse, not better, with this patch: 1. The mode is *not* a "four-digit number". It is a plain integer instead. Some people find it convenient to write this number in base8, using Python's octal number notation. 2. Other people find it convenient to use a symbolic bit mask to compute the number. Your patch removes the listing of the possible symbolic constants, which is bad. 3. You fail to mention some of the bits (e.g. the s-bits) which are available in the current documentation. 4. The patch fails to address the platform differences which atleast logistix considers important, in his comment to #755617 ---------------------------------------------------------------------- Comment By: Christopher Blunck (blunck2) Date: 2003-06-23 15:12 Message: Logged In: YES user_id=531881 Sure- According to the discussion here: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=mailman.1055808030.15325.python-list%40python.org&rnum=1&prev=/groups%3Fq%3Dos.chmod%2Bgroup:comp.lang.python.*%26hl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.lang.python.*%26selm%3Dmailman.1055808030.15325.python-list%2540python.org%26rnum%3D1 there was confusion as the behavior of os.chmod() on non-Unix platforms. Discussion led to a recommendation for a documentation change, which was submitted as an attachment to the bug report located here: http://www.python.org/sf/755617 The submitter of the bug report didn't know how to submit a patch. I decided to capture the documentation, add it to the appropriate tex file, produce a patch, and submit it to sf. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-06-21 15:33 Message: Logged In: YES user_id=21627 Can you give the rationale for this change, for those of us that don't know which thread you are referring to? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755677&group_id=5470 From noreply at sourceforge.net Tue Nov 18 15:56:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 18 15:57:06 2003 Subject: [Patches] [ python-Patches-843455 ] Make weakref callbacks play nice in gc Message-ID: Patches item #843455, was opened at 2003-11-16 22:18 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=843455&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 9 Submitted By: Tim Peters (tim_one) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Make weakref callbacks play nice in gc Initial Comment: See bug 839548. Weakref callbacks attached to objects in dead cycles can see objects that have gone thru tp_clear() now, and can resurrect such objects too. A wide variety of bad things can result, up to and including segfaults. This implements a scheme I detailed on Python-Dev to teach gc about the bad things callbacks can do, still calling them, but ensuring that a callback can't reach any objects on which tp_clear has been invoked. If a callback happens to resurrect an object, tp_clear won't get invoked on the latter object at all by gc. This keeps Python-visible objects wholly sane, and even unsurprising. If this patch is accepted, I'll also check in a plain-text file with a version of the Python-Dev msg explaining the scheme. Neal, I most want your eyeballs on this, since you know the most about gc's design. Please assign to Fred when you're done (whether or not you can make time), because I want his eyeballs on the weakref changes. Two changes were made to the weakref implementation: (1) a new private API function _PyWeakref_HasCallback(), so gc can determine which objects have associated weakref callbacks; and, (2) because objects in cyclic trash don't have refcount 0, I had to remove the refcnt==0 check from PyObject_ClearWeakRefs(). Maybe it would be better to introduce a workalike private function that skipped that one check, and leave the public function alone? When reviewing this, note that it has to be backported to the 2.3 line too: 2.3.2 is the release in which Jim Fulton first saw segfaults in real life. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-11-18 15:56 Message: Logged In: YES user_id=31435 Jim Fulton told me he applied clear_first3.txt to the 2.3.2 release, and ran Zope3 against it without problems (no segfaults). Zope3 is what triggered the segfaults to begin with, so that's good news. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-18 14:35 Message: Logged In: YES user_id=31435 That's cool. New patch is clear_first3.txt. Comment changed to """ In the end, then, wr_callbacks consists of cleared weakrefs that are immune from collection. Near the end of gc, after collecting all the cyclic trash, we call release_weakrefs(). That releases our references to the cleared weakrefs, which in turn may trigger callbacks on their callbacks. """ That's no more complicated than it really is . New patch also has more comments in the new tests, and another new test setting up both "safe" and "unsafe" weakref callbacks *on* a weakref callback. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-11-18 14:04 Message: Logged In: YES user_id=35752 Small nit: the comment "wr_callbacks mutates to contain temporarily-immortal weakref objects abused to hold temporarily immortal callbacks" confused me more than it helped. I was looking around for some trashcan-like pointer swapping. I think you mean that the weakrefs in wr_callbacks are temporarily made immortal so that their callbacks will not be deallocated. After the GC is done tearing things up with tp_clear then they are made mortal again. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-18 13:16 Message: Logged In: YES user_id=31435 Assigned to Fred for weakref-abuse review. As Neal suggested, there's a new private _PyWeakref_ClearRef() function that allows most of the obscure weakref fiddling needed by gc to live inside the weakref module. The new patch is clear_first2.txt. I still need to write more tests, and finish writing comments for the tests already in the patch. I hope that none of the C code will need to change again. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-18 12:41 Message: Logged In: YES user_id=31435 Na, I like that idea a lot! But maybe I didn't fully understand what you meant, so implemented a better idea . Assigned back to me until tests finish and I upload a new patch. Then back to Fred. It appears that gc and weakref internals *have* to know a lot about each other to prevent segfaults (etc), but the rework you suggested allows most of the obscure mucking with weakref internals to live inside the weakref module. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-11-18 12:09 Message: Logged In: YES user_id=35752 Well, scratch that last idea. After trying to come up with a patch I've concluded that it's not any cleaner. I also tried changing the weakref tp_clear method to not decref the wr_callback attribute. I'm not sure that's any better either since it spreads the subtle code around. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-11-18 11:26 Message: Logged In: YES user_id=35752 The patch looks sound. I think it would be cleaner if the weakref object provided a _PyWeakref_ClearRefs() function for the GC to use (that did not mess with the callback). That way the GC could just incref the weakref and call that function. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-18 00:52 Message: Logged In: YES user_id=31435 New patch (clear_first.txt). This implements a scheme of doing tp_clear() on trash weakrefs first, so that their callbacks get disabled. There are subtleties (heh), most discussed on Python-Dev already. Eyeballs, Neal? This no longer changes anything in the weakref implementation, but it does engage in weakref abuse, so I'd like Fred to peer at it too. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-17 02:38 Message: Logged In: YES user_id=31435 Back to me: I think there's a fundamental flaw here. Despite that it fixes the new test cases, what matters isn't really which objects are reachable from the objects whose deaths trigger callbacks, what matters is which objects are reachable from the callbacks themselves. Those are the ones that must not get tp_clear'ed before the callbacks run. In all the test cases so far, it turned out they were also reachable from the objects whose deaths trigger callbacks, so it seemed to work. But it should be possible to stumble into a tougher case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=843455&group_id=5470 From noreply at sourceforge.net Tue Nov 18 22:23:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 18 22:23:23 2003 Subject: [Patches] [ python-Patches-842567 ] reflect the removal of mpz Message-ID: Patches item #842567, was opened at 2003-11-15 12:00 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=842567&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: reflect the removal of mpz Initial Comment: mpz's doc says "This module will be removed in Python 2.3" but Python 2.3 has been released, so it should read: "This module has been removed in Python 2.3" Python 2.3.2 (#1, Oct 9 2003, 12:03:29) Type "help", "copyright", "credits" or "license" for more information. >>> import mpz Traceback (most recent call last): File "", line 1, in ? ImportError: No module named mpz ---------------------------------------------------------------------- >Comment By: George Yoshida (quiver) Date: 2003-11-19 12:23 Message: Logged In: YES user_id=671362 Following your advice, I revised the previous patch. * remove the obscure part (This module will be removed in Python 2.3.) * add the version infomation to the availability of the module (use \versionchanged tag) I guess this is clearer what has changed since 2.3. The change is as follows: Deprecated since release 2.2. See the references at the end of this section for information about packages which provide similar functionality. This module will be removed in Python 2.3. This is an optional module. It is only available when Python is configured to include it, which requires that the GNU MP software is installed. --> patch applied Deprecated since release 2.2. See the references at the end of this section for information about packages which provide similar functionality. Changed in version 2.3: This is an optional module. It is only available when Python is configured to include it, which requires that the GNU MP software is installed. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-19 04:51 Message: Logged In: YES user_id=21627 I believe the patch is incorrect; the module is still available. The fact that you don't have it probably originates from the fact that you don't have gmp build environment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=842567&group_id=5470 From noreply at sourceforge.net Wed Nov 19 13:37:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 19 13:37:05 2003 Subject: [Patches] [ python-Patches-845306 ] socketmodule.c: fix for platforms w/o IPV6 (i.e.Solaris 5.7) Message-ID: Patches item #845306, was opened at 2003-11-19 13:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=845306&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Bachmann (matt979) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule.c: fix for platforms w/o IPV6 (i.e.Solaris 5.7) Initial Comment: Fixes Bug #818490 socketmodule.c will not compile on platforms without IPV6 support such as Solaris 5.7 because the AF_INET6 and INET_ADDRSTRLEN are used outside the ENABLE_IPV6 guarded sections. For example (lines 2971-2977): #ifndef ENABLE_IPV6 if(af == AF_INET6) { PyErr_SetString(socket_error, "can't use AF_INET6, IPv6 is disabled"); return NULL; } #endif The code is putting error checking in when IPV6 is not supported, but it is using the AF_INET6 define which does not exist on platforms w/o IPV6. I simply removed the block and let the check fall to the inet_pton call. I'm not so clear as what to do w/ INET_ADDRSTRLEN define because I'm not knowledgable about its history. At least under Solaris, INET_ADDRSTRLEN along with INET6_ADDRSTRLEN only appear w/ IPV6 support. In the patch, I simply substituted it with 16 which is the value. Since its just the number of characters in a dotted IP address, it seems like it would be pretty constant accross platforms. The diff given is against the r232 cvs tag. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=845306&group_id=5470 From noreply at sourceforge.net Thu Nov 20 16:27:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 20 16:27:22 2003 Subject: [Patches] [ python-Patches-843455 ] Make weakref callbacks play nice in gc Message-ID: Patches item #843455, was opened at 2003-11-16 22:18 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=843455&group_id=5470 Category: Core (C code) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 9 Submitted By: Tim Peters (tim_one) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Make weakref callbacks play nice in gc Initial Comment: See bug 839548. Weakref callbacks attached to objects in dead cycles can see objects that have gone thru tp_clear() now, and can resurrect such objects too. A wide variety of bad things can result, up to and including segfaults. This implements a scheme I detailed on Python-Dev to teach gc about the bad things callbacks can do, still calling them, but ensuring that a callback can't reach any objects on which tp_clear has been invoked. If a callback happens to resurrect an object, tp_clear won't get invoked on the latter object at all by gc. This keeps Python-visible objects wholly sane, and even unsurprising. If this patch is accepted, I'll also check in a plain-text file with a version of the Python-Dev msg explaining the scheme. Neal, I most want your eyeballs on this, since you know the most about gc's design. Please assign to Fred when you're done (whether or not you can make time), because I want his eyeballs on the weakref changes. Two changes were made to the weakref implementation: (1) a new private API function _PyWeakref_HasCallback(), so gc can determine which objects have associated weakref callbacks; and, (2) because objects in cyclic trash don't have refcount 0, I had to remove the refcnt==0 check from PyObject_ClearWeakRefs(). Maybe it would be better to introduce a workalike private function that skipped that one check, and leave the public function alone? When reviewing this, note that it has to be backported to the 2.3 line too: 2.3.2 is the release in which Jim Fulton first saw segfaults in real life. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-11-20 16:27 Message: Logged In: YES user_id=31435 I checked this in on the head, so closing it. I'll backport it to 2.3 maint. Fred, I think the changes to the weakref module were simple and harmless. But if you still want to review them, you're more than welcome to! Note that the new file Modules/gc_weakref.txt contains an account of the problem and how it was cured. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-18 15:56 Message: Logged In: YES user_id=31435 Jim Fulton told me he applied clear_first3.txt to the 2.3.2 release, and ran Zope3 against it without problems (no segfaults). Zope3 is what triggered the segfaults to begin with, so that's good news. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-18 14:35 Message: Logged In: YES user_id=31435 That's cool. New patch is clear_first3.txt. Comment changed to """ In the end, then, wr_callbacks consists of cleared weakrefs that are immune from collection. Near the end of gc, after collecting all the cyclic trash, we call release_weakrefs(). That releases our references to the cleared weakrefs, which in turn may trigger callbacks on their callbacks. """ That's no more complicated than it really is . New patch also has more comments in the new tests, and another new test setting up both "safe" and "unsafe" weakref callbacks *on* a weakref callback. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-11-18 14:04 Message: Logged In: YES user_id=35752 Small nit: the comment "wr_callbacks mutates to contain temporarily-immortal weakref objects abused to hold temporarily immortal callbacks" confused me more than it helped. I was looking around for some trashcan-like pointer swapping. I think you mean that the weakrefs in wr_callbacks are temporarily made immortal so that their callbacks will not be deallocated. After the GC is done tearing things up with tp_clear then they are made mortal again. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-18 13:16 Message: Logged In: YES user_id=31435 Assigned to Fred for weakref-abuse review. As Neal suggested, there's a new private _PyWeakref_ClearRef() function that allows most of the obscure weakref fiddling needed by gc to live inside the weakref module. The new patch is clear_first2.txt. I still need to write more tests, and finish writing comments for the tests already in the patch. I hope that none of the C code will need to change again. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-18 12:41 Message: Logged In: YES user_id=31435 Na, I like that idea a lot! But maybe I didn't fully understand what you meant, so implemented a better idea . Assigned back to me until tests finish and I upload a new patch. Then back to Fred. It appears that gc and weakref internals *have* to know a lot about each other to prevent segfaults (etc), but the rework you suggested allows most of the obscure mucking with weakref internals to live inside the weakref module. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-11-18 12:09 Message: Logged In: YES user_id=35752 Well, scratch that last idea. After trying to come up with a patch I've concluded that it's not any cleaner. I also tried changing the weakref tp_clear method to not decref the wr_callback attribute. I'm not sure that's any better either since it spreads the subtle code around. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-11-18 11:26 Message: Logged In: YES user_id=35752 The patch looks sound. I think it would be cleaner if the weakref object provided a _PyWeakref_ClearRefs() function for the GC to use (that did not mess with the callback). That way the GC could just incref the weakref and call that function. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-18 00:52 Message: Logged In: YES user_id=31435 New patch (clear_first.txt). This implements a scheme of doing tp_clear() on trash weakrefs first, so that their callbacks get disabled. There are subtleties (heh), most discussed on Python-Dev already. Eyeballs, Neal? This no longer changes anything in the weakref implementation, but it does engage in weakref abuse, so I'd like Fred to peer at it too. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-17 02:38 Message: Logged In: YES user_id=31435 Back to me: I think there's a fundamental flaw here. Despite that it fixes the new test cases, what matters isn't really which objects are reachable from the objects whose deaths trigger callbacks, what matters is which objects are reachable from the callbacks themselves. Those are the ones that must not get tp_clear'ed before the callbacks run. In all the test cases so far, it turned out they were also reachable from the objects whose deaths trigger callbacks, so it seemed to work. But it should be possible to stumble into a tougher case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=843455&group_id=5470 From noreply at sourceforge.net Fri Nov 21 01:29:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 01:29:27 2003 Subject: [Patches] [ python-Patches-846388 ] Check for signals during regular expression matches Message-ID: Patches item #846388, was opened at 2003-11-20 22:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=846388&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Josh Hoyt (joshhoyt) Assigned to: Nobody/Anonymous (nobody) Summary: Check for signals during regular expression matches Initial Comment: This patch adds a call to PyErr_CheckSignals to SRE_MATCH so that signal handlers can be invoked during long regular expression matches. It also adds a new error return value indicating that an exception occurred in a signal handler during the match, allowing exceptions in the signal handler to propagate up to the main loop. Rationale: Regular expressions can run away inside of the C code. There is no way for Python code to stop the C code from running away, so we attempted to use setrlimit to interrupt the process when the CPU usage exceeded a limit. When the signal was received, the signal function was triggered. The sre code does not allow the main loop to run, so the triggered handlers were not called until the regular expression finished, if ever. This behaviour makes the interruption by the signal useless for the purposes of constraining the running time of regular expression matches. I am unsure whether the PyErr_CheckSignals is lightweight enough to be called inside of the for loop in SRE_MATCH, so I took the conservative approach and only checked on recursion or match invocation. I believe that the performance hit from this check would not be prohibitive inside of the loop, since PyErr_CheckSignals does very little work unless there is a signal to handle. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=846388&group_id=5470 From noreply at sourceforge.net Fri Nov 21 10:53:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 10:53:27 2003 Subject: [Patches] [ python-Patches-846659 ] fix for bug #812325 (tarfile violates bufsize) Message-ID: Patches item #846659, was opened at 2003-11-21 16:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=846659&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: fix for bug #812325 (tarfile violates bufsize) Initial Comment: The attached patch fixes an error in the code for GNU longname/longlink creation. An additional GNU header block is added to the tar file but not summed up to the internal counter (self.offset). On close() the zeropadding is miscalculated which leads to blocksize violation at the end of the archive. I had a conversation with Johan Fredrik ?hman (johanfo) who reported bug #812325 and he told me that my patch solved his problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=846659&group_id=5470 From noreply at sourceforge.net Sat Nov 22 10:14:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 22 10:14:10 2003 Subject: [Patches] [ python-Patches-846388 ] Check for signals during regular expression matches Message-ID: Patches item #846388, was opened at 2003-11-21 07:29 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=846388&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Josh Hoyt (joshhoyt) Assigned to: Nobody/Anonymous (nobody) Summary: Check for signals during regular expression matches Initial Comment: This patch adds a call to PyErr_CheckSignals to SRE_MATCH so that signal handlers can be invoked during long regular expression matches. It also adds a new error return value indicating that an exception occurred in a signal handler during the match, allowing exceptions in the signal handler to propagate up to the main loop. Rationale: Regular expressions can run away inside of the C code. There is no way for Python code to stop the C code from running away, so we attempted to use setrlimit to interrupt the process when the CPU usage exceeded a limit. When the signal was received, the signal function was triggered. The sre code does not allow the main loop to run, so the triggered handlers were not called until the regular expression finished, if ever. This behaviour makes the interruption by the signal useless for the purposes of constraining the running time of regular expression matches. I am unsure whether the PyErr_CheckSignals is lightweight enough to be called inside of the for loop in SRE_MATCH, so I took the conservative approach and only checked on recursion or match invocation. I believe that the performance hit from this check would not be prohibitive inside of the loop, since PyErr_CheckSignals does very little work unless there is a signal to handle. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-22 16:14 Message: Logged In: YES user_id=21627 Can you give an example for a SRE matching that is so slow that the user may press Ctrl-C? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=846388&group_id=5470 From noreply at sourceforge.net Sun Nov 23 17:24:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 23 17:24:04 2003 Subject: [Patches] [ python-Patches-847857 ] Extend struct.unpack to product nested tuples Message-ID: Patches item #847857, was opened at 2003-11-23 16:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=847857&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthew F. Barnes (mfbarnes) Assigned to: Nobody/Anonymous (nobody) Summary: Extend struct.unpack to product nested tuples Initial Comment: This patch extends the struct.unpack format notation to be able to express groups of data with parentheses. For example: >>> data = struct.pack('iiii', 1, 2, 3, 4) >>> struct.unpack('i(ii)i', data) (1, (2, 3), 4) Integral repeat counts can also be applied to groups. >>> struct.unpack('2(ii)', data) ((1, 2), (3, 4)) In addition, struct.calcsize also handles parentheses in format strings correctly. >>> struct.calcsize('4(ii)') 32 No changes were made to struct.pack. It still treats parentheses as illegal format characters. I have not yet updated any documentation or tests associated with struct.calcsize or struct.unpack. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=847857&group_id=5470 From noreply at sourceforge.net Sun Nov 23 17:25:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 23 17:25:45 2003 Subject: [Patches] [ python-Patches-847857 ] Extend struct.unpack to produce nested tuples Message-ID: Patches item #847857, was opened at 2003-11-23 16:24 Message generated for change (Settings changed) made by mfbarnes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=847857&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthew F. Barnes (mfbarnes) Assigned to: Nobody/Anonymous (nobody) >Summary: Extend struct.unpack to produce nested tuples Initial Comment: This patch extends the struct.unpack format notation to be able to express groups of data with parentheses. For example: >>> data = struct.pack('iiii', 1, 2, 3, 4) >>> struct.unpack('i(ii)i', data) (1, (2, 3), 4) Integral repeat counts can also be applied to groups. >>> struct.unpack('2(ii)', data) ((1, 2), (3, 4)) In addition, struct.calcsize also handles parentheses in format strings correctly. >>> struct.calcsize('4(ii)') 32 No changes were made to struct.pack. It still treats parentheses as illegal format characters. I have not yet updated any documentation or tests associated with struct.calcsize or struct.unpack. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=847857&group_id=5470 From noreply at sourceforge.net Mon Nov 24 01:10:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 24 01:10:45 2003 Subject: [Patches] [ python-Patches-848017 ] One step closer to RFC 2109 Message-ID: Patches item #848017, was opened at 2003-11-23 22:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=848017&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Alfred Morgan (zectbumo) Assigned to: Nobody/Anonymous (nobody) Summary: One step closer to RFC 2109 Initial Comment: - Changed the default separator from \n to \r\n. - Suppressed the trailing semicolon. - Changed the examples because doctest doesn't allow carriage returns in the examples. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=848017&group_id=5470 From noreply at sourceforge.net Mon Nov 24 01:12:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 24 01:12:45 2003 Subject: [Patches] [ python-Patches-848017 ] Cookie.py: One step closer to RFC 2109 Message-ID: Patches item #848017, was opened at 2003-11-23 22:10 Message generated for change (Settings changed) made by zectbumo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=848017&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Alfred Morgan (zectbumo) Assigned to: Nobody/Anonymous (nobody) >Summary: Cookie.py: One step closer to RFC 2109 Initial Comment: - Changed the default separator from \n to \r\n. - Suppressed the trailing semicolon. - Changed the examples because doctest doesn't allow carriage returns in the examples. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=848017&group_id=5470 From noreply at sourceforge.net Tue Nov 25 03:56:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 25 06:02:29 2003 Subject: [Patches] [ python-Patches-848793 ] Rational bug Message-ID: Patches item #848793, was opened at 2003-11-25 08:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=848793&group_id=5470 Category: Demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Oren Tirosh (orenti) Assigned to: Nobody/Anonymous (nobody) Summary: Rational bug Initial Comment: Rational.py in the sandbox has a simple copy-and-paste error in argument checking. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=848793&group_id=5470 From noreply at sourceforge.net Tue Nov 25 06:36:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 25 06:36:48 2003 Subject: [Patches] [ python-Patches-848870 ] Flakey urllib2.parse_http_list Message-ID: Patches item #848870, was opened at 2003-11-25 22:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=848870&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: Flakey urllib2.parse_http_list Initial Comment: Breaks with the following challenge: realm="localhost",nonce="764d66b5e8c907eb5873d5d4c2131 1a1ad62535c",qop=auth,charset=utf-8,algorithm=md5-sess''' 'realm="localhost",nonce="764d66b5e8c907eb5873d5d4c213 11a1ad62535c",qop=auth,charset=utf-8,algorithm=md5-sess Suggest changing the implementation to: import csv def parse_http_list(s): """Parse lists as described by RFC 2068 Section 2. In particular, parse comman-separated lists where the elements of the list may include quoted-strings. A quoted-string could contain a comma. """ return csv.reader([s]).next() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=848870&group_id=5470 From noreply at sourceforge.net Tue Nov 25 06:38:54 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 25 06:39:00 2003 Subject: [Patches] [ python-Patches-848870 ] Flakey urllib2.parse_http_list Message-ID: Patches item #848870, was opened at 2003-11-25 22:36 Message generated for change (Settings changed) made by zenzen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=848870&group_id=5470 >Category: Library (Lib) >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: Flakey urllib2.parse_http_list Initial Comment: Breaks with the following challenge: realm="localhost",nonce="764d66b5e8c907eb5873d5d4c2131 1a1ad62535c",qop=auth,charset=utf-8,algorithm=md5-sess''' 'realm="localhost",nonce="764d66b5e8c907eb5873d5d4c213 11a1ad62535c",qop=auth,charset=utf-8,algorithm=md5-sess Suggest changing the implementation to: import csv def parse_http_list(s): """Parse lists as described by RFC 2068 Section 2. In particular, parse comman-separated lists where the elements of the list may include quoted-strings. A quoted-string could contain a comma. """ return csv.reader([s]).next() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=848870&group_id=5470 From noreply at sourceforge.net Tue Nov 25 06:53:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 25 06:53:51 2003 Subject: [Patches] [ python-Patches-848870 ] Flakey urllib2.parse_http_list Message-ID: Patches item #848870, was opened at 2003-11-25 22:36 Message generated for change (Comment added) made by zenzen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=848870&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: Flakey urllib2.parse_http_list Initial Comment: Breaks with the following challenge: realm="localhost",nonce="764d66b5e8c907eb5873d5d4c2131 1a1ad62535c",qop=auth,charset=utf-8,algorithm=md5-sess''' 'realm="localhost",nonce="764d66b5e8c907eb5873d5d4c213 11a1ad62535c",qop=auth,charset=utf-8,algorithm=md5-sess Suggest changing the implementation to: import csv def parse_http_list(s): """Parse lists as described by RFC 2068 Section 2. In particular, parse comman-separated lists where the elements of the list may include quoted-strings. A quoted-string could contain a comma. """ return csv.reader([s]).next() ---------------------------------------------------------------------- >Comment By: Stuart Bishop (zenzen) Date: 2003-11-25 22:53 Message: Logged In: YES user_id=46639 I appear to be cut & paste challenged. The challenge is: realm="localhost",nonce="764d66b5e8c907eb5873d5d4c2131 1a1ad62535c",qop=auth,charset=utf-8,algorithm=md5-sess Might not be worth fixing on the 2.3 branch, since this isn't actually generated from a webserver (its from jabberd). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=848870&group_id=5470 From noreply at sourceforge.net Tue Nov 25 15:20:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 25 15:20:46 2003 Subject: [Patches] [ python-Patches-849227 ] Remove int FutureWarnings (hex/oct) Message-ID: Patches item #849227, was opened at 2003-11-25 21:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849227&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kalle Svensson (krftkndl) Assigned to: Nobody/Anonymous (nobody) Summary: Remove int FutureWarnings (hex/oct) Initial Comment: This patch implements the hex/oct constant and shifting stuff from PEP 237, and removes the FutureWarnings about it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849227&group_id=5470 From noreply at sourceforge.net Tue Nov 25 15:58:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 25 15:58:16 2003 Subject: [Patches] [ python-Patches-849252 ] Small error in test_format Message-ID: Patches item #849252, was opened at 2003-11-25 21:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849252&group_id=5470 Category: Tests Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kalle Svensson (krftkndl) Assigned to: Nobody/Anonymous (nobody) Summary: Small error in test_format Initial Comment: There is an off-by-one bug in test_format, which causes a test that's supposed to run only on 32-bit machines to be skipped everywhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849252&group_id=5470 From noreply at sourceforge.net Tue Nov 25 16:20:54 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 25 16:22:05 2003 Subject: [Patches] [ python-Patches-848793 ] Rational bug Message-ID: Patches item #848793, was opened at 2003-11-25 03:56 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=848793&group_id=5470 Category: Demos and tools Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Oren Tirosh (orenti) Assigned to: Nobody/Anonymous (nobody) Summary: Rational bug Initial Comment: Rational.py in the sandbox has a simple copy-and-paste error in argument checking. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-25 16:20 Message: Logged In: YES user_id=80475 Applied to Rational.py 1.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=848793&group_id=5470 From noreply at sourceforge.net Tue Nov 25 16:25:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 25 16:25:47 2003 Subject: [Patches] [ python-Patches-849262 ] 832799 proposed changes Message-ID: Patches item #849262, was opened at 2003-11-25 16:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849262&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: 832799 proposed changes Initial Comment: 1) allow a subclass of build_ext.py to specify global extra_link_args in addition to the per-ext ones. 2) make the toplevel setup.py set this as specified by an environment var. 3) Make Makefile.pre.in set this up when building shared libs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849262&group_id=5470 From noreply at sourceforge.net Tue Nov 25 17:00:31 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 25 17:01:10 2003 Subject: [Patches] [ python-Patches-849278 ] improve embeddability of python Message-ID: Patches item #849278, was opened at 2003-11-25 17:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849278&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: improve embeddability of python Initial Comment: Add PyInitializeX that omits check in environment variables to set debugging, optimize, and verbose flags. Add PySetSysPaths to specify location of modules and the prefixes and the full path. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849278&group_id=5470 From noreply at sourceforge.net Tue Nov 25 19:49:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 25 19:49:08 2003 Subject: [Patches] [ python-Patches-849350 ] update docs for bool changes Message-ID: Patches item #849350, was opened at 2003-11-26 09:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849350&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: update docs for bool changes Initial Comment: This patch updates sample codes in the docs to reflect bool changes. (e.g. 1/0 is now True/False). I confirmed return values using Python 2.3 & 2.4. Following files are related: libdoctest.tex liboperator.tex libpprint.tex libweakref.tex -- "$ grep ^[01]$" found them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849350&group_id=5470 From noreply at sourceforge.net Tue Nov 25 22:41:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 25 22:42:02 2003 Subject: [Patches] [ python-Patches-849407 ] urllib reporthook could be more informative Message-ID: Patches item #849407, was opened at 2003-11-25 19:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849407&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Allan B. Wilson (allanbwilson) Assigned to: Nobody/Anonymous (nobody) Summary: urllib reporthook could be more informative Initial Comment: A reporthook in urllib.urlretrieve() (in 2.3.2) is given the max number of characters accepted ("bs") per .read() as its second argument. It would be more helpful to receive the number of characters actually retrieved in the most recent block. While perhaps this would break some existing code (though I can't imagine how), the minor patches below will allow giving progess updates, etc. that are accurate. Thanks Allan Wilson ------------ *** urllib.py.old Tue Nov 25 17:42:55 2003 --- urllib.py Tue Nov 25 18:00:50 2003 *************** *** 236,248 **** reporthook(0, bs, size) block = fp.read(bs) if reporthook: ! reporthook(1, bs, size) while block: tfp.write(block) block = fp.read(bs) blocknum = blocknum + 1 if reporthook: ! reporthook(blocknum, bs, size) fp.close() tfp.close() del fp --- 236,248 ---- reporthook(0, bs, size) block = fp.read(bs) if reporthook: ! reporthook(1, len(block), size) while block: tfp.write(block) block = fp.read(bs) blocknum = blocknum + 1 if reporthook: ! reporthook(blocknum, len(block), size) fp.close() tfp.close() del fp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849407&group_id=5470 From noreply at sourceforge.net Wed Nov 26 06:40:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 26 06:40:59 2003 Subject: [Patches] [ python-Patches-849595 ] socket.shutdown() constants Message-ID: Patches item #849595, was opened at 2003-11-26 14:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849595&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: socket.shutdown() constants Initial Comment: socket.shutdown() constants added to socket module: SHUT_RD Disables further receive operations. SHUT_WR Disables further send operations. SHUT_RDWR Disables further send and receive operations. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849595&group_id=5470 From noreply at sourceforge.net Thu Nov 27 14:40:48 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 27 14:40:56 2003 Subject: [Patches] [ python-Patches-849595 ] socket.shutdown() constants Message-ID: Patches item #849595, was opened at 2003-11-26 12:40 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849595&group_id=5470 Category: Modules Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: socket.shutdown() constants Initial Comment: socket.shutdown() constants added to socket module: SHUT_RD Disables further receive operations. SHUT_WR Disables further send operations. SHUT_RDWR Disables further send and receive operations. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-27 20:40 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as libsocket.tex 1.78 NEWS 1.900 socketmodule.c 1.279 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849595&group_id=5470 From noreply at sourceforge.net Thu Nov 27 14:41:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 27 14:41:26 2003 Subject: [Patches] [ python-Patches-849407 ] urllib reporthook could be more informative Message-ID: Patches item #849407, was opened at 2003-11-26 04:41 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849407&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Allan B. Wilson (allanbwilson) Assigned to: Nobody/Anonymous (nobody) Summary: urllib reporthook could be more informative Initial Comment: A reporthook in urllib.urlretrieve() (in 2.3.2) is given the max number of characters accepted ("bs") per .read() as its second argument. It would be more helpful to receive the number of characters actually retrieved in the most recent block. While perhaps this would break some existing code (though I can't imagine how), the minor patches below will allow giving progess updates, etc. that are accurate. Thanks Allan Wilson ------------ *** urllib.py.old Tue Nov 25 17:42:55 2003 --- urllib.py Tue Nov 25 18:00:50 2003 *************** *** 236,248 **** reporthook(0, bs, size) block = fp.read(bs) if reporthook: ! reporthook(1, bs, size) while block: tfp.write(block) block = fp.read(bs) blocknum = blocknum + 1 if reporthook: ! reporthook(blocknum, bs, size) fp.close() tfp.close() del fp --- 236,248 ---- reporthook(0, bs, size) block = fp.read(bs) if reporthook: ! reporthook(1, len(block), size) while block: tfp.write(block) block = fp.read(bs) blocknum = blocknum + 1 if reporthook: ! reporthook(blocknum, len(block), size) fp.close() tfp.close() del fp ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-27 20:41 Message: Logged In: YES user_id=21627 Can you please attach the patch, instead of pasting it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849407&group_id=5470 From noreply at sourceforge.net Thu Nov 27 14:48:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 27 14:48:34 2003 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 12:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None >Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2003-11-27 20:48 Message: Logged In: YES user_id=89016 Here the first part of the test_types port: list and tuple tests have been moved to their own scripts: test_tuple.py and test_list.py. Common tests for tuple, list and UserList are shared (in seq_test.py and list_test.py) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-02 03:53 Message: Logged In: YES user_id=80475 Applied as: Lib/test/test_slice.py 1.5. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 01:52 Message: Logged In: YES user_id=80475 Looks good. I added a couple of minor tests. Revised patch attached. Okay to apply. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-31 21:49 Message: Logged In: YES user_id=89016 Thanks! Here's another one: test_slice.py ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-31 01:04 Message: Logged In: YES user_id=80475 Done. See: Lib/test/test_longexp.py 1.9; previous revision: 1.8 Lib/test/test_pep263.py 1.3; previous revision: 1.2 Lib/test/test_sets.py 1.27; previous revision: 1.26 Lib/test/test_structseq.py 1.5; previous revision: 1.4 Lib/test/output/test_longexp delete; previous revision: 1.3 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 19:10 Message: Logged In: YES user_id=80475 Will do! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-30 19:06 Message: Logged In: YES user_id=89016 Here's test_structse.py converted with a few additional tests. If all three scripts are OK, could you check them in Raymond, as I'll be on vacation for three weeks? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-09 17:47 Message: Logged In: YES user_id=89016 Here are two simple ones: test_pep263 and test_longexp. I can't think of any additional tests to add. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-23 15:38 Message: Logged In: YES user_id=80475 Fixed Walter's review comments and committed as Lib/test/test_compile.py 1.19 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-23 13:49 Message: Logged In: YES user_id=89016 Are you sure, that the code path is the same in the new test_argument_handling() as in the old test? I.e. is "eval('lambda a,a: 0')" the same as "exec 'def f(a, a): pass'"? The print statement in test_float_literals should be changed to a comment. Should the imports in test_unary_minus() be moved to the start of the script? Otherwise the test looks (and runs) OK. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-20 21:26 Message: Logged In: YES user_id=80475 Here's one for you: test_compile.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-19 11:46 Message: Logged In: YES user_id=89016 Maybe test_types.py should be split into several scripts: test_dict, test_tuple, test_list, test_int, test_long etc. Some of them already exist (like test_long), some don't. The constructor tests from test_builtin should probably be moved to the new test scripts as well. Furthermore we should try to share as much testing functionality as possible (e.g. between test_int and test_long, or between test_list and test_userlist) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 21:48 Message: Logged In: YES user_id=80475 Great! Can I suggest that test_types.py be next. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-18 16:27 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_builtin.py 1.21 Lib/test/test_complex.py 1.10 (I've moved the constructor tests from test_builtin to test_complex) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 01:49 Message: Logged In: YES user_id=80475 I added a few tests. If they are fine with you, go ahead and commit. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 23:36 Message: Logged In: YES user_id=89016 Here's the next one: text_complex.py. There one test that's currently commented out, because it crashes Python on Alpha (see http://www.python.org/sf/756093. The old test scripts states that tests for the constructor are in test_builtin, but I've added many tests to this script, so this is no longer true. We could move the tests to test_builtin, but IMHO that doesn't make sense, we'd better move the rest of the constructor tests from test_builtin to test_complex. I'd like to have a version of assertAlmostEqual() in unittest.py that can cope with complex numbers, but this would have to be coordinated with the standalone version of PyUnit (and it would probably have to wait until the 2.4 cycle starts) (I noticed that there is no assertAlmostEqual in the code on pyunit.sf.net anyway.) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 14:06 Message: Logged In: YES user_id=89016 I'd like to keep this patch open, as it is an ongoing task (the next test scripts to be converted will be test_complex and then maybe test_marshal) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 23:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 21:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 21:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 20:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 20:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 18:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 14:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 19:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 18:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 17:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 15:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-19 01:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 05:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 04:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 03:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 02:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 01:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply at sourceforge.net Thu Nov 27 14:48:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 27 14:48:55 2003 Subject: [Patches] [ python-Patches-849350 ] update docs for bool changes Message-ID: Patches item #849350, was opened at 2003-11-26 01:49 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849350&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: update docs for bool changes Initial Comment: This patch updates sample codes in the docs to reflect bool changes. (e.g. 1/0 is now True/False). I confirmed return values using Python 2.3 & 2.4. Following files are related: libdoctest.tex liboperator.tex libpprint.tex libweakref.tex -- "$ grep ^[01]$" found them. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-27 20:48 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as libdoctest.tex 1.19 liboperator.tex 1.29 libpprint.tex 1.16 libweakref.tex 1.21 libdoctest.tex 1.17.8.2 liboperator.tex 1.27.12.2 libpprint.tex 1.15.18.1 libweakref.tex 1.19.8.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849350&group_id=5470 From noreply at sourceforge.net Thu Nov 27 16:57:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 27 16:58:05 2003 Subject: [Patches] [ python-Patches-839496 ] SimpleHTTPServer reports wrong content-length for text files Message-ID: Patches item #839496, was opened at 2003-11-10 21:42 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=839496&group_id=5470 >Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleHTTPServer reports wrong content-length for text files Initial Comment: (Python 2.3.2 on Windows) SimpleHTTPServer reports the size of the file on disk as Content-Length. This works except for text files. If the content type starts with "text/" it is opening the file in 'text' mode rather than 'binary' mode. At least on Windows this causes newline translations, thereby making the actual size of the content transmitted *less* than the content-length! I don't know why SimpleHTTPServer is reading text files with text mode. The included patch removes this distinction so all files are opened in binary mode (and, also on windows, the actual size transmitted is the same as the reported content-length). --Irmen de Jong ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=839496&group_id=5470 From noreply at sourceforge.net Thu Nov 27 18:12:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 27 18:12:12 2003 Subject: [Patches] [ python-Patches-850482 ] Enhance frame handing in warnings.warn() Message-ID: Patches item #850482, was opened at 2003-11-28 00:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=850482&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Enhance frame handing in warnings.warn() Initial Comment: This patch enhances warnings.warn() in the following way: The stacklevel passed in may be negative. In that case the call stack is searched for the innermost frame whose module name differs in the first -stacklevel components. This frame will be used in the report. So when you have the following call stack: m1.f() m1.m11.f() m1.m12.f() m2.m21.f() m2.m22.f() and the innermost function() m2.m22.f() call warnings.warn() with a stacklevel of -2 the frame reported will be from m1.m12.f(), because it is the first one from outside the m2 package. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=850482&group_id=5470 From noreply at sourceforge.net Fri Nov 28 07:47:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 28 07:47:38 2003 Subject: [Patches] [ python-Patches-850728 ] Semaphore.acquire() timeout parameter Message-ID: Patches item #850728, was opened at 2003-11-28 15:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=850728&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: Semaphore.acquire() timeout parameter Initial Comment: New optional timeout parameter for Semaphore.acquire(). acquire(block=True, timeout=None) When invoked with blocking set to true and timeout set to a positive number, it blocks at most timeout seconds and return false if the internal counter is still zero; otherwise return true. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=850728&group_id=5470 From noreply at sourceforge.net Fri Nov 28 10:55:48 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 28 10:55:53 2003 Subject: [Patches] [ python-Patches-850789 ] call com_set_lineno more often Message-ID: Patches item #850789, was opened at 2003-11-28 15:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=850789&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: call com_set_lineno more often Initial Comment: This patch makes Python/compile.c:com_node call com_set_lineno unconditionally, and removes all the other calls to the function, exploiting the fact that com_set_lineno is now a noop when unnecessary. I can't help feeling this is too easy. What have I missed? Resulting python passes make test, but that's not really news. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=850789&group_id=5470 From noreply at sourceforge.net Fri Nov 28 19:19:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 28 19:19:14 2003 Subject: [Patches] [ python-Patches-850977 ] Modify Setup.py to Detect Tcl/Tk on BSD Message-ID: Patches item #850977, was opened at 2003-11-28 19:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=850977&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: A.M. Kuchling (akuchling) Summary: Modify Setup.py to Detect Tcl/Tk on BSD Initial Comment: FreeBSD and OpenBSD set up libs as .../libtcl83 but includes as .../include/tcl8.3 Patch allows detection on OpenBSD w/o the use of Modules/Setup.local as is currently done in the port, also allows easier Python development on that platform (build w/o using ports). This is just an enhancement of the Debian detection method. Tested on OpenBSD and Linux. Assigning to Andrew for review, he's the last to work on this section of the code. Backport 2.3 candidate? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=850977&group_id=5470 From noreply at sourceforge.net Sat Nov 29 18:53:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 29 18:53:20 2003 Subject: [Patches] [ python-Patches-849227 ] Remove int FutureWarnings (hex/oct) Message-ID: Patches item #849227, was opened at 2003-11-25 15:20 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849227&group_id=5470 Category: Core (C code) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Kalle Svensson (krftkndl) Assigned to: Nobody/Anonymous (nobody) Summary: Remove int FutureWarnings (hex/oct) Initial Comment: This patch implements the hex/oct constant and shifting stuff from PEP 237, and removes the FutureWarnings about it. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-11-29 18:53 Message: Logged In: YES user_id=6380 Thanks! That was perfect. I've only changed a few details in test_compile, where test_unary_minus() seemed a little strange after the changes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849227&group_id=5470 From noreply at sourceforge.net Sat Nov 29 18:56:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 29 18:56:38 2003 Subject: [Patches] [ python-Patches-849252 ] Small error in test_format Message-ID: Patches item #849252, was opened at 2003-11-25 15:58 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849252&group_id=5470 Category: Tests >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kalle Svensson (krftkndl) Assigned to: Nobody/Anonymous (nobody) Summary: Small error in test_format Initial Comment: There is an off-by-one bug in test_format, which causes a test that's supposed to run only on 32-bit machines to be skipped everywhere. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-11-29 18:56 Message: Logged In: YES user_id=6380 Thanks, fixed in CVS. (I'm leaving this open since somebody might want to backport the fix to 2.3.3.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849252&group_id=5470 From noreply at sourceforge.net Sun Nov 30 01:27:55 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 30 01:27:57 2003 Subject: [Patches] [ python-Patches-851459 ] Argument passing from /usr/bin/idle2.3 to idle.py Message-ID: Patches item #851459, was opened at 2003-11-30 04:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851459&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Humberto Di?genes (virtualspirit) Assigned to: Nobody/Anonymous (nobody) Summary: Argument passing from /usr/bin/idle2.3 to idle.py Initial Comment: /usr/bin/idle2.3 wrapper (from the 2.3.2-1pydotorg rpm) ignores command-line arguments when calling idle.py. Fixed only by adding "$*" to the script. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851459&group_id=5470 From noreply at sourceforge.net Sun Nov 30 16:51:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 30 16:51:06 2003 Subject: [Patches] [ python-Patches-851736 ] urllib2 CacheFTPHandler doesn't work on multiple dirs Message-ID: Patches item #851736, was opened at 2003-11-30 21:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851736&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 CacheFTPHandler doesn't work on multiple dirs Initial Comment: This is a fix for bug 738973. Where are functional tests supposed to go? Is the __name__ == "__main__" block the official place? The urllib2 functional tests are quite out of date, thanks to shifting URLs, so I'd like to fix them, but need to know where to do it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851736&group_id=5470 From noreply at sourceforge.net Sun Nov 30 16:53:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 30 16:53:14 2003 Subject: [Patches] [ python-Patches-851736 ] urllib2 CacheFTPHandler doesn't work on multiple dirs Message-ID: Patches item #851736, was opened at 2003-11-30 21:51 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851736&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 CacheFTPHandler doesn't work on multiple dirs Initial Comment: This is a fix for bug 738973. Where are functional tests supposed to go? Is the __name__ == "__main__" block the official place? The urllib2 functional tests are quite out of date, thanks to shifting URLs, so I'd like to fix them, but need to know where to do it. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2003-11-30 21:53 Message: Logged In: YES user_id=261020 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851736&group_id=5470 From noreply at sourceforge.net Sun Nov 30 17:16:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 30 17:16:33 2003 Subject: [Patches] [ python-Patches-851752 ] urllib2 silently returns None when auth_uri is mismatched Message-ID: Patches item #851752, was opened at 2003-11-30 22:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851752&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 silently returns None when auth_uri is mismatched Initial Comment: Fix for 820583. Also clarifies what install_opener does, since people often seem confused about this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851752&group_id=5470 From noreply at sourceforge.net Sun Nov 30 17:26:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 30 17:26:09 2003 Subject: [Patches] [ python-Patches-817379 ] urllib2 does not allow for absolute ftp paths Message-ID: Patches item #817379, was opened at 2003-10-03 20:45 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=817379&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mihai Ibanescu (misa) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 does not allow for absolute ftp paths Initial Comment: urllib does the unquote() on FTP paths too early; therefore, URLs like: ftp://myname@host.dom/%2Fetc/motd are unquoted as: //etc/motd and then the wrong thing happens. The correct behaviour is documented in: http://ietf.org/rfc/rfc1738.txt section 3.2.2 Within a name or CWD component, the characters "/" and ";" are reserved and must be encoded. The components are decoded prior to their use in the FTP protocol. In particular, if the appropriate FTP sequence to access a particular file requires supplying a string containing a "/" as an argument to a CWD or RETR command, it is necessary to encode each "/". For example, the URL is interpreted by FTP-ing to "host.dom", logging in as "myname" (prompting for a password if it is asked for), and then executing "CWD /etc" and then "RETR motd". This has a different meaning from which would "CWD etc" and then "RETR motd"; the initial "CWD" might be executed relative to the default directory for "myname". On the other hand, , would "CWD " with a null argument, then "CWD etc", and then "RETR motd". ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-11-30 22:26 Message: Logged In: YES user_id=261020 This still hasn't been applied. The patch looks correct to me. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-10-03 21:59 Message: Logged In: YES user_id=31392 Sounds like an easy fix. I'll do it tonight. ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2003-10-03 20:48 Message: Logged In: YES user_id=205865 Note: patch was generated a long time ago against python 2.2.2, and I was sure I uploaded it to sourceforge. Anyway, patch still applies cleanly to 2.3.1 urllib2; the bug is still present in HEAD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=817379&group_id=5470