From noreply at sourceforge.net Thu Sep 1 00:13:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Aug 2005 15:13:40 -0700 Subject: [Patches] [ python-Patches-1276378 ] tarfile: adding filed that use direct device addressing Message-ID: Patches item #1276378, was opened at 2005-08-30 09:50 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1276378&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Urban Purkat (urbanp) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile: adding filed that use direct device addressing Initial Comment: The module tarfile has problems using os.stat() if the filenames use direct device addressing on Windows systems. For example: \?\GLOBALROOT\Device\HarddiskVolume1\TEMP\1.txt The following error is reported: Traceback (most recent call last): File "C:\urbanp\py\test.py", line 9, in ? tar.add('\\?\GLOBALROOT\Device\HarddiskVolume1\TEMP\1.txt', 'TEMP\1.txt') File "C:\PROGRA~1\Python23\lib\tarfile.py", line 1204, in add tarinfo = self.gettarinfo(name, arcname) File "C:\PROGRA~1\Python23\lib\tarfile.py", line 1080, in gettarinfo statres = os.lstat(name) OSError: [Errno 2] No such file or directory: '\\?\GLOBALROOT\Device\HarddiskVolume1\TEMP\1.txt' As a solution we can use win32file.GetFileAttributesEx(). I mapped win32file.GetFileAttributesEx result into a tuple that has the same structure as a os.stat result tuple. Therefore, the same variable can be used. The reason for using direct device addressing is that I need to create a tar package from a volume snapshot (vss on Windows 2003) that cannot be mounted. The solution also works on StorageCraft VSnap snapshots. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-01 00:13 Message: Logged In: YES user_id=1188172 I don't know whether direct device addressing is officially supported by any part of Python anyway. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1276378&group_id=5470 From noreply at sourceforge.net Thu Sep 1 00:22:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Aug 2005 15:22:22 -0700 Subject: [Patches] [ python-Patches-1242579 ] bltinmodule.c whitespace normalization Message-ID: Patches item #1242579, was opened at 2005-07-21 22:12 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1242579&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Ruslan Spivak (alienoid) Assigned to: Nobody/Anonymous (nobody) Summary: bltinmodule.c whitespace normalization Initial Comment: bltinmodule.c whitespace normalization ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-01 00:22 Message: Logged In: YES user_id=1188172 Python/bltinmodule.c r2.324. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1242579&group_id=5470 From noreply at sourceforge.net Thu Sep 1 00:27:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Aug 2005 15:27:07 -0700 Subject: [Patches] [ python-Patches-1227545 ] Patch for (Doc) bug #1212195 Message-ID: Patches item #1227545, was opened at 2005-06-26 00:03 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1227545&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter van Kampen (pterk) Assigned to: M.-A. Lemburg (lemburg) Summary: Patch for (Doc) bug #1212195 Initial Comment: Doc-patch for both libstring.tex and libstdtypes.tex. Added warning for the upper, lower and swapcase in libstring.tex and upper, lower, title and swapcase in libstdtypes.tex. warning: {function} can change the encoding of 8-bit strings for some locales. In libstdtypes I left the remark "For 8-bit strings, this method is locale-dependent." intact. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-01 00:27 Message: Logged In: YES user_id=1188172 The patch only adds warnings. The note about locale-dependency is there since bug #935749 was fixed. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-31 22:42 Message: Logged In: YES user_id=38388 Please remove the warnings - they sound much too dramatic. Otherwise, adding the note on the locale-dependency is good. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-04 20:17 Message: Logged In: YES user_id=1188172 I can't judge whether this is correct. Assigning to the bug assignee. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1227545&group_id=5470 From noreply at sourceforge.net Thu Sep 1 00:29:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Aug 2005 15:29:21 -0700 Subject: [Patches] [ python-Patches-1212921 ] option to allow reload to affect existing instances Message-ID: Patches item #1212921, was opened at 2005-06-01 20:18 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212921&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Brett Rosen (bdrosen) Assigned to: Nobody/Anonymous (nobody) Summary: option to allow reload to affect existing instances Initial Comment: One of the commonly asked questions (especially when developing GUI apps) is how do I reload a modified python file and have the existing instances automatically get the changed behavior. (this greatly speeds up the development cycle.) Unfortunately python doesn't support this without having to do the work yourself. To rectify this, I've implemented smart reloading as detailed below: Smart reloading is defined as applying modified code to your already instantiated objects on reload. Supporting smart reloading for python: Make sure that you execute python with the -r flag if you want smart reloading to work by default. The semantics of reload work as normal The normal model has been expanded by adding two special attributes to classes: 1 __pqname__ : This is used to give a hint as to our context if we are a nested class (top level classes don't need to use it) It specifies the parent hierarchy, excluding the module name. ie: class outer(object): class middle(object): __pqname__ = "outer" class inner(object): __pqname__ = "outer.middle" excluding this for inner classes can lead to confusion if you have multiple inner classes with the same name. 2 __reloadMode__ : This can have one of the 3 values - "overlay", "clear" and "disable" a) clear is the default if you are in reload mode (-r) and you don't specify anything. The behavior here is to clear the class dictionary before doing the reload of the class. b) overlay works like clear except that it doesn't clear the class dictionary first. c) disable gives you the classic python behavior and is the default if you are not in reload mode (no -r specified) When using this you almost never want to reuse class names in a module file. For example: class foo(object): ... class foo(object): ... would be bad. The second class foo replaces the first one, although with overlay it could be used as syntactic sugar for adding new methods to an existing class. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-01 00:29 Message: Logged In: YES user_id=1188172 Does anyone care to give a quick, obliterative judgement about this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212921&group_id=5470 From noreply at sourceforge.net Thu Sep 1 00:30:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Aug 2005 15:30:23 -0700 Subject: [Patches] [ python-Patches-1212928 ] new patch for fixing skipitem() in getargs.c Message-ID: Patches item #1212928, was opened at 2005-06-01 20:21 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212928&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Reinhold Birkenfeld (birkenfeld) >Assigned to: Raymond Hettinger (rhettinger) Summary: new patch for fixing skipitem() in getargs.c Initial Comment: This patch subsumes #985713 and #853890. In Python/getargs.c, the function skipitem() has not been updated with new argument format codes, such as u, u#, w, w# etc. This is corrected with this patch. There are two possibilities: either all new codes are added to the switch statement (this is the file getargs-skipitem-diff), or the function is rewritten so that there is no need for a switch (because the pointer type for va_arg is irrelevant). That solution is in the file new_skipitem.c. Remaining issue: I don't know if the '(...)' formatting code should be handled here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212928&group_id=5470 From noreply at sourceforge.net Thu Sep 1 00:36:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Aug 2005 15:36:01 -0700 Subject: [Patches] [ python-Patches-1225466 ] fileinput openfile patch, bz2fileinput Message-ID: Patches item #1225466, was opened at 2005-06-22 13:50 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1225466&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Stephan Boettcher (sib4) Assigned to: Nobody/Anonymous (nobody) Summary: fileinput openfile patch, bz2fileinput Initial Comment: Please consider the enclosed patch to fileinput.py, which implements an openfile method of FileInput. Included is a use case bz2fileinput.py. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-01 00:36 Message: Logged In: YES user_id=1188172 In addition to hoffmanm's question about the renaming of FileInput, two issues: - An additional module, especially with only a few lines in it, is not going to be accepted into the stdlib. This is better done in your own code, where you know what types of files you will encounter. See patch #1215184, which implements a similar openhook for fileinput. - Only bz2 is too selective. You would have to have modules "gzfileinput", "urlfileinput", etc. Too much name crowding. For these reasons, rejecting this patch. ---------------------------------------------------------------------- Comment By: Michael Hoffman (hoffmanm) Date: 2005-06-30 09:51 Message: Logged In: YES user_id=987664 Hmmm. This could be useful. Pythonistas could also supply openfile for, say, URLs as well. I'm kind of lukewarm on it for some reason--I think that you'd be better off decompressing the data somewhere else. I also did some benchmarking the other day and found that fileinput is really, really slow. I don't understand the change from Fileinput to _Fileinput. You're going to need to fix the inplace stuff in Fileinput.readline(). This needs documentation, and a more detailed description. Please provide a patch against the latest CVS instead of Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1225466&group_id=5470 From noreply at sourceforge.net Thu Sep 1 00:38:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Aug 2005 15:38:22 -0700 Subject: [Patches] [ python-Patches-1243678 ] httplib gzip support Message-ID: Patches item #1243678, was opened at 2005-07-23 20:51 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1243678&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Moonz (mooonz) Assigned to: Nobody/Anonymous (nobody) Summary: httplib gzip support Initial Comment: Add gzip support for httplib. It seems to work correctly - according to the tests I did done, but some points should be altered (I think to the putrequest method, where I didn't change anything - except the two lines of comments who said that the gzip support is not included) ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-01 00:38 Message: Logged In: YES user_id=1188172 This will need documentation and test suite changes, too. ---------------------------------------------------------------------- Comment By: Moonz (mooonz) Date: 2005-07-23 20:54 Message: Logged In: YES user_id=826215 It's better with the patch ;) ---------------------------------------------------------------------- Comment By: Moonz (mooonz) Date: 2005-07-23 20:54 Message: Logged In: YES user_id=826215 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1243678&group_id=5470 From noreply at sourceforge.net Thu Sep 1 00:50:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Aug 2005 15:50:09 -0700 Subject: [Patches] [ python-Patches-1242454 ] shutil.copytree() quits too soon after an error. Message-ID: Patches item #1242454, was opened at 2005-07-21 19:24 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1242454&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Dale Wilson (dalewilson) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.copytree() quits too soon after an error. Initial Comment: When shutil.copytree has been called recursively and catches an error from copy2 it adds the message to the errors list, then continues to copy the remaining items in that directory. This is good. At the end of the directory, however it raises an Error which escapes all the way back to the original caller. As a result the remaining contents of any parent directories do not get copied. The attached patch adds an "except Error" on the try surrounding the recursive call. Errors are accumulated then the copy continues. The result is that all files that can be copied do get copied and all files that cannot be copied are accumulated in the Error that ultimately is thrown to the caller. . ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-01 00:50 Message: Logged In: YES user_id=1188172 The patch had an error in it: """except Error, errors""" Here "errors" is NOT the list of errors given as argument to the exception when raised with """raise Error, errors""". Apart from that, applied the change as Lib/shutil.py 1.37, 1.34.2.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1242454&group_id=5470 From noreply at sourceforge.net Thu Sep 1 10:18:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Sep 2005 01:18:29 -0700 Subject: [Patches] [ python-Patches-1227545 ] Patch for (Doc) bug #1212195 Message-ID: Patches item #1227545, was opened at 2005-06-26 00:03 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1227545&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Peter van Kampen (pterk) Assigned to: M.-A. Lemburg (lemburg) Summary: Patch for (Doc) bug #1212195 Initial Comment: Doc-patch for both libstring.tex and libstdtypes.tex. Added warning for the upper, lower and swapcase in libstring.tex and upper, lower, title and swapcase in libstdtypes.tex. warning: {function} can change the encoding of 8-bit strings for some locales. In libstdtypes I left the remark "For 8-bit strings, this method is locale-dependent." intact. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-09-01 10:18 Message: Logged In: YES user_id=38388 Closing the patch as no longer needed. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-01 00:27 Message: Logged In: YES user_id=1188172 The patch only adds warnings. The note about locale-dependency is there since bug #935749 was fixed. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-31 22:42 Message: Logged In: YES user_id=38388 Please remove the warnings - they sound much too dramatic. Otherwise, adding the note on the locale-dependency is good. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-04 20:17 Message: Logged In: YES user_id=1188172 I can't judge whether this is correct. Assigning to the bug assignee. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1227545&group_id=5470 From noreply at sourceforge.net Thu Sep 1 11:38:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Sep 2005 02:38:40 -0700 Subject: [Patches] [ python-Patches-1212921 ] option to allow reload to affect existing instances Message-ID: Patches item #1212921, was opened at 2005-06-01 19:18 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212921&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Brett Rosen (bdrosen) Assigned to: Nobody/Anonymous (nobody) Summary: option to allow reload to affect existing instances Initial Comment: One of the commonly asked questions (especially when developing GUI apps) is how do I reload a modified python file and have the existing instances automatically get the changed behavior. (this greatly speeds up the development cycle.) Unfortunately python doesn't support this without having to do the work yourself. To rectify this, I've implemented smart reloading as detailed below: Smart reloading is defined as applying modified code to your already instantiated objects on reload. Supporting smart reloading for python: Make sure that you execute python with the -r flag if you want smart reloading to work by default. The semantics of reload work as normal The normal model has been expanded by adding two special attributes to classes: 1 __pqname__ : This is used to give a hint as to our context if we are a nested class (top level classes don't need to use it) It specifies the parent hierarchy, excluding the module name. ie: class outer(object): class middle(object): __pqname__ = "outer" class inner(object): __pqname__ = "outer.middle" excluding this for inner classes can lead to confusion if you have multiple inner classes with the same name. 2 __reloadMode__ : This can have one of the 3 values - "overlay", "clear" and "disable" a) clear is the default if you are in reload mode (-r) and you don't specify anything. The behavior here is to clear the class dictionary before doing the reload of the class. b) overlay works like clear except that it doesn't clear the class dictionary first. c) disable gives you the classic python behavior and is the default if you are not in reload mode (no -r specified) When using this you almost never want to reuse class names in a module file. For example: class foo(object): ... class foo(object): ... would be bad. The second class foo replaces the first one, although with overlay it could be used as syntactic sugar for adding new methods to an existing class. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-09-01 10:38 Message: Logged In: YES user_id=6656 My first thought is to plug my recipe: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/160164 In fact, this seems pretty similar to what the patch does, on a quick skim. Given that the bulk of the functionality can be implemented in Python, I'm not sure *I* support the further complication of type_new for this. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-31 23:29 Message: Logged In: YES user_id=1188172 Does anyone care to give a quick, obliterative judgement about this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212921&group_id=5470 From noreply at sourceforge.net Thu Sep 1 16:01:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Sep 2005 07:01:06 -0700 Subject: [Patches] [ python-Patches-1225466 ] fileinput openfile patch, bz2fileinput Message-ID: Patches item #1225466, was opened at 2005-06-22 11:50 Message generated for change (Comment added) made by sib4 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1225466&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.3 Status: Closed Resolution: Rejected Priority: 5 Submitted By: Stephan Boettcher (sib4) Assigned to: Nobody/Anonymous (nobody) Summary: fileinput openfile patch, bz2fileinput Initial Comment: Please consider the enclosed patch to fileinput.py, which implements an openfile method of FileInput. Included is a use case bz2fileinput.py. ---------------------------------------------------------------------- >Comment By: Stephan Boettcher (sib4) Date: 2005-09-01 14:01 Message: Logged In: YES user_id=252223 Sorry for not responding in time to those questions. My proposal was meant to provide the openfile method, and provide the user with a way to override it and still use the static infrastructure if the fileinput module, as demonstrated by bz2fileinput.py. Instead of using the hook "_FileInput" to provide a replacement class to the module, it may be better to replace FileInput.openfile() in derived modules, but I thought that may be even more of a hack. If you think this is worth following up, please advise of the best way to achieve this goal. Thanks Stephan ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-31 22:36 Message: Logged In: YES user_id=1188172 In addition to hoffmanm's question about the renaming of FileInput, two issues: - An additional module, especially with only a few lines in it, is not going to be accepted into the stdlib. This is better done in your own code, where you know what types of files you will encounter. See patch #1215184, which implements a similar openhook for fileinput. - Only bz2 is too selective. You would have to have modules "gzfileinput", "urlfileinput", etc. Too much name crowding. For these reasons, rejecting this patch. ---------------------------------------------------------------------- Comment By: Michael Hoffman (hoffmanm) Date: 2005-06-30 07:51 Message: Logged In: YES user_id=987664 Hmmm. This could be useful. Pythonistas could also supply openfile for, say, URLs as well. I'm kind of lukewarm on it for some reason--I think that you'd be better off decompressing the data somewhere else. I also did some benchmarking the other day and found that fileinput is really, really slow. I don't understand the change from Fileinput to _Fileinput. You're going to need to fix the inplace stuff in Fileinput.readline(). This needs documentation, and a more detailed description. Please provide a patch against the latest CVS instead of Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1225466&group_id=5470 From noreply at sourceforge.net Thu Sep 1 19:33:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Sep 2005 10:33:11 -0700 Subject: [Patches] [ python-Patches-1245379 ] Encoding alias "unicode-1-1-utf-7" Message-ID: Patches item #1245379, was opened at 2005-07-26 18:37 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1245379&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Oren Tirosh (orenti) Assigned to: Nobody/Anonymous (nobody) Summary: Encoding alias "unicode-1-1-utf-7" Initial Comment: The utf7 encoding seems to be used quite a lot in Europe for emails (probably because it's more compact and readable than utf8+base64 or utf8+quopri). Some systems use the encoding name "unicode-1-1-utf-7" for 'utf7': http://www.google.com/search?q=unicode-1-1-utf-7 This patch adds this name as an alias for utf7. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-09-01 19:33 Message: Logged In: YES user_id=89016 Here's another version of the patch. BTW, "UNICODE-1-1-UTF-7" is explicitely mentioned in RFC 1642 (http://www.faqs.org/rfcs/rfc1642.html) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-09 17:03 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1245379&group_id=5470 From noreply at sourceforge.net Fri Sep 2 20:55:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Sep 2005 11:55:09 -0700 Subject: [Patches] [ python-Patches-1268314 ] Cache lines in StreamReader.readlines Message-ID: Patches item #1268314, was opened at 2005-08-24 16:13 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1268314&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. L?wis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Cache lines in StreamReader.readlines Initial Comment: Currently, the splitlines result is discarded, and only the first line is used. Then, when another line is requested, the rest string is split again. With this patch, the splitlines result is preserved if it has more than two lines, and subsequent .readline calls get their results from self.linebuffer. Data is either in self.linebuffer or self.charbuffer; read() converts the linebuffer back to a charbuffer in case somebody mixes .read and .readline calls. On a file with 104 lines (103 of them being "pass") and 542 bytes, the number of _IsLinebreak calls went down from 6770 to 550 ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-09-02 20:55 Message: Logged In: YES user_id=89016 Is there any change that this patch gets into 2.4.2? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1268314&group_id=5470 From noreply at sourceforge.net Fri Sep 2 23:36:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Sep 2005 14:36:05 -0700 Subject: [Patches] [ python-Patches-1212921 ] option to allow reload to affect existing instances Message-ID: Patches item #1212921, was opened at 2005-06-01 14:18 Message generated for change (Comment added) made by tczotter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212921&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Brett Rosen (bdrosen) Assigned to: Nobody/Anonymous (nobody) Summary: option to allow reload to affect existing instances Initial Comment: One of the commonly asked questions (especially when developing GUI apps) is how do I reload a modified python file and have the existing instances automatically get the changed behavior. (this greatly speeds up the development cycle.) Unfortunately python doesn't support this without having to do the work yourself. To rectify this, I've implemented smart reloading as detailed below: Smart reloading is defined as applying modified code to your already instantiated objects on reload. Supporting smart reloading for python: Make sure that you execute python with the -r flag if you want smart reloading to work by default. The semantics of reload work as normal The normal model has been expanded by adding two special attributes to classes: 1 __pqname__ : This is used to give a hint as to our context if we are a nested class (top level classes don't need to use it) It specifies the parent hierarchy, excluding the module name. ie: class outer(object): class middle(object): __pqname__ = "outer" class inner(object): __pqname__ = "outer.middle" excluding this for inner classes can lead to confusion if you have multiple inner classes with the same name. 2 __reloadMode__ : This can have one of the 3 values - "overlay", "clear" and "disable" a) clear is the default if you are in reload mode (-r) and you don't specify anything. The behavior here is to clear the class dictionary before doing the reload of the class. b) overlay works like clear except that it doesn't clear the class dictionary first. c) disable gives you the classic python behavior and is the default if you are not in reload mode (no -r specified) When using this you almost never want to reuse class names in a module file. For example: class foo(object): ... class foo(object): ... would be bad. The second class foo replaces the first one, although with overlay it could be used as syntactic sugar for adding new methods to an existing class. ---------------------------------------------------------------------- Comment By: Ted Czotter (tczotter) Date: 2005-09-02 17:35 Message: Logged In: YES user_id=1339137 Ahh - finally someone is interested in this one. Michael's recipe does address *some* of the same problems solved by this patch, but not all. Before I get into more detail, let's be clear about something. The reload wart is a problem of inconvenience, not the inability to do something. For ordinary development, when I make a change in one module, I save time and avoid mistakes if I don't have to: * reload other modules * restart all or part of my application and thereby have to recover my state Neither of these stop me from developing, they just slow me down. So a good solution is going to be measured on three things: 1) How well it improves my efficiency as a developer. 2) The level of effort required to use the solution. Ok. So the core of the wart is that when you re-compile a class, a *new* class is created, instead of altering the definitions bound to the existing class. The symptoms are: * Existing instances (like open dialogs or sockets) continue to use the old class and don't inherit new behavior. * Existing subclasses refer to the old base class and any instances created in the future are still inheriting old behavior. Michael's recipe addresses these symptoms. Are there other important symptoms? Unfortunately, yes. * OTHER REFERENCES TO THE OLD CLASS EXIST Where? All over the place. Consider this: from mycompany.corporateframework.gui.widgets import Button, CheckBox # This *module* now points to the old Button and CheckBox. # Many calls to Button() and CheckBox() follow in methods after this. The recipe can't find and fix these references. If I was using the recipe, I'd have to reload all these modules. But then I compound the problem. Reloading these other modules creates *still more new classes*, causing dozens of *other* modules to need reloading. In the end, I'm better off just restarting the whole darn application. I understand that I could take advantage of the fact that modules retain their identity and so if I use fully qualified names everywhere, I won't have this problem because I'd always be looking up the latest class. But realistically, who is going to type b = mycompany.corporateframework.gui.widgets.Button("OK") all the time instead of just: b = Button("OK") Making people use python "a certain way" that is not idiomatic (i.e. automatic, normal, how we do things every day) is a problem and lowers the usefulness of the solution. And I'm certainly not about to suggest that anybody go through our 30,000 lines of python code to make such idiomatic changes so the recipe can work. Anyway, even if I did accept that tactic (and I don't) I'm still not out of the woods. Consider warehouses and factories. Here you are storing pointers to classes in containers for later invocations. For example, In wx, the grid class requires that you register classes to be used later for in-place editing in a grid. All these registrations are pointing to old class definitions. To fix the problem, we have to re- register. Which usually means reloading some modules. Which means reloading some more modules - you get it by now. So as a result, my first measures of success are not met very well by the recipe. Yes, I can type foo.DoLatestThing() at the console, but in real life I'm still going to have to restart my application a lot. On the other hand, the patch addresses the *cause* of the problem instead of some of the symptoms. ****** The true cause is that re-compiled classes change their identity. ****** With this patch, they do not. They retain their identity just like modules do. All the symptoms go away. Now let's talk about the harm the recipe does. What harm you ask? Well to make it work you have to make all your most-base classes use Michael's metaclass. Unfortunately, we already use metaclasses for a lot of things. And we use multiple inheritance a lot (we like mixins). How fast can you say "metaclass conflict"? I like what metaclasses do and I'm happy that Python let's me extend "internal" behavior so neatly. But the metaclass conflict is another serious wart. If we can avoid it, good. And I'm not happy that I seriously have to edit a few hundred class definitions in existing code to get the benefit of the recipe. **** The patch approach requires ZERO changes to existing applications. Z E R O **** Brett and I work at the same company. He made this patch because we were wasting hundreds of hours debugging reload problems or just quitting the application and restarting. I've been using this patch now for 3 months. It has saved our company hundreds of man-hours and we didn't have to change one line of existing code to make it work. If the community doesn't want to use it, I'm fine with that. I just want to make sure that you fully understand what you are giving up. Ted Czotter CTO Lavastorm Technologies ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-09-01 05:38 Message: Logged In: YES user_id=6656 My first thought is to plug my recipe: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/160164 In fact, this seems pretty similar to what the patch does, on a quick skim. Given that the bulk of the functionality can be implemented in Python, I'm not sure *I* support the further complication of type_new for this. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-31 18:29 Message: Logged In: YES user_id=1188172 Does anyone care to give a quick, obliterative judgement about this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212921&group_id=5470 From noreply at sourceforge.net Sat Sep 3 11:57:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Sep 2005 02:57:02 -0700 Subject: [Patches] [ python-Patches-1212921 ] option to allow reload to affect existing instances Message-ID: Patches item #1212921, was opened at 2005-06-01 19:18 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212921&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Brett Rosen (bdrosen) Assigned to: Nobody/Anonymous (nobody) Summary: option to allow reload to affect existing instances Initial Comment: One of the commonly asked questions (especially when developing GUI apps) is how do I reload a modified python file and have the existing instances automatically get the changed behavior. (this greatly speeds up the development cycle.) Unfortunately python doesn't support this without having to do the work yourself. To rectify this, I've implemented smart reloading as detailed below: Smart reloading is defined as applying modified code to your already instantiated objects on reload. Supporting smart reloading for python: Make sure that you execute python with the -r flag if you want smart reloading to work by default. The semantics of reload work as normal The normal model has been expanded by adding two special attributes to classes: 1 __pqname__ : This is used to give a hint as to our context if we are a nested class (top level classes don't need to use it) It specifies the parent hierarchy, excluding the module name. ie: class outer(object): class middle(object): __pqname__ = "outer" class inner(object): __pqname__ = "outer.middle" excluding this for inner classes can lead to confusion if you have multiple inner classes with the same name. 2 __reloadMode__ : This can have one of the 3 values - "overlay", "clear" and "disable" a) clear is the default if you are in reload mode (-r) and you don't specify anything. The behavior here is to clear the class dictionary before doing the reload of the class. b) overlay works like clear except that it doesn't clear the class dictionary first. c) disable gives you the classic python behavior and is the default if you are not in reload mode (no -r specified) When using this you almost never want to reuse class names in a module file. For example: class foo(object): ... class foo(object): ... would be bad. The second class foo replaces the first one, although with overlay it could be used as syntactic sugar for adding new methods to an existing class. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-09-03 10:57 Message: Logged In: YES user_id=6656 Oh, come on, my recipe could very clearly be changed to mutate the overridden class instead of assigning to its instances' __class__ attribute. *My* point is that there's very little the patch does that can't be done in Python. type_new is already far too complicated, this adds more complication. The main advantage your patch has over my recipe is that it edits the default metaclass which obviates the need to edit any class statements and avoids metaclass conflict issues. Is that enough to override my objections above? Maybe, maybe not. I'll think about it. (PS: a touch less bombast would be nice) ---------------------------------------------------------------------- Comment By: Ted Czotter (tczotter) Date: 2005-09-02 22:35 Message: Logged In: YES user_id=1339137 Ahh - finally someone is interested in this one. Michael's recipe does address *some* of the same problems solved by this patch, but not all. Before I get into more detail, let's be clear about something. The reload wart is a problem of inconvenience, not the inability to do something. For ordinary development, when I make a change in one module, I save time and avoid mistakes if I don't have to: * reload other modules * restart all or part of my application and thereby have to recover my state Neither of these stop me from developing, they just slow me down. So a good solution is going to be measured on three things: 1) How well it improves my efficiency as a developer. 2) The level of effort required to use the solution. Ok. So the core of the wart is that when you re-compile a class, a *new* class is created, instead of altering the definitions bound to the existing class. The symptoms are: * Existing instances (like open dialogs or sockets) continue to use the old class and don't inherit new behavior. * Existing subclasses refer to the old base class and any instances created in the future are still inheriting old behavior. Michael's recipe addresses these symptoms. Are there other important symptoms? Unfortunately, yes. * OTHER REFERENCES TO THE OLD CLASS EXIST Where? All over the place. Consider this: from mycompany.corporateframework.gui.widgets import Button, CheckBox # This *module* now points to the old Button and CheckBox. # Many calls to Button() and CheckBox() follow in methods after this. The recipe can't find and fix these references. If I was using the recipe, I'd have to reload all these modules. But then I compound the problem. Reloading these other modules creates *still more new classes*, causing dozens of *other* modules to need reloading. In the end, I'm better off just restarting the whole darn application. I understand that I could take advantage of the fact that modules retain their identity and so if I use fully qualified names everywhere, I won't have this problem because I'd always be looking up the latest class. But realistically, who is going to type b = mycompany.corporateframework.gui.widgets.Button("OK") all the time instead of just: b = Button("OK") Making people use python "a certain way" that is not idiomatic (i.e. automatic, normal, how we do things every day) is a problem and lowers the usefulness of the solution. And I'm certainly not about to suggest that anybody go through our 30,000 lines of python code to make such idiomatic changes so the recipe can work. Anyway, even if I did accept that tactic (and I don't) I'm still not out of the woods. Consider warehouses and factories. Here you are storing pointers to classes in containers for later invocations. For example, In wx, the grid class requires that you register classes to be used later for in-place editing in a grid. All these registrations are pointing to old class definitions. To fix the problem, we have to re- register. Which usually means reloading some modules. Which means reloading some more modules - you get it by now. So as a result, my first measures of success are not met very well by the recipe. Yes, I can type foo.DoLatestThing() at the console, but in real life I'm still going to have to restart my application a lot. On the other hand, the patch addresses the *cause* of the problem instead of some of the symptoms. ****** The true cause is that re-compiled classes change their identity. ****** With this patch, they do not. They retain their identity just like modules do. All the symptoms go away. Now let's talk about the harm the recipe does. What harm you ask? Well to make it work you have to make all your most-base classes use Michael's metaclass. Unfortunately, we already use metaclasses for a lot of things. And we use multiple inheritance a lot (we like mixins). How fast can you say "metaclass conflict"? I like what metaclasses do and I'm happy that Python let's me extend "internal" behavior so neatly. But the metaclass conflict is another serious wart. If we can avoid it, good. And I'm not happy that I seriously have to edit a few hundred class definitions in existing code to get the benefit of the recipe. **** The patch approach requires ZERO changes to existing applications. Z E R O **** Brett and I work at the same company. He made this patch because we were wasting hundreds of hours debugging reload problems or just quitting the application and restarting. I've been using this patch now for 3 months. It has saved our company hundreds of man-hours and we didn't have to change one line of existing code to make it work. If the community doesn't want to use it, I'm fine with that. I just want to make sure that you fully understand what you are giving up. Ted Czotter CTO Lavastorm Technologies ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-09-01 10:38 Message: Logged In: YES user_id=6656 My first thought is to plug my recipe: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/160164 In fact, this seems pretty similar to what the patch does, on a quick skim. Given that the bulk of the functionality can be implemented in Python, I'm not sure *I* support the further complication of type_new for this. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-31 23:29 Message: Logged In: YES user_id=1188172 Does anyone care to give a quick, obliterative judgement about this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212921&group_id=5470 From noreply at sourceforge.net Sat Sep 3 11:57:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Sep 2005 02:57:20 -0700 Subject: [Patches] [ python-Patches-1212921 ] option to allow reload to affect existing instances Message-ID: Patches item #1212921, was opened at 2005-06-01 19:18 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212921&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Brett Rosen (bdrosen) Assigned to: Nobody/Anonymous (nobody) Summary: option to allow reload to affect existing instances Initial Comment: One of the commonly asked questions (especially when developing GUI apps) is how do I reload a modified python file and have the existing instances automatically get the changed behavior. (this greatly speeds up the development cycle.) Unfortunately python doesn't support this without having to do the work yourself. To rectify this, I've implemented smart reloading as detailed below: Smart reloading is defined as applying modified code to your already instantiated objects on reload. Supporting smart reloading for python: Make sure that you execute python with the -r flag if you want smart reloading to work by default. The semantics of reload work as normal The normal model has been expanded by adding two special attributes to classes: 1 __pqname__ : This is used to give a hint as to our context if we are a nested class (top level classes don't need to use it) It specifies the parent hierarchy, excluding the module name. ie: class outer(object): class middle(object): __pqname__ = "outer" class inner(object): __pqname__ = "outer.middle" excluding this for inner classes can lead to confusion if you have multiple inner classes with the same name. 2 __reloadMode__ : This can have one of the 3 values - "overlay", "clear" and "disable" a) clear is the default if you are in reload mode (-r) and you don't specify anything. The behavior here is to clear the class dictionary before doing the reload of the class. b) overlay works like clear except that it doesn't clear the class dictionary first. c) disable gives you the classic python behavior and is the default if you are not in reload mode (no -r specified) When using this you almost never want to reuse class names in a module file. For example: class foo(object): ... class foo(object): ... would be bad. The second class foo replaces the first one, although with overlay it could be used as syntactic sugar for adding new methods to an existing class. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-09-03 10:57 Message: Logged In: YES user_id=6656 Oh, come on, my recipe could very clearly be changed to mutate the overridden class instead of assigning to its instances' __class__ attribute. *My* point is that there's very little the patch does that can't be done in Python. type_new is already far too complicated, this adds more complication. The main advantage your patch has over my recipe is that it edits the default metaclass which obviates the need to edit any class statements and avoids metaclass conflict issues. Is that enough to override my objections above? Maybe, maybe not. I'll think about it. (PS: a touch less bombast would be nice) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-09-03 10:57 Message: Logged In: YES user_id=6656 Oh, come on, my recipe could very clearly be changed to mutate the overridden class instead of assigning to its instances' __class__ attribute. *My* point is that there's very little the patch does that can't be done in Python. type_new is already far too complicated, this adds more complication. The main advantage your patch has over my recipe is that it edits the default metaclass which obviates the need to edit any class statements and avoids metaclass conflict issues. Is that enough to override my objections above? Maybe, maybe not. I'll think about it. (PS: a touch less bombast would be nice) ---------------------------------------------------------------------- Comment By: Ted Czotter (tczotter) Date: 2005-09-02 22:35 Message: Logged In: YES user_id=1339137 Ahh - finally someone is interested in this one. Michael's recipe does address *some* of the same problems solved by this patch, but not all. Before I get into more detail, let's be clear about something. The reload wart is a problem of inconvenience, not the inability to do something. For ordinary development, when I make a change in one module, I save time and avoid mistakes if I don't have to: * reload other modules * restart all or part of my application and thereby have to recover my state Neither of these stop me from developing, they just slow me down. So a good solution is going to be measured on three things: 1) How well it improves my efficiency as a developer. 2) The level of effort required to use the solution. Ok. So the core of the wart is that when you re-compile a class, a *new* class is created, instead of altering the definitions bound to the existing class. The symptoms are: * Existing instances (like open dialogs or sockets) continue to use the old class and don't inherit new behavior. * Existing subclasses refer to the old base class and any instances created in the future are still inheriting old behavior. Michael's recipe addresses these symptoms. Are there other important symptoms? Unfortunately, yes. * OTHER REFERENCES TO THE OLD CLASS EXIST Where? All over the place. Consider this: from mycompany.corporateframework.gui.widgets import Button, CheckBox # This *module* now points to the old Button and CheckBox. # Many calls to Button() and CheckBox() follow in methods after this. The recipe can't find and fix these references. If I was using the recipe, I'd have to reload all these modules. But then I compound the problem. Reloading these other modules creates *still more new classes*, causing dozens of *other* modules to need reloading. In the end, I'm better off just restarting the whole darn application. I understand that I could take advantage of the fact that modules retain their identity and so if I use fully qualified names everywhere, I won't have this problem because I'd always be looking up the latest class. But realistically, who is going to type b = mycompany.corporateframework.gui.widgets.Button("OK") all the time instead of just: b = Button("OK") Making people use python "a certain way" that is not idiomatic (i.e. automatic, normal, how we do things every day) is a problem and lowers the usefulness of the solution. And I'm certainly not about to suggest that anybody go through our 30,000 lines of python code to make such idiomatic changes so the recipe can work. Anyway, even if I did accept that tactic (and I don't) I'm still not out of the woods. Consider warehouses and factories. Here you are storing pointers to classes in containers for later invocations. For example, In wx, the grid class requires that you register classes to be used later for in-place editing in a grid. All these registrations are pointing to old class definitions. To fix the problem, we have to re- register. Which usually means reloading some modules. Which means reloading some more modules - you get it by now. So as a result, my first measures of success are not met very well by the recipe. Yes, I can type foo.DoLatestThing() at the console, but in real life I'm still going to have to restart my application a lot. On the other hand, the patch addresses the *cause* of the problem instead of some of the symptoms. ****** The true cause is that re-compiled classes change their identity. ****** With this patch, they do not. They retain their identity just like modules do. All the symptoms go away. Now let's talk about the harm the recipe does. What harm you ask? Well to make it work you have to make all your most-base classes use Michael's metaclass. Unfortunately, we already use metaclasses for a lot of things. And we use multiple inheritance a lot (we like mixins). How fast can you say "metaclass conflict"? I like what metaclasses do and I'm happy that Python let's me extend "internal" behavior so neatly. But the metaclass conflict is another serious wart. If we can avoid it, good. And I'm not happy that I seriously have to edit a few hundred class definitions in existing code to get the benefit of the recipe. **** The patch approach requires ZERO changes to existing applications. Z E R O **** Brett and I work at the same company. He made this patch because we were wasting hundreds of hours debugging reload problems or just quitting the application and restarting. I've been using this patch now for 3 months. It has saved our company hundreds of man-hours and we didn't have to change one line of existing code to make it work. If the community doesn't want to use it, I'm fine with that. I just want to make sure that you fully understand what you are giving up. Ted Czotter CTO Lavastorm Technologies ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-09-01 10:38 Message: Logged In: YES user_id=6656 My first thought is to plug my recipe: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/160164 In fact, this seems pretty similar to what the patch does, on a quick skim. Given that the bulk of the functionality can be implemented in Python, I'm not sure *I* support the further complication of type_new for this. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-31 23:29 Message: Logged In: YES user_id=1188172 Does anyone care to give a quick, obliterative judgement about this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212921&group_id=5470 From noreply at sourceforge.net Sun Sep 4 13:40:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Sep 2005 04:40:17 -0700 Subject: [Patches] [ python-Patches-1281573 ] String formatting character for str.join Message-ID: Patches item #1281573, was opened at 2005-09-04 21: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=1281573&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: String formatting character for str.join Initial Comment: Current string formatting doesn't provide an easy way to say "put the contents of this sequence here, using this string as the separator". The only generic way is to use the '%s' formatting character, and then put "sep.join(map(str, seq))" in the appropriate place. This isn't so obvious with lists and tuples, as their default string representations are usually good enough. When trying to add debug statements for iterators, however, the current behaviour is a pain. This patch adds a '%j' (for 'join) formatting character that allows a separator string to be specified between the percent symbol and the format character. For example, "%'\n'j" would indicate that a newline should be used to separate items in the supplied iterable. At this point (initial posting) the patch doesn't support Unicode objects, and doesn't have any tests or documentation - it is solely a proof of concept. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1281573&group_id=5470 From noreply at sourceforge.net Sun Sep 4 13:53:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Sep 2005 04:53:46 -0700 Subject: [Patches] [ python-Patches-1281573 ] String formatting character for str.join Message-ID: Patches item #1281573, was opened at 2005-09-04 21:40 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1281573&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: String formatting character for str.join Initial Comment: Current string formatting doesn't provide an easy way to say "put the contents of this sequence here, using this string as the separator". The only generic way is to use the '%s' formatting character, and then put "sep.join(map(str, seq))" in the appropriate place. This isn't so obvious with lists and tuples, as their default string representations are usually good enough. When trying to add debug statements for iterators, however, the current behaviour is a pain. This patch adds a '%j' (for 'join) formatting character that allows a separator string to be specified between the percent symbol and the format character. For example, "%'\n'j" would indicate that a newline should be used to separate items in the supplied iterable. At this point (initial posting) the patch doesn't support Unicode objects, and doesn't have any tests or documentation - it is solely a proof of concept. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2005-09-04 21:53 Message: Logged In: YES user_id=1038590 Hmm, looks like this version has a few problems dealing with generators, so avoid it unless you don't mind the odd seg fault. . . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1281573&group_id=5470 From noreply at sourceforge.net Sun Sep 4 14:26:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Sep 2005 05:26:17 -0700 Subject: [Patches] [ python-Patches-1281573 ] String formatting character for str.join Message-ID: Patches item #1281573, was opened at 2005-09-04 21:40 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1281573&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: String formatting character for str.join Initial Comment: Current string formatting doesn't provide an easy way to say "put the contents of this sequence here, using this string as the separator". The only generic way is to use the '%s' formatting character, and then put "sep.join(map(str, seq))" in the appropriate place. This isn't so obvious with lists and tuples, as their default string representations are usually good enough. When trying to add debug statements for iterators, however, the current behaviour is a pain. This patch adds a '%j' (for 'join) formatting character that allows a separator string to be specified between the percent symbol and the format character. For example, "%'\n'j" would indicate that a newline should be used to separate items in the supplied iterable. At this point (initial posting) the patch doesn't support Unicode objects, and doesn't have any tests or documentation - it is solely a proof of concept. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2005-09-04 22:26 Message: Logged In: YES user_id=1038590 2nd version attached which fixed some problems with handling generators by cleaning up the reference counting and not trying to get too fancy when having to convert non-strings. Tested with the following simple test cases: $ ./python -c "print '%j' % range(10)" 0123456789 $ ./python -c "print '%j' % (x for x in range(10))" 0123456789 $ ./python -c "print '%j' % (x*x for x in range(10))" 0149162536496481 $ ./python -c "print '%\ \j' % (x*x for x in range(10))" 0 1 4 9 16 25 36 49 64 81 ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-09-04 21:53 Message: Logged In: YES user_id=1038590 Hmm, looks like this version has a few problems dealing with generators, so avoid it unless you don't mind the odd seg fault. . . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1281573&group_id=5470 From noreply at sourceforge.net Sun Sep 4 15:09:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Sep 2005 06:09:42 -0700 Subject: [Patches] [ python-Patches-1251748 ] compiler package: "global a; a=5" Message-ID: Patches item #1251748, was opened at 2005-08-04 10:28 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1251748&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: compiler package: "global a; a=5" Initial Comment: The stdlib compiler package produces wrong code for "global a; a=5". It produces a STORE_NAME instead of a STORE_GLOBAL. Quick patch from Michael attached. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-09-04 13:09 Message: Logged In: YES user_id=4771 The compiler package contains several bugs along the lines of the one reported here. It doesn't seem to be that much used; with PyPy it is probably the first time that this package is tested in-depth, as we are trying to pass CPython's own test suite by using only this compiler package. We had to make a few involved fixes. Attached is a diff against the 2.4 maintenance head of CPython (we based our changes on 2.4.1). If there is interest, I can extract individual parts of the big diff and/or port them to 2.5 CVS HEAD. For now I will only give a quick overview of the diff. * the more involved problem was related to scoping of variables. This turned out to be more difficult to fix than mwh's patch (included in this tracker). (Disclaimer: Michael never pretended his patch was more than a quick hack.) For reference, see the following code snippets: http://codespeak.net/svn/pypy/dist/pypy/interpreter/test/test_syntax.py * we try to always raise SyntaxErrors with line number information. (Note sure if this has been done completely yet.) * pyassem.py has some heavy changes that I cannot comment on (don't know about them). Other changes there are related to scoping flags. * a number of situations should raise a SyntaxError, but were silently accepted (and generally produce weird bytecodes). * fixed docstring handling. Previously, in interactive mode, entering "hello" produced no result at all -- because the string was interpreted as a docstring! Also, a genuine docstring on the same line as a statement -- "docstring"; x=5 -- would result in the statement being ignored. * we can pass future flags from outside now. * lambda functions didn't get the official name . (Yeah, I know it's a detail, but a CPython test fails because of that.) * added raising of SyntaxWarnings. * the st->ast transformer 'single' mode now returns a Module AST node instead of a Stmt. This matches more closely what the rest of the package expects. * some minor changes in transformer.py are probably not interesting to CPython (e.g. changing some () into []). Their goal was to make transformer.py statically typeable for PyPy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1251748&group_id=5470 From noreply at sourceforge.net Sun Sep 4 19:53:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Sep 2005 10:53:44 -0700 Subject: [Patches] [ python-Patches-1281707 ] Speed up gzip.readline (~40%) Message-ID: Patches item #1281707, was opened at 2005-09-04 12: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=1281707&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: April King (marumari) Assigned to: Nobody/Anonymous (nobody) Summary: Speed up gzip.readline (~40%) Initial Comment: See bug 849046 for history. This patch passes both the regression test and the standard test. Hopefully the extra information below won't be too difficult to read. I can attach this info to the bug, if need be. Fixed: - Add self.min_readsize to __init__. Follows the principal that lines are likely to be the same length in size, and doesn't start over at a minimum length string every call to readline() - Rewriting of assignment for readsize and size at the beginning of function. Eliminates almost all calls to min() - Change bufs to a string, and not an array. No point in using an array when all you do with it is "".join(bufs). Uses string addition instead. - Remove extra assignments to bufs (in return()) - Changes readline() to be much more readable (loop reordering, more comments) Recommendations: - Delete _unread() function. It is used _only_ by readline(), and moving its functionality into readline() itself saves the function call overhead. _unread() is only 3 lines long. Testing shows that removing it speeds readline() up by about 3%. Backwards compatibility concerns? Testing results: test_append (__main__.TestGzip) ... ok test_many_append (__main__.TestGzip) ... ok test_mode (__main__.TestGzip) ... ok test_read (__main__.TestGzip) ... ok test_readline (__main__.TestGzip) ... ok test_readlines (__main__.TestGzip) ... ok test_seek_read (__main__.TestGzip) ... ok test_seek_write (__main__.TestGzip) ... ok test_write (__main__.TestGzip) ... ok ---------------------------------------------------------------------- Ran 9 tests in 0.331s Regression tests: python regrtest.py -g test_gzip.py test_gzip 1 test OK. --- Profiling Results (performed on a common compressed log file - 200748 lines). With patch... 1213961 function calls in 12.188 CPU seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 1 0.000 0.000 0.000 0.000 :0(close) 1159 0.020 0.000 0.020 0.000 :0(crc32) 1158 0.100 0.000 0.100 0.000 :0(decompress) 1 0.000 0.000 0.000 0.000 :0(decompressobj) 200774 0.812 0.000 0.812 0.000 :0(find) 403865 0.902 0.000 0.902 0.000 :0(len) 1183 0.000 0.000 0.000 0.000 :0(min) 2 0.000 0.000 0.000 0.000 :0(ord) 1173 0.000 0.000 0.000 0.000 :0(read) 12 0.000 0.000 0.000 0.000 :0(seek) 1 0.000 0.000 0.000 0.000 :0(setprofile) 18 0.000 0.000 0.000 0.000 :0(tell) 2 0.000 0.000 0.000 0.000 :0(unpack) 1 0.000 0.000 12.188 12.188 :1(?) 1 0.000 0.000 0.000 0.000 gzip_new.py:156(_init_read) 1 0.000 0.000 0.000 0.000 gzip_new.py:160(_read_gzip_header) 3 0.000 0.000 0.000 0.000 gzip_new.py:18(U32) 200774 2.453 0.000 2.593 0.000 gzip_new.py:207(read) 200749 2.894 0.000 3.796 0.000 gzip_new.py:239(_unread) 1166 0.010 0.000 0.140 0.000 gzip_new.py:244(_read) 1 0.000 0.000 0.000 0.000 gzip_new.py:27(LOWU32) 1158 0.010 0.000 0.030 0.000 gzip_new.py:294(_add_read_data) 1 0.000 0.000 0.000 0.000 gzip_new.py:300(_read_eof) 1 0.000 0.000 0.000 0.000 gzip_new.py:314(close) 1 0.000 0.000 0.000 0.000 gzip_new.py:327(__del__) 200749 3.916 0.000 11.117 0.000 gzip_new.py:384(readline) 2 0.000 0.000 0.000 0.000 gzip_new.py:39(read32) 1 0.000 0.000 0.000 0.000 gzip_new.py:42(open) 1 0.000 0.000 0.000 0.000 gzip_new.py:60(__init__) 1 0.000 0.000 12.188 12.188 profile:0(gunzip_gzip_new_open()) 0 0.000 0.000 profile:0(profiler) 1 1.071 1.071 12.188 12.188 test_gzip_speed.py:14(gunzip_gzip_new_open) Without patch... 2073328 function calls in 18.597 CPU seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 243820 0.735 0.000 0.735 0.000 :0(append) 1 0.000 0.000 0.000 0.000 :0(close) 1159 0.040 0.000 0.040 0.000 :0(crc32) 1158 0.100 0.000 0.100 0.000 :0(decompress) 1 0.000 0.000 0.000 0.000 :0(decompressobj) 243820 0.960 0.000 0.960 0.000 :0(find) 200749 0.801 0.000 0.801 0.000 :0(join) 489958 1.330 0.000 1.330 0.000 :0(len) 243820 0.791 0.000 0.791 0.000 :0(min) 2 0.000 0.000 0.000 0.000 :0(ord) 1173 0.030 0.000 0.030 0.000 :0(read) 6 0.000 0.000 0.000 0.000 :0(seek) 1 0.000 0.000 0.000 0.000 :0(setprofile) 6 0.000 0.000 0.000 0.000 :0(tell) 2 0.000 0.000 0.000 0.000 :0(unpack) 1 0.000 0.000 18.597 18.597 :1(?) 1 0.000 0.000 0.000 0.000 gzip.py:154(_init_read) 1 0.000 0.000 0.000 0.000 gzip.py:158(_read_gzip_header) 3 0.000 0.000 0.000 0.000 gzip.py:18(U32) 243820 2.711 0.000 2.921 0.000 gzip.py:205(read) 200749 3.083 0.000 4.143 0.000 gzip.py:237(_unread) 1160 0.010 0.000 0.210 0.000 gzip.py:242(_read) 1 0.000 0.000 0.000 0.000 gzip.py:27(LOWU32) 1158 0.030 0.000 0.070 0.000 gzip.py:292(_add_read_data) 1 0.000 0.000 0.000 0.000 gzip.py:298(_read_eof) 1 0.000 0.000 0.000 0.000 gzip.py:312(close) 1 0.000 0.000 0.000 0.000 gzip.py:325(__del__) 200749 6.934 0.000 17.555 0.000 gzip.py:379(readline) 2 0.000 0.000 0.000 0.000 gzip.py:39(read32) 1 0.000 0.000 0.000 0.000 gzip.py:42(open) 1 0.000 0.000 0.000 0.000 gzip.py:59(__init__) 1 0.000 0.000 18.597 18.597 profile:0(gunzip_gzip_open()) 0 0.000 0.000 profile:0(profiler) 1 1.042 1.042 18.597 18.597 test_gzip_speed.py:7(gunzip_gzip_open) Using popen + gunzip -c... 200754 function calls in 4.338 CPU seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 1 0.000 0.000 0.000 0.000 :0(popen) 200749 3.578 0.000 3.578 0.000 :0(readline) 1 0.000 0.000 0.000 0.000 :0(setprofile) 1 0.240 0.240 4.338 4.338 :1(?) 1 0.000 0.000 4.338 4.338 profile:0(gunzip_popen()) 0 0.000 0.000 profile:0(profiler) 1 0.520 0.520 4.098 4.098 test_gzip_speed.py:21(gunzip_popen) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1281707&group_id=5470 From noreply at sourceforge.net Sun Sep 4 19:57:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Sep 2005 10:57:48 -0700 Subject: [Patches] [ python-Patches-1281707 ] Speed up gzip.readline (~40%) Message-ID: Patches item #1281707, was opened at 2005-09-04 12:53 Message generated for change (Comment added) made by marumari You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1281707&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: April King (marumari) Assigned to: Nobody/Anonymous (nobody) Summary: Speed up gzip.readline (~40%) Initial Comment: See bug 849046 for history. This patch passes both the regression test and the standard test. Hopefully the extra information below won't be too difficult to read. I can attach this info to the bug, if need be. Fixed: - Add self.min_readsize to __init__. Follows the principal that lines are likely to be the same length in size, and doesn't start over at a minimum length string every call to readline() - Rewriting of assignment for readsize and size at the beginning of function. Eliminates almost all calls to min() - Change bufs to a string, and not an array. No point in using an array when all you do with it is "".join(bufs). Uses string addition instead. - Remove extra assignments to bufs (in return()) - Changes readline() to be much more readable (loop reordering, more comments) Recommendations: - Delete _unread() function. It is used _only_ by readline(), and moving its functionality into readline() itself saves the function call overhead. _unread() is only 3 lines long. Testing shows that removing it speeds readline() up by about 3%. Backwards compatibility concerns? Testing results: test_append (__main__.TestGzip) ... ok test_many_append (__main__.TestGzip) ... ok test_mode (__main__.TestGzip) ... ok test_read (__main__.TestGzip) ... ok test_readline (__main__.TestGzip) ... ok test_readlines (__main__.TestGzip) ... ok test_seek_read (__main__.TestGzip) ... ok test_seek_write (__main__.TestGzip) ... ok test_write (__main__.TestGzip) ... ok ---------------------------------------------------------------------- Ran 9 tests in 0.331s Regression tests: python regrtest.py -g test_gzip.py test_gzip 1 test OK. --- Profiling Results (performed on a common compressed log file - 200748 lines). With patch... 1213961 function calls in 12.188 CPU seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 1 0.000 0.000 0.000 0.000 :0(close) 1159 0.020 0.000 0.020 0.000 :0(crc32) 1158 0.100 0.000 0.100 0.000 :0(decompress) 1 0.000 0.000 0.000 0.000 :0(decompressobj) 200774 0.812 0.000 0.812 0.000 :0(find) 403865 0.902 0.000 0.902 0.000 :0(len) 1183 0.000 0.000 0.000 0.000 :0(min) 2 0.000 0.000 0.000 0.000 :0(ord) 1173 0.000 0.000 0.000 0.000 :0(read) 12 0.000 0.000 0.000 0.000 :0(seek) 1 0.000 0.000 0.000 0.000 :0(setprofile) 18 0.000 0.000 0.000 0.000 :0(tell) 2 0.000 0.000 0.000 0.000 :0(unpack) 1 0.000 0.000 12.188 12.188 :1(?) 1 0.000 0.000 0.000 0.000 gzip_new.py:156(_init_read) 1 0.000 0.000 0.000 0.000 gzip_new.py:160(_read_gzip_header) 3 0.000 0.000 0.000 0.000 gzip_new.py:18(U32) 200774 2.453 0.000 2.593 0.000 gzip_new.py:207(read) 200749 2.894 0.000 3.796 0.000 gzip_new.py:239(_unread) 1166 0.010 0.000 0.140 0.000 gzip_new.py:244(_read) 1 0.000 0.000 0.000 0.000 gzip_new.py:27(LOWU32) 1158 0.010 0.000 0.030 0.000 gzip_new.py:294(_add_read_data) 1 0.000 0.000 0.000 0.000 gzip_new.py:300(_read_eof) 1 0.000 0.000 0.000 0.000 gzip_new.py:314(close) 1 0.000 0.000 0.000 0.000 gzip_new.py:327(__del__) 200749 3.916 0.000 11.117 0.000 gzip_new.py:384(readline) 2 0.000 0.000 0.000 0.000 gzip_new.py:39(read32) 1 0.000 0.000 0.000 0.000 gzip_new.py:42(open) 1 0.000 0.000 0.000 0.000 gzip_new.py:60(__init__) 1 0.000 0.000 12.188 12.188 profile:0(gunzip_gzip_new_open()) 0 0.000 0.000 profile:0(profiler) 1 1.071 1.071 12.188 12.188 test_gzip_speed.py:14(gunzip_gzip_new_open) Without patch... 2073328 function calls in 18.597 CPU seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 243820 0.735 0.000 0.735 0.000 :0(append) 1 0.000 0.000 0.000 0.000 :0(close) 1159 0.040 0.000 0.040 0.000 :0(crc32) 1158 0.100 0.000 0.100 0.000 :0(decompress) 1 0.000 0.000 0.000 0.000 :0(decompressobj) 243820 0.960 0.000 0.960 0.000 :0(find) 200749 0.801 0.000 0.801 0.000 :0(join) 489958 1.330 0.000 1.330 0.000 :0(len) 243820 0.791 0.000 0.791 0.000 :0(min) 2 0.000 0.000 0.000 0.000 :0(ord) 1173 0.030 0.000 0.030 0.000 :0(read) 6 0.000 0.000 0.000 0.000 :0(seek) 1 0.000 0.000 0.000 0.000 :0(setprofile) 6 0.000 0.000 0.000 0.000 :0(tell) 2 0.000 0.000 0.000 0.000 :0(unpack) 1 0.000 0.000 18.597 18.597 :1(?) 1 0.000 0.000 0.000 0.000 gzip.py:154(_init_read) 1 0.000 0.000 0.000 0.000 gzip.py:158(_read_gzip_header) 3 0.000 0.000 0.000 0.000 gzip.py:18(U32) 243820 2.711 0.000 2.921 0.000 gzip.py:205(read) 200749 3.083 0.000 4.143 0.000 gzip.py:237(_unread) 1160 0.010 0.000 0.210 0.000 gzip.py:242(_read) 1 0.000 0.000 0.000 0.000 gzip.py:27(LOWU32) 1158 0.030 0.000 0.070 0.000 gzip.py:292(_add_read_data) 1 0.000 0.000 0.000 0.000 gzip.py:298(_read_eof) 1 0.000 0.000 0.000 0.000 gzip.py:312(close) 1 0.000 0.000 0.000 0.000 gzip.py:325(__del__) 200749 6.934 0.000 17.555 0.000 gzip.py:379(readline) 2 0.000 0.000 0.000 0.000 gzip.py:39(read32) 1 0.000 0.000 0.000 0.000 gzip.py:42(open) 1 0.000 0.000 0.000 0.000 gzip.py:59(__init__) 1 0.000 0.000 18.597 18.597 profile:0(gunzip_gzip_open()) 0 0.000 0.000 profile:0(profiler) 1 1.042 1.042 18.597 18.597 test_gzip_speed.py:7(gunzip_gzip_open) Using popen + gunzip -c... 200754 function calls in 4.338 CPU seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 1 0.000 0.000 0.000 0.000 :0(popen) 200749 3.578 0.000 3.578 0.000 :0(readline) 1 0.000 0.000 0.000 0.000 :0(setprofile) 1 0.240 0.240 4.338 4.338 :1(?) 1 0.000 0.000 4.338 4.338 profile:0(gunzip_popen()) 0 0.000 0.000 profile:0(profiler) 1 0.520 0.520 4.098 4.098 test_gzip_speed.py:21(gunzip_popen) ---------------------------------------------------------------------- >Comment By: April King (marumari) Date: 2005-09-04 12:57 Message: Logged In: YES user_id=747439 See attached text file for the detailed description (that's much more readable). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1281707&group_id=5470 From noreply at sourceforge.net Mon Sep 5 00:42:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Sep 2005 15:42:54 -0700 Subject: [Patches] [ python-Patches-1090482 ] Patch for bug 999042. Message-ID: Patches item #1090482, was opened at 2004-12-23 18:07 Message generated for change (Settings changed) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1090482&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Darek Suchojad (dsuch) >Assigned to: Neil Schemenauer (nascheme) Summary: Patch for bug 999042. Initial Comment: Hello, I believe this one-line patch fixes [999042] "Compiler module doesn't handle global statement correctly" bug. Without setting the 'optimized' flag compiler.pycodegen.CodeGenerator._nameOp always emits STORE_NAME and not STORE_GLOBAL opcode. After applying test_compiler passes fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1090482&group_id=5470 From noreply at sourceforge.net Mon Sep 5 00:52:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Sep 2005 15:52:16 -0700 Subject: [Patches] [ python-Patches-1251748 ] compiler package: "global a; a=5" Message-ID: Patches item #1251748, was opened at 2005-08-04 10:28 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1251748&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: compiler package: "global a; a=5" Initial Comment: The stdlib compiler package produces wrong code for "global a; a=5". It produces a STORE_NAME instead of a STORE_GLOBAL. Quick patch from Michael attached. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2005-09-04 22:52 Message: Logged In: YES user_id=35752 These fixes should definitely go into 2.5, IMHO. If you need help porting the patch, let me know. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-04 13:09 Message: Logged In: YES user_id=4771 The compiler package contains several bugs along the lines of the one reported here. It doesn't seem to be that much used; with PyPy it is probably the first time that this package is tested in-depth, as we are trying to pass CPython's own test suite by using only this compiler package. We had to make a few involved fixes. Attached is a diff against the 2.4 maintenance head of CPython (we based our changes on 2.4.1). If there is interest, I can extract individual parts of the big diff and/or port them to 2.5 CVS HEAD. For now I will only give a quick overview of the diff. * the more involved problem was related to scoping of variables. This turned out to be more difficult to fix than mwh's patch (included in this tracker). (Disclaimer: Michael never pretended his patch was more than a quick hack.) For reference, see the following code snippets: http://codespeak.net/svn/pypy/dist/pypy/interpreter/test/test_syntax.py * we try to always raise SyntaxErrors with line number information. (Note sure if this has been done completely yet.) * pyassem.py has some heavy changes that I cannot comment on (don't know about them). Other changes there are related to scoping flags. * a number of situations should raise a SyntaxError, but were silently accepted (and generally produce weird bytecodes). * fixed docstring handling. Previously, in interactive mode, entering "hello" produced no result at all -- because the string was interpreted as a docstring! Also, a genuine docstring on the same line as a statement -- "docstring"; x=5 -- would result in the statement being ignored. * we can pass future flags from outside now. * lambda functions didn't get the official name . (Yeah, I know it's a detail, but a CPython test fails because of that.) * added raising of SyntaxWarnings. * the st->ast transformer 'single' mode now returns a Module AST node instead of a Stmt. This matches more closely what the rest of the package expects. * some minor changes in transformer.py are probably not interesting to CPython (e.g. changing some () into []). Their goal was to make transformer.py statically typeable for PyPy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1251748&group_id=5470 From noreply at sourceforge.net Mon Sep 5 14:22:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Sep 2005 05:22:50 -0700 Subject: [Patches] [ python-Patches-1281573 ] String formatting character for str.join Message-ID: Patches item #1281573, was opened at 2005-09-04 21:40 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1281573&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: String formatting character for str.join Initial Comment: Current string formatting doesn't provide an easy way to say "put the contents of this sequence here, using this string as the separator". The only generic way is to use the '%s' formatting character, and then put "sep.join(map(str, seq))" in the appropriate place. This isn't so obvious with lists and tuples, as their default string representations are usually good enough. When trying to add debug statements for iterators, however, the current behaviour is a pain. This patch adds a '%j' (for 'join) formatting character that allows a separator string to be specified between the percent symbol and the format character. For example, "%'\n'j" would indicate that a newline should be used to separate items in the supplied iterable. At this point (initial posting) the patch doesn't support Unicode objects, and doesn't have any tests or documentation - it is solely a proof of concept. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2005-09-05 22:22 Message: Logged In: YES user_id=1038590 'twas a silly idea. I still thinking printing an arbitrary sequence of non-strings is harder than it should be, but this isn't the answer. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-09-04 22:26 Message: Logged In: YES user_id=1038590 2nd version attached which fixed some problems with handling generators by cleaning up the reference counting and not trying to get too fancy when having to convert non-strings. Tested with the following simple test cases: $ ./python -c "print '%j' % range(10)" 0123456789 $ ./python -c "print '%j' % (x for x in range(10))" 0123456789 $ ./python -c "print '%j' % (x*x for x in range(10))" 0149162536496481 $ ./python -c "print '%\ \j' % (x*x for x in range(10))" 0 1 4 9 16 25 36 49 64 81 ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-09-04 21:53 Message: Logged In: YES user_id=1038590 Hmm, looks like this version has a few problems dealing with generators, so avoid it unless you don't mind the odd seg fault. . . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1281573&group_id=5470 From noreply at sourceforge.net Mon Sep 5 18:17:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Sep 2005 09:17:56 -0700 Subject: [Patches] [ python-Patches-1282340 ] Enable SSL for smtplib Message-ID: Patches item #1282340, was opened at 2005-09-05 17:17 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=1282340&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Phil Underwood (furbrain) Assigned to: Nobody/Anonymous (nobody) Summary: Enable SSL for smtplib Initial Comment: smtplib already has limited support for using SSL through the starttls function. However, some SMTP servers require an SSL connection right from the start. This patch allows you to use an SMTP_SSL object to connect (in a similar manner to Imap_SSL or POP3_SSL). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1282340&group_id=5470 From noreply at sourceforge.net Tue Sep 6 00:43:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Sep 2005 15:43:17 -0700 Subject: [Patches] [ python-Patches-1123430 ] Python memory allocator: Free memory Message-ID: Patches item #1123430, was opened at 2005-02-15 16:27 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1123430&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Evan Jones (vulturex) >Assigned to: Tim Peters (tim_one) Summary: Python memory allocator: Free memory Initial Comment: This is the second version of my Python memory allocator patch. The first version was discussed on the python-dev mailing list here: http://mail.python.org/pipermail/python-dev/2005-January/ 051255.html This patch enables Python to actually return memory to the system. The current version's memory usage will only grow. This version maintains the same backwards compatability guarantees as the previous version: Calling PyObject_Free with a pointer that was returned by malloc() while NOT holding the GIL will work, and will not corrupt the state of the memory allocator. The patch modifies obmalloc.c. If it is accepted, other modifications to that file are required. In particular, I have not yet updated the WITH_MEMORY_LIMITS implementation, nor have I looked closely at the PYMALLOC_DEBUG code to see what changes (if any) are required. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-09-05 18:43 Message: Logged In: YES user_id=31435 Assigned to me. ---------------------------------------------------------------------- Comment By: Evan Jones (vulturex) Date: 2005-05-10 00:31 Message: Logged In: YES user_id=539295 Whoops! I uploaded a "fixed" version a while ago, but I guess I didn't update the comments. The patch currently attached to this is the most up- to-date version. Sorry about that. ---------------------------------------------------------------------- Comment By: Evan Jones (vulturex) Date: 2005-02-19 09:07 Message: Logged In: YES user_id=539295 As per the discussion on python-dev, I've removed the concurrency hack. The routines in obmalloc.c now *must* be called while holding the GIL, even if the pointer was allocated with malloc(). I also finally fixed the PYMALLOC_DEBUG routines, so I believe this patch is now "complete." ---------------------------------------------------------------------- Comment By: Evan Jones (vulturex) Date: 2005-02-18 17:08 Message: Logged In: YES user_id=539295 Please ignore this patch for the moment: I'm in the process of making some fixes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1123430&group_id=5470 From noreply at sourceforge.net Tue Sep 6 16:45:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Sep 2005 07:45:34 -0700 Subject: [Patches] [ python-Patches-1000267 ] BSD-style wait4 implementation Message-ID: Patches item #1000267, was opened at 2004-07-29 13:52 Message generated for change (Settings changed) made by cjschr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1000267&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: chads (cjschr) Assigned to: Nobody/Anonymous (nobody) >Summary: BSD-style wait4 implementation Initial Comment: A BSD-style wait4 implementation. Using existing code from the posixmodule.c and resource.c files, I threw together a patch that implements the wait4 function. This function is similar to waitpid, but it also returns usage information about the child process. wait4(pid, options) -> (pid, status, rusage) It works for me on RedHat Linux 9 and FreeBSD 4.5 boxes using Python-2.3.4. The patch may need some fine tuning. Thanks Chad ---------------------------------------------------------------------- Comment By: chads (cjschr) Date: 2005-08-01 17:50 Message: Logged In: YES user_id=1093928 Fix compilation error (gcc-2.95). Has anyone had a chance to look at this for inclusion? ---------------------------------------------------------------------- Comment By: chads (cjschr) Date: 2005-06-01 17:18 Message: Logged In: YES user_id=1093928 Per Martin's suggestions - thanks again. Documentation additions, configure test, import when called, single diff. LMK how this one fairs. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-24 16:15 Message: Logged In: YES user_id=21627 The code looks fine. The only problem I have with it that it seems to assume that any POSIX system implements wait4. However, I don't see it in Single Unix V3, so I think there should be some configure test to determine whether the function is present. Also, it would be nice if the resource module was only imported if wait4 was actually called. I can't see documentation changes; please provide a patch for Doc/lib/libos.tex as well. If you resubmit the patch, it would be easiest if the patch was a single file, eg. generated with "cvs diff -u". There is no need to include configure changes; configure.in would be sufficient. ---------------------------------------------------------------------- Comment By: chads (cjschr) Date: 2005-05-18 15:32 Message: Logged In: YES user_id=1093928 Finally took the time to implement os.wait4 based the comments from loewis. Added a resourcemodule.h header and modified resource.c and posixmodule.c appropriately. Take a gander and let me know what you think. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-22 11:23 Message: Logged In: YES user_id=21627 struct rusage is already defined in Modules/resourcemodule.c. It would be good if there was only a single definition of the type object. To achieve this, resourcemodule.c should expose a C API (e.g. PyObject *PyResource_FromResource(struct rusage*) ). This should be put into a CObject, which should be published through the module; then posixmodule should import resource when wait4 is called for the first time. Alternative, wait4 could be added to resourcemodule.c entirely. Yet another alternative, on top of this approach, posixmodule and/or os.py could provide their own definition of wait4 which delegates to resource.wait4 on first usage. ---------------------------------------------------------------------- Comment By: chads (cjschr) Date: 2004-08-13 14:00 Message: Logged In: YES user_id=1093928 Added a test suite and an example of using wait4. Feedback is welcome. Thanks. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-08-04 16:53 Message: Logged In: YES user_id=2772 You should also add code to the test suite to test wait4 when it is available. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1000267&group_id=5470 From noreply at sourceforge.net Wed Sep 7 22:56:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Sep 2005 13:56:04 -0700 Subject: [Patches] [ python-Patches-1284289 ] AIX port from Elemental Security Message-ID: Patches item #1284289, was opened at 2005-09-07 16: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=1284289&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: AIX port from Elemental Security Initial Comment: Note: don't commit this until the contribution paperwork has been submitted. These are patches to make Python 2.4.1 compile and run (mostly) on AIX 5.3 ML2. (I should know the hardware platform but I'm completely ignorant of that kind of stuff.) The patches were created by Monte Davidoff and paid for by Elemental Security. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1284289&group_id=5470 From noreply at sourceforge.net Wed Sep 7 22:59:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Sep 2005 13:59:04 -0700 Subject: [Patches] [ python-Patches-1284289 ] AIX port from Elemental Security Message-ID: Patches item #1284289, was opened at 2005-09-07 16:56 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1284289&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: AIX port from Elemental Security Initial Comment: Note: don't commit this until the contribution paperwork has been submitted. These are patches to make Python 2.4.1 compile and run (mostly) on AIX 5.3 ML2. (I should know the hardware platform but I'm completely ignorant of that kind of stuff.) The patches were created by Monte Davidoff and paid for by Elemental Security. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-09-07 16:59 Message: Logged In: YES user_id=6380 Here are Monte's notes. Python was configured using: ./configure --with-gcc='xlc_r -q64' --with-cxx='xlC_r -q64' --disable-ipv6 AR='ar -q64' Eventhough xlc_r is not gcc, configure produced better results when --with-gcc was used. IPv6 was disabled, because configure reported that getaddrinfo() was buggy, and, at this time, Elemental Security does not require IPv6. Note: the test suite still fails on: test_codecencodings_cn, test_codecmaps_cn, test_curses, test_mmap, and test_multibytecodec, as Elemental Security did not require these features. All other tests in the test suite that were not skipped passed. These source changes were required: Modules/makexp_aix This script uses nm to create an export list of global symbols for the AIX dynamic linker. Changed the script to include the nm -X32_64 option, which allows it to process both 32-bit and 64-bit object files. For backward compatibility, this option is added only if the nm command implements the option. Include/import.h Python/import.c Modules/signalmodule.c These files were modified to reallocate the import lock in the child process after a fork. This prevents the child process from receiving EACCES when performing operations on the import lock. Include/import.h -- added prototype for _PyImport_ReInitLock. Python/import.c -- added _PyImport_ReInitLock. This function was modeled after PyEval_ReInitThreads, which serves a similar purpose. The _PyImport_ReInitLock function reallocates the import_lock, if the import_lock has already been allocated. The code within _PyImport_ReInitLock is under #ifdef _AIX. Modules/signalmodule.c -- added call to _PyImport_ReInitLock in PyOS_AfterFork. Modules/socketmodule.c Modules/socketmodule.h These files were modified to fix a memory corruption problem involving AF_UNIX sockets. AIX's struct sockaddr_un structure contains a path name which is the address of a UNIX socket. Unlike several other flavors of UNIX-like systems, the AIX declaration for struct sockaddr_un actually allocates enough space for any path name (PATH_MAX). This means a struct sockaddr_un takes up 1025 bytes. However, several places in socketmodule.c allocated only 256 bytes for a socket address. The first thing they do with the 256-byte socket address buffer is zero 1025 bytes. Not good! Modules/socketmodule.h -- the PySocketSockObject typedef already defined a union sock_addr that allocates enough space for any socket address. Moved the union outside the PySocketSockObject struct into its own typedef, sock_addr_t. Modules/socketmodule.c -- replaced the "char addrbuf[256]" definitions with "sock_addr_t addrbuf" and made other changes required by that. Modules/grpmodule.c Modules/pwdmodule.c UIDs and GIDs are unsigned. Changed pwd_getpwuid and grp_getgrgid to accept unsigned UIDs and GIDs. On AIX, the passwd and group files use the largest unsigned int for nobody. Lib/test/test_ioctl.py -- Fixed bug in import statement for test.test_support. Fixed bug where the test would fail if the test suite was being run in the backgroud. In this case, the TIOCGPGRP ioctl on /dev/tty returns the session ID, not the process group ID. Lib/test/regrtest.py -- added skips for aix5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1284289&group_id=5470 From noreply at sourceforge.net Wed Sep 7 23:15:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Sep 2005 14:15:30 -0700 Subject: [Patches] [ python-Patches-1284289 ] AIX port from Elemental Security Message-ID: Patches item #1284289, was opened at 2005-09-07 13:56 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1284289&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: AIX port from Elemental Security Initial Comment: Note: don't commit this until the contribution paperwork has been submitted. These are patches to make Python 2.4.1 compile and run (mostly) on AIX 5.3 ML2. (I should know the hardware platform but I'm completely ignorant of that kind of stuff.) The patches were created by Monte Davidoff and paid for by Elemental Security. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-07 14:15 Message: Logged In: YES user_id=33168 There is another patch to correct pwdmodule.c and grpmodule.c using unsigned values. I haven't looked at either patch (that one or this one) in detail just the comments. https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066546&group_id=5470 105470 has 2 one line changes to convert i -> I. This is from the comments. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-09-07 13:59 Message: Logged In: YES user_id=6380 Here are Monte's notes. Python was configured using: ./configure --with-gcc='xlc_r -q64' --with-cxx='xlC_r -q64' --disable-ipv6 AR='ar -q64' Eventhough xlc_r is not gcc, configure produced better results when --with-gcc was used. IPv6 was disabled, because configure reported that getaddrinfo() was buggy, and, at this time, Elemental Security does not require IPv6. Note: the test suite still fails on: test_codecencodings_cn, test_codecmaps_cn, test_curses, test_mmap, and test_multibytecodec, as Elemental Security did not require these features. All other tests in the test suite that were not skipped passed. These source changes were required: Modules/makexp_aix This script uses nm to create an export list of global symbols for the AIX dynamic linker. Changed the script to include the nm -X32_64 option, which allows it to process both 32-bit and 64-bit object files. For backward compatibility, this option is added only if the nm command implements the option. Include/import.h Python/import.c Modules/signalmodule.c These files were modified to reallocate the import lock in the child process after a fork. This prevents the child process from receiving EACCES when performing operations on the import lock. Include/import.h -- added prototype for _PyImport_ReInitLock. Python/import.c -- added _PyImport_ReInitLock. This function was modeled after PyEval_ReInitThreads, which serves a similar purpose. The _PyImport_ReInitLock function reallocates the import_lock, if the import_lock has already been allocated. The code within _PyImport_ReInitLock is under #ifdef _AIX. Modules/signalmodule.c -- added call to _PyImport_ReInitLock in PyOS_AfterFork. Modules/socketmodule.c Modules/socketmodule.h These files were modified to fix a memory corruption problem involving AF_UNIX sockets. AIX's struct sockaddr_un structure contains a path name which is the address of a UNIX socket. Unlike several other flavors of UNIX-like systems, the AIX declaration for struct sockaddr_un actually allocates enough space for any path name (PATH_MAX). This means a struct sockaddr_un takes up 1025 bytes. However, several places in socketmodule.c allocated only 256 bytes for a socket address. The first thing they do with the 256-byte socket address buffer is zero 1025 bytes. Not good! Modules/socketmodule.h -- the PySocketSockObject typedef already defined a union sock_addr that allocates enough space for any socket address. Moved the union outside the PySocketSockObject struct into its own typedef, sock_addr_t. Modules/socketmodule.c -- replaced the "char addrbuf[256]" definitions with "sock_addr_t addrbuf" and made other changes required by that. Modules/grpmodule.c Modules/pwdmodule.c UIDs and GIDs are unsigned. Changed pwd_getpwuid and grp_getgrgid to accept unsigned UIDs and GIDs. On AIX, the passwd and group files use the largest unsigned int for nobody. Lib/test/test_ioctl.py -- Fixed bug in import statement for test.test_support. Fixed bug where the test would fail if the test suite was being run in the backgroud. In this case, the TIOCGPGRP ioctl on /dev/tty returns the session ID, not the process group ID. Lib/test/regrtest.py -- added skips for aix5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1284289&group_id=5470 From noreply at sourceforge.net Thu Sep 8 11:28:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Sep 2005 02:28:31 -0700 Subject: [Patches] [ python-Patches-1284670 ] Allow to restrict ModuleFinder to get "direct" dependencies Message-ID: Patches item #1284670, was opened at 2005-09-08 11:28 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=1284670&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Scherer Michael (misc_from_metz) Assigned to: Nobody/Anonymous (nobody) Summary: Allow to restrict ModuleFinder to get "direct" dependencies Initial Comment: this patch add a parameter to ModuleFinder, to not recurse when searching module. This way, someone can compute the modules needed by a specific file, without having to compute all other imported module, which may take time for result that are no t needed. With the current system, you cannot create a clean graph of modules dependancy, since they are all on the same level. This patch do not change the default behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1284670&group_id=5470 From noreply at sourceforge.net Thu Sep 8 17:25:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Sep 2005 08:25:21 -0700 Subject: [Patches] [ python-Patches-1212837 ] Improved profiler Message-ID: Patches item #1212837, was opened at 2005-06-01 12:05 Message generated for change (Comment added) made by bdrosen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212837&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Brett Rosen (bdrosen) Assigned to: Nobody/Anonymous (nobody) Summary: Improved profiler Initial Comment: I tried using both hotshot and the old python profiler and found them both to be inadequate. The old python profiler seems to give accurate results for timing, but is slow enough that it adds significant overhead to what it is measuing (approximately 10 times). Furthermore, it has no ability to give detailed stats about children. (how much of the cumulative time was taken up by each function called by a function) The hotshot profiler is much faster (profiling) adding only 30% overhead. However, it is extremely slow to load the results from the log file. It does not currently support detailed child stats, although I imagine that it could be made to do so using the information in the log file. The biggest problem with it, is that the time results seem to be highly inaccurate. (doesn't correspond to actual seconds, although they seem to be proportionally wrong) To address these shortcomings, I wrote a new profiling module. It adds about the same overhead (30%) as hotshot, but is much faster in retrieving results. It supports detailed child stats and gives accurate timing information in milliseconds. The accompanying .py module could use additional work though - because of the child stats, I was not able to reuse the stats module like hotshot does. I've included a simple test script that runs pystone for all 3 profilers (and without the profiler) to give a better idea of the differences. I've also included a dump of the output of the script running under Windows XP with python 2.4.1 ---------------------------------------------------------------------- >Comment By: Brett Rosen (bdrosen) Date: 2005-09-08 11:25 Message: Logged In: YES user_id=1289249 I've enclosed an updated version of profile.c that fixes a problem in the original patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212837&group_id=5470 From noreply at sourceforge.net Thu Sep 8 21:27:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Sep 2005 12:27:01 -0700 Subject: [Patches] [ python-Patches-1281573 ] String formatting character for str.join Message-ID: Patches item #1281573, was opened at 2005-09-04 07:40 Message generated for change (Settings changed) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1281573&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Closed >Resolution: Postponed Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: String formatting character for str.join Initial Comment: Current string formatting doesn't provide an easy way to say "put the contents of this sequence here, using this string as the separator". The only generic way is to use the '%s' formatting character, and then put "sep.join(map(str, seq))" in the appropriate place. This isn't so obvious with lists and tuples, as their default string representations are usually good enough. When trying to add debug statements for iterators, however, the current behaviour is a pain. This patch adds a '%j' (for 'join) formatting character that allows a separator string to be specified between the percent symbol and the format character. For example, "%'\n'j" would indicate that a newline should be used to separate items in the supplied iterable. At this point (initial posting) the patch doesn't support Unicode objects, and doesn't have any tests or documentation - it is solely a proof of concept. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-09-05 08:22 Message: Logged In: YES user_id=1038590 'twas a silly idea. I still thinking printing an arbitrary sequence of non-strings is harder than it should be, but this isn't the answer. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-09-04 08:26 Message: Logged In: YES user_id=1038590 2nd version attached which fixed some problems with handling generators by cleaning up the reference counting and not trying to get too fancy when having to convert non-strings. Tested with the following simple test cases: $ ./python -c "print '%j' % range(10)" 0123456789 $ ./python -c "print '%j' % (x for x in range(10))" 0123456789 $ ./python -c "print '%j' % (x*x for x in range(10))" 0149162536496481 $ ./python -c "print '%\ \j' % (x*x for x in range(10))" 0 1 4 9 16 25 36 49 64 81 ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-09-04 07:53 Message: Logged In: YES user_id=1038590 Hmm, looks like this version has a few problems dealing with generators, so avoid it unless you don't mind the odd seg fault. . . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1281573&group_id=5470 From starrman37 at comcast.net Fri Sep 9 11:32:06 2005 From: starrman37 at comcast.net (Thom Starr) Date: Fri, 9 Sep 2005 02:32:06 -0700 Subject: [Patches] Cheap Xanax Online - USA Pharmacy ELBE 0 Message-ID: <000801c5b521$58d799c0$50e38218@hsd1.ca.comcast.net> how do i get my medicine ! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20050909/e8a66d4c/attachment.html From noreply at sourceforge.net Mon Sep 12 00:05:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Sep 2005 15:05:19 -0700 Subject: [Patches] [ python-Patches-1288056 ] pygettext - provide comments to help translators Message-ID: Patches item #1288056, was opened at 2005-09-11 23:05 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=1288056&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Toby Dickenson (htrd) Assigned to: Nobody/Anonymous (nobody) Summary: pygettext - provide comments to help translators Initial Comment: The .po file format supports "automatic comments". These are comments which have been automatically generated or extracted from the original source along with the "msgid" reference strings. Automatic comments are a good way to communicate extra information to the translator. For example message context, or information about string substitutions. The Gnu gettext tools have good support for "automatic comments". For example msgmerge (which merges updates from a programmer into the master po file maintained by a translator) will preserve the programmer's copy of the "automatic comments" but the translator's copy of the other comments. This patch includes an option to pygettext which automatically copies comments from Python source code into its output .po file. The comment must appear on the same line as the extracted string, and the first character of the comment (immediately after the #) must be a period. Example usage: msg = _('Opening file....') #. status bar message msg = _("Connected on %1") #. eg. connected on com1 Rationale: Why not use any python source code comment on the same line, rather than require the #. prefix? My first variant of this patch worked that way. I found this inadvertently included too many programmer-oriented comments that were inappropriate for the translator. Why the #. notation? This is the same format as used in .po files. Thats not a big advantage, because nobody spends much time reading raw po files. It is concise, which is an advantage since the comment needs to be on the same line as the extracted string. Why should the python source code notation use python comments, rather than an extra parameter to the _ function? Partly tradition.... Gnu gettext for C also looks in specially marked comments. It is also nice to not require changes to other translateable string extraction tools (if there are any) or existing translation functions which currently do not expect an extra parameter. Why a new command line option? Hmmmm - no good reason..... maybe this functionality should always be enabled. Why require the comment to be on the same line? Gnu gettext for C searches the same line *and* the preceeding line. I have experience converting a large python project of approx 800 extracted strings where this hasnt been a problem. Im happy to extend this if necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1288056&group_id=5470 From noreply at sourceforge.net Mon Sep 12 11:09:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Sep 2005 02:09:24 -0700 Subject: [Patches] [ python-Patches-1251748 ] compiler package: "global a; a=5" Message-ID: Patches item #1251748, was opened at 2005-08-04 10:28 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1251748&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: compiler package: "global a; a=5" Initial Comment: The stdlib compiler package produces wrong code for "global a; a=5". It produces a STORE_NAME instead of a STORE_GLOBAL. Quick patch from Michael attached. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-09-12 09:09 Message: Logged In: YES user_id=4771 The patch appears to apply as it is on the CVS HEAD, with at most offsets of 10 lines, and test_compiler.py passes afterwards. I suppose that someone (else than me) needs to give the patch a quick review anyway, so feel free to consider it as a 2.4 + 2.5 patch. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-09-04 22:52 Message: Logged In: YES user_id=35752 These fixes should definitely go into 2.5, IMHO. If you need help porting the patch, let me know. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-04 13:09 Message: Logged In: YES user_id=4771 The compiler package contains several bugs along the lines of the one reported here. It doesn't seem to be that much used; with PyPy it is probably the first time that this package is tested in-depth, as we are trying to pass CPython's own test suite by using only this compiler package. We had to make a few involved fixes. Attached is a diff against the 2.4 maintenance head of CPython (we based our changes on 2.4.1). If there is interest, I can extract individual parts of the big diff and/or port them to 2.5 CVS HEAD. For now I will only give a quick overview of the diff. * the more involved problem was related to scoping of variables. This turned out to be more difficult to fix than mwh's patch (included in this tracker). (Disclaimer: Michael never pretended his patch was more than a quick hack.) For reference, see the following code snippets: http://codespeak.net/svn/pypy/dist/pypy/interpreter/test/test_syntax.py * we try to always raise SyntaxErrors with line number information. (Note sure if this has been done completely yet.) * pyassem.py has some heavy changes that I cannot comment on (don't know about them). Other changes there are related to scoping flags. * a number of situations should raise a SyntaxError, but were silently accepted (and generally produce weird bytecodes). * fixed docstring handling. Previously, in interactive mode, entering "hello" produced no result at all -- because the string was interpreted as a docstring! Also, a genuine docstring on the same line as a statement -- "docstring"; x=5 -- would result in the statement being ignored. * we can pass future flags from outside now. * lambda functions didn't get the official name . (Yeah, I know it's a detail, but a CPython test fails because of that.) * added raising of SyntaxWarnings. * the st->ast transformer 'single' mode now returns a Module AST node instead of a Stmt. This matches more closely what the rest of the package expects. * some minor changes in transformer.py are probably not interesting to CPython (e.g. changing some () into []). Their goal was to make transformer.py statically typeable for PyPy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1251748&group_id=5470 From noreply at sourceforge.net Mon Sep 12 17:35:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Sep 2005 08:35:05 -0700 Subject: [Patches] [ python-Patches-1288833 ] FreeBSD 5.3 and upward has thread-safe getaddrinfo(3) Message-ID: Patches item #1288833, was opened at 2005-09-12 15: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=1288833&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Maxim Sobolev (sobomax) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD 5.3 and upward has thread-safe getaddrinfo(3) Initial Comment: The FreeBSD operating system has thread-safe getaddrinfo(3) since version 5.3. Therefore, serialization in the socket module is not necessary when Python is compiled for this system. -Maxim ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1288833&group_id=5470 From noreply at sourceforge.net Tue Sep 13 01:39:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Sep 2005 16:39:29 -0700 Subject: [Patches] [ python-Patches-1288833 ] FreeBSD 5.3 and upward has thread-safe getaddrinfo(3) Message-ID: Patches item #1288833, was opened at 2005-09-13 00:35 Message generated for change (Settings changed) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1288833&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Maxim Sobolev (sobomax) >Assigned to: Hye-Shik Chang (perky) Summary: FreeBSD 5.3 and upward has thread-safe getaddrinfo(3) Initial Comment: The FreeBSD operating system has thread-safe getaddrinfo(3) since version 5.3. Therefore, serialization in the socket module is not necessary when Python is compiled for this system. -Maxim ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1288833&group_id=5470 From noreply at sourceforge.net Tue Sep 13 22:57:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Sep 2005 13:57:33 -0700 Subject: [Patches] [ python-Patches-1290454 ] Fix reload() error message Message-ID: Patches item #1290454, was opened at 2005-09-13 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=1290454&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Fix reload() error message Initial Comment: As of CVS revision 2.242, PyImport_ReloadModule gives the wrong error message when the parent module no longer exists in sys.modules. Below is a sample session: Python 2.4.1 (#1, Aug 11 2005, 08:51:39) [GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import distutils.command.sdist >>> import sys >>> del sys.modules['distutils.command'] >>> del sys.modules['distutils'] >>> reload(distutils.command.sdist) Traceback (most recent call last): File "", line 1, in ? ImportError: reload(): parent distutils.command.sdist not in sys.modules >>> The ImportError message should read "reload(): parent distutils.command not in sys.modules". The attached patch (against import.c, r2.242) fixes this behaviour. The patch has been tested with the regression suite shipped with Python 2.4.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1290454&group_id=5470 From noreply at sourceforge.net Wed Sep 14 09:01:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 00:01:49 -0700 Subject: [Patches] [ python-Patches-1290454 ] Fix reload() error message Message-ID: Patches item #1290454, was opened at 2005-09-13 22:57 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1290454&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Collin Winter (collinwinter) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Fix reload() error message Initial Comment: As of CVS revision 2.242, PyImport_ReloadModule gives the wrong error message when the parent module no longer exists in sys.modules. Below is a sample session: Python 2.4.1 (#1, Aug 11 2005, 08:51:39) [GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import distutils.command.sdist >>> import sys >>> del sys.modules['distutils.command'] >>> del sys.modules['distutils'] >>> reload(distutils.command.sdist) Traceback (most recent call last): File "", line 1, in ? ImportError: reload(): parent distutils.command.sdist not in sys.modules >>> The ImportError message should read "reload(): parent distutils.command not in sys.modules". The attached patch (against import.c, r2.242) fixes this behaviour. The patch has been tested with the regression suite shipped with Python 2.4.1. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-14 09:01 Message: Logged In: YES user_id=1188172 Thanks for the fix! However, please produce a context diff in the future, it makes it much easier to grasp, ehm, the context of the changes, so that one does not have to apply the patch before reviewing it. Committed as import.c r2.243, r2.240.2.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1290454&group_id=5470 From noreply at sourceforge.net Wed Sep 14 19:27:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 10:27:32 -0700 Subject: [Patches] [ python-Patches-1291169 ] mmap with unsigned int offset and cross build for ppc Message-ID: Patches item #1291169, was opened at 2005-09-14 17: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=1291169&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Jos? Pedro Pereira Valente de M (jose-v-matos) Assigned to: Nobody/Anonymous (nobody) Summary: mmap with unsigned int offset and cross build for ppc Initial Comment: # Based on "K's cluttered loft - ARM cross-compiling howto" http://www.ailis.de/~k/docs/crosscompiling/python.php and mmap patch from Yotam Medini yotamm at mellanox.co.il. I've created a script in attach that does the cross_compile. Also in the script is the diff from "cvs diff -u " I changed the mmapmodule.c to use unsigned int, and therefor not report OverflowError. I would like to use python to do automatic tests on chips in boards that are usually mapped on high address values like 0xFFF00000. Right now I can do that. Needs patch to the tests and documentation, I think. Hope this helps someone. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1291169&group_id=5470 From noreply at sourceforge.net Wed Sep 14 19:57:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 10:57:25 -0700 Subject: [Patches] [ python-Patches-1225212 ] HP-UX ia64 64-bit Python executable Message-ID: Patches item #1225212, was opened at 2005-06-21 19:34 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1225212&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Peter Kropf (peterk) Assigned to: Guido van Rossum (gvanrossum) Summary: HP-UX ia64 64-bit Python executable Initial Comment: In working on getting a 64-bit Python to build and pass the test suites on a Itanium 2 system running HP-UX 11, there were two major issues that needed to be resolved: - on ia64 HP-UX, unistd.h does not define _POSIX_THREADS and therefore Python/thread.c was not including thread_pthreads.h even though enough of the posix threading API is available to support threads in Python. - isnan() was not being called to check floating point numbers and math.sqrt(-1) would not throw a ValueError. The attached patch make the following changes: - modifies Python/thread.c to check for __hpux and _SC_THREADS and if they're defined, then define _POSIX_THREADS. - modifies Include/pyport.h to check for __hpux and __ia64 in the macro that defines _Py_SET_EDOM_FOR_NAN. - modifies Readme to include details on how to build a 64-bit version of Python on a HP-UX based Itanium 2 system. The patch file was created by running: cvs diff -c | tee ~/hpux_ia64_port.patch from python/dist/src on a current CVS tree. The current Readme also states that there is optimization problems when building Python on an ia64 based HP-UX system using HP's C compiler. I have not found this to be a problem. Should this note be removed or marked as out of date? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-09-14 13:57 Message: Logged In: YES user_id=6380 Checked into HEAD and 2.4 branch, in time for 2.4.2. We didn't get to the automatic detection feature that Martin requested; sorry. We (Elemental Security) have mailed a contributor agreement to the PSF. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-07-20 13:49 Message: Logged In: YES user_id=6380 I will work to check this in. I have to get the contribution agreement reviewed by ESI management first. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-06-24 18:21 Message: Logged In: YES user_id=21627 The patch looks good, but I have one comment: it would be better if the user would not have to specify flags explicitly. Python should build out of the box on the platform, with not having to set environment variables. Ideally, it should built forall of the most likely configurations, i.e. c89/aCC and gcc, both 64 bits (I guess nobody would want to build an ia32 binary even if this is possible). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1225212&group_id=5470 From noreply at sourceforge.net Wed Sep 14 20:16:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 11:16:05 -0700 Subject: [Patches] [ python-Patches-1284289 ] AIX port from Elemental Security Message-ID: Patches item #1284289, was opened at 2005-09-07 16:56 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1284289&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: AIX port from Elemental Security Initial Comment: Note: don't commit this until the contribution paperwork has been submitted. These are patches to make Python 2.4.1 compile and run (mostly) on AIX 5.3 ML2. (I should know the hardware platform but I'm completely ignorant of that kind of stuff.) The patches were created by Monte Davidoff and paid for by Elemental Security. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-09-14 14:16 Message: Logged In: YES user_id=6380 Checked in for 2.4.2 and HEAD. Elemental Security has mailed a signed contributor form to the PSF. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-07 17:15 Message: Logged In: YES user_id=33168 There is another patch to correct pwdmodule.c and grpmodule.c using unsigned values. I haven't looked at either patch (that one or this one) in detail just the comments. https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066546&group_id=5470 105470 has 2 one line changes to convert i -> I. This is from the comments. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-09-07 16:59 Message: Logged In: YES user_id=6380 Here are Monte's notes. Python was configured using: ./configure --with-gcc='xlc_r -q64' --with-cxx='xlC_r -q64' --disable-ipv6 AR='ar -q64' Eventhough xlc_r is not gcc, configure produced better results when --with-gcc was used. IPv6 was disabled, because configure reported that getaddrinfo() was buggy, and, at this time, Elemental Security does not require IPv6. Note: the test suite still fails on: test_codecencodings_cn, test_codecmaps_cn, test_curses, test_mmap, and test_multibytecodec, as Elemental Security did not require these features. All other tests in the test suite that were not skipped passed. These source changes were required: Modules/makexp_aix This script uses nm to create an export list of global symbols for the AIX dynamic linker. Changed the script to include the nm -X32_64 option, which allows it to process both 32-bit and 64-bit object files. For backward compatibility, this option is added only if the nm command implements the option. Include/import.h Python/import.c Modules/signalmodule.c These files were modified to reallocate the import lock in the child process after a fork. This prevents the child process from receiving EACCES when performing operations on the import lock. Include/import.h -- added prototype for _PyImport_ReInitLock. Python/import.c -- added _PyImport_ReInitLock. This function was modeled after PyEval_ReInitThreads, which serves a similar purpose. The _PyImport_ReInitLock function reallocates the import_lock, if the import_lock has already been allocated. The code within _PyImport_ReInitLock is under #ifdef _AIX. Modules/signalmodule.c -- added call to _PyImport_ReInitLock in PyOS_AfterFork. Modules/socketmodule.c Modules/socketmodule.h These files were modified to fix a memory corruption problem involving AF_UNIX sockets. AIX's struct sockaddr_un structure contains a path name which is the address of a UNIX socket. Unlike several other flavors of UNIX-like systems, the AIX declaration for struct sockaddr_un actually allocates enough space for any path name (PATH_MAX). This means a struct sockaddr_un takes up 1025 bytes. However, several places in socketmodule.c allocated only 256 bytes for a socket address. The first thing they do with the 256-byte socket address buffer is zero 1025 bytes. Not good! Modules/socketmodule.h -- the PySocketSockObject typedef already defined a union sock_addr that allocates enough space for any socket address. Moved the union outside the PySocketSockObject struct into its own typedef, sock_addr_t. Modules/socketmodule.c -- replaced the "char addrbuf[256]" definitions with "sock_addr_t addrbuf" and made other changes required by that. Modules/grpmodule.c Modules/pwdmodule.c UIDs and GIDs are unsigned. Changed pwd_getpwuid and grp_getgrgid to accept unsigned UIDs and GIDs. On AIX, the passwd and group files use the largest unsigned int for nobody. Lib/test/test_ioctl.py -- Fixed bug in import statement for test.test_support. Fixed bug where the test would fail if the test suite was being run in the backgroud. In this case, the TIOCGPGRP ioctl on /dev/tty returns the session ID, not the process group ID. Lib/test/regrtest.py -- added skips for aix5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1284289&group_id=5470 From noreply at sourceforge.net Wed Sep 14 21:32:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 12:32:06 -0700 Subject: [Patches] [ python-Patches-1212928 ] new patch for fixing skipitem() in getargs.c Message-ID: Patches item #1212928, was opened at 2005-06-01 20:21 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212928&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Reinhold Birkenfeld (birkenfeld) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: new patch for fixing skipitem() in getargs.c Initial Comment: This patch subsumes #985713 and #853890. In Python/getargs.c, the function skipitem() has not been updated with new argument format codes, such as u, u#, w, w# etc. This is corrected with this patch. There are two possibilities: either all new codes are added to the switch statement (this is the file getargs-skipitem-diff), or the function is rewritten so that there is no need for a switch (because the pointer type for va_arg is irrelevant). That solution is in the file new_skipitem.c. Remaining issue: I don't know if the '(...)' formatting code should be handled here. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-14 21:32 Message: Logged In: YES user_id=1188172 I used a hybrid solution now. The checking for invalid characters remains, but the type argument is irrelevant. Python/getargs.c r2.107 and r2.102.2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212928&group_id=5470 From noreply at sourceforge.net Wed Sep 14 23:07:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 14:07:43 -0700 Subject: [Patches] [ python-Patches-1276356 ] Adding new regrtest resource 'urlfetch' Message-ID: Patches item #1276356, was opened at 2005-08-30 09:05 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1276356&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Adding new regrtest resource 'urlfetch' Initial Comment: This is a fix for SF #1010952. test_normalization and test_codecmaps_* require too much effort to fetch the each test files. When this fix got applied, passing '-uurlfetch' to regrtest will enables on-demand downloads for the tests. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-14 23:07 Message: Logged In: YES user_id=1188172 Applied the patch, works like a charm. I wonder though if you should give the user some feedback when he is downloading a file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1276356&group_id=5470 From noreply at sourceforge.net Thu Sep 15 09:20:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 00:20:33 -0700 Subject: [Patches] [ python-Patches-1244861 ] Enable os.startfile and webbrowser.WindowsDefault on Cygwin Message-ID: Patches item #1244861, was opened at 2005-07-26 01:38 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1244861&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: Enable os.startfile and webbrowser.WindowsDefault on Cygwin Initial Comment: This patch enables os.startfile() on Cygwin, converting Cygwin POSIX paths to Windows paths unless they look like URLs, and calling ShellExecute() on the result. It also enables the webbrowser.WindowsDefault class, which uses os.startfile(). It has to make WindowsError and the PyErr*Windows* functions available as well because win32_startfile() might call them. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 09:20 Message: Logged In: YES user_id=1188172 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1244861&group_id=5470 From noreply at sourceforge.net Thu Sep 15 09:54:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 00:54:55 -0700 Subject: [Patches] [ python-Patches-1077979 ] Simple webbrowser fix for netscape -remote Message-ID: Patches item #1077979, was opened at 2004-12-02 23:41 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1077979&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Josh Cherry (jlcherry) Assigned to: Nobody/Anonymous (nobody) Summary: Simple webbrowser fix for netscape -remote Initial Comment: This patch simply removes a space in a netscape -remote command that is executed by webbrowser. This space caused problems with certain urls, at least with netscape 7.2. For example, webbrowser.open_new('http://www.python.org') would file, though webbrowser.open_new('http://www.python.org/') would work. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 09:54 Message: Logged In: YES user_id=1188172 Fixed in webbrowser.py r1.37.4.1. Included in big webbrowser patch for 2.5. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-20 02:21 Message: Logged In: YES user_id=9057 1144816 and 1077979 are the the same patch, as documented in a comment for 1144816 by Oleg Broytmann. The wrong behaviour was reported to Mozilla (unspecified version), Netscape 7.2 and Mozilla-firefox (unspecified version). I could not reproduce the problem neither with Mozilla 1.7.2 nor with Firefox 1.0.1. Nevertheless, applying the patch does not break current functionality and might fix bugs in older browsers. I recommend applying 1077979, and closing 1144816. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-12-07 12:26 Message: Logged In: YES user_id=4799 Yes, I can confirm the problem with Mozilla. I updated my big patch for webbrowser.py at http://python.org/sf/754022. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1077979&group_id=5470 From noreply at sourceforge.net Thu Sep 15 09:58:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 00:58:41 -0700 Subject: [Patches] [ python-Patches-954628 ] Replacement for webbrowser.py which has problems. Message-ID: Patches item #954628, was opened at 2004-05-16 00:02 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=954628&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Michel Van den Bergh (vdbergh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Replacement for webbrowser.py which has problems. Initial Comment: I have been checking out webbrowser.py. Unfortunately this module has some obvious problems (tested on CVS version under Linux with mozilla) (*) If you open an url (with the option "new window") and the browser is not already running then it opens *two* windows: the home page and your url. This is different for example from the default behaviour on Windows and also quite ugly. (**) There is another related problem: if you open a url and the browser is not already running then the code starts a new browser, sleeps 4 seconds and then issues a "-remote" command. Using a timed sleep is very bad programming and *extremely fragile*. Indeed I had failures because the delay (PROCESS_CREATION_DELAY) was not long enough. At the very least the -remote command should be tried a couple of times. BUT: there is no reason *at all* to issue a -remote command in this case. All browsers I know accept a url as argument. So one can just start a new browser with the url as argument. There are two pending patches for webbrowser.py but they don't address the above problems. Therefore I made a new version of webbrowser.py (from the latest CVS) that addresses them. Along the way I made a few other non-intrusive changes. They are listed below. Added PYTHONBROWSER environment variable since Mandrake 10.0 already sets BROWSER. Added opera, epiphany,firefox,firebird. Firebird and firefox and the rewritten code for Galeon are not tested Changed default on windows to be "startfile" (instead of Netscape). Changed _tryorder on X into something more reasonable for these days. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 09:58 Message: Logged In: YES user_id=1188172 Subsumed by #754022. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-20 02:26 Message: Logged In: YES user_id=9057 There is no patch attached, but the whole file was uploaded. Twice! There is already a comment by Oleg Broytmann telling the person to re-submit it in as a proper patch. There are multiple changes in it, perhaps multiples patches. Each addresing a single change. Some of the proposed changes are declared untested. Some changes might be controversial, like using a new environment variable PYTHONBROWSER prior to checking BROWSER. There are no references to this being discussed in python-dev. I recommend closing 954628. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-19 21:48 Message: Logged In: YES user_id=4799 IWBN to have exactly one patch (I do not understand which one of those two is THE patch) in "context diff" format. Please delete the attachments and resubmit the patch. The idea of running "-remote" and then starting the program if it hadn't been started is fine! Why to add "-iconic" for Netscape if not autoraise? "Not autoraise" means "do not change z-order of the window" but that does not neccessary implies "leave the window iconic" even less "make the window iconic". When you run a new program "not autoraise" should be ignore, as far as I understand. ---------------------------------------------------------------------- Comment By: Martin Franklin (mfranklin1) Date: 2004-11-11 11:05 Message: Logged In: YES user_id=482545 Great work... couple of points I just tested on my fedora c2 box (with firefox & opera installed...) The try order did not include firefox. Also I believe (at least on my system) opera can be treated just like the netscape browsers, it supports the same command line flags. As to the tryorder *I* would personally have firefox up front because if you have it installed the chances are you want to use it instead of mozzilla (same goes for opera) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=954628&group_id=5470 From noreply at sourceforge.net Thu Sep 15 10:04:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 01:04:06 -0700 Subject: [Patches] [ python-Patches-728278 ] Multiple webbrowser.py bug fixes / improvements Message-ID: Patches item #728278, was opened at 2003-04-27 06:02 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=728278&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Stephan R.A. Deibel (sdeibel) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Multiple webbrowser.py bug fixes / improvements Initial Comment: In using webbrowser.py we uncovered and fixed a number of problems and made some improvements in usability and consistency of behavior. Appended below is a summary of the changes made. This list is also found at the top of the uploaded file, which was based on the version of webbrowser.py found in Python 2.3a2. Sorry to submit so many changes at once but they were all made in a period of a few days when we went through this module for use in Wing IDE. I'm also submitting some unit tests for the module. I've tried to review everything carefully, further review is definately needed. Feel free to contact me if you have questions or comments or want me to make changes and resubmit. Hope this is helpful. - Stephan ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 10:04 Message: Logged In: YES user_id=1188172 Relevant ideas are now in #754022. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-30 10:26 Message: Logged In: YES user_id=4799 I'd like to return to discuss some parts that I've recommended to reject. When I've said "do not try to emulate a shell" I didn't mean "never manipulate a command-line", I meant "never write your own shell". Do not parse a command-line string, do not split it into words, do not interpret these words, quote them, combine and pass them to the real OS shell. Instead of manipulating strings manipulate lists (of strings and markers). Instead of quoting special characters avoid using shell altogether - use fork+exec (or spawn). This is much more safe. That said, I'd like to ask you to rewrite _safequote() and patch the entire webbrowser.py based on these ideas. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 15:18 Message: Logged In: YES user_id=4799 After two days of studying and playing with the patch I recommend to reject it. I can draw one or two smaller things from it - _isexecutable(), for example. But the entire patch is too big, too invasive, and sometimes does more harm than good. The problem number one. The patch tries to emulate a Unix shell - it splits command-line into words, it escapes shell metacharacters. And of course it fails. Nobody can emulate a shell, because there is no THE shell. There are far too many shells, all different. The patch escapes backslash, dollar sign, backtick and semicolon. What about other special characters, '!', '|', or asterisk? The problem number two. It adds ' &' to the every GenericBrowser command line. That's bad for text-mode console browsers. If I define BROWSER="lynx %s" I certainly don't want to run it in the background. And that's incompatible with the patch 754022 that runs browsers in _tryorder to find one that works; running a browser in the background prevents check if the browser has been started. The problem number three. The patch quotes too much. It quotes %s in remote commands: instead of openURL(http://example.com) it runs openURL('http://example.com'). Mozilla does not accept it and report error 509. (I don't know which instance rejects it - current or remote.) ---------------------------------------------------------------------- Comment By: Stephan R.A. Deibel (sdeibel) Date: 2005-03-21 00:46 Message: Logged In: YES user_id=12608 Sorry, guilty as charged re: uploading whole files. I did this for lack of time since there is some value here. Diffs are also not that useful given large number of changes. Agree this needs to be split up. Some additional comments: Splitting off the bug fixes for specific OSes may also be a good idea so they can be reviewed separately. Ediff is a good way to review the changes against current sources and make smaller patches. I deleted the initial (bad) upload. Not sure why I didn't do that originally. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-20 15:04 Message: Logged In: YES user_id=9057 Against the [http://python.org/patches/ Patch Submission Guidelines] this entry has uploaded both the whole file and .tgz, but no patch file. The large numbers of changes make it difficult to review. All the changes were documented to the top of the file, I don't believe they belong there. At least that is not complaint to the first rule in http://www.python.org/patches/style.html There are several OS X specific corrections that I'm unable to reproduce/validate, since I have no access to that platform. The modules was renamed to wingwebbrowser.py and the test case was built using this name. I believe this is inadequate, the original module name should be kept. There are three categories of changes: bug fixes, internal changes and interface changes. IMO it would be better to break this patch in at least three, matching these types of changes. Bug fixes would have a higher priority, less chance to break backward compatibility and more chance to be incorporated earlier. It should be applied before patch 1077979, otherwise that fix would be reversed. In spite of the formatting comments above, there are *valuable* changes in the submitted file. This is a nice candidate to be tackled in a Python Bug Day, since it functionality involves a broad range of platforms and user browsers preferences. Moreover, thourough test cases are hard to be cooked. I recommend keeping it open until somebody (possibly its author) reshape it properly and then applying it. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-20 05:38 Message: Logged In: YES user_id=9057 According to the Patch Submission Guidelines, we are supposed to submit patch files nor modified versions of modules nor zip files. I advise you to resubmit according to the guidelines documented in http://python.org/patches/ ---------------------------------------------------------------------- Comment By: Stephan R.A. Deibel (sdeibel) Date: 2004-11-24 01:08 Message: Logged In: YES user_id=12608 I'm uploading a newer version of the webbrowser.py file, which contains a small fix to avoid failing when there is an empty ("") BROWSER environment variable set. The diff is just this: --- wingwebbrowser.py 20 Feb 2004 23:45:26 -0000 1.3 +++ wingwebbrowser.py 10 Nov 2004 16:51:36 -0000 1.4 @@ -210,6 +210,8 @@ def _splitcommand(cmd): """Extract command name and args from command line""" + if cmd == '': + return '', '' if cmd[0] in ('"', "'"): name = cmd[1:cmd[1:].find(cmd[0])+1] args = cmd[len(name)+2:].strip() @@ -603,7 +605,8 @@ # Treat choices in same way as if passed into get() but do register # and prepend to _tryorder for cmdline in _userchoices: - _synthesize(cmdline, -1, True) + if cmdline != '': + _synthesize(cmdline, -1, True) cmdline = None # to make del work if _userchoices was empty del cmdline del _userchoices ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-04-29 16:50 Message: Logged In: YES user_id=6656 Is now. ---------------------------------------------------------------------- Comment By: Stephan R.A. Deibel (sdeibel) Date: 2003-04-29 16:46 Message: Logged In: YES user_id=12608 Yes, I intended it to be post-2.3. The Group popup choices doesn't include 2.4, however. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-04-29 13:51 Message: Logged In: YES user_id=21627 Because this is quite a large change, I recommend to postpone it after 2.3. ---------------------------------------------------------------------- Comment By: Stephan R.A. Deibel (sdeibel) Date: 2003-04-27 06:32 Message: Logged In: YES user_id=12608 Jeez, here is the list of changes in this patch which I meant to append to the original report. Bugs fixed: * Don't apply lower() to command lines or commands that are going to be executed * Don't confuse browser name/id with command line used to launch the browser * Require that browser commands be executable * Identify user-provided strings as a command line by looking for any args and not just for %s * Handle spaces in user-provided command names, either if quoted on the user-provided command line or escaped with back slashes * Use '%s' instead of "%s", which avoids character interpretation on Unix command lines * Escape and quote urls more safely to prevent crafting urls that result in command lines that execute arbitrary commands * Fixed Galeon so it doesn't hang up the app until the browser is quit * Added the Mac OS X support that doesn't make bad environment assumptions on OS 10.1 * Fixed win32 use of Netscape, which before would never work because the _tryorder entry was being pruned out * Leave found items in _browsers and _tryorder on OS X (but prepend the OS X specific support in _tryorder). OS X is Unix so these are useful there. * Now add %s to end of command lines if they don't contain %s already, for compatibility e.g. with KDE's default value for BROWSER environment * Now add '&' to end of Unix command lines that are going to be launched from GenericBrowser to avoid hanging up on user-provided command lines * Added additional quoting of command names, so some of the browser classes can work with a renamed browser with a space in the executable name * Added a number of return values / checks where before there were bad assumptions in the code that might have led to errors Other internal changes made: * Added unit tests * Removed the loop in get() which always returned in the first iteration * _tryorder more tightly coupled with registering in _browsers, and removed potentially problematic last-ditch GenericBrowser registering clause and the prune-_tryorder clauses from the end of the module * _iscommand also returns true if cmd is an existing file name, and it returns the full path or None instead of just True and False * _synthesize registers and returns GenericBrowser if synthesis fails but the user-provided command line looks valid * Some additional uses of True and False instead of 1 and 0 Changes to the public interface: * Added optional update_tryorder arg to register() (default value is same as previous action of this function) * Open/open_new return False if command definately failed and True if it may have succeeded (both previously returned None in all cases) * Get() returns a GenericCommand if 'using' is given and doesn't name or synthesize a browser (previously it did this correctly only when %s was in the given command line) * Values passed via BROWSER environment will be registered and synthesized in the same way as 'using' arg values are treated in get() ---------------------------------------------------------------------- Comment By: Stephan R.A. Deibel (sdeibel) Date: 2003-04-27 06:14 Message: Logged In: YES user_id=12608 Oops, correcting the upload ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=728278&group_id=5470 From noreply at sourceforge.net Thu Sep 15 10:07:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 01:07:21 -0700 Subject: [Patches] [ python-Patches-754022 ] Greatly enhanced webbrowser.py Message-ID: Patches item #754022, was opened at 2003-06-13 17:24 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Oleg Broytmann (phd) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Greatly enhanced webbrowser.py Initial Comment: The patch enhances webbrowser.py. First, all calls to os.system return result code, and the inverse of the code (it is ok/fail status) passed through all higher-level routines up to top-level call to open(url). This allows to check if a browser was really started. Second, the very open() modified so it is now trying to run all registered browsers in order until a browser returns 1. Third, the file can be used as a program: webbrowser.py url. Optional parameters -n allows to open the url in a new window. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 10:07 Message: Logged In: YES user_id=1188172 Adding new patch (webbrowser.diff), enhanced with other patches and bugfixes here on SF. Also updated the docs with changed/added notes. Please review, I'll apply this for 2.5. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 18:33 Message: Logged In: YES user_id=1188172 I have reviewed this one too, and I really recommend to apply it for 2.5. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-30 13:02 Message: Logged In: YES user_id=4799 Added Opera controller to the doc. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-30 13:01 Message: Logged In: YES user_id=4799 Added remote functionality for Opera on Unix. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-29 10:50 Message: Logged In: YES user_id=4799 Updated documention patch - added a section about webbrowser script and its command-line options and arguments. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-29 10:48 Message: Logged In: YES user_id=4799 Changed _isexecutable() on w32 to test for executable extensions (.exe, bat) . Tested on Linux with Mozilla/links/elinks; on w32 with Mozilla/Opera/Firefox. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-28 23:25 Message: Logged In: YES user_id=9057 I have revised: libwebbrowser.tex.patch and webbrowser.py.patch. They are Ok, I recommend to apply both. Outstanding work. However, I would withdraw the webbrowser wrapper script, since the same functionality can be accomplished with: python -m webbrowser http://www.python.org ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-28 16:21 Message: Logged In: YES user_id=4799 Patch for documentation. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-28 16:19 Message: Logged In: YES user_id=4799 Minor bugfix. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 14:30 Message: Logged In: YES user_id=4799 Do not report error if the browser doesn't support tabs - just open the URL in a new window. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 14:14 Message: Logged In: YES user_id=4799 I've reworked the patch once more. I moved some common functionality into the UnixBrowser class and added two new features - Elinks launcher class (elinks supports remote commands in a manner very similar to Mozilla) and new-tab functionality for browsers that support tabbed browsing (Mozilla and elinks); a user can now run "webbrowser -t URL" to open the URL a new tab. All classes in the module are now new-style classes (except for the Error class). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 22:18 Message: Logged In: YES user_id=4799 Uploading webbrowser wrapper script. Put it into Tools/scripts directory, and add to the end of setup.py. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 22:17 Message: Logged In: YES user_id=4799 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 22:14 Message: Logged In: YES user_id=4799 I've moved script code to main() function. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-23 20:25 Message: Logged In: YES user_id=9057 I have reviewed this patch in 2005-03-23 and recommend it to be applied ! Oleg have made the comments below to Python-dev, and those must be taken into consideration while applying this patch. http://python.org/sf/728278 Close with resolution "partially applied, partially rejected". http://python.org/sf/754022 Review and apply! ;) http://python.org/sf/1166780 Close with resolution "applied". (Though it was not applied in exactly that form...) http://python.org/sf/1077979 Close with resolution "applied long ago". http://python.org/sf/1144816 Close with resolution "duplicate of 1077979". ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 19:06 Message: Logged In: YES user_id=4799 I've consolidated patches 728278, 754022, 954628, 1166780 into this single patch. Some parts of those patches were applied, some rejected, many things changed. I also added elinks support - currently it is very similar to links. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-12-07 12:23 Message: Logged In: YES user_id=4799 Applied the patch from http://python.org/sf/1077979. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-20 08:11 Message: Logged In: YES user_id=80475 Too late for Py2.4. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-10-07 09:48 Message: Logged In: YES user_id=4799 And don't forget to make it executable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 From noreply at sourceforge.net Thu Sep 15 12:49:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 03:49:15 -0700 Subject: [Patches] [ python-Patches-1244861 ] Enable os.startfile and webbrowser.WindowsDefault on Cygwin Message-ID: Patches item #1244861, was opened at 2005-07-25 23:38 Message generated for change (Comment added) made by hoffmanm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1244861&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: Enable os.startfile and webbrowser.WindowsDefault on Cygwin Initial Comment: This patch enables os.startfile() on Cygwin, converting Cygwin POSIX paths to Windows paths unless they look like URLs, and calling ShellExecute() on the result. It also enables the webbrowser.WindowsDefault class, which uses os.startfile(). It has to make WindowsError and the PyErr*Windows* functions available as well because win32_startfile() might call them. ---------------------------------------------------------------------- >Comment By: Michael Hoffman (hoffmanm) Date: 2005-09-15 10:49 Message: Logged In: YES user_id=987664 Argh, sorry about that. Thanks Reinhold; here's the patch. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 07:20 Message: Logged In: YES user_id=1188172 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1244861&group_id=5470 From noreply at sourceforge.net Thu Sep 15 14:39:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 05:39:35 -0700 Subject: [Patches] [ python-Patches-1244861 ] Enable os.startfile and webbrowser.WindowsDefault on Cygwin Message-ID: Patches item #1244861, was opened at 2005-07-26 01:38 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1244861&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: Enable os.startfile and webbrowser.WindowsDefault on Cygwin Initial Comment: This patch enables os.startfile() on Cygwin, converting Cygwin POSIX paths to Windows paths unless they look like URLs, and calling ShellExecute() on the result. It also enables the webbrowser.WindowsDefault class, which uses os.startfile(). It has to make WindowsError and the PyErr*Windows* functions available as well because win32_startfile() might call them. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 14:39 Message: Logged In: YES user_id=1188172 I still see no patch... are you sure you check the right box? ;-) ---------------------------------------------------------------------- Comment By: Michael Hoffman (hoffmanm) Date: 2005-09-15 12:49 Message: Logged In: YES user_id=987664 Argh, sorry about that. Thanks Reinhold; here's the patch. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 09:20 Message: Logged In: YES user_id=1188172 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1244861&group_id=5470 From noreply at sourceforge.net Thu Sep 15 14:44:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 05:44:28 -0700 Subject: [Patches] [ python-Patches-1244861 ] Enable os.startfile and webbrowser.WindowsDefault on Cygwin Message-ID: Patches item #1244861, was opened at 2005-07-25 23:38 Message generated for change (Comment added) made by hoffmanm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1244861&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: Enable os.startfile and webbrowser.WindowsDefault on Cygwin Initial Comment: This patch enables os.startfile() on Cygwin, converting Cygwin POSIX paths to Windows paths unless they look like URLs, and calling ShellExecute() on the result. It also enables the webbrowser.WindowsDefault class, which uses os.startfile(). It has to make WindowsError and the PyErr*Windows* functions available as well because win32_startfile() might call them. ---------------------------------------------------------------------- >Comment By: Michael Hoffman (hoffmanm) Date: 2005-09-15 12:44 Message: Logged In: YES user_id=987664 Let's try this again... ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 12:39 Message: Logged In: YES user_id=1188172 I still see no patch... are you sure you check the right box? ;-) ---------------------------------------------------------------------- Comment By: Michael Hoffman (hoffmanm) Date: 2005-09-15 10:49 Message: Logged In: YES user_id=987664 Argh, sorry about that. Thanks Reinhold; here's the patch. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 07:20 Message: Logged In: YES user_id=1188172 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1244861&group_id=5470 From noreply at sourceforge.net Thu Sep 15 15:00:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 06:00:58 -0700 Subject: [Patches] [ python-Patches-1119423 ] python -c readlink()s and stat()s '-c' Message-ID: Patches item #1119423, was opened at 2005-02-09 18:00 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1119423&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Brian Foley (bpfoley) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: python -c readlink()s and stat()s '-c' Initial Comment: Due to the way input arguments are processed by Py_Main when Python is invoked with the -c switch, PySys_SetArgv treats '-c' as the name of the python executable and tries to get an absolute path for it before adding it to sys.argv. This is mostly harmless, but is doing work that shouldn't be done: on UNIX it involves calling readlink() and realpath(). The patch avoids the lookup if argv0 is '-c'. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 15:00 Message: Logged In: YES user_id=1188172 Thanks for the patch, committed in Python/sysmodule.c r2.129, r2.126.2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1119423&group_id=5470 From noreply at sourceforge.net Thu Sep 15 15:04:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 06:04:09 -0700 Subject: [Patches] [ python-Patches-1244861 ] Enable os.startfile and webbrowser.WindowsDefault on Cygwin Message-ID: Patches item #1244861, was opened at 2005-07-26 01:38 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1244861&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) >Assigned to: Raymond Hettinger (rhettinger) Summary: Enable os.startfile and webbrowser.WindowsDefault on Cygwin Initial Comment: This patch enables os.startfile() on Cygwin, converting Cygwin POSIX paths to Windows paths unless they look like URLs, and calling ShellExecute() on the result. It also enables the webbrowser.WindowsDefault class, which uses os.startfile(). It has to make WindowsError and the PyErr*Windows* functions available as well because win32_startfile() might call them. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 15:04 Message: Logged In: YES user_id=1188172 Raymond, can you look at this one? It seems to be okay, but I can't test it. ---------------------------------------------------------------------- Comment By: Michael Hoffman (hoffmanm) Date: 2005-09-15 14:44 Message: Logged In: YES user_id=987664 Let's try this again... ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 14:39 Message: Logged In: YES user_id=1188172 I still see no patch... are you sure you check the right box? ;-) ---------------------------------------------------------------------- Comment By: Michael Hoffman (hoffmanm) Date: 2005-09-15 12:49 Message: Logged In: YES user_id=987664 Argh, sorry about that. Thanks Reinhold; here's the patch. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 09:20 Message: Logged In: YES user_id=1188172 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1244861&group_id=5470 From noreply at sourceforge.net Thu Sep 15 15:16:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 06:16:56 -0700 Subject: [Patches] [ python-Patches-944928 ] Bugfix for dircheck() in Objects/fileobject.c Message-ID: Patches item #944928, was opened at 2004-04-30 00:20 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=944928&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Ulrich Berning (uberning) Assigned to: Nobody/Anonymous (nobody) Summary: Bugfix for dircheck() in Objects/fileobject.c Initial Comment: When the sys module is initialized in _PySys_Init(), it creates file objects for stdin, stdout and stderr with PyFile_FromFile() which calls fill_file_fields() to initialize the file object. At the end of initialization dircheck() is called, to ensure that the file is not a directory. If the underlaying file descriptors for stdin, stdout, stderr (0, 1, 2) are closed by the parent process, dircheck() fails at least on AIX. I don't know exactly why this fails but the following expression in dircheck() if (fstat(fileno(f->f_fp), &buf) == 0 && S_ISDIR(buf.st_mode)) evaluates to True for stdin which results in setting an exception and returning NULL to _PySys_Init(). The applied patch changes dircheck() to return without further checks if the file object is for stdin, stdout or stderr. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 15:16 Message: Logged In: YES user_id=1188172 Closing due to lack of response and improbability of validity. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-18 15:42 Message: Logged In: YES user_id=21627 This patch is not acceptable in this form. What you describe seems to point to a clear bug in AIX, and, as other AIX users have not reported that as a problem, appears to be specific to your installation. Maybe there is a problem with the compiler installation somehow? If you want to investigate this further, please try to reproduce the stat/ISDIR problem in a small stand-alone C program. If that succeeds, please generate an strace/ktrace/truss output for that binary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=944928&group_id=5470 From noreply at sourceforge.net Thu Sep 15 18:03:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 09:03:08 -0700 Subject: [Patches] [ python-Patches-1277677 ] tkinter hello world example bug Message-ID: Patches item #1277677, was opened at 2005-08-31 21:04 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1277677&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Yusuke Shinyama (euske) Assigned to: Nobody/Anonymous (nobody) Summary: tkinter hello world example bug Initial Comment: The "hello world" program, shown in the Tkinter documentation, has a small bug: it freezes IDLE when invoked from the editor. I confirmed this happens in both Windows and Linux version. So here is a small fix for it. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 18:03 Message: Logged In: YES user_id=1188172 Thanks for the fix! Committed as Doc/lib/tkinter.tex r1.32, r1.27.2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1277677&group_id=5470 From noreply at sourceforge.net Thu Sep 15 18:09:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 09:09:53 -0700 Subject: [Patches] [ python-Patches-728815 ] test_timeout updates Message-ID: Patches item #728815, was opened at 2003-04-28 12:21 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=728815&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) >Assigned to: Raymond Hettinger (rhettinger) Summary: test_timeout updates Initial Comment: Changes: - code refactoring; - now we catch only exceptions with proper errno codes (also see bug #708927); - addr_remote changed, ('www.google.com', 80) not always works for me since we use transparent proxy; - attempt to implement testSend(), testSendto(), testSendall(); ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 16:52 Message: Logged In: YES user_id=80475 I'll give it more review. Since Py2.3b2 is out, I'm marking this as a change for Py2.4 and we can apply it in early August. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 16:52 Message: Logged In: YES user_id=80475 I'll give it more review. Since Py2.3b2 is out, I'm marking this as a change for Py2.4 and we can apply it in early August. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 16:52 Message: Logged In: YES user_id=80475 I'll give it more review. Since Py2.3b2 is out, I'm marking this as a change for Py2.4 and we can apply it in early August. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-30 14:37 Message: Logged In: YES user_id=89016 I'm no expert in socket programming, so the final decision whether this is OK is your's. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 16:09 Message: Logged In: YES user_id=80475 Walter, are you interested in working this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=728815&group_id=5470 From noreply at sourceforge.net Thu Sep 15 19:26:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 10:26:37 -0700 Subject: [Patches] [ python-Patches-754022 ] Greatly enhanced webbrowser.py Message-ID: Patches item #754022, was opened at 2003-06-14 00:24 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Oleg Broytmann (phd) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Greatly enhanced webbrowser.py Initial Comment: The patch enhances webbrowser.py. First, all calls to os.system return result code, and the inverse of the code (it is ok/fail status) passed through all higher-level routines up to top-level call to open(url). This allows to check if a browser was really started. Second, the very open() modified so it is now trying to run all registered browsers in order until a browser returns 1. Third, the file can be used as a program: webbrowser.py url. Optional parameters -n allows to open the url in a new window. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-09-16 02:26 Message: Logged In: YES user_id=671362 Let me point out two problems: o NameError if remote_background: cmd += ' &' => if self.remote_background: # add "self." cmd += ' &' o copy and paste mistake? \lineiii{'mozilla'}{\class{Mozilla('mozilla')}}{} \lineiii{'firefox'}{\class{Mozilla('mozilla')}}{} => \lineiii{'mozilla'}{\class{Mozilla('mozilla')}}{} \lineiii{'firefox'}{\class{Mozilla('firefox')}}{} ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 17:07 Message: Logged In: YES user_id=1188172 Adding new patch (webbrowser.diff), enhanced with other patches and bugfixes here on SF. Also updated the docs with changed/added notes. Please review, I'll apply this for 2.5. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-02 01:33 Message: Logged In: YES user_id=1188172 I have reviewed this one too, and I really recommend to apply it for 2.5. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-30 20:02 Message: Logged In: YES user_id=4799 Added Opera controller to the doc. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-30 20:01 Message: Logged In: YES user_id=4799 Added remote functionality for Opera on Unix. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-29 17:50 Message: Logged In: YES user_id=4799 Updated documention patch - added a section about webbrowser script and its command-line options and arguments. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-29 17:48 Message: Logged In: YES user_id=4799 Changed _isexecutable() on w32 to test for executable extensions (.exe, bat) . Tested on Linux with Mozilla/links/elinks; on w32 with Mozilla/Opera/Firefox. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-29 06:25 Message: Logged In: YES user_id=9057 I have revised: libwebbrowser.tex.patch and webbrowser.py.patch. They are Ok, I recommend to apply both. Outstanding work. However, I would withdraw the webbrowser wrapper script, since the same functionality can be accomplished with: python -m webbrowser http://www.python.org ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-28 23:21 Message: Logged In: YES user_id=4799 Patch for documentation. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-28 23:19 Message: Logged In: YES user_id=4799 Minor bugfix. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 22:30 Message: Logged In: YES user_id=4799 Do not report error if the browser doesn't support tabs - just open the URL in a new window. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 22:14 Message: Logged In: YES user_id=4799 I've reworked the patch once more. I moved some common functionality into the UnixBrowser class and added two new features - Elinks launcher class (elinks supports remote commands in a manner very similar to Mozilla) and new-tab functionality for browsers that support tabbed browsing (Mozilla and elinks); a user can now run "webbrowser -t URL" to open the URL a new tab. All classes in the module are now new-style classes (except for the Error class). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 06:18 Message: Logged In: YES user_id=4799 Uploading webbrowser wrapper script. Put it into Tools/scripts directory, and add to the end of setup.py. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 06:17 Message: Logged In: YES user_id=4799 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 06:14 Message: Logged In: YES user_id=4799 I've moved script code to main() function. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-24 04:25 Message: Logged In: YES user_id=9057 I have reviewed this patch in 2005-03-23 and recommend it to be applied ! Oleg have made the comments below to Python-dev, and those must be taken into consideration while applying this patch. http://python.org/sf/728278 Close with resolution "partially applied, partially rejected". http://python.org/sf/754022 Review and apply! ;) http://python.org/sf/1166780 Close with resolution "applied". (Though it was not applied in exactly that form...) http://python.org/sf/1077979 Close with resolution "applied long ago". http://python.org/sf/1144816 Close with resolution "duplicate of 1077979". ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 03:06 Message: Logged In: YES user_id=4799 I've consolidated patches 728278, 754022, 954628, 1166780 into this single patch. Some parts of those patches were applied, some rejected, many things changed. I also added elinks support - currently it is very similar to links. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-12-07 20:23 Message: Logged In: YES user_id=4799 Applied the patch from http://python.org/sf/1077979. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-20 15:11 Message: Logged In: YES user_id=80475 Too late for Py2.4. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-10-07 16:48 Message: Logged In: YES user_id=4799 And don't forget to make it executable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 From noreply at sourceforge.net Thu Sep 15 21:49:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 12:49:41 -0700 Subject: [Patches] [ python-Patches-754022 ] Greatly enhanced webbrowser.py Message-ID: Patches item #754022, was opened at 2003-06-13 17:24 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Oleg Broytmann (phd) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Greatly enhanced webbrowser.py Initial Comment: The patch enhances webbrowser.py. First, all calls to os.system return result code, and the inverse of the code (it is ok/fail status) passed through all higher-level routines up to top-level call to open(url). This allows to check if a browser was really started. Second, the very open() modified so it is now trying to run all registered browsers in order until a browser returns 1. Third, the file can be used as a program: webbrowser.py url. Optional parameters -n allows to open the url in a new window. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 21:49 Message: Logged In: YES user_id=1188172 Ah, thanks. I had already corrected #1, but didn't look closely enough for #2. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-09-15 19:26 Message: Logged In: YES user_id=671362 Let me point out two problems: o NameError if remote_background: cmd += ' &' => if self.remote_background: # add "self." cmd += ' &' o copy and paste mistake? \lineiii{'mozilla'}{\class{Mozilla('mozilla')}}{} \lineiii{'firefox'}{\class{Mozilla('mozilla')}}{} => \lineiii{'mozilla'}{\class{Mozilla('mozilla')}}{} \lineiii{'firefox'}{\class{Mozilla('firefox')}}{} ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 10:07 Message: Logged In: YES user_id=1188172 Adding new patch (webbrowser.diff), enhanced with other patches and bugfixes here on SF. Also updated the docs with changed/added notes. Please review, I'll apply this for 2.5. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 18:33 Message: Logged In: YES user_id=1188172 I have reviewed this one too, and I really recommend to apply it for 2.5. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-30 13:02 Message: Logged In: YES user_id=4799 Added Opera controller to the doc. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-30 13:01 Message: Logged In: YES user_id=4799 Added remote functionality for Opera on Unix. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-29 10:50 Message: Logged In: YES user_id=4799 Updated documention patch - added a section about webbrowser script and its command-line options and arguments. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-29 10:48 Message: Logged In: YES user_id=4799 Changed _isexecutable() on w32 to test for executable extensions (.exe, bat) . Tested on Linux with Mozilla/links/elinks; on w32 with Mozilla/Opera/Firefox. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-28 23:25 Message: Logged In: YES user_id=9057 I have revised: libwebbrowser.tex.patch and webbrowser.py.patch. They are Ok, I recommend to apply both. Outstanding work. However, I would withdraw the webbrowser wrapper script, since the same functionality can be accomplished with: python -m webbrowser http://www.python.org ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-28 16:21 Message: Logged In: YES user_id=4799 Patch for documentation. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-28 16:19 Message: Logged In: YES user_id=4799 Minor bugfix. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 14:30 Message: Logged In: YES user_id=4799 Do not report error if the browser doesn't support tabs - just open the URL in a new window. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 14:14 Message: Logged In: YES user_id=4799 I've reworked the patch once more. I moved some common functionality into the UnixBrowser class and added two new features - Elinks launcher class (elinks supports remote commands in a manner very similar to Mozilla) and new-tab functionality for browsers that support tabbed browsing (Mozilla and elinks); a user can now run "webbrowser -t URL" to open the URL a new tab. All classes in the module are now new-style classes (except for the Error class). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 22:18 Message: Logged In: YES user_id=4799 Uploading webbrowser wrapper script. Put it into Tools/scripts directory, and add to the end of setup.py. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 22:17 Message: Logged In: YES user_id=4799 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 22:14 Message: Logged In: YES user_id=4799 I've moved script code to main() function. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-23 20:25 Message: Logged In: YES user_id=9057 I have reviewed this patch in 2005-03-23 and recommend it to be applied ! Oleg have made the comments below to Python-dev, and those must be taken into consideration while applying this patch. http://python.org/sf/728278 Close with resolution "partially applied, partially rejected". http://python.org/sf/754022 Review and apply! ;) http://python.org/sf/1166780 Close with resolution "applied". (Though it was not applied in exactly that form...) http://python.org/sf/1077979 Close with resolution "applied long ago". http://python.org/sf/1144816 Close with resolution "duplicate of 1077979". ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 19:06 Message: Logged In: YES user_id=4799 I've consolidated patches 728278, 754022, 954628, 1166780 into this single patch. Some parts of those patches were applied, some rejected, many things changed. I also added elinks support - currently it is very similar to links. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-12-07 12:23 Message: Logged In: YES user_id=4799 Applied the patch from http://python.org/sf/1077979. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-20 08:11 Message: Logged In: YES user_id=80475 Too late for Py2.4. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-10-07 09:48 Message: Logged In: YES user_id=4799 And don't forget to make it executable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 From noreply at sourceforge.net Thu Sep 15 22:18:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 13:18:15 -0700 Subject: [Patches] [ python-Patches-754022 ] Greatly enhanced webbrowser.py Message-ID: Patches item #754022, was opened at 2003-06-13 19:24 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Oleg Broytmann (phd) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Greatly enhanced webbrowser.py Initial Comment: The patch enhances webbrowser.py. First, all calls to os.system return result code, and the inverse of the code (it is ok/fail status) passed through all higher-level routines up to top-level call to open(url). This allows to check if a browser was really started. Second, the very open() modified so it is now trying to run all registered browsers in order until a browser returns 1. Third, the file can be used as a program: webbrowser.py url. Optional parameters -n allows to open the url in a new window. ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2005-09-16 00:18 Message: Logged In: YES user_id=4799 In the main(): opts, args = getopt.getopt(sys.argv[1:], 'ntd') You can remove 'd' as you've dropeed debugging prints. Are you going to drop standalone webbrowser script? Is "python -m webbrowser" enough? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 23:49 Message: Logged In: YES user_id=1188172 Ah, thanks. I had already corrected #1, but didn't look closely enough for #2. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-09-15 21:26 Message: Logged In: YES user_id=671362 Let me point out two problems: o NameError if remote_background: cmd += ' &' => if self.remote_background: # add "self." cmd += ' &' o copy and paste mistake? \lineiii{'mozilla'}{\class{Mozilla('mozilla')}}{} \lineiii{'firefox'}{\class{Mozilla('mozilla')}}{} => \lineiii{'mozilla'}{\class{Mozilla('mozilla')}}{} \lineiii{'firefox'}{\class{Mozilla('firefox')}}{} ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 12:07 Message: Logged In: YES user_id=1188172 Adding new patch (webbrowser.diff), enhanced with other patches and bugfixes here on SF. Also updated the docs with changed/added notes. Please review, I'll apply this for 2.5. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 20:33 Message: Logged In: YES user_id=1188172 I have reviewed this one too, and I really recommend to apply it for 2.5. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-30 15:02 Message: Logged In: YES user_id=4799 Added Opera controller to the doc. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-30 15:01 Message: Logged In: YES user_id=4799 Added remote functionality for Opera on Unix. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-29 12:50 Message: Logged In: YES user_id=4799 Updated documention patch - added a section about webbrowser script and its command-line options and arguments. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-29 12:48 Message: Logged In: YES user_id=4799 Changed _isexecutable() on w32 to test for executable extensions (.exe, bat) . Tested on Linux with Mozilla/links/elinks; on w32 with Mozilla/Opera/Firefox. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-29 01:25 Message: Logged In: YES user_id=9057 I have revised: libwebbrowser.tex.patch and webbrowser.py.patch. They are Ok, I recommend to apply both. Outstanding work. However, I would withdraw the webbrowser wrapper script, since the same functionality can be accomplished with: python -m webbrowser http://www.python.org ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-28 18:21 Message: Logged In: YES user_id=4799 Patch for documentation. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-28 18:19 Message: Logged In: YES user_id=4799 Minor bugfix. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 16:30 Message: Logged In: YES user_id=4799 Do not report error if the browser doesn't support tabs - just open the URL in a new window. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 16:14 Message: Logged In: YES user_id=4799 I've reworked the patch once more. I moved some common functionality into the UnixBrowser class and added two new features - Elinks launcher class (elinks supports remote commands in a manner very similar to Mozilla) and new-tab functionality for browsers that support tabbed browsing (Mozilla and elinks); a user can now run "webbrowser -t URL" to open the URL a new tab. All classes in the module are now new-style classes (except for the Error class). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 00:18 Message: Logged In: YES user_id=4799 Uploading webbrowser wrapper script. Put it into Tools/scripts directory, and add to the end of setup.py. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 00:17 Message: Logged In: YES user_id=4799 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 00:14 Message: Logged In: YES user_id=4799 I've moved script code to main() function. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-23 22:25 Message: Logged In: YES user_id=9057 I have reviewed this patch in 2005-03-23 and recommend it to be applied ! Oleg have made the comments below to Python-dev, and those must be taken into consideration while applying this patch. http://python.org/sf/728278 Close with resolution "partially applied, partially rejected". http://python.org/sf/754022 Review and apply! ;) http://python.org/sf/1166780 Close with resolution "applied". (Though it was not applied in exactly that form...) http://python.org/sf/1077979 Close with resolution "applied long ago". http://python.org/sf/1144816 Close with resolution "duplicate of 1077979". ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 21:06 Message: Logged In: YES user_id=4799 I've consolidated patches 728278, 754022, 954628, 1166780 into this single patch. Some parts of those patches were applied, some rejected, many things changed. I also added elinks support - currently it is very similar to links. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-12-07 14:23 Message: Logged In: YES user_id=4799 Applied the patch from http://python.org/sf/1077979. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-20 10:11 Message: Logged In: YES user_id=80475 Too late for Py2.4. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-10-07 11:48 Message: Logged In: YES user_id=4799 And don't forget to make it executable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 From noreply at sourceforge.net Thu Sep 15 22:48:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 13:48:28 -0700 Subject: [Patches] [ python-Patches-754022 ] Greatly enhanced webbrowser.py Message-ID: Patches item #754022, was opened at 2003-06-13 17:24 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Oleg Broytmann (phd) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Greatly enhanced webbrowser.py Initial Comment: The patch enhances webbrowser.py. First, all calls to os.system return result code, and the inverse of the code (it is ok/fail status) passed through all higher-level routines up to top-level call to open(url). This allows to check if a browser was really started. Second, the very open() modified so it is now trying to run all registered browsers in order until a browser returns 1. Third, the file can be used as a program: webbrowser.py url. Optional parameters -n allows to open the url in a new window. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 22:48 Message: Logged In: YES user_id=1188172 No other module that can be used standalone delivers such a script. There's also the question where to install it, etc. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-09-15 22:18 Message: Logged In: YES user_id=4799 In the main(): opts, args = getopt.getopt(sys.argv[1:], 'ntd') You can remove 'd' as you've dropeed debugging prints. Are you going to drop standalone webbrowser script? Is "python -m webbrowser" enough? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 21:49 Message: Logged In: YES user_id=1188172 Ah, thanks. I had already corrected #1, but didn't look closely enough for #2. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-09-15 19:26 Message: Logged In: YES user_id=671362 Let me point out two problems: o NameError if remote_background: cmd += ' &' => if self.remote_background: # add "self." cmd += ' &' o copy and paste mistake? \lineiii{'mozilla'}{\class{Mozilla('mozilla')}}{} \lineiii{'firefox'}{\class{Mozilla('mozilla')}}{} => \lineiii{'mozilla'}{\class{Mozilla('mozilla')}}{} \lineiii{'firefox'}{\class{Mozilla('firefox')}}{} ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 10:07 Message: Logged In: YES user_id=1188172 Adding new patch (webbrowser.diff), enhanced with other patches and bugfixes here on SF. Also updated the docs with changed/added notes. Please review, I'll apply this for 2.5. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 18:33 Message: Logged In: YES user_id=1188172 I have reviewed this one too, and I really recommend to apply it for 2.5. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-30 13:02 Message: Logged In: YES user_id=4799 Added Opera controller to the doc. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-30 13:01 Message: Logged In: YES user_id=4799 Added remote functionality for Opera on Unix. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-29 10:50 Message: Logged In: YES user_id=4799 Updated documention patch - added a section about webbrowser script and its command-line options and arguments. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-29 10:48 Message: Logged In: YES user_id=4799 Changed _isexecutable() on w32 to test for executable extensions (.exe, bat) . Tested on Linux with Mozilla/links/elinks; on w32 with Mozilla/Opera/Firefox. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-28 23:25 Message: Logged In: YES user_id=9057 I have revised: libwebbrowser.tex.patch and webbrowser.py.patch. They are Ok, I recommend to apply both. Outstanding work. However, I would withdraw the webbrowser wrapper script, since the same functionality can be accomplished with: python -m webbrowser http://www.python.org ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-28 16:21 Message: Logged In: YES user_id=4799 Patch for documentation. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-28 16:19 Message: Logged In: YES user_id=4799 Minor bugfix. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 14:30 Message: Logged In: YES user_id=4799 Do not report error if the browser doesn't support tabs - just open the URL in a new window. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 14:14 Message: Logged In: YES user_id=4799 I've reworked the patch once more. I moved some common functionality into the UnixBrowser class and added two new features - Elinks launcher class (elinks supports remote commands in a manner very similar to Mozilla) and new-tab functionality for browsers that support tabbed browsing (Mozilla and elinks); a user can now run "webbrowser -t URL" to open the URL a new tab. All classes in the module are now new-style classes (except for the Error class). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 22:18 Message: Logged In: YES user_id=4799 Uploading webbrowser wrapper script. Put it into Tools/scripts directory, and add to the end of setup.py. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 22:17 Message: Logged In: YES user_id=4799 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 22:14 Message: Logged In: YES user_id=4799 I've moved script code to main() function. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-23 20:25 Message: Logged In: YES user_id=9057 I have reviewed this patch in 2005-03-23 and recommend it to be applied ! Oleg have made the comments below to Python-dev, and those must be taken into consideration while applying this patch. http://python.org/sf/728278 Close with resolution "partially applied, partially rejected". http://python.org/sf/754022 Review and apply! ;) http://python.org/sf/1166780 Close with resolution "applied". (Though it was not applied in exactly that form...) http://python.org/sf/1077979 Close with resolution "applied long ago". http://python.org/sf/1144816 Close with resolution "duplicate of 1077979". ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 19:06 Message: Logged In: YES user_id=4799 I've consolidated patches 728278, 754022, 954628, 1166780 into this single patch. Some parts of those patches were applied, some rejected, many things changed. I also added elinks support - currently it is very similar to links. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-12-07 12:23 Message: Logged In: YES user_id=4799 Applied the patch from http://python.org/sf/1077979. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-20 08:11 Message: Logged In: YES user_id=80475 Too late for Py2.4. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-10-07 09:48 Message: Logged In: YES user_id=4799 And don't forget to make it executable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 From noreply at sourceforge.net Thu Sep 15 23:52:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 14:52:55 -0700 Subject: [Patches] [ python-Patches-754022 ] Greatly enhanced webbrowser.py Message-ID: Patches item #754022, was opened at 2003-06-13 19:24 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Oleg Broytmann (phd) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Greatly enhanced webbrowser.py Initial Comment: The patch enhances webbrowser.py. First, all calls to os.system return result code, and the inverse of the code (it is ok/fail status) passed through all higher-level routines up to top-level call to open(url). This allows to check if a browser was really started. Second, the very open() modified so it is now trying to run all registered browsers in order until a browser returns 1. Third, the file can be used as a program: webbrowser.py url. Optional parameters -n allows to open the url in a new window. ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2005-09-16 01:52 Message: Logged In: YES user_id=4799 >From setup.py: scripts = ['Tools/scripts/pydoc', 'Tools/scripts/idle', 'Lib/smtpd.py'] See, Python installs 3 scripts into /usr/{local/}bin/ - pydoc, idle and smtpd.py. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-16 00:48 Message: Logged In: YES user_id=1188172 No other module that can be used standalone delivers such a script. There's also the question where to install it, etc. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-09-16 00:18 Message: Logged In: YES user_id=4799 In the main(): opts, args = getopt.getopt(sys.argv[1:], 'ntd') You can remove 'd' as you've dropeed debugging prints. Are you going to drop standalone webbrowser script? Is "python -m webbrowser" enough? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 23:49 Message: Logged In: YES user_id=1188172 Ah, thanks. I had already corrected #1, but didn't look closely enough for #2. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-09-15 21:26 Message: Logged In: YES user_id=671362 Let me point out two problems: o NameError if remote_background: cmd += ' &' => if self.remote_background: # add "self." cmd += ' &' o copy and paste mistake? \lineiii{'mozilla'}{\class{Mozilla('mozilla')}}{} \lineiii{'firefox'}{\class{Mozilla('mozilla')}}{} => \lineiii{'mozilla'}{\class{Mozilla('mozilla')}}{} \lineiii{'firefox'}{\class{Mozilla('firefox')}}{} ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 12:07 Message: Logged In: YES user_id=1188172 Adding new patch (webbrowser.diff), enhanced with other patches and bugfixes here on SF. Also updated the docs with changed/added notes. Please review, I'll apply this for 2.5. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 20:33 Message: Logged In: YES user_id=1188172 I have reviewed this one too, and I really recommend to apply it for 2.5. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-30 15:02 Message: Logged In: YES user_id=4799 Added Opera controller to the doc. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-30 15:01 Message: Logged In: YES user_id=4799 Added remote functionality for Opera on Unix. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-29 12:50 Message: Logged In: YES user_id=4799 Updated documention patch - added a section about webbrowser script and its command-line options and arguments. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-29 12:48 Message: Logged In: YES user_id=4799 Changed _isexecutable() on w32 to test for executable extensions (.exe, bat) . Tested on Linux with Mozilla/links/elinks; on w32 with Mozilla/Opera/Firefox. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-29 01:25 Message: Logged In: YES user_id=9057 I have revised: libwebbrowser.tex.patch and webbrowser.py.patch. They are Ok, I recommend to apply both. Outstanding work. However, I would withdraw the webbrowser wrapper script, since the same functionality can be accomplished with: python -m webbrowser http://www.python.org ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-28 18:21 Message: Logged In: YES user_id=4799 Patch for documentation. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-28 18:19 Message: Logged In: YES user_id=4799 Minor bugfix. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 16:30 Message: Logged In: YES user_id=4799 Do not report error if the browser doesn't support tabs - just open the URL in a new window. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 16:14 Message: Logged In: YES user_id=4799 I've reworked the patch once more. I moved some common functionality into the UnixBrowser class and added two new features - Elinks launcher class (elinks supports remote commands in a manner very similar to Mozilla) and new-tab functionality for browsers that support tabbed browsing (Mozilla and elinks); a user can now run "webbrowser -t URL" to open the URL a new tab. All classes in the module are now new-style classes (except for the Error class). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 00:18 Message: Logged In: YES user_id=4799 Uploading webbrowser wrapper script. Put it into Tools/scripts directory, and add to the end of setup.py. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 00:17 Message: Logged In: YES user_id=4799 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 00:14 Message: Logged In: YES user_id=4799 I've moved script code to main() function. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-23 22:25 Message: Logged In: YES user_id=9057 I have reviewed this patch in 2005-03-23 and recommend it to be applied ! Oleg have made the comments below to Python-dev, and those must be taken into consideration while applying this patch. http://python.org/sf/728278 Close with resolution "partially applied, partially rejected". http://python.org/sf/754022 Review and apply! ;) http://python.org/sf/1166780 Close with resolution "applied". (Though it was not applied in exactly that form...) http://python.org/sf/1077979 Close with resolution "applied long ago". http://python.org/sf/1144816 Close with resolution "duplicate of 1077979". ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 21:06 Message: Logged In: YES user_id=4799 I've consolidated patches 728278, 754022, 954628, 1166780 into this single patch. Some parts of those patches were applied, some rejected, many things changed. I also added elinks support - currently it is very similar to links. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-12-07 14:23 Message: Logged In: YES user_id=4799 Applied the patch from http://python.org/sf/1077979. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-20 10:11 Message: Logged In: YES user_id=80475 Too late for Py2.4. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-10-07 11:48 Message: Logged In: YES user_id=4799 And don't forget to make it executable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 From noreply at sourceforge.net Fri Sep 16 08:32:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 23:32:16 -0700 Subject: [Patches] [ python-Patches-754022 ] Greatly enhanced webbrowser.py Message-ID: Patches item #754022, was opened at 2003-06-13 17:24 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Oleg Broytmann (phd) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Greatly enhanced webbrowser.py Initial Comment: The patch enhances webbrowser.py. First, all calls to os.system return result code, and the inverse of the code (it is ok/fail status) passed through all higher-level routines up to top-level call to open(url). This allows to check if a browser was really started. Second, the very open() modified so it is now trying to run all registered browsers in order until a browser returns 1. Third, the file can be used as a program: webbrowser.py url. Optional parameters -n allows to open the url in a new window. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-16 08:32 Message: Logged In: YES user_id=1188172 Granted, but you will concur that starting a webbrowser isn't something that the command line user normally wants to do via a Python script. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-09-15 23:52 Message: Logged In: YES user_id=4799 >From setup.py: scripts = ['Tools/scripts/pydoc', 'Tools/scripts/idle', 'Lib/smtpd.py'] See, Python installs 3 scripts into /usr/{local/}bin/ - pydoc, idle and smtpd.py. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 22:48 Message: Logged In: YES user_id=1188172 No other module that can be used standalone delivers such a script. There's also the question where to install it, etc. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-09-15 22:18 Message: Logged In: YES user_id=4799 In the main(): opts, args = getopt.getopt(sys.argv[1:], 'ntd') You can remove 'd' as you've dropeed debugging prints. Are you going to drop standalone webbrowser script? Is "python -m webbrowser" enough? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 21:49 Message: Logged In: YES user_id=1188172 Ah, thanks. I had already corrected #1, but didn't look closely enough for #2. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-09-15 19:26 Message: Logged In: YES user_id=671362 Let me point out two problems: o NameError if remote_background: cmd += ' &' => if self.remote_background: # add "self." cmd += ' &' o copy and paste mistake? \lineiii{'mozilla'}{\class{Mozilla('mozilla')}}{} \lineiii{'firefox'}{\class{Mozilla('mozilla')}}{} => \lineiii{'mozilla'}{\class{Mozilla('mozilla')}}{} \lineiii{'firefox'}{\class{Mozilla('firefox')}}{} ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 10:07 Message: Logged In: YES user_id=1188172 Adding new patch (webbrowser.diff), enhanced with other patches and bugfixes here on SF. Also updated the docs with changed/added notes. Please review, I'll apply this for 2.5. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 18:33 Message: Logged In: YES user_id=1188172 I have reviewed this one too, and I really recommend to apply it for 2.5. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-30 13:02 Message: Logged In: YES user_id=4799 Added Opera controller to the doc. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-30 13:01 Message: Logged In: YES user_id=4799 Added remote functionality for Opera on Unix. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-29 10:50 Message: Logged In: YES user_id=4799 Updated documention patch - added a section about webbrowser script and its command-line options and arguments. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-29 10:48 Message: Logged In: YES user_id=4799 Changed _isexecutable() on w32 to test for executable extensions (.exe, bat) . Tested on Linux with Mozilla/links/elinks; on w32 with Mozilla/Opera/Firefox. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-28 23:25 Message: Logged In: YES user_id=9057 I have revised: libwebbrowser.tex.patch and webbrowser.py.patch. They are Ok, I recommend to apply both. Outstanding work. However, I would withdraw the webbrowser wrapper script, since the same functionality can be accomplished with: python -m webbrowser http://www.python.org ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-28 16:21 Message: Logged In: YES user_id=4799 Patch for documentation. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-28 16:19 Message: Logged In: YES user_id=4799 Minor bugfix. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 14:30 Message: Logged In: YES user_id=4799 Do not report error if the browser doesn't support tabs - just open the URL in a new window. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 14:14 Message: Logged In: YES user_id=4799 I've reworked the patch once more. I moved some common functionality into the UnixBrowser class and added two new features - Elinks launcher class (elinks supports remote commands in a manner very similar to Mozilla) and new-tab functionality for browsers that support tabbed browsing (Mozilla and elinks); a user can now run "webbrowser -t URL" to open the URL a new tab. All classes in the module are now new-style classes (except for the Error class). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 22:18 Message: Logged In: YES user_id=4799 Uploading webbrowser wrapper script. Put it into Tools/scripts directory, and add to the end of setup.py. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 22:17 Message: Logged In: YES user_id=4799 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 22:14 Message: Logged In: YES user_id=4799 I've moved script code to main() function. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-23 20:25 Message: Logged In: YES user_id=9057 I have reviewed this patch in 2005-03-23 and recommend it to be applied ! Oleg have made the comments below to Python-dev, and those must be taken into consideration while applying this patch. http://python.org/sf/728278 Close with resolution "partially applied, partially rejected". http://python.org/sf/754022 Review and apply! ;) http://python.org/sf/1166780 Close with resolution "applied". (Though it was not applied in exactly that form...) http://python.org/sf/1077979 Close with resolution "applied long ago". http://python.org/sf/1144816 Close with resolution "duplicate of 1077979". ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 19:06 Message: Logged In: YES user_id=4799 I've consolidated patches 728278, 754022, 954628, 1166780 into this single patch. Some parts of those patches were applied, some rejected, many things changed. I also added elinks support - currently it is very similar to links. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-12-07 12:23 Message: Logged In: YES user_id=4799 Applied the patch from http://python.org/sf/1077979. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-20 08:11 Message: Logged In: YES user_id=80475 Too late for Py2.4. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-10-07 09:48 Message: Logged In: YES user_id=4799 And don't forget to make it executable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 From noreply at sourceforge.net Fri Sep 16 09:14:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Sep 2005 00:14:32 -0700 Subject: [Patches] [ python-Patches-1292625 ] use LIST_APPEND opcode for X.append() method calls Message-ID: Patches item #1292625, was opened at 2005-09-16 00:14 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=1292625&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: use LIST_APPEND opcode for X.append() method calls Initial Comment: As discussed on python-dev here: http://mail.python.org/pipermail/python-dev/2005-September/056396.html This is a more complete version. It seems to speed up code that makes heavy use of append by about 1.5 - 2.0 % ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1292625&group_id=5470 From noreply at sourceforge.net Fri Sep 16 09:28:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Sep 2005 00:28:55 -0700 Subject: [Patches] [ python-Patches-754022 ] Greatly enhanced webbrowser.py Message-ID: Patches item #754022, was opened at 2003-06-13 19:24 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Oleg Broytmann (phd) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Greatly enhanced webbrowser.py Initial Comment: The patch enhances webbrowser.py. First, all calls to os.system return result code, and the inverse of the code (it is ok/fail status) passed through all higher-level routines up to top-level call to open(url). This allows to check if a browser was really started. Second, the very open() modified so it is now trying to run all registered browsers in order until a browser returns 1. Third, the file can be used as a program: webbrowser.py url. Optional parameters -n allows to open the url in a new window. ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2005-09-16 11:28 Message: Logged In: YES user_id=4799 Arguable (especially compared with smtpd.py), but I am not goint to argue. Please apply the patch and let us see what other people think and say. It seems there are enough users... ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-16 10:32 Message: Logged In: YES user_id=1188172 Granted, but you will concur that starting a webbrowser isn't something that the command line user normally wants to do via a Python script. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-09-16 01:52 Message: Logged In: YES user_id=4799 >From setup.py: scripts = ['Tools/scripts/pydoc', 'Tools/scripts/idle', 'Lib/smtpd.py'] See, Python installs 3 scripts into /usr/{local/}bin/ - pydoc, idle and smtpd.py. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-16 00:48 Message: Logged In: YES user_id=1188172 No other module that can be used standalone delivers such a script. There's also the question where to install it, etc. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-09-16 00:18 Message: Logged In: YES user_id=4799 In the main(): opts, args = getopt.getopt(sys.argv[1:], 'ntd') You can remove 'd' as you've dropeed debugging prints. Are you going to drop standalone webbrowser script? Is "python -m webbrowser" enough? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 23:49 Message: Logged In: YES user_id=1188172 Ah, thanks. I had already corrected #1, but didn't look closely enough for #2. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-09-15 21:26 Message: Logged In: YES user_id=671362 Let me point out two problems: o NameError if remote_background: cmd += ' &' => if self.remote_background: # add "self." cmd += ' &' o copy and paste mistake? \lineiii{'mozilla'}{\class{Mozilla('mozilla')}}{} \lineiii{'firefox'}{\class{Mozilla('mozilla')}}{} => \lineiii{'mozilla'}{\class{Mozilla('mozilla')}}{} \lineiii{'firefox'}{\class{Mozilla('firefox')}}{} ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 12:07 Message: Logged In: YES user_id=1188172 Adding new patch (webbrowser.diff), enhanced with other patches and bugfixes here on SF. Also updated the docs with changed/added notes. Please review, I'll apply this for 2.5. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 20:33 Message: Logged In: YES user_id=1188172 I have reviewed this one too, and I really recommend to apply it for 2.5. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-30 15:02 Message: Logged In: YES user_id=4799 Added Opera controller to the doc. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-30 15:01 Message: Logged In: YES user_id=4799 Added remote functionality for Opera on Unix. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-29 12:50 Message: Logged In: YES user_id=4799 Updated documention patch - added a section about webbrowser script and its command-line options and arguments. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-29 12:48 Message: Logged In: YES user_id=4799 Changed _isexecutable() on w32 to test for executable extensions (.exe, bat) . Tested on Linux with Mozilla/links/elinks; on w32 with Mozilla/Opera/Firefox. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-29 01:25 Message: Logged In: YES user_id=9057 I have revised: libwebbrowser.tex.patch and webbrowser.py.patch. They are Ok, I recommend to apply both. Outstanding work. However, I would withdraw the webbrowser wrapper script, since the same functionality can be accomplished with: python -m webbrowser http://www.python.org ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-28 18:21 Message: Logged In: YES user_id=4799 Patch for documentation. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-28 18:19 Message: Logged In: YES user_id=4799 Minor bugfix. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 16:30 Message: Logged In: YES user_id=4799 Do not report error if the browser doesn't support tabs - just open the URL in a new window. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 16:14 Message: Logged In: YES user_id=4799 I've reworked the patch once more. I moved some common functionality into the UnixBrowser class and added two new features - Elinks launcher class (elinks supports remote commands in a manner very similar to Mozilla) and new-tab functionality for browsers that support tabbed browsing (Mozilla and elinks); a user can now run "webbrowser -t URL" to open the URL a new tab. All classes in the module are now new-style classes (except for the Error class). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 00:18 Message: Logged In: YES user_id=4799 Uploading webbrowser wrapper script. Put it into Tools/scripts directory, and add to the end of setup.py. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 00:17 Message: Logged In: YES user_id=4799 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 00:14 Message: Logged In: YES user_id=4799 I've moved script code to main() function. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-23 22:25 Message: Logged In: YES user_id=9057 I have reviewed this patch in 2005-03-23 and recommend it to be applied ! Oleg have made the comments below to Python-dev, and those must be taken into consideration while applying this patch. http://python.org/sf/728278 Close with resolution "partially applied, partially rejected". http://python.org/sf/754022 Review and apply! ;) http://python.org/sf/1166780 Close with resolution "applied". (Though it was not applied in exactly that form...) http://python.org/sf/1077979 Close with resolution "applied long ago". http://python.org/sf/1144816 Close with resolution "duplicate of 1077979". ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 21:06 Message: Logged In: YES user_id=4799 I've consolidated patches 728278, 754022, 954628, 1166780 into this single patch. Some parts of those patches were applied, some rejected, many things changed. I also added elinks support - currently it is very similar to links. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-12-07 14:23 Message: Logged In: YES user_id=4799 Applied the patch from http://python.org/sf/1077979. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-20 10:11 Message: Logged In: YES user_id=80475 Too late for Py2.4. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-10-07 11:48 Message: Logged In: YES user_id=4799 And don't forget to make it executable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 From noreply at sourceforge.net Fri Sep 16 10:12:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Sep 2005 01:12:41 -0700 Subject: [Patches] [ python-Patches-1292625 ] use LIST_APPEND opcode for X.append() method calls Message-ID: Patches item #1292625, was opened at 2005-09-16 02:14 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1292625&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: use LIST_APPEND opcode for X.append() method calls Initial Comment: As discussed on python-dev here: http://mail.python.org/pipermail/python-dev/2005-September/056396.html This is a more complete version. It seems to speed up code that makes heavy use of append by about 1.5 - 2.0 % ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-16 03:12 Message: Logged In: YES user_id=80475 -0 on this one. It really needs a much larger improvement (30% to 50%) to be worth it. The new ceval.c code for LIST_APPEND will slightly slow-down the list comprehension case that the opcode was originally designed for. Also, it slows-down the peepholer with a string comparison test for every attribute lookup making it the slowest and most frequently executed code in the peepholer. The implementation is limited to the simplest case, x.append(y) and cannot handle general expressions such x.append(y+y). It would likely be better to implement this sort of transformation through AST when it is complete. If it goes in anyway, be sure to add a test to make sure descriptors still work (i.e. a non-data descriptor called "append" for a user defined class). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1292625&group_id=5470 From noreply at sourceforge.net Sat Sep 17 14:50:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Sep 2005 05:50:52 -0700 Subject: [Patches] [ python-Patches-1293788 ] python.sty correction - verbatim environment Message-ID: Patches item #1293788, was opened at 2005-09-17 14:50 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=1293788&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wojciech Smigaj (smigaj) Assigned to: Nobody/Anonymous (nobody) Summary: python.sty correction - verbatim environment Initial Comment: This patch alters the way the verbatim environment is customized in the python.sty package. The old way -- essentially redefining the environment -- made the verbatim text be surrounded by an excessive, and somewhat irregular, amount of space. To get rid of it I propose to use the dedicated \every at verbatim hook and \verbatim at font commands. As a result we get code: - typeset in \small typeface, - separated from the preceding and following text by exactly \parskip (the amount of space separating normal paragraphs), - indented by \leftmargini -- the indent consistent with that used e.g. in descriptions. The code isn't enclosed in a minipage any more, as I can't see any reason for it now. Consequently, page breaking inside verbatim text is now permitted (which I consider a good thing, since listings may be lengthy). As a minor trouble, the alltt package defining the environment of the same name does not use the \every at verbatim hook. However, since the code is rather short, I propose to include the modified definition in the python.sty package itself. A test case: compare how the code included into "Documenting Python" (doc.tex) looks when latexed with the original and modified versions of python.sty. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1293788&group_id=5470 From noreply at sourceforge.net Sat Sep 17 14:54:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Sep 2005 05:54:38 -0700 Subject: [Patches] [ python-Patches-1293790 ] python.sty: \py@sigline correction Message-ID: Patches item #1293790, was opened at 2005-09-17 14:54 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=1293790&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wojciech Smigaj (smigaj) Assigned to: Nobody/Anonymous (nobody) Summary: python.sty: \py at sigline correction Initial Comment: This patch corrects the following bug: the last line of multiline headings created with environments like classdesc, methoddesc... clash into the following text. The source of this problem is typesetting the "parameter" part of the heading inside a \parbox[t] (parbox with its first ("top") line aligned with the surrounding text). As a consequence, when the parameter list takes multiple lines, all lines beneath the first add up to the *depth* (not the *height*) of the parbox. This causes TeX to treat the box as a very long "descender", and place only \lineskip=1pt between the bottom of the box and the following line. The proposed solution is to shape the paragraph in a "natural" way, using the \hangafter and \hangindent macros instead of the \parbox command. Additionally, inclusion of the \raggedright macro makes the argument list left-justified, thus preventing excessive stretching of interword spaces and hyphenation of parameter names, which doesn't look good in most cases. A test case follows (text taken from the PyX package manual). Compare the space between both headings when processed with the original and modified versions of python.sty. \documentclass{manual} \begin{document} some text\dots \begin{classdesc}{histogram}{lineattrs=[], steps=0, fromvalue=0, % {{{ frompathattrs=[], fillable=0, autohistogramaxisindex=0, autohistogrampointpos=0.5, epsilon=1e-10} This class is a style to plot histograms. \var{lineattrs} is merged with \code{defaultlineattrs} which is \code{[deco.stroked]}. When \var{steps} is set, the histrogram is plotted as steps instead of the default being a boxed histogram. \var{fromvalue} is the baseline value of the histogram. When set to \code{None}, the histogram will start at the baseline. When fromvalue is set, \var{frompathattrs} are the stroke attributes used to show the histogram baseline path. etc\dots \end{classdesc} \begin{classdesc}{barpos}{fromvalue=None, frompathattrs=[], epsilon=1e-10} % {{{ This class is a hidden style providing position information in a bar graph. Those graphs need to contain a specialized axis, namely a bar axis. The data column for this bar axis is named \code{Xname} where \code{X} is an axis name. In the other graph dimension the data column name must be equal to an axis name. To plot several bars in a single graph side by side, you need to have a nested bar axis and provide a tuple as data for nested bar axis. \end{classdesc} \end{document} ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1293790&group_id=5470 From noreply at sourceforge.net Sun Sep 18 10:19:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Sep 2005 01:19:17 -0700 Subject: [Patches] [ python-Patches-1213831 ] Trivial typo in unicodedata._getcode Message-ID: Patches item #1213831, was opened at 2005-06-03 00:00 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1213831&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Darek Suchojad (dsuch) Assigned to: Martin v. L?wis (loewis) Summary: Trivial typo in unicodedata._getcode Initial Comment: Hi, I think there's a typo in unicodedata module's _getcode function. Line 823 (today's CVS build) should be if (L != -1 && V != -1 && T != -1 && pos-name == namelen) { not if (V != -1 && V != -1 && T != -1 && pos-name == namelen) { as in attached patch. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-09-18 10:19 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as NEWS 1.1368 unicodedata.c 2.35 NEWS 1.1193.2.100 unicodedata.c 2.32.2.1 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-03 02:36 Message: Logged In: YES user_id=80475 Martin, I believe this is your code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1213831&group_id=5470 From noreply at sourceforge.net Sun Sep 18 10:31:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Sep 2005 01:31:02 -0700 Subject: [Patches] [ python-Patches-1213831 ] Trivial typo in unicodedata._getcode Message-ID: Patches item #1213831, was opened at 2005-06-03 00:00 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1213831&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Darek Suchojad (dsuch) Assigned to: Martin v. L?wis (loewis) Summary: Trivial typo in unicodedata._getcode Initial Comment: Hi, I think there's a typo in unicodedata module's _getcode function. Line 823 (today's CVS build) should be if (L != -1 && V != -1 && T != -1 && pos-name == namelen) { not if (V != -1 && V != -1 && T != -1 && pos-name == namelen) { as in attached patch. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-18 10:19 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as NEWS 1.1368 unicodedata.c 2.35 NEWS 1.1193.2.100 unicodedata.c 2.32.2.1 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-03 02:36 Message: Logged In: YES user_id=80475 Martin, I believe this is your code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1213831&group_id=5470 From noreply at sourceforge.net Sun Sep 18 10:46:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Sep 2005 01:46:14 -0700 Subject: [Patches] [ python-Patches-1268314 ] Cache lines in StreamReader.readlines Message-ID: Patches item #1268314, was opened at 2005-08-24 16:13 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1268314&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Martin v. L?wis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Cache lines in StreamReader.readlines Initial Comment: Currently, the splitlines result is discarded, and only the first line is used. Then, when another line is requested, the rest string is split again. With this patch, the splitlines result is preserved if it has more than two lines, and subsequent .readline calls get their results from self.linebuffer. Data is either in self.linebuffer or self.charbuffer; read() converts the linebuffer back to a charbuffer in case somebody mixes .read and .readline calls. On a file with 104 lines (103 of them being "pass") and 542 bytes, the number of _IsLinebreak calls went down from 6770 to 550 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-09-18 10:46 Message: Logged In: YES user_id=21627 Yes, I just committed it as codecs.py 1.49 NEWS 1.1369 codecs.py 1.35.2.11 NEWS 1.1193.2.101 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-09-02 20:55 Message: Logged In: YES user_id=89016 Is there any change that this patch gets into 2.4.2? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1268314&group_id=5470 From noreply at sourceforge.net Tue Sep 20 09:05:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Sep 2005 00:05:21 -0700 Subject: [Patches] [ python-Patches-1166938 ] locale.getdefaultencoding: LANGUAGE not correctly parsed Message-ID: Patches item #1166938, was opened at 2005-03-20 13:57 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166938&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: locale.getdefaultencoding: LANGUAGE not correctly parsed Initial Comment: According to gettext(3), "LANGUAGE is assumed to contain a colon separated list of locale names.". Fix it by taking the string up to the first colon as localename. ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2005-09-20 09:05 Message: Logged In: YES user_id=60903 checked in as Lib/locale.py: 1.32 (HEAD) Lib/locale.py: 1.28.4.2 (2.4 branch) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166938&group_id=5470 From noreply at sourceforge.net Tue Sep 20 09:06:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Sep 2005 00:06:32 -0700 Subject: [Patches] [ python-Patches-1166948 ] locale.getdefaultencoding: precedence of LANGUAGE / LANG Message-ID: Patches item #1166948, was opened at 2005-03-20 14:11 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166948&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: locale.getdefaultencoding: precedence of LANGUAGE / LANG Initial Comment: locale.getdefaultencoding checks first LANGUAGE, then the LC_* and LANG variables. Assume LANGUAGE is set to en:de, and LANG to en_US.utf-8, then getdefaultencoding returns the wrong encoding (ISO8859-1). AFAIK, LANGUAGE is specific to gettext (GNU extension), and IMO should not interfer with getting the correct encoding. This patch uses LANGUAGE as the choice with the lowest priority, so the other variables to determine the locale and encoding take precedence (LC_ALL, LC_CTYPE, LANG). There's another (minor) bug in the implementation: LANGUAGE is honoured even if the default locale is "C". ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2005-09-20 09:06 Message: Logged In: YES user_id=60903 checked in as Lib/locale.py: 1.32 (HEAD) Lib/locale.py: 1.28.4.2 (2.4 branch) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 19:04 Message: Logged In: YES user_id=1188172 This file is one big patch for #1166938, #1166948 and #1166957. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166948&group_id=5470 From noreply at sourceforge.net Tue Sep 20 09:07:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Sep 2005 00:07:34 -0700 Subject: [Patches] [ python-Patches-1166957 ] locale: 'utf' is not a known encoding Message-ID: Patches item #1166957, was opened at 2005-03-20 14:32 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166957&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: locale: 'utf' is not a known encoding Initial Comment: checked with glibc-2.3.2 on a Debian/sarge system. The locale_alias and the encoding_alias tables map the encoding from utf-8, utf8 to utf, which is not a valid encoding, at least on this system. LANG=de_DE.utf-8 python -c 'import locale; locale.resetlocale()' Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 391, in resetlocale _setlocale(category, _build_localename(getdefaultlocale())) locale.Error: unsupported locale setting ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2005-09-20 09:07 Message: Logged In: YES user_id=60903 already fixed on HEAD, rejected for the branch ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 19:04 Message: Logged In: YES user_id=1188172 This file is one big patch for #1166938, #1166948 and #1166957. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166957&group_id=5470 From noreply at sourceforge.net Tue Sep 20 18:29:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Sep 2005 09:29:32 -0700 Subject: [Patches] [ python-Patches-1293788 ] python.sty correction - verbatim environment Message-ID: Patches item #1293788, was opened at 2005-09-17 08:50 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1293788&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wojciech Smigaj (smigaj) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: python.sty correction - verbatim environment Initial Comment: This patch alters the way the verbatim environment is customized in the python.sty package. The old way -- essentially redefining the environment -- made the verbatim text be surrounded by an excessive, and somewhat irregular, amount of space. To get rid of it I propose to use the dedicated \every at verbatim hook and \verbatim at font commands. As a result we get code: - typeset in \small typeface, - separated from the preceding and following text by exactly \parskip (the amount of space separating normal paragraphs), - indented by \leftmargini -- the indent consistent with that used e.g. in descriptions. The code isn't enclosed in a minipage any more, as I can't see any reason for it now. Consequently, page breaking inside verbatim text is now permitted (which I consider a good thing, since listings may be lengthy). As a minor trouble, the alltt package defining the environment of the same name does not use the \every at verbatim hook. However, since the code is rather short, I propose to include the modified definition in the python.sty package itself. A test case: compare how the code included into "Documenting Python" (doc.tex) looks when latexed with the original and modified versions of python.sty. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1293788&group_id=5470 From noreply at sourceforge.net Tue Sep 20 18:30:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Sep 2005 09:30:23 -0700 Subject: [Patches] [ python-Patches-1293790 ] python.sty: \py@sigline correction Message-ID: Patches item #1293790, was opened at 2005-09-17 08:54 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1293790&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wojciech Smigaj (smigaj) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: python.sty: \py at sigline correction Initial Comment: This patch corrects the following bug: the last line of multiline headings created with environments like classdesc, methoddesc... clash into the following text. The source of this problem is typesetting the "parameter" part of the heading inside a \parbox[t] (parbox with its first ("top") line aligned with the surrounding text). As a consequence, when the parameter list takes multiple lines, all lines beneath the first add up to the *depth* (not the *height*) of the parbox. This causes TeX to treat the box as a very long "descender", and place only \lineskip=1pt between the bottom of the box and the following line. The proposed solution is to shape the paragraph in a "natural" way, using the \hangafter and \hangindent macros instead of the \parbox command. Additionally, inclusion of the \raggedright macro makes the argument list left-justified, thus preventing excessive stretching of interword spaces and hyphenation of parameter names, which doesn't look good in most cases. A test case follows (text taken from the PyX package manual). Compare the space between both headings when processed with the original and modified versions of python.sty. \documentclass{manual} \begin{document} some text\dots \begin{classdesc}{histogram}{lineattrs=[], steps=0, fromvalue=0, % {{{ frompathattrs=[], fillable=0, autohistogramaxisindex=0, autohistogrampointpos=0.5, epsilon=1e-10} This class is a style to plot histograms. \var{lineattrs} is merged with \code{defaultlineattrs} which is \code{[deco.stroked]}. When \var{steps} is set, the histrogram is plotted as steps instead of the default being a boxed histogram. \var{fromvalue} is the baseline value of the histogram. When set to \code{None}, the histogram will start at the baseline. When fromvalue is set, \var{frompathattrs} are the stroke attributes used to show the histogram baseline path. etc\dots \end{classdesc} \begin{classdesc}{barpos}{fromvalue=None, frompathattrs=[], epsilon=1e-10} % {{{ This class is a hidden style providing position information in a bar graph. Those graphs need to contain a specialized axis, namely a bar axis. The data column for this bar axis is named \code{Xname} where \code{X} is an axis name. In the other graph dimension the data column name must be equal to an axis name. To plot several bars in a single graph side by side, you need to have a nested bar axis and provide a tuple as data for nested bar axis. \end{classdesc} \end{document} ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1293790&group_id=5470 From noreply at sourceforge.net Wed Sep 21 01:25:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Sep 2005 16:25:35 -0700 Subject: [Patches] [ python-Patches-1297028 ] cjkcodecs does not initialize type pointer Message-ID: Patches item #1297028, was opened at 2005-09-20 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=1297028&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Eric Huss (ehuss) Assigned to: Nobody/Anonymous (nobody) Summary: cjkcodecs does not initialize type pointer Initial Comment: The cjkcodecs code does not initialize the ob_type pointer for the 3 type objects it defines. The following code will illustrate a segmentation fault: >>> import _codecs_cn >>> c = _codecs_cn.getcodec('gb2312') >>> type(c) Segmentation fault (core dumped) I have attached a patch which should solve the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1297028&group_id=5470 From noreply at sourceforge.net Wed Sep 21 08:46:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Sep 2005 23:46:27 -0700 Subject: [Patches] [ python-Patches-1297028 ] cjkcodecs does not initialize type pointer Message-ID: Patches item #1297028, was opened at 2005-09-20 16:25 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1297028&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None >Priority: 9 Submitted By: Eric Huss (ehuss) >Assigned to: Anthony Baxter (anthonybaxter) Summary: cjkcodecs does not initialize type pointer Initial Comment: The cjkcodecs code does not initialize the ob_type pointer for the 3 type objects it defines. The following code will illustrate a segmentation fault: >>> import _codecs_cn >>> c = _codecs_cn.getcodec('gb2312') >>> type(c) Segmentation fault (core dumped) I have attached a patch which should solve the problem. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-20 23:46 Message: Logged In: YES user_id=33168 Thanks! Checked in as: * Misc/NEWS 1.1374 * Modules/cjkcodecs/multibytecodec.c 1.4 This needs to be backported. Anthony is the branch still frozen? Feel free to backport this. I tried to create a test, but it didn't crash. If someone can write a test that crashes when running under regrtest.py, that would be great. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1297028&group_id=5470 From noreply at sourceforge.net Wed Sep 21 08:57:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Sep 2005 23:57:21 -0700 Subject: [Patches] [ python-Patches-1297028 ] cjkcodecs does not initialize type pointer Message-ID: Patches item #1297028, was opened at 2005-09-21 09:25 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1297028&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 9 Submitted By: Eric Huss (ehuss) Assigned to: Anthony Baxter (anthonybaxter) Summary: cjkcodecs does not initialize type pointer Initial Comment: The cjkcodecs code does not initialize the ob_type pointer for the 3 type objects it defines. The following code will illustrate a segmentation fault: >>> import _codecs_cn >>> c = _codecs_cn.getcodec('gb2312') >>> type(c) Segmentation fault (core dumped) I have attached a patch which should solve the problem. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2005-09-21 16:57 Message: Logged In: YES user_id=29957 Yes, branch is still frozen. I'll check this in once 2.4.2c1 is out (before 2.4.2 final). I can't get a test case to fail (rather than just segfault). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-21 16:46 Message: Logged In: YES user_id=33168 Thanks! Checked in as: * Misc/NEWS 1.1374 * Modules/cjkcodecs/multibytecodec.c 1.4 This needs to be backported. Anthony is the branch still frozen? Feel free to backport this. I tried to create a test, but it didn't crash. If someone can write a test that crashes when running under regrtest.py, that would be great. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1297028&group_id=5470 From noreply at sourceforge.net Wed Sep 21 17:18:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Sep 2005 08:18:22 -0700 Subject: [Patches] [ python-Patches-1212837 ] Improved profiler Message-ID: Patches item #1212837, was opened at 2005-06-01 18:05 Message generated for change (Comment added) made by lcreighton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212837&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Brett Rosen (bdrosen) Assigned to: Nobody/Anonymous (nobody) Summary: Improved profiler Initial Comment: I tried using both hotshot and the old python profiler and found them both to be inadequate. The old python profiler seems to give accurate results for timing, but is slow enough that it adds significant overhead to what it is measuing (approximately 10 times). Furthermore, it has no ability to give detailed stats about children. (how much of the cumulative time was taken up by each function called by a function) The hotshot profiler is much faster (profiling) adding only 30% overhead. However, it is extremely slow to load the results from the log file. It does not currently support detailed child stats, although I imagine that it could be made to do so using the information in the log file. The biggest problem with it, is that the time results seem to be highly inaccurate. (doesn't correspond to actual seconds, although they seem to be proportionally wrong) To address these shortcomings, I wrote a new profiling module. It adds about the same overhead (30%) as hotshot, but is much faster in retrieving results. It supports detailed child stats and gives accurate timing information in milliseconds. The accompanying .py module could use additional work though - because of the child stats, I was not able to reuse the stats module like hotshot does. I've included a simple test script that runs pystone for all 3 profilers (and without the profiler) to give a better idea of the differences. I've also included a dump of the output of the script running under Windows XP with python 2.4.1 ---------------------------------------------------------------------- Comment By: Laura Creighton (lcreighton) Date: 2005-09-21 17:18 Message: Logged In: YES user_id=376262 We've been using Hotshot at Strakt for a while now. We tried your patch and it worked precisely as advertised. Thank you for writing it. Laura Creighton ---------------------------------------------------------------------- Comment By: Brett Rosen (bdrosen) Date: 2005-09-08 17:25 Message: Logged In: YES user_id=1289249 I've enclosed an updated version of profile.c that fixes a problem in the original patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212837&group_id=5470 From noreply at sourceforge.net Wed Sep 21 17:57:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Sep 2005 08:57:09 -0700 Subject: [Patches] [ python-Patches-1212837 ] Improved profiler Message-ID: Patches item #1212837, was opened at 2005-06-01 16:05 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212837&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Brett Rosen (bdrosen) Assigned to: Nobody/Anonymous (nobody) Summary: Improved profiler Initial Comment: I tried using both hotshot and the old python profiler and found them both to be inadequate. The old python profiler seems to give accurate results for timing, but is slow enough that it adds significant overhead to what it is measuing (approximately 10 times). Furthermore, it has no ability to give detailed stats about children. (how much of the cumulative time was taken up by each function called by a function) The hotshot profiler is much faster (profiling) adding only 30% overhead. However, it is extremely slow to load the results from the log file. It does not currently support detailed child stats, although I imagine that it could be made to do so using the information in the log file. The biggest problem with it, is that the time results seem to be highly inaccurate. (doesn't correspond to actual seconds, although they seem to be proportionally wrong) To address these shortcomings, I wrote a new profiling module. It adds about the same overhead (30%) as hotshot, but is much faster in retrieving results. It supports detailed child stats and gives accurate timing information in milliseconds. The accompanying .py module could use additional work though - because of the child stats, I was not able to reuse the stats module like hotshot does. I've included a simple test script that runs pystone for all 3 profilers (and without the profiler) to give a better idea of the differences. I've also included a dump of the output of the script running under Windows XP with python 2.4.1 ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-09-21 15:57 Message: Logged In: YES user_id=4771 Thanks for your work. The two existing profilers are definitely not satisfactory in my opinion too (I am also encountering crashes with profile.py). There are a number of details that should be addressed before your profiler can be a replacement for the existing ones, e.g. providing simple entry points and documentations, and having the C code reviewed. I am willing to help with all this. I hope you won't mind that I have checked your source code in a public Subversion repository, where I am working a bit on it together with Michael Hudson. (Obviously, the goal is to have the code eventually in the CPython CVS.) http://codespeak.net/svn/user/arigo/hack/misc/lsprof/ ---------------------------------------------------------------------- Comment By: Laura Creighton (lcreighton) Date: 2005-09-21 15:18 Message: Logged In: YES user_id=376262 We've been using Hotshot at Strakt for a while now. We tried your patch and it worked precisely as advertised. Thank you for writing it. Laura Creighton ---------------------------------------------------------------------- Comment By: Brett Rosen (bdrosen) Date: 2005-09-08 15:25 Message: Logged In: YES user_id=1289249 I've enclosed an updated version of profile.c that fixes a problem in the original patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212837&group_id=5470 From noreply at sourceforge.net Wed Sep 21 19:43:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Sep 2005 10:43:41 -0700 Subject: [Patches] [ python-Patches-1212837 ] Improved profiler Message-ID: Patches item #1212837, was opened at 2005-06-01 12:05 Message generated for change (Comment added) made by bdrosen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212837&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Brett Rosen (bdrosen) Assigned to: Nobody/Anonymous (nobody) Summary: Improved profiler Initial Comment: I tried using both hotshot and the old python profiler and found them both to be inadequate. The old python profiler seems to give accurate results for timing, but is slow enough that it adds significant overhead to what it is measuing (approximately 10 times). Furthermore, it has no ability to give detailed stats about children. (how much of the cumulative time was taken up by each function called by a function) The hotshot profiler is much faster (profiling) adding only 30% overhead. However, it is extremely slow to load the results from the log file. It does not currently support detailed child stats, although I imagine that it could be made to do so using the information in the log file. The biggest problem with it, is that the time results seem to be highly inaccurate. (doesn't correspond to actual seconds, although they seem to be proportionally wrong) To address these shortcomings, I wrote a new profiling module. It adds about the same overhead (30%) as hotshot, but is much faster in retrieving results. It supports detailed child stats and gives accurate timing information in milliseconds. The accompanying .py module could use additional work though - because of the child stats, I was not able to reuse the stats module like hotshot does. I've included a simple test script that runs pystone for all 3 profilers (and without the profiler) to give a better idea of the differences. I've also included a dump of the output of the script running under Windows XP with python 2.4.1 ---------------------------------------------------------------------- >Comment By: Brett Rosen (bdrosen) Date: 2005-09-21 13:43 Message: Logged In: YES user_id=1289249 I welcome any additional changes (and help making those changes) that would improve the patch and help get it ready for inclusion in CPython. The main detail that I knew that would need to be addressed was lspstats.py. I didn't spend a lot of time working on it because I generally use a wx TreeListCtrl object to view/sort the results. What other details need to be addressed? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-21 11:57 Message: Logged In: YES user_id=4771 Thanks for your work. The two existing profilers are definitely not satisfactory in my opinion too (I am also encountering crashes with profile.py). There are a number of details that should be addressed before your profiler can be a replacement for the existing ones, e.g. providing simple entry points and documentations, and having the C code reviewed. I am willing to help with all this. I hope you won't mind that I have checked your source code in a public Subversion repository, where I am working a bit on it together with Michael Hudson. (Obviously, the goal is to have the code eventually in the CPython CVS.) http://codespeak.net/svn/user/arigo/hack/misc/lsprof/ ---------------------------------------------------------------------- Comment By: Laura Creighton (lcreighton) Date: 2005-09-21 11:18 Message: Logged In: YES user_id=376262 We've been using Hotshot at Strakt for a while now. We tried your patch and it worked precisely as advertised. Thank you for writing it. Laura Creighton ---------------------------------------------------------------------- Comment By: Brett Rosen (bdrosen) Date: 2005-09-08 11:25 Message: Logged In: YES user_id=1289249 I've enclosed an updated version of profile.c that fixes a problem in the original patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212837&group_id=5470 From noreply at sourceforge.net Wed Sep 21 20:35:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Sep 2005 11:35:04 -0700 Subject: [Patches] [ python-Patches-1212837 ] Improved profiler Message-ID: Patches item #1212837, was opened at 2005-06-01 17:05 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212837&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Brett Rosen (bdrosen) Assigned to: Nobody/Anonymous (nobody) Summary: Improved profiler Initial Comment: I tried using both hotshot and the old python profiler and found them both to be inadequate. The old python profiler seems to give accurate results for timing, but is slow enough that it adds significant overhead to what it is measuing (approximately 10 times). Furthermore, it has no ability to give detailed stats about children. (how much of the cumulative time was taken up by each function called by a function) The hotshot profiler is much faster (profiling) adding only 30% overhead. However, it is extremely slow to load the results from the log file. It does not currently support detailed child stats, although I imagine that it could be made to do so using the information in the log file. The biggest problem with it, is that the time results seem to be highly inaccurate. (doesn't correspond to actual seconds, although they seem to be proportionally wrong) To address these shortcomings, I wrote a new profiling module. It adds about the same overhead (30%) as hotshot, but is much faster in retrieving results. It supports detailed child stats and gives accurate timing information in milliseconds. The accompanying .py module could use additional work though - because of the child stats, I was not able to reuse the stats module like hotshot does. I've included a simple test script that runs pystone for all 3 profilers (and without the profiler) to give a better idea of the differences. I've also included a dump of the output of the script running under Windows XP with python 2.4.1 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-09-21 19:35 Message: Logged In: YES user_id=6656 Well, you can see what we've done to your baby: http://codespeak.net/svn/user/arigo/hack/misc/lsprof/profile.c Mostly it's just C style conformance so far, though we've fixed a couple of little bugs too. ---------------------------------------------------------------------- Comment By: Brett Rosen (bdrosen) Date: 2005-09-21 18:43 Message: Logged In: YES user_id=1289249 I welcome any additional changes (and help making those changes) that would improve the patch and help get it ready for inclusion in CPython. The main detail that I knew that would need to be addressed was lspstats.py. I didn't spend a lot of time working on it because I generally use a wx TreeListCtrl object to view/sort the results. What other details need to be addressed? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-21 16:57 Message: Logged In: YES user_id=4771 Thanks for your work. The two existing profilers are definitely not satisfactory in my opinion too (I am also encountering crashes with profile.py). There are a number of details that should be addressed before your profiler can be a replacement for the existing ones, e.g. providing simple entry points and documentations, and having the C code reviewed. I am willing to help with all this. I hope you won't mind that I have checked your source code in a public Subversion repository, where I am working a bit on it together with Michael Hudson. (Obviously, the goal is to have the code eventually in the CPython CVS.) http://codespeak.net/svn/user/arigo/hack/misc/lsprof/ ---------------------------------------------------------------------- Comment By: Laura Creighton (lcreighton) Date: 2005-09-21 16:18 Message: Logged In: YES user_id=376262 We've been using Hotshot at Strakt for a while now. We tried your patch and it worked precisely as advertised. Thank you for writing it. Laura Creighton ---------------------------------------------------------------------- Comment By: Brett Rosen (bdrosen) Date: 2005-09-08 16:25 Message: Logged In: YES user_id=1289249 I've enclosed an updated version of profile.c that fixes a problem in the original patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212837&group_id=5470 From noreply at sourceforge.net Thu Sep 22 05:35:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Sep 2005 20:35:51 -0700 Subject: [Patches] [ python-Patches-754022 ] Greatly enhanced webbrowser.py Message-ID: Patches item #754022, was opened at 2003-06-14 00:24 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Oleg Broytmann (phd) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Greatly enhanced webbrowser.py Initial Comment: The patch enhances webbrowser.py. First, all calls to os.system return result code, and the inverse of the code (it is ok/fail status) passed through all higher-level routines up to top-level call to open(url). This allows to check if a browser was really started. Second, the very open() modified so it is now trying to run all registered browsers in order until a browser returns 1. Third, the file can be used as a program: webbrowser.py url. Optional parameters -n allows to open the url in a new window. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-09-22 12:35 Message: Logged In: YES user_id=671362 Minor nit. 11.1.1 Browser Controller Objects from the description of open method:: > If new is true, a new browser window is opened if possible. Now "new" can be 0, 1 or 2. This part also needs an update. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-09-16 16:28 Message: Logged In: YES user_id=4799 Arguable (especially compared with smtpd.py), but I am not goint to argue. Please apply the patch and let us see what other people think and say. It seems there are enough users... ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-16 15:32 Message: Logged In: YES user_id=1188172 Granted, but you will concur that starting a webbrowser isn't something that the command line user normally wants to do via a Python script. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-09-16 06:52 Message: Logged In: YES user_id=4799 >From setup.py: scripts = ['Tools/scripts/pydoc', 'Tools/scripts/idle', 'Lib/smtpd.py'] See, Python installs 3 scripts into /usr/{local/}bin/ - pydoc, idle and smtpd.py. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-16 05:48 Message: Logged In: YES user_id=1188172 No other module that can be used standalone delivers such a script. There's also the question where to install it, etc. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-09-16 05:18 Message: Logged In: YES user_id=4799 In the main(): opts, args = getopt.getopt(sys.argv[1:], 'ntd') You can remove 'd' as you've dropeed debugging prints. Are you going to drop standalone webbrowser script? Is "python -m webbrowser" enough? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-16 04:49 Message: Logged In: YES user_id=1188172 Ah, thanks. I had already corrected #1, but didn't look closely enough for #2. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-09-16 02:26 Message: Logged In: YES user_id=671362 Let me point out two problems: o NameError if remote_background: cmd += ' &' => if self.remote_background: # add "self." cmd += ' &' o copy and paste mistake? \lineiii{'mozilla'}{\class{Mozilla('mozilla')}}{} \lineiii{'firefox'}{\class{Mozilla('mozilla')}}{} => \lineiii{'mozilla'}{\class{Mozilla('mozilla')}}{} \lineiii{'firefox'}{\class{Mozilla('firefox')}}{} ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 17:07 Message: Logged In: YES user_id=1188172 Adding new patch (webbrowser.diff), enhanced with other patches and bugfixes here on SF. Also updated the docs with changed/added notes. Please review, I'll apply this for 2.5. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-02 01:33 Message: Logged In: YES user_id=1188172 I have reviewed this one too, and I really recommend to apply it for 2.5. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-30 20:02 Message: Logged In: YES user_id=4799 Added Opera controller to the doc. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-30 20:01 Message: Logged In: YES user_id=4799 Added remote functionality for Opera on Unix. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-29 17:50 Message: Logged In: YES user_id=4799 Updated documention patch - added a section about webbrowser script and its command-line options and arguments. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-29 17:48 Message: Logged In: YES user_id=4799 Changed _isexecutable() on w32 to test for executable extensions (.exe, bat) . Tested on Linux with Mozilla/links/elinks; on w32 with Mozilla/Opera/Firefox. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-29 06:25 Message: Logged In: YES user_id=9057 I have revised: libwebbrowser.tex.patch and webbrowser.py.patch. They are Ok, I recommend to apply both. Outstanding work. However, I would withdraw the webbrowser wrapper script, since the same functionality can be accomplished with: python -m webbrowser http://www.python.org ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-28 23:21 Message: Logged In: YES user_id=4799 Patch for documentation. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-28 23:19 Message: Logged In: YES user_id=4799 Minor bugfix. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 22:30 Message: Logged In: YES user_id=4799 Do not report error if the browser doesn't support tabs - just open the URL in a new window. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 22:14 Message: Logged In: YES user_id=4799 I've reworked the patch once more. I moved some common functionality into the UnixBrowser class and added two new features - Elinks launcher class (elinks supports remote commands in a manner very similar to Mozilla) and new-tab functionality for browsers that support tabbed browsing (Mozilla and elinks); a user can now run "webbrowser -t URL" to open the URL a new tab. All classes in the module are now new-style classes (except for the Error class). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 06:18 Message: Logged In: YES user_id=4799 Uploading webbrowser wrapper script. Put it into Tools/scripts directory, and add to the end of setup.py. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 06:17 Message: Logged In: YES user_id=4799 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 06:14 Message: Logged In: YES user_id=4799 I've moved script code to main() function. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-24 04:25 Message: Logged In: YES user_id=9057 I have reviewed this patch in 2005-03-23 and recommend it to be applied ! Oleg have made the comments below to Python-dev, and those must be taken into consideration while applying this patch. http://python.org/sf/728278 Close with resolution "partially applied, partially rejected". http://python.org/sf/754022 Review and apply! ;) http://python.org/sf/1166780 Close with resolution "applied". (Though it was not applied in exactly that form...) http://python.org/sf/1077979 Close with resolution "applied long ago". http://python.org/sf/1144816 Close with resolution "duplicate of 1077979". ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 03:06 Message: Logged In: YES user_id=4799 I've consolidated patches 728278, 754022, 954628, 1166780 into this single patch. Some parts of those patches were applied, some rejected, many things changed. I also added elinks support - currently it is very similar to links. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-12-07 20:23 Message: Logged In: YES user_id=4799 Applied the patch from http://python.org/sf/1077979. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-20 15:11 Message: Logged In: YES user_id=80475 Too late for Py2.4. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-10-07 16:48 Message: Logged In: YES user_id=4799 And don't forget to make it executable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 From noreply at sourceforge.net Thu Sep 22 09:45:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 00:45:01 -0700 Subject: [Patches] [ python-Patches-1298449 ] "Fatal Python error" from cStringIO's writelines Message-ID: Patches item #1298449, was opened at 2005-09-22 17:45 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=1298449&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Bennetts (spiv) Assigned to: Nobody/Anonymous (nobody) Summary: "Fatal Python error" from cStringIO's writelines Initial Comment: This patch fixes a bug demonstrated by the following code: def i(): yield "line1" raise KeyboardInterrupt() import cStringIO sio = cStringIO.StringIO() sio.writelines(i()) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298449&group_id=5470 From noreply at sourceforge.net Thu Sep 22 09:45:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 00:45:55 -0700 Subject: [Patches] [ python-Patches-1098749 ] Single-line option to pygettext.py Message-ID: Patches item #1098749, was opened at 2005-01-08 19:01 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1098749&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Demos and tools Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Martin Blais (blais) Assigned to: Nobody/Anonymous (nobody) Summary: Single-line option to pygettext.py Initial Comment: i added an option that make pygettext consider certain multi-line strings as single-line strings. If you're using an editor like kbabel, it's nice, you don't see the newlines. This comes really handy for strings to be used as HTML, where line breaks don't matter (and I'm sure for many other uses). You can select which keywords trigger this special extraction. All the other gettext tools work normally. Default behaviour does not change. I use it something like this: POTCMD = pygettext.py --verbose --extract-all --no-default-keywords --keyword-single=_ --keyword-single=N_ --keyword=__ ... pot: $(POTCMD) -d $(PROJECT) -p $(dir $@) $(PYFILES) cheers, ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-09-22 00:45 Message: Logged In: NO Code review.... 1. You have a few lines like : s = '%s' % ' '.join(newlines) Surely that is the same as just: s = ' '.join(newlines) 2. You use the single line option value as part of the key in __messages dictionary. That means that the output will have duplicate msgid values if your source contains both _normal('hello world') and _single('hello world'). Other GNU gettext tools assume that there will not be duplicates. (assuming --keyword=_normal --keyword-single=_single) 3. You also get duplicates for: _single("""this is one line and this is another""") and _single("""this is one line and this is another""") because normalization is performed just before output. Unless Im missing something, I think the right solution to these two problems is to normalize before calling __addentry, and leave the key to __messages as it was originally. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1098749&group_id=5470 From noreply at sourceforge.net Thu Sep 22 10:40:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 01:40:32 -0700 Subject: [Patches] [ python-Patches-1298499 ] Unchecked return value in cStringIO Message-ID: Patches item #1298499, was opened at 2005-09-22 18: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=1298499&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Bennetts (spiv) Assigned to: Nobody/Anonymous (nobody) Summary: Unchecked return value in cStringIO Initial Comment: There's a PyList_Append call in IO_readlines that doesn't have its return value checked. This patch fixes it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298499&group_id=5470 From noreply at sourceforge.net Thu Sep 22 11:03:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 02:03:35 -0700 Subject: [Patches] [ python-Patches-1298499 ] Unchecked return value in cStringIO Message-ID: Patches item #1298499, was opened at 2005-09-22 18:40 Message generated for change (Comment added) made by spiv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298499&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Bennetts (spiv) Assigned to: Nobody/Anonymous (nobody) Summary: Unchecked return value in cStringIO Initial Comment: There's a PyList_Append call in IO_readlines that doesn't have its return value checked. This patch fixes it. ---------------------------------------------------------------------- >Comment By: Andrew Bennetts (spiv) Date: 2005-09-22 19:03 Message: Logged In: YES user_id=50945 Sorry, that patch was a brainfart. Here's a saner one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298499&group_id=5470 From noreply at sourceforge.net Thu Sep 22 11:17:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 02:17:33 -0700 Subject: [Patches] [ python-Patches-1298499 ] Unchecked return value in cStringIO Message-ID: Patches item #1298499, was opened at 2005-09-22 03:40 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298499&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Bennetts (spiv) >Assigned to: Raymond Hettinger (rhettinger) Summary: Unchecked return value in cStringIO Initial Comment: There's a PyList_Append call in IO_readlines that doesn't have its return value checked. This patch fixes it. ---------------------------------------------------------------------- Comment By: Andrew Bennetts (spiv) Date: 2005-09-22 04:03 Message: Logged In: YES user_id=50945 Sorry, that patch was a brainfart. Here's a saner one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298499&group_id=5470 From noreply at sourceforge.net Thu Sep 22 11:20:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 02:20:22 -0700 Subject: [Patches] [ python-Patches-1298499 ] Unchecked return value in cStringIO Message-ID: Patches item #1298499, was opened at 2005-09-22 09:40 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298499&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Andrew Bennetts (spiv) >Assigned to: Michael Hudson (mwh) Summary: Unchecked return value in cStringIO Initial Comment: There's a PyList_Append call in IO_readlines that doesn't have its return value checked. This patch fixes it. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-09-22 10:20 Message: Logged In: YES user_id=6656 OK, this is checked in (along with your other patch) as: Lib/test/test_StringIO.py revision 1.20 Misc/ACKS revision 1.296 Misc/NEWS revsision 1.1375 Modules/cStringIO.c revision 2.50 Thanks! ---------------------------------------------------------------------- Comment By: Andrew Bennetts (spiv) Date: 2005-09-22 10:03 Message: Logged In: YES user_id=50945 Sorry, that patch was a brainfart. Here's a saner one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298499&group_id=5470 From noreply at sourceforge.net Thu Sep 22 11:20:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 02:20:44 -0700 Subject: [Patches] [ python-Patches-1298449 ] "Fatal Python error" from cStringIO's writelines Message-ID: Patches item #1298449, was opened at 2005-09-22 08:45 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298449&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Andrew Bennetts (spiv) >Assigned to: Michael Hudson (mwh) Summary: "Fatal Python error" from cStringIO's writelines Initial Comment: This patch fixes a bug demonstrated by the following code: def i(): yield "line1" raise KeyboardInterrupt() import cStringIO sio = cStringIO.StringIO() sio.writelines(i()) ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-09-22 10:20 Message: Logged In: YES user_id=6656 OK, this is checked in (along with your other patch) as: Lib/test/test_StringIO.py revision 1.20 Misc/ACKS revision 1.296 Misc/NEWS revsision 1.1375 Modules/cStringIO.c revision 2.50 Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298449&group_id=5470 From noreply at sourceforge.net Thu Sep 22 15:16:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 06:16:19 -0700 Subject: [Patches] [ python-Patches-1203393 ] Patch for [ 1163563 ] Sub threads execute in restricted mode Message-ID: Patches item #1203393, was opened at 2005-05-17 10:39 Message generated for change (Settings changed) made by yetanothermax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1203393&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 >Status: Pending Resolution: None Priority: 5 Submitted By: anothermax (yetanothermax) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for [ 1163563 ] Sub threads execute in restricted mode Initial Comment: The thread module delivered with versions of python greater than 2.3.4 is not compatible with the use of sub interpreters, this causes problems with the jep product and seems also to be a problem for mod_python. This has been raised as a bug "[ 1163563 ] Sub threads execute in restricted mode" (http://sourceforge.net/tracker/index.php? func=detail&aid=1163563&group_id=5470&atid=105470) please see this bug report for further details. The problem seems to be the with use of PyGIL_StateXXX functions in the module. This patch replaces these calls with those used in pre- 2.3.5 threadmodule.c. A file called threadtest.c is attached to the bug report which demonstrates the problem. I'm using Python version 2.4.1 on Windows XP SP1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1203393&group_id=5470 From noreply at sourceforge.net Thu Sep 22 17:12:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 08:12:43 -0700 Subject: [Patches] [ python-Patches-1298835 ] vendor-packages directory. Message-ID: Patches item #1298835, was opened at 2005-09-22 08: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=1298835&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Rich Burridge (richburridge) Assigned to: Nobody/Anonymous (nobody) Summary: vendor-packages directory. Initial Comment: Python needs a .../python2.x.y/vendor-packages directory for vendor supplied Python files. See: http://mail.python.org/pipermail/python-list/2005-September/300029.html for the full reasoning behind this request. I also approached Guido w.r.t. this. Here's his reply. Subject: Re: Python vendor-packages directory in a future Python release? Date: Tue, 20 Sep 2005 19:48:40 -0700 From: Guido van Rossum Reply-To: Guido van Rossum To: Rich Burridge References: <4330C108.4030100 at sun.com> I think that's a reasonable request. (In the mean time, I think that using site-packages is fine as an interim solution.) I suggest that you use the SourceForge patch manager for the Python project to upload your patch, and then post to python-dev. You may be asked to review 5 other patches in order to have someone look at your favorite patch. --Guido ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298835&group_id=5470 From noreply at sourceforge.net Thu Sep 22 16:54:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 07:54:06 -0700 Subject: [Patches] [ python-Patches-1298813 ] sysmodule.c: realpath() is unsafe Message-ID: Patches item #1298813, was opened at 2005-09-22 10:54 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=1298813&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Mihai Ibanescu (misa) Assigned to: Nobody/Anonymous (nobody) Summary: sysmodule.c: realpath() is unsafe Initial Comment: realpath() will dereference all symlinks and resolve references to /./ and /../ (and so on). realpath accepts a source buffer and a destination buffer to copy the resolved path into. On certain systems PATH_MAX can be of arbitrary size, while the buffer passed in would be of a limiited size. There is no way to specify how long your "resolved" buffer is, therefore it is possible for one to overflow it. According to the man page: BUGS Never use this function. It is broken by design since it is impossible to determine a suitable size for the output buffer. According to POSIX a buffer of size PATH_MAX suffices, but PATH_MAX need not be a defined constant, and may have to be obtained using pathconf(). And asking pathconf() does not really help, since on the one hand POSIX warns that the result of pathconf() may be huge and unsuitable for mallocing mem- ory. And on the other hand pathconf() may return -1 to signify that PATH_MAX is not bounded. glibc has certain extensions to avoid the buffer overflow. One option is to use canonicalize_file_name(), another is to specify a NULL as the second argument to realpath() (which essentially makes it behave like canonicalize_file_name(). Relevant documentation: info libc http://www.delorie.com/gnu/docs/glibc/libc_279.html Attached is a patch to use canonicalize_file_name if available. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298813&group_id=5470 From noreply at sourceforge.net Fri Sep 23 05:23:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 20:23:17 -0700 Subject: [Patches] [ python-Patches-1299675 ] fix for distutils "upload" command Message-ID: Patches item #1299675, was opened at 2005-09-23 13:23 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=1299675&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: fix for distutils "upload" command Initial Comment: This patch fixes distutils/command/upload.py so it can talk to an improved PyPI interface. Specifically, it allows upload of a file for an un"register"ed release. Should be applied against CVS HEAD. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1299675&group_id=5470 From noreply at sourceforge.net Fri Sep 23 05:25:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 20:25:09 -0700 Subject: [Patches] [ python-Patches-1297028 ] cjkcodecs does not initialize type pointer Message-ID: Patches item #1297028, was opened at 2005-09-20 16:25 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1297028&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 9 Submitted By: Eric Huss (ehuss) Assigned to: Anthony Baxter (anthonybaxter) Summary: cjkcodecs does not initialize type pointer Initial Comment: The cjkcodecs code does not initialize the ob_type pointer for the 3 type objects it defines. The following code will illustrate a segmentation fault: >>> import _codecs_cn >>> c = _codecs_cn.getcodec('gb2312') >>> type(c) Segmentation fault (core dumped) I have attached a patch which should solve the problem. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-22 20:25 Message: Logged In: YES user_id=33168 I figured Anthony is busy enough. I checked this in since he said he would. My bad if you didn't want it in 2.4.2. Checked in as: * Misc/NEWS 1.1193.2.107 * Modules/cjkcodecs/multibytecodec.c 1.3.2.1 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2005-09-20 23:57 Message: Logged In: YES user_id=29957 Yes, branch is still frozen. I'll check this in once 2.4.2c1 is out (before 2.4.2 final). I can't get a test case to fail (rather than just segfault). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-20 23:46 Message: Logged In: YES user_id=33168 Thanks! Checked in as: * Misc/NEWS 1.1374 * Modules/cjkcodecs/multibytecodec.c 1.4 This needs to be backported. Anthony is the branch still frozen? Feel free to backport this. I tried to create a test, but it didn't crash. If someone can write a test that crashes when running under regrtest.py, that would be great. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1297028&group_id=5470 From noreply at sourceforge.net Fri Sep 23 05:29:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 20:29:11 -0700 Subject: [Patches] [ python-Patches-1297028 ] cjkcodecs does not initialize type pointer Message-ID: Patches item #1297028, was opened at 2005-09-20 16:25 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1297028&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Closed Resolution: Accepted Priority: 9 Submitted By: Eric Huss (ehuss) Assigned to: Anthony Baxter (anthonybaxter) Summary: cjkcodecs does not initialize type pointer Initial Comment: The cjkcodecs code does not initialize the ob_type pointer for the 3 type objects it defines. The following code will illustrate a segmentation fault: >>> import _codecs_cn >>> c = _codecs_cn.getcodec('gb2312') >>> type(c) Segmentation fault (core dumped) I have attached a patch which should solve the problem. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-22 20:29 Message: Logged In: YES user_id=33168 Eric, I have a question about your patch. Is there any reason you didn't change PyObject_HEAD_INIT(NULL) to PyObject_HEAD_INIT(&PyType_Type) rather than do the assignment in init? Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-22 20:25 Message: Logged In: YES user_id=33168 I figured Anthony is busy enough. I checked this in since he said he would. My bad if you didn't want it in 2.4.2. Checked in as: * Misc/NEWS 1.1193.2.107 * Modules/cjkcodecs/multibytecodec.c 1.3.2.1 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2005-09-20 23:57 Message: Logged In: YES user_id=29957 Yes, branch is still frozen. I'll check this in once 2.4.2c1 is out (before 2.4.2 final). I can't get a test case to fail (rather than just segfault). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-20 23:46 Message: Logged In: YES user_id=33168 Thanks! Checked in as: * Misc/NEWS 1.1374 * Modules/cjkcodecs/multibytecodec.c 1.4 This needs to be backported. Anthony is the branch still frozen? Feel free to backport this. I tried to create a test, but it didn't crash. If someone can write a test that crashes when running under regrtest.py, that would be great. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1297028&group_id=5470 From noreply at sourceforge.net Fri Sep 23 09:46:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Sep 2005 00:46:48 -0700 Subject: [Patches] [ python-Patches-1212837 ] Improved profiler Message-ID: Patches item #1212837, was opened at 2005-06-01 16:05 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212837&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Brett Rosen (bdrosen) Assigned to: Nobody/Anonymous (nobody) Summary: Improved profiler Initial Comment: I tried using both hotshot and the old python profiler and found them both to be inadequate. The old python profiler seems to give accurate results for timing, but is slow enough that it adds significant overhead to what it is measuing (approximately 10 times). Furthermore, it has no ability to give detailed stats about children. (how much of the cumulative time was taken up by each function called by a function) The hotshot profiler is much faster (profiling) adding only 30% overhead. However, it is extremely slow to load the results from the log file. It does not currently support detailed child stats, although I imagine that it could be made to do so using the information in the log file. The biggest problem with it, is that the time results seem to be highly inaccurate. (doesn't correspond to actual seconds, although they seem to be proportionally wrong) To address these shortcomings, I wrote a new profiling module. It adds about the same overhead (30%) as hotshot, but is much faster in retrieving results. It supports detailed child stats and gives accurate timing information in milliseconds. The accompanying .py module could use additional work though - because of the child stats, I was not able to reuse the stats module like hotshot does. I've included a simple test script that runs pystone for all 3 profilers (and without the profiler) to give a better idea of the differences. I've also included a dump of the output of the script running under Windows XP with python 2.4.1 ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-09-23 07:46 Message: Logged In: YES user_id=4771 I replaced the linked lists with some kind of auto-balacing trees; the linked lists were creating a huge overhead to profile large programs. The reason for not using plain Python dicts instead is that PyCodeObjects are not very good at being keys in dicts -- their hash computation takes ages, and we'd prefer an identity mapping anyway. The current SVN version is now the first profiler that works and gives sensible results when profiling the PyPy translation process. getstats() is now producing tuples-with-attribute-names instead of dicts (similar to os.stat()). This was mostly motivated by a lack of motivation to introduce error checking everywhere in the dict-building code, but I think it's a reasonable change. There are only a couple of places left in profile.c still missing checks for error results or out-of-memory conditions. The lsprof.py module exposes a simple but minimalistic interface. I suggest we keep and document it or a similar one, but also support -- for compatibility -- the convoluted interface of the existing profile.py/pstats.py and/or hotshot, with the option to dump the stats to a file and reload them. However I don't think it makes sense to use exactly the same format as pstats does (as far as I can guess it doesn't support per-caller information). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-09-21 18:35 Message: Logged In: YES user_id=6656 Well, you can see what we've done to your baby: http://codespeak.net/svn/user/arigo/hack/misc/lsprof/profile.c Mostly it's just C style conformance so far, though we've fixed a couple of little bugs too. ---------------------------------------------------------------------- Comment By: Brett Rosen (bdrosen) Date: 2005-09-21 17:43 Message: Logged In: YES user_id=1289249 I welcome any additional changes (and help making those changes) that would improve the patch and help get it ready for inclusion in CPython. The main detail that I knew that would need to be addressed was lspstats.py. I didn't spend a lot of time working on it because I generally use a wx TreeListCtrl object to view/sort the results. What other details need to be addressed? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-21 15:57 Message: Logged In: YES user_id=4771 Thanks for your work. The two existing profilers are definitely not satisfactory in my opinion too (I am also encountering crashes with profile.py). There are a number of details that should be addressed before your profiler can be a replacement for the existing ones, e.g. providing simple entry points and documentations, and having the C code reviewed. I am willing to help with all this. I hope you won't mind that I have checked your source code in a public Subversion repository, where I am working a bit on it together with Michael Hudson. (Obviously, the goal is to have the code eventually in the CPython CVS.) http://codespeak.net/svn/user/arigo/hack/misc/lsprof/ ---------------------------------------------------------------------- Comment By: Laura Creighton (lcreighton) Date: 2005-09-21 15:18 Message: Logged In: YES user_id=376262 We've been using Hotshot at Strakt for a while now. We tried your patch and it worked precisely as advertised. Thank you for writing it. Laura Creighton ---------------------------------------------------------------------- Comment By: Brett Rosen (bdrosen) Date: 2005-09-08 15:25 Message: Logged In: YES user_id=1289249 I've enclosed an updated version of profile.c that fixes a problem in the original patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212837&group_id=5470 From noreply at sourceforge.net Fri Sep 23 11:37:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Sep 2005 02:37:51 -0700 Subject: [Patches] [ python-Patches-1300515 ] xdrlib.py: pack_fstring() did not use null bytes for padding Message-ID: Patches item #1300515, was opened at 2005-09-23 11:37 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=1300515&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Don Quijote (dq_searchlores) Assigned to: Nobody/Anonymous (nobody) Summary: xdrlib.py: pack_fstring() did not use null bytes for padding Initial Comment: According to the documentation, null shall be used as padding byte. But, as the test below shows, instead of null, additional trailing characters of the original string are used. This is also wrong according to the related RFC 1014 (and RFC 1832). This is tested on Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 >>> import xdrlib >>> p = xdrlib.Packer() >>> p.pack_fstring(2,"abcdef") >>> p.get_buffer() 'abcd' I am expecting 'ab\0\0' This change does not have any impact on unpack_fstring(). The patch is done against the current CVS tree. The patch does not add nor change any functionality. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1300515&group_id=5470 From noreply at sourceforge.net Fri Sep 23 13:12:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Sep 2005 04:12:52 -0700 Subject: [Patches] [ python-Patches-1275079 ] Compile socket module under cygwin Message-ID: Patches item #1275079, was opened at 2005-08-28 02:41 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1275079&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: Compile socket module under cygwin Initial Comment: Currently (CVS Aug 28, 05) socket module does not compile under Cygwin. The attached patch fixes that. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2005-09-23 03:12 Message: Logged In: YES user_id=86216 This is a known Cygwin issues which will be fixed in 1.5.19: http://cygwin.com/ml/cygwin/2005-07/msg01257.html I recommend that Cygwin users temporarily patch their netinet/in.h instead of changing the Python source code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1275079&group_id=5470 From noreply at sourceforge.net Fri Sep 23 16:10:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Sep 2005 07:10:04 -0700 Subject: [Patches] [ python-Patches-754022 ] Greatly enhanced webbrowser.py Message-ID: Patches item #754022, was opened at 2003-06-13 19:24 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Oleg Broytmann (phd) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Greatly enhanced webbrowser.py Initial Comment: The patch enhances webbrowser.py. First, all calls to os.system return result code, and the inverse of the code (it is ok/fail status) passed through all higher-level routines up to top-level call to open(url). This allows to check if a browser was really started. Second, the very open() modified so it is now trying to run all registered browsers in order until a browser returns 1. Third, the file can be used as a program: webbrowser.py url. Optional parameters -n allows to open the url in a new window. ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2005-09-23 18:09 Message: Logged In: YES user_id=4799 Done. New libwebbrowser.tex.patch is about to be uploaded. Thank you! ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-09-22 07:35 Message: Logged In: YES user_id=671362 Minor nit. 11.1.1 Browser Controller Objects from the description of open method:: > If new is true, a new browser window is opened if possible. Now "new" can be 0, 1 or 2. This part also needs an update. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-09-16 11:28 Message: Logged In: YES user_id=4799 Arguable (especially compared with smtpd.py), but I am not goint to argue. Please apply the patch and let us see what other people think and say. It seems there are enough users... ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-16 10:32 Message: Logged In: YES user_id=1188172 Granted, but you will concur that starting a webbrowser isn't something that the command line user normally wants to do via a Python script. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-09-16 01:52 Message: Logged In: YES user_id=4799 >From setup.py: scripts = ['Tools/scripts/pydoc', 'Tools/scripts/idle', 'Lib/smtpd.py'] See, Python installs 3 scripts into /usr/{local/}bin/ - pydoc, idle and smtpd.py. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-16 00:48 Message: Logged In: YES user_id=1188172 No other module that can be used standalone delivers such a script. There's also the question where to install it, etc. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-09-16 00:18 Message: Logged In: YES user_id=4799 In the main(): opts, args = getopt.getopt(sys.argv[1:], 'ntd') You can remove 'd' as you've dropeed debugging prints. Are you going to drop standalone webbrowser script? Is "python -m webbrowser" enough? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 23:49 Message: Logged In: YES user_id=1188172 Ah, thanks. I had already corrected #1, but didn't look closely enough for #2. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-09-15 21:26 Message: Logged In: YES user_id=671362 Let me point out two problems: o NameError if remote_background: cmd += ' &' => if self.remote_background: # add "self." cmd += ' &' o copy and paste mistake? \lineiii{'mozilla'}{\class{Mozilla('mozilla')}}{} \lineiii{'firefox'}{\class{Mozilla('mozilla')}}{} => \lineiii{'mozilla'}{\class{Mozilla('mozilla')}}{} \lineiii{'firefox'}{\class{Mozilla('firefox')}}{} ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 12:07 Message: Logged In: YES user_id=1188172 Adding new patch (webbrowser.diff), enhanced with other patches and bugfixes here on SF. Also updated the docs with changed/added notes. Please review, I'll apply this for 2.5. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 20:33 Message: Logged In: YES user_id=1188172 I have reviewed this one too, and I really recommend to apply it for 2.5. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-30 15:02 Message: Logged In: YES user_id=4799 Added Opera controller to the doc. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-30 15:01 Message: Logged In: YES user_id=4799 Added remote functionality for Opera on Unix. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-29 12:50 Message: Logged In: YES user_id=4799 Updated documention patch - added a section about webbrowser script and its command-line options and arguments. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-29 12:48 Message: Logged In: YES user_id=4799 Changed _isexecutable() on w32 to test for executable extensions (.exe, bat) . Tested on Linux with Mozilla/links/elinks; on w32 with Mozilla/Opera/Firefox. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-29 01:25 Message: Logged In: YES user_id=9057 I have revised: libwebbrowser.tex.patch and webbrowser.py.patch. They are Ok, I recommend to apply both. Outstanding work. However, I would withdraw the webbrowser wrapper script, since the same functionality can be accomplished with: python -m webbrowser http://www.python.org ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-28 18:21 Message: Logged In: YES user_id=4799 Patch for documentation. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-28 18:19 Message: Logged In: YES user_id=4799 Minor bugfix. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 16:30 Message: Logged In: YES user_id=4799 Do not report error if the browser doesn't support tabs - just open the URL in a new window. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 16:14 Message: Logged In: YES user_id=4799 I've reworked the patch once more. I moved some common functionality into the UnixBrowser class and added two new features - Elinks launcher class (elinks supports remote commands in a manner very similar to Mozilla) and new-tab functionality for browsers that support tabbed browsing (Mozilla and elinks); a user can now run "webbrowser -t URL" to open the URL a new tab. All classes in the module are now new-style classes (except for the Error class). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 00:18 Message: Logged In: YES user_id=4799 Uploading webbrowser wrapper script. Put it into Tools/scripts directory, and add to the end of setup.py. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 00:17 Message: Logged In: YES user_id=4799 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-24 00:14 Message: Logged In: YES user_id=4799 I've moved script code to main() function. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-03-23 22:25 Message: Logged In: YES user_id=9057 I have reviewed this patch in 2005-03-23 and recommend it to be applied ! Oleg have made the comments below to Python-dev, and those must be taken into consideration while applying this patch. http://python.org/sf/728278 Close with resolution "partially applied, partially rejected". http://python.org/sf/754022 Review and apply! ;) http://python.org/sf/1166780 Close with resolution "applied". (Though it was not applied in exactly that form...) http://python.org/sf/1077979 Close with resolution "applied long ago". http://python.org/sf/1144816 Close with resolution "duplicate of 1077979". ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-03-23 21:06 Message: Logged In: YES user_id=4799 I've consolidated patches 728278, 754022, 954628, 1166780 into this single patch. Some parts of those patches were applied, some rejected, many things changed. I also added elinks support - currently it is very similar to links. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-12-07 14:23 Message: Logged In: YES user_id=4799 Applied the patch from http://python.org/sf/1077979. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-20 10:11 Message: Logged In: YES user_id=80475 Too late for Py2.4. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-10-07 11:48 Message: Logged In: YES user_id=4799 And don't forget to make it executable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=754022&group_id=5470 From noreply at sourceforge.net Fri Sep 23 18:16:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Sep 2005 09:16:27 -0700 Subject: [Patches] [ python-Patches-1297028 ] cjkcodecs does not initialize type pointer Message-ID: Patches item #1297028, was opened at 2005-09-20 16:25 Message generated for change (Comment added) made by ehuss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1297028&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Closed Resolution: Accepted Priority: 9 Submitted By: Eric Huss (ehuss) Assigned to: Anthony Baxter (anthonybaxter) Summary: cjkcodecs does not initialize type pointer Initial Comment: The cjkcodecs code does not initialize the ob_type pointer for the 3 type objects it defines. The following code will illustrate a segmentation fault: >>> import _codecs_cn >>> c = _codecs_cn.getcodec('gb2312') >>> type(c) Segmentation fault (core dumped) I have attached a patch which should solve the problem. ---------------------------------------------------------------------- >Comment By: Eric Huss (ehuss) Date: 2005-09-23 09:16 Message: Logged In: YES user_id=393416 Good question. I'm following the convention that the majority of the Python modules follow. There are 74 instances where it uses NULL and only 19 where it is immediately defined (with zipimport and xxsubtype doing some weird DEFERRED_ADDRESS macro). In section 10.3 in the API docs it recommends doing this for dynamically loading modules (in windows). I wasn't sure if anyone compiles the module as a shared module, so I figured it would be safer to do it this way. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-22 20:29 Message: Logged In: YES user_id=33168 Eric, I have a question about your patch. Is there any reason you didn't change PyObject_HEAD_INIT(NULL) to PyObject_HEAD_INIT(&PyType_Type) rather than do the assignment in init? Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-22 20:25 Message: Logged In: YES user_id=33168 I figured Anthony is busy enough. I checked this in since he said he would. My bad if you didn't want it in 2.4.2. Checked in as: * Misc/NEWS 1.1193.2.107 * Modules/cjkcodecs/multibytecodec.c 1.3.2.1 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2005-09-20 23:57 Message: Logged In: YES user_id=29957 Yes, branch is still frozen. I'll check this in once 2.4.2c1 is out (before 2.4.2 final). I can't get a test case to fail (rather than just segfault). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-20 23:46 Message: Logged In: YES user_id=33168 Thanks! Checked in as: * Misc/NEWS 1.1374 * Modules/cjkcodecs/multibytecodec.c 1.4 This needs to be backported. Anthony is the branch still frozen? Feel free to backport this. I tried to create a test, but it didn't crash. If someone can write a test that crashes when running under regrtest.py, that would be great. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1297028&group_id=5470 From noreply at sourceforge.net Fri Sep 23 18:25:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Sep 2005 09:25:27 -0700 Subject: [Patches] [ python-Patches-1297028 ] cjkcodecs does not initialize type pointer Message-ID: Patches item #1297028, was opened at 2005-09-20 16:25 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1297028&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Closed Resolution: Accepted Priority: 9 Submitted By: Eric Huss (ehuss) Assigned to: Anthony Baxter (anthonybaxter) Summary: cjkcodecs does not initialize type pointer Initial Comment: The cjkcodecs code does not initialize the ob_type pointer for the 3 type objects it defines. The following code will illustrate a segmentation fault: >>> import _codecs_cn >>> c = _codecs_cn.getcodec('gb2312') >>> type(c) Segmentation fault (core dumped) I have attached a patch which should solve the problem. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-23 09:25 Message: Logged In: YES user_id=33168 Ok, thanks. I remembered something about Windows here, but wasn't sure. I looked at some module that it did it the other way. I'm not going to change what's been checked in. ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2005-09-23 09:16 Message: Logged In: YES user_id=393416 Good question. I'm following the convention that the majority of the Python modules follow. There are 74 instances where it uses NULL and only 19 where it is immediately defined (with zipimport and xxsubtype doing some weird DEFERRED_ADDRESS macro). In section 10.3 in the API docs it recommends doing this for dynamically loading modules (in windows). I wasn't sure if anyone compiles the module as a shared module, so I figured it would be safer to do it this way. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-22 20:29 Message: Logged In: YES user_id=33168 Eric, I have a question about your patch. Is there any reason you didn't change PyObject_HEAD_INIT(NULL) to PyObject_HEAD_INIT(&PyType_Type) rather than do the assignment in init? Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-22 20:25 Message: Logged In: YES user_id=33168 I figured Anthony is busy enough. I checked this in since he said he would. My bad if you didn't want it in 2.4.2. Checked in as: * Misc/NEWS 1.1193.2.107 * Modules/cjkcodecs/multibytecodec.c 1.3.2.1 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2005-09-20 23:57 Message: Logged In: YES user_id=29957 Yes, branch is still frozen. I'll check this in once 2.4.2c1 is out (before 2.4.2 final). I can't get a test case to fail (rather than just segfault). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-20 23:46 Message: Logged In: YES user_id=33168 Thanks! Checked in as: * Misc/NEWS 1.1374 * Modules/cjkcodecs/multibytecodec.c 1.4 This needs to be backported. Anthony is the branch still frozen? Feel free to backport this. I tried to create a test, but it didn't crash. If someone can write a test that crashes when running under regrtest.py, that would be great. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1297028&group_id=5470 From noreply at sourceforge.net Fri Sep 23 18:30:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Sep 2005 09:30:52 -0700 Subject: [Patches] [ python-Patches-1301512 ] desktop module (providing startfile as open, all platforms) Message-ID: Patches item #1301512, was opened at 2005-09-23 18: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=1301512&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: desktop module (providing startfile as open, all platforms) Initial Comment: Currently, in Python's standard library, there is apparently no coherent, cross-platform way of getting the user's environment to "open" files or resources (ie. show such files in browsers, editors) when requested by a Python program. There is an os.startfile function which works for Windows, but no equivalent function for other desktop environments - the webbrowser module seems to employ alternative mechanisms in choosing and running external programs and presumably does not seek to provide general support for non-URL resources anyway. Since desktop environments like KDE and GNOME provide mechanisms for running browsers and editors according to the identified type of a file or resource, just as Windows "runs" files or resources, it is appropriate to have a module which accesses these mechanisms. Attached is a simple module which seeks to support KDE, GNOME and Windows - the latter using the existing os.startfile support - and which could be extended to support other desktop environments such as Mac OS X, XFCE, CDE (along with others deemed important and feasible enough to support). Note that this approach is arguably better than that employed by the webbrowser module since most desktop environments already provide mechanisms for configuring and choosing the user's preferred programs for various activities, whereas the webbrowser module makes relatively uninformed guesses (eg. opening Firefox on a KDE desktop configured to use Konqueror as the default browser). Note also that the startfile function is arguably misplaced in the os module; thus, this functionality is supplied as a new module rather than as a patch to the os module, and the name of the function is "open" (like in the webbrowser module) rather than "startfile" which is a fairly Windows specific term. One could also envisage the desktop module residing within the os package to avoid top-level namespace pollution. Recent discussion in the comp.lang.python thread "Open PDF" covering this issue can be found here: http://groups.google.no/group/comp.lang.python/browse_frm/thread/8e00f7c1ccfae166/6168b6728cf64cb7 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 From noreply at sourceforge.net Fri Sep 23 22:51:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Sep 2005 13:51:43 -0700 Subject: [Patches] [ python-Patches-1166938 ] locale.getdefaultencoding: LANGUAGE not correctly parsed Message-ID: Patches item #1166938, was opened at 2005-03-20 07:57 Message generated for change (Settings changed) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166938&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: locale.getdefaultencoding: LANGUAGE not correctly parsed Initial Comment: According to gettext(3), "LANGUAGE is assumed to contain a colon separated list of locale names.". Fix it by taking the string up to the first colon as localename. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2005-09-20 03:05 Message: Logged In: YES user_id=60903 checked in as Lib/locale.py: 1.32 (HEAD) Lib/locale.py: 1.28.4.2 (2.4 branch) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166938&group_id=5470 From noreply at sourceforge.net Fri Sep 23 22:52:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Sep 2005 13:52:47 -0700 Subject: [Patches] [ python-Patches-1166948 ] locale.getdefaultencoding: precedence of LANGUAGE / LANG Message-ID: Patches item #1166948, was opened at 2005-03-20 08:11 Message generated for change (Settings changed) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166948&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: locale.getdefaultencoding: precedence of LANGUAGE / LANG Initial Comment: locale.getdefaultencoding checks first LANGUAGE, then the LC_* and LANG variables. Assume LANGUAGE is set to en:de, and LANG to en_US.utf-8, then getdefaultencoding returns the wrong encoding (ISO8859-1). AFAIK, LANGUAGE is specific to gettext (GNU extension), and IMO should not interfer with getting the correct encoding. This patch uses LANGUAGE as the choice with the lowest priority, so the other variables to determine the locale and encoding take precedence (LC_ALL, LC_CTYPE, LANG). There's another (minor) bug in the implementation: LANGUAGE is honoured even if the default locale is "C". ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2005-09-20 03:06 Message: Logged In: YES user_id=60903 checked in as Lib/locale.py: 1.32 (HEAD) Lib/locale.py: 1.28.4.2 (2.4 branch) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 13:04 Message: Logged In: YES user_id=1188172 This file is one big patch for #1166938, #1166948 and #1166957. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166948&group_id=5470 From noreply at sourceforge.net Fri Sep 23 22:58:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Sep 2005 13:58:53 -0700 Subject: [Patches] [ python-Patches-1166957 ] locale: 'utf' is not a known encoding Message-ID: Patches item #1166957, was opened at 2005-03-20 08:32 Message generated for change (Settings changed) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166957&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: locale: 'utf' is not a known encoding Initial Comment: checked with glibc-2.3.2 on a Debian/sarge system. The locale_alias and the encoding_alias tables map the encoding from utf-8, utf8 to utf, which is not a valid encoding, at least on this system. LANG=de_DE.utf-8 python -c 'import locale; locale.resetlocale()' Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 391, in resetlocale _setlocale(category, _build_localename(getdefaultlocale())) locale.Error: unsupported locale setting ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2005-09-20 03:07 Message: Logged In: YES user_id=60903 already fixed on HEAD, rejected for the branch ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 13:04 Message: Logged In: YES user_id=1188172 This file is one big patch for #1166938, #1166948 and #1166957. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166957&group_id=5470 From noreply at sourceforge.net Sat Sep 24 01:49:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Sep 2005 16:49:30 -0700 Subject: [Patches] [ python-Patches-1298835 ] vendor-packages directory. Message-ID: Patches item #1298835, was opened at 2005-09-22 11:12 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298835&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Rich Burridge (richburridge) Assigned to: Nobody/Anonymous (nobody) Summary: vendor-packages directory. Initial Comment: Python needs a .../python2.x.y/vendor-packages directory for vendor supplied Python files. See: http://mail.python.org/pipermail/python-list/2005-September/300029.html for the full reasoning behind this request. I also approached Guido w.r.t. this. Here's his reply. Subject: Re: Python vendor-packages directory in a future Python release? Date: Tue, 20 Sep 2005 19:48:40 -0700 From: Guido van Rossum Reply-To: Guido van Rossum To: Rich Burridge References: <4330C108.4030100 at sun.com> I think that's a reasonable request. (In the mean time, I think that using site-packages is fine as an interim solution.) I suggest that you use the SourceForge patch manager for the Python project to upload your patch, and then post to python-dev. You may be asked to review 5 other patches in order to have someone look at your favorite patch. --Guido ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-23 19:49 Message: Logged In: YES user_id=593130 The reason for this patch given in the referred-to post is: "We have been told that this directory is inappropriate for vendor supplied packages, just as "site_perl" is inappropriate for Perl. With Perl, vendor supplied packages go under "vendor_perl". " where 'this directory' is site-packages, which works fine. The python-dev thread subequent to this posting starts with http://mail.python.org/pipermail/python-dev/2005- September/056682.html A subsequent post http://mail.python.org/pipermail/python-dev/2005- September/056696.html clarifies that 'vendor supplied packages' here means packages installed by the system/OS vendor. Disconnected (in the pipermail archives) pieces of the thread start here http://mail.python.org/pipermail/python-dev/2005- September/056697.html and here http://mail.python.org/pipermail/python-dev/2005- September/056702.html This last suggests that this proposal is on hold while a .pth solution is explored. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298835&group_id=5470 From noreply at sourceforge.net Sat Sep 24 14:13:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Sep 2005 05:13:05 -0700 Subject: [Patches] [ python-Patches-1301512 ] desktop module (providing startfile as open, all platforms) Message-ID: Patches item #1301512, was opened at 2005-09-23 17:30 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: desktop module (providing startfile as open, all platforms) Initial Comment: Currently, in Python's standard library, there is apparently no coherent, cross-platform way of getting the user's environment to "open" files or resources (ie. show such files in browsers, editors) when requested by a Python program. There is an os.startfile function which works for Windows, but no equivalent function for other desktop environments - the webbrowser module seems to employ alternative mechanisms in choosing and running external programs and presumably does not seek to provide general support for non-URL resources anyway. Since desktop environments like KDE and GNOME provide mechanisms for running browsers and editors according to the identified type of a file or resource, just as Windows "runs" files or resources, it is appropriate to have a module which accesses these mechanisms. Attached is a simple module which seeks to support KDE, GNOME and Windows - the latter using the existing os.startfile support - and which could be extended to support other desktop environments such as Mac OS X, XFCE, CDE (along with others deemed important and feasible enough to support). Note that this approach is arguably better than that employed by the webbrowser module since most desktop environments already provide mechanisms for configuring and choosing the user's preferred programs for various activities, whereas the webbrowser module makes relatively uninformed guesses (eg. opening Firefox on a KDE desktop configured to use Konqueror as the default browser). Note also that the startfile function is arguably misplaced in the os module; thus, this functionality is supplied as a new module rather than as a patch to the os module, and the name of the function is "open" (like in the webbrowser module) rather than "startfile" which is a fairly Windows specific term. One could also envisage the desktop module residing within the os package to avoid top-level namespace pollution. Recent discussion in the comp.lang.python thread "Open PDF" covering this issue can be found here: http://groups.google.no/group/comp.lang.python/browse_frm/thread/8e00f7c1ccfae166/6168b6728cf64cb7 ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-24 13:13 Message: Logged In: YES user_id=261020 +1 on the idea, but a slight change to the implementation for KDE... I wrote a detailed bug report below, then discovered the solution to what I assume is a bug. Here's the solution: For KDE, use 'exec' instead of 'openURL' as the first argument to kfmclient. Here's the detailed report: I tried setting up KDE 3.2.2 to associate text files in the order: Emacs KWrite KEdit Kate I used Control Center->KDE Components->File Associations to do that. All of those editors are installed on my machine. Then I attempted to open this text file: $ file /home/john/test.txt /home/john/test.txt: ASCII text $ cat /home/john/test.txt hello, world $ When I open it by clicking on it from a Konqueror directory listing, GNU emacs running in an X11 window starts up, with the specified file opened. When I use your module: $ python2.4 Python 2.4 (#1, Feb 19 2005, 23:54:54) [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import desktop >>> desktop.open("/home/john/blocking.txt") >>> ...it opens in Konqueror with some embedded editor (KEdit or KWrite, I assume), not directly in any of the editors I specified, and certainly not in emacs. Same applies if I use a URL: >>> desktop.open("file:///home/john/test.txt") This doesn't seem to be the intended behaviour of your module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 From noreply at sourceforge.net Sat Sep 24 14:28:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Sep 2005 05:28:37 -0700 Subject: [Patches] [ python-Patches-1301512 ] desktop module (providing startfile as open, all platforms) Message-ID: Patches item #1301512, was opened at 2005-09-23 17:30 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: desktop module (providing startfile as open, all platforms) Initial Comment: Currently, in Python's standard library, there is apparently no coherent, cross-platform way of getting the user's environment to "open" files or resources (ie. show such files in browsers, editors) when requested by a Python program. There is an os.startfile function which works for Windows, but no equivalent function for other desktop environments - the webbrowser module seems to employ alternative mechanisms in choosing and running external programs and presumably does not seek to provide general support for non-URL resources anyway. Since desktop environments like KDE and GNOME provide mechanisms for running browsers and editors according to the identified type of a file or resource, just as Windows "runs" files or resources, it is appropriate to have a module which accesses these mechanisms. Attached is a simple module which seeks to support KDE, GNOME and Windows - the latter using the existing os.startfile support - and which could be extended to support other desktop environments such as Mac OS X, XFCE, CDE (along with others deemed important and feasible enough to support). Note that this approach is arguably better than that employed by the webbrowser module since most desktop environments already provide mechanisms for configuring and choosing the user's preferred programs for various activities, whereas the webbrowser module makes relatively uninformed guesses (eg. opening Firefox on a KDE desktop configured to use Konqueror as the default browser). Note also that the startfile function is arguably misplaced in the os module; thus, this functionality is supplied as a new module rather than as a patch to the os module, and the name of the function is "open" (like in the webbrowser module) rather than "startfile" which is a fairly Windows specific term. One could also envisage the desktop module residing within the os package to avoid top-level namespace pollution. Recent discussion in the comp.lang.python thread "Open PDF" covering this issue can be found here: http://groups.google.no/group/comp.lang.python/browse_frm/thread/8e00f7c1ccfae166/6168b6728cf64cb7 ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-24 13:28 Message: Logged In: YES user_id=261020 I guess there are probably security implications with using kfmclient exec (risk of running arbitrary code)... but then I guess the same applies to os.startfile(). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-24 13:13 Message: Logged In: YES user_id=261020 +1 on the idea, but a slight change to the implementation for KDE... I wrote a detailed bug report below, then discovered the solution to what I assume is a bug. Here's the solution: For KDE, use 'exec' instead of 'openURL' as the first argument to kfmclient. Here's the detailed report: I tried setting up KDE 3.2.2 to associate text files in the order: Emacs KWrite KEdit Kate I used Control Center->KDE Components->File Associations to do that. All of those editors are installed on my machine. Then I attempted to open this text file: $ file /home/john/test.txt /home/john/test.txt: ASCII text $ cat /home/john/test.txt hello, world $ When I open it by clicking on it from a Konqueror directory listing, GNU emacs running in an X11 window starts up, with the specified file opened. When I use your module: $ python2.4 Python 2.4 (#1, Feb 19 2005, 23:54:54) [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import desktop >>> desktop.open("/home/john/blocking.txt") >>> ...it opens in Konqueror with some embedded editor (KEdit or KWrite, I assume), not directly in any of the editors I specified, and certainly not in emacs. Same applies if I use a URL: >>> desktop.open("file:///home/john/test.txt") This doesn't seem to be the intended behaviour of your module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 From noreply at sourceforge.net Sat Sep 24 14:47:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Sep 2005 05:47:36 -0700 Subject: [Patches] [ python-Patches-1301512 ] desktop module (providing startfile as open, all platforms) Message-ID: Patches item #1301512, was opened at 2005-09-23 17:30 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: desktop module (providing startfile as open, all platforms) Initial Comment: Currently, in Python's standard library, there is apparently no coherent, cross-platform way of getting the user's environment to "open" files or resources (ie. show such files in browsers, editors) when requested by a Python program. There is an os.startfile function which works for Windows, but no equivalent function for other desktop environments - the webbrowser module seems to employ alternative mechanisms in choosing and running external programs and presumably does not seek to provide general support for non-URL resources anyway. Since desktop environments like KDE and GNOME provide mechanisms for running browsers and editors according to the identified type of a file or resource, just as Windows "runs" files or resources, it is appropriate to have a module which accesses these mechanisms. Attached is a simple module which seeks to support KDE, GNOME and Windows - the latter using the existing os.startfile support - and which could be extended to support other desktop environments such as Mac OS X, XFCE, CDE (along with others deemed important and feasible enough to support). Note that this approach is arguably better than that employed by the webbrowser module since most desktop environments already provide mechanisms for configuring and choosing the user's preferred programs for various activities, whereas the webbrowser module makes relatively uninformed guesses (eg. opening Firefox on a KDE desktop configured to use Konqueror as the default browser). Note also that the startfile function is arguably misplaced in the os module; thus, this functionality is supplied as a new module rather than as a patch to the os module, and the name of the function is "open" (like in the webbrowser module) rather than "startfile" which is a fairly Windows specific term. One could also envisage the desktop module residing within the os package to avoid top-level namespace pollution. Recent discussion in the comp.lang.python thread "Open PDF" covering this issue can be found here: http://groups.google.no/group/comp.lang.python/browse_frm/thread/8e00f7c1ccfae166/6168b6728cf64cb7 ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-24 13:47 Message: Logged In: YES user_id=261020 Looking at the thread you reference, I guess it would be nice if the desktop module supported returning a process handle. On Windows, I imagine os.startfile could be extended in Python 2.5 to use StartFileEx() (win32 function suggested by Thomas Heller) and return a process handle. I guess it's worth asking whether that's actually very useful without ctypes or win32all, though. Anybody know how you'd get a pid out of KDE or GNOME? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-24 13:28 Message: Logged In: YES user_id=261020 I guess there are probably security implications with using kfmclient exec (risk of running arbitrary code)... but then I guess the same applies to os.startfile(). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-24 13:13 Message: Logged In: YES user_id=261020 +1 on the idea, but a slight change to the implementation for KDE... I wrote a detailed bug report below, then discovered the solution to what I assume is a bug. Here's the solution: For KDE, use 'exec' instead of 'openURL' as the first argument to kfmclient. Here's the detailed report: I tried setting up KDE 3.2.2 to associate text files in the order: Emacs KWrite KEdit Kate I used Control Center->KDE Components->File Associations to do that. All of those editors are installed on my machine. Then I attempted to open this text file: $ file /home/john/test.txt /home/john/test.txt: ASCII text $ cat /home/john/test.txt hello, world $ When I open it by clicking on it from a Konqueror directory listing, GNU emacs running in an X11 window starts up, with the specified file opened. When I use your module: $ python2.4 Python 2.4 (#1, Feb 19 2005, 23:54:54) [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import desktop >>> desktop.open("/home/john/blocking.txt") >>> ...it opens in Konqueror with some embedded editor (KEdit or KWrite, I assume), not directly in any of the editors I specified, and certainly not in emacs. Same applies if I use a URL: >>> desktop.open("file:///home/john/test.txt") This doesn't seem to be the intended behaviour of your module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 From noreply at sourceforge.net Sat Sep 24 17:05:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Sep 2005 08:05:36 -0700 Subject: [Patches] [ python-Patches-1288833 ] FreeBSD 5.3 and upward has thread-safe getaddrinfo(3) Message-ID: Patches item #1288833, was opened at 2005-09-13 00:35 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1288833&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Modules >Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Maxim Sobolev (sobomax) Assigned to: Hye-Shik Chang (perky) Summary: FreeBSD 5.3 and upward has thread-safe getaddrinfo(3) Initial Comment: The FreeBSD operating system has thread-safe getaddrinfo(3) since version 5.3. Therefore, serialization in the socket module is not necessary when Python is compiled for this system. -Maxim ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2005-09-25 00:05 Message: Logged In: YES user_id=55188 Fixed in CVS: Modules/socketmodule.c 1.314 Misc/NEWS 1.1376 I'll merge this patch into ports along with updating lang/python to 2.4.2 after the version is released. Thank you! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1288833&group_id=5470 From noreply at sourceforge.net Sat Sep 24 18:33:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Sep 2005 09:33:55 -0700 Subject: [Patches] [ python-Patches-1301512 ] desktop module (providing startfile as open, all platforms) Message-ID: Patches item #1301512, was opened at 2005-09-23 18:30 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: desktop module (providing startfile as open, all platforms) Initial Comment: Currently, in Python's standard library, there is apparently no coherent, cross-platform way of getting the user's environment to "open" files or resources (ie. show such files in browsers, editors) when requested by a Python program. There is an os.startfile function which works for Windows, but no equivalent function for other desktop environments - the webbrowser module seems to employ alternative mechanisms in choosing and running external programs and presumably does not seek to provide general support for non-URL resources anyway. Since desktop environments like KDE and GNOME provide mechanisms for running browsers and editors according to the identified type of a file or resource, just as Windows "runs" files or resources, it is appropriate to have a module which accesses these mechanisms. Attached is a simple module which seeks to support KDE, GNOME and Windows - the latter using the existing os.startfile support - and which could be extended to support other desktop environments such as Mac OS X, XFCE, CDE (along with others deemed important and feasible enough to support). Note that this approach is arguably better than that employed by the webbrowser module since most desktop environments already provide mechanisms for configuring and choosing the user's preferred programs for various activities, whereas the webbrowser module makes relatively uninformed guesses (eg. opening Firefox on a KDE desktop configured to use Konqueror as the default browser). Note also that the startfile function is arguably misplaced in the os module; thus, this functionality is supplied as a new module rather than as a patch to the os module, and the name of the function is "open" (like in the webbrowser module) rather than "startfile" which is a fairly Windows specific term. One could also envisage the desktop module residing within the os package to avoid top-level namespace pollution. Recent discussion in the comp.lang.python thread "Open PDF" covering this issue can be found here: http://groups.google.no/group/comp.lang.python/browse_frm/thread/8e00f7c1ccfae166/6168b6728cf64cb7 ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2005-09-24 18:33 Message: Logged In: YES user_id=226443 Configuring KDE to open different types of files requires some magic that I don't fully understand. Nevertheless, I find that if I create a shell script with executable permissions then "kfmclient exec" will run that script, whereas "kfmclient openURL" will ask whether I want to run it first. That said, "kfmclient exec" probably has closer semantics to the win32-supported os.startfile function. I've uploaded a new version of the module which returns the process identifier, along with some exception handling around os.startfile. See this page for related discussion of KDE and GNOME application launching: http://my.opera.com/community/forums/topic.dml?id=83890 See this thread for upcoming standards: http://thread.gmane.org/gmane.linux.xdg.devel/2524 See this page for details of such standards: http://www.freedesktop.org/Standards/mime-actions-spec ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-24 14:47 Message: Logged In: YES user_id=261020 Looking at the thread you reference, I guess it would be nice if the desktop module supported returning a process handle. On Windows, I imagine os.startfile could be extended in Python 2.5 to use StartFileEx() (win32 function suggested by Thomas Heller) and return a process handle. I guess it's worth asking whether that's actually very useful without ctypes or win32all, though. Anybody know how you'd get a pid out of KDE or GNOME? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-24 14:28 Message: Logged In: YES user_id=261020 I guess there are probably security implications with using kfmclient exec (risk of running arbitrary code)... but then I guess the same applies to os.startfile(). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-24 14:13 Message: Logged In: YES user_id=261020 +1 on the idea, but a slight change to the implementation for KDE... I wrote a detailed bug report below, then discovered the solution to what I assume is a bug. Here's the solution: For KDE, use 'exec' instead of 'openURL' as the first argument to kfmclient. Here's the detailed report: I tried setting up KDE 3.2.2 to associate text files in the order: Emacs KWrite KEdit Kate I used Control Center->KDE Components->File Associations to do that. All of those editors are installed on my machine. Then I attempted to open this text file: $ file /home/john/test.txt /home/john/test.txt: ASCII text $ cat /home/john/test.txt hello, world $ When I open it by clicking on it from a Konqueror directory listing, GNU emacs running in an X11 window starts up, with the specified file opened. When I use your module: $ python2.4 Python 2.4 (#1, Feb 19 2005, 23:54:54) [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import desktop >>> desktop.open("/home/john/blocking.txt") >>> ...it opens in Konqueror with some embedded editor (KEdit or KWrite, I assume), not directly in any of the editors I specified, and certainly not in emacs. Same applies if I use a URL: >>> desktop.open("file:///home/john/test.txt") This doesn't seem to be the intended behaviour of your module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 From noreply at sourceforge.net Sat Sep 24 20:23:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Sep 2005 11:23:46 -0700 Subject: [Patches] [ python-Patches-1301512 ] desktop module (providing startfile as open, all platforms) Message-ID: Patches item #1301512, was opened at 2005-09-23 18:30 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: desktop module (providing startfile as open, all platforms) Initial Comment: Currently, in Python's standard library, there is apparently no coherent, cross-platform way of getting the user's environment to "open" files or resources (ie. show such files in browsers, editors) when requested by a Python program. There is an os.startfile function which works for Windows, but no equivalent function for other desktop environments - the webbrowser module seems to employ alternative mechanisms in choosing and running external programs and presumably does not seek to provide general support for non-URL resources anyway. Since desktop environments like KDE and GNOME provide mechanisms for running browsers and editors according to the identified type of a file or resource, just as Windows "runs" files or resources, it is appropriate to have a module which accesses these mechanisms. Attached is a simple module which seeks to support KDE, GNOME and Windows - the latter using the existing os.startfile support - and which could be extended to support other desktop environments such as Mac OS X, XFCE, CDE (along with others deemed important and feasible enough to support). Note that this approach is arguably better than that employed by the webbrowser module since most desktop environments already provide mechanisms for configuring and choosing the user's preferred programs for various activities, whereas the webbrowser module makes relatively uninformed guesses (eg. opening Firefox on a KDE desktop configured to use Konqueror as the default browser). Note also that the startfile function is arguably misplaced in the os module; thus, this functionality is supplied as a new module rather than as a patch to the os module, and the name of the function is "open" (like in the webbrowser module) rather than "startfile" which is a fairly Windows specific term. One could also envisage the desktop module residing within the os package to avoid top-level namespace pollution. Recent discussion in the comp.lang.python thread "Open PDF" covering this issue can be found here: http://groups.google.no/group/comp.lang.python/browse_frm/thread/8e00f7c1ccfae166/6168b6728cf64cb7 ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2005-09-24 20:23 Message: Logged In: YES user_id=226443 Other related material: http://www.freedesktop.org/wiki/Software_2fpyxdg ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-24 18:33 Message: Logged In: YES user_id=226443 Configuring KDE to open different types of files requires some magic that I don't fully understand. Nevertheless, I find that if I create a shell script with executable permissions then "kfmclient exec" will run that script, whereas "kfmclient openURL" will ask whether I want to run it first. That said, "kfmclient exec" probably has closer semantics to the win32-supported os.startfile function. I've uploaded a new version of the module which returns the process identifier, along with some exception handling around os.startfile. See this page for related discussion of KDE and GNOME application launching: http://my.opera.com/community/forums/topic.dml?id=83890 See this thread for upcoming standards: http://thread.gmane.org/gmane.linux.xdg.devel/2524 See this page for details of such standards: http://www.freedesktop.org/Standards/mime-actions-spec ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-24 14:47 Message: Logged In: YES user_id=261020 Looking at the thread you reference, I guess it would be nice if the desktop module supported returning a process handle. On Windows, I imagine os.startfile could be extended in Python 2.5 to use StartFileEx() (win32 function suggested by Thomas Heller) and return a process handle. I guess it's worth asking whether that's actually very useful without ctypes or win32all, though. Anybody know how you'd get a pid out of KDE or GNOME? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-24 14:28 Message: Logged In: YES user_id=261020 I guess there are probably security implications with using kfmclient exec (risk of running arbitrary code)... but then I guess the same applies to os.startfile(). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-24 14:13 Message: Logged In: YES user_id=261020 +1 on the idea, but a slight change to the implementation for KDE... I wrote a detailed bug report below, then discovered the solution to what I assume is a bug. Here's the solution: For KDE, use 'exec' instead of 'openURL' as the first argument to kfmclient. Here's the detailed report: I tried setting up KDE 3.2.2 to associate text files in the order: Emacs KWrite KEdit Kate I used Control Center->KDE Components->File Associations to do that. All of those editors are installed on my machine. Then I attempted to open this text file: $ file /home/john/test.txt /home/john/test.txt: ASCII text $ cat /home/john/test.txt hello, world $ When I open it by clicking on it from a Konqueror directory listing, GNU emacs running in an X11 window starts up, with the specified file opened. When I use your module: $ python2.4 Python 2.4 (#1, Feb 19 2005, 23:54:54) [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import desktop >>> desktop.open("/home/john/blocking.txt") >>> ...it opens in Konqueror with some embedded editor (KEdit or KWrite, I assume), not directly in any of the editors I specified, and certainly not in emacs. Same applies if I use a URL: >>> desktop.open("file:///home/john/test.txt") This doesn't seem to be the intended behaviour of your module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 From noreply at sourceforge.net Sat Sep 24 20:49:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Sep 2005 11:49:43 -0700 Subject: [Patches] [ python-Patches-1301512 ] desktop module (providing startfile as open, all platforms) Message-ID: Patches item #1301512, was opened at 2005-09-23 11:30 Message generated for change (Comment added) made by mwm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: desktop module (providing startfile as open, all platforms) Initial Comment: Currently, in Python's standard library, there is apparently no coherent, cross-platform way of getting the user's environment to "open" files or resources (ie. show such files in browsers, editors) when requested by a Python program. There is an os.startfile function which works for Windows, but no equivalent function for other desktop environments - the webbrowser module seems to employ alternative mechanisms in choosing and running external programs and presumably does not seek to provide general support for non-URL resources anyway. Since desktop environments like KDE and GNOME provide mechanisms for running browsers and editors according to the identified type of a file or resource, just as Windows "runs" files or resources, it is appropriate to have a module which accesses these mechanisms. Attached is a simple module which seeks to support KDE, GNOME and Windows - the latter using the existing os.startfile support - and which could be extended to support other desktop environments such as Mac OS X, XFCE, CDE (along with others deemed important and feasible enough to support). Note that this approach is arguably better than that employed by the webbrowser module since most desktop environments already provide mechanisms for configuring and choosing the user's preferred programs for various activities, whereas the webbrowser module makes relatively uninformed guesses (eg. opening Firefox on a KDE desktop configured to use Konqueror as the default browser). Note also that the startfile function is arguably misplaced in the os module; thus, this functionality is supplied as a new module rather than as a patch to the os module, and the name of the function is "open" (like in the webbrowser module) rather than "startfile" which is a fairly Windows specific term. One could also envisage the desktop module residing within the os package to avoid top-level namespace pollution. Recent discussion in the comp.lang.python thread "Open PDF" covering this issue can be found here: http://groups.google.no/group/comp.lang.python/browse_frm/thread/8e00f7c1ccfae166/6168b6728cf64cb7 ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-24 13:49 Message: Logged In: YES user_id=93910 The code to support Mac OS X is: While the commentary that webbrowser does it wrong is on target, the proposed code resembles that more than one would like. Both webbrowser and desktop poke around the system to make a guess as to what application they should be using. This is fine, so long as they guess right. The problems is if they guess wrong. webbrowser allows for this by allowing the user to specify a file opener in the environment variable OPENER. I'd suggest supporting that. I started to add support, then decided that ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-24 13:23 Message: Logged In: YES user_id=226443 Other related material: http://www.freedesktop.org/wiki/Software_2fpyxdg ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-24 11:33 Message: Logged In: YES user_id=226443 Configuring KDE to open different types of files requires some magic that I don't fully understand. Nevertheless, I find that if I create a shell script with executable permissions then "kfmclient exec" will run that script, whereas "kfmclient openURL" will ask whether I want to run it first. That said, "kfmclient exec" probably has closer semantics to the win32-supported os.startfile function. I've uploaded a new version of the module which returns the process identifier, along with some exception handling around os.startfile. See this page for related discussion of KDE and GNOME application launching: http://my.opera.com/community/forums/topic.dml?id=83890 See this thread for upcoming standards: http://thread.gmane.org/gmane.linux.xdg.devel/2524 See this page for details of such standards: http://www.freedesktop.org/Standards/mime-actions-spec ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-24 07:47 Message: Logged In: YES user_id=261020 Looking at the thread you reference, I guess it would be nice if the desktop module supported returning a process handle. On Windows, I imagine os.startfile could be extended in Python 2.5 to use StartFileEx() (win32 function suggested by Thomas Heller) and return a process handle. I guess it's worth asking whether that's actually very useful without ctypes or win32all, though. Anybody know how you'd get a pid out of KDE or GNOME? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-24 07:28 Message: Logged In: YES user_id=261020 I guess there are probably security implications with using kfmclient exec (risk of running arbitrary code)... but then I guess the same applies to os.startfile(). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-24 07:13 Message: Logged In: YES user_id=261020 +1 on the idea, but a slight change to the implementation for KDE... I wrote a detailed bug report below, then discovered the solution to what I assume is a bug. Here's the solution: For KDE, use 'exec' instead of 'openURL' as the first argument to kfmclient. Here's the detailed report: I tried setting up KDE 3.2.2 to associate text files in the order: Emacs KWrite KEdit Kate I used Control Center->KDE Components->File Associations to do that. All of those editors are installed on my machine. Then I attempted to open this text file: $ file /home/john/test.txt /home/john/test.txt: ASCII text $ cat /home/john/test.txt hello, world $ When I open it by clicking on it from a Konqueror directory listing, GNU emacs running in an X11 window starts up, with the specified file opened. When I use your module: $ python2.4 Python 2.4 (#1, Feb 19 2005, 23:54:54) [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import desktop >>> desktop.open("/home/john/blocking.txt") >>> ...it opens in Konqueror with some embedded editor (KEdit or KWrite, I assume), not directly in any of the editors I specified, and certainly not in emacs. Same applies if I use a URL: >>> desktop.open("file:///home/john/test.txt") This doesn't seem to be the intended behaviour of your module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 From noreply at sourceforge.net Sat Sep 24 20:53:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Sep 2005 11:53:09 -0700 Subject: [Patches] [ python-Patches-1301512 ] desktop module (providing startfile as open, all platforms) Message-ID: Patches item #1301512, was opened at 2005-09-23 11:30 Message generated for change (Comment added) made by mwm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: desktop module (providing startfile as open, all platforms) Initial Comment: Currently, in Python's standard library, there is apparently no coherent, cross-platform way of getting the user's environment to "open" files or resources (ie. show such files in browsers, editors) when requested by a Python program. There is an os.startfile function which works for Windows, but no equivalent function for other desktop environments - the webbrowser module seems to employ alternative mechanisms in choosing and running external programs and presumably does not seek to provide general support for non-URL resources anyway. Since desktop environments like KDE and GNOME provide mechanisms for running browsers and editors according to the identified type of a file or resource, just as Windows "runs" files or resources, it is appropriate to have a module which accesses these mechanisms. Attached is a simple module which seeks to support KDE, GNOME and Windows - the latter using the existing os.startfile support - and which could be extended to support other desktop environments such as Mac OS X, XFCE, CDE (along with others deemed important and feasible enough to support). Note that this approach is arguably better than that employed by the webbrowser module since most desktop environments already provide mechanisms for configuring and choosing the user's preferred programs for various activities, whereas the webbrowser module makes relatively uninformed guesses (eg. opening Firefox on a KDE desktop configured to use Konqueror as the default browser). Note also that the startfile function is arguably misplaced in the os module; thus, this functionality is supplied as a new module rather than as a patch to the os module, and the name of the function is "open" (like in the webbrowser module) rather than "startfile" which is a fairly Windows specific term. One could also envisage the desktop module residing within the os package to avoid top-level namespace pollution. Recent discussion in the comp.lang.python thread "Open PDF" covering this issue can be found here: http://groups.google.no/group/comp.lang.python/browse_frm/thread/8e00f7c1ccfae166/6168b6728cf64cb7 ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-24 13:53 Message: Logged In: YES user_id=93910 The code to support Mac OS X is: if sys.platform == 'darwin': cmd = ['open'] etc. While the commentary that webbrowser does it wrong is on target, the proposed code resembles that more than one would like. Both webbrowser and desktop poke around the system to make a guess as to what application they should be using. This is fine, so long as they guess right. The problems is if they guess wrong. There's an OSS replacement for open on the Mac, and just because a box isn't running GNOME or KDE doesn't mean it's Windows, or doesn't have a file opener. webbrowser allows for this by allowing the user to specify a file opener in an environment variable. Gnome (or was it KDE?) uses OPENER for that. I'd suggest supporting that. I started to add support, then noticed that cmd was a list of strings, and you can't really specify that in an environment variable, so it needs to be encoded somehow. I'm going to leave that to someone more interested in the problem. KDE Components->File Associations to do that. All of those editors are installed on my machine. Then I attempted to open this text file: $ file /home/john/test.txt /home/john/test.txt: ASCII text $ cat /home/john/test.txt hello, world $ When I open it by clicking on it from a Konqueror directory listing, GNU emacs running in an X11 window starts up, with the specified file opened. When I use your module: $ python2.4 Python 2.4 (#1, Feb 19 2005, 23:54:54) [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import desktop >>> desktop.open("/home/john/blocking.txt") >>> ...it opens in Konqueror with some embedded editor (KEdit or KWrite, I assume), not directly in any of the editors I specified, and certainly not in emacs. Same applies if I use a URL: >>> desktop.open("file:///home/john/test.txt") This doesn't seem to be the intended behaviour of your module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 From noreply at sourceforge.net Sat Sep 24 23:28:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Sep 2005 14:28:44 -0700 Subject: [Patches] [ python-Patches-1301512 ] desktop module (providing startfile as open, all platforms) Message-ID: Patches item #1301512, was opened at 2005-09-23 17:30 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: desktop module (providing startfile as open, all platforms) Initial Comment: Currently, in Python's standard library, there is apparently no coherent, cross-platform way of getting the user's environment to "open" files or resources (ie. show such files in browsers, editors) when requested by a Python program. There is an os.startfile function which works for Windows, but no equivalent function for other desktop environments - the webbrowser module seems to employ alternative mechanisms in choosing and running external programs and presumably does not seek to provide general support for non-URL resources anyway. Since desktop environments like KDE and GNOME provide mechanisms for running browsers and editors according to the identified type of a file or resource, just as Windows "runs" files or resources, it is appropriate to have a module which accesses these mechanisms. Attached is a simple module which seeks to support KDE, GNOME and Windows - the latter using the existing os.startfile support - and which could be extended to support other desktop environments such as Mac OS X, XFCE, CDE (along with others deemed important and feasible enough to support). Note that this approach is arguably better than that employed by the webbrowser module since most desktop environments already provide mechanisms for configuring and choosing the user's preferred programs for various activities, whereas the webbrowser module makes relatively uninformed guesses (eg. opening Firefox on a KDE desktop configured to use Konqueror as the default browser). Note also that the startfile function is arguably misplaced in the os module; thus, this functionality is supplied as a new module rather than as a patch to the os module, and the name of the function is "open" (like in the webbrowser module) rather than "startfile" which is a fairly Windows specific term. One could also envisage the desktop module residing within the os package to avoid top-level namespace pollution. Recent discussion in the comp.lang.python thread "Open PDF" covering this issue can be found here: http://groups.google.no/group/comp.lang.python/browse_frm/thread/8e00f7c1ccfae166/6168b6728cf64cb7 ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-24 22:28 Message: Logged In: YES user_id=261020 Oops, s/StartFileEx()/ShellExecuteEx()/ Paul: What are we actually trying to do here? 1) Open arbitrary files (possibly by means of a URL) using the method that the desktop user has configured his desktop / OS? Or 2) open arbitrary URLs in the web browser he has configured (possibly making use of GUI components embedded in the browser)? Or 3) something else? If 1) (which is what I had gathered from your initial comment and the c.l.py thread you referenced), then I guess ShellExecute (os.startfile) is right, as is kfmclient exec, and we just have to accept there are security implications that need to be borne in mind and acted upon appropriately (I'm not certain what that entails). Are there really major security differences between kfmclient exec and ShellExecute here? If 2). then it seems that we're doing two different things on the two different desktops we're talking about: kfmclient has openUrl, but ShellExecute doesn't have any equivalent (I assume the "explore" verb always lands you in IE / Windows Explorer, never firefox, for example). Perhaps unavoidable, but weakens the case for the module. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-24 19:53 Message: Logged In: YES user_id=93910 The code to support Mac OS X is: if sys.platform == 'darwin': cmd = ['open'] etc. While the commentary that webbrowser does it wrong is on target, the proposed code resembles that more than one would like. Both webbrowser and desktop poke around the system to make a guess as to what application they should be using. This is fine, so long as they guess right. The problems is if they guess wrong. There's an OSS replacement for open on the Mac, and just because a box isn't running GNOME or KDE doesn't mean it's Windows, or doesn't have a file opener. webbrowser allows for this by allowing the user to specify a file opener in an environment variable. Gnome (or was it KDE?) uses OPENER for that. I'd suggest supporting that. I started to add support, then noticed that cmd was a list of strings, and you can't really specify that in an environment variable, so it needs to be encoded somehow. I'm going to leave that to someone more interested in the problem. KDE Components->File Associations to do that. All of those editors are installed on my machine. Then I attempted to open this text file: $ file /home/john/test.txt /home/john/test.txt: ASCII text $ cat /home/john/test.txt hello, world $ When I open it by clicking on it from a Konqueror directory listing, GNU emacs running in an X11 window starts up, with the specified file opened. When I use your module: $ python2.4 Python 2.4 (#1, Feb 19 2005, 23:54:54) [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import desktop >>> desktop.open("/home/john/blocking.txt") >>> ...it opens in Konqueror with some embedded editor (KEdit or KWrite, I assume), not directly in any of the editors I specified, and certainly not in emacs. Same applies if I use a URL: >>> desktop.open("file:///home/john/test.txt") This doesn't seem to be the intended behaviour of your module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 From noreply at sourceforge.net Sat Sep 24 23:39:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Sep 2005 14:39:31 -0700 Subject: [Patches] [ python-Patches-1301512 ] desktop module (providing startfile as open, all platforms) Message-ID: Patches item #1301512, was opened at 2005-09-23 18:30 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: desktop module (providing startfile as open, all platforms) Initial Comment: Currently, in Python's standard library, there is apparently no coherent, cross-platform way of getting the user's environment to "open" files or resources (ie. show such files in browsers, editors) when requested by a Python program. There is an os.startfile function which works for Windows, but no equivalent function for other desktop environments - the webbrowser module seems to employ alternative mechanisms in choosing and running external programs and presumably does not seek to provide general support for non-URL resources anyway. Since desktop environments like KDE and GNOME provide mechanisms for running browsers and editors according to the identified type of a file or resource, just as Windows "runs" files or resources, it is appropriate to have a module which accesses these mechanisms. Attached is a simple module which seeks to support KDE, GNOME and Windows - the latter using the existing os.startfile support - and which could be extended to support other desktop environments such as Mac OS X, XFCE, CDE (along with others deemed important and feasible enough to support). Note that this approach is arguably better than that employed by the webbrowser module since most desktop environments already provide mechanisms for configuring and choosing the user's preferred programs for various activities, whereas the webbrowser module makes relatively uninformed guesses (eg. opening Firefox on a KDE desktop configured to use Konqueror as the default browser). Note also that the startfile function is arguably misplaced in the os module; thus, this functionality is supplied as a new module rather than as a patch to the os module, and the name of the function is "open" (like in the webbrowser module) rather than "startfile" which is a fairly Windows specific term. One could also envisage the desktop module residing within the os package to avoid top-level namespace pollution. Recent discussion in the comp.lang.python thread "Open PDF" covering this issue can be found here: http://groups.google.no/group/comp.lang.python/browse_frm/thread/8e00f7c1ccfae166/6168b6728cf64cb7 ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2005-09-24 23:39 Message: Logged In: YES user_id=226443 Several good points, Mike! (And I wondered where your own open program would fit in here.) The major problem with webbrowser is that it either uses obsolete techniques or just leaves most of the work to the caller. Moreover, it has to keep pace with the range of applicable programs, which is more work than just keeping up with relevant desktop environments even for such a restricted domain. Mike, John: the motivation for this module was that os.startfile hooks into the Windows API in order to follow the user preferences reliably stored elsewhere, yet there aren't equivalent functions for other systems, despite the fact that such functions have been around for some time. I think "kfmclient exec" may be the way to go for KDE, by the way. As for Windows, I do recall entering URLs at the command line, but I don't recall whether Windows observed my desktop preferences, although I do seem to remember it launching Acrobat Reader for remote PDF resources. Someone else would have to verify that, though. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-24 23:28 Message: Logged In: YES user_id=261020 Oops, s/StartFileEx()/ShellExecuteEx()/ Paul: What are we actually trying to do here? 1) Open arbitrary files (possibly by means of a URL) using the method that the desktop user has configured his desktop / OS? Or 2) open arbitrary URLs in the web browser he has configured (possibly making use of GUI components embedded in the browser)? Or 3) something else? If 1) (which is what I had gathered from your initial comment and the c.l.py thread you referenced), then I guess ShellExecute (os.startfile) is right, as is kfmclient exec, and we just have to accept there are security implications that need to be borne in mind and acted upon appropriately (I'm not certain what that entails). Are there really major security differences between kfmclient exec and ShellExecute here? If 2). then it seems that we're doing two different things on the two different desktops we're talking about: kfmclient has openUrl, but ShellExecute doesn't have any equivalent (I assume the "explore" verb always lands you in IE / Windows Explorer, never firefox, for example). Perhaps unavoidable, but weakens the case for the module. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-24 20:53 Message: Logged In: YES user_id=93910 The code to support Mac OS X is: if sys.platform == 'darwin': cmd = ['open'] etc. While the commentary that webbrowser does it wrong is on target, the proposed code resembles that more than one would like. Both webbrowser and desktop poke around the system to make a guess as to what application they should be using. This is fine, so long as they guess right. The problems is if they guess wrong. There's an OSS replacement for open on the Mac, and just because a box isn't running GNOME or KDE doesn't mean it's Windows, or doesn't have a file opener. webbrowser allows for this by allowing the user to specify a file opener in an environment variable. Gnome (or was it KDE?) uses OPENER for that. I'd suggest supporting that. I started to add support, then noticed that cmd was a list of strings, and you can't really specify that in an environment variable, so it needs to be encoded somehow. I'm going to leave that to someone more interested in the problem. KDE Components->File Associations to do that. All of those editors are installed on my machine. Then I attempted to open this text file: $ file /home/john/test.txt /home/john/test.txt: ASCII text $ cat /home/john/test.txt hello, world $ When I open it by clicking on it from a Konqueror directory listing, GNU emacs running in an X11 window starts up, with the specified file opened. When I use your module: $ python2.4 Python 2.4 (#1, Feb 19 2005, 23:54:54) [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import desktop >>> desktop.open("/home/john/blocking.txt") >>> ...it opens in Konqueror with some embedded editor (KEdit or KWrite, I assume), not directly in any of the editors I specified, and certainly not in emacs. Same applies if I use a URL: >>> desktop.open("file:///home/john/test.txt") This doesn't seem to be the intended behaviour of your module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 From noreply at sourceforge.net Sun Sep 25 01:06:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Sep 2005 16:06:35 -0700 Subject: [Patches] [ python-Patches-1303595 ] Update documentation for __builtins__ Message-ID: Patches item #1303595, was opened at 2005-09-24 19:06 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=1303595&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Update documentation for __builtins__ Initial Comment: If applied, this patch would explicitly tell users that they should be using __builtin__ to override built-in functions, rather than __builtins__. The patch would also add documentation clairifying that __builtins__ is a module when in __main__ and a dictionary anywhere else. This diff was made against dist/src/Doc/ref/ref4.tex, version 1.38 from CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1303595&group_id=5470 From noreply at sourceforge.net Sun Sep 25 01:54:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Sep 2005 16:54:11 -0700 Subject: [Patches] [ python-Patches-1049855 ] PyOS_InputHook inconsistency on Windows Message-ID: Patches item #1049855, was opened at 2004-10-19 18:03 Message generated for change (Comment added) made by mdehoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1049855&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Nobody/Anonymous (nobody) Summary: PyOS_InputHook inconsistency on Windows Initial Comment: PyOS_InputHook is a pointer to a function to be called periodically when Python is idle. It is used, for example, to get messages delivered to graphics windows. If I compile Python from source (which uses Modules/readline.c), PyOS_InputHook is called ten times per second. However, with the Windows-version of Python, PyOS_InputHook is called only once for each command typed by the user. It seems that the problem resides in Parser/myreadline.c (which I presume is used for the Windows-version of Python): if (PyOS_InputHook != NULL) (void)(PyOS_InputHook)(); ... p = fgets(buf, len, fp); Python idles at "fgets", but PyOS_InputHook is not being called while Python is idle. The attached patch solves this problem by using the "select" function, basically in the same way as what is in Module/readline.c. I don't know how to compile Python for Windows, so I wasn't able to test this patch. ---------------------------------------------------------------------- >Comment By: Michiel de Hoon (mdehoon) Date: 2005-09-25 08:54 Message: Logged In: YES user_id=488897 Your comments made me realize that since fixing PyOS_InputHook's behavior is potentially too disruptive, it's probably better not to do that with a simple patch. So I think it's best to reject this patch. PyOS_InputHook and event loops in general probably should be discussed in some more detail on python-dev before making changes to Python. For the record, I wrote a response to the three issues you raised. You are right of course on #1, but I don't think #2 and #3 are valid --see below. Thanks for looking at this patch. #1: > if the system is not windows, it invokes select > unconditionally; this should be conditioned with HAVE_SELECT You are certainly right here. While this patch can probably be fixed, this code would have to be tested on a large number of platformsto make sure this patch won't break python for somebody (which is why I'm shying away from doing this in a patch right now). #2 > the Windows version uses kbhit; this may or may not > operate on the same handle as hStdIn. In fact, it likely is > a different handle. See the source code of the crt: kbhit > uses _coninpfh, which is created from opening CONIN$. Try > using GetNumberOfConsoleInputEvents/PeekConsoleInput > instead, checking for a KEY_EVENT event. In the patch, I test if the file descriptor is a tty. The _kbhit() function is called only if that is the case. So AFAICT, using _coninpfh is the right thing to do. Note also that the same code is already being used in _tkinter: In the EventHook function, _kbhit is used to decide if the program should return from the EventHook function because input is available at stdin. So essentially, I am moving code from _tkinter to Python's main loop, to make it available for extension modules other than _tkinter. I'm not sure how GetNumberOfConsoleInputEvents or PeekConsoleInput would help us. #3 > as stdin may be buffered, it may be the case that there is > already input available, even though the file descriptor is > not ready. I don't think the situation can occur in which select blocks although input is already available in the buffer used by fgets. With thanks to comp.unix.programmer: If python is reading input from a tty, the input mode is line buffered. Each time the user hits return, a complete line is available to fgets, so buffering is not a problem. If, however, python is reading input from disk, the input mode is block buffered. When the end of the file is reached, EOF is flagged, and select will return immediately. So if fgets reads a block of data and stores it in its buffer, and still more data is available in the file, the file descriptor will be ready and select returns. If, however, fgets reads the last block of data and stores it in its buffer, EOF is set, so select won't block in this case either. Note that this is also code that already exists in Python's _tkinter. If _tkinter is imported, before calling fgets, Python sits in a loop inside the EventHook function. Except on Windows platforms, the fileno of stdin is passed to Tcl_CreateFileHandler, where it is used in a call to select inside the Tcl_WaitForEvent function. The call to select will trigger a call to MyFileProc in _tkinter.c if input is available, causing EventHook to return so that fgets can be called. So essentially, the same code exists already inside _tkinter (with the call to select buried inside Tcl). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-08 03:25 Message: Logged In: YES user_id=21627 I think this code is way too fragile to be applied to 2.4. As for specific errors I could find: - if the system is not windows, it invokes select unconditionally; this should be conditioned with HAVE_SELECT - the Windows version uses kbhit; this may or may not operate on the same handle as hStdIn. In fact, it likely is a different handle. See the source code of the crt: kbhit uses _coninpfh, which is created from opening CONIN$. Try using GetNumberOfConsoleInputEvents/PeekConsoleInput instead, checking for a KEY_EVENT event. - as stdin may be buffered, it may be the case that there is already input available, even though the file descriptor is not ready. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-08-06 06:07 Message: Logged In: YES user_id=488897 One more fix: I noticed that on Windows, the patch causes the CPU usage to go up to 100%. The reason for this is that if the users presses a control key (e.g. shift), the WaitForSingleObject function returns, but _kbhit() returns false since no character input is waiting in the buffer. Hence, the loop continues to run, and WaitForSingleObject will again return because the control key stroke has not been flushed from the buffer. The fix is in the patch dated 20050803, which is to flush the buffer with FlushConsoleInputBuffer if a key was hit but no character input is available. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-07-29 11:40 Message: Logged In: YES user_id=488897 I have found a solution for the problem described below ("python -i < inputfile.py" behaves differently). The solution was to use _isatty to check if stdin is redirected, and check for keyboard input only if stdin is not redirected. With the latest version of this patch (20050728), there are no changes in Python's behaviour on Windows or Unix (except that PyOS_InputHook is called ten times per second, which is what this patch intends to solve). I apologize for the fact that multiple iterations were needed to converge to the right (I hope) solution for this bug. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-07-16 11:14 Message: Logged In: YES user_id=488897 I have now recompiled Python on Windows to test this patch. When compiling this patch, I found out that _get_osfhandle needs to be cast to a HANDLE*. The latest version of this patch (dated 20050715) includes this cast. I have tested this patch by running the test suite. One note: Whereas "python -i inputfile.py" and "python < inputfile.py" work as expected, "python -i < inputfile.py" behaves differently with this patch (python waits for the user to hit enter before proceeding). I am not sure if this is significant, as I wouldn't know what a user might try to achieve with "python -i < inputfile.py". I'd be happy to send a binary for Windows to anybody who would like to test this patch. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-06-11 05:46 Message: Logged In: YES user_id=488897 Thomas Heller sent me this comment: > The PyOS_StdioReadline function calls my_fgets with a file > pointer argument. The my_fgets function in the patch assumes > that STD_INPUT_HANDLE is the handle to use - is this > assumption always correct? He is right, this assumption is not necessarily correct. I have made a new patch (labeled 20050610) to solve this issue. This latest version has been tested on Cygwin, but not yet on Windows -- I need to dig up a compiler for Windows first. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-05-13 12:57 Message: Logged In: YES user_id=488897 I have rewritten the patch to include Windows support. I compiled Python on Windows with VC98, and on Linux and Mac OS X and found no problems with it. The new patch is attached. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-05-02 12:40 Message: Logged In: YES user_id=149084 Yeah, that's why I didn't want to check it in, I can't build on Windows ithe VC 5. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-05-02 11:52 Message: Logged In: YES user_id=488897 Thanks for looking at this patch. Today I found out that it is possible to compile Python 2.4.1 with the older Microsoft Visual Studio 6.0, which I happen to have in my office. It turned out that the patch does not work correctly on Windows, due to the fact that the "select" function doesn't work with stdin on Windows. I will fix the patch so it'll work on Windows too. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-05-01 03:21 Message: Logged In: YES user_id=149084 The revised patch looks ok to me. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-03-26 22:33 Message: Logged In: YES user_id=488897 I have now tested this patch. After fixing one error (I had forgotton to declare one variable), the patch works correctly. I have uploaded a fixed patch. Note that this bug occurs not only on Windows, but on any Python compiled without readline. (which allowed me to test this patch by compiling Python without readline support). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1049855&group_id=5470 From noreply at sourceforge.net Sun Sep 25 03:01:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Sep 2005 18:01:50 -0700 Subject: [Patches] [ python-Patches-1301512 ] desktop module (providing startfile as open, all platforms) Message-ID: Patches item #1301512, was opened at 2005-09-23 11:30 Message generated for change (Comment added) made by mwm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: desktop module (providing startfile as open, all platforms) Initial Comment: Currently, in Python's standard library, there is apparently no coherent, cross-platform way of getting the user's environment to "open" files or resources (ie. show such files in browsers, editors) when requested by a Python program. There is an os.startfile function which works for Windows, but no equivalent function for other desktop environments - the webbrowser module seems to employ alternative mechanisms in choosing and running external programs and presumably does not seek to provide general support for non-URL resources anyway. Since desktop environments like KDE and GNOME provide mechanisms for running browsers and editors according to the identified type of a file or resource, just as Windows "runs" files or resources, it is appropriate to have a module which accesses these mechanisms. Attached is a simple module which seeks to support KDE, GNOME and Windows - the latter using the existing os.startfile support - and which could be extended to support other desktop environments such as Mac OS X, XFCE, CDE (along with others deemed important and feasible enough to support). Note that this approach is arguably better than that employed by the webbrowser module since most desktop environments already provide mechanisms for configuring and choosing the user's preferred programs for various activities, whereas the webbrowser module makes relatively uninformed guesses (eg. opening Firefox on a KDE desktop configured to use Konqueror as the default browser). Note also that the startfile function is arguably misplaced in the os module; thus, this functionality is supplied as a new module rather than as a patch to the os module, and the name of the function is "open" (like in the webbrowser module) rather than "startfile" which is a fairly Windows specific term. One could also envisage the desktop module residing within the os package to avoid top-level namespace pollution. Recent discussion in the comp.lang.python thread "Open PDF" covering this issue can be found here: http://groups.google.no/group/comp.lang.python/browse_frm/thread/8e00f7c1ccfae166/6168b6728cf64cb7 ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-24 20:01 Message: Logged In: YES user_id=93910 open is a desktop-independent variation on gnome-open and kfmclient. So it's something that desktop could be set up to run, using cmd = ["open", url]. On the other hand, it also exposes an API to Python progams, so you could (in theory) replace Unix-specific parts of desktop with (using the development version): from open import run run(filename, have = ['open']) except that it'd use the users "open" preferences instead of their desktop preferences. This is why I proposed the OPENER environment variable. I don't run a desktop, so the proposed version would default to trying os.startfile. I'd rather it use open. KDE Components->File Associations to do that. All of those editors are installed on my machine. Then I attempted to open this text file: $ file /home/john/test.txt /home/john/test.txt: ASCII text $ cat /home/john/test.txt hello, world $ When I open it by clicking on it from a Konqueror directory listing, GNU emacs running in an X11 window starts up, with the specified file opened. When I use your module: $ python2.4 Python 2.4 (#1, Feb 19 2005, 23:54:54) [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import desktop >>> desktop.open("/home/john/blocking.txt") >>> ...it opens in Konqueror with some embedded editor (KEdit or KWrite, I assume), not directly in any of the editors I specified, and certainly not in emacs. Same applies if I use a URL: >>> desktop.open("file:///home/john/test.txt") This doesn't seem to be the intended behaviour of your module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 From noreply at sourceforge.net Sun Sep 25 06:29:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Sep 2005 21:29:26 -0700 Subject: [Patches] [ python-Patches-1049855 ] PyOS_InputHook inconsistency on Windows Message-ID: Patches item #1049855, was opened at 2004-10-19 11:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1049855&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Nobody/Anonymous (nobody) Summary: PyOS_InputHook inconsistency on Windows Initial Comment: PyOS_InputHook is a pointer to a function to be called periodically when Python is idle. It is used, for example, to get messages delivered to graphics windows. If I compile Python from source (which uses Modules/readline.c), PyOS_InputHook is called ten times per second. However, with the Windows-version of Python, PyOS_InputHook is called only once for each command typed by the user. It seems that the problem resides in Parser/myreadline.c (which I presume is used for the Windows-version of Python): if (PyOS_InputHook != NULL) (void)(PyOS_InputHook)(); ... p = fgets(buf, len, fp); Python idles at "fgets", but PyOS_InputHook is not being called while Python is idle. The attached patch solves this problem by using the "select" function, basically in the same way as what is in Module/readline.c. I don't know how to compile Python for Windows, so I wasn't able to test this patch. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-09-25 06:29 Message: Logged In: YES user_id=21627 Rejecting as suggested. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-09-25 01:54 Message: Logged In: YES user_id=488897 Your comments made me realize that since fixing PyOS_InputHook's behavior is potentially too disruptive, it's probably better not to do that with a simple patch. So I think it's best to reject this patch. PyOS_InputHook and event loops in general probably should be discussed in some more detail on python-dev before making changes to Python. For the record, I wrote a response to the three issues you raised. You are right of course on #1, but I don't think #2 and #3 are valid --see below. Thanks for looking at this patch. #1: > if the system is not windows, it invokes select > unconditionally; this should be conditioned with HAVE_SELECT You are certainly right here. While this patch can probably be fixed, this code would have to be tested on a large number of platformsto make sure this patch won't break python for somebody (which is why I'm shying away from doing this in a patch right now). #2 > the Windows version uses kbhit; this may or may not > operate on the same handle as hStdIn. In fact, it likely is > a different handle. See the source code of the crt: kbhit > uses _coninpfh, which is created from opening CONIN$. Try > using GetNumberOfConsoleInputEvents/PeekConsoleInput > instead, checking for a KEY_EVENT event. In the patch, I test if the file descriptor is a tty. The _kbhit() function is called only if that is the case. So AFAICT, using _coninpfh is the right thing to do. Note also that the same code is already being used in _tkinter: In the EventHook function, _kbhit is used to decide if the program should return from the EventHook function because input is available at stdin. So essentially, I am moving code from _tkinter to Python's main loop, to make it available for extension modules other than _tkinter. I'm not sure how GetNumberOfConsoleInputEvents or PeekConsoleInput would help us. #3 > as stdin may be buffered, it may be the case that there is > already input available, even though the file descriptor is > not ready. I don't think the situation can occur in which select blocks although input is already available in the buffer used by fgets. With thanks to comp.unix.programmer: If python is reading input from a tty, the input mode is line buffered. Each time the user hits return, a complete line is available to fgets, so buffering is not a problem. If, however, python is reading input from disk, the input mode is block buffered. When the end of the file is reached, EOF is flagged, and select will return immediately. So if fgets reads a block of data and stores it in its buffer, and still more data is available in the file, the file descriptor will be ready and select returns. If, however, fgets reads the last block of data and stores it in its buffer, EOF is set, so select won't block in this case either. Note that this is also code that already exists in Python's _tkinter. If _tkinter is imported, before calling fgets, Python sits in a loop inside the EventHook function. Except on Windows platforms, the fileno of stdin is passed to Tcl_CreateFileHandler, where it is used in a call to select inside the Tcl_WaitForEvent function. The call to select will trigger a call to MyFileProc in _tkinter.c if input is available, causing EventHook to return so that fgets can be called. So essentially, the same code exists already inside _tkinter (with the call to select buried inside Tcl). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-07 20:25 Message: Logged In: YES user_id=21627 I think this code is way too fragile to be applied to 2.4. As for specific errors I could find: - if the system is not windows, it invokes select unconditionally; this should be conditioned with HAVE_SELECT - the Windows version uses kbhit; this may or may not operate on the same handle as hStdIn. In fact, it likely is a different handle. See the source code of the crt: kbhit uses _coninpfh, which is created from opening CONIN$. Try using GetNumberOfConsoleInputEvents/PeekConsoleInput instead, checking for a KEY_EVENT event. - as stdin may be buffered, it may be the case that there is already input available, even though the file descriptor is not ready. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-08-05 23:07 Message: Logged In: YES user_id=488897 One more fix: I noticed that on Windows, the patch causes the CPU usage to go up to 100%. The reason for this is that if the users presses a control key (e.g. shift), the WaitForSingleObject function returns, but _kbhit() returns false since no character input is waiting in the buffer. Hence, the loop continues to run, and WaitForSingleObject will again return because the control key stroke has not been flushed from the buffer. The fix is in the patch dated 20050803, which is to flush the buffer with FlushConsoleInputBuffer if a key was hit but no character input is available. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-07-29 04:40 Message: Logged In: YES user_id=488897 I have found a solution for the problem described below ("python -i < inputfile.py" behaves differently). The solution was to use _isatty to check if stdin is redirected, and check for keyboard input only if stdin is not redirected. With the latest version of this patch (20050728), there are no changes in Python's behaviour on Windows or Unix (except that PyOS_InputHook is called ten times per second, which is what this patch intends to solve). I apologize for the fact that multiple iterations were needed to converge to the right (I hope) solution for this bug. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-07-16 04:14 Message: Logged In: YES user_id=488897 I have now recompiled Python on Windows to test this patch. When compiling this patch, I found out that _get_osfhandle needs to be cast to a HANDLE*. The latest version of this patch (dated 20050715) includes this cast. I have tested this patch by running the test suite. One note: Whereas "python -i inputfile.py" and "python < inputfile.py" work as expected, "python -i < inputfile.py" behaves differently with this patch (python waits for the user to hit enter before proceeding). I am not sure if this is significant, as I wouldn't know what a user might try to achieve with "python -i < inputfile.py". I'd be happy to send a binary for Windows to anybody who would like to test this patch. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-06-10 22:46 Message: Logged In: YES user_id=488897 Thomas Heller sent me this comment: > The PyOS_StdioReadline function calls my_fgets with a file > pointer argument. The my_fgets function in the patch assumes > that STD_INPUT_HANDLE is the handle to use - is this > assumption always correct? He is right, this assumption is not necessarily correct. I have made a new patch (labeled 20050610) to solve this issue. This latest version has been tested on Cygwin, but not yet on Windows -- I need to dig up a compiler for Windows first. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-05-13 05:57 Message: Logged In: YES user_id=488897 I have rewritten the patch to include Windows support. I compiled Python on Windows with VC98, and on Linux and Mac OS X and found no problems with it. The new patch is attached. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-05-02 05:40 Message: Logged In: YES user_id=149084 Yeah, that's why I didn't want to check it in, I can't build on Windows ithe VC 5. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-05-02 04:52 Message: Logged In: YES user_id=488897 Thanks for looking at this patch. Today I found out that it is possible to compile Python 2.4.1 with the older Microsoft Visual Studio 6.0, which I happen to have in my office. It turned out that the patch does not work correctly on Windows, due to the fact that the "select" function doesn't work with stdin on Windows. I will fix the patch so it'll work on Windows too. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-04-30 20:21 Message: Logged In: YES user_id=149084 The revised patch looks ok to me. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2005-03-26 14:33 Message: Logged In: YES user_id=488897 I have now tested this patch. After fixing one error (I had forgotton to declare one variable), the patch works correctly. I have uploaded a fixed patch. Note that this bug occurs not only on Windows, but on any Python compiled without readline. (which allowed me to test this patch by compiling Python without readline support). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1049855&group_id=5470 From noreply at sourceforge.net Sun Sep 25 06:30:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Sep 2005 21:30:50 -0700 Subject: [Patches] [ python-Patches-1299675 ] fix for distutils "upload" command Message-ID: Patches item #1299675, was opened at 2005-09-23 05:23 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1299675&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) >Assigned to: Martin v. L?wis (loewis) Summary: fix for distutils "upload" command Initial Comment: This patch fixes distutils/command/upload.py so it can talk to an improved PyPI interface. Specifically, it allows upload of a file for an un"register"ed release. Should be applied against CVS HEAD. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1299675&group_id=5470 From noreply at sourceforge.net Sun Sep 25 16:26:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Sep 2005 07:26:47 -0700 Subject: [Patches] [ python-Patches-1301512 ] desktop module (providing startfile as open, all platforms) Message-ID: Patches item #1301512, was opened at 2005-09-23 18:30 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: desktop module (providing startfile as open, all platforms) Initial Comment: Currently, in Python's standard library, there is apparently no coherent, cross-platform way of getting the user's environment to "open" files or resources (ie. show such files in browsers, editors) when requested by a Python program. There is an os.startfile function which works for Windows, but no equivalent function for other desktop environments - the webbrowser module seems to employ alternative mechanisms in choosing and running external programs and presumably does not seek to provide general support for non-URL resources anyway. Since desktop environments like KDE and GNOME provide mechanisms for running browsers and editors according to the identified type of a file or resource, just as Windows "runs" files or resources, it is appropriate to have a module which accesses these mechanisms. Attached is a simple module which seeks to support KDE, GNOME and Windows - the latter using the existing os.startfile support - and which could be extended to support other desktop environments such as Mac OS X, XFCE, CDE (along with others deemed important and feasible enough to support). Note that this approach is arguably better than that employed by the webbrowser module since most desktop environments already provide mechanisms for configuring and choosing the user's preferred programs for various activities, whereas the webbrowser module makes relatively uninformed guesses (eg. opening Firefox on a KDE desktop configured to use Konqueror as the default browser). Note also that the startfile function is arguably misplaced in the os module; thus, this functionality is supplied as a new module rather than as a patch to the os module, and the name of the function is "open" (like in the webbrowser module) rather than "startfile" which is a fairly Windows specific term. One could also envisage the desktop module residing within the os package to avoid top-level namespace pollution. Recent discussion in the comp.lang.python thread "Open PDF" covering this issue can be found here: http://groups.google.no/group/comp.lang.python/browse_frm/thread/8e00f7c1ccfae166/6168b6728cf64cb7 ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2005-09-25 16:26 Message: Logged In: YES user_id=226443 I've uploaded a version which supports OPENER, although I can't find any references to that variable anywhere. By the way, I wonder if the open program's preferences couldn't somehow work with the various freedesktop.org standards if they don't already. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-25 03:01 Message: Logged In: YES user_id=93910 open is a desktop-independent variation on gnome-open and kfmclient. So it's something that desktop could be set up to run, using cmd = ["open", url]. On the other hand, it also exposes an API to Python progams, so you could (in theory) replace Unix-specific parts of desktop with (using the development version): from open import run run(filename, have = ['open']) except that it'd use the users "open" preferences instead of their desktop preferences. This is why I proposed the OPENER environment variable. I don't run a desktop, so the proposed version would default to trying os.startfile. I'd rather it use open. KDE Components->File Associations to do that. All of those editors are installed on my machine. Then I attempted to open this text file: $ file /home/john/test.txt /home/john/test.txt: ASCII text $ cat /home/john/test.txt hello, world $ When I open it by clicking on it from a Konqueror directory listing, GNU emacs running in an X11 window starts up, with the specified file opened. When I use your module: $ python2.4 Python 2.4 (#1, Feb 19 2005, 23:54:54) [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import desktop >>> desktop.open("/home/john/blocking.txt") >>> ...it opens in Konqueror with some embedded editor (KEdit or KWrite, I assume), not directly in any of the editors I specified, and certainly not in emacs. Same applies if I use a URL: >>> desktop.open("file:///home/john/test.txt") This doesn't seem to be the intended behaviour of your module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 From noreply at sourceforge.net Sun Sep 25 17:57:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Sep 2005 08:57:39 -0700 Subject: [Patches] [ python-Patches-1301512 ] desktop module (providing startfile as open, all platforms) Message-ID: Patches item #1301512, was opened at 2005-09-23 17:30 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: desktop module (providing startfile as open, all platforms) Initial Comment: Currently, in Python's standard library, there is apparently no coherent, cross-platform way of getting the user's environment to "open" files or resources (ie. show such files in browsers, editors) when requested by a Python program. There is an os.startfile function which works for Windows, but no equivalent function for other desktop environments - the webbrowser module seems to employ alternative mechanisms in choosing and running external programs and presumably does not seek to provide general support for non-URL resources anyway. Since desktop environments like KDE and GNOME provide mechanisms for running browsers and editors according to the identified type of a file or resource, just as Windows "runs" files or resources, it is appropriate to have a module which accesses these mechanisms. Attached is a simple module which seeks to support KDE, GNOME and Windows - the latter using the existing os.startfile support - and which could be extended to support other desktop environments such as Mac OS X, XFCE, CDE (along with others deemed important and feasible enough to support). Note that this approach is arguably better than that employed by the webbrowser module since most desktop environments already provide mechanisms for configuring and choosing the user's preferred programs for various activities, whereas the webbrowser module makes relatively uninformed guesses (eg. opening Firefox on a KDE desktop configured to use Konqueror as the default browser). Note also that the startfile function is arguably misplaced in the os module; thus, this functionality is supplied as a new module rather than as a patch to the os module, and the name of the function is "open" (like in the webbrowser module) rather than "startfile" which is a fairly Windows specific term. One could also envisage the desktop module residing within the os package to avoid top-level namespace pollution. Recent discussion in the comp.lang.python thread "Open PDF" covering this issue can be found here: http://groups.google.no/group/comp.lang.python/browse_frm/thread/8e00f7c1ccfae166/6168b6728cf64cb7 ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-25 16:57 Message: Logged In: YES user_id=261020 If OPENER is not standard in any way (ad hoc or otherwise), why add it? Moght not doing that without talking to other people about it (presumably on freedesktop, including GNOME, KDE. etc. people) be positively harmful? Mike: is this Python version of Apple's "open" actually published on the web somewhere? I can't find it. I also notice that "open" is already in use as a shell wrapper around open (2) the system call. "start" seems unused, FWTW here. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-25 15:26 Message: Logged In: YES user_id=226443 I've uploaded a version which supports OPENER, although I can't find any references to that variable anywhere. By the way, I wonder if the open program's preferences couldn't somehow work with the various freedesktop.org standards if they don't already. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-25 02:01 Message: Logged In: YES user_id=93910 open is a desktop-independent variation on gnome-open and kfmclient. So it's something that desktop could be set up to run, using cmd = ["open", url]. On the other hand, it also exposes an API to Python progams, so you could (in theory) replace Unix-specific parts of desktop with (using the development version): from open import run run(filename, have = ['open']) except that it'd use the users "open" preferences instead of their desktop preferences. This is why I proposed the OPENER environment variable. I don't run a desktop, so the proposed version would default to trying os.startfile. I'd rather it use open. KDE Components->File Associations to do that. All of those editors are installed on my machine. Then I attempted to open this text file: $ file /home/john/test.txt /home/john/test.txt: ASCII text $ cat /home/john/test.txt hello, world $ When I open it by clicking on it from a Konqueror directory listing, GNU emacs running in an X11 window starts up, with the specified file opened. When I use your module: $ python2.4 Python 2.4 (#1, Feb 19 2005, 23:54:54) [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import desktop >>> desktop.open("/home/john/blocking.txt") >>> ...it opens in Konqueror with some embedded editor (KEdit or KWrite, I assume), not directly in any of the editors I specified, and certainly not in emacs. Same applies if I use a URL: >>> desktop.open("file:///home/john/test.txt") This doesn't seem to be the intended behaviour of your module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 From noreply at sourceforge.net Sun Sep 25 18:06:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Sep 2005 09:06:25 -0700 Subject: [Patches] [ python-Patches-1303595 ] Update documentation for __builtins__ Message-ID: Patches item #1303595, was opened at 2005-09-25 01:06 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1303595&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Update documentation for __builtins__ Initial Comment: If applied, this patch would explicitly tell users that they should be using __builtin__ to override built-in functions, rather than __builtins__. The patch would also add documentation clairifying that __builtins__ is a module when in __main__ and a dictionary anywhere else. This diff was made against dist/src/Doc/ref/ref4.tex, version 1.38 from CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1303595&group_id=5470 From noreply at sourceforge.net Mon Sep 26 00:01:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Sep 2005 15:01:52 -0700 Subject: [Patches] [ python-Patches-1301512 ] desktop module (providing startfile as open, all platforms) Message-ID: Patches item #1301512, was opened at 2005-09-23 11:30 Message generated for change (Comment added) made by mwm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: desktop module (providing startfile as open, all platforms) Initial Comment: Currently, in Python's standard library, there is apparently no coherent, cross-platform way of getting the user's environment to "open" files or resources (ie. show such files in browsers, editors) when requested by a Python program. There is an os.startfile function which works for Windows, but no equivalent function for other desktop environments - the webbrowser module seems to employ alternative mechanisms in choosing and running external programs and presumably does not seek to provide general support for non-URL resources anyway. Since desktop environments like KDE and GNOME provide mechanisms for running browsers and editors according to the identified type of a file or resource, just as Windows "runs" files or resources, it is appropriate to have a module which accesses these mechanisms. Attached is a simple module which seeks to support KDE, GNOME and Windows - the latter using the existing os.startfile support - and which could be extended to support other desktop environments such as Mac OS X, XFCE, CDE (along with others deemed important and feasible enough to support). Note that this approach is arguably better than that employed by the webbrowser module since most desktop environments already provide mechanisms for configuring and choosing the user's preferred programs for various activities, whereas the webbrowser module makes relatively uninformed guesses (eg. opening Firefox on a KDE desktop configured to use Konqueror as the default browser). Note also that the startfile function is arguably misplaced in the os module; thus, this functionality is supplied as a new module rather than as a patch to the os module, and the name of the function is "open" (like in the webbrowser module) rather than "startfile" which is a fairly Windows specific term. One could also envisage the desktop module residing within the os package to avoid top-level namespace pollution. Recent discussion in the comp.lang.python thread "Open PDF" covering this issue can be found here: http://groups.google.no/group/comp.lang.python/browse_frm/thread/8e00f7c1ccfae166/6168b6728cf64cb7 ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-25 17:01 Message: Logged In: YES user_id=93910 I suggested OPENER because I saw it in use somewhere while looking for things for open. I couldn't find it when I went looking for it to reply to this. Clearly, the desktop module needs some way for the user to say "I don't care what you think the system looks like - use *this*." If there's a standard for that, we should use it. If there isn't a standard, we get to establish one. Putting it in the beta version so people can play with it is a good idea. Until the module is accepted, nothing is wired down, and testers should know that. Open has been announced in a number of places. It doesn't have it's own web page yet. You can find a link to the tarball at http://www.mired.org/downloads/. It's also listed in PyPI. Other than it's existence showing that desktop needs a way for user to override the guesses the module makes (which the OSS launch tool does for OS X as well), this isn't really the place to discuss open. I've addressed the issues raised here about open in the README file that was posted in the 0.3 version. Further discussion should go to me directly, or to the Python list/newsgroup. If you think it belongs in another forum, please let me know. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-25 10:57 Message: Logged In: YES user_id=261020 If OPENER is not standard in any way (ad hoc or otherwise), why add it? Moght not doing that without talking to other people about it (presumably on freedesktop, including GNOME, KDE. etc. people) be positively harmful? Mike: is this Python version of Apple's "open" actually published on the web somewhere? I can't find it. I also notice that "open" is already in use as a shell wrapper around open (2) the system call. "start" seems unused, FWTW here. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-25 09:26 Message: Logged In: YES user_id=226443 I've uploaded a version which supports OPENER, although I can't find any references to that variable anywhere. By the way, I wonder if the open program's preferences couldn't somehow work with the various freedesktop.org standards if they don't already. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-24 20:01 Message: Logged In: YES user_id=93910 open is a desktop-independent variation on gnome-open and kfmclient. So it's something that desktop could be set up to run, using cmd = ["open", url]. On the other hand, it also exposes an API to Python progams, so you could (in theory) replace Unix-specific parts of desktop with (using the development version): from open import run run(filename, have = ['open']) except that it'd use the users "open" preferences instead of their desktop preferences. This is why I proposed the OPENER environment variable. I don't run a desktop, so the proposed version would default to trying os.startfile. I'd rather it use open. KDE Components->File Associations to do that. All of those editors are installed on my machine. Then I attempted to open this text file: $ file /home/john/test.txt /home/john/test.txt: ASCII text $ cat /home/john/test.txt hello, world $ When I open it by clicking on it from a Konqueror directory listing, GNU emacs running in an X11 window starts up, with the specified file opened. When I use your module: $ python2.4 Python 2.4 (#1, Feb 19 2005, 23:54:54) [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import desktop >>> desktop.open("/home/john/blocking.txt") >>> ...it opens in Konqueror with some embedded editor (KEdit or KWrite, I assume), not directly in any of the editors I specified, and certainly not in emacs. Same applies if I use a URL: >>> desktop.open("file:///home/john/test.txt") This doesn't seem to be the intended behaviour of your module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 From noreply at sourceforge.net Mon Sep 26 01:34:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Sep 2005 16:34:25 -0700 Subject: [Patches] [ python-Patches-1301512 ] desktop module (providing startfile as open, all platforms) Message-ID: Patches item #1301512, was opened at 2005-09-23 17:30 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: desktop module (providing startfile as open, all platforms) Initial Comment: Currently, in Python's standard library, there is apparently no coherent, cross-platform way of getting the user's environment to "open" files or resources (ie. show such files in browsers, editors) when requested by a Python program. There is an os.startfile function which works for Windows, but no equivalent function for other desktop environments - the webbrowser module seems to employ alternative mechanisms in choosing and running external programs and presumably does not seek to provide general support for non-URL resources anyway. Since desktop environments like KDE and GNOME provide mechanisms for running browsers and editors according to the identified type of a file or resource, just as Windows "runs" files or resources, it is appropriate to have a module which accesses these mechanisms. Attached is a simple module which seeks to support KDE, GNOME and Windows - the latter using the existing os.startfile support - and which could be extended to support other desktop environments such as Mac OS X, XFCE, CDE (along with others deemed important and feasible enough to support). Note that this approach is arguably better than that employed by the webbrowser module since most desktop environments already provide mechanisms for configuring and choosing the user's preferred programs for various activities, whereas the webbrowser module makes relatively uninformed guesses (eg. opening Firefox on a KDE desktop configured to use Konqueror as the default browser). Note also that the startfile function is arguably misplaced in the os module; thus, this functionality is supplied as a new module rather than as a patch to the os module, and the name of the function is "open" (like in the webbrowser module) rather than "startfile" which is a fairly Windows specific term. One could also envisage the desktop module residing within the os package to avoid top-level namespace pollution. Recent discussion in the comp.lang.python thread "Open PDF" covering this issue can be found here: http://groups.google.no/group/comp.lang.python/browse_frm/thread/8e00f7c1ccfae166/6168b6728cf64cb7 ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-26 00:34 Message: Logged In: YES user_id=261020 Why does the desktop module need something more than Paul's "desktop" argument? (Though perhaps "desktop" is not a sufficiently general name, as I think you said.) I don't think it's desirable for Python to start introducing half-baked and nonstandard environment variable conventions, especially in this area. 1. Why should other people start following *Python*'s convention here? 2. Any such convention may be overtaken by efforts with more backing (such as freedesktop), leaving us with cruft in the stdlib, perhaps even cruft that's in conflict with the new standards (what if somebody with actual clout mandates START instead? something will break). 3. Any program that wants to can follow this supposed OPENER convention, without needing to bake it into the stdlib. Having said all that, if you can get agreement from people at freedesktop to agree on OPENER (which might well be possible), and I guess set a useful default at desktop startup, I will worship at your feet ;-) I'm not sure what you mean by "the guesses that the module makes". It makes exactly one guess: which opener to use, and that guess is overridable with the "desktop" argument to open(). ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-25 23:01 Message: Logged In: YES user_id=93910 I suggested OPENER because I saw it in use somewhere while looking for things for open. I couldn't find it when I went looking for it to reply to this. Clearly, the desktop module needs some way for the user to say "I don't care what you think the system looks like - use *this*." If there's a standard for that, we should use it. If there isn't a standard, we get to establish one. Putting it in the beta version so people can play with it is a good idea. Until the module is accepted, nothing is wired down, and testers should know that. Open has been announced in a number of places. It doesn't have it's own web page yet. You can find a link to the tarball at http://www.mired.org/downloads/. It's also listed in PyPI. Other than it's existence showing that desktop needs a way for user to override the guesses the module makes (which the OSS launch tool does for OS X as well), this isn't really the place to discuss open. I've addressed the issues raised here about open in the README file that was posted in the 0.3 version. Further discussion should go to me directly, or to the Python list/newsgroup. If you think it belongs in another forum, please let me know. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-25 16:57 Message: Logged In: YES user_id=261020 If OPENER is not standard in any way (ad hoc or otherwise), why add it? Moght not doing that without talking to other people about it (presumably on freedesktop, including GNOME, KDE. etc. people) be positively harmful? Mike: is this Python version of Apple's "open" actually published on the web somewhere? I can't find it. I also notice that "open" is already in use as a shell wrapper around open (2) the system call. "start" seems unused, FWTW here. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-25 15:26 Message: Logged In: YES user_id=226443 I've uploaded a version which supports OPENER, although I can't find any references to that variable anywhere. By the way, I wonder if the open program's preferences couldn't somehow work with the various freedesktop.org standards if they don't already. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-25 02:01 Message: Logged In: YES user_id=93910 open is a desktop-independent variation on gnome-open and kfmclient. So it's something that desktop could be set up to run, using cmd = ["open", url]. On the other hand, it also exposes an API to Python progams, so you could (in theory) replace Unix-specific parts of desktop with (using the development version): from open import run run(filename, have = ['open']) except that it'd use the users "open" preferences instead of their desktop preferences. This is why I proposed the OPENER environment variable. I don't run a desktop, so the proposed version would default to trying os.startfile. I'd rather it use open. KDE Components->File Associations to do that. All of those editors are installed on my machine. Then I attempted to open this text file: $ file /home/john/test.txt /home/john/test.txt: ASCII text $ cat /home/john/test.txt hello, world $ When I open it by clicking on it from a Konqueror directory listing, GNU emacs running in an X11 window starts up, with the specified file opened. When I use your module: $ python2.4 Python 2.4 (#1, Feb 19 2005, 23:54:54) [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import desktop >>> desktop.open("/home/john/blocking.txt") >>> ...it opens in Konqueror with some embedded editor (KEdit or KWrite, I assume), not directly in any of the editors I specified, and certainly not in emacs. Same applies if I use a URL: >>> desktop.open("file:///home/john/test.txt") This doesn't seem to be the intended behaviour of your module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 From noreply at sourceforge.net Mon Sep 26 02:14:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Sep 2005 17:14:47 -0700 Subject: [Patches] [ python-Patches-1301512 ] desktop module (providing startfile as open, all platforms) Message-ID: Patches item #1301512, was opened at 2005-09-23 18:30 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: desktop module (providing startfile as open, all platforms) Initial Comment: Currently, in Python's standard library, there is apparently no coherent, cross-platform way of getting the user's environment to "open" files or resources (ie. show such files in browsers, editors) when requested by a Python program. There is an os.startfile function which works for Windows, but no equivalent function for other desktop environments - the webbrowser module seems to employ alternative mechanisms in choosing and running external programs and presumably does not seek to provide general support for non-URL resources anyway. Since desktop environments like KDE and GNOME provide mechanisms for running browsers and editors according to the identified type of a file or resource, just as Windows "runs" files or resources, it is appropriate to have a module which accesses these mechanisms. Attached is a simple module which seeks to support KDE, GNOME and Windows - the latter using the existing os.startfile support - and which could be extended to support other desktop environments such as Mac OS X, XFCE, CDE (along with others deemed important and feasible enough to support). Note that this approach is arguably better than that employed by the webbrowser module since most desktop environments already provide mechanisms for configuring and choosing the user's preferred programs for various activities, whereas the webbrowser module makes relatively uninformed guesses (eg. opening Firefox on a KDE desktop configured to use Konqueror as the default browser). Note also that the startfile function is arguably misplaced in the os module; thus, this functionality is supplied as a new module rather than as a patch to the os module, and the name of the function is "open" (like in the webbrowser module) rather than "startfile" which is a fairly Windows specific term. One could also envisage the desktop module residing within the os package to avoid top-level namespace pollution. Recent discussion in the comp.lang.python thread "Open PDF" covering this issue can be found here: http://groups.google.no/group/comp.lang.python/browse_frm/thread/8e00f7c1ccfae166/6168b6728cf64cb7 ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2005-09-26 02:14 Message: Logged In: YES user_id=226443 Actually, "desktop" just provides a way of saying "I'm on KDE not GNOME!" or something similar; the decisions then made by the function aren't themselves configurable, but then a developer would arguably be better off using os.system at that point. The module is really supposed to encapsulate knowledge about how to start programs in various desktop environments, along with a means to detect those environments in the first place. If you as a programmer disagree with the detection, override it; if you as a programmer know better, don't use the function... but do send a patch! As for user overrides, something like OPENER might be needed to get around the decisions taken in the module, although something "lighter" like DESKTOP might also be useful to override just the detection. It astounds me that such simple things haven't been agreed on by the freedesktop people, or at least not in any obvious way. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-26 01:34 Message: Logged In: YES user_id=261020 Why does the desktop module need something more than Paul's "desktop" argument? (Though perhaps "desktop" is not a sufficiently general name, as I think you said.) I don't think it's desirable for Python to start introducing half-baked and nonstandard environment variable conventions, especially in this area. 1. Why should other people start following *Python*'s convention here? 2. Any such convention may be overtaken by efforts with more backing (such as freedesktop), leaving us with cruft in the stdlib, perhaps even cruft that's in conflict with the new standards (what if somebody with actual clout mandates START instead? something will break). 3. Any program that wants to can follow this supposed OPENER convention, without needing to bake it into the stdlib. Having said all that, if you can get agreement from people at freedesktop to agree on OPENER (which might well be possible), and I guess set a useful default at desktop startup, I will worship at your feet ;-) I'm not sure what you mean by "the guesses that the module makes". It makes exactly one guess: which opener to use, and that guess is overridable with the "desktop" argument to open(). ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-26 00:01 Message: Logged In: YES user_id=93910 I suggested OPENER because I saw it in use somewhere while looking for things for open. I couldn't find it when I went looking for it to reply to this. Clearly, the desktop module needs some way for the user to say "I don't care what you think the system looks like - use *this*." If there's a standard for that, we should use it. If there isn't a standard, we get to establish one. Putting it in the beta version so people can play with it is a good idea. Until the module is accepted, nothing is wired down, and testers should know that. Open has been announced in a number of places. It doesn't have it's own web page yet. You can find a link to the tarball at http://www.mired.org/downloads/. It's also listed in PyPI. Other than it's existence showing that desktop needs a way for user to override the guesses the module makes (which the OSS launch tool does for OS X as well), this isn't really the place to discuss open. I've addressed the issues raised here about open in the README file that was posted in the 0.3 version. Further discussion should go to me directly, or to the Python list/newsgroup. If you think it belongs in another forum, please let me know. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-25 17:57 Message: Logged In: YES user_id=261020 If OPENER is not standard in any way (ad hoc or otherwise), why add it? Moght not doing that without talking to other people about it (presumably on freedesktop, including GNOME, KDE. etc. people) be positively harmful? Mike: is this Python version of Apple's "open" actually published on the web somewhere? I can't find it. I also notice that "open" is already in use as a shell wrapper around open (2) the system call. "start" seems unused, FWTW here. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-25 16:26 Message: Logged In: YES user_id=226443 I've uploaded a version which supports OPENER, although I can't find any references to that variable anywhere. By the way, I wonder if the open program's preferences couldn't somehow work with the various freedesktop.org standards if they don't already. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-25 03:01 Message: Logged In: YES user_id=93910 open is a desktop-independent variation on gnome-open and kfmclient. So it's something that desktop could be set up to run, using cmd = ["open", url]. On the other hand, it also exposes an API to Python progams, so you could (in theory) replace Unix-specific parts of desktop with (using the development version): from open import run run(filename, have = ['open']) except that it'd use the users "open" preferences instead of their desktop preferences. This is why I proposed the OPENER environment variable. I don't run a desktop, so the proposed version would default to trying os.startfile. I'd rather it use open. KDE Components->File Associations to do that. All of those editors are installed on my machine. Then I attempted to open this text file: $ file /home/john/test.txt /home/john/test.txt: ASCII text $ cat /home/john/test.txt hello, world $ When I open it by clicking on it from a Konqueror directory listing, GNU emacs running in an X11 window starts up, with the specified file opened. When I use your module: $ python2.4 Python 2.4 (#1, Feb 19 2005, 23:54:54) [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import desktop >>> desktop.open("/home/john/blocking.txt") >>> ...it opens in Konqueror with some embedded editor (KEdit or KWrite, I assume), not directly in any of the editors I specified, and certainly not in emacs. Same applies if I use a URL: >>> desktop.open("file:///home/john/test.txt") This doesn't seem to be the intended behaviour of your module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 From noreply at sourceforge.net Mon Sep 26 02:45:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Sep 2005 17:45:48 -0700 Subject: [Patches] [ python-Patches-1301512 ] desktop module (providing startfile as open, all platforms) Message-ID: Patches item #1301512, was opened at 2005-09-23 18:30 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: desktop module (providing startfile as open, all platforms) Initial Comment: Currently, in Python's standard library, there is apparently no coherent, cross-platform way of getting the user's environment to "open" files or resources (ie. show such files in browsers, editors) when requested by a Python program. There is an os.startfile function which works for Windows, but no equivalent function for other desktop environments - the webbrowser module seems to employ alternative mechanisms in choosing and running external programs and presumably does not seek to provide general support for non-URL resources anyway. Since desktop environments like KDE and GNOME provide mechanisms for running browsers and editors according to the identified type of a file or resource, just as Windows "runs" files or resources, it is appropriate to have a module which accesses these mechanisms. Attached is a simple module which seeks to support KDE, GNOME and Windows - the latter using the existing os.startfile support - and which could be extended to support other desktop environments such as Mac OS X, XFCE, CDE (along with others deemed important and feasible enough to support). Note that this approach is arguably better than that employed by the webbrowser module since most desktop environments already provide mechanisms for configuring and choosing the user's preferred programs for various activities, whereas the webbrowser module makes relatively uninformed guesses (eg. opening Firefox on a KDE desktop configured to use Konqueror as the default browser). Note also that the startfile function is arguably misplaced in the os module; thus, this functionality is supplied as a new module rather than as a patch to the os module, and the name of the function is "open" (like in the webbrowser module) rather than "startfile" which is a fairly Windows specific term. One could also envisage the desktop module residing within the os package to avoid top-level namespace pollution. Recent discussion in the comp.lang.python thread "Open PDF" covering this issue can be found here: http://groups.google.no/group/comp.lang.python/browse_frm/thread/8e00f7c1ccfae166/6168b6728cf64cb7 ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2005-09-26 02:45 Message: Logged In: YES user_id=226443 On environment variables, here's a thread discussing them: http://lists.freedesktop.org/archives/xdg/2004-December/005553.html The discussion ranges from environment variables referring to the desktop (DESKTOP) and a launcher (DESKTOP_LAUNCH) or some kind of information program (DESKTOP_CTL), all the way to such variables referencing .so files which are then dlopened. The abstraction elevator/escalator is thankfully stopped before things get any more complicated. A previous thread (mentioned in the above thread) proposes the DESKTOP variable and the alternative DESKTOP_OPEN variable: http://lists.freedesktop.org/archives/xdg/2004-May/003942.html The above thread continues here, proposing DESKTOP again along with a desktop-open script, later shifting to some people favouring DESKTOP_LAUNCH and some favouring a desktop-launch script: http://lists.freedesktop.org/archives/xdg/2004-May/003995.html A standards document mentioned in the last thread: http://primates.ximian.com/~michael/desktop.txt ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 02:14 Message: Logged In: YES user_id=226443 Actually, "desktop" just provides a way of saying "I'm on KDE not GNOME!" or something similar; the decisions then made by the function aren't themselves configurable, but then a developer would arguably be better off using os.system at that point. The module is really supposed to encapsulate knowledge about how to start programs in various desktop environments, along with a means to detect those environments in the first place. If you as a programmer disagree with the detection, override it; if you as a programmer know better, don't use the function... but do send a patch! As for user overrides, something like OPENER might be needed to get around the decisions taken in the module, although something "lighter" like DESKTOP might also be useful to override just the detection. It astounds me that such simple things haven't been agreed on by the freedesktop people, or at least not in any obvious way. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-26 01:34 Message: Logged In: YES user_id=261020 Why does the desktop module need something more than Paul's "desktop" argument? (Though perhaps "desktop" is not a sufficiently general name, as I think you said.) I don't think it's desirable for Python to start introducing half-baked and nonstandard environment variable conventions, especially in this area. 1. Why should other people start following *Python*'s convention here? 2. Any such convention may be overtaken by efforts with more backing (such as freedesktop), leaving us with cruft in the stdlib, perhaps even cruft that's in conflict with the new standards (what if somebody with actual clout mandates START instead? something will break). 3. Any program that wants to can follow this supposed OPENER convention, without needing to bake it into the stdlib. Having said all that, if you can get agreement from people at freedesktop to agree on OPENER (which might well be possible), and I guess set a useful default at desktop startup, I will worship at your feet ;-) I'm not sure what you mean by "the guesses that the module makes". It makes exactly one guess: which opener to use, and that guess is overridable with the "desktop" argument to open(). ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-26 00:01 Message: Logged In: YES user_id=93910 I suggested OPENER because I saw it in use somewhere while looking for things for open. I couldn't find it when I went looking for it to reply to this. Clearly, the desktop module needs some way for the user to say "I don't care what you think the system looks like - use *this*." If there's a standard for that, we should use it. If there isn't a standard, we get to establish one. Putting it in the beta version so people can play with it is a good idea. Until the module is accepted, nothing is wired down, and testers should know that. Open has been announced in a number of places. It doesn't have it's own web page yet. You can find a link to the tarball at http://www.mired.org/downloads/. It's also listed in PyPI. Other than it's existence showing that desktop needs a way for user to override the guesses the module makes (which the OSS launch tool does for OS X as well), this isn't really the place to discuss open. I've addressed the issues raised here about open in the README file that was posted in the 0.3 version. Further discussion should go to me directly, or to the Python list/newsgroup. If you think it belongs in another forum, please let me know. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-25 17:57 Message: Logged In: YES user_id=261020 If OPENER is not standard in any way (ad hoc or otherwise), why add it? Moght not doing that without talking to other people about it (presumably on freedesktop, including GNOME, KDE. etc. people) be positively harmful? Mike: is this Python version of Apple's "open" actually published on the web somewhere? I can't find it. I also notice that "open" is already in use as a shell wrapper around open (2) the system call. "start" seems unused, FWTW here. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-25 16:26 Message: Logged In: YES user_id=226443 I've uploaded a version which supports OPENER, although I can't find any references to that variable anywhere. By the way, I wonder if the open program's preferences couldn't somehow work with the various freedesktop.org standards if they don't already. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-25 03:01 Message: Logged In: YES user_id=93910 open is a desktop-independent variation on gnome-open and kfmclient. So it's something that desktop could be set up to run, using cmd = ["open", url]. On the other hand, it also exposes an API to Python progams, so you could (in theory) replace Unix-specific parts of desktop with (using the development version): from open import run run(filename, have = ['open']) except that it'd use the users "open" preferences instead of their desktop preferences. This is why I proposed the OPENER environment variable. I don't run a desktop, so the proposed version would default to trying os.startfile. I'd rather it use open. KDE Components->File Associations to do that. All of those editors are installed on my machine. Then I attempted to open this text file: $ file /home/john/test.txt /home/john/test.txt: ASCII text $ cat /home/john/test.txt hello, world $ When I open it by clicking on it from a Konqueror directory listing, GNU emacs running in an X11 window starts up, with the specified file opened. When I use your module: $ python2.4 Python 2.4 (#1, Feb 19 2005, 23:54:54) [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import desktop >>> desktop.open("/home/john/blocking.txt") >>> ...it opens in Konqueror with some embedded editor (KEdit or KWrite, I assume), not directly in any of the editors I specified, and certainly not in emacs. Same applies if I use a URL: >>> desktop.open("file:///home/john/test.txt") This doesn't seem to be the intended behaviour of your module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 From noreply at sourceforge.net Mon Sep 26 02:55:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Sep 2005 17:55:09 -0700 Subject: [Patches] [ python-Patches-1301512 ] desktop module (providing startfile as open, all platforms) Message-ID: Patches item #1301512, was opened at 2005-09-23 18:30 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: desktop module (providing startfile as open, all platforms) Initial Comment: Currently, in Python's standard library, there is apparently no coherent, cross-platform way of getting the user's environment to "open" files or resources (ie. show such files in browsers, editors) when requested by a Python program. There is an os.startfile function which works for Windows, but no equivalent function for other desktop environments - the webbrowser module seems to employ alternative mechanisms in choosing and running external programs and presumably does not seek to provide general support for non-URL resources anyway. Since desktop environments like KDE and GNOME provide mechanisms for running browsers and editors according to the identified type of a file or resource, just as Windows "runs" files or resources, it is appropriate to have a module which accesses these mechanisms. Attached is a simple module which seeks to support KDE, GNOME and Windows - the latter using the existing os.startfile support - and which could be extended to support other desktop environments such as Mac OS X, XFCE, CDE (along with others deemed important and feasible enough to support). Note that this approach is arguably better than that employed by the webbrowser module since most desktop environments already provide mechanisms for configuring and choosing the user's preferred programs for various activities, whereas the webbrowser module makes relatively uninformed guesses (eg. opening Firefox on a KDE desktop configured to use Konqueror as the default browser). Note also that the startfile function is arguably misplaced in the os module; thus, this functionality is supplied as a new module rather than as a patch to the os module, and the name of the function is "open" (like in the webbrowser module) rather than "startfile" which is a fairly Windows specific term. One could also envisage the desktop module residing within the os package to avoid top-level namespace pollution. Recent discussion in the comp.lang.python thread "Open PDF" covering this issue can be found here: http://groups.google.no/group/comp.lang.python/browse_frm/thread/8e00f7c1ccfae166/6168b6728cf64cb7 ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2005-09-26 02:55 Message: Logged In: YES user_id=226443 Oh, and after the DESKTOP specification, there was the DESKTOP_LAUNCH specification: http://lists.freedesktop.org/archives/xdg/2004-August/004489.html Things happen slowly in desktop standardisation land. Searching for usage of DESKTOP_LAUNCH revealed this interesting script: http://www.mail-archive.com/dashboard-hackers%40gnome.org/msg00762/desktop-launch ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 02:45 Message: Logged In: YES user_id=226443 On environment variables, here's a thread discussing them: http://lists.freedesktop.org/archives/xdg/2004-December/005553.html The discussion ranges from environment variables referring to the desktop (DESKTOP) and a launcher (DESKTOP_LAUNCH) or some kind of information program (DESKTOP_CTL), all the way to such variables referencing .so files which are then dlopened. The abstraction elevator/escalator is thankfully stopped before things get any more complicated. A previous thread (mentioned in the above thread) proposes the DESKTOP variable and the alternative DESKTOP_OPEN variable: http://lists.freedesktop.org/archives/xdg/2004-May/003942.html The above thread continues here, proposing DESKTOP again along with a desktop-open script, later shifting to some people favouring DESKTOP_LAUNCH and some favouring a desktop-launch script: http://lists.freedesktop.org/archives/xdg/2004-May/003995.html A standards document mentioned in the last thread: http://primates.ximian.com/~michael/desktop.txt ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 02:14 Message: Logged In: YES user_id=226443 Actually, "desktop" just provides a way of saying "I'm on KDE not GNOME!" or something similar; the decisions then made by the function aren't themselves configurable, but then a developer would arguably be better off using os.system at that point. The module is really supposed to encapsulate knowledge about how to start programs in various desktop environments, along with a means to detect those environments in the first place. If you as a programmer disagree with the detection, override it; if you as a programmer know better, don't use the function... but do send a patch! As for user overrides, something like OPENER might be needed to get around the decisions taken in the module, although something "lighter" like DESKTOP might also be useful to override just the detection. It astounds me that such simple things haven't been agreed on by the freedesktop people, or at least not in any obvious way. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-26 01:34 Message: Logged In: YES user_id=261020 Why does the desktop module need something more than Paul's "desktop" argument? (Though perhaps "desktop" is not a sufficiently general name, as I think you said.) I don't think it's desirable for Python to start introducing half-baked and nonstandard environment variable conventions, especially in this area. 1. Why should other people start following *Python*'s convention here? 2. Any such convention may be overtaken by efforts with more backing (such as freedesktop), leaving us with cruft in the stdlib, perhaps even cruft that's in conflict with the new standards (what if somebody with actual clout mandates START instead? something will break). 3. Any program that wants to can follow this supposed OPENER convention, without needing to bake it into the stdlib. Having said all that, if you can get agreement from people at freedesktop to agree on OPENER (which might well be possible), and I guess set a useful default at desktop startup, I will worship at your feet ;-) I'm not sure what you mean by "the guesses that the module makes". It makes exactly one guess: which opener to use, and that guess is overridable with the "desktop" argument to open(). ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-26 00:01 Message: Logged In: YES user_id=93910 I suggested OPENER because I saw it in use somewhere while looking for things for open. I couldn't find it when I went looking for it to reply to this. Clearly, the desktop module needs some way for the user to say "I don't care what you think the system looks like - use *this*." If there's a standard for that, we should use it. If there isn't a standard, we get to establish one. Putting it in the beta version so people can play with it is a good idea. Until the module is accepted, nothing is wired down, and testers should know that. Open has been announced in a number of places. It doesn't have it's own web page yet. You can find a link to the tarball at http://www.mired.org/downloads/. It's also listed in PyPI. Other than it's existence showing that desktop needs a way for user to override the guesses the module makes (which the OSS launch tool does for OS X as well), this isn't really the place to discuss open. I've addressed the issues raised here about open in the README file that was posted in the 0.3 version. Further discussion should go to me directly, or to the Python list/newsgroup. If you think it belongs in another forum, please let me know. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-25 17:57 Message: Logged In: YES user_id=261020 If OPENER is not standard in any way (ad hoc or otherwise), why add it? Moght not doing that without talking to other people about it (presumably on freedesktop, including GNOME, KDE. etc. people) be positively harmful? Mike: is this Python version of Apple's "open" actually published on the web somewhere? I can't find it. I also notice that "open" is already in use as a shell wrapper around open (2) the system call. "start" seems unused, FWTW here. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-25 16:26 Message: Logged In: YES user_id=226443 I've uploaded a version which supports OPENER, although I can't find any references to that variable anywhere. By the way, I wonder if the open program's preferences couldn't somehow work with the various freedesktop.org standards if they don't already. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-25 03:01 Message: Logged In: YES user_id=93910 open is a desktop-independent variation on gnome-open and kfmclient. So it's something that desktop could be set up to run, using cmd = ["open", url]. On the other hand, it also exposes an API to Python progams, so you could (in theory) replace Unix-specific parts of desktop with (using the development version): from open import run run(filename, have = ['open']) except that it'd use the users "open" preferences instead of their desktop preferences. This is why I proposed the OPENER environment variable. I don't run a desktop, so the proposed version would default to trying os.startfile. I'd rather it use open. KDE Components->File Associations to do that. All of those editors are installed on my machine. Then I attempted to open this text file: $ file /home/john/test.txt /home/john/test.txt: ASCII text $ cat /home/john/test.txt hello, world $ When I open it by clicking on it from a Konqueror directory listing, GNU emacs running in an X11 window starts up, with the specified file opened. When I use your module: $ python2.4 Python 2.4 (#1, Feb 19 2005, 23:54:54) [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import desktop >>> desktop.open("/home/john/blocking.txt") >>> ...it opens in Konqueror with some embedded editor (KEdit or KWrite, I assume), not directly in any of the editors I specified, and certainly not in emacs. Same applies if I use a URL: >>> desktop.open("file:///home/john/test.txt") This doesn't seem to be the intended behaviour of your module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 From noreply at sourceforge.net Mon Sep 26 04:25:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Sep 2005 19:25:09 -0700 Subject: [Patches] [ python-Patches-1301512 ] desktop module (providing startfile as open, all platforms) Message-ID: Patches item #1301512, was opened at 2005-09-23 11:30 Message generated for change (Comment added) made by mwm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: desktop module (providing startfile as open, all platforms) Initial Comment: Currently, in Python's standard library, there is apparently no coherent, cross-platform way of getting the user's environment to "open" files or resources (ie. show such files in browsers, editors) when requested by a Python program. There is an os.startfile function which works for Windows, but no equivalent function for other desktop environments - the webbrowser module seems to employ alternative mechanisms in choosing and running external programs and presumably does not seek to provide general support for non-URL resources anyway. Since desktop environments like KDE and GNOME provide mechanisms for running browsers and editors according to the identified type of a file or resource, just as Windows "runs" files or resources, it is appropriate to have a module which accesses these mechanisms. Attached is a simple module which seeks to support KDE, GNOME and Windows - the latter using the existing os.startfile support - and which could be extended to support other desktop environments such as Mac OS X, XFCE, CDE (along with others deemed important and feasible enough to support). Note that this approach is arguably better than that employed by the webbrowser module since most desktop environments already provide mechanisms for configuring and choosing the user's preferred programs for various activities, whereas the webbrowser module makes relatively uninformed guesses (eg. opening Firefox on a KDE desktop configured to use Konqueror as the default browser). Note also that the startfile function is arguably misplaced in the os module; thus, this functionality is supplied as a new module rather than as a patch to the os module, and the name of the function is "open" (like in the webbrowser module) rather than "startfile" which is a fairly Windows specific term. One could also envisage the desktop module residing within the os package to avoid top-level namespace pollution. Recent discussion in the comp.lang.python thread "Open PDF" covering this issue can be found here: http://groups.google.no/group/comp.lang.python/browse_frm/thread/8e00f7c1ccfae166/6168b6728cf64cb7 ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-25 21:25 Message: Logged In: YES user_id=93910 Actually, the guess that the module makes is which desktop the user is on - and that's overridable by the "desktop" argument. The pre-OPENER version of desktop.py had no way to override it's choice of opener - the best you can do is tell it to use the default opener for some desktop it knows about. Further, the "desktop" argument is really only applicable to the application developer. The end-user - the person who actually chooses the launcher to use - can't use it without editing the source to the application. While you may consider this an acceptable configuration mechanism, I don't. The standard Unix mechanism for setting things like this - dating back to the 70s - is an environment variable that names the command to use. If you want to suggest a better mechanism, feel free to do so. Until then the question is what the name should be. Based on what the freedesktop talk, maybe it shold be DESKTOP_OPEN or DESKTOP_LAUNCH. On the other hand, the freedesktop folks seem much better at generating discussion than specifications - and neither of those carries as much weight with me as running code. Part of this does depend on the point of the desktop module. I thought it was to make os.startfile functionality available in a platform-independent manner. If so, it needs to deal with things other than the tools provided by a couple of common desktops. If instead it's supposed to provide access to the knowledge built into the most popular desktops, then ignoring user preferences is reasonable. But that makes it much less usefull. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-25 19:55 Message: Logged In: YES user_id=226443 Oh, and after the DESKTOP specification, there was the DESKTOP_LAUNCH specification: http://lists.freedesktop.org/archives/xdg/2004-August/004489.html Things happen slowly in desktop standardisation land. Searching for usage of DESKTOP_LAUNCH revealed this interesting script: http://www.mail-archive.com/dashboard-hackers%40gnome.org/msg00762/desktop-launch ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-25 19:45 Message: Logged In: YES user_id=226443 On environment variables, here's a thread discussing them: http://lists.freedesktop.org/archives/xdg/2004-December/005553.html The discussion ranges from environment variables referring to the desktop (DESKTOP) and a launcher (DESKTOP_LAUNCH) or some kind of information program (DESKTOP_CTL), all the way to such variables referencing .so files which are then dlopened. The abstraction elevator/escalator is thankfully stopped before things get any more complicated. A previous thread (mentioned in the above thread) proposes the DESKTOP variable and the alternative DESKTOP_OPEN variable: http://lists.freedesktop.org/archives/xdg/2004-May/003942.html The above thread continues here, proposing DESKTOP again along with a desktop-open script, later shifting to some people favouring DESKTOP_LAUNCH and some favouring a desktop-launch script: http://lists.freedesktop.org/archives/xdg/2004-May/003995.html A standards document mentioned in the last thread: http://primates.ximian.com/~michael/desktop.txt ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-25 19:14 Message: Logged In: YES user_id=226443 Actually, "desktop" just provides a way of saying "I'm on KDE not GNOME!" or something similar; the decisions then made by the function aren't themselves configurable, but then a developer would arguably be better off using os.system at that point. The module is really supposed to encapsulate knowledge about how to start programs in various desktop environments, along with a means to detect those environments in the first place. If you as a programmer disagree with the detection, override it; if you as a programmer know better, don't use the function... but do send a patch! As for user overrides, something like OPENER might be needed to get around the decisions taken in the module, although something "lighter" like DESKTOP might also be useful to override just the detection. It astounds me that such simple things haven't been agreed on by the freedesktop people, or at least not in any obvious way. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-25 18:34 Message: Logged In: YES user_id=261020 Why does the desktop module need something more than Paul's "desktop" argument? (Though perhaps "desktop" is not a sufficiently general name, as I think you said.) I don't think it's desirable for Python to start introducing half-baked and nonstandard environment variable conventions, especially in this area. 1. Why should other people start following *Python*'s convention here? 2. Any such convention may be overtaken by efforts with more backing (such as freedesktop), leaving us with cruft in the stdlib, perhaps even cruft that's in conflict with the new standards (what if somebody with actual clout mandates START instead? something will break). 3. Any program that wants to can follow this supposed OPENER convention, without needing to bake it into the stdlib. Having said all that, if you can get agreement from people at freedesktop to agree on OPENER (which might well be possible), and I guess set a useful default at desktop startup, I will worship at your feet ;-) I'm not sure what you mean by "the guesses that the module makes". It makes exactly one guess: which opener to use, and that guess is overridable with the "desktop" argument to open(). ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-25 17:01 Message: Logged In: YES user_id=93910 I suggested OPENER because I saw it in use somewhere while looking for things for open. I couldn't find it when I went looking for it to reply to this. Clearly, the desktop module needs some way for the user to say "I don't care what you think the system looks like - use *this*." If there's a standard for that, we should use it. If there isn't a standard, we get to establish one. Putting it in the beta version so people can play with it is a good idea. Until the module is accepted, nothing is wired down, and testers should know that. Open has been announced in a number of places. It doesn't have it's own web page yet. You can find a link to the tarball at http://www.mired.org/downloads/. It's also listed in PyPI. Other than it's existence showing that desktop needs a way for user to override the guesses the module makes (which the OSS launch tool does for OS X as well), this isn't really the place to discuss open. I've addressed the issues raised here about open in the README file that was posted in the 0.3 version. Further discussion should go to me directly, or to the Python list/newsgroup. If you think it belongs in another forum, please let me know. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-25 10:57 Message: Logged In: YES user_id=261020 If OPENER is not standard in any way (ad hoc or otherwise), why add it? Moght not doing that without talking to other people about it (presumably on freedesktop, including GNOME, KDE. etc. people) be positively harmful? Mike: is this Python version of Apple's "open" actually published on the web somewhere? I can't find it. I also notice that "open" is already in use as a shell wrapper around open (2) the system call. "start" seems unused, FWTW here. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-25 09:26 Message: Logged In: YES user_id=226443 I've uploaded a version which supports OPENER, although I can't find any references to that variable anywhere. By the way, I wonder if the open program's preferences couldn't somehow work with the various freedesktop.org standards if they don't already. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-24 20:01 Message: Logged In: YES user_id=93910 open is a desktop-independent variation on gnome-open and kfmclient. So it's something that desktop could be set up to run, using cmd = ["open", url]. On the other hand, it also exposes an API to Python progams, so you could (in theory) replace Unix-specific parts of desktop with (using the development version): from open import run run(filename, have = ['open']) except that it'd use the users "open" preferences instead of their desktop preferences. This is why I proposed the OPENER environment variable. I don't run a desktop, so the proposed version would default to trying os.startfile. I'd rather it use open. KDE Components->File Associations to do that. All of those editors are installed on my machine. Then I attempted to open this text file: $ file /home/john/test.txt /home/john/test.txt: ASCII text $ cat /home/john/test.txt hello, world $ When I open it by clicking on it from a Konqueror directory listing, GNU emacs running in an X11 window starts up, with the specified file opened. When I use your module: $ python2.4 Python 2.4 (#1, Feb 19 2005, 23:54:54) [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import desktop >>> desktop.open("/home/john/blocking.txt") >>> ...it opens in Konqueror with some embedded editor (KEdit or KWrite, I assume), not directly in any of the editors I specified, and certainly not in emacs. Same applies if I use a URL: >>> desktop.open("file:///home/john/test.txt") This doesn't seem to be the intended behaviour of your module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 From noreply at sourceforge.net Mon Sep 26 15:08:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Sep 2005 06:08:42 -0700 Subject: [Patches] [ python-Patches-1301512 ] desktop module (providing startfile as open, all platforms) Message-ID: Patches item #1301512, was opened at 2005-09-23 18:30 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: desktop module (providing startfile as open, all platforms) Initial Comment: Currently, in Python's standard library, there is apparently no coherent, cross-platform way of getting the user's environment to "open" files or resources (ie. show such files in browsers, editors) when requested by a Python program. There is an os.startfile function which works for Windows, but no equivalent function for other desktop environments - the webbrowser module seems to employ alternative mechanisms in choosing and running external programs and presumably does not seek to provide general support for non-URL resources anyway. Since desktop environments like KDE and GNOME provide mechanisms for running browsers and editors according to the identified type of a file or resource, just as Windows "runs" files or resources, it is appropriate to have a module which accesses these mechanisms. Attached is a simple module which seeks to support KDE, GNOME and Windows - the latter using the existing os.startfile support - and which could be extended to support other desktop environments such as Mac OS X, XFCE, CDE (along with others deemed important and feasible enough to support). Note that this approach is arguably better than that employed by the webbrowser module since most desktop environments already provide mechanisms for configuring and choosing the user's preferred programs for various activities, whereas the webbrowser module makes relatively uninformed guesses (eg. opening Firefox on a KDE desktop configured to use Konqueror as the default browser). Note also that the startfile function is arguably misplaced in the os module; thus, this functionality is supplied as a new module rather than as a patch to the os module, and the name of the function is "open" (like in the webbrowser module) rather than "startfile" which is a fairly Windows specific term. One could also envisage the desktop module residing within the os package to avoid top-level namespace pollution. Recent discussion in the comp.lang.python thread "Open PDF" covering this issue can be found here: http://groups.google.no/group/comp.lang.python/browse_frm/thread/8e00f7c1ccfae166/6168b6728cf64cb7 ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2005-09-26 15:08 Message: Logged In: YES user_id=226443 I've now attached another version of the module which observes DESKTOP_LAUNCH, does a bit more verification, and exposes the desktop detection. I'll probably do a bit more reading of the fd.o mailing lists and possibly try and get some answers from the interested parties. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-26 04:25 Message: Logged In: YES user_id=93910 Actually, the guess that the module makes is which desktop the user is on - and that's overridable by the "desktop" argument. The pre-OPENER version of desktop.py had no way to override it's choice of opener - the best you can do is tell it to use the default opener for some desktop it knows about. Further, the "desktop" argument is really only applicable to the application developer. The end-user - the person who actually chooses the launcher to use - can't use it without editing the source to the application. While you may consider this an acceptable configuration mechanism, I don't. The standard Unix mechanism for setting things like this - dating back to the 70s - is an environment variable that names the command to use. If you want to suggest a better mechanism, feel free to do so. Until then the question is what the name should be. Based on what the freedesktop talk, maybe it shold be DESKTOP_OPEN or DESKTOP_LAUNCH. On the other hand, the freedesktop folks seem much better at generating discussion than specifications - and neither of those carries as much weight with me as running code. Part of this does depend on the point of the desktop module. I thought it was to make os.startfile functionality available in a platform-independent manner. If so, it needs to deal with things other than the tools provided by a couple of common desktops. If instead it's supposed to provide access to the knowledge built into the most popular desktops, then ignoring user preferences is reasonable. But that makes it much less usefull. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 02:55 Message: Logged In: YES user_id=226443 Oh, and after the DESKTOP specification, there was the DESKTOP_LAUNCH specification: http://lists.freedesktop.org/archives/xdg/2004-August/004489.html Things happen slowly in desktop standardisation land. Searching for usage of DESKTOP_LAUNCH revealed this interesting script: http://www.mail-archive.com/dashboard-hackers%40gnome.org/msg00762/desktop-launch ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 02:45 Message: Logged In: YES user_id=226443 On environment variables, here's a thread discussing them: http://lists.freedesktop.org/archives/xdg/2004-December/005553.html The discussion ranges from environment variables referring to the desktop (DESKTOP) and a launcher (DESKTOP_LAUNCH) or some kind of information program (DESKTOP_CTL), all the way to such variables referencing .so files which are then dlopened. The abstraction elevator/escalator is thankfully stopped before things get any more complicated. A previous thread (mentioned in the above thread) proposes the DESKTOP variable and the alternative DESKTOP_OPEN variable: http://lists.freedesktop.org/archives/xdg/2004-May/003942.html The above thread continues here, proposing DESKTOP again along with a desktop-open script, later shifting to some people favouring DESKTOP_LAUNCH and some favouring a desktop-launch script: http://lists.freedesktop.org/archives/xdg/2004-May/003995.html A standards document mentioned in the last thread: http://primates.ximian.com/~michael/desktop.txt ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 02:14 Message: Logged In: YES user_id=226443 Actually, "desktop" just provides a way of saying "I'm on KDE not GNOME!" or something similar; the decisions then made by the function aren't themselves configurable, but then a developer would arguably be better off using os.system at that point. The module is really supposed to encapsulate knowledge about how to start programs in various desktop environments, along with a means to detect those environments in the first place. If you as a programmer disagree with the detection, override it; if you as a programmer know better, don't use the function... but do send a patch! As for user overrides, something like OPENER might be needed to get around the decisions taken in the module, although something "lighter" like DESKTOP might also be useful to override just the detection. It astounds me that such simple things haven't been agreed on by the freedesktop people, or at least not in any obvious way. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-26 01:34 Message: Logged In: YES user_id=261020 Why does the desktop module need something more than Paul's "desktop" argument? (Though perhaps "desktop" is not a sufficiently general name, as I think you said.) I don't think it's desirable for Python to start introducing half-baked and nonstandard environment variable conventions, especially in this area. 1. Why should other people start following *Python*'s convention here? 2. Any such convention may be overtaken by efforts with more backing (such as freedesktop), leaving us with cruft in the stdlib, perhaps even cruft that's in conflict with the new standards (what if somebody with actual clout mandates START instead? something will break). 3. Any program that wants to can follow this supposed OPENER convention, without needing to bake it into the stdlib. Having said all that, if you can get agreement from people at freedesktop to agree on OPENER (which might well be possible), and I guess set a useful default at desktop startup, I will worship at your feet ;-) I'm not sure what you mean by "the guesses that the module makes". It makes exactly one guess: which opener to use, and that guess is overridable with the "desktop" argument to open(). ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-26 00:01 Message: Logged In: YES user_id=93910 I suggested OPENER because I saw it in use somewhere while looking for things for open. I couldn't find it when I went looking for it to reply to this. Clearly, the desktop module needs some way for the user to say "I don't care what you think the system looks like - use *this*." If there's a standard for that, we should use it. If there isn't a standard, we get to establish one. Putting it in the beta version so people can play with it is a good idea. Until the module is accepted, nothing is wired down, and testers should know that. Open has been announced in a number of places. It doesn't have it's own web page yet. You can find a link to the tarball at http://www.mired.org/downloads/. It's also listed in PyPI. Other than it's existence showing that desktop needs a way for user to override the guesses the module makes (which the OSS launch tool does for OS X as well), this isn't really the place to discuss open. I've addressed the issues raised here about open in the README file that was posted in the 0.3 version. Further discussion should go to me directly, or to the Python list/newsgroup. If you think it belongs in another forum, please let me know. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-25 17:57 Message: Logged In: YES user_id=261020 If OPENER is not standard in any way (ad hoc or otherwise), why add it? Moght not doing that without talking to other people about it (presumably on freedesktop, including GNOME, KDE. etc. people) be positively harmful? Mike: is this Python version of Apple's "open" actually published on the web somewhere? I can't find it. I also notice that "open" is already in use as a shell wrapper around open (2) the system call. "start" seems unused, FWTW here. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-25 16:26 Message: Logged In: YES user_id=226443 I've uploaded a version which supports OPENER, although I can't find any references to that variable anywhere. By the way, I wonder if the open program's preferences couldn't somehow work with the various freedesktop.org standards if they don't already. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-25 03:01 Message: Logged In: YES user_id=93910 open is a desktop-independent variation on gnome-open and kfmclient. So it's something that desktop could be set up to run, using cmd = ["open", url]. On the other hand, it also exposes an API to Python progams, so you could (in theory) replace Unix-specific parts of desktop with (using the development version): from open import run run(filename, have = ['open']) except that it'd use the users "open" preferences instead of their desktop preferences. This is why I proposed the OPENER environment variable. I don't run a desktop, so the proposed version would default to trying os.startfile. I'd rather it use open. KDE Components->File Associations to do that. All of those editors are installed on my machine. Then I attempted to open this text file: $ file /home/john/test.txt /home/john/test.txt: ASCII text $ cat /home/john/test.txt hello, world $ When I open it by clicking on it from a Konqueror directory listing, GNU emacs running in an X11 window starts up, with the specified file opened. When I use your module: $ python2.4 Python 2.4 (#1, Feb 19 2005, 23:54:54) [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import desktop >>> desktop.open("/home/john/blocking.txt") >>> ...it opens in Konqueror with some embedded editor (KEdit or KWrite, I assume), not directly in any of the editors I specified, and certainly not in emacs. Same applies if I use a URL: >>> desktop.open("file:///home/john/test.txt") This doesn't seem to be the intended behaviour of your module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 From noreply at sourceforge.net Mon Sep 26 15:21:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Sep 2005 06:21:46 -0700 Subject: [Patches] [ python-Patches-1298813 ] sysmodule.c: realpath() is unsafe Message-ID: Patches item #1298813, was opened at 2005-09-22 16:54 Message generated for change (Comment added) made by spektrum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298813&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Mihai Ibanescu (misa) Assigned to: Nobody/Anonymous (nobody) Summary: sysmodule.c: realpath() is unsafe Initial Comment: realpath() will dereference all symlinks and resolve references to /./ and /../ (and so on). realpath accepts a source buffer and a destination buffer to copy the resolved path into. On certain systems PATH_MAX can be of arbitrary size, while the buffer passed in would be of a limiited size. There is no way to specify how long your "resolved" buffer is, therefore it is possible for one to overflow it. According to the man page: BUGS Never use this function. It is broken by design since it is impossible to determine a suitable size for the output buffer. According to POSIX a buffer of size PATH_MAX suffices, but PATH_MAX need not be a defined constant, and may have to be obtained using pathconf(). And asking pathconf() does not really help, since on the one hand POSIX warns that the result of pathconf() may be huge and unsuitable for mallocing mem- ory. And on the other hand pathconf() may return -1 to signify that PATH_MAX is not bounded. glibc has certain extensions to avoid the buffer overflow. One option is to use canonicalize_file_name(), another is to specify a NULL as the second argument to realpath() (which essentially makes it behave like canonicalize_file_name(). Relevant documentation: info libc http://www.delorie.com/gnu/docs/glibc/libc_279.html Attached is a patch to use canonicalize_file_name if available. ---------------------------------------------------------------------- Comment By: Matejcik (spektrum) Date: 2005-09-26 15:21 Message: Logged In: YES user_id=631694 there are two bugs in the patch: one is explained on https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169046 the other one is that with this patch, the value of n (length to be copied) stays zero all the time, so no copy occurs and various things happen. i have a patch, but don't know how to attach it - should i mail it to you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298813&group_id=5470 From noreply at sourceforge.net Mon Sep 26 15:54:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Sep 2005 06:54:06 -0700 Subject: [Patches] [ python-Patches-1212837 ] Improved profiler Message-ID: Patches item #1212837, was opened at 2005-06-01 12:05 Message generated for change (Comment added) made by bdrosen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212837&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Brett Rosen (bdrosen) Assigned to: Nobody/Anonymous (nobody) Summary: Improved profiler Initial Comment: I tried using both hotshot and the old python profiler and found them both to be inadequate. The old python profiler seems to give accurate results for timing, but is slow enough that it adds significant overhead to what it is measuing (approximately 10 times). Furthermore, it has no ability to give detailed stats about children. (how much of the cumulative time was taken up by each function called by a function) The hotshot profiler is much faster (profiling) adding only 30% overhead. However, it is extremely slow to load the results from the log file. It does not currently support detailed child stats, although I imagine that it could be made to do so using the information in the log file. The biggest problem with it, is that the time results seem to be highly inaccurate. (doesn't correspond to actual seconds, although they seem to be proportionally wrong) To address these shortcomings, I wrote a new profiling module. It adds about the same overhead (30%) as hotshot, but is much faster in retrieving results. It supports detailed child stats and gives accurate timing information in milliseconds. The accompanying .py module could use additional work though - because of the child stats, I was not able to reuse the stats module like hotshot does. I've included a simple test script that runs pystone for all 3 profilers (and without the profiler) to give a better idea of the differences. I've also included a dump of the output of the script running under Windows XP with python 2.4.1 ---------------------------------------------------------------------- >Comment By: Brett Rosen (bdrosen) Date: 2005-09-26 09:54 Message: Logged In: YES user_id=1289249 I looked over the changes so far and they look reasonable. I did have a few questions though: 1 Do we not need to Increment/Decrement references to the code objects? We are using them as keys in the trees as well as payload data later on, but I don't see how we are guaranteed that they won't be reaped. (although it seems unlikely) 2 Is it deliberate to use lsprof.YYY style names for some of the objects (ie lsprof.Profiler) instead of _lsprof ? (is this the normal convention?) 3 Do you have a feel for the performance differences of using the tree instead of the lists? Doing the simple benchmark test they seemed to be comparable, but that test is pretty simple. I'm assuming tht in a large program, the tree approach will be considerably faster? 4 In lsprof.py, is there a reason that the Stats class does not derive from object? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-23 03:46 Message: Logged In: YES user_id=4771 I replaced the linked lists with some kind of auto-balacing trees; the linked lists were creating a huge overhead to profile large programs. The reason for not using plain Python dicts instead is that PyCodeObjects are not very good at being keys in dicts -- their hash computation takes ages, and we'd prefer an identity mapping anyway. The current SVN version is now the first profiler that works and gives sensible results when profiling the PyPy translation process. getstats() is now producing tuples-with-attribute-names instead of dicts (similar to os.stat()). This was mostly motivated by a lack of motivation to introduce error checking everywhere in the dict-building code, but I think it's a reasonable change. There are only a couple of places left in profile.c still missing checks for error results or out-of-memory conditions. The lsprof.py module exposes a simple but minimalistic interface. I suggest we keep and document it or a similar one, but also support -- for compatibility -- the convoluted interface of the existing profile.py/pstats.py and/or hotshot, with the option to dump the stats to a file and reload them. However I don't think it makes sense to use exactly the same format as pstats does (as far as I can guess it doesn't support per-caller information). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-09-21 14:35 Message: Logged In: YES user_id=6656 Well, you can see what we've done to your baby: http://codespeak.net/svn/user/arigo/hack/misc/lsprof/profile.c Mostly it's just C style conformance so far, though we've fixed a couple of little bugs too. ---------------------------------------------------------------------- Comment By: Brett Rosen (bdrosen) Date: 2005-09-21 13:43 Message: Logged In: YES user_id=1289249 I welcome any additional changes (and help making those changes) that would improve the patch and help get it ready for inclusion in CPython. The main detail that I knew that would need to be addressed was lspstats.py. I didn't spend a lot of time working on it because I generally use a wx TreeListCtrl object to view/sort the results. What other details need to be addressed? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-21 11:57 Message: Logged In: YES user_id=4771 Thanks for your work. The two existing profilers are definitely not satisfactory in my opinion too (I am also encountering crashes with profile.py). There are a number of details that should be addressed before your profiler can be a replacement for the existing ones, e.g. providing simple entry points and documentations, and having the C code reviewed. I am willing to help with all this. I hope you won't mind that I have checked your source code in a public Subversion repository, where I am working a bit on it together with Michael Hudson. (Obviously, the goal is to have the code eventually in the CPython CVS.) http://codespeak.net/svn/user/arigo/hack/misc/lsprof/ ---------------------------------------------------------------------- Comment By: Laura Creighton (lcreighton) Date: 2005-09-21 11:18 Message: Logged In: YES user_id=376262 We've been using Hotshot at Strakt for a while now. We tried your patch and it worked precisely as advertised. Thank you for writing it. Laura Creighton ---------------------------------------------------------------------- Comment By: Brett Rosen (bdrosen) Date: 2005-09-08 11:25 Message: Logged In: YES user_id=1289249 I've enclosed an updated version of profile.c that fixes a problem in the original patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212837&group_id=5470 From noreply at sourceforge.net Mon Sep 26 16:51:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Sep 2005 07:51:52 -0700 Subject: [Patches] [ python-Patches-1304895 ] Strobe Timer for guis Message-ID: Patches item #1304895, was opened at 2005-09-26 10: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=1304895&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Brett Rosen (bdrosen) Assigned to: Nobody/Anonymous (nobody) Summary: Strobe Timer for guis Initial Comment: Often when doing gui work it is useful to queue up a task to run at some later time - either once or periodically. Although you can use the thread support to do this, it is problematic because: 1 one because if the work being done is gui related, it often needs to be done in the same thread which owns the gui 2 it is easier to not need to code using threads if you don't need to 3 having multiple threads executing at once doesn't scale so well, especially when you have lots of idle time in a gui app. I created this module to get around this problem. In you gui, you would add _timers.AppServiceTimers to your onIdle method (or whatever method get called for idle processing) Then to register an event to be run you would do: import _timers a = _timers.StrobeTimer() a.Interval(500) def MyStrobe(self): print "I am called every 500 ms", self a.Strobe = MyStrobe a.StartTimer() # do some work a.StopTimer() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1304895&group_id=5470 From noreply at sourceforge.net Mon Sep 26 21:11:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Sep 2005 12:11:37 -0700 Subject: [Patches] [ python-Patches-1298813 ] sysmodule.c: realpath() is unsafe Message-ID: Patches item #1298813, was opened at 2005-09-22 14:54 Message generated for change (Comment added) made by pjones You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298813&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Mihai Ibanescu (misa) Assigned to: Nobody/Anonymous (nobody) Summary: sysmodule.c: realpath() is unsafe Initial Comment: realpath() will dereference all symlinks and resolve references to /./ and /../ (and so on). realpath accepts a source buffer and a destination buffer to copy the resolved path into. On certain systems PATH_MAX can be of arbitrary size, while the buffer passed in would be of a limiited size. There is no way to specify how long your "resolved" buffer is, therefore it is possible for one to overflow it. According to the man page: BUGS Never use this function. It is broken by design since it is impossible to determine a suitable size for the output buffer. According to POSIX a buffer of size PATH_MAX suffices, but PATH_MAX need not be a defined constant, and may have to be obtained using pathconf(). And asking pathconf() does not really help, since on the one hand POSIX warns that the result of pathconf() may be huge and unsuitable for mallocing mem- ory. And on the other hand pathconf() may return -1 to signify that PATH_MAX is not bounded. glibc has certain extensions to avoid the buffer overflow. One option is to use canonicalize_file_name(), another is to specify a NULL as the second argument to realpath() (which essentially makes it behave like canonicalize_file_name(). Relevant documentation: info libc http://www.delorie.com/gnu/docs/glibc/libc_279.html Attached is a patch to use canonicalize_file_name if available. ---------------------------------------------------------------------- Comment By: Peter Jones (pjones) Date: 2005-09-26 19:11 Message: Logged In: YES user_id=27350 There are actually a few more, very subtle problems with the new patch as well. I'll get misa to update a patch once I've worked through them. In general, regarding Red Hat's bz# 169046, there's no reason to do readlink() or realpath() if you've got canonicalize_file_name; it should provide both sets of functionality just fine. ---------------------------------------------------------------------- Comment By: Matejcik (spektrum) Date: 2005-09-26 13:21 Message: Logged In: YES user_id=631694 there are two bugs in the patch: one is explained on https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169046 the other one is that with this patch, the value of n (length to be copied) stays zero all the time, so no copy occurs and various things happen. i have a patch, but don't know how to attach it - should i mail it to you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298813&group_id=5470 From noreply at sourceforge.net Mon Sep 26 21:14:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Sep 2005 12:14:09 -0700 Subject: [Patches] [ python-Patches-1298813 ] sysmodule.c: realpath() is unsafe Message-ID: Patches item #1298813, was opened at 2005-09-22 14:54 Message generated for change (Comment added) made by pjones You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298813&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Mihai Ibanescu (misa) Assigned to: Nobody/Anonymous (nobody) Summary: sysmodule.c: realpath() is unsafe Initial Comment: realpath() will dereference all symlinks and resolve references to /./ and /../ (and so on). realpath accepts a source buffer and a destination buffer to copy the resolved path into. On certain systems PATH_MAX can be of arbitrary size, while the buffer passed in would be of a limiited size. There is no way to specify how long your "resolved" buffer is, therefore it is possible for one to overflow it. According to the man page: BUGS Never use this function. It is broken by design since it is impossible to determine a suitable size for the output buffer. According to POSIX a buffer of size PATH_MAX suffices, but PATH_MAX need not be a defined constant, and may have to be obtained using pathconf(). And asking pathconf() does not really help, since on the one hand POSIX warns that the result of pathconf() may be huge and unsuitable for mallocing mem- ory. And on the other hand pathconf() may return -1 to signify that PATH_MAX is not bounded. glibc has certain extensions to avoid the buffer overflow. One option is to use canonicalize_file_name(), another is to specify a NULL as the second argument to realpath() (which essentially makes it behave like canonicalize_file_name(). Relevant documentation: info libc http://www.delorie.com/gnu/docs/glibc/libc_279.html Attached is a patch to use canonicalize_file_name if available. ---------------------------------------------------------------------- Comment By: Peter Jones (pjones) Date: 2005-09-26 19:14 Message: Logged In: YES user_id=27350 ... but I see you meant the condition different than I parsed your explanation. Anyway, I'll get misa to upload a new patch once I've figured out what's going wrong entirely. ---------------------------------------------------------------------- Comment By: Peter Jones (pjones) Date: 2005-09-26 19:11 Message: Logged In: YES user_id=27350 There are actually a few more, very subtle problems with the new patch as well. I'll get misa to update a patch once I've worked through them. In general, regarding Red Hat's bz# 169046, there's no reason to do readlink() or realpath() if you've got canonicalize_file_name; it should provide both sets of functionality just fine. ---------------------------------------------------------------------- Comment By: Matejcik (spektrum) Date: 2005-09-26 13:21 Message: Logged In: YES user_id=631694 there are two bugs in the patch: one is explained on https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169046 the other one is that with this patch, the value of n (length to be copied) stays zero all the time, so no copy occurs and various things happen. i have a patch, but don't know how to attach it - should i mail it to you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298813&group_id=5470 From noreply at sourceforge.net Tue Sep 27 02:20:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Sep 2005 17:20:13 -0700 Subject: [Patches] [ python-Patches-1301512 ] desktop module (providing startfile as open, all platforms) Message-ID: Patches item #1301512, was opened at 2005-09-23 17:30 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: desktop module (providing startfile as open, all platforms) Initial Comment: Currently, in Python's standard library, there is apparently no coherent, cross-platform way of getting the user's environment to "open" files or resources (ie. show such files in browsers, editors) when requested by a Python program. There is an os.startfile function which works for Windows, but no equivalent function for other desktop environments - the webbrowser module seems to employ alternative mechanisms in choosing and running external programs and presumably does not seek to provide general support for non-URL resources anyway. Since desktop environments like KDE and GNOME provide mechanisms for running browsers and editors according to the identified type of a file or resource, just as Windows "runs" files or resources, it is appropriate to have a module which accesses these mechanisms. Attached is a simple module which seeks to support KDE, GNOME and Windows - the latter using the existing os.startfile support - and which could be extended to support other desktop environments such as Mac OS X, XFCE, CDE (along with others deemed important and feasible enough to support). Note that this approach is arguably better than that employed by the webbrowser module since most desktop environments already provide mechanisms for configuring and choosing the user's preferred programs for various activities, whereas the webbrowser module makes relatively uninformed guesses (eg. opening Firefox on a KDE desktop configured to use Konqueror as the default browser). Note also that the startfile function is arguably misplaced in the os module; thus, this functionality is supplied as a new module rather than as a patch to the os module, and the name of the function is "open" (like in the webbrowser module) rather than "startfile" which is a fairly Windows specific term. One could also envisage the desktop module residing within the os package to avoid top-level namespace pollution. Recent discussion in the comp.lang.python thread "Open PDF" covering this issue can be found here: http://groups.google.no/group/comp.lang.python/browse_frm/thread/8e00f7c1ccfae166/6168b6728cf64cb7 ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-27 01:20 Message: Logged In: YES user_id=261020 Quite correct about desktop meaning (roughly) what it says, rather than "opener": my mistake. And I see we are all in agreement about what environment variables are for. But, as Paul says, """the decisions then made by the function aren't themselves configurable, but then a developer would arguably be better off using os.system at that point.""" The correct way of dealing with things like these proposed opener environment vars in the Python stdlib at this point in time (in the absence of anything very close to an accepted wider standard) is for applications to do this: if os.environ.has_key("USER_KNOWS_BETTER"): obey_user(fn) else: desktop.open(fn) where one would expect obey_user() to be a one-liner: def obey_user(fn): subprocess.Popen(os.environ["DESKTOP_OPENER"]) So what is to be gained by baking some random new "standard" into the Python stdlib? Clearly, any individual application obeying some such environment var gains little without others following suit with the *same* env var, but that is no reason to include code knowing about eg. OPENER in the stdlib; in fact, that's precisely the reason such code shouldn't be included right now: we don't know what env var (or other mechanism) other apps will end up using. I don't think de facto semi-standardisation across "applications using Python 2.5 and the desktop module" is likely to gain much momentum or prove very useful to the vast majority of end users, but it does make life that extra little bit more complicated for future users and maintainers of Python, and for users and maintainers of applications wishing to "start" files. I suppose you could try and argue that OPENER is simply an implementation detail of open() that should be changed when and if some standard env var name or other mechanism becomes popular, but that doesn't make sense to me: first, we would be exposing this detail to "end-users" (or else what use is it), and second, the presence of code such as the if os.environ.has_key("OPENER") in the last version of desktop.py I looked at makes life slightly *harder* for applications who know about newer, more widespread conventions than some old version of desktop.py knows about. Finally, I don't know what to make of your (Mike) comment that "neither of those carries as much weight with me as running code". Writing code is simply not the problem here: the (obey_user()) code is almost as simple as it gets. The problem here is almost entirely about getting agreement with other people, which, yes, means sometimes-tiresome discussions. Sometimes it means trying to generate de-facto standards and leave those tiresome discussions in the dust, agreed: I guess I'm stating my opinion here that the Python stdlib is not the place to do that, for the reasons I enumerated above and in my ealier post (2005-09-26 00:34). Foolishly trusting in the sanity of humankind, I think that KDE and GNOME will *eventually* get their act together. Am I just totally wrongheaded about this? OK, I must stop this nonsense, perhaps this is just one of those bikesheds... ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 14:08 Message: Logged In: YES user_id=226443 I've now attached another version of the module which observes DESKTOP_LAUNCH, does a bit more verification, and exposes the desktop detection. I'll probably do a bit more reading of the fd.o mailing lists and possibly try and get some answers from the interested parties. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-26 03:25 Message: Logged In: YES user_id=93910 Actually, the guess that the module makes is which desktop the user is on - and that's overridable by the "desktop" argument. The pre-OPENER version of desktop.py had no way to override it's choice of opener - the best you can do is tell it to use the default opener for some desktop it knows about. Further, the "desktop" argument is really only applicable to the application developer. The end-user - the person who actually chooses the launcher to use - can't use it without editing the source to the application. While you may consider this an acceptable configuration mechanism, I don't. The standard Unix mechanism for setting things like this - dating back to the 70s - is an environment variable that names the command to use. If you want to suggest a better mechanism, feel free to do so. Until then the question is what the name should be. Based on what the freedesktop talk, maybe it shold be DESKTOP_OPEN or DESKTOP_LAUNCH. On the other hand, the freedesktop folks seem much better at generating discussion than specifications - and neither of those carries as much weight with me as running code. Part of this does depend on the point of the desktop module. I thought it was to make os.startfile functionality available in a platform-independent manner. If so, it needs to deal with things other than the tools provided by a couple of common desktops. If instead it's supposed to provide access to the knowledge built into the most popular desktops, then ignoring user preferences is reasonable. But that makes it much less usefull. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 01:55 Message: Logged In: YES user_id=226443 Oh, and after the DESKTOP specification, there was the DESKTOP_LAUNCH specification: http://lists.freedesktop.org/archives/xdg/2004-August/004489.html Things happen slowly in desktop standardisation land. Searching for usage of DESKTOP_LAUNCH revealed this interesting script: http://www.mail-archive.com/dashboard-hackers%40gnome.org/msg00762/desktop-launch ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 01:45 Message: Logged In: YES user_id=226443 On environment variables, here's a thread discussing them: http://lists.freedesktop.org/archives/xdg/2004-December/005553.html The discussion ranges from environment variables referring to the desktop (DESKTOP) and a launcher (DESKTOP_LAUNCH) or some kind of information program (DESKTOP_CTL), all the way to such variables referencing .so files which are then dlopened. The abstraction elevator/escalator is thankfully stopped before things get any more complicated. A previous thread (mentioned in the above thread) proposes the DESKTOP variable and the alternative DESKTOP_OPEN variable: http://lists.freedesktop.org/archives/xdg/2004-May/003942.html The above thread continues here, proposing DESKTOP again along with a desktop-open script, later shifting to some people favouring DESKTOP_LAUNCH and some favouring a desktop-launch script: http://lists.freedesktop.org/archives/xdg/2004-May/003995.html A standards document mentioned in the last thread: http://primates.ximian.com/~michael/desktop.txt ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 01:14 Message: Logged In: YES user_id=226443 Actually, "desktop" just provides a way of saying "I'm on KDE not GNOME!" or something similar; the decisions then made by the function aren't themselves configurable, but then a developer would arguably be better off using os.system at that point. The module is really supposed to encapsulate knowledge about how to start programs in various desktop environments, along with a means to detect those environments in the first place. If you as a programmer disagree with the detection, override it; if you as a programmer know better, don't use the function... but do send a patch! As for user overrides, something like OPENER might be needed to get around the decisions taken in the module, although something "lighter" like DESKTOP might also be useful to override just the detection. It astounds me that such simple things haven't been agreed on by the freedesktop people, or at least not in any obvious way. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-26 00:34 Message: Logged In: YES user_id=261020 Why does the desktop module need something more than Paul's "desktop" argument? (Though perhaps "desktop" is not a sufficiently general name, as I think you said.) I don't think it's desirable for Python to start introducing half-baked and nonstandard environment variable conventions, especially in this area. 1. Why should other people start following *Python*'s convention here? 2. Any such convention may be overtaken by efforts with more backing (such as freedesktop), leaving us with cruft in the stdlib, perhaps even cruft that's in conflict with the new standards (what if somebody with actual clout mandates START instead? something will break). 3. Any program that wants to can follow this supposed OPENER convention, without needing to bake it into the stdlib. Having said all that, if you can get agreement from people at freedesktop to agree on OPENER (which might well be possible), and I guess set a useful default at desktop startup, I will worship at your feet ;-) I'm not sure what you mean by "the guesses that the module makes". It makes exactly one guess: which opener to use, and that guess is overridable with the "desktop" argument to open(). ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-25 23:01 Message: Logged In: YES user_id=93910 I suggested OPENER because I saw it in use somewhere while looking for things for open. I couldn't find it when I went looking for it to reply to this. Clearly, the desktop module needs some way for the user to say "I don't care what you think the system looks like - use *this*." If there's a standard for that, we should use it. If there isn't a standard, we get to establish one. Putting it in the beta version so people can play with it is a good idea. Until the module is accepted, nothing is wired down, and testers should know that. Open has been announced in a number of places. It doesn't have it's own web page yet. You can find a link to the tarball at http://www.mired.org/downloads/. It's also listed in PyPI. Other than it's existence showing that desktop needs a way for user to override the guesses the module makes (which the OSS launch tool does for OS X as well), this isn't really the place to discuss open. I've addressed the issues raised here about open in the README file that was posted in the 0.3 version. Further discussion should go to me directly, or to the Python list/newsgroup. If you think it belongs in another forum, please let me know. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-25 16:57 Message: Logged In: YES user_id=261020 If OPENER is not standard in any way (ad hoc or otherwise), why add it? Moght not doing that without talking to other people about it (presumably on freedesktop, including GNOME, KDE. etc. people) be positively harmful? Mike: is this Python version of Apple's "open" actually published on the web somewhere? I can't find it. I also notice that "open" is already in use as a shell wrapper around open (2) the system call. "start" seems unused, FWTW here. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-25 15:26 Message: Logged In: YES user_id=226443 I've uploaded a version which supports OPENER, although I can't find any references to that variable anywhere. By the way, I wonder if the open program's preferences couldn't somehow work with the various freedesktop.org standards if they don't already. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-25 02:01 Message: Logged In: YES user_id=93910 open is a desktop-independent variation on gnome-open and kfmclient. So it's something that desktop could be set up to run, using cmd = ["open", url]. On the other hand, it also exposes an API to Python progams, so you could (in theory) replace Unix-specific parts of desktop with (using the development version): from open import run run(filename, have = ['open']) except that it'd use the users "open" preferences instead of their desktop preferences. This is why I proposed the OPENER environment variable. I don't run a desktop, so the proposed version would default to trying os.startfile. I'd rather it use open. KDE Components->File Associations to do that. All of those editors are installed on my machine. Then I attempted to open this text file: $ file /home/john/test.txt /home/john/test.txt: ASCII text $ cat /home/john/test.txt hello, world $ When I open it by clicking on it from a Konqueror directory listing, GNU emacs running in an X11 window starts up, with the specified file opened. When I use your module: $ python2.4 Python 2.4 (#1, Feb 19 2005, 23:54:54) [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import desktop >>> desktop.open("/home/john/blocking.txt") >>> ...it opens in Konqueror with some embedded editor (KEdit or KWrite, I assume), not directly in any of the editors I specified, and certainly not in emacs. Same applies if I use a URL: >>> desktop.open("file:///home/john/test.txt") This doesn't seem to be the intended behaviour of your module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 From noreply at sourceforge.net Tue Sep 27 03:14:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Sep 2005 18:14:41 -0700 Subject: [Patches] [ python-Patches-1301512 ] desktop module (providing startfile as open, all platforms) Message-ID: Patches item #1301512, was opened at 2005-09-23 11:30 Message generated for change (Comment added) made by mwm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: desktop module (providing startfile as open, all platforms) Initial Comment: Currently, in Python's standard library, there is apparently no coherent, cross-platform way of getting the user's environment to "open" files or resources (ie. show such files in browsers, editors) when requested by a Python program. There is an os.startfile function which works for Windows, but no equivalent function for other desktop environments - the webbrowser module seems to employ alternative mechanisms in choosing and running external programs and presumably does not seek to provide general support for non-URL resources anyway. Since desktop environments like KDE and GNOME provide mechanisms for running browsers and editors according to the identified type of a file or resource, just as Windows "runs" files or resources, it is appropriate to have a module which accesses these mechanisms. Attached is a simple module which seeks to support KDE, GNOME and Windows - the latter using the existing os.startfile support - and which could be extended to support other desktop environments such as Mac OS X, XFCE, CDE (along with others deemed important and feasible enough to support). Note that this approach is arguably better than that employed by the webbrowser module since most desktop environments already provide mechanisms for configuring and choosing the user's preferred programs for various activities, whereas the webbrowser module makes relatively uninformed guesses (eg. opening Firefox on a KDE desktop configured to use Konqueror as the default browser). Note also that the startfile function is arguably misplaced in the os module; thus, this functionality is supplied as a new module rather than as a patch to the os module, and the name of the function is "open" (like in the webbrowser module) rather than "startfile" which is a fairly Windows specific term. One could also envisage the desktop module residing within the os package to avoid top-level namespace pollution. Recent discussion in the comp.lang.python thread "Open PDF" covering this issue can be found here: http://groups.google.no/group/comp.lang.python/browse_frm/thread/8e00f7c1ccfae166/6168b6728cf64cb7 ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-26 20:14 Message: Logged In: YES user_id=93910 I purposely avoided dealing with the "better off using os.system" before, because I didn't think it was relevant. Since you seem to think it's right, let's deal with it. First of all, the code isn't that simple. You want a convention for your environment variable that's flexible enough to deal with the three cases (kde, gnome and OS X) we already have. Just tossing a string to Popen won't cut it. The split() done by the current implementation is problematical - OS X at the very least comes with standard directories with spaces in their names. I'm not proposing a solution to that here - just pointing out the problem. You're advocating that, instead of putting this functionality in desktop, we leave it up to every application writer to write it. That means - at the very least - that every application writer now has to write if os.environ.has_key("DESKTOP_LAUNCH"): else: desktop.open(filename) rather than simply doing: desktop.open(filename) It also means that every application writer has to decide how they're going to deal with possible spaces in the file name in the environment variable, or if they are at all. And they also get to decide which of the various proposed environment variable names they want to use. If the user is lucky, they won't have two applications that use the same name with different conventions. If not, well, that would just suck. Second, if another a standard does emerge, you can fix all the applications by fixing *one* file in stdlib. Better yet, ithe fix can be transitioned in smoothly for all applications by working with that one file. Basically, *not* providing this hook is simply poor software engineering - it makes things harder on the developers, harder on the users, and harder on the maintainers in the future. While not wanting to push forward standards may be a good thing, it's certainly not a reason for doing a wrong thing. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-26 19:20 Message: Logged In: YES user_id=261020 Quite correct about desktop meaning (roughly) what it says, rather than "opener": my mistake. And I see we are all in agreement about what environment variables are for. But, as Paul says, """the decisions then made by the function aren't themselves configurable, but then a developer would arguably be better off using os.system at that point.""" The correct way of dealing with things like these proposed opener environment vars in the Python stdlib at this point in time (in the absence of anything very close to an accepted wider standard) is for applications to do this: if os.environ.has_key("USER_KNOWS_BETTER"): obey_user(fn) else: desktop.open(fn) where one would expect obey_user() to be a one-liner: def obey_user(fn): subprocess.Popen(os.environ["DESKTOP_OPENER"]) So what is to be gained by baking some random new "standard" into the Python stdlib? Clearly, any individual application obeying some such environment var gains little without others following suit with the *same* env var, but that is no reason to include code knowing about eg. OPENER in the stdlib; in fact, that's precisely the reason such code shouldn't be included right now: we don't know what env var (or other mechanism) other apps will end up using. I don't think de facto semi-standardisation across "applications using Python 2.5 and the desktop module" is likely to gain much momentum or prove very useful to the vast majority of end users, but it does make life that extra little bit more complicated for future users and maintainers of Python, and for users and maintainers of applications wishing to "start" files. I suppose you could try and argue that OPENER is simply an implementation detail of open() that should be changed when and if some standard env var name or other mechanism becomes popular, but that doesn't make sense to me: first, we would be exposing this detail to "end-users" (or else what use is it), and second, the presence of code such as the if os.environ.has_key("OPENER") in the last version of desktop.py I looked at makes life slightly *harder* for applications who know about newer, more widespread conventions than some old version of desktop.py knows about. Finally, I don't know what to make of your (Mike) comment that "neither of those carries as much weight with me as running code". Writing code is simply not the problem here: the (obey_user()) code is almost as simple as it gets. The problem here is almost entirely about getting agreement with other people, which, yes, means sometimes-tiresome discussions. Sometimes it means trying to generate de-facto standards and leave those tiresome discussions in the dust, agreed: I guess I'm stating my opinion here that the Python stdlib is not the place to do that, for the reasons I enumerated above and in my ealier post (2005-09-26 00:34). Foolishly trusting in the sanity of humankind, I think that KDE and GNOME will *eventually* get their act together. Am I just totally wrongheaded about this? OK, I must stop this nonsense, perhaps this is just one of those bikesheds... ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 08:08 Message: Logged In: YES user_id=226443 I've now attached another version of the module which observes DESKTOP_LAUNCH, does a bit more verification, and exposes the desktop detection. I'll probably do a bit more reading of the fd.o mailing lists and possibly try and get some answers from the interested parties. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-25 21:25 Message: Logged In: YES user_id=93910 Actually, the guess that the module makes is which desktop the user is on - and that's overridable by the "desktop" argument. The pre-OPENER version of desktop.py had no way to override it's choice of opener - the best you can do is tell it to use the default opener for some desktop it knows about. Further, the "desktop" argument is really only applicable to the application developer. The end-user - the person who actually chooses the launcher to use - can't use it without editing the source to the application. While you may consider this an acceptable configuration mechanism, I don't. The standard Unix mechanism for setting things like this - dating back to the 70s - is an environment variable that names the command to use. If you want to suggest a better mechanism, feel free to do so. Until then the question is what the name should be. Based on what the freedesktop talk, maybe it shold be DESKTOP_OPEN or DESKTOP_LAUNCH. On the other hand, the freedesktop folks seem much better at generating discussion than specifications - and neither of those carries as much weight with me as running code. Part of this does depend on the point of the desktop module. I thought it was to make os.startfile functionality available in a platform-independent manner. If so, it needs to deal with things other than the tools provided by a couple of common desktops. If instead it's supposed to provide access to the knowledge built into the most popular desktops, then ignoring user preferences is reasonable. But that makes it much less usefull. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-25 19:55 Message: Logged In: YES user_id=226443 Oh, and after the DESKTOP specification, there was the DESKTOP_LAUNCH specification: http://lists.freedesktop.org/archives/xdg/2004-August/004489.html Things happen slowly in desktop standardisation land. Searching for usage of DESKTOP_LAUNCH revealed this interesting script: http://www.mail-archive.com/dashboard-hackers%40gnome.org/msg00762/desktop-launch ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-25 19:45 Message: Logged In: YES user_id=226443 On environment variables, here's a thread discussing them: http://lists.freedesktop.org/archives/xdg/2004-December/005553.html The discussion ranges from environment variables referring to the desktop (DESKTOP) and a launcher (DESKTOP_LAUNCH) or some kind of information program (DESKTOP_CTL), all the way to such variables referencing .so files which are then dlopened. The abstraction elevator/escalator is thankfully stopped before things get any more complicated. A previous thread (mentioned in the above thread) proposes the DESKTOP variable and the alternative DESKTOP_OPEN variable: http://lists.freedesktop.org/archives/xdg/2004-May/003942.html The above thread continues here, proposing DESKTOP again along with a desktop-open script, later shifting to some people favouring DESKTOP_LAUNCH and some favouring a desktop-launch script: http://lists.freedesktop.org/archives/xdg/2004-May/003995.html A standards document mentioned in the last thread: http://primates.ximian.com/~michael/desktop.txt ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-25 19:14 Message: Logged In: YES user_id=226443 Actually, "desktop" just provides a way of saying "I'm on KDE not GNOME!" or something similar; the decisions then made by the function aren't themselves configurable, but then a developer would arguably be better off using os.system at that point. The module is really supposed to encapsulate knowledge about how to start programs in various desktop environments, along with a means to detect those environments in the first place. If you as a programmer disagree with the detection, override it; if you as a programmer know better, don't use the function... but do send a patch! As for user overrides, something like OPENER might be needed to get around the decisions taken in the module, although something "lighter" like DESKTOP might also be useful to override just the detection. It astounds me that such simple things haven't been agreed on by the freedesktop people, or at least not in any obvious way. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-25 18:34 Message: Logged In: YES user_id=261020 Why does the desktop module need something more than Paul's "desktop" argument? (Though perhaps "desktop" is not a sufficiently general name, as I think you said.) I don't think it's desirable for Python to start introducing half-baked and nonstandard environment variable conventions, especially in this area. 1. Why should other people start following *Python*'s convention here? 2. Any such convention may be overtaken by efforts with more backing (such as freedesktop), leaving us with cruft in the stdlib, perhaps even cruft that's in conflict with the new standards (what if somebody with actual clout mandates START instead? something will break). 3. Any program that wants to can follow this supposed OPENER convention, without needing to bake it into the stdlib. Having said all that, if you can get agreement from people at freedesktop to agree on OPENER (which might well be possible), and I guess set a useful default at desktop startup, I will worship at your feet ;-) I'm not sure what you mean by "the guesses that the module makes". It makes exactly one guess: which opener to use, and that guess is overridable with the "desktop" argument to open(). ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-25 17:01 Message: Logged In: YES user_id=93910 I suggested OPENER because I saw it in use somewhere while looking for things for open. I couldn't find it when I went looking for it to reply to this. Clearly, the desktop module needs some way for the user to say "I don't care what you think the system looks like - use *this*." If there's a standard for that, we should use it. If there isn't a standard, we get to establish one. Putting it in the beta version so people can play with it is a good idea. Until the module is accepted, nothing is wired down, and testers should know that. Open has been announced in a number of places. It doesn't have it's own web page yet. You can find a link to the tarball at http://www.mired.org/downloads/. It's also listed in PyPI. Other than it's existence showing that desktop needs a way for user to override the guesses the module makes (which the OSS launch tool does for OS X as well), this isn't really the place to discuss open. I've addressed the issues raised here about open in the README file that was posted in the 0.3 version. Further discussion should go to me directly, or to the Python list/newsgroup. If you think it belongs in another forum, please let me know. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-25 10:57 Message: Logged In: YES user_id=261020 If OPENER is not standard in any way (ad hoc or otherwise), why add it? Moght not doing that without talking to other people about it (presumably on freedesktop, including GNOME, KDE. etc. people) be positively harmful? Mike: is this Python version of Apple's "open" actually published on the web somewhere? I can't find it. I also notice that "open" is already in use as a shell wrapper around open (2) the system call. "start" seems unused, FWTW here. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-25 09:26 Message: Logged In: YES user_id=226443 I've uploaded a version which supports OPENER, although I can't find any references to that variable anywhere. By the way, I wonder if the open program's preferences couldn't somehow work with the various freedesktop.org standards if they don't already. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-24 20:01 Message: Logged In: YES user_id=93910 open is a desktop-independent variation on gnome-open and kfmclient. So it's something that desktop could be set up to run, using cmd = ["open", url]. On the other hand, it also exposes an API to Python progams, so you could (in theory) replace Unix-specific parts of desktop with (using the development version): from open import run run(filename, have = ['open']) except that it'd use the users "open" preferences instead of their desktop preferences. This is why I proposed the OPENER environment variable. I don't run a desktop, so the proposed version would default to trying os.startfile. I'd rather it use open. KDE Components->File Associations to do that. All of those editors are installed on my machine. Then I attempted to open this text file: $ file /home/john/test.txt /home/john/test.txt: ASCII text $ cat /home/john/test.txt hello, world $ When I open it by clicking on it from a Konqueror directory listing, GNU emacs running in an X11 window starts up, with the specified file opened. When I use your module: $ python2.4 Python 2.4 (#1, Feb 19 2005, 23:54:54) [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import desktop >>> desktop.open("/home/john/blocking.txt") >>> ...it opens in Konqueror with some embedded editor (KEdit or KWrite, I assume), not directly in any of the editors I specified, and certainly not in emacs. Same applies if I use a URL: >>> desktop.open("file:///home/john/test.txt") This doesn't seem to be the intended behaviour of your module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 From noreply at sourceforge.net Tue Sep 27 12:07:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Sep 2005 03:07:24 -0700 Subject: [Patches] [ python-Patches-1301512 ] desktop module (providing startfile as open, all platforms) Message-ID: Patches item #1301512, was opened at 2005-09-23 18:30 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: desktop module (providing startfile as open, all platforms) Initial Comment: Currently, in Python's standard library, there is apparently no coherent, cross-platform way of getting the user's environment to "open" files or resources (ie. show such files in browsers, editors) when requested by a Python program. There is an os.startfile function which works for Windows, but no equivalent function for other desktop environments - the webbrowser module seems to employ alternative mechanisms in choosing and running external programs and presumably does not seek to provide general support for non-URL resources anyway. Since desktop environments like KDE and GNOME provide mechanisms for running browsers and editors according to the identified type of a file or resource, just as Windows "runs" files or resources, it is appropriate to have a module which accesses these mechanisms. Attached is a simple module which seeks to support KDE, GNOME and Windows - the latter using the existing os.startfile support - and which could be extended to support other desktop environments such as Mac OS X, XFCE, CDE (along with others deemed important and feasible enough to support). Note that this approach is arguably better than that employed by the webbrowser module since most desktop environments already provide mechanisms for configuring and choosing the user's preferred programs for various activities, whereas the webbrowser module makes relatively uninformed guesses (eg. opening Firefox on a KDE desktop configured to use Konqueror as the default browser). Note also that the startfile function is arguably misplaced in the os module; thus, this functionality is supplied as a new module rather than as a patch to the os module, and the name of the function is "open" (like in the webbrowser module) rather than "startfile" which is a fairly Windows specific term. One could also envisage the desktop module residing within the os package to avoid top-level namespace pollution. Recent discussion in the comp.lang.python thread "Open PDF" covering this issue can be found here: http://groups.google.no/group/comp.lang.python/browse_frm/thread/8e00f7c1ccfae166/6168b6728cf64cb7 ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2005-09-27 12:07 Message: Logged In: YES user_id=226443 Well, the latest attachment (the first in the list) goes some way towards providing user override support. I've since posted to the xdg mailing list asking for clarification about environment variables. As for the code, I've now changed the way the environment variable is used - it must be a shell-quoted command plus optional arguments. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-27 03:14 Message: Logged In: YES user_id=93910 I purposely avoided dealing with the "better off using os.system" before, because I didn't think it was relevant. Since you seem to think it's right, let's deal with it. First of all, the code isn't that simple. You want a convention for your environment variable that's flexible enough to deal with the three cases (kde, gnome and OS X) we already have. Just tossing a string to Popen won't cut it. The split() done by the current implementation is problematical - OS X at the very least comes with standard directories with spaces in their names. I'm not proposing a solution to that here - just pointing out the problem. You're advocating that, instead of putting this functionality in desktop, we leave it up to every application writer to write it. That means - at the very least - that every application writer now has to write if os.environ.has_key("DESKTOP_LAUNCH"): else: desktop.open(filename) rather than simply doing: desktop.open(filename) It also means that every application writer has to decide how they're going to deal with possible spaces in the file name in the environment variable, or if they are at all. And they also get to decide which of the various proposed environment variable names they want to use. If the user is lucky, they won't have two applications that use the same name with different conventions. If not, well, that would just suck. Second, if another a standard does emerge, you can fix all the applications by fixing *one* file in stdlib. Better yet, ithe fix can be transitioned in smoothly for all applications by working with that one file. Basically, *not* providing this hook is simply poor software engineering - it makes things harder on the developers, harder on the users, and harder on the maintainers in the future. While not wanting to push forward standards may be a good thing, it's certainly not a reason for doing a wrong thing. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-27 02:20 Message: Logged In: YES user_id=261020 Quite correct about desktop meaning (roughly) what it says, rather than "opener": my mistake. And I see we are all in agreement about what environment variables are for. But, as Paul says, """the decisions then made by the function aren't themselves configurable, but then a developer would arguably be better off using os.system at that point.""" The correct way of dealing with things like these proposed opener environment vars in the Python stdlib at this point in time (in the absence of anything very close to an accepted wider standard) is for applications to do this: if os.environ.has_key("USER_KNOWS_BETTER"): obey_user(fn) else: desktop.open(fn) where one would expect obey_user() to be a one-liner: def obey_user(fn): subprocess.Popen(os.environ["DESKTOP_OPENER"]) So what is to be gained by baking some random new "standard" into the Python stdlib? Clearly, any individual application obeying some such environment var gains little without others following suit with the *same* env var, but that is no reason to include code knowing about eg. OPENER in the stdlib; in fact, that's precisely the reason such code shouldn't be included right now: we don't know what env var (or other mechanism) other apps will end up using. I don't think de facto semi-standardisation across "applications using Python 2.5 and the desktop module" is likely to gain much momentum or prove very useful to the vast majority of end users, but it does make life that extra little bit more complicated for future users and maintainers of Python, and for users and maintainers of applications wishing to "start" files. I suppose you could try and argue that OPENER is simply an implementation detail of open() that should be changed when and if some standard env var name or other mechanism becomes popular, but that doesn't make sense to me: first, we would be exposing this detail to "end-users" (or else what use is it), and second, the presence of code such as the if os.environ.has_key("OPENER") in the last version of desktop.py I looked at makes life slightly *harder* for applications who know about newer, more widespread conventions than some old version of desktop.py knows about. Finally, I don't know what to make of your (Mike) comment that "neither of those carries as much weight with me as running code". Writing code is simply not the problem here: the (obey_user()) code is almost as simple as it gets. The problem here is almost entirely about getting agreement with other people, which, yes, means sometimes-tiresome discussions. Sometimes it means trying to generate de-facto standards and leave those tiresome discussions in the dust, agreed: I guess I'm stating my opinion here that the Python stdlib is not the place to do that, for the reasons I enumerated above and in my ealier post (2005-09-26 00:34). Foolishly trusting in the sanity of humankind, I think that KDE and GNOME will *eventually* get their act together. Am I just totally wrongheaded about this? OK, I must stop this nonsense, perhaps this is just one of those bikesheds... ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 15:08 Message: Logged In: YES user_id=226443 I've now attached another version of the module which observes DESKTOP_LAUNCH, does a bit more verification, and exposes the desktop detection. I'll probably do a bit more reading of the fd.o mailing lists and possibly try and get some answers from the interested parties. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-26 04:25 Message: Logged In: YES user_id=93910 Actually, the guess that the module makes is which desktop the user is on - and that's overridable by the "desktop" argument. The pre-OPENER version of desktop.py had no way to override it's choice of opener - the best you can do is tell it to use the default opener for some desktop it knows about. Further, the "desktop" argument is really only applicable to the application developer. The end-user - the person who actually chooses the launcher to use - can't use it without editing the source to the application. While you may consider this an acceptable configuration mechanism, I don't. The standard Unix mechanism for setting things like this - dating back to the 70s - is an environment variable that names the command to use. If you want to suggest a better mechanism, feel free to do so. Until then the question is what the name should be. Based on what the freedesktop talk, maybe it shold be DESKTOP_OPEN or DESKTOP_LAUNCH. On the other hand, the freedesktop folks seem much better at generating discussion than specifications - and neither of those carries as much weight with me as running code. Part of this does depend on the point of the desktop module. I thought it was to make os.startfile functionality available in a platform-independent manner. If so, it needs to deal with things other than the tools provided by a couple of common desktops. If instead it's supposed to provide access to the knowledge built into the most popular desktops, then ignoring user preferences is reasonable. But that makes it much less usefull. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 02:55 Message: Logged In: YES user_id=226443 Oh, and after the DESKTOP specification, there was the DESKTOP_LAUNCH specification: http://lists.freedesktop.org/archives/xdg/2004-August/004489.html Things happen slowly in desktop standardisation land. Searching for usage of DESKTOP_LAUNCH revealed this interesting script: http://www.mail-archive.com/dashboard-hackers%40gnome.org/msg00762/desktop-launch ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 02:45 Message: Logged In: YES user_id=226443 On environment variables, here's a thread discussing them: http://lists.freedesktop.org/archives/xdg/2004-December/005553.html The discussion ranges from environment variables referring to the desktop (DESKTOP) and a launcher (DESKTOP_LAUNCH) or some kind of information program (DESKTOP_CTL), all the way to such variables referencing .so files which are then dlopened. The abstraction elevator/escalator is thankfully stopped before things get any more complicated. A previous thread (mentioned in the above thread) proposes the DESKTOP variable and the alternative DESKTOP_OPEN variable: http://lists.freedesktop.org/archives/xdg/2004-May/003942.html The above thread continues here, proposing DESKTOP again along with a desktop-open script, later shifting to some people favouring DESKTOP_LAUNCH and some favouring a desktop-launch script: http://lists.freedesktop.org/archives/xdg/2004-May/003995.html A standards document mentioned in the last thread: http://primates.ximian.com/~michael/desktop.txt ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 02:14 Message: Logged In: YES user_id=226443 Actually, "desktop" just provides a way of saying "I'm on KDE not GNOME!" or something similar; the decisions then made by the function aren't themselves configurable, but then a developer would arguably be better off using os.system at that point. The module is really supposed to encapsulate knowledge about how to start programs in various desktop environments, along with a means to detect those environments in the first place. If you as a programmer disagree with the detection, override it; if you as a programmer know better, don't use the function... but do send a patch! As for user overrides, something like OPENER might be needed to get around the decisions taken in the module, although something "lighter" like DESKTOP might also be useful to override just the detection. It astounds me that such simple things haven't been agreed on by the freedesktop people, or at least not in any obvious way. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-26 01:34 Message: Logged In: YES user_id=261020 Why does the desktop module need something more than Paul's "desktop" argument? (Though perhaps "desktop" is not a sufficiently general name, as I think you said.) I don't think it's desirable for Python to start introducing half-baked and nonstandard environment variable conventions, especially in this area. 1. Why should other people start following *Python*'s convention here? 2. Any such convention may be overtaken by efforts with more backing (such as freedesktop), leaving us with cruft in the stdlib, perhaps even cruft that's in conflict with the new standards (what if somebody with actual clout mandates START instead? something will break). 3. Any program that wants to can follow this supposed OPENER convention, without needing to bake it into the stdlib. Having said all that, if you can get agreement from people at freedesktop to agree on OPENER (which might well be possible), and I guess set a useful default at desktop startup, I will worship at your feet ;-) I'm not sure what you mean by "the guesses that the module makes". It makes exactly one guess: which opener to use, and that guess is overridable with the "desktop" argument to open(). ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-26 00:01 Message: Logged In: YES user_id=93910 I suggested OPENER because I saw it in use somewhere while looking for things for open. I couldn't find it when I went looking for it to reply to this. Clearly, the desktop module needs some way for the user to say "I don't care what you think the system looks like - use *this*." If there's a standard for that, we should use it. If there isn't a standard, we get to establish one. Putting it in the beta version so people can play with it is a good idea. Until the module is accepted, nothing is wired down, and testers should know that. Open has been announced in a number of places. It doesn't have it's own web page yet. You can find a link to the tarball at http://www.mired.org/downloads/. It's also listed in PyPI. Other than it's existence showing that desktop needs a way for user to override the guesses the module makes (which the OSS launch tool does for OS X as well), this isn't really the place to discuss open. I've addressed the issues raised here about open in the README file that was posted in the 0.3 version. Further discussion should go to me directly, or to the Python list/newsgroup. If you think it belongs in another forum, please let me know. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-25 17:57 Message: Logged In: YES user_id=261020 If OPENER is not standard in any way (ad hoc or otherwise), why add it? Moght not doing that without talking to other people about it (presumably on freedesktop, including GNOME, KDE. etc. people) be positively harmful? Mike: is this Python version of Apple's "open" actually published on the web somewhere? I can't find it. I also notice that "open" is already in use as a shell wrapper around open (2) the system call. "start" seems unused, FWTW here. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-25 16:26 Message: Logged In: YES user_id=226443 I've uploaded a version which supports OPENER, although I can't find any references to that variable anywhere. By the way, I wonder if the open program's preferences couldn't somehow work with the various freedesktop.org standards if they don't already. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-25 03:01 Message: Logged In: YES user_id=93910 open is a desktop-independent variation on gnome-open and kfmclient. So it's something that desktop could be set up to run, using cmd = ["open", url]. On the other hand, it also exposes an API to Python progams, so you could (in theory) replace Unix-specific parts of desktop with (using the development version): from open import run run(filename, have = ['open']) except that it'd use the users "open" preferences instead of their desktop preferences. This is why I proposed the OPENER environment variable. I don't run a desktop, so the proposed version would default to trying os.startfile. I'd rather it use open. KDE Components->File Associations to do that. All of those editors are installed on my machine. Then I attempted to open this text file: $ file /home/john/test.txt /home/john/test.txt: ASCII text $ cat /home/john/test.txt hello, world $ When I open it by clicking on it from a Konqueror directory listing, GNU emacs running in an X11 window starts up, with the specified file opened. When I use your module: $ python2.4 Python 2.4 (#1, Feb 19 2005, 23:54:54) [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import desktop >>> desktop.open("/home/john/blocking.txt") >>> ...it opens in Konqueror with some embedded editor (KEdit or KWrite, I assume), not directly in any of the editors I specified, and certainly not in emacs. Same applies if I use a URL: >>> desktop.open("file:///home/john/test.txt") This doesn't seem to be the intended behaviour of your module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 From noreply at sourceforge.net Tue Sep 27 12:50:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Sep 2005 03:50:33 -0700 Subject: [Patches] [ python-Patches-1301512 ] desktop module (providing startfile as open, all platforms) Message-ID: Patches item #1301512, was opened at 2005-09-23 17:30 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: desktop module (providing startfile as open, all platforms) Initial Comment: Currently, in Python's standard library, there is apparently no coherent, cross-platform way of getting the user's environment to "open" files or resources (ie. show such files in browsers, editors) when requested by a Python program. There is an os.startfile function which works for Windows, but no equivalent function for other desktop environments - the webbrowser module seems to employ alternative mechanisms in choosing and running external programs and presumably does not seek to provide general support for non-URL resources anyway. Since desktop environments like KDE and GNOME provide mechanisms for running browsers and editors according to the identified type of a file or resource, just as Windows "runs" files or resources, it is appropriate to have a module which accesses these mechanisms. Attached is a simple module which seeks to support KDE, GNOME and Windows - the latter using the existing os.startfile support - and which could be extended to support other desktop environments such as Mac OS X, XFCE, CDE (along with others deemed important and feasible enough to support). Note that this approach is arguably better than that employed by the webbrowser module since most desktop environments already provide mechanisms for configuring and choosing the user's preferred programs for various activities, whereas the webbrowser module makes relatively uninformed guesses (eg. opening Firefox on a KDE desktop configured to use Konqueror as the default browser). Note also that the startfile function is arguably misplaced in the os module; thus, this functionality is supplied as a new module rather than as a patch to the os module, and the name of the function is "open" (like in the webbrowser module) rather than "startfile" which is a fairly Windows specific term. One could also envisage the desktop module residing within the os package to avoid top-level namespace pollution. Recent discussion in the comp.lang.python thread "Open PDF" covering this issue can be found here: http://groups.google.no/group/comp.lang.python/browse_frm/thread/8e00f7c1ccfae166/6168b6728cf64cb7 ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-27 11:50 Message: Logged In: YES user_id=261020 Mike: I'm unpersuaded, but I've nothing to add to what I've already said, so I'll shut up now :-) ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-27 11:07 Message: Logged In: YES user_id=226443 Well, the latest attachment (the first in the list) goes some way towards providing user override support. I've since posted to the xdg mailing list asking for clarification about environment variables. As for the code, I've now changed the way the environment variable is used - it must be a shell-quoted command plus optional arguments. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-27 02:14 Message: Logged In: YES user_id=93910 I purposely avoided dealing with the "better off using os.system" before, because I didn't think it was relevant. Since you seem to think it's right, let's deal with it. First of all, the code isn't that simple. You want a convention for your environment variable that's flexible enough to deal with the three cases (kde, gnome and OS X) we already have. Just tossing a string to Popen won't cut it. The split() done by the current implementation is problematical - OS X at the very least comes with standard directories with spaces in their names. I'm not proposing a solution to that here - just pointing out the problem. You're advocating that, instead of putting this functionality in desktop, we leave it up to every application writer to write it. That means - at the very least - that every application writer now has to write if os.environ.has_key("DESKTOP_LAUNCH"): else: desktop.open(filename) rather than simply doing: desktop.open(filename) It also means that every application writer has to decide how they're going to deal with possible spaces in the file name in the environment variable, or if they are at all. And they also get to decide which of the various proposed environment variable names they want to use. If the user is lucky, they won't have two applications that use the same name with different conventions. If not, well, that would just suck. Second, if another a standard does emerge, you can fix all the applications by fixing *one* file in stdlib. Better yet, ithe fix can be transitioned in smoothly for all applications by working with that one file. Basically, *not* providing this hook is simply poor software engineering - it makes things harder on the developers, harder on the users, and harder on the maintainers in the future. While not wanting to push forward standards may be a good thing, it's certainly not a reason for doing a wrong thing. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-27 01:20 Message: Logged In: YES user_id=261020 Quite correct about desktop meaning (roughly) what it says, rather than "opener": my mistake. And I see we are all in agreement about what environment variables are for. But, as Paul says, """the decisions then made by the function aren't themselves configurable, but then a developer would arguably be better off using os.system at that point.""" The correct way of dealing with things like these proposed opener environment vars in the Python stdlib at this point in time (in the absence of anything very close to an accepted wider standard) is for applications to do this: if os.environ.has_key("USER_KNOWS_BETTER"): obey_user(fn) else: desktop.open(fn) where one would expect obey_user() to be a one-liner: def obey_user(fn): subprocess.Popen(os.environ["DESKTOP_OPENER"]) So what is to be gained by baking some random new "standard" into the Python stdlib? Clearly, any individual application obeying some such environment var gains little without others following suit with the *same* env var, but that is no reason to include code knowing about eg. OPENER in the stdlib; in fact, that's precisely the reason such code shouldn't be included right now: we don't know what env var (or other mechanism) other apps will end up using. I don't think de facto semi-standardisation across "applications using Python 2.5 and the desktop module" is likely to gain much momentum or prove very useful to the vast majority of end users, but it does make life that extra little bit more complicated for future users and maintainers of Python, and for users and maintainers of applications wishing to "start" files. I suppose you could try and argue that OPENER is simply an implementation detail of open() that should be changed when and if some standard env var name or other mechanism becomes popular, but that doesn't make sense to me: first, we would be exposing this detail to "end-users" (or else what use is it), and second, the presence of code such as the if os.environ.has_key("OPENER") in the last version of desktop.py I looked at makes life slightly *harder* for applications who know about newer, more widespread conventions than some old version of desktop.py knows about. Finally, I don't know what to make of your (Mike) comment that "neither of those carries as much weight with me as running code". Writing code is simply not the problem here: the (obey_user()) code is almost as simple as it gets. The problem here is almost entirely about getting agreement with other people, which, yes, means sometimes-tiresome discussions. Sometimes it means trying to generate de-facto standards and leave those tiresome discussions in the dust, agreed: I guess I'm stating my opinion here that the Python stdlib is not the place to do that, for the reasons I enumerated above and in my ealier post (2005-09-26 00:34). Foolishly trusting in the sanity of humankind, I think that KDE and GNOME will *eventually* get their act together. Am I just totally wrongheaded about this? OK, I must stop this nonsense, perhaps this is just one of those bikesheds... ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 14:08 Message: Logged In: YES user_id=226443 I've now attached another version of the module which observes DESKTOP_LAUNCH, does a bit more verification, and exposes the desktop detection. I'll probably do a bit more reading of the fd.o mailing lists and possibly try and get some answers from the interested parties. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-26 03:25 Message: Logged In: YES user_id=93910 Actually, the guess that the module makes is which desktop the user is on - and that's overridable by the "desktop" argument. The pre-OPENER version of desktop.py had no way to override it's choice of opener - the best you can do is tell it to use the default opener for some desktop it knows about. Further, the "desktop" argument is really only applicable to the application developer. The end-user - the person who actually chooses the launcher to use - can't use it without editing the source to the application. While you may consider this an acceptable configuration mechanism, I don't. The standard Unix mechanism for setting things like this - dating back to the 70s - is an environment variable that names the command to use. If you want to suggest a better mechanism, feel free to do so. Until then the question is what the name should be. Based on what the freedesktop talk, maybe it shold be DESKTOP_OPEN or DESKTOP_LAUNCH. On the other hand, the freedesktop folks seem much better at generating discussion than specifications - and neither of those carries as much weight with me as running code. Part of this does depend on the point of the desktop module. I thought it was to make os.startfile functionality available in a platform-independent manner. If so, it needs to deal with things other than the tools provided by a couple of common desktops. If instead it's supposed to provide access to the knowledge built into the most popular desktops, then ignoring user preferences is reasonable. But that makes it much less usefull. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 01:55 Message: Logged In: YES user_id=226443 Oh, and after the DESKTOP specification, there was the DESKTOP_LAUNCH specification: http://lists.freedesktop.org/archives/xdg/2004-August/004489.html Things happen slowly in desktop standardisation land. Searching for usage of DESKTOP_LAUNCH revealed this interesting script: http://www.mail-archive.com/dashboard-hackers%40gnome.org/msg00762/desktop-launch ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 01:45 Message: Logged In: YES user_id=226443 On environment variables, here's a thread discussing them: http://lists.freedesktop.org/archives/xdg/2004-December/005553.html The discussion ranges from environment variables referring to the desktop (DESKTOP) and a launcher (DESKTOP_LAUNCH) or some kind of information program (DESKTOP_CTL), all the way to such variables referencing .so files which are then dlopened. The abstraction elevator/escalator is thankfully stopped before things get any more complicated. A previous thread (mentioned in the above thread) proposes the DESKTOP variable and the alternative DESKTOP_OPEN variable: http://lists.freedesktop.org/archives/xdg/2004-May/003942.html The above thread continues here, proposing DESKTOP again along with a desktop-open script, later shifting to some people favouring DESKTOP_LAUNCH and some favouring a desktop-launch script: http://lists.freedesktop.org/archives/xdg/2004-May/003995.html A standards document mentioned in the last thread: http://primates.ximian.com/~michael/desktop.txt ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 01:14 Message: Logged In: YES user_id=226443 Actually, "desktop" just provides a way of saying "I'm on KDE not GNOME!" or something similar; the decisions then made by the function aren't themselves configurable, but then a developer would arguably be better off using os.system at that point. The module is really supposed to encapsulate knowledge about how to start programs in various desktop environments, along with a means to detect those environments in the first place. If you as a programmer disagree with the detection, override it; if you as a programmer know better, don't use the function... but do send a patch! As for user overrides, something like OPENER might be needed to get around the decisions taken in the module, although something "lighter" like DESKTOP might also be useful to override just the detection. It astounds me that such simple things haven't been agreed on by the freedesktop people, or at least not in any obvious way. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-26 00:34 Message: Logged In: YES user_id=261020 Why does the desktop module need something more than Paul's "desktop" argument? (Though perhaps "desktop" is not a sufficiently general name, as I think you said.) I don't think it's desirable for Python to start introducing half-baked and nonstandard environment variable conventions, especially in this area. 1. Why should other people start following *Python*'s convention here? 2. Any such convention may be overtaken by efforts with more backing (such as freedesktop), leaving us with cruft in the stdlib, perhaps even cruft that's in conflict with the new standards (what if somebody with actual clout mandates START instead? something will break). 3. Any program that wants to can follow this supposed OPENER convention, without needing to bake it into the stdlib. Having said all that, if you can get agreement from people at freedesktop to agree on OPENER (which might well be possible), and I guess set a useful default at desktop startup, I will worship at your feet ;-) I'm not sure what you mean by "the guesses that the module makes". It makes exactly one guess: which opener to use, and that guess is overridable with the "desktop" argument to open(). ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-25 23:01 Message: Logged In: YES user_id=93910 I suggested OPENER because I saw it in use somewhere while looking for things for open. I couldn't find it when I went looking for it to reply to this. Clearly, the desktop module needs some way for the user to say "I don't care what you think the system looks like - use *this*." If there's a standard for that, we should use it. If there isn't a standard, we get to establish one. Putting it in the beta version so people can play with it is a good idea. Until the module is accepted, nothing is wired down, and testers should know that. Open has been announced in a number of places. It doesn't have it's own web page yet. You can find a link to the tarball at http://www.mired.org/downloads/. It's also listed in PyPI. Other than it's existence showing that desktop needs a way for user to override the guesses the module makes (which the OSS launch tool does for OS X as well), this isn't really the place to discuss open. I've addressed the issues raised here about open in the README file that was posted in the 0.3 version. Further discussion should go to me directly, or to the Python list/newsgroup. If you think it belongs in another forum, please let me know. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-25 16:57 Message: Logged In: YES user_id=261020 If OPENER is not standard in any way (ad hoc or otherwise), why add it? Moght not doing that without talking to other people about it (presumably on freedesktop, including GNOME, KDE. etc. people) be positively harmful? Mike: is this Python version of Apple's "open" actually published on the web somewhere? I can't find it. I also notice that "open" is already in use as a shell wrapper around open (2) the system call. "start" seems unused, FWTW here. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-25 15:26 Message: Logged In: YES user_id=226443 I've uploaded a version which supports OPENER, although I can't find any references to that variable anywhere. By the way, I wonder if the open program's preferences couldn't somehow work with the various freedesktop.org standards if they don't already. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-25 02:01 Message: Logged In: YES user_id=93910 open is a desktop-independent variation on gnome-open and kfmclient. So it's something that desktop could be set up to run, using cmd = ["open", url]. On the other hand, it also exposes an API to Python progams, so you could (in theory) replace Unix-specific parts of desktop with (using the development version): from open import run run(filename, have = ['open']) except that it'd use the users "open" preferences instead of their desktop preferences. This is why I proposed the OPENER environment variable. I don't run a desktop, so the proposed version would default to trying os.startfile. I'd rather it use open. KDE Components->File Associations to do that. All of those editors are installed on my machine. Then I attempted to open this text file: $ file /home/john/test.txt /home/john/test.txt: ASCII text $ cat /home/john/test.txt hello, world $ When I open it by clicking on it from a Konqueror directory listing, GNU emacs running in an X11 window starts up, with the specified file opened. When I use your module: $ python2.4 Python 2.4 (#1, Feb 19 2005, 23:54:54) [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import desktop >>> desktop.open("/home/john/blocking.txt") >>> ...it opens in Konqueror with some embedded editor (KEdit or KWrite, I assume), not directly in any of the editors I specified, and certainly not in emacs. Same applies if I use a URL: >>> desktop.open("file:///home/john/test.txt") This doesn't seem to be the intended behaviour of your module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 From noreply at sourceforge.net Tue Sep 27 23:03:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Sep 2005 14:03:37 -0700 Subject: [Patches] [ python-Patches-1212837 ] Improved profiler Message-ID: Patches item #1212837, was opened at 2005-06-01 16:05 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212837&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Brett Rosen (bdrosen) Assigned to: Nobody/Anonymous (nobody) Summary: Improved profiler Initial Comment: I tried using both hotshot and the old python profiler and found them both to be inadequate. The old python profiler seems to give accurate results for timing, but is slow enough that it adds significant overhead to what it is measuing (approximately 10 times). Furthermore, it has no ability to give detailed stats about children. (how much of the cumulative time was taken up by each function called by a function) The hotshot profiler is much faster (profiling) adding only 30% overhead. However, it is extremely slow to load the results from the log file. It does not currently support detailed child stats, although I imagine that it could be made to do so using the information in the log file. The biggest problem with it, is that the time results seem to be highly inaccurate. (doesn't correspond to actual seconds, although they seem to be proportionally wrong) To address these shortcomings, I wrote a new profiling module. It adds about the same overhead (30%) as hotshot, but is much faster in retrieving results. It supports detailed child stats and gives accurate timing information in milliseconds. The accompanying .py module could use additional work though - because of the child stats, I was not able to reuse the stats module like hotshot does. I've included a simple test script that runs pystone for all 3 profilers (and without the profiler) to give a better idea of the differences. I've also included a dump of the output of the script running under Windows XP with python 2.4.1 ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-09-27 21:03 Message: Logged In: YES user_id=4771 1 The Py_INCREF(_code) at line 86 is the same as in your original code; it should guarantee that the code object doesn't go away. However, I forgot the corresponding Py_DECREF()... 2 It was a quick hack to have help(lsprof) display these types as well. Now I'm no longer sure that we need help(lsprof) to display them anyway, so let's use the standard '_lsprof.XXX' names. 3 Profiling a large program took forever. I interrupted it after 30 minutes when it showed no sign of wanting to go past the initial step that normally takes only a few minutes. With rotating trees this step is fast again. Maybe they are not an optimal structure, though, because it still takes something like three times longer to finish the whole program (normally takes half an hour). 4 No. Checked in your proposed changes. What is still missing: deciding how much similar to the profiler.py and pstats.py API we need to be, and writing some tests (ideally, having good test coverage would be nice). ---------------------------------------------------------------------- Comment By: Brett Rosen (bdrosen) Date: 2005-09-26 13:54 Message: Logged In: YES user_id=1289249 I looked over the changes so far and they look reasonable. I did have a few questions though: 1 Do we not need to Increment/Decrement references to the code objects? We are using them as keys in the trees as well as payload data later on, but I don't see how we are guaranteed that they won't be reaped. (although it seems unlikely) 2 Is it deliberate to use lsprof.YYY style names for some of the objects (ie lsprof.Profiler) instead of _lsprof ? (is this the normal convention?) 3 Do you have a feel for the performance differences of using the tree instead of the lists? Doing the simple benchmark test they seemed to be comparable, but that test is pretty simple. I'm assuming tht in a large program, the tree approach will be considerably faster? 4 In lsprof.py, is there a reason that the Stats class does not derive from object? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-23 07:46 Message: Logged In: YES user_id=4771 I replaced the linked lists with some kind of auto-balacing trees; the linked lists were creating a huge overhead to profile large programs. The reason for not using plain Python dicts instead is that PyCodeObjects are not very good at being keys in dicts -- their hash computation takes ages, and we'd prefer an identity mapping anyway. The current SVN version is now the first profiler that works and gives sensible results when profiling the PyPy translation process. getstats() is now producing tuples-with-attribute-names instead of dicts (similar to os.stat()). This was mostly motivated by a lack of motivation to introduce error checking everywhere in the dict-building code, but I think it's a reasonable change. There are only a couple of places left in profile.c still missing checks for error results or out-of-memory conditions. The lsprof.py module exposes a simple but minimalistic interface. I suggest we keep and document it or a similar one, but also support -- for compatibility -- the convoluted interface of the existing profile.py/pstats.py and/or hotshot, with the option to dump the stats to a file and reload them. However I don't think it makes sense to use exactly the same format as pstats does (as far as I can guess it doesn't support per-caller information). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-09-21 18:35 Message: Logged In: YES user_id=6656 Well, you can see what we've done to your baby: http://codespeak.net/svn/user/arigo/hack/misc/lsprof/profile.c Mostly it's just C style conformance so far, though we've fixed a couple of little bugs too. ---------------------------------------------------------------------- Comment By: Brett Rosen (bdrosen) Date: 2005-09-21 17:43 Message: Logged In: YES user_id=1289249 I welcome any additional changes (and help making those changes) that would improve the patch and help get it ready for inclusion in CPython. The main detail that I knew that would need to be addressed was lspstats.py. I didn't spend a lot of time working on it because I generally use a wx TreeListCtrl object to view/sort the results. What other details need to be addressed? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-21 15:57 Message: Logged In: YES user_id=4771 Thanks for your work. The two existing profilers are definitely not satisfactory in my opinion too (I am also encountering crashes with profile.py). There are a number of details that should be addressed before your profiler can be a replacement for the existing ones, e.g. providing simple entry points and documentations, and having the C code reviewed. I am willing to help with all this. I hope you won't mind that I have checked your source code in a public Subversion repository, where I am working a bit on it together with Michael Hudson. (Obviously, the goal is to have the code eventually in the CPython CVS.) http://codespeak.net/svn/user/arigo/hack/misc/lsprof/ ---------------------------------------------------------------------- Comment By: Laura Creighton (lcreighton) Date: 2005-09-21 15:18 Message: Logged In: YES user_id=376262 We've been using Hotshot at Strakt for a while now. We tried your patch and it worked precisely as advertised. Thank you for writing it. Laura Creighton ---------------------------------------------------------------------- Comment By: Brett Rosen (bdrosen) Date: 2005-09-08 15:25 Message: Logged In: YES user_id=1289249 I've enclosed an updated version of profile.c that fixes a problem in the original patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212837&group_id=5470 From noreply at sourceforge.net Tue Sep 27 23:34:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Sep 2005 14:34:41 -0700 Subject: [Patches] [ python-Patches-1292625 ] use LIST_APPEND opcode for X.append() method calls Message-ID: Patches item #1292625, was opened at 2005-09-16 07:14 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1292625&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: use LIST_APPEND opcode for X.append() method calls Initial Comment: As discussed on python-dev here: http://mail.python.org/pipermail/python-dev/2005-September/056396.html This is a more complete version. It seems to speed up code that makes heavy use of append by about 1.5 - 2.0 % ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-09-27 21:34 Message: Logged In: YES user_id=4771 I vote -1 on this: * these peephole transformations need a lot of care to get perfectly right. For example, I think that you are not checking that there is really a LOAD_XXX between LOAD_ATTR and CALL_FUNCTION, which means that you'll incorrectly match e.g. the bytecode of the line 'f(x.prepend < x.append)' and turn it into something very broken. * I don't remember seeing ever discussed the fact that CALL_METHOD-style optimizations are a semantic change: in 'x.append(f())', the LOAD_ATTR occurs before the call to f(), whereas with the optimization it occurs after. No sane code should rely on that, but the language specification tends to promize a left-to-right evaluation order unless otherwise specified. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-16 08:12 Message: Logged In: YES user_id=80475 -0 on this one. It really needs a much larger improvement (30% to 50%) to be worth it. The new ceval.c code for LIST_APPEND will slightly slow-down the list comprehension case that the opcode was originally designed for. Also, it slows-down the peepholer with a string comparison test for every attribute lookup making it the slowest and most frequently executed code in the peepholer. The implementation is limited to the simplest case, x.append(y) and cannot handle general expressions such x.append(y+y). It would likely be better to implement this sort of transformation through AST when it is complete. If it goes in anyway, be sure to add a test to make sure descriptors still work (i.e. a non-data descriptor called "append" for a user defined class). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1292625&group_id=5470 From noreply at sourceforge.net Wed Sep 28 07:50:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Sep 2005 22:50:24 -0700 Subject: [Patches] [ python-Patches-1292625 ] use LIST_APPEND opcode for X.append() method calls Message-ID: Patches item #1292625, was opened at 2005-09-16 00:14 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1292625&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: use LIST_APPEND opcode for X.append() method calls Initial Comment: As discussed on python-dev here: http://mail.python.org/pipermail/python-dev/2005-September/056396.html This is a more complete version. It seems to speed up code that makes heavy use of append by about 1.5 - 2.0 % ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-27 22:50 Message: Logged In: YES user_id=33168 Response to Armin: 1) I think you are correct there is a problem with f(x.pp < x.append). 2) I don't know if there was a discussion on the semantic changes. Response to Raymond: The improvement is on the order of 50% for code that just does L.append(). It was ~2% for Tim's program that is referenced in the mail thread. ie, it was the total program speed up, not just a simple test specifically for this feature. I'm not real keen on this patch as it's too targetted. I think the arguments could be overcome, however, time is better spent on a more general solution. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-27 14:34 Message: Logged In: YES user_id=4771 I vote -1 on this: * these peephole transformations need a lot of care to get perfectly right. For example, I think that you are not checking that there is really a LOAD_XXX between LOAD_ATTR and CALL_FUNCTION, which means that you'll incorrectly match e.g. the bytecode of the line 'f(x.prepend < x.append)' and turn it into something very broken. * I don't remember seeing ever discussed the fact that CALL_METHOD-style optimizations are a semantic change: in 'x.append(f())', the LOAD_ATTR occurs before the call to f(), whereas with the optimization it occurs after. No sane code should rely on that, but the language specification tends to promize a left-to-right evaluation order unless otherwise specified. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-16 01:12 Message: Logged In: YES user_id=80475 -0 on this one. It really needs a much larger improvement (30% to 50%) to be worth it. The new ceval.c code for LIST_APPEND will slightly slow-down the list comprehension case that the opcode was originally designed for. Also, it slows-down the peepholer with a string comparison test for every attribute lookup making it the slowest and most frequently executed code in the peepholer. The implementation is limited to the simplest case, x.append(y) and cannot handle general expressions such x.append(y+y). It would likely be better to implement this sort of transformation through AST when it is complete. If it goes in anyway, be sure to add a test to make sure descriptors still work (i.e. a non-data descriptor called "append" for a user defined class). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1292625&group_id=5470 From noreply at sourceforge.net Wed Sep 28 16:22:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Sep 2005 07:22:12 -0700 Subject: [Patches] [ python-Patches-723312 ] ability to pass a timeout to underlying socket Message-ID: Patches item #723312, was opened at 2003-04-17 21:03 Message generated for change (Comment added) made by zeidler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723312&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: Works For Me Priority: 6 Submitted By: Matthew Russell (mattruss) Assigned to: Skip Montanaro (montanaro) Summary: ability to pass a timeout to underlying socket Initial Comment: this patch superceeds an earlier one i posted (#714592) - a bit *too* enthusiastic am afraid (sorry!) classes in modules such as httplib, ftpplib do not currently allow an easy way to take advantage of the new socket timeout feature in 2.3. This patch provides that abilty though one additonal class in socket.py ( socket.NetworkConnection ) and accompying test in test_socket.py (basic though the test is :-s ) As an extra benifit, the patch removes duplicate code, as each connect method in the main class of most modules (FTP, HTTPConnection, Telnet, POP3 etc) are copies of each other. The modules that use sockets are: * ftplib * httplib * telnetlib * poplib * urllib * imaplib * nntplib * xmlrpclib Of these I have only been able to easily refactor NetworkConnection into httplib, ftplib, telnetllib, poplib and smtplib. I did look to see if there were any unittests for theese modules in .Lib/test but found none (? - I appologise if there are some, i am new to the library tests) I did however check that the test() [like] methods at the bottom of each of the afore mentioned modules worked. thanks for your advice again Skip :o) Matt ---------------------------------------------------------------------- Comment By: zeidler (zeidler) Date: 2005-09-28 16:22 Message: Logged In: YES user_id=1082576 perhaps to add a little emphasis: i'd really like to see that patch included into one of the next releases too. i was just going to submit my own, much much simpler version of adding a socket timeout in httplib.py, but matt's patch is a much better way to do this... we're using xml-rpc a lot over here, and the default timeouts are just way too long to keep up a decent user interaction in case of server problems. so, we'd really appreciate this becoming part of the distro! ;) thanks & good job matt, andi ---------------------------------------------------------------------- Comment By: Gr?goire Weber (gregweb) Date: 2005-01-12 14:52 Message: Logged In: YES user_id=812601 Just lobbying: It would be nice to have that on board in futire python versions. Would this be possible in python 2.4.1? I need timeouts for xmlrpclib and subclassed xmlrpclib.Transport for my needs. But nevertheless it would be nice to have that in python 2.4.1. Thanks! Gregoire ---------------------------------------------------------------------- Comment By: Matthew Russell (mattruss) Date: 2003-04-21 01:20 Message: Logged In: YES user_id=737261 Errata: i forgot to mention urlllib2 as modules affected. the line above starting "The modules that use sockets are: " should really read: "classes in the modules stated below would benifit from the ability pass timeouts:" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723312&group_id=5470 From noreply at sourceforge.net Thu Sep 29 08:29:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Sep 2005 23:29:55 -0700 Subject: [Patches] [ python-Patches-936813 ] fast modular exponentiation Message-ID: Patches item #936813, was opened at 2004-04-17 01:16 Message generated for change (Comment added) made by trevp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936813&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Trevor Perrin (trevp) Assigned to: Nobody/Anonymous (nobody) Summary: fast modular exponentiation Initial Comment: For crypto-sized numbers, Python mod-exp is several times slower than GMP or OpenSSL (6x or more). Those libraries do crazy special-case stuff, + assembly, platform-specific tuning, and so on. However, there's some low-hanging fruit: this patch has a few basic optimizations giving a 2-3x speedup for numbers in the 1000-8000 bit range (that's what I've mostly tested; but the patch should improve, or at least not hurt, everything else): - x_mul() is special-cased for squaring, which is almost twice as fast as general multiplication. - x_mul() uses pointers instead of indices for iteration, giving ~10% speedup (under VC6). - the right-to-left square-and-multiply exponentiation algorithm is replaced with a left-to-right square-and-multiply, which takes advantage of small bases. - when the exponent is above a certain size, "k-ary" exponentiation is used to reduce the number of multiplications via precalculation. - when the modulus is odd, Montgomery reduction is used. - the Karatsuba cutoff seems too low. For multiplicands in the range of 500-5000 bits, Karatsuba slows multiplication by around ~25% (VC6sp4, Intel P4M 1.7 Ghz). For larger numbers, the benefits of Karatsuba are less than they could be. Currently, the cutoff is 35 digits (525 bits). I've tried 70, 140, 280, and 560. 70, 140, and 280 are roughly the same: they don't slow down small values, and they have good speedup on large ones. 560 is not quite as good for large values, but at least it doesn't hurt small ones. I know this is platform-dependent, but I think we should err on the side of making the cutoff too high and losing some optimization, instead of putting it too low and slowing things down. I suggest 70. A couple misc. things: - Negative exponents with a modulus no longer give an error, when the base is coprime with the modulus. Instead, it calculates the multiplicative inverse of the base with respect to the modulus, using the extended euclidean algorithm, and exponentiates that. Libraries like GMP and LibTomMath work the same way. Being able to take inverses mod a number is useful for cryptography (e.g. RSA, DSA, and Elgamal). - The diff includes patch 923643, which supports converting longs to byte-strings. Ignore the last few diff entries, if you don't want this. - I haven't looked into harmonizing with int_pow(). Something may have to be done. ---------------------------------------------------------------------- >Comment By: Trevor Perrin (trevp) Date: 2005-09-28 23:29 Message: Logged In: YES user_id=973611 I updated this patch to CVS head, but didn't change it otherwise. It's still a bit hairy. However, it's also still a big speedup (see benchmarks from 2004-10-03). If I can do anything to help this make it in 2.5, let me know. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-10-05 00:25 Message: Logged In: YES user_id=973611 Montgomery has a fixed cost, so it slows down small exponents. For example modular squaring is slowed ~5x. I added a MONTGOMERY_CUTOFF to take care of this. Submitting long_mont4.diff. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-10-04 00:48 Message: Logged In: YES user_id=973611 oops. Good thing for random testing, carry propagation was buggy. Submitting long_mont3.diff. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-10-03 22:43 Message: Logged In: YES user_id=973611 I did more code review, testing, and timing. The only change in this new patch (long_mont2.diff) is a couple "int"s were changed to "digits"s, and it's against CVS head. As far as testing, I used the random module and GMPY to check it on ~3 million random input values. That's about an hour of testing. I'll leave the tests running for a few days and see if anything crops up. As far as timing, I updated the benchmarks with a new machine (OpenBSD): http://trevp.net/long_pow/ On 3 different machines, Montgomery gives a speedup of 2x, 3x, and 4x. That dwarfs what we've done so far, so I'm crossing my fingers for 2.4. Let me know if I can explain or improve the code, or anything.. (The below crypto library comes with a "book" which has an explanation of Montgomery I found helpful): http://math.libtomcrypt.org/download.html ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-09-13 01:20 Message: Logged In: YES user_id=973611 Here's the 3rd part of the patch (long_mont.diff; Montgomery Reduction), diff'd against 2.4a3 and cleaned up a bit. Note that this doesn't include negative exponent handling. If this patch is accepted, I'll make a new tracker item for that, since it's not an optimization, just an "opportunistic feature" (it builds on one of the helper functions needed for Montgomery). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-29 19:47 Message: Logged In: YES user_id=31435 Same deal with the 2nd part of the patch (major format changes, minor code changes). Incidentally fixed an old leak bug in long_pow() during the review. Added code to raise a compile-time error (C) if SHIFT isn't divisible by 5, and removed long_pow's new hardcoded assumption that SHIFT is exactly 15. Include/longintrepr.h 2.16 Misc/NEWS 1.1120 Objects/longobject.c 1.163 This is cool stuff (& thank you!), but I'm sorry to say I can't foresee making time for the 3rd part of the patch for weeks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-29 15:21 Message: Logged In: YES user_id=31435 Checked in the first part of the patch, with major format changes (Python's C coding standard is hard 8-column tabs), and minor code changes: Include/longintrepr.h 2.15 Misc/ACKS 1.280 Misc/NEWS 1.1119 Objects/longobject.c 1.162 I don't know whether it's possible for me to get to part 2 of the patch before 2.4a3, but I would like to. It seems plainly impossible that I'll be able to get to part 3 before 2.4a3. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-22 01:39 Message: Logged In: YES user_id=973611 Pragmatics isn't my strong suit... but I get your drift :-). I split it into 3 diffs: 1) x_mul optimizations: (pointers instead of indices, special-case squaring, changing Karatsuba cutoff) 2) rewriting long_pow() for left-to-right 5-ary 3) Montgomery reduction. This also includes l_invmod(), since it's necessary for Montgomery. I've left out the code which exposes l_invmod() to the user (and associated docs, tests, and intobject changes). We could slap that on afterwards or not... Anyways, these are applied sequentially: longobject.c + longobject1.diff = longobject1.c longobject1.c + longobject2.diff = longobject2.c longobject2.c + longobject2.diff = longobject3.c Should I open new tracker items for them? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-21 12:29 Message: Logged In: YES user_id=31435 Pragmatics are a real problem here, Trevor. I don't foresee being able to make a solid block of sufficient hours to give to reviewing this before Python 2.4 is history (which is why I've left this patch unassigned, BTW -- I just can't promise to make enough time). So if nobody else can volunteer to review it, that alone is likely to leave the patch sitting here unapplied. But there are several independent changes in this patch, and it *could* be broken into several smaller patches. I tossed that bait out before, but you didn't bite. You should . ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-19 04:00 Message: Logged In: YES user_id=973611 Tim, thanks for the feedback. I'm uploading a new patch against CVS latest that fixes those issues, and adds docs and tests. Also, I cleaned up the code quite a bit, and got it properly handling (I hope) all the varied combinations of ints/longs, positives/negatives/zeros etc.. Unfortunately, Montgomery is the bulk of the speedup: http://trevp.net/long_pow/ But I could split out the negative exponent handling into a separate patch, if that would be easier. Anyways, I'd like to add more tests for the exponentiation stuff. Aside from that, I think the patch is complete. And more robust than previously, though I still wouldn't trust it until another person or two gives it a serious looking-over.... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-16 20:06 Message: Logged In: YES user_id=31435 Notes after a brief eyeball scan: Note that the expression a & 1 == 1 groups as a & (1 == 1) in C -- comparisons have higher precedence in C than bit- fiddling operators. Stuff like that is usually best resolved by explicitly parenthesizing any "impure" expression fiddling with bits. In this case, in a boolean expression plain a & 1 has the hoped-for effect. and is clearer anyway. Would be better to use "**" than "^" in comments when exponentiation is intended, since "^" means xor in both Python and C. Doc changes are needed, because you're changing visible semantics in some cases. Tests are needed, especially for new semantics. l_invmod can return NULL for more than one reason, but one of its callers ignores this, assuming that all NULL returns are due to lack of coprimality. It's unreasonable to, e.g., replace a MemoryError with a complaint about coprimality; this needs reworking. l_invmod should probably set an exception in the "not coprime" case. As is, it's a weird function, sometimes setting an exception when it returns NULL, but not setting one when coprimality doesn't obtain. That makes life difficult for callers (which isn't apparent in the patch, because its callers are currently ignoring this issue). The Montgomery reduction gimmicks grossly complicate this patch -- they're long-winded and hard to follow. That may come with the territory, but it's the only part of the patch that made me want to vomit . I'd be happier if it weren't there, for aesthetic, clarity, and maintainability reasons. How much of a speedup does it actually buy? You're right that int pow must deliver the same results as long pow, so code is needed for that too. "short int" versus "unbounded int" is increasingly meant to be an invisible internal implementation detail in Python. I'm also in favor of giving this meaning to modular negative exponents, btw, so no problem with that. An easy way would be to change int pow to delegate to long pow when this is needed. Pragmatics: there's a better chance of making 2.4 if the patch were done in bite-size stages. For example, no doc changes are needed to switch to 5-ary left-to-right exponentation, and that has no effect on the int implementation either, etc. A patch that did just that much probably would have gone in a long time ago. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-13 01:04 Message: Logged In: YES user_id=973611 Uploading 2nd version of longobject.diff - the only change is that patch 923643 is removed from this diff. That was a diff for converting longs to byte-strings, which I unnecessarily left in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936813&group_id=5470 From noreply at sourceforge.net Thu Sep 29 08:44:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Sep 2005 23:44:08 -0700 Subject: [Patches] [ python-Patches-936813 ] fast modular exponentiation Message-ID: Patches item #936813, was opened at 2004-04-17 10:16 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936813&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Trevor Perrin (trevp) >Assigned to: Tim Peters (tim_one) Summary: fast modular exponentiation Initial Comment: For crypto-sized numbers, Python mod-exp is several times slower than GMP or OpenSSL (6x or more). Those libraries do crazy special-case stuff, + assembly, platform-specific tuning, and so on. However, there's some low-hanging fruit: this patch has a few basic optimizations giving a 2-3x speedup for numbers in the 1000-8000 bit range (that's what I've mostly tested; but the patch should improve, or at least not hurt, everything else): - x_mul() is special-cased for squaring, which is almost twice as fast as general multiplication. - x_mul() uses pointers instead of indices for iteration, giving ~10% speedup (under VC6). - the right-to-left square-and-multiply exponentiation algorithm is replaced with a left-to-right square-and-multiply, which takes advantage of small bases. - when the exponent is above a certain size, "k-ary" exponentiation is used to reduce the number of multiplications via precalculation. - when the modulus is odd, Montgomery reduction is used. - the Karatsuba cutoff seems too low. For multiplicands in the range of 500-5000 bits, Karatsuba slows multiplication by around ~25% (VC6sp4, Intel P4M 1.7 Ghz). For larger numbers, the benefits of Karatsuba are less than they could be. Currently, the cutoff is 35 digits (525 bits). I've tried 70, 140, 280, and 560. 70, 140, and 280 are roughly the same: they don't slow down small values, and they have good speedup on large ones. 560 is not quite as good for large values, but at least it doesn't hurt small ones. I know this is platform-dependent, but I think we should err on the side of making the cutoff too high and losing some optimization, instead of putting it too low and slowing things down. I suggest 70. A couple misc. things: - Negative exponents with a modulus no longer give an error, when the base is coprime with the modulus. Instead, it calculates the multiplicative inverse of the base with respect to the modulus, using the extended euclidean algorithm, and exponentiates that. Libraries like GMP and LibTomMath work the same way. Being able to take inverses mod a number is useful for cryptography (e.g. RSA, DSA, and Elgamal). - The diff includes patch 923643, which supports converting longs to byte-strings. Ignore the last few diff entries, if you don't want this. - I haven't looked into harmonizing with int_pow(). Something may have to be done. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2005-09-29 08:29 Message: Logged In: YES user_id=973611 I updated this patch to CVS head, but didn't change it otherwise. It's still a bit hairy. However, it's also still a big speedup (see benchmarks from 2004-10-03). If I can do anything to help this make it in 2.5, let me know. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-10-05 09:25 Message: Logged In: YES user_id=973611 Montgomery has a fixed cost, so it slows down small exponents. For example modular squaring is slowed ~5x. I added a MONTGOMERY_CUTOFF to take care of this. Submitting long_mont4.diff. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-10-04 09:48 Message: Logged In: YES user_id=973611 oops. Good thing for random testing, carry propagation was buggy. Submitting long_mont3.diff. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-10-04 07:43 Message: Logged In: YES user_id=973611 I did more code review, testing, and timing. The only change in this new patch (long_mont2.diff) is a couple "int"s were changed to "digits"s, and it's against CVS head. As far as testing, I used the random module and GMPY to check it on ~3 million random input values. That's about an hour of testing. I'll leave the tests running for a few days and see if anything crops up. As far as timing, I updated the benchmarks with a new machine (OpenBSD): http://trevp.net/long_pow/ On 3 different machines, Montgomery gives a speedup of 2x, 3x, and 4x. That dwarfs what we've done so far, so I'm crossing my fingers for 2.4. Let me know if I can explain or improve the code, or anything.. (The below crypto library comes with a "book" which has an explanation of Montgomery I found helpful): http://math.libtomcrypt.org/download.html ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-09-13 10:20 Message: Logged In: YES user_id=973611 Here's the 3rd part of the patch (long_mont.diff; Montgomery Reduction), diff'd against 2.4a3 and cleaned up a bit. Note that this doesn't include negative exponent handling. If this patch is accepted, I'll make a new tracker item for that, since it's not an optimization, just an "opportunistic feature" (it builds on one of the helper functions needed for Montgomery). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-30 04:47 Message: Logged In: YES user_id=31435 Same deal with the 2nd part of the patch (major format changes, minor code changes). Incidentally fixed an old leak bug in long_pow() during the review. Added code to raise a compile-time error (C) if SHIFT isn't divisible by 5, and removed long_pow's new hardcoded assumption that SHIFT is exactly 15. Include/longintrepr.h 2.16 Misc/NEWS 1.1120 Objects/longobject.c 1.163 This is cool stuff (& thank you!), but I'm sorry to say I can't foresee making time for the 3rd part of the patch for weeks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-30 00:21 Message: Logged In: YES user_id=31435 Checked in the first part of the patch, with major format changes (Python's C coding standard is hard 8-column tabs), and minor code changes: Include/longintrepr.h 2.15 Misc/ACKS 1.280 Misc/NEWS 1.1119 Objects/longobject.c 1.162 I don't know whether it's possible for me to get to part 2 of the patch before 2.4a3, but I would like to. It seems plainly impossible that I'll be able to get to part 3 before 2.4a3. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-22 10:39 Message: Logged In: YES user_id=973611 Pragmatics isn't my strong suit... but I get your drift :-). I split it into 3 diffs: 1) x_mul optimizations: (pointers instead of indices, special-case squaring, changing Karatsuba cutoff) 2) rewriting long_pow() for left-to-right 5-ary 3) Montgomery reduction. This also includes l_invmod(), since it's necessary for Montgomery. I've left out the code which exposes l_invmod() to the user (and associated docs, tests, and intobject changes). We could slap that on afterwards or not... Anyways, these are applied sequentially: longobject.c + longobject1.diff = longobject1.c longobject1.c + longobject2.diff = longobject2.c longobject2.c + longobject2.diff = longobject3.c Should I open new tracker items for them? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-21 21:29 Message: Logged In: YES user_id=31435 Pragmatics are a real problem here, Trevor. I don't foresee being able to make a solid block of sufficient hours to give to reviewing this before Python 2.4 is history (which is why I've left this patch unassigned, BTW -- I just can't promise to make enough time). So if nobody else can volunteer to review it, that alone is likely to leave the patch sitting here unapplied. But there are several independent changes in this patch, and it *could* be broken into several smaller patches. I tossed that bait out before, but you didn't bite. You should . ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-19 13:00 Message: Logged In: YES user_id=973611 Tim, thanks for the feedback. I'm uploading a new patch against CVS latest that fixes those issues, and adds docs and tests. Also, I cleaned up the code quite a bit, and got it properly handling (I hope) all the varied combinations of ints/longs, positives/negatives/zeros etc.. Unfortunately, Montgomery is the bulk of the speedup: http://trevp.net/long_pow/ But I could split out the negative exponent handling into a separate patch, if that would be easier. Anyways, I'd like to add more tests for the exponentiation stuff. Aside from that, I think the patch is complete. And more robust than previously, though I still wouldn't trust it until another person or two gives it a serious looking-over.... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-17 05:06 Message: Logged In: YES user_id=31435 Notes after a brief eyeball scan: Note that the expression a & 1 == 1 groups as a & (1 == 1) in C -- comparisons have higher precedence in C than bit- fiddling operators. Stuff like that is usually best resolved by explicitly parenthesizing any "impure" expression fiddling with bits. In this case, in a boolean expression plain a & 1 has the hoped-for effect. and is clearer anyway. Would be better to use "**" than "^" in comments when exponentiation is intended, since "^" means xor in both Python and C. Doc changes are needed, because you're changing visible semantics in some cases. Tests are needed, especially for new semantics. l_invmod can return NULL for more than one reason, but one of its callers ignores this, assuming that all NULL returns are due to lack of coprimality. It's unreasonable to, e.g., replace a MemoryError with a complaint about coprimality; this needs reworking. l_invmod should probably set an exception in the "not coprime" case. As is, it's a weird function, sometimes setting an exception when it returns NULL, but not setting one when coprimality doesn't obtain. That makes life difficult for callers (which isn't apparent in the patch, because its callers are currently ignoring this issue). The Montgomery reduction gimmicks grossly complicate this patch -- they're long-winded and hard to follow. That may come with the territory, but it's the only part of the patch that made me want to vomit . I'd be happier if it weren't there, for aesthetic, clarity, and maintainability reasons. How much of a speedup does it actually buy? You're right that int pow must deliver the same results as long pow, so code is needed for that too. "short int" versus "unbounded int" is increasingly meant to be an invisible internal implementation detail in Python. I'm also in favor of giving this meaning to modular negative exponents, btw, so no problem with that. An easy way would be to change int pow to delegate to long pow when this is needed. Pragmatics: there's a better chance of making 2.4 if the patch were done in bite-size stages. For example, no doc changes are needed to switch to 5-ary left-to-right exponentation, and that has no effect on the int implementation either, etc. A patch that did just that much probably would have gone in a long time ago. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-13 10:04 Message: Logged In: YES user_id=973611 Uploading 2nd version of longobject.diff - the only change is that patch 923643 is removed from this diff. That was a diff for converting longs to byte-strings, which I unnecessarily left in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936813&group_id=5470 From noreply at sourceforge.net Thu Sep 29 16:47:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 07:47:47 -0700 Subject: [Patches] [ python-Patches-1298835 ] vendor-packages directory. Message-ID: Patches item #1298835, was opened at 2005-09-22 08:12 Message generated for change (Comment added) made by richburridge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298835&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Rich Burridge (richburridge) Assigned to: Nobody/Anonymous (nobody) Summary: vendor-packages directory. Initial Comment: Python needs a .../python2.x.y/vendor-packages directory for vendor supplied Python files. See: http://mail.python.org/pipermail/python-list/2005-September/300029.html for the full reasoning behind this request. I also approached Guido w.r.t. this. Here's his reply. Subject: Re: Python vendor-packages directory in a future Python release? Date: Tue, 20 Sep 2005 19:48:40 -0700 From: Guido van Rossum Reply-To: Guido van Rossum To: Rich Burridge References: <4330C108.4030100 at sun.com> I think that's a reasonable request. (In the mean time, I think that using site-packages is fine as an interim solution.) I suggest that you use the SourceForge patch manager for the Python project to upload your patch, and then post to python-dev. You may be asked to review 5 other patches in order to have someone look at your favorite patch. --Guido ---------------------------------------------------------------------- >Comment By: Rich Burridge (richburridge) Date: 2005-09-29 07:47 Message: Logged In: YES user_id=511506 A good alternative solution to this problem was given on the python-devel mailing list. See: http://mail.python.org/pipermail/python-dev/2005-September/056697.html http://mail.python.org/pipermail/python-dev/2005-September/056699.html The architectural commitee have approved this solution, so I'm closing this bug as "Invalid". If there'd been a "Withdrawn" resolution, I'd have closed it that way instead. Perhaps that's what Deleted is supposed to do. Feel free to tweak if I've selected the wrong closure. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-23 16:49 Message: Logged In: YES user_id=593130 The reason for this patch given in the referred-to post is: "We have been told that this directory is inappropriate for vendor supplied packages, just as "site_perl" is inappropriate for Perl. With Perl, vendor supplied packages go under "vendor_perl". " where 'this directory' is site-packages, which works fine. The python-dev thread subequent to this posting starts with http://mail.python.org/pipermail/python-dev/2005- September/056682.html A subsequent post http://mail.python.org/pipermail/python-dev/2005- September/056696.html clarifies that 'vendor supplied packages' here means packages installed by the system/OS vendor. Disconnected (in the pipermail archives) pieces of the thread start here http://mail.python.org/pipermail/python-dev/2005- September/056697.html and here http://mail.python.org/pipermail/python-dev/2005- September/056702.html This last suggests that this proposal is on hold while a .pth solution is explored. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298835&group_id=5470 From noreply at sourceforge.net Thu Sep 29 22:49:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 13:49:38 -0700 Subject: [Patches] [ python-Patches-1300515 ] xdrlib.py: pack_fstring() did not use null bytes for padding Message-ID: Patches item #1300515, was opened at 2005-09-23 11:37 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1300515&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Don Quijote (dq_searchlores) Assigned to: Nobody/Anonymous (nobody) Summary: xdrlib.py: pack_fstring() did not use null bytes for padding Initial Comment: According to the documentation, null shall be used as padding byte. But, as the test below shows, instead of null, additional trailing characters of the original string are used. This is also wrong according to the related RFC 1014 (and RFC 1832). This is tested on Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 >>> import xdrlib >>> p = xdrlib.Packer() >>> p.pack_fstring(2,"abcdef") >>> p.get_buffer() 'abcd' I am expecting 'ab\0\0' This change does not have any impact on unpack_fstring(). The patch is done against the current CVS tree. The patch does not add nor change any functionality. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 22:49 Message: Logged In: YES user_id=1188172 Thanks for the patch, committed in xdrlib.py r1.18, r1.16.4.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1300515&group_id=5470 From noreply at sourceforge.net Fri Sep 30 00:46:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 15:46:16 -0700 Subject: [Patches] [ python-Patches-1309009 ] pyexpat.c: Two line fix for decoding crash Message-ID: Patches item #1309009, was opened at 2005-09-29 18:46 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=1309009&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Evan Jones (vulturex) Assigned to: Nobody/Anonymous (nobody) Summary: pyexpat.c: Two line fix for decoding crash Initial Comment: The attached Python script "test.py" will crash Python version 2.3, 2.4 and current CVS. The problem is that expat could pass back a string that is not in UTF8 format when the character encoding is not specified. In the example "test.py" the XML document is in latin_1 format, but Python thinks it is in UTF-8 format. The workaround is to decode the string into Unicode first, then encode it as UTF8. However, if this data was coming from a file or a user, it could crash the interpreter. With the attached patch, instead of causing a segmentation fault it raises an exception, which is exactly what Python 2.2 does in this case: Traceback (most recent call last): File "/home/ejones/test.py", line 5, in ? dom = xml.dom.minidom.parseString( x.encode( 'latin_1' ) ) File "/home/ejones/python/dist/src/Lib/xml/dom/minidom.py", line 1925, in parseString return expatbuilder.parseString(string) File "/home/ejones/python/dist/src/Lib/xml/dom/expatbuilder.py", line 940, in parseString return builder.parseString(string) File "/home/ejones/python/dist/src/Lib/xml/dom/expatbuilder.py", line 223, in parseString parser.Parse(string, True) UnicodeDecodeError: 'utf8' codec can't decode bytes in position 4-6: invalid data ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1309009&group_id=5470 From noreply at sourceforge.net Fri Sep 30 02:25:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 17:25:34 -0700 Subject: [Patches] [ python-Patches-1309009 ] pyexpat.c: Two line fix for decoding crash Message-ID: Patches item #1309009, was opened at 2005-09-29 18:46 Message generated for change (Comment added) made by vulturex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1309009&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Evan Jones (vulturex) Assigned to: Nobody/Anonymous (nobody) Summary: pyexpat.c: Two line fix for decoding crash Initial Comment: The attached Python script "test.py" will crash Python version 2.3, 2.4 and current CVS. The problem is that expat could pass back a string that is not in UTF8 format when the character encoding is not specified. In the example "test.py" the XML document is in latin_1 format, but Python thinks it is in UTF-8 format. The workaround is to decode the string into Unicode first, then encode it as UTF8. However, if this data was coming from a file or a user, it could crash the interpreter. With the attached patch, instead of causing a segmentation fault it raises an exception, which is exactly what Python 2.2 does in this case: Traceback (most recent call last): File "/home/ejones/test.py", line 5, in ? dom = xml.dom.minidom.parseString( x.encode( 'latin_1' ) ) File "/home/ejones/python/dist/src/Lib/xml/dom/minidom.py", line 1925, in parseString return expatbuilder.parseString(string) File "/home/ejones/python/dist/src/Lib/xml/dom/expatbuilder.py", line 940, in parseString return builder.parseString(string) File "/home/ejones/python/dist/src/Lib/xml/dom/expatbuilder.py", line 223, in parseString parser.Parse(string, True) UnicodeDecodeError: 'utf8' codec can't decode bytes in position 4-6: invalid data ---------------------------------------------------------------------- >Comment By: Evan Jones (vulturex) Date: 2005-09-29 20:25 Message: Logged In: YES user_id=539295 I've also attached a patch which adds this as a test case to test_minidom.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1309009&group_id=5470 From noreply at sourceforge.net Fri Sep 30 06:58:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 21:58:57 -0700 Subject: [Patches] [ python-Patches-1309009 ] pyexpat.c: Two line fix for decoding crash Message-ID: Patches item #1309009, was opened at 2005-09-29 15:46 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1309009&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Evan Jones (vulturex) Assigned to: Nobody/Anonymous (nobody) Summary: pyexpat.c: Two line fix for decoding crash Initial Comment: The attached Python script "test.py" will crash Python version 2.3, 2.4 and current CVS. The problem is that expat could pass back a string that is not in UTF8 format when the character encoding is not specified. In the example "test.py" the XML document is in latin_1 format, but Python thinks it is in UTF-8 format. The workaround is to decode the string into Unicode first, then encode it as UTF8. However, if this data was coming from a file or a user, it could crash the interpreter. With the attached patch, instead of causing a segmentation fault it raises an exception, which is exactly what Python 2.2 does in this case: Traceback (most recent call last): File "/home/ejones/test.py", line 5, in ? dom = xml.dom.minidom.parseString( x.encode( 'latin_1' ) ) File "/home/ejones/python/dist/src/Lib/xml/dom/minidom.py", line 1925, in parseString return expatbuilder.parseString(string) File "/home/ejones/python/dist/src/Lib/xml/dom/expatbuilder.py", line 940, in parseString return builder.parseString(string) File "/home/ejones/python/dist/src/Lib/xml/dom/expatbuilder.py", line 223, in parseString parser.Parse(string, True) UnicodeDecodeError: 'utf8' codec can't decode bytes in position 4-6: invalid data ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 21:58 Message: Logged In: YES user_id=33168 Thanks! Note, I had to modify the patch a little bit because the result of string_intern() was passed to Py_BuildValue(). Since string_intern() returned NULL, Py_BuildValue() returned NULL and container wound up being Py_DECREF()ed twice which showed up in a debug build. Checking in Lib/test/test_minidom.py 1.42, 1.39.4.3 Checking in Misc/ACKS 1.297, 1.289.2.4 Checking in Misc/NEWS 1.1381, 1.1193.2.115 Checking in Modules/pyexpat.c 2.91, 2.89.2.2 ---------------------------------------------------------------------- Comment By: Evan Jones (vulturex) Date: 2005-09-29 17:25 Message: Logged In: YES user_id=539295 I've also attached a patch which adds this as a test case to test_minidom.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1309009&group_id=5470 From noreply at sourceforge.net Fri Sep 30 12:18:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Sep 2005 03:18:50 -0700 Subject: [Patches] [ python-Patches-1309352 ] Make fcntl work properly on AMD64 Message-ID: Patches item #1309352, was opened at 2005-09-30 20: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=1309352&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Brad Hards (bradh) Assigned to: Nobody/Anonymous (nobody) Summary: Make fcntl work properly on AMD64 Initial Comment: The fcntl call doesn't work correctly on AMD-64, because of an unsigned int conversion problem. I found the problem using the dnotify.py code from buildbot.sf.net (attached). It (roughly) does: self.flags = reduce(lambda x, y: x | y, flags) | fcntl.DN_MULTISHOT self.fd = os.open(dirname, os.O_RDONLY) fcntl.fcntl(self.fd, fcntl.F_NOTIFY, self.flags) fcntl.DN_MULTISHOT is 0x80000000, which causes OverflowError: signed integer is greater than maximum There is a similar fix already committed for ioctl - see http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/fcntlmodule.c?r1=2.43&r2=2.44 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1309352&group_id=5470 From noreply at sourceforge.net Fri Sep 30 17:32:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Sep 2005 08:32:40 -0700 Subject: [Patches] [ python-Patches-1309579 ] A wait4() implementation Message-ID: Patches item #1309579, was opened at 2005-09-30 10:32 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=1309579&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: chads (cjschr) Assigned to: Nobody/Anonymous (nobody) Summary: A wait4() implementation Initial Comment: Implementation of a BSD-style wait4() function, which is similar to waitpid, but it also returns resource usage information about the child process. wait4(pid, options) -> (pid, status, rusage) Chad ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1309579&group_id=5470