From noreply at sourceforge.net Fri Jul 1 00:47:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Jun 2005 15:47:05 -0700 Subject: [Patches] [ python-Patches-1230615 ] Patch for (Doc) #1168746 Message-ID: Patches item #1230615, was opened at 2005-06-30 16:38 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1230615&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: Reinhold Birkenfeld (birkenfeld) Summary: Patch for (Doc) #1168746 Initial Comment: I will try to add another file later on. On 'undocuments' these attributes as per Arigo's suggestion ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-30 17:47 Message: Logged In: YES user_id=80475 Reinhold, do you want to verify the patch's accuracy and then apply it? Also, for documentation patches, be sure to verify the TeX markup by running python -m texcheck -m ref3.tex. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-06-30 16:49 Message: Logged In: YES user_id=174455 The second patch 'corrects' the docs using Arigo's description. This should make it easy to close this one by someone who can make a good estimate of the usefullness of these values to anyone. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1230615&group_id=5470 From noreply at sourceforge.net Fri Jul 1 01:40:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Jun 2005 16:40:58 -0700 Subject: [Patches] [ python-Patches-1225769 ] Proposal to implement comment rows in csv module Message-ID: Patches item #1225769, was opened at 2005-06-22 19:48 Message generated for change (Comment added) made by iain_haslam You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1225769&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: Iain Haslam (iain_haslam) Assigned to: Skip Montanaro (montanaro) Summary: Proposal to implement comment rows in csv module Initial Comment: Sometimes csv files contain comment rows, for temporarily commenting out data or occasionally for documentation. The current csv module has no built-in ability to skip rows; in order to skip all lines beginning with '#', the programmer writes something like: csv_reader = csv.reader(fp) for row in csv_reader: if row[0][0] != '#': #assuming no blank lines print row I propose adding a "commentchar" parameter to the csv parser, so that the above code could be written (more elegantly, in my opinion): csv_reader = csv.reader(fp, commentchar='#') for row in csv_reader: print row This requires only relatively minor changes to the module, and by defaulting to using no comment character, existing code will behave as before. If you are interested, the patch (diffs against current cvs) required for the second example to run are attached. Note that that implementation adds SKIPPED_RECORD as a pseudonym for START_RECORD, because setting status to START_RECORD after skipping a record would cause a blank record to be returned. Altering that behaviour would cause more changes and the patch would be harder to review. I've also held back on updating tests and documentation to reflect this change, pending any support for it. It shoud be irrelevant, but this has been developed on Debian testing against the cvs head of Python. ---------------------------------------------------------------------- >Comment By: Iain Haslam (iain_haslam) Date: 2005-06-30 23:40 Message: Logged In: YES user_id=1301296 Here are the documentation and test diffs. I'm glad to hear of the positive feedback. I couldn't find the csv mailing list (I assume it's not public), so didn't see the discussion of round-tripping, but I agree with the implied conclusion that flagging rows as comments would complicate the interface too much. On a related point, I noticed that the csv documentation is filed under "Internet data handling". This seems a little odd - I'd suggest moving it to "Miscellaneous Services" alongside fileinput and ConfigParser. Thanks, Iain. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-27 17:25 Message: Logged In: YES user_id=44345 Iain - There was some positive response to your patch from the csv mailing list (most notably from one of the authors of the C extension module). Can you provide diffs for the module documentation and necessary test cases to go along with your patch? Also, addressing the issue that CSV files with comments (probably?) won't round-trip would be a good thing to note in the docs. Skip ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-26 18:02 Message: Logged In: YES user_id=44345 Something else just occurred to me. What about writing csv files with comments? Also, a tweak to the docs would be in order if this is accepted. ---------------------------------------------------------------------- Comment By: Iain Haslam (iain_haslam) Date: 2005-06-26 17:26 Message: Logged In: YES user_id=1301296 > I'm not inclined to clutter the C code with further > complications. Sorry - I haven't been keeping up with the existing complications! Don't forget that one man's clutter is another man's functionality. It doesn't actually require much of a change to the code, although I was slightly suprised to discover that this module was in C in the first place... Basically, I noticed that the csv module has a bias towards Excel-generated csv files, but most of the time I've come across csv files, they were hand-edited, and I've often seen comment fields as described in the submission. My submission was intended in the "batteries included" spirit (I do understand that you stop short of the kitchen sink), and also seemed in-keeping with the 'skipinitialspace' option within the existing csv module. > Why can't you implement this on an as-needed basis > with a file object wrapper [other options] True, I could do any of those things, but it would be simpler / clearer not to have to. Of course, if you took your argument further, you could cut chunks out of several modules; the argument comes down to whether the benefits outweigh the additional complexity. I was suprised to discover the option wasn't already there, but maybe that's just me. In any case, if your vote goes from your apparent -0 to -1, that's your choice, and you're better placed to make it than I am. Cheers, Iain. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-25 19:39 Message: Logged In: YES user_id=44345 I'm not inclined to clutter the C code with further complications. Why can't you implement this on an as-needed basis with a file object wrapper, a subclass of the csv.reader class, or just continue to use the example in your submission? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1225769&group_id=5470 From noreply at sourceforge.net Fri Jul 1 18:04:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Jul 2005 09:04:49 -0700 Subject: [Patches] [ python-Patches-1231053 ] audioop - alaw encoding/decoding added, code updated Message-ID: Patches item #1231053, was opened at 2005-07-01 18:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231053&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: Lars Immisch (larsimmisch) Assigned to: Nobody/Anonymous (nobody) Summary: audioop - alaw encoding/decoding added, code updated Initial Comment: This patch adds a-LAW encoding to audioop and replaces[1] the old u-LAW encoding/decoding code with the current code from sox. If audioop has an ulaw codec, it should also have an alaw codec. Besides, shtoom wants/needs it. Tests and documentation are updated with this patch too. The patch is a unified diff against CVS that can be applied in one piece frrom the root of the python tree. Beyond the cursory tests in the unittests, I have done successful tests with real-life data. Possible issues: the code from sox uses int16_t. [1] Rationale for the replacement of existing code: the alaw code would have been different in style from the ulaw code and attribution of the code would have been less clear. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231053&group_id=5470 From noreply at sourceforge.net Sat Jul 2 03:55:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Jul 2005 18:55:44 -0700 Subject: [Patches] [ python-Patches-1231336 ] Add unicode for sys.argv, os.environ, os.system Message-ID: Patches item #1231336, was opened at 2005-07-02 11:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231336&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: Neil Hodgson (nyamatongwe) Assigned to: Nobody/Anonymous (nobody) Summary: Add unicode for sys.argv, os.environ, os.system Initial Comment: Most installations of Windows (2000, XP) are unicode native with narrow character APIs only providing a distorted view of the system. Python does not currently provide access to some basic features through wide character calls and so may see distorted values. This patch adds unicode compatibility for sys.argv, os.environ, and os.system. os.system accepts a unicode argument in the same way as described in PEP 277 for file APIs. For sys.argv and os.environ, new parallel unicode attributes sys.argvu and os.environu are added as it would cause too many problems to use unicode values for the existing attributes or to use unicode only for non-ASCII values. The features are only enabled on unicode native versions of Windows. The three features are demonstrated at http://www.scintilla.org/pyunicode.png The patch contains some documentation additions for sys.argvu and os.environu. There are no test cases as test cases involving running extra processes can be messy and fail for uninteresting reasons. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231336&group_id=5470 From noreply at sourceforge.net Sat Jul 2 12:29:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Jul 2005 03:29:32 -0700 Subject: [Patches] [ python-Patches-1230615 ] Patch for (Doc) #1168746 Message-ID: Patches item #1230615, was opened at 2005-06-30 23:38 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1230615&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: Accepted Priority: 5 Submitted By: Peter van Kampen (pterk) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Patch for (Doc) #1168746 Initial Comment: I will try to add another file later on. On 'undocuments' these attributes as per Arigo's suggestion ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-02 12:29 Message: Logged In: YES user_id=1188172 Okay, checked in correction patch as Doc/ref/ref3.tex r1.125, r1.121.2.4. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-01 00:47 Message: Logged In: YES user_id=80475 Reinhold, do you want to verify the patch's accuracy and then apply it? Also, for documentation patches, be sure to verify the TeX markup by running python -m texcheck -m ref3.tex. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-06-30 23:49 Message: Logged In: YES user_id=174455 The second patch 'corrects' the docs using Arigo's description. This should make it easy to close this one by someone who can make a good estimate of the usefullness of these values to anyone. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1230615&group_id=5470 From noreply at sourceforge.net Sat Jul 2 12:45:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Jul 2005 03:45:31 -0700 Subject: [Patches] [ python-Patches-1229935 ] Patch for (Doc) bug #1228904 Message-ID: Patches item #1229935, was opened at 2005-06-29 21:45 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1229935&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: Fixed Priority: 5 Submitted By: Peter van Kampen (pterk) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Patch for (Doc) bug #1228904 Initial Comment: Provide working (and shorter) example. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-02 12:45 Message: Logged In: YES user_id=1188172 Fixed in Doc/lib/libweakref.py r1.28, r1.27.4.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1229935&group_id=5470 From noreply at sourceforge.net Sat Jul 2 13:08:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Jul 2005 04:08:49 -0700 Subject: [Patches] [ python-Patches-977553 ] Speed up EnumKey call Message-ID: Patches item #977553, was opened at 2004-06-22 17:22 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=977553&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: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Garth Bushell (garth42) Assigned to: Nobody/Anonymous (nobody) Summary: Speed up EnumKey call Initial Comment: This patch removes the RegQueryInfoKey call and replaces it with a call to EnumKeyEx. This greatly speeds up this call. The script below times python 2.3 5531 89.7130000591 python 2.4 +patch 5531 0.0469999313354 start = time.time() i = 0 try: while 1: _winreg.EnumKey(_winreg.HKEY_CLASSES_ROOT, i) i += 1 except WindowsError: pass print i, time.time() - start ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-02 13:08 Message: Logged In: YES user_id=1188172 Attached a revised patch following coding style and adding additional error handling. winreg-enumkey.diff ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 09:08 Message: Logged In: YES user_id=21627 garth42, can you please indicate whether you are willing to work on the patch, and if so in what time frame? ---------------------------------------------------------------------- Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-02-27 17:59 Message: Logged In: YES user_id=1115903 I think it's a good idea to get 16-bit Windows functions out of Python per Microsoft's recommendation, especially when doing so can also help performance. It looks like this patch still needs some cleanup and a test or two. If nobody else wants to do it I can probably finish it up. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-26 14:31 Message: Logged In: YES user_id=21627 Also, please follow the Python style guide for C code, PEP 7. In particular: - use tabs for indentation, with a tab being worth 8 spaces - omit spaces after opening and before closing parens - put the opening brace of a code block on the same line as the keyword ---------------------------------------------------------------------- Comment By: Garth Bushell (garth42) Date: 2004-07-14 18:12 Message: Logged In: YES user_id=45280 mmangino: Yes you're correct it should be 256 in both cases. Doh! I'll attach a new patch in a while. but It's easy to mmodify the patch and up the linit to 256 theller: The advantage of the latter is it returns the Length of the string returned so we can pass it straight back to the string creation funtion in python without a strlen. also the SDK says this.... Note This function is provided only for compatibility with 16-bit versions of Windows. Applications should use the RegEnumKeyEx function. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-14 17:54 Message: Logged In: YES user_id=11105 I'm curious: Why did you replace RegEnumKey with RegEnumKeyEx? Are there any advantages of the latter? ---------------------------------------------------------------------- Comment By: Mike Mangino (mmangino) Date: 2004-07-14 16:12 Message: Logged In: YES user_id=74879 This looks good to me, but I think the buffer size is off by one. I read the SDK to say tha they key can be 255 characters. That means you need to allocate 256 characters to allow for the null terminator. Could you create a test case for a max length registry key? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=977553&group_id=5470 From noreply at sourceforge.net Sat Jul 2 18:55:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Jul 2005 09:55:44 -0700 Subject: [Patches] [ python-Patches-1231538 ] Typo fix in compiler/transformer.py (WalkerEror) Message-ID: Patches item #1231538, was opened at 2005-07-02 18:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231538&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: Adrien Di Mascio (adimasci) Assigned to: Nobody/Anonymous (nobody) Summary: Typo fix in compiler/transformer.py (WalkerEror) Initial Comment: Error description : Module : transformer.py Package : compiler (python implementation, not the builtin C one) There seems to be some typos in compiler/transformer.py. A WalkerError exception class is defined but a WalkerEror (with one missing 'r') instance is raised some times. I couldn't find a bug or patch in the tracker. The patch was generated with the following command line : diff -c transformer.py transformer.py.fixed > transformer.py.patch The patch is based on the current CVS version of transformer.py (i.e. version 1.50) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231538&group_id=5470 From noreply at sourceforge.net Sat Jul 2 20:38:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Jul 2005 11:38:33 -0700 Subject: [Patches] [ python-Patches-1231538 ] Typo fix in compiler/transformer.py (WalkerEror) Message-ID: Patches item #1231538, was opened at 2005-07-02 18:55 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231538&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: Adrien Di Mascio (adimasci) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Typo fix in compiler/transformer.py (WalkerEror) Initial Comment: Error description : Module : transformer.py Package : compiler (python implementation, not the builtin C one) There seems to be some typos in compiler/transformer.py. A WalkerError exception class is defined but a WalkerEror (with one missing 'r') instance is raised some times. I couldn't find a bug or patch in the tracker. The patch was generated with the following command line : diff -c transformer.py transformer.py.fixed > transformer.py.patch The patch is based on the current CVS version of transformer.py (i.e. version 1.50) ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-02 20:38 Message: Logged In: YES user_id=1188172 Thanks for the report, committed as Lib/compiler/transformer.py r1.51, r1.49.2.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231538&group_id=5470 From noreply at sourceforge.net Sun Jul 3 21:57:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jul 2005 12:57:17 -0700 Subject: [Patches] [ python-Patches-1231890 ] Patch for (Doc) #1162912 Message-ID: Patches item #1231890, was opened at 2005-07-03 21: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=1231890&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: Peter van Kampen (pterk) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for (Doc) #1162912 Initial Comment: Adds a note to footnote 8 (list.sort) http://docs.python.org/lib/typesseq-mutable.html that reads: If both key and cmp are supplied the key function is applied before the cmp function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231890&group_id=5470 From noreply at sourceforge.net Sun Jul 3 22:22:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jul 2005 13:22:40 -0700 Subject: [Patches] [ python-Patches-1231890 ] Patch for (Doc) #1162912 Message-ID: Patches item #1231890, was opened at 2005-07-03 21:57 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231890&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: Peter van Kampen (pterk) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Patch for (Doc) #1162912 Initial Comment: Adds a note to footnote 8 (list.sort) http://docs.python.org/lib/typesseq-mutable.html that reads: If both key and cmp are supplied the key function is applied before the cmp function. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-03 22:22 Message: Logged In: YES user_id=1188172 Thanks for the report and the patch. Committed as Doc/lib/libstdtypes.tex r1.183, r1.170.2.12. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231890&group_id=5470 From noreply at sourceforge.net Mon Jul 4 07:57:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jul 2005 22:57:28 -0700 Subject: [Patches] [ python-Patches-1232023 ] MS Windows - module search path fix Message-ID: Patches item #1232023, was opened at 2005-07-04 13: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=1232023&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: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: K. Thananchayan (thanan) Assigned to: Nobody/Anonymous (nobody) Summary: MS Windows - module search path fix Initial Comment: Module search path initialization code for Windows (PC) contains empty component(s) if Python home is determined and registry key "Software/Python/PythonCore//PythonPath" of HKLM or HKCU exists but does not any subkeys as usually the case. This(ese) empyt componentes transformed into current directory later causing to load modules in the current directory in preference to modules in the installation. This patch removes this(ese) empty component(s) from initial module search path. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1232023&group_id=5470 From noreply at sourceforge.net Mon Jul 4 20:03:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jul 2005 11:03:32 -0700 Subject: [Patches] [ python-Patches-1232343 ] PyOS_Readline Message-ID: Patches item #1232343, was opened at 2005-07-04 15:03 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=1232343&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: Lisandro Dalcin (dalcinl) Assigned to: Nobody/Anonymous (nobody) Summary: PyOS_Readline Initial Comment: Greg Lielens submitted some time ago a patch [id 955928] about 'PyOS_Readline()' behavior with non-interactive tty's. Basically, there is no way to properly override 'PyOS_ReadlineFunctionPointer' as 'PyOS_Readline()' calls 'PyOS_StdioReadline()' when 'stdin' or 'stdout' are not tty's. A snippet of "Parser/myreadline.c": ... if (!isatty (fileno (sys_stdin)) || !isatty (fileno (sys_stdout))) rv = PyOS_StdioReadline (sys_stdin, sys_stdout, prompt); else rv = (*PyOS_ReadlineFunctionPointer)(sys_stdin, sys_stdout, prompt); ... Greg Lielens is completely right about the problem, but his patch is perhaps a bit crude, it also modifies "Python/bltinmodule.c" to solve the same issue with 'raw_input'. I think I have found a not so crude solution, and completely backward compatible. Basically, I moved 'isatty()' test from 'PyOS_Readline()' in file "Parser/myreadline.c" to 'call_readline()' in file "Modules/readline.c". In order to do that, I believe 'PyOS_StdioReadline' have to be added to file "Include/pythonrun.h". All those changes will not affect in any way the behavior in interactive sessions. Now 'PyOS_ReadlineFunctionPointer' can be properly overrode and users of 'readline' module will not see any change: in non-interactive tty's 'PyOS_StdioReadline()' will be called anyway. The problem in 'input' and 'raw_input' builtins remains, but its solution is not so clear to me, I think this part should not be touched right now. This patch passes 'Lib/test/regrtest.py' (of course, all those tests are non-interactive!). I use Python interpreter every day in the standard way and also in MPI-parallelized interactive sessions with this patch applied, and I never have any problem. I send my patch obtained with 'cvs diff -c' from current sources. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1232343&group_id=5470 From noreply at sourceforge.net Mon Jul 4 20:17:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jul 2005 11:17:04 -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-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 Tue Jul 5 06:25:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jul 2005 21:25:25 -0700 Subject: [Patches] [ python-Patches-1231336 ] Add unicode for sys.argv, os.environ, os.system Message-ID: Patches item #1231336, was opened at 2005-07-02 11:55 Message generated for change (Comment added) made by nyamatongwe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231336&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: Neil Hodgson (nyamatongwe) Assigned to: Nobody/Anonymous (nobody) Summary: Add unicode for sys.argv, os.environ, os.system Initial Comment: Most installations of Windows (2000, XP) are unicode native with narrow character APIs only providing a distorted view of the system. Python does not currently provide access to some basic features through wide character calls and so may see distorted values. This patch adds unicode compatibility for sys.argv, os.environ, and os.system. os.system accepts a unicode argument in the same way as described in PEP 277 for file APIs. For sys.argv and os.environ, new parallel unicode attributes sys.argvu and os.environu are added as it would cause too many problems to use unicode values for the existing attributes or to use unicode only for non-ASCII values. The features are only enabled on unicode native versions of Windows. The three features are demonstrated at http://www.scintilla.org/pyunicode.png The patch contains some documentation additions for sys.argvu and os.environu. There are no test cases as test cases involving running extra processes can be messy and fail for uninteresting reasons. ---------------------------------------------------------------------- >Comment By: Neil Hodgson (nyamatongwe) Date: 2005-07-05 14:25 Message: Logged In: YES user_id=12579 There are problems in sys.argvu as the current argument processing code removes some option arguments where these are processed by python. This can be almost fixed by storing the argc last elements into sys.argvu. However, when using [-c command], the command is removed from sys.argv as this allows the Python code to determine that it is either running with a command line command ("-c") or the name of the file. Attached patch fixes these problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231336&group_id=5470 From noreply at sourceforge.net Tue Jul 5 06:27:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jul 2005 21:27:31 -0700 Subject: [Patches] [ python-Patches-1231336 ] Add unicode for sys.argv, os.environ, os.system Message-ID: Patches item #1231336, was opened at 2005-07-02 11:55 Message generated for change (Comment added) made by nyamatongwe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231336&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: Neil Hodgson (nyamatongwe) Assigned to: Nobody/Anonymous (nobody) Summary: Add unicode for sys.argv, os.environ, os.system Initial Comment: Most installations of Windows (2000, XP) are unicode native with narrow character APIs only providing a distorted view of the system. Python does not currently provide access to some basic features through wide character calls and so may see distorted values. This patch adds unicode compatibility for sys.argv, os.environ, and os.system. os.system accepts a unicode argument in the same way as described in PEP 277 for file APIs. For sys.argv and os.environ, new parallel unicode attributes sys.argvu and os.environu are added as it would cause too many problems to use unicode values for the existing attributes or to use unicode only for non-ASCII values. The features are only enabled on unicode native versions of Windows. The three features are demonstrated at http://www.scintilla.org/pyunicode.png The patch contains some documentation additions for sys.argvu and os.environu. There are no test cases as test cases involving running extra processes can be messy and fail for uninteresting reasons. ---------------------------------------------------------------------- >Comment By: Neil Hodgson (nyamatongwe) Date: 2005-07-05 14:27 Message: Logged In: YES user_id=12579 Added a description to diff file. ---------------------------------------------------------------------- Comment By: Neil Hodgson (nyamatongwe) Date: 2005-07-05 14:25 Message: Logged In: YES user_id=12579 There are problems in sys.argvu as the current argument processing code removes some option arguments where these are processed by python. This can be almost fixed by storing the argc last elements into sys.argvu. However, when using [-c command], the command is removed from sys.argv as this allows the Python code to determine that it is either running with a command line command ("-c") or the name of the file. Attached patch fixes these problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231336&group_id=5470 From noreply at sourceforge.net Thu Jul 7 11:34:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jul 2005 02:34:27 -0700 Subject: [Patches] [ python-Patches-1234057 ] PEP 343 draft documentation Message-ID: Patches item #1234057, was opened at 2005-07-07 19:34 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=1234057&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Raymond Hettinger (rhettinger) Summary: PEP 343 draft documentation Initial Comment: Draft documentation for PEP 343's new 'with' statement, describing the operation in terms of contexts and context management. Uses __enter__/__exit__, as that is what currently has the BDFL's blessing via the approval of PEP 343. Requires addition of formatting codes before it can be included in the official documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1234057&group_id=5470 From noreply at sourceforge.net Thu Jul 7 16:14:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jul 2005 07:14:29 -0700 Subject: [Patches] [ python-Patches-1223381 ] PEP 342 Generator enhancements Message-ID: Patches item #1223381, was opened at 2005-06-19 00:08 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1223381&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: Phillip J. Eby (pje) Assigned to: Phillip J. Eby (pje) Summary: PEP 342 Generator enhancements Initial Comment: The attached patch implements code and test changes for: * yield expressions * bare yield (short for yield None) * yield in try/finally * generator.send(value) (send value into generator; substituted for PEP 342's next(arg)) * generator.throw(typ[,val[,tb]]) (raise error in generator) * generator.close() (per PEP 343) * GeneratorExit built-in exception type * generator.__del__ (well, the C equivalent) * All necessary mods to the compiler, parser module, and Python 'compiler' package to support these changes. It was necessary to change a small part of the eval loop (well, the initialization, not the loop) and the gc module's has_finalizer() logic in order to support a C equivalent to __del__. Specialists in these areas should probably scrutinize this patch! There is one additional implementation detail that was not contemplated in either PEP. in order to prevent used-up generators from retaining unnecessary references to their frame's contents, I set the generator's gi_frame member to None whenever the generator finishes normally or with an error. Thus, an exhausted generator cannot be part of a cycle, and it releases its frame object sooner than in previous Python versions. For generators used only in a direct "for" loop, this makes no difference, but for generators used with the iterator protocol (i.e. "gen.next()") from Python, this avoids stranding the generator's frame in a traceback cycle. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-07-07 15:14 Message: Logged In: YES user_id=6656 You missed an incref in gen_throw (symptom was Fatal Python error: ../Objects/tupleobject.c:169 object at 0x4013807c has negative ref count -606348326 on exit after running test_generators). New patch attached. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-28 08:10 Message: Logged In: YES user_id=6380 Since I've accepted PEP 342+343 last night in my Europython keynote, you can check this in now. ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2005-06-27 16:40 Message: Logged In: YES user_id=56214 I had hoped to be able to avoid dealing with string exceptions, but I guess it makes sense that if somebody has thrown one, it should be able to propagate. So I guess I'll take care of that along with the rest. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-27 16:31 Message: Logged In: YES user_id=6656 Heh heh heh. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-27 16:22 Message: Logged In: YES user_id=6380 (Removing 343 from the subject since all this is now in PEP 342.) Playing with the code a bit, I notice that throw() doesn't like string exceptions. That could cause some problems. Also, I think the tb argument should be allowed to be None. Otherwise, great! In a few hours you can check it in. :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-24 00:20 Message: Logged In: YES user_id=6656 Fair enough. I want to use with statements in a presentation at EuroPython next week, so I've hacked together a truly horrible implementation that will do for now and will see about a real one some time after... ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2005-06-24 00:07 Message: Logged In: YES user_id=56214 No, I haven't, and I never really planned to be the person implementing "with". Doesn't mean I might not end up doing it eventually, but it's not currently in my plans. I'm going to have my hands full just updating PEP 342 (Guido has asked me to take it over), and getting docs written to go with this patch. Between all that and my distutils-related work, my pro-bono Python project time is booked up solid for maybe the next 2 months or so. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-22 21:59 Message: Logged In: YES user_id=6656 Argh, I'd hoped you'd done with, too :) Have you done any work on that yet? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-19 08:37 Message: Logged In: YES user_id=1188172 Minor nit: on line 642, 'yield_stmt' should be changed to 'yield_expr'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1223381&group_id=5470 From noreply at sourceforge.net Fri Jul 8 16:15:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jul 2005 07:15:04 -0700 Subject: [Patches] [ python-Patches-1234057 ] PEP 343 draft documentation Message-ID: Patches item #1234057, was opened at 2005-07-07 19:34 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1234057&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Raymond Hettinger (rhettinger) Summary: PEP 343 draft documentation Initial Comment: Draft documentation for PEP 343's new 'with' statement, describing the operation in terms of contexts and context management. Uses __enter__/__exit__, as that is what currently has the BDFL's blessing via the approval of PEP 343. Requires addition of formatting codes before it can be included in the official documentation. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2005-07-09 00:15 Message: Logged In: YES user_id=1038590 New file attached - Update with PJE's HTML example - Show resource management example (synchronisation lock) - Show usage of closing() (including 'as' clause) - Fix a couple of typos ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1234057&group_id=5470 From noreply at sourceforge.net Sat Jul 9 01:49:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jul 2005 16:49:10 -0700 Subject: [Patches] [ python-Patches-1209527 ] Optimization for textwrap Message-ID: Patches item #1209527, was opened at 2005-05-26 23:09 Message generated for change (Comment added) made by connelly You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1209527&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: Connelly (connelly) Assigned to: Greg Ward (gward) Summary: Optimization for textwrap Initial Comment: This patch speeds up the textwrap module, so that it takes O(n) time to process n chunks rather than the O(n^2) time that textwrap previously took. This makes textwrap much faster for large texts (for example, the patched version runs textwrap.fill('foo' * 100000) 80 times faster than the unpatched version). ---------------------------------------------------------------------- >Comment By: Connelly (connelly) Date: 2005-07-08 23:49 Message: Logged In: YES user_id=1039782 Personally, I need linear running time for this module, so I contributed the patch in the hope that others would find it useful. The practical result is that parsing a 5 MB unwrapped text file takes an order of seconds with the patch, and > 10 minutes without the patch (3 GHz Pentium). If the code is written with a deque or queue, there would be a similar speed incease, since deque operations are O(1). Is the patch not 'clean enough' code-wide? (I could recode it to use collections.deque or else a simple dummy queue if collections is not available). ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-06-03 13:49 Message: Logged In: YES user_id=2772 I didn't benchmark the speed increase, but I verified that on my system 'test_textwrap.py' still completes successfully. I also looked at the patch and found the change to be straightforward. However, I wonder if the speed increase would be nearly as great if collections.deque was used instead of the reversed list. Unfortunately, the textwrap module seems to intend portability with older versions of Python, which would not work if the collections module is used. ---------------------------------------------------------------------- Comment By: Connelly (connelly) Date: 2005-05-27 16:37 Message: Logged In: YES user_id=1039782 I assign the Copyright for this patch to the Python Software Foundation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1209527&group_id=5470 From noreply at sourceforge.net Sat Jul 9 03:02:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jul 2005 18:02:13 -0700 Subject: [Patches] [ python-Patches-1234057 ] PEP 343 draft documentation Message-ID: Patches item #1234057, was opened at 2005-07-07 19:34 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1234057&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Raymond Hettinger (rhettinger) Summary: PEP 343 draft documentation Initial Comment: Draft documentation for PEP 343's new 'with' statement, describing the operation in terms of contexts and context management. Uses __enter__/__exit__, as that is what currently has the BDFL's blessing via the approval of PEP 343. Requires addition of formatting codes before it can be included in the official documentation. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2005-07-09 11:02 Message: Logged In: YES user_id=1038590 v.3 - added decimal.getcontext() example - added non-generator version of closing() example - added generator version of tag() example ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-07-09 00:15 Message: Logged In: YES user_id=1038590 New file attached - Update with PJE's HTML example - Show resource management example (synchronisation lock) - Show usage of closing() (including 'as' clause) - Fix a couple of typos ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1234057&group_id=5470 From noreply at sourceforge.net Sat Jul 9 13:15:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jul 2005 04:15:03 -0700 Subject: [Patches] [ python-Patches-1209527 ] Optimization for textwrap Message-ID: Patches item #1209527, was opened at 2005-05-27 01:09 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1209527&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: Connelly (connelly) Assigned to: Greg Ward (gward) Summary: Optimization for textwrap Initial Comment: This patch speeds up the textwrap module, so that it takes O(n) time to process n chunks rather than the O(n^2) time that textwrap previously took. This makes textwrap much faster for large texts (for example, the patched version runs textwrap.fill('foo' * 100000) 80 times faster than the unpatched version). ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-09 13:15 Message: Logged In: YES user_id=1188172 I've applied the original patch, ensured the test suite ran and measured the same speedup as Connelly. Looks like a sound addition. Another option is, as he said, using collections.deque or an substitute class for compatibility. ---------------------------------------------------------------------- Comment By: Connelly (connelly) Date: 2005-07-09 01:49 Message: Logged In: YES user_id=1039782 Personally, I need linear running time for this module, so I contributed the patch in the hope that others would find it useful. The practical result is that parsing a 5 MB unwrapped text file takes an order of seconds with the patch, and > 10 minutes without the patch (3 GHz Pentium). If the code is written with a deque or queue, there would be a similar speed incease, since deque operations are O(1). Is the patch not 'clean enough' code-wide? (I could recode it to use collections.deque or else a simple dummy queue if collections is not available). ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-06-03 15:49 Message: Logged In: YES user_id=2772 I didn't benchmark the speed increase, but I verified that on my system 'test_textwrap.py' still completes successfully. I also looked at the patch and found the change to be straightforward. However, I wonder if the speed increase would be nearly as great if collections.deque was used instead of the reversed list. Unfortunately, the textwrap module seems to intend portability with older versions of Python, which would not work if the collections module is used. ---------------------------------------------------------------------- Comment By: Connelly (connelly) Date: 2005-05-27 18:37 Message: Logged In: YES user_id=1039782 I assign the Copyright for this patch to the Python Software Foundation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1209527&group_id=5470 From noreply at sourceforge.net Sat Jul 9 15:35:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jul 2005 06:35:17 -0700 Subject: [Patches] [ python-Patches-1209527 ] Optimization for textwrap Message-ID: Patches item #1209527, was opened at 2005-05-26 18:09 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1209527&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: Connelly (connelly) >Assigned to: Raymond Hettinger (rhettinger) Summary: Optimization for textwrap Initial Comment: This patch speeds up the textwrap module, so that it takes O(n) time to process n chunks rather than the O(n^2) time that textwrap previously took. This makes textwrap much faster for large texts (for example, the patched version runs textwrap.fill('foo' * 100000) 80 times faster than the unpatched version). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-09 06:15 Message: Logged In: YES user_id=1188172 I've applied the original patch, ensured the test suite ran and measured the same speedup as Connelly. Looks like a sound addition. Another option is, as he said, using collections.deque or an substitute class for compatibility. ---------------------------------------------------------------------- Comment By: Connelly (connelly) Date: 2005-07-08 18:49 Message: Logged In: YES user_id=1039782 Personally, I need linear running time for this module, so I contributed the patch in the hope that others would find it useful. The practical result is that parsing a 5 MB unwrapped text file takes an order of seconds with the patch, and > 10 minutes without the patch (3 GHz Pentium). If the code is written with a deque or queue, there would be a similar speed incease, since deque operations are O(1). Is the patch not 'clean enough' code-wide? (I could recode it to use collections.deque or else a simple dummy queue if collections is not available). ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-06-03 08:49 Message: Logged In: YES user_id=2772 I didn't benchmark the speed increase, but I verified that on my system 'test_textwrap.py' still completes successfully. I also looked at the patch and found the change to be straightforward. However, I wonder if the speed increase would be nearly as great if collections.deque was used instead of the reversed list. Unfortunately, the textwrap module seems to intend portability with older versions of Python, which would not work if the collections module is used. ---------------------------------------------------------------------- Comment By: Connelly (connelly) Date: 2005-05-27 11:37 Message: Logged In: YES user_id=1039782 I assign the Copyright for this patch to the Python Software Foundation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1209527&group_id=5470 From noreply at sourceforge.net Sat Jul 9 16:26:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jul 2005 07:26:30 -0700 Subject: [Patches] [ python-Patches-1175850 ] Allow weak referencing of classic classes Message-ID: Patches item #1175850, was opened at 2005-04-03 07:29 Message generated for change (Comment added) made by glchapman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1175850&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: Greg Chapman (glchapman) Assigned to: Raymond Hettinger (rhettinger) Summary: Allow weak referencing of classic classes Initial Comment: In Python 2.4, you can weakref instances of classic classes but not the classes themselves. Attached is a patch which adds weakref support to classic classes. ---------------------------------------------------------------------- >Comment By: Greg Chapman (glchapman) Date: 2005-07-09 06:26 Message: Logged In: YES user_id=86307 Well, I'd been meaning to get around to finishing this, but here it is three months later, and I haven't found (or made) the time. So I'm just going to close this as Rejected. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-04-10 11:47 Message: Logged In: YES user_id=86307 Ah, I see, not so easy to do it properly. Fair enough. One quick question though: Py_TPFLAGS_HAVE_WEAKREFS is included in Py_TPFLAGS_DEFAULT. I didn't include it explicitly because of that and because neither of the other two types in classobject.c explicitly uses it (though I see other types do explicitly use it). So are PyInstance_Type and PyMethod_Type wrong? (Should I include a change to their definitions?) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-10 10:51 Message: Logged In: YES user_id=80475 Be sure to add Py_TPFLAGS_HAVE_WEAKREFS to tp_flags. Beef-up the unittest. See test_weakref() in test.test_deque.py for an example. Add classic classes to the list of weak referencables in libweakref.tex. Include a \versionadded tag. Add an entry to Misc/NEWS. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-04-10 09:05 Message: Logged In: YES user_id=86307 Here's my use case. I've been experimenting with the multimethods module written by David Mertz (part of his gnosis utilities). This uses mros from a declared signature and from the actual parameter types to determine which overload to call. Classic classes don't have an mro, so I needed to calculate one to accomodate them. Having done so, I wanted to cache it. The best solution might be the one I'm using now, which is simply to assign the calculated mro to a __mro__ attribute of the classic class. However, it seemed better to me to use an external cache, rather than modifying the class. I wanted this external cache to be a WeakKeyDictionary, because, if a module containing a classic class is reloaded, I didn't want the old version of the class kept alive solely by my cache (it avoided a reference cycle with the mro itself by storing a list with the first element set to None; then, when fetched, copying the list and putting the class in the copy's first element). Anyway, feel free to reject this. It was so easy to do, I just thought I'd go ahead and post it in case the lack was simply an oversight. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-10 08:02 Message: Logged In: YES user_id=80475 I'm curious why you would ever want to do this. It is somewhat rare to delete a class reference and, I presume, rarer still to need a weak-reference to such a class. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1175850&group_id=5470 From noreply at sourceforge.net Sat Jul 9 16:29:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jul 2005 07:29:03 -0700 Subject: [Patches] [ python-Patches-628208 ] xmlrpclib: Optional 'nil' support Message-ID: Patches item #628208, was opened at 2002-10-24 22:33 Message generated for change (Comment added) made by jpa- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=628208&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: Accepted Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: A.M. Kuchling (akuchling) Summary: xmlrpclib: Optional 'nil' support Initial Comment: This patch doesn't include documentation or test suite updates yet, and only touches the < The <nil/> extension is defined at http://ontosys.com/xml-rpc/extensions.html. Outstanding questions: * To generate <nil/>, an option must be explicitly supplied to dumps(). <nil/> is always accepted, and it can't be turned off. Is this OK? * Similarly, allow_none is on or off for a ServerProxy; you can't turn it on for just one method. (Seems a reasonable limitation...) * Should the parameter to enable it be named allow_none (Python term) or allow_nil (XML-RPC term)? * When allow_none is false and a None is encountered, this patch raises a ValueError. Is that the right exception, or should it use xmlrpclib.Error? Can anyone suggest a better message for the exception? * The FastMarshaller accelerator would also need to be updated. * Are we ever likely to change the default for allow_none to True? If so, how should we arrange things so we can warn people? ---------------------------------------------------------------------- Comment By: jpa (jpa-) Date: 2005-07-09 17:29 Message: Logged In: YES user_id=1197626 Should it be possible to return 'None' from function? I'm having problem with this, and I think the "cannot marshal" error is coming from the server, not client. However, SimpleXMLRPCServer doesn't recognize allow_none as an argument? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-26 04:20 Message: Logged In: YES user_id=33168 This was checked in. Is there anything left to do or should this patch be closed? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-04-20 22:06 Message: Logged In: YES user_id=11375 Should I leave the name of the 'allow_none' parameter alone, or should I change it to 'strict' and default it to True? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-04-19 11:01 Message: Logged In: YES user_id=21627 Since /F seems unresponsive, I'll accept the patch, on the provision that it is integrated before Python 2.3b1 (or after Python 2.3 is released), and that a documentation change is also committed. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-10-29 18:44 Message: Logged In: YES user_id=11375 Updated version of the patch: raises TypeError instead of ValueError, and uses Martin's suggested wording; thanks! Now it's up to /F to accept, decline, or request revisions to this patch. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-24 22:50 Message: Logged In: YES user_id=21627 On the exception: Currently, you get TypeError: cannot marshal <type 'NoneType'> objects and TypeError seems to be the right thing. The message might read cannot marshal None unless allow_none is enabled On allowing None by default: I'd assume that you would want to disable None only for "strictly-conforming" operation, so I'd expect to see an option strict (which then defaults to False). I don't know in what other ways we'd reasonably deviate from the spec. If that ever happens, I don't think a transitional warning is needed: existing applications continue to work. In general, in cases that produce an exception now, we don't need a transition procedure. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=628208&group_id=5470 From noreply at sourceforge.net Sat Jul 9 17:29:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jul 2005 08:29:23 -0700 Subject: [Patches] [ python-Patches-1175850 ] Allow weak referencing of classic classes Message-ID: Patches item #1175850, was opened at 2005-04-03 17:29 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1175850&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: Greg Chapman (glchapman) Assigned to: Raymond Hettinger (rhettinger) Summary: Allow weak referencing of classic classes Initial Comment: In Python 2.4, you can weakref instances of classic classes but not the classes themselves. Attached is a patch which adds weakref support to classic classes. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-09 17:29 Message: Logged In: YES user_id=1188172 Changing to Postponed, as the new functionality as such wasn't rejected. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-07-09 16:26 Message: Logged In: YES user_id=86307 Well, I'd been meaning to get around to finishing this, but here it is three months later, and I haven't found (or made) the time. So I'm just going to close this as Rejected. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-04-10 21:47 Message: Logged In: YES user_id=86307 Ah, I see, not so easy to do it properly. Fair enough. One quick question though: Py_TPFLAGS_HAVE_WEAKREFS is included in Py_TPFLAGS_DEFAULT. I didn't include it explicitly because of that and because neither of the other two types in classobject.c explicitly uses it (though I see other types do explicitly use it). So are PyInstance_Type and PyMethod_Type wrong? (Should I include a change to their definitions?) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-10 20:51 Message: Logged In: YES user_id=80475 Be sure to add Py_TPFLAGS_HAVE_WEAKREFS to tp_flags. Beef-up the unittest. See test_weakref() in test.test_deque.py for an example. Add classic classes to the list of weak referencables in libweakref.tex. Include a \versionadded tag. Add an entry to Misc/NEWS. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-04-10 19:05 Message: Logged In: YES user_id=86307 Here's my use case. I've been experimenting with the multimethods module written by David Mertz (part of his gnosis utilities). This uses mros from a declared signature and from the actual parameter types to determine which overload to call. Classic classes don't have an mro, so I needed to calculate one to accomodate them. Having done so, I wanted to cache it. The best solution might be the one I'm using now, which is simply to assign the calculated mro to a __mro__ attribute of the classic class. However, it seemed better to me to use an external cache, rather than modifying the class. I wanted this external cache to be a WeakKeyDictionary, because, if a module containing a classic class is reloaded, I didn't want the old version of the class kept alive solely by my cache (it avoided a reference cycle with the mro itself by storing a list with the first element set to None; then, when fetched, copying the list and putting the class in the copy's first element). Anyway, feel free to reject this. It was so easy to do, I just thought I'd go ahead and post it in case the lack was simply an oversight. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-10 18:02 Message: Logged In: YES user_id=80475 I'm curious why you would ever want to do this. It is somewhat rare to delete a class reference and, I presume, rarer still to need a weak-reference to such a class. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1175850&group_id=5470 From noreply at sourceforge.net Sat Jul 9 19:28:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jul 2005 10:28:15 -0700 Subject: [Patches] [ python-Patches-847857 ] Extend struct.unpack to produce nested tuples Message-ID: Patches item #847857, was opened at 2003-11-23 23:24 Message generated for change (Comment added) made by fabe3k You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=847857&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: Matthew Barnes (mfbarnes) Assigned to: Nobody/Anonymous (nobody) Summary: Extend struct.unpack to produce nested tuples Initial Comment: This patch extends the struct.unpack format notation to be able to express groups of data with parentheses. For example: >>> data = struct.pack('iiii', 1, 2, 3, 4) >>> struct.unpack('i(ii)i', data) (1, (2, 3), 4) Integral repeat counts can also be applied to groups. >>> struct.unpack('2(ii)', data) ((1, 2), (3, 4)) In addition, struct.calcsize also handles parentheses in format strings correctly. >>> struct.calcsize('4(ii)') 32 No changes were made to struct.pack. It still treats parentheses as illegal format characters. I have not yet updated any documentation or tests associated with struct.calcsize or struct.unpack. ---------------------------------------------------------------------- Comment By: Fabian Bieler (fabe3k) Date: 2005-07-09 19:28 Message: Logged In: YES user_id=615150 I would like to see this patch applied to Python. This functionality would be very usefull for opening binary files with a given format. Is there a particular reason why this patch was not accepted? ---------------------------------------------------------------------- Comment By: Matthew Barnes (mfbarnes) Date: 2004-12-20 07:43 Message: Logged In: YES user_id=843448 I suggested this change on Python-Dev last year (http://mail.python.org/pipermail/python-dev/2003-November/040391.html). The use case I put forth at the time was as follows: Use Case: I have a program written in C that contains a bunch of aggregate data structures (arrays of structs, structs containing arrays, etc.) and I'm transmitting these structures over a socket connection to a Python program that then unpacks the data using the struct module. Problem is that I have to unpack the incoming data as a flat sequence of data elements, and then repartition the sequence into nested sequences to better reflect how the data is structured in the C program. It would be more convenient to express these groupings as I'm unpacking the raw data. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-20 04:57 Message: Logged In: YES user_id=80475 What are the use cases to warrant this change? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=847857&group_id=5470 From noreply at sourceforge.net Sat Jul 9 19:44:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jul 2005 10:44:12 -0700 Subject: [Patches] [ python-Patches-847857 ] Extend struct.unpack to produce nested tuples Message-ID: Patches item #847857, was opened at 2003-11-23 17:24 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=847857&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: Matthew Barnes (mfbarnes) >Assigned to: Raymond Hettinger (rhettinger) Summary: Extend struct.unpack to produce nested tuples Initial Comment: This patch extends the struct.unpack format notation to be able to express groups of data with parentheses. For example: >>> data = struct.pack('iiii', 1, 2, 3, 4) >>> struct.unpack('i(ii)i', data) (1, (2, 3), 4) Integral repeat counts can also be applied to groups. >>> struct.unpack('2(ii)', data) ((1, 2), (3, 4)) In addition, struct.calcsize also handles parentheses in format strings correctly. >>> struct.calcsize('4(ii)') 32 No changes were made to struct.pack. It still treats parentheses as illegal format characters. I have not yet updated any documentation or tests associated with struct.calcsize or struct.unpack. ---------------------------------------------------------------------- Comment By: Fabian Bieler (fabe3k) Date: 2005-07-09 12:28 Message: Logged In: YES user_id=615150 I would like to see this patch applied to Python. This functionality would be very usefull for opening binary files with a given format. Is there a particular reason why this patch was not accepted? ---------------------------------------------------------------------- Comment By: Matthew Barnes (mfbarnes) Date: 2004-12-20 01:43 Message: Logged In: YES user_id=843448 I suggested this change on Python-Dev last year (http://mail.python.org/pipermail/python-dev/2003-November/040391.html). The use case I put forth at the time was as follows: Use Case: I have a program written in C that contains a bunch of aggregate data structures (arrays of structs, structs containing arrays, etc.) and I'm transmitting these structures over a socket connection to a Python program that then unpacks the data using the struct module. Problem is that I have to unpack the incoming data as a flat sequence of data elements, and then repartition the sequence into nested sequences to better reflect how the data is structured in the C program. It would be more convenient to express these groupings as I'm unpacking the raw data. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 22:57 Message: Logged In: YES user_id=80475 What are the use cases to warrant this change? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=847857&group_id=5470 From noreply at sourceforge.net Sat Jul 9 19:45:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jul 2005 10:45:35 -0700 Subject: [Patches] [ python-Patches-847857 ] Extend struct.unpack to produce nested tuples Message-ID: Patches item #847857, was opened at 2003-11-23 17:24 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=847857&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: Matthew Barnes (mfbarnes) Assigned to: Raymond Hettinger (rhettinger) Summary: Extend struct.unpack to produce nested tuples Initial Comment: This patch extends the struct.unpack format notation to be able to express groups of data with parentheses. For example: >>> data = struct.pack('iiii', 1, 2, 3, 4) >>> struct.unpack('i(ii)i', data) (1, (2, 3), 4) Integral repeat counts can also be applied to groups. >>> struct.unpack('2(ii)', data) ((1, 2), (3, 4)) In addition, struct.calcsize also handles parentheses in format strings correctly. >>> struct.calcsize('4(ii)') 32 No changes were made to struct.pack. It still treats parentheses as illegal format characters. I have not yet updated any documentation or tests associated with struct.calcsize or struct.unpack. ---------------------------------------------------------------------- Comment By: Fabian Bieler (fabe3k) Date: 2005-07-09 12:28 Message: Logged In: YES user_id=615150 I would like to see this patch applied to Python. This functionality would be very usefull for opening binary files with a given format. Is there a particular reason why this patch was not accepted? ---------------------------------------------------------------------- Comment By: Matthew Barnes (mfbarnes) Date: 2004-12-20 01:43 Message: Logged In: YES user_id=843448 I suggested this change on Python-Dev last year (http://mail.python.org/pipermail/python-dev/2003-November/040391.html). The use case I put forth at the time was as follows: Use Case: I have a program written in C that contains a bunch of aggregate data structures (arrays of structs, structs containing arrays, etc.) and I'm transmitting these structures over a socket connection to a Python program that then unpacks the data using the struct module. Problem is that I have to unpack the incoming data as a flat sequence of data elements, and then repartition the sequence into nested sequences to better reflect how the data is structured in the C program. It would be more convenient to express these groupings as I'm unpacking the raw data. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 22:57 Message: Logged In: YES user_id=80475 What are the use cases to warrant this change? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=847857&group_id=5470 From noreply at sourceforge.net Mon Jul 11 12:09:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jul 2005 03:09:53 -0700 Subject: [Patches] [ python-Patches-1235943 ] PEP 343 implementation Message-ID: Patches item #1235943, was opened at 2005-07-11 11:09 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=1235943&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: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 343 implementation Initial Comment: This large patch (nearly 90 K, affecting 25 files!) implements PEP 343. Work done: Changes Grammar/Grammar, Python/compile.c and Python/ceval.c to support new statement (a new opcode, LOAD_EXIT_ARGS, is possibly not strictly needed, but the stack yoga to avoid it would be very tiring). Implements a new __future__ statement, "with_statement", by cribbing the '#if 0'ed out code from when generators were optional. Implements support for the with statement in Lib/compiler (but Lib/ compiler doesn't support future statements at all?). Updates Lib/opcode.py, Lib/symbol.py. Updates the parser module and it's tests. Lib/test/test_with.py contains a couple of doctests, one a reasonably comprehensive tour of with statement functionality and the other is intended to contain the examples from the PEP, but most of these depend on PEP 342, the implementation of which hasn't been checked in yet. The code isn't the prettiest in places (esp search for the two XXXs). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1235943&group_id=5470 From noreply at sourceforge.net Mon Jul 11 18:30:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jul 2005 09:30:52 -0700 Subject: [Patches] [ python-Patches-1220212 ] os.kill on windows Message-ID: Patches item #1220212, was opened at 2005-06-14 11:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220212&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: Miki Tebeka (tebeka) >Assigned to: Nobody/Anonymous (nobody) Summary: os.kill on windows Initial Comment: This patch enables os.kill on windows. This way there will be an "out of the box" way to kill process on windows. Basically kill calls TerminateProcess and the "signal" paramer will be the process return code. Don't have CVS access today so I'm sending the whole files in a zip (sorry). Also some config wizard need to change the winsows configuration and set HAVE_KILL. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-07-11 18:30 Message: Logged In: YES user_id=21627 Converted to unified diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220212&group_id=5470 From noreply at sourceforge.net Mon Jul 11 18:42:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jul 2005 09:42:41 -0700 Subject: [Patches] [ python-Patches-1231336 ] Add unicode for sys.argv, os.environ, os.system Message-ID: Patches item #1231336, was opened at 2005-07-02 03:55 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231336&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: Neil Hodgson (nyamatongwe) Assigned to: Nobody/Anonymous (nobody) Summary: Add unicode for sys.argv, os.environ, os.system Initial Comment: Most installations of Windows (2000, XP) are unicode native with narrow character APIs only providing a distorted view of the system. Python does not currently provide access to some basic features through wide character calls and so may see distorted values. This patch adds unicode compatibility for sys.argv, os.environ, and os.system. os.system accepts a unicode argument in the same way as described in PEP 277 for file APIs. For sys.argv and os.environ, new parallel unicode attributes sys.argvu and os.environu are added as it would cause too many problems to use unicode values for the existing attributes or to use unicode only for non-ASCII values. The features are only enabled on unicode native versions of Windows. The three features are demonstrated at http://www.scintilla.org/pyunicode.png The patch contains some documentation additions for sys.argvu and os.environu. There are no test cases as test cases involving running extra processes can be messy and fail for uninteresting reasons. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-07-11 18:42 Message: Logged In: YES user_id=21627 For os.environ, I think I would prefer a solution where Unicode keys result in Unicode values and string keys result in string values, with the canonical conversion through "mbcs" in place. For argv, I agree something should be done, but I'm not certain that the introduction of argvu is the best thing to do; this should be dicsussed on python-dev, and with all people originally involved in PEP 277. The change to system() is not mentioned at all in your message. It doesn't seem to belong into this patch, either, so please submit it as a separate patch. If system() is changed to support Unicode commands, I think spawn*() should be changed as well. These seem less debatable, as they come as natural extensions to PEP 277 (i.e. pass Unicode through to the system). ---------------------------------------------------------------------- Comment By: Neil Hodgson (nyamatongwe) Date: 2005-07-05 06:27 Message: Logged In: YES user_id=12579 Added a description to diff file. ---------------------------------------------------------------------- Comment By: Neil Hodgson (nyamatongwe) Date: 2005-07-05 06:25 Message: Logged In: YES user_id=12579 There are problems in sys.argvu as the current argument processing code removes some option arguments where these are processed by python. This can be almost fixed by storing the argc last elements into sys.argvu. However, when using [-c command], the command is removed from sys.argv as this allows the Python code to determine that it is either running with a command line command ("-c") or the name of the file. Attached patch fixes these problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231336&group_id=5470 From noreply at sourceforge.net Mon Jul 11 18:44:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jul 2005 09:44:32 -0700 Subject: [Patches] [ python-Patches-1229239 ] optionally allow mutable builtin types Message-ID: Patches item #1229239, was opened at 2005-06-28 20:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1229239&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: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: optionally allow mutable builtin types Initial Comment: Non-heap types, aka builtin types, cannot have their attributes changed by Python code -- see Objects/typeobject.c: type_setattro(). This limitation is good for Python's core builtin types (int, float, list, dict, ...), but not necessarily for non-heap types in extension modules. The attached patch allows for non-heap types to mutate iff the Py_TPFLAGS_MUTABLE_BUILTIN flag is set. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-07-11 18:44 Message: Logged In: YES user_id=21627 Why can't you create such a type as a heap type? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1229239&group_id=5470 From noreply at sourceforge.net Tue Jul 12 05:11:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jul 2005 20:11:26 -0700 Subject: [Patches] [ python-Patches-1234057 ] PEP 343 draft documentation Message-ID: Patches item #1234057, was opened at 2005-07-07 04:34 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1234057&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Raymond Hettinger (rhettinger) Summary: PEP 343 draft documentation Initial Comment: Draft documentation for PEP 343's new 'with' statement, describing the operation in terms of contexts and context management. Uses __enter__/__exit__, as that is what currently has the BDFL's blessing via the approval of PEP 343. Requires addition of formatting codes before it can be included in the official documentation. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-11 22:11 Message: Logged In: YES user_id=80475 I'm happy to review the docs but it will likely take a week for me to get to it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-07-08 20:02 Message: Logged In: YES user_id=1038590 v.3 - added decimal.getcontext() example - added non-generator version of closing() example - added generator version of tag() example ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-07-08 09:15 Message: Logged In: YES user_id=1038590 New file attached - Update with PJE's HTML example - Show resource management example (synchronisation lock) - Show usage of closing() (including 'as' clause) - Fix a couple of typos ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1234057&group_id=5470 From noreply at sourceforge.net Tue Jul 12 11:59:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jul 2005 02:59:31 -0700 Subject: [Patches] [ python-Patches-1214889 ] file.encoding support for file.write and file.writelines Message-ID: Patches item #1214889, was opened at 2005-06-04 19:45 Message generated for change (Comment added) made by prikryl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&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: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: file.encoding support for file.write and file.writelines Initial Comment: Here is a patch that allows Unicode strings written to a file being automatically encoded. It enables Python code to set file.encoding and obeys this encoding when writing Unicode strings with write() or writelines(). It is my first core hackery, so forgive me one leaked ref or the other. I hope I got the error handling right; it is kind of confusing... (btw: Bug #967986 will be fixed with this) ---------------------------------------------------------------------- Comment By: Petr Prikryl (prikryl) Date: 2005-07-12 11:59 Message: Logged In: YES user_id=771873 The title and the comments do not say so, but the patch was created by Reinhold Birkenfeld to solve the bug [ 1099364 ] raw_input() displays wrong unicode prompt As the bug was closed and Reinhold claims to be his "first core hackery", I'd like to ask someone else to revise, whether the patch is the correct solution to the reported bug. The bug seems to be very visible (hence serious) in non-English speaking countries where Unicode promisses to solve many problems. Because of that I ask whether the bug should be closed before accepting the patch. I am adding this text also to link this patch to the original problem. Thanks, Petr ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 18:31 Message: Logged In: YES user_id=1188172 Okay, put on #5. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-06-05 17:20 Message: Logged In: YES user_id=55188 Yet another thing to fix: You can't put local namespace declarations after non-declaration statements. Because Python uses C89 as a C source code standard, you should all declarations in the top of functions only. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 14:17 Message: Logged In: YES user_id=1188172 Thanks! Corrected in patch #4. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-06-05 14:09 Message: Logged In: YES user_id=671362 Reinhold, libstdtypes.tex needs two fixes. \versionadded{2.3} +\versionchanged[The encoding attribute is now writable and is used +for encoding Unicode strings given to \method{write()} and +\method{writelines()}.]{ ~~~ First, versionchanged tag does not have a trailing brace and it resuls in compile error. Second(really trivial), versionchanged macro automatically appends a period at the end of the sentence(see the link [*]), so you don't need to put it by hand. Then the above line would become: +\method{writelines()}]{2.5} [*]: http://docs.python.org/doc/inline-markup.html ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 09:56 Message: Logged In: YES user_id=1188172 Third revision; adds new documentation and allows Python code to set the encoding to Py_None. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-06-05 04:26 Message: Logged In: YES user_id=55188 The idea looks good to me. I attached a revised patch fixed code style, C99-style local variable declaration and added a regrtest. I think some documentation update will be needed also. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&group_id=5470 From eurosemi at eurosemi.eu.com Tue Jul 12 16:51:12 2005 From: eurosemi at eurosemi.eu.com (eurosemi@eurosemi.eu.com) Date: Tue, 12 Jul 2005 10:51:12 -0400 (EDT) Subject: [Patches] Eurosemi Newsletter Message-ID: <20050712145112.6C34755042B@sulux.angelbc.co.uk> charset="iso-8859-1" Content-Transfer-Encoding:8bit If you are viewing this message your email system is not set up to view html email. Please view the online version of this mailshot at the url below. http://www.eurosemi.eu.com/es-120705.htm Kind regards, Eurosemi Team -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20050712/743f2047/attachment-0001.htm From noreply at sourceforge.net Tue Jul 12 23:59:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jul 2005 14:59:23 -0700 Subject: [Patches] [ python-Patches-1101726 ] Patch for potential buffer overrun in tokenizer.c Message-ID: Patches item #1101726, was opened at 2005-01-13 16:45 Message generated for change (Settings changed) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1101726&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: Fixed Priority: 7 Submitted By: Greg Chapman (glchapman) Assigned to: Martin v. L?wis (loewis) Summary: Patch for potential buffer overrun in tokenizer.c Initial Comment: The fp_readl function in tokenizer.c has a potential buffer overrun; see: www.python.org/sf/1089395 It is also triggered by trying to generate the pycom file for the Excel 11.0 typelib, which is where I ran into it. The attached patch allows successful generation of the Excel file; it also runs the fail.py script from the above report without an access violation. It also doesn't break any of the tests in the regression suite (probably something like fail.py should be added as a test). It is not as efficient as it might be; with a function for determining the number of unicode characters in a utf8 string, you could avoid some memory allocations. Perhaps such a function should be added to unicodeobject.c? And, of course, the patch definitely needs review. I'm especially concerned that my use of tok->decoding_buffer might be violating some kind of assumption that I missed. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-07-12 23:59 Message: Logged In: YES user_id=89016 Checked in as: Parser/tokenizer.c 2.78 Parser/tokenizer.c 2.76.2.1 ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-05-17 15:47 Message: Logged In: YES user_id=86307 Looks good to me. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-05-16 16:11 Message: Logged In: YES user_id=89016 Here is another version of the patch, this version doesn't pass any arguments to readline(), because it's no longer neccessary to limit the line length. What do you think? ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-03-21 14:47 Message: Logged In: YES user_id=86307 You're quite right, 2.4 AV's reliably using the new test_pep263. The copy of python24.dll I was testing against already had (the first version of) the patch applied. Anyway, I'm attaching a diff for test_pep263 (against the original 2.4 test_pep263) which incorporates your suggestions about not assuming the current directory. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-03-14 22:43 Message: Logged In: YES user_id=89016 Maybe I've put the test files in the wrong spot, but what I'm getting is: > ./python Lib/test/test_pep263.py test_pep263 (__main__.PEP263Test) ... ok test_evilencoding (__main__.EvilEncodingTest) ... ok Segmentation fault You should probably put pep263_evilencoding.py and pep263_longline.py alongside test_pep263.py and then find then via os.path.join(__file__.rsplit(os.sep, 1)[0], "pep263_longline.py") ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-02-27 16:22 Message: Logged In: YES user_id=86307 After thinking about it some more, I realized that fp_readl doesn?t have to do any utf8 manipulation. If the string it copies into the buffer does not include a \n, the buffer is expanded and fp_readl is called again until a \n is returned (or the end of the file is reached). It doesn?t matter if, during this loop, the buffer contains temporarily broken utf8 characters. So I?m attaching another new patch. This copies as many characters as fit into the buffer and saves any overflow into a new string object (stored in tok >decoding_buffer). When it is called again by the loop, it uses this overflow string to copy characters into the buffer. I?m also attaching a zip file with a modified test_pep263.py and some ancillary files. To test fp_readl, python needs to read from a file. Perhaps it would be better to generate temporary files rather than include these extra files. Also, although the tests will trigger the assert using a debug build of the 2.4 source, I?m not getting an access violation running regrtest against a release build (of 2.4) ? perhaps different tests are in order? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-02-23 20:48 Message: Logged In: YES user_id=89016 I think the patch looks good. Staring at it for a while I believe the reference counts are OK. Can you incorporate fail.py into the test suite? ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-01-23 15:26 Message: Logged In: YES user_id=86307 I'm attaching a new patch (tokenizer.c.2.diff), which should be better since it avoids some unnecessary allocations and decoding/encoding. Hopefully, I haven't made any unwarranted assumptions about UTF8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1101726&group_id=5470 From noreply at sourceforge.net Thu Jul 14 09:52:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jul 2005 00:52:30 -0700 Subject: [Patches] [ python-Patches-1214889 ] file.encoding support for file.write and file.writelines Message-ID: Patches item #1214889, was opened at 2005-06-04 19:45 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&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: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: file.encoding support for file.write and file.writelines Initial Comment: Here is a patch that allows Unicode strings written to a file being automatically encoded. It enables Python code to set file.encoding and obeys this encoding when writing Unicode strings with write() or writelines(). It is my first core hackery, so forgive me one leaked ref or the other. I hope I got the error handling right; it is kind of confusing... (btw: Bug #967986 will be fixed with this) ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-07-14 09:52 Message: Logged In: YES user_id=38388 This doesn't quite work (yet): you've broken the support for writing binary data to the file via file.write(). Encodings should only be used for non-binary files. Also note that you are not freeing the memory allocated by the "et#" parser for s. Please add some test cases where you open a binary file and write: a) binary strings b) contents of a buffer object c) Unicode objects to it. Case c) should raise an exception. a) and b) should result in the data being written as-is - without doing any recoding. ---------------------------------------------------------------------- Comment By: Petr Prikryl (prikryl) Date: 2005-07-12 11:59 Message: Logged In: YES user_id=771873 The title and the comments do not say so, but the patch was created by Reinhold Birkenfeld to solve the bug [ 1099364 ] raw_input() displays wrong unicode prompt As the bug was closed and Reinhold claims to be his "first core hackery", I'd like to ask someone else to revise, whether the patch is the correct solution to the reported bug. The bug seems to be very visible (hence serious) in non-English speaking countries where Unicode promisses to solve many problems. Because of that I ask whether the bug should be closed before accepting the patch. I am adding this text also to link this patch to the original problem. Thanks, Petr ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 18:31 Message: Logged In: YES user_id=1188172 Okay, put on #5. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-06-05 17:20 Message: Logged In: YES user_id=55188 Yet another thing to fix: You can't put local namespace declarations after non-declaration statements. Because Python uses C89 as a C source code standard, you should all declarations in the top of functions only. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 14:17 Message: Logged In: YES user_id=1188172 Thanks! Corrected in patch #4. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-06-05 14:09 Message: Logged In: YES user_id=671362 Reinhold, libstdtypes.tex needs two fixes. \versionadded{2.3} +\versionchanged[The encoding attribute is now writable and is used +for encoding Unicode strings given to \method{write()} and +\method{writelines()}.]{ ~~~ First, versionchanged tag does not have a trailing brace and it resuls in compile error. Second(really trivial), versionchanged macro automatically appends a period at the end of the sentence(see the link [*]), so you don't need to put it by hand. Then the above line would become: +\method{writelines()}]{2.5} [*]: http://docs.python.org/doc/inline-markup.html ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 09:56 Message: Logged In: YES user_id=1188172 Third revision; adds new documentation and allows Python code to set the encoding to Py_None. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-06-05 04:26 Message: Logged In: YES user_id=55188 The idea looks good to me. I attached a revised patch fixed code style, C99-style local variable declaration and added a regrtest. I think some documentation update will be needed also. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&group_id=5470 From noreply at sourceforge.net Thu Jul 14 10:19:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jul 2005 01:19:12 -0700 Subject: [Patches] [ python-Patches-1214889 ] file.encoding support for file.write and file.writelines Message-ID: Patches item #1214889, was opened at 2005-06-04 19:45 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&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: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: file.encoding support for file.write and file.writelines Initial Comment: Here is a patch that allows Unicode strings written to a file being automatically encoded. It enables Python code to set file.encoding and obeys this encoding when writing Unicode strings with write() or writelines(). It is my first core hackery, so forgive me one leaked ref or the other. I hope I got the error handling right; it is kind of confusing... (btw: Bug #967986 will be fixed with this) ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-07-14 10:19 Message: Logged In: YES user_id=38388 I've thought about this some more: I'm not sure whether it is such a good idea to try to move code from the codecs into the standard file object - after all, the codecs already support all this and do a much better job at handling error cases and the like. Furthermore, codecs support both directions: reading and writing. Your patch only does one way. The encoding support you currently find in the file object is only needed for printing Unicode objects - it is not used anywhere else. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-07-14 09:52 Message: Logged In: YES user_id=38388 This doesn't quite work (yet): you've broken the support for writing binary data to the file via file.write(). Encodings should only be used for non-binary files. Also note that you are not freeing the memory allocated by the "et#" parser for s. Please add some test cases where you open a binary file and write: a) binary strings b) contents of a buffer object c) Unicode objects to it. Case c) should raise an exception. a) and b) should result in the data being written as-is - without doing any recoding. ---------------------------------------------------------------------- Comment By: Petr Prikryl (prikryl) Date: 2005-07-12 11:59 Message: Logged In: YES user_id=771873 The title and the comments do not say so, but the patch was created by Reinhold Birkenfeld to solve the bug [ 1099364 ] raw_input() displays wrong unicode prompt As the bug was closed and Reinhold claims to be his "first core hackery", I'd like to ask someone else to revise, whether the patch is the correct solution to the reported bug. The bug seems to be very visible (hence serious) in non-English speaking countries where Unicode promisses to solve many problems. Because of that I ask whether the bug should be closed before accepting the patch. I am adding this text also to link this patch to the original problem. Thanks, Petr ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 18:31 Message: Logged In: YES user_id=1188172 Okay, put on #5. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-06-05 17:20 Message: Logged In: YES user_id=55188 Yet another thing to fix: You can't put local namespace declarations after non-declaration statements. Because Python uses C89 as a C source code standard, you should all declarations in the top of functions only. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 14:17 Message: Logged In: YES user_id=1188172 Thanks! Corrected in patch #4. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-06-05 14:09 Message: Logged In: YES user_id=671362 Reinhold, libstdtypes.tex needs two fixes. \versionadded{2.3} +\versionchanged[The encoding attribute is now writable and is used +for encoding Unicode strings given to \method{write()} and +\method{writelines()}.]{ ~~~ First, versionchanged tag does not have a trailing brace and it resuls in compile error. Second(really trivial), versionchanged macro automatically appends a period at the end of the sentence(see the link [*]), so you don't need to put it by hand. Then the above line would become: +\method{writelines()}]{2.5} [*]: http://docs.python.org/doc/inline-markup.html ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 09:56 Message: Logged In: YES user_id=1188172 Third revision; adds new documentation and allows Python code to set the encoding to Py_None. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-06-05 04:26 Message: Logged In: YES user_id=55188 The idea looks good to me. I attached a revised patch fixed code style, C99-style local variable declaration and added a regrtest. I think some documentation update will be needed also. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&group_id=5470 From noreply at sourceforge.net Thu Jul 14 10:34:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jul 2005 01:34:11 -0700 Subject: [Patches] [ python-Patches-1214889 ] file.encoding support for file.write and file.writelines Message-ID: Patches item #1214889, was opened at 2005-06-04 19:45 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&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: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: file.encoding support for file.write and file.writelines Initial Comment: Here is a patch that allows Unicode strings written to a file being automatically encoded. It enables Python code to set file.encoding and obeys this encoding when writing Unicode strings with write() or writelines(). It is my first core hackery, so forgive me one leaked ref or the other. I hope I got the error handling right; it is kind of confusing... (btw: Bug #967986 will be fixed with this) ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-14 10:34 Message: Logged In: YES user_id=1188172 I agree with you that writing Unicode objects to a binary file should raise an exception, but with the 'et#' format string, 8-bit string objects should pass through file.write unrecoded. About your second comment: Yes, codecs is one way to do it, but then I think that the encoding handling for print should be ripped out, too. After all, that's what many people complain about: "print unistr" works, while "sys.stdout.write(unistr)" does not. As the comment below about bug 1099364 shows, this shows up in various locations. If this is rejected, file.write() shouldn't accept Unicode anymore, and print should behave the same way. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-07-14 10:19 Message: Logged In: YES user_id=38388 I've thought about this some more: I'm not sure whether it is such a good idea to try to move code from the codecs into the standard file object - after all, the codecs already support all this and do a much better job at handling error cases and the like. Furthermore, codecs support both directions: reading and writing. Your patch only does one way. The encoding support you currently find in the file object is only needed for printing Unicode objects - it is not used anywhere else. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-07-14 09:52 Message: Logged In: YES user_id=38388 This doesn't quite work (yet): you've broken the support for writing binary data to the file via file.write(). Encodings should only be used for non-binary files. Also note that you are not freeing the memory allocated by the "et#" parser for s. Please add some test cases where you open a binary file and write: a) binary strings b) contents of a buffer object c) Unicode objects to it. Case c) should raise an exception. a) and b) should result in the data being written as-is - without doing any recoding. ---------------------------------------------------------------------- Comment By: Petr Prikryl (prikryl) Date: 2005-07-12 11:59 Message: Logged In: YES user_id=771873 The title and the comments do not say so, but the patch was created by Reinhold Birkenfeld to solve the bug [ 1099364 ] raw_input() displays wrong unicode prompt As the bug was closed and Reinhold claims to be his "first core hackery", I'd like to ask someone else to revise, whether the patch is the correct solution to the reported bug. The bug seems to be very visible (hence serious) in non-English speaking countries where Unicode promisses to solve many problems. Because of that I ask whether the bug should be closed before accepting the patch. I am adding this text also to link this patch to the original problem. Thanks, Petr ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 18:31 Message: Logged In: YES user_id=1188172 Okay, put on #5. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-06-05 17:20 Message: Logged In: YES user_id=55188 Yet another thing to fix: You can't put local namespace declarations after non-declaration statements. Because Python uses C89 as a C source code standard, you should all declarations in the top of functions only. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 14:17 Message: Logged In: YES user_id=1188172 Thanks! Corrected in patch #4. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-06-05 14:09 Message: Logged In: YES user_id=671362 Reinhold, libstdtypes.tex needs two fixes. \versionadded{2.3} +\versionchanged[The encoding attribute is now writable and is used +for encoding Unicode strings given to \method{write()} and +\method{writelines()}.]{ ~~~ First, versionchanged tag does not have a trailing brace and it resuls in compile error. Second(really trivial), versionchanged macro automatically appends a period at the end of the sentence(see the link [*]), so you don't need to put it by hand. Then the above line would become: +\method{writelines()}]{2.5} [*]: http://docs.python.org/doc/inline-markup.html ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 09:56 Message: Logged In: YES user_id=1188172 Third revision; adds new documentation and allows Python code to set the encoding to Py_None. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-06-05 04:26 Message: Logged In: YES user_id=55188 The idea looks good to me. I attached a revised patch fixed code style, C99-style local variable declaration and added a regrtest. I think some documentation update will be needed also. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214889&group_id=5470 From noreply at sourceforge.net Thu Jul 14 12:35:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jul 2005 03:35:11 -0700 Subject: [Patches] [ python-Patches-1231336 ] Add unicode for sys.argv, os.environ, os.system Message-ID: Patches item #1231336, was opened at 2005-07-02 11:55 Message generated for change (Comment added) made by nyamatongwe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231336&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: Neil Hodgson (nyamatongwe) Assigned to: Nobody/Anonymous (nobody) Summary: Add unicode for sys.argv, os.environ, os.system Initial Comment: Most installations of Windows (2000, XP) are unicode native with narrow character APIs only providing a distorted view of the system. Python does not currently provide access to some basic features through wide character calls and so may see distorted values. This patch adds unicode compatibility for sys.argv, os.environ, and os.system. os.system accepts a unicode argument in the same way as described in PEP 277 for file APIs. For sys.argv and os.environ, new parallel unicode attributes sys.argvu and os.environu are added as it would cause too many problems to use unicode values for the existing attributes or to use unicode only for non-ASCII values. The features are only enabled on unicode native versions of Windows. The three features are demonstrated at http://www.scintilla.org/pyunicode.png The patch contains some documentation additions for sys.argvu and os.environu. There are no test cases as test cases involving running extra processes can be messy and fail for uninteresting reasons. ---------------------------------------------------------------------- >Comment By: Neil Hodgson (nyamatongwe) Date: 2005-07-14 20:35 Message: Logged In: YES user_id=12579 os.environ is a dictionary and unicode keys can not be discerned from string keys. For sys.argv it appears that there is no support for the "parallel universe" approach with sys.argvu and I expect one of the "promotion" models will be chosen. The patch should be rejected (or parked?) until consensus emerges. os.system was only included to allow testing but I saw difficulties in writing robust unit tests for these features so didn't include any. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-07-12 02:42 Message: Logged In: YES user_id=21627 For os.environ, I think I would prefer a solution where Unicode keys result in Unicode values and string keys result in string values, with the canonical conversion through "mbcs" in place. For argv, I agree something should be done, but I'm not certain that the introduction of argvu is the best thing to do; this should be dicsussed on python-dev, and with all people originally involved in PEP 277. The change to system() is not mentioned at all in your message. It doesn't seem to belong into this patch, either, so please submit it as a separate patch. If system() is changed to support Unicode commands, I think spawn*() should be changed as well. These seem less debatable, as they come as natural extensions to PEP 277 (i.e. pass Unicode through to the system). ---------------------------------------------------------------------- Comment By: Neil Hodgson (nyamatongwe) Date: 2005-07-05 14:27 Message: Logged In: YES user_id=12579 Added a description to diff file. ---------------------------------------------------------------------- Comment By: Neil Hodgson (nyamatongwe) Date: 2005-07-05 14:25 Message: Logged In: YES user_id=12579 There are problems in sys.argvu as the current argument processing code removes some option arguments where these are processed by python. This can be almost fixed by storing the argc last elements into sys.argvu. However, when using [-c command], the command is removed from sys.argv as this allows the Python code to determine that it is either running with a command line command ("-c") or the name of the file. Attached patch fixes these problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231336&group_id=5470 From noreply at sourceforge.net Thu Jul 14 14:27:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jul 2005 05:27:48 -0700 Subject: [Patches] [ python-Patches-1151323 ] New fpconst module Message-ID: Patches item #1151323, was opened at 2005-02-24 20:06 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1151323&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: Gregory Warnes (warnes) Assigned to: Nobody/Anonymous (nobody) Summary: New fpconst module Initial Comment: This patch adds the 'fpconst' module, described in PEP754 to the standard python library. It includes both the source code and the documentation. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-07-14 13:27 Message: Logged In: YES user_id=6656 For Python 2.5 you should indeed be able to use the "' without success before resorting to the big_endian_ check... -Greg ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-02-25 00:25 Message: Logged In: YES user_id=139309 Is there a reason why you don't use the struct.pack endian markers? You could get rid of all the code that deals with _big_endian if you just prefixed the formats with ! or > ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1151323&group_id=5470 From noreply at sourceforge.net Thu Jul 14 20:10:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jul 2005 11:10:39 -0700 Subject: [Patches] [ python-Patches-1231336 ] Add unicode for sys.argv, os.environ, os.system Message-ID: Patches item #1231336, was opened at 2005-07-02 03:55 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231336&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: Rejected Priority: 5 Submitted By: Neil Hodgson (nyamatongwe) Assigned to: Nobody/Anonymous (nobody) Summary: Add unicode for sys.argv, os.environ, os.system Initial Comment: Most installations of Windows (2000, XP) are unicode native with narrow character APIs only providing a distorted view of the system. Python does not currently provide access to some basic features through wide character calls and so may see distorted values. This patch adds unicode compatibility for sys.argv, os.environ, and os.system. os.system accepts a unicode argument in the same way as described in PEP 277 for file APIs. For sys.argv and os.environ, new parallel unicode attributes sys.argvu and os.environu are added as it would cause too many problems to use unicode values for the existing attributes or to use unicode only for non-ASCII values. The features are only enabled on unicode native versions of Windows. The three features are demonstrated at http://www.scintilla.org/pyunicode.png The patch contains some documentation additions for sys.argvu and os.environu. There are no test cases as test cases involving running extra processes can be messy and fail for uninteresting reasons. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-07-14 20:10 Message: Logged In: YES user_id=21627 os.environ is not a dictionary, it is a UserDict.IterableUserDict. Discerning strings and Unicode object would well be possible. As you are not willing to discuss the issues on python-dev, I'm rejecting the patch. ---------------------------------------------------------------------- Comment By: Neil Hodgson (nyamatongwe) Date: 2005-07-14 12:35 Message: Logged In: YES user_id=12579 os.environ is a dictionary and unicode keys can not be discerned from string keys. For sys.argv it appears that there is no support for the "parallel universe" approach with sys.argvu and I expect one of the "promotion" models will be chosen. The patch should be rejected (or parked?) until consensus emerges. os.system was only included to allow testing but I saw difficulties in writing robust unit tests for these features so didn't include any. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-07-11 18:42 Message: Logged In: YES user_id=21627 For os.environ, I think I would prefer a solution where Unicode keys result in Unicode values and string keys result in string values, with the canonical conversion through "mbcs" in place. For argv, I agree something should be done, but I'm not certain that the introduction of argvu is the best thing to do; this should be dicsussed on python-dev, and with all people originally involved in PEP 277. The change to system() is not mentioned at all in your message. It doesn't seem to belong into this patch, either, so please submit it as a separate patch. If system() is changed to support Unicode commands, I think spawn*() should be changed as well. These seem less debatable, as they come as natural extensions to PEP 277 (i.e. pass Unicode through to the system). ---------------------------------------------------------------------- Comment By: Neil Hodgson (nyamatongwe) Date: 2005-07-05 06:27 Message: Logged In: YES user_id=12579 Added a description to diff file. ---------------------------------------------------------------------- Comment By: Neil Hodgson (nyamatongwe) Date: 2005-07-05 06:25 Message: Logged In: YES user_id=12579 There are problems in sys.argvu as the current argument processing code removes some option arguments where these are processed by python. This can be almost fixed by storing the argc last elements into sys.argvu. However, when using [-c command], the command is removed from sys.argv as this allows the Python code to determine that it is either running with a command line command ("-c") or the name of the file. Attached patch fixes these problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231336&group_id=5470 From noreply at sourceforge.net Thu Jul 14 20:33:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jul 2005 11:33:15 -0700 Subject: [Patches] [ python-Patches-1231336 ] Add unicode for sys.argv, os.environ, os.system Message-ID: Patches item #1231336, was opened at 2005-07-02 03:55 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231336&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: Rejected Priority: 5 Submitted By: Neil Hodgson (nyamatongwe) Assigned to: Nobody/Anonymous (nobody) Summary: Add unicode for sys.argv, os.environ, os.system Initial Comment: Most installations of Windows (2000, XP) are unicode native with narrow character APIs only providing a distorted view of the system. Python does not currently provide access to some basic features through wide character calls and so may see distorted values. This patch adds unicode compatibility for sys.argv, os.environ, and os.system. os.system accepts a unicode argument in the same way as described in PEP 277 for file APIs. For sys.argv and os.environ, new parallel unicode attributes sys.argvu and os.environu are added as it would cause too many problems to use unicode values for the existing attributes or to use unicode only for non-ASCII values. The features are only enabled on unicode native versions of Windows. The three features are demonstrated at http://www.scintilla.org/pyunicode.png The patch contains some documentation additions for sys.argvu and os.environu. There are no test cases as test cases involving running extra processes can be messy and fail for uninteresting reasons. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-07-14 20:33 Message: Logged In: YES user_id=38388 Just as data point: the idea of using the type of a dictionary key to determine the resulting return type is a really bad design idea - just like the idea to let functions determine their return type based on the types of their input parameters. These things should always be made explicit, e.g. os.environ.get_unicode(), sys.argv.get_unicode() etc. However, as the discussion on python-dev shows, we may not need this kind of approach at all. Cheers, Marc-Andre. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-07-14 20:10 Message: Logged In: YES user_id=21627 os.environ is not a dictionary, it is a UserDict.IterableUserDict. Discerning strings and Unicode object would well be possible. As you are not willing to discuss the issues on python-dev, I'm rejecting the patch. ---------------------------------------------------------------------- Comment By: Neil Hodgson (nyamatongwe) Date: 2005-07-14 12:35 Message: Logged In: YES user_id=12579 os.environ is a dictionary and unicode keys can not be discerned from string keys. For sys.argv it appears that there is no support for the "parallel universe" approach with sys.argvu and I expect one of the "promotion" models will be chosen. The patch should be rejected (or parked?) until consensus emerges. os.system was only included to allow testing but I saw difficulties in writing robust unit tests for these features so didn't include any. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-07-11 18:42 Message: Logged In: YES user_id=21627 For os.environ, I think I would prefer a solution where Unicode keys result in Unicode values and string keys result in string values, with the canonical conversion through "mbcs" in place. For argv, I agree something should be done, but I'm not certain that the introduction of argvu is the best thing to do; this should be dicsussed on python-dev, and with all people originally involved in PEP 277. The change to system() is not mentioned at all in your message. It doesn't seem to belong into this patch, either, so please submit it as a separate patch. If system() is changed to support Unicode commands, I think spawn*() should be changed as well. These seem less debatable, as they come as natural extensions to PEP 277 (i.e. pass Unicode through to the system). ---------------------------------------------------------------------- Comment By: Neil Hodgson (nyamatongwe) Date: 2005-07-05 06:27 Message: Logged In: YES user_id=12579 Added a description to diff file. ---------------------------------------------------------------------- Comment By: Neil Hodgson (nyamatongwe) Date: 2005-07-05 06:25 Message: Logged In: YES user_id=12579 There are problems in sys.argvu as the current argument processing code removes some option arguments where these are processed by python. This can be almost fixed by storing the argc last elements into sys.argvu. However, when using [-c command], the command is removed from sys.argv as this allows the Python code to determine that it is either running with a command line command ("-c") or the name of the file. Attached patch fixes these problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231336&group_id=5470 From noreply at sourceforge.net Fri Jul 15 02:17:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jul 2005 17:17:06 -0700 Subject: [Patches] [ python-Patches-1231336 ] Add unicode for sys.argv, os.environ, os.system Message-ID: Patches item #1231336, was opened at 2005-07-02 11:55 Message generated for change (Comment added) made by nyamatongwe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231336&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: Rejected Priority: 5 Submitted By: Neil Hodgson (nyamatongwe) Assigned to: Nobody/Anonymous (nobody) Summary: Add unicode for sys.argv, os.environ, os.system Initial Comment: Most installations of Windows (2000, XP) are unicode native with narrow character APIs only providing a distorted view of the system. Python does not currently provide access to some basic features through wide character calls and so may see distorted values. This patch adds unicode compatibility for sys.argv, os.environ, and os.system. os.system accepts a unicode argument in the same way as described in PEP 277 for file APIs. For sys.argv and os.environ, new parallel unicode attributes sys.argvu and os.environu are added as it would cause too many problems to use unicode values for the existing attributes or to use unicode only for non-ASCII values. The features are only enabled on unicode native versions of Windows. The three features are demonstrated at http://www.scintilla.org/pyunicode.png The patch contains some documentation additions for sys.argvu and os.environu. There are no test cases as test cases involving running extra processes can be messy and fail for uninteresting reasons. ---------------------------------------------------------------------- >Comment By: Neil Hodgson (nyamatongwe) Date: 2005-07-15 10:17 Message: Logged In: YES user_id=12579 I thought that posixmodule.c was creating os.environ but now see the code in os.py. "As you are not willing to discuss the issues on python-dev". Eh? I thought that was what I was doing in the "Adding the 'path' module" thread. You can reject the patch due to the discussion on python-dev but I don't think the given reason is valid. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-07-15 04:33 Message: Logged In: YES user_id=38388 Just as data point: the idea of using the type of a dictionary key to determine the resulting return type is a really bad design idea - just like the idea to let functions determine their return type based on the types of their input parameters. These things should always be made explicit, e.g. os.environ.get_unicode(), sys.argv.get_unicode() etc. However, as the discussion on python-dev shows, we may not need this kind of approach at all. Cheers, Marc-Andre. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-07-15 04:10 Message: Logged In: YES user_id=21627 os.environ is not a dictionary, it is a UserDict.IterableUserDict. Discerning strings and Unicode object would well be possible. As you are not willing to discuss the issues on python-dev, I'm rejecting the patch. ---------------------------------------------------------------------- Comment By: Neil Hodgson (nyamatongwe) Date: 2005-07-14 20:35 Message: Logged In: YES user_id=12579 os.environ is a dictionary and unicode keys can not be discerned from string keys. For sys.argv it appears that there is no support for the "parallel universe" approach with sys.argvu and I expect one of the "promotion" models will be chosen. The patch should be rejected (or parked?) until consensus emerges. os.system was only included to allow testing but I saw difficulties in writing robust unit tests for these features so didn't include any. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-07-12 02:42 Message: Logged In: YES user_id=21627 For os.environ, I think I would prefer a solution where Unicode keys result in Unicode values and string keys result in string values, with the canonical conversion through "mbcs" in place. For argv, I agree something should be done, but I'm not certain that the introduction of argvu is the best thing to do; this should be dicsussed on python-dev, and with all people originally involved in PEP 277. The change to system() is not mentioned at all in your message. It doesn't seem to belong into this patch, either, so please submit it as a separate patch. If system() is changed to support Unicode commands, I think spawn*() should be changed as well. These seem less debatable, as they come as natural extensions to PEP 277 (i.e. pass Unicode through to the system). ---------------------------------------------------------------------- Comment By: Neil Hodgson (nyamatongwe) Date: 2005-07-05 14:27 Message: Logged In: YES user_id=12579 Added a description to diff file. ---------------------------------------------------------------------- Comment By: Neil Hodgson (nyamatongwe) Date: 2005-07-05 14:25 Message: Logged In: YES user_id=12579 There are problems in sys.argvu as the current argument processing code removes some option arguments where these are processed by python. This can be almost fixed by storing the argc last elements into sys.argvu. However, when using [-c command], the command is removed from sys.argv as this allows the Python code to determine that it is either running with a command line command ("-c") or the name of the file. Attached patch fixes these problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231336&group_id=5470 From noreply at sourceforge.net Fri Jul 15 07:17:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jul 2005 22:17:59 -0700 Subject: [Patches] [ python-Patches-1231336 ] Add unicode for sys.argv, os.environ, os.system Message-ID: Patches item #1231336, was opened at 2005-07-02 03:55 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231336&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: Neil Hodgson (nyamatongwe) Assigned to: Nobody/Anonymous (nobody) Summary: Add unicode for sys.argv, os.environ, os.system Initial Comment: Most installations of Windows (2000, XP) are unicode native with narrow character APIs only providing a distorted view of the system. Python does not currently provide access to some basic features through wide character calls and so may see distorted values. This patch adds unicode compatibility for sys.argv, os.environ, and os.system. os.system accepts a unicode argument in the same way as described in PEP 277 for file APIs. For sys.argv and os.environ, new parallel unicode attributes sys.argvu and os.environu are added as it would cause too many problems to use unicode values for the existing attributes or to use unicode only for non-ASCII values. The features are only enabled on unicode native versions of Windows. The three features are demonstrated at http://www.scintilla.org/pyunicode.png The patch contains some documentation additions for sys.argvu and os.environu. There are no test cases as test cases involving running extra processes can be messy and fail for uninteresting reasons. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-07-15 07:17 Message: Logged In: YES user_id=21627 Sorry, I missed the discussion; reopening. ---------------------------------------------------------------------- Comment By: Neil Hodgson (nyamatongwe) Date: 2005-07-15 02:17 Message: Logged In: YES user_id=12579 I thought that posixmodule.c was creating os.environ but now see the code in os.py. "As you are not willing to discuss the issues on python-dev". Eh? I thought that was what I was doing in the "Adding the 'path' module" thread. You can reject the patch due to the discussion on python-dev but I don't think the given reason is valid. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-07-14 20:33 Message: Logged In: YES user_id=38388 Just as data point: the idea of using the type of a dictionary key to determine the resulting return type is a really bad design idea - just like the idea to let functions determine their return type based on the types of their input parameters. These things should always be made explicit, e.g. os.environ.get_unicode(), sys.argv.get_unicode() etc. However, as the discussion on python-dev shows, we may not need this kind of approach at all. Cheers, Marc-Andre. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-07-14 20:10 Message: Logged In: YES user_id=21627 os.environ is not a dictionary, it is a UserDict.IterableUserDict. Discerning strings and Unicode object would well be possible. As you are not willing to discuss the issues on python-dev, I'm rejecting the patch. ---------------------------------------------------------------------- Comment By: Neil Hodgson (nyamatongwe) Date: 2005-07-14 12:35 Message: Logged In: YES user_id=12579 os.environ is a dictionary and unicode keys can not be discerned from string keys. For sys.argv it appears that there is no support for the "parallel universe" approach with sys.argvu and I expect one of the "promotion" models will be chosen. The patch should be rejected (or parked?) until consensus emerges. os.system was only included to allow testing but I saw difficulties in writing robust unit tests for these features so didn't include any. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-07-11 18:42 Message: Logged In: YES user_id=21627 For os.environ, I think I would prefer a solution where Unicode keys result in Unicode values and string keys result in string values, with the canonical conversion through "mbcs" in place. For argv, I agree something should be done, but I'm not certain that the introduction of argvu is the best thing to do; this should be dicsussed on python-dev, and with all people originally involved in PEP 277. The change to system() is not mentioned at all in your message. It doesn't seem to belong into this patch, either, so please submit it as a separate patch. If system() is changed to support Unicode commands, I think spawn*() should be changed as well. These seem less debatable, as they come as natural extensions to PEP 277 (i.e. pass Unicode through to the system). ---------------------------------------------------------------------- Comment By: Neil Hodgson (nyamatongwe) Date: 2005-07-05 06:27 Message: Logged In: YES user_id=12579 Added a description to diff file. ---------------------------------------------------------------------- Comment By: Neil Hodgson (nyamatongwe) Date: 2005-07-05 06:25 Message: Logged In: YES user_id=12579 There are problems in sys.argvu as the current argument processing code removes some option arguments where these are processed by python. This can be almost fixed by storing the argc last elements into sys.argvu. However, when using [-c command], the command is removed from sys.argv as this allows the Python code to determine that it is either running with a command line command ("-c") or the name of the file. Attached patch fixes these problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1231336&group_id=5470 From noreply at sourceforge.net Fri Jul 15 08:54:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jul 2005 23:54:43 -0700 Subject: [Patches] [ python-Patches-1209527 ] Optimization for textwrap Message-ID: Patches item #1209527, was opened at 2005-05-26 18:09 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1209527&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: Connelly (connelly) Assigned to: Raymond Hettinger (rhettinger) Summary: Optimization for textwrap Initial Comment: This patch speeds up the textwrap module, so that it takes O(n) time to process n chunks rather than the O(n^2) time that textwrap previously took. This makes textwrap much faster for large texts (for example, the patched version runs textwrap.fill('foo' * 100000) 80 times faster than the unpatched version). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-15 01:54 Message: Logged In: YES user_id=80475 Applied as Lib/textwrap.py 1.38. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-09 06:15 Message: Logged In: YES user_id=1188172 I've applied the original patch, ensured the test suite ran and measured the same speedup as Connelly. Looks like a sound addition. Another option is, as he said, using collections.deque or an substitute class for compatibility. ---------------------------------------------------------------------- Comment By: Connelly (connelly) Date: 2005-07-08 18:49 Message: Logged In: YES user_id=1039782 Personally, I need linear running time for this module, so I contributed the patch in the hope that others would find it useful. The practical result is that parsing a 5 MB unwrapped text file takes an order of seconds with the patch, and > 10 minutes without the patch (3 GHz Pentium). If the code is written with a deque or queue, there would be a similar speed incease, since deque operations are O(1). Is the patch not 'clean enough' code-wide? (I could recode it to use collections.deque or else a simple dummy queue if collections is not available). ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-06-03 08:49 Message: Logged In: YES user_id=2772 I didn't benchmark the speed increase, but I verified that on my system 'test_textwrap.py' still completes successfully. I also looked at the patch and found the change to be straightforward. However, I wonder if the speed increase would be nearly as great if collections.deque was used instead of the reversed list. Unfortunately, the textwrap module seems to intend portability with older versions of Python, which would not work if the collections module is used. ---------------------------------------------------------------------- Comment By: Connelly (connelly) Date: 2005-05-27 11:37 Message: Logged In: YES user_id=1039782 I assign the Copyright for this patch to the Python Software Foundation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1209527&group_id=5470 From noreply at sourceforge.net Fri Jul 15 09:26:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jul 2005 00:26:14 -0700 Subject: [Patches] [ python-Patches-1229239 ] optionally allow mutable builtin types Message-ID: Patches item #1229239, was opened at 2005-06-28 11:57 Message generated for change (Comment added) made by gregcouch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1229239&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: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: optionally allow mutable builtin types Initial Comment: Non-heap types, aka builtin types, cannot have their attributes changed by Python code -- see Objects/typeobject.c: type_setattro(). This limitation is good for Python's core builtin types (int, float, list, dict, ...), but not necessarily for non-heap types in extension modules. The attached patch allows for non-heap types to mutate iff the Py_TPFLAGS_MUTABLE_BUILTIN flag is set. ---------------------------------------------------------------------- >Comment By: Greg Couch (gregcouch) Date: 2005-07-15 00:26 Message: Logged In: YES user_id=131838 One reason that the type wasn't a heap type was because I didn't find an example in the Python documentation. And because when I was looking through typeobject.c, I saw code, like type_get_doc(), that ignores the (tp_doc) slot when it is a heap type -- exactly what I don't want (looking closer, it may be the only one). I also like most of the restrictions a non-heap type has, like being unable to change its name. So if heap types are as fast as non-heap types, then I have no objection to switching. I'm also concerned about the additional startup time switching to heap types would cost since I currently have 75 types in my module. The python code that prompted this patch was code that reached in and added extra keyword arguments to a method, sort of like a decorator, for additional bookkeeping. Subclassing is out because the C (C++) object factory function only returns the instances of the original type. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-07-11 09:44 Message: Logged In: YES user_id=21627 Why can't you create such a type as a heap type? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1229239&group_id=5470 From noreply at sourceforge.net Fri Jul 15 10:51:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jul 2005 01:51:47 -0700 Subject: [Patches] [ python-Patches-1062060 ] fix for 1016880 urllib.urlretrieve silently truncates dwnld Message-ID: Patches item #1062060, was opened at 2004-11-07 21:15 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062060&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: 6 Submitted By: Irmen de Jong (irmen) >Assigned to: Raymond Hettinger (rhettinger) Summary: fix for 1016880 urllib.urlretrieve silently truncates dwnld Initial Comment: The patch makes urllib.urlretrieve raise an IOError if the actual download size is different from the expected size (taken from the content-length header). ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-15 10:51 Message: Logged In: YES user_id=1188172 Attaching new patch which implements Martin's suggestion (urllib-truncate.diff). Please review. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-24 22:07 Message: Logged In: YES user_id=21627 I think the patch is essentially right. However, I'm concerned with losing the data that got just downloaded - I propose to stick them into the IOError (or, better, subclass IOError to keep the data, and document where to find them). ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-12-24 15:30 Message: Logged In: YES user_id=129426 Suggested addition to the doc of urllib (liburllib.tex, if I'm not mistaken): """ urlretrieve will raise IOError when it detects that the amount of data available was less than the expected amount (which is the size reported by a Content-Length header). This can occur, for example, when the download is interrupted. The Content-Length is treated as a lower bound (just like tools such as wget and Ffirefox appear to do): if there's more data to read, urlretrieve reads more data, but if less data is available, it raises IOError. If no Content-Length header was supplied, urlretrieve can not check the size of the data it has downloaded, and just returns it. In this case you just have to assume that the download was successful. """ ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-12-24 15:10 Message: Logged In: YES user_id=129426 Yes I'm having trouble building the docs from source, so I will just add the text that I would like to change in the docs. When I have some time left (it's Christmas after all :) ) I'll also create a regression test for the new behavior. In the meantime, the "urllib.patch" may be deleted because "urllib.patch2" is the correct patch (I seem to be unable to delete the attachment myself) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-21 01:00 Message: Logged In: YES user_id=80475 Irmin, please attach the new patch. If you're having trouble with the docs, that's fine, just include the text you want changed. Do include tests with your patch. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-12-06 22:48 Message: Logged In: YES user_id=469548 Sorry Irmen, I'm a bit late with this, but now is the time to get new "features" checked into the trunk. Could you add a doc patch that explains the behavior as you did in your previous message and a tests patch? I can check it in then. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-11-07 21:54 Message: Logged In: YES user_id=129426 NOTE: urllib.patch2 may be a bit better. It fixes a misspelling, and also is more relaxed about a 'wrong' download size. To be more precise: it treats content-length as a lower bound (just like wget and firefox appear to do). So if there's more data to read, it reads more data, but if less data is available, it gives an IOError ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1062060&group_id=5470 From noreply at sourceforge.net Fri Jul 15 11:17:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jul 2005 02:17:08 -0700 Subject: [Patches] [ python-Patches-1196903 ] smarter behaviour for home key in IDLE Message-ID: Patches item #1196903, was opened at 2005-05-06 16:33 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196903&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: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Shute (jshute) >Assigned to: Kurt B. Kaiser (kbk) Summary: smarter behaviour for home key in IDLE Initial Comment: This patch modifies IDLE to have behaviour similar to other IDEs when you press home. Pressing ones takes you to the start of text on the line (skipping whitespace or the prompt characters). Pressing home again toggles between that position and the absolute start of the line. There was already some code in PyShell.py that attempted to do part of this for the prompt characters, but it did not work. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-15 04:17 Message: Logged In: YES user_id=80475 Hmm, the toggling part is not that common or intuitive. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1196903&group_id=5470 From noreply at sourceforge.net Fri Jul 15 21:26:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jul 2005 12:26:36 -0700 Subject: [Patches] [ python-Patches-1239112 ] Fix LINKCC (Bug #1189330) Message-ID: Patches item #1239112, was opened at 2005-07-15 21:26 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=1239112&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Christoph Ludwig (cludwig) Assigned to: Nobody/Anonymous (nobody) Summary: Fix LINKCC (Bug #1189330) Initial Comment: A build of Python 2.4.1 on a i686-pc-linux-gnu system with GCC 4.0 failed. configure set `LINKCC=$(PURIFY) $(CC) ' even though main() was compiled with g++ and you cannot lin C++ object files with the C compiler on this platform (Bug #1189330). There was some discussion on python-dev that on some platforms (notably Linux/ELF) the C++ compiler is unnecessarily used to build Python which makes the python executable depend on this particular compiler version's C++ runtime library. This patch does *not* address this issue; it keeps the criticized behaviour but fixes configure.in such that make does not fail anymore on above mentioned platform. (I will try to come up in the next weeks with a patch for the main trunk that addresses the - on some platforms - needless dependency on the C++ runtime.) In 2.4.1, configure compiled a single source file with the C++ compiler and tries to link it with the C compiler. Apparently the improved optimizer of GCC 4.0 realized that in this simple test program all symbols from the C++ runtime could be omitted whence linking with the C compiler succeeded. The new test generates two source files that more closely resemble the situation with ccpython.cc: main() calls a C function in another translation unit. main() is compiled with the C++ compiler, the C function with the C compiler. Only if the resulting object files can be linked into an executable by the C compiler then configure sets 'LINKCC=$(PURIFY) $(CC)'. I tested the patch with GCC 4.0 and GCC 2.95.2 on i686-pc-linux-gnu. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1239112&group_id=5470 From noreply at sourceforge.net Sat Jul 16 04:14:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jul 2005 19:14:58 -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-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 Jul 17 21:42:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jul 2005 12:42:09 -0700 Subject: [Patches] [ python-Patches-1239890 ] Prevent race condition in os.makedirs Message-ID: Patches item #1239890, was opened at 2005-07-17 22:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1239890&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: Nir Soffer (nirs) Assigned to: Nobody/Anonymous (nobody) Summary: Prevent race condition in os.makedirs Initial Comment: makedirs check if a directory exists, and call mkdir to create it. In rare cases, the directory might have been created by another process or thread in the time passed from the exists() call to the mkdir() call. To prevent this rare race condition, use try: expect: to create the directory, then ignore "File exists" errors, which mean the directory was there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1239890&group_id=5470 From noreply at sourceforge.net Sun Jul 17 21:57:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jul 2005 12:57:13 -0700 Subject: [Patches] [ python-Patches-1239890 ] Prevent race condition in os.makedirs Message-ID: Patches item #1239890, was opened at 2005-07-17 21:42 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1239890&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: Nir Soffer (nirs) Assigned to: Nobody/Anonymous (nobody) Summary: Prevent race condition in os.makedirs Initial Comment: makedirs check if a directory exists, and call mkdir to create it. In rare cases, the directory might have been created by another process or thread in the time passed from the exists() call to the mkdir() call. To prevent this rare race condition, use try: expect: to create the directory, then ignore "File exists" errors, which mean the directory was there. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 21:57 Message: Logged In: YES user_id=1188172 See bug #1223238. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1239890&group_id=5470 From noreply at sourceforge.net Sun Jul 17 22:06:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jul 2005 13:06:51 -0700 Subject: [Patches] [ python-Patches-1239890 ] Prevent race condition in os.makedirs Message-ID: Patches item #1239890, was opened at 2005-07-17 22:42 Message generated for change (Comment added) made by nirs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1239890&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: Nir Soffer (nirs) Assigned to: Nobody/Anonymous (nobody) Summary: Prevent race condition in os.makedirs Initial Comment: makedirs check if a directory exists, and call mkdir to create it. In rare cases, the directory might have been created by another process or thread in the time passed from the exists() call to the mkdir() call. To prevent this rare race condition, use try: expect: to create the directory, then ignore "File exists" errors, which mean the directory was there. ---------------------------------------------------------------------- >Comment By: Nir Soffer (nirs) Date: 2005-07-17 23:06 Message: Logged In: YES user_id=832344 I can't find such bug or patch. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 22:57 Message: Logged In: YES user_id=1188172 See bug #1223238. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1239890&group_id=5470 From noreply at sourceforge.net Sun Jul 17 22:13:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jul 2005 13:13:13 -0700 Subject: [Patches] [ python-Patches-1239890 ] Prevent race condition in os.makedirs Message-ID: Patches item #1239890, was opened at 2005-07-17 21:42 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1239890&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: Nir Soffer (nirs) Assigned to: Nobody/Anonymous (nobody) Summary: Prevent race condition in os.makedirs Initial Comment: makedirs check if a directory exists, and call mkdir to create it. In rare cases, the directory might have been created by another process or thread in the time passed from the exists() call to the mkdir() call. To prevent this rare race condition, use try: expect: to create the directory, then ignore "File exists" errors, which mean the directory was there. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 22:13 Message: Logged In: YES user_id=1188172 http://sourceforge.net/tracker/index.php?func=detail&aid=1223238&group_id=5470&atid=105470 ---------------------------------------------------------------------- Comment By: Nir Soffer (nirs) Date: 2005-07-17 22:06 Message: Logged In: YES user_id=832344 I can't find such bug or patch. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 21:57 Message: Logged In: YES user_id=1188172 See bug #1223238. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1239890&group_id=5470 From noreply at sourceforge.net Sun Jul 17 23:13:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jul 2005 14:13:36 -0700 Subject: [Patches] [ python-Patches-1239890 ] Prevent race condition in os.makedirs Message-ID: Patches item #1239890, was opened at 2005-07-17 22:42 Message generated for change (Comment added) made by nirs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1239890&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: Nir Soffer (nirs) Assigned to: Nobody/Anonymous (nobody) Summary: Prevent race condition in os.makedirs Initial Comment: makedirs check if a directory exists, and call mkdir to create it. In rare cases, the directory might have been created by another process or thread in the time passed from the exists() call to the mkdir() call. To prevent this rare race condition, use try: expect: to create the directory, then ignore "File exists" errors, which mean the directory was there. ---------------------------------------------------------------------- >Comment By: Nir Soffer (nirs) Date: 2005-07-18 00:13 Message: Logged In: YES user_id=832344 Here is another patch, using simpler design, maybe for 2.5? The attached patch will try once to create each leaf in the path, ignoring existing leafs. This should work for most cases. If one run application that can delete its own directories, he should use proper locking. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 23:13 Message: Logged In: YES user_id=1188172 http://sourceforge.net/tracker/index.php?func=detail&aid=1223238&group_id=5470&atid=105470 ---------------------------------------------------------------------- Comment By: Nir Soffer (nirs) Date: 2005-07-17 23:06 Message: Logged In: YES user_id=832344 I can't find such bug or patch. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 22:57 Message: Logged In: YES user_id=1188172 See bug #1223238. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1239890&group_id=5470 From noreply at sourceforge.net Mon Jul 18 21:34:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Jul 2005 12:34:22 -0700 Subject: [Patches] [ python-Patches-900744 ] catch invalid chunk length in httplib read routine Message-ID: Patches item #900744, was opened at 2004-02-20 00:14 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=900744&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: Wummel (calvin) >Assigned to: Raymond Hettinger (rhettinger) Summary: catch invalid chunk length in httplib read routine Initial Comment: In HTTPResponse._read_chunked the chunk length is not checked to be a valid integer, and a ValueError will be raised in such a case. The attached patch catches ValueError (which should not normally happen, so this try:except: is reasonably fast), and raises IncompleteRead exception instead. I have no test case for this yet, but am trying to construct one :) ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-18 21:34 Message: Logged In: YES user_id=1188172 Attaching patch which does what agwego said (httplib-chunked.diff). Please review. ---------------------------------------------------------------------- Comment By: agwego (agwego) Date: 2005-02-28 17:53 Message: Logged In: YES user_id=1228982 I've run into this problem in conjunction with mod_python 3.1.4 (and although the problem is caused in mod_python) my python skills aren't up to the task. Which leaves me with fixing httplib. Although the above patch works when it comes to end of file situations, I think it would be better to return what has been consumed so far and leave it at that. A few lines down there's a comment about consuming trailers, this is the case that is tripping up httplib as far as I can tell. This is happening in Python 2.3.4. --- packages/Python-2.3.4/Lib/httplib.py Sun Nov 2 11:51:38 2003 +++ httplib.py Mon Feb 28 11:26:48 2005 @@ -423,7 +423,11 @@ i = line.find(';') if i >= 0: line = line[:i] # strip chunk-extensions - chunk_left = int(line, 16) + try: + chunk_left = int(line, 16) + except ValueError, msg: + self.close() + return value if chunk_left == 0: break if amt is None: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=900744&group_id=5470 From noreply at sourceforge.net Tue Jul 19 03:07:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Jul 2005 18:07:51 -0700 Subject: [Patches] [ python-Patches-900744 ] catch invalid chunk length in httplib read routine Message-ID: Patches item #900744, was opened at 2004-02-19 18:14 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=900744&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: Wummel (calvin) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: catch invalid chunk length in httplib read routine Initial Comment: In HTTPResponse._read_chunked the chunk length is not checked to be a valid integer, and a ValueError will be raised in such a case. The attached patch catches ValueError (which should not normally happen, so this try:except: is reasonably fast), and raises IncompleteRead exception instead. I have no test case for this yet, but am trying to construct one :) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-18 20:07 Message: Logged In: YES user_id=80475 Technically, the patch is fine and it is the way the code should have been written in the first place. Please bring-up on python-dev to determine whether it should be done. I can imagine that a fair amount of existing code has through trial and error discovered the ValueError and chosen to catch that. Changing the exception may unnecessarily break people's code. Sometimes we take that step when it needs to be done, but there should be a good pay-off and, in this case, I don't see it. You may also want to mention it on comp.lang.python to see if anyone cares If the patch goes forward, see if you can mock-up a test that triggers the exception so we have a good unittest. In anycase, this should not be backported (we avoid giving people reasons to not upgrade). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-18 14:34 Message: Logged In: YES user_id=1188172 Attaching patch which does what agwego said (httplib-chunked.diff). Please review. ---------------------------------------------------------------------- Comment By: agwego (agwego) Date: 2005-02-28 11:53 Message: Logged In: YES user_id=1228982 I've run into this problem in conjunction with mod_python 3.1.4 (and although the problem is caused in mod_python) my python skills aren't up to the task. Which leaves me with fixing httplib. Although the above patch works when it comes to end of file situations, I think it would be better to return what has been consumed so far and leave it at that. A few lines down there's a comment about consuming trailers, this is the case that is tripping up httplib as far as I can tell. This is happening in Python 2.3.4. --- packages/Python-2.3.4/Lib/httplib.py Sun Nov 2 11:51:38 2003 +++ httplib.py Mon Feb 28 11:26:48 2005 @@ -423,7 +423,11 @@ i = line.find(';') if i >= 0: line = line[:i] # strip chunk-extensions - chunk_left = int(line, 16) + try: + chunk_left = int(line, 16) + except ValueError, msg: + self.close() + return value if chunk_left == 0: break if amt is None: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=900744&group_id=5470 From noreply at sourceforge.net Tue Jul 19 04:25:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Jul 2005 19:25:19 -0700 Subject: [Patches] [ python-Patches-1240614 ] release lock on exception in threading.Thread.join() Message-ID: Patches item #1240614, was opened at 2005-07-18 19: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=1240614&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: Dirk Groeneveld (marvinalone) Assigned to: Nobody/Anonymous (nobody) Summary: release lock on exception in threading.Thread.join() Initial Comment: If an exception happens in threading.Thread.join(), the lock self.__block never gets released. The next time Thread.join() is called, it blocks forever. The only exception I can think of right now that triggers this error is KeyboardInterrupt, but there might be more. The patch puts everything between self.__block.acquire() and self.__block.release() into a try ... finally block, and releases the lock in the finally clause. A transcript of the error follows: >>> import threading >>> def f(): ... while True: ... pass ... >>> t = threading.Thread(target = f) >>> t.setDaemon(True) >>> def j(t): ... while True: ... print "trying to join" ... t.join(1) ... >>> t.start() >>> j(t) trying to join trying to join trying to join Traceback (most recent call last): File "", line 1, in ? File "", line 4, in j File "/usr/lib/python2.4/threading.py", line 550, in join self.__block.wait(delay) File "/usr/lib/python2.4/threading.py", line 222, in wait _sleep(delay) KeyboardInterrupt >>> j(t) trying to join ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1240614&group_id=5470 From noreply at sourceforge.net Wed Jul 20 19:49:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Jul 2005 10:49:21 -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: Open Resolution: None 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-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 Paddyclarkson at aol.com Wed Jul 20 23:17:44 2005 From: Paddyclarkson at aol.com (Paddyclarkson@aol.com) Date: Wed, 20 Jul 2005 17:17:44 EDT Subject: [Patches] 78.BZM. Stay hard with Cialis Message-ID: <127.60824d3d.30101978@aol.com> Please e-mail me with some information -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20050720/a9590d49/attachment.htm From noreply at sourceforge.net Thu Jul 21 19:24:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Jul 2005 10:24:16 -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 12:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=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: Open Resolution: None 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. . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1242454&group_id=5470 From noreply at sourceforge.net Thu Jul 21 22:12:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Jul 2005 13:12:13 -0700 Subject: [Patches] [ python-Patches-1242579 ] bltinmodule.c whitespace normalization Message-ID: Patches item #1242579, was opened at 2005-07-21 23:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=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: Open Resolution: None Priority: 5 Submitted By: Ruslan Spivak (alienoid) Assigned to: Nobody/Anonymous (nobody) Summary: bltinmodule.c whitespace normalization Initial Comment: bltinmodule.c whitespace normalization ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1242579&group_id=5470 From noreply at sourceforge.net Fri Jul 22 03:55:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Jul 2005 18:55:52 -0700 Subject: [Patches] [ python-Patches-1204347 ] optparse documentation bug fixes Message-ID: Patches item #1204347, was opened at 2005-05-18 11:11 Message generated for change (Comment added) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1204347&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: Barry A. Warsaw (bwarsaw) Assigned to: Greg Ward (gward) Summary: optparse documentation bug fixes Initial Comment: I would have checked these minor fixes to typos in the optparse documentation myself, but I vaguely recall that the docs in Python are derived from some upstream source. If that isn't the case, re-assign to me and I'll check the fixes in. ---------------------------------------------------------------------- >Comment By: Greg Ward (gward) Date: 2005-07-21 21:55 Message: Logged In: YES user_id=14422 Thanks Barry! Fixed in rev 505 in the Optik subversion repository, and in rev 1.18.2.6 of Doc/lib/liboptparse.tex (2.4 branch). Not fixed on Python trunk -- hopefully I'll regenerate optparse from Optik before 2.5 is released. ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1204347&group_id=5470 From noreply at sourceforge.net Fri Jul 22 09:12:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Jul 2005 00:12:55 -0700 Subject: [Patches] [ python-Patches-1240614 ] release lock on exception in threading.Thread.join() Message-ID: Patches item #1240614, was opened at 2005-07-18 19:25 Message generated for change (Comment added) made by marvinalone You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1240614&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: Dirk Groeneveld (marvinalone) Assigned to: Nobody/Anonymous (nobody) Summary: release lock on exception in threading.Thread.join() Initial Comment: If an exception happens in threading.Thread.join(), the lock self.__block never gets released. The next time Thread.join() is called, it blocks forever. The only exception I can think of right now that triggers this error is KeyboardInterrupt, but there might be more. The patch puts everything between self.__block.acquire() and self.__block.release() into a try ... finally block, and releases the lock in the finally clause. A transcript of the error follows: >>> import threading >>> def f(): ... while True: ... pass ... >>> t = threading.Thread(target = f) >>> t.setDaemon(True) >>> def j(t): ... while True: ... print "trying to join" ... t.join(1) ... >>> t.start() >>> j(t) trying to join trying to join trying to join Traceback (most recent call last): File "", line 1, in ? File "", line 4, in j File "/usr/lib/python2.4/threading.py", line 550, in join self.__block.wait(delay) File "/usr/lib/python2.4/threading.py", line 222, in wait _sleep(delay) KeyboardInterrupt >>> j(t) trying to join ---------------------------------------------------------------------- >Comment By: Dirk Groeneveld (marvinalone) Date: 2005-07-22 00:12 Message: Logged In: YES user_id=146647 The (a?) corresponding bug report is #1171023, at http://www.python.org/sf/1171023. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1240614&group_id=5470 From noreply at sourceforge.net Fri Jul 22 16:18:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Jul 2005 07:18:10 -0700 Subject: [Patches] [ python-Patches-1243081 ] repair typos Message-ID: Patches item #1243081, was opened at 2005-07-22 23: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=1243081&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: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: repair typos Initial Comment: This patch fixes a bunch of typos. - Doc/lib/libsets.tex The built-in versions do not have a _repr(sort=True) method sort -> sorted. Refer to Lib/sets.py. - Doc/lib/libsets.tex because it the one supported by the builtin set() and frozenset() types. because it *is* the one ... - Doc/whatsnew/whatsnew25.tex a \method{extractall()} method that extracts an \method{extractall()} ... - compatability -> compatibility Yes, google has 663000 hits of compatability, but at least in the Python documentation, compatibility is used about 100 times more frequently than compatability, so this change will make the wording more consistent. Many files are affected. Attached a patch for CVS HEAD and release24-maint. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1243081&group_id=5470 From noreply at sourceforge.net Fri Jul 22 17:39:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Jul 2005 08:39:49 -0700 Subject: [Patches] [ python-Patches-1243081 ] repair typos Message-ID: Patches item #1243081, was opened at 2005-07-22 09:18 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1243081&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: Open >Resolution: Accepted Priority: 5 Submitted By: George Yoshida (quiver) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: repair typos Initial Comment: This patch fixes a bunch of typos. - Doc/lib/libsets.tex The built-in versions do not have a _repr(sort=True) method sort -> sorted. Refer to Lib/sets.py. - Doc/lib/libsets.tex because it the one supported by the builtin set() and frozenset() types. because it *is* the one ... - Doc/whatsnew/whatsnew25.tex a \method{extractall()} method that extracts an \method{extractall()} ... - compatability -> compatibility Yes, google has 663000 hits of compatability, but at least in the Python documentation, compatibility is used about 100 times more frequently than compatability, so this change will make the wording more consistent. Many files are affected. Attached a patch for CVS HEAD and release24-maint. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1243081&group_id=5470 From noreply at sourceforge.net Fri Jul 22 20:41:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Jul 2005 11:41:36 -0700 Subject: [Patches] [ python-Patches-1243081 ] repair typos Message-ID: Patches item #1243081, was opened at 2005-07-22 16:18 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1243081&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: George Yoshida (quiver) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: repair typos Initial Comment: This patch fixes a bunch of typos. - Doc/lib/libsets.tex The built-in versions do not have a _repr(sort=True) method sort -> sorted. Refer to Lib/sets.py. - Doc/lib/libsets.tex because it the one supported by the builtin set() and frozenset() types. because it *is* the one ... - Doc/whatsnew/whatsnew25.tex a \method{extractall()} method that extracts an \method{extractall()} ... - compatability -> compatibility Yes, google has 663000 hits of compatability, but at least in the Python documentation, compatibility is used about 100 times more frequently than compatability, so this change will make the wording more consistent. Many files are affected. Attached a patch for CVS HEAD and release24-maint. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-22 20:41 Message: Logged In: YES user_id=1188172 Done! Checking in Modules/cjkcodecs/_codecs_jp.c; new revision: 1.2; previous revision: 1.1 Checking in Misc/NEWS; new revision: 1.1321; previous revision: 1.1320 Checking in Lib/plat-mac/macostools.py; new revision: 1.5; previous revision: 1.4 Checking in Lib/plat-mac/aetypes.py; new revision: 1.8; previous revision: 1.7 Checking in Lib/idlelib/ChangeLog; new revision: 1.6; previous revision: 1.5 Checking in Include/objimpl.h; new revision: 2.61; previous revision: 2.60 Checking in Doc/lib/libsets.tex; new revision: 1.19; previous revision: 1.18 Checking in Doc/lib/libfuncs.tex; new revision: 1.185; previous revision: 1.184 Checking in Doc/whatsnew/whatsnew25.tex; new revision: 1.14; previous revision: 1.13 Checking in Modules/cjkcodecs/_codecs_jp.c; new revision: 1.1.4.1; previous revision: 1.1 Checking in Misc/NEWS; new revision: 1.1193.2.65; previous revision: 1.1193.2.64 Checking in Lib/plat-mac/macostools.py; new revision: 1.4.4.1; previous revision: 1.4 Checking in Lib/plat-mac/aetypes.py; new revision: 1.7.4.1; previous revision: 1.7 Checking in Lib/idlelib/ChangeLog; new revision: 1.5.12.1; previous revision: 1.5 Checking in Include/objimpl.h; new revision: 2.60.4.1; previous revision: 2.60 Checking in Doc/lib/libsets.tex; new revision: 1.15.4.4; previous revision: 1.15.4.3 Checking in Doc/lib/libfuncs.tex; new revision: 1.175.2.5; previous revision: 1.175.2.4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1243081&group_id=5470 From noreply at sourceforge.net Sat Jul 23 04:41:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Jul 2005 19:41:32 -0700 Subject: [Patches] [ python-Patches-1048075 ] fileinput.py fixed clobbering behavior and added encodings Message-ID: Patches item #1048075, was opened at 2004-10-15 18:14 Message generated for change (Settings changed) made by cconnett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1048075&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: Out of Date Priority: 5 Submitted By: Chris Connett (cconnett) Assigned to: Nobody/Anonymous (nobody) Summary: fileinput.py fixed clobbering behavior and added encodings Initial Comment: Fixed behavior of inplace modification without a specified backup extension. No longer clobbers innocent files. Added file encoding support. Note that universal newlines functionality depends entirely on the implementation of readlines() in the StreamReader class for the specified codec. Updated docs and testcases, too. ---------------------------------------------------------------------- >Comment By: Chris Connett (cconnett) Date: 2005-07-22 22:41 Message: Logged In: YES user_id=1140166 I'm withdrawing this: it's out of date, and I mixed in a feature change with a bug fix (shame on me), and it's an undiscussed feature as well (double shame). On top of it all, I submitted it just as a patch without an associated bug report (three strikes, I'm out). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1048075&group_id=5470 From noreply at sourceforge.net Sat Jul 23 19:04:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Jul 2005 10:04:08 -0700 Subject: [Patches] [ python-Patches-1243654 ] Faster output if message already has a boundary Message-ID: Patches item #1243654, was opened at 2005-07-23 10:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1243654&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: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: Faster output if message already has a boundary Initial Comment: A simple change speeds up Message.as_string by more than a factor of 2 if the message already has a defined boundary, by avoiding a time-consuming RE compilation and search. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1243654&group_id=5470 From noreply at sourceforge.net Sat Jul 23 19:04:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Jul 2005 10:04:36 -0700 Subject: [Patches] [ python-Patches-1243654 ] Faster output if message already has a boundary Message-ID: Patches item #1243654, was opened at 2005-07-23 10:04 Message generated for change (Settings changed) made by lpd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1243654&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: L. Peter Deutsch (lpd) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Faster output if message already has a boundary Initial Comment: A simple change speeds up Message.as_string by more than a factor of 2 if the message already has a defined boundary, by avoiding a time-consuming RE compilation and search. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1243654&group_id=5470 From noreply at sourceforge.net Sat Jul 23 20:51:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Jul 2005 11:51:28 -0700 Subject: [Patches] [ python-Patches-1243678 ] httplib gzip support Message-ID: Patches item #1243678, was opened at 2005-07-23 18: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=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) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1243678&group_id=5470 From noreply at sourceforge.net Sat Jul 23 20:54:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Jul 2005 11:54:14 -0700 Subject: [Patches] [ python-Patches-1243678 ] httplib gzip support Message-ID: Patches item #1243678, was opened at 2005-07-23 18:51 Message generated for change (Comment added) made by mooonz 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: Moonz (mooonz) Date: 2005-07-23 18:54 Message: Logged In: YES user_id=826215 It's better with the patch ;) ---------------------------------------------------------------------- Comment By: Moonz (mooonz) Date: 2005-07-23 18: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 Sun Jul 24 00:07:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Jul 2005 15:07:37 -0700 Subject: [Patches] [ python-Patches-1243730 ] Big speedup in email message parsing Message-ID: Patches item #1243730, was opened at 2005-07-23 15:07 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=1243730&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: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: Big speedup in email message parsing Initial Comment: Python 2.4.1, Red Hat Linux 7.3. Speeds up message parsing on files with large attachments by approximately 4x, mostly by replacing REs by direct string processing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1243730&group_id=5470 From noreply at sourceforge.net Sun Jul 24 00:08:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Jul 2005 15:08:22 -0700 Subject: [Patches] [ python-Patches-1243730 ] Big speedup in email message parsing Message-ID: Patches item #1243730, was opened at 2005-07-23 15:07 Message generated for change (Settings changed) made by lpd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1243730&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: L. Peter Deutsch (lpd) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Big speedup in email message parsing Initial Comment: Python 2.4.1, Red Hat Linux 7.3. Speeds up message parsing on files with large attachments by approximately 4x, mostly by replacing REs by direct string processing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1243730&group_id=5470 From noreply at sourceforge.net Sun Jul 24 00:08:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Jul 2005 15:08:57 -0700 Subject: [Patches] [ python-Patches-1243654 ] Faster output if message already has a boundary Message-ID: Patches item #1243654, was opened at 2005-07-23 10:04 Message generated for change (Comment added) made by lpd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1243654&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: L. Peter Deutsch (lpd) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Faster output if message already has a boundary Initial Comment: A simple change speeds up Message.as_string by more than a factor of 2 if the message already has a defined boundary, by avoiding a time-consuming RE compilation and search. ---------------------------------------------------------------------- >Comment By: L. Peter Deutsch (lpd) Date: 2005-07-23 15:08 Message: Logged In: YES user_id=8861 Sorry, forgot to enter this with the original submission: Python 2.4.1, Red Hat Linux 7.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1243654&group_id=5470 From noreply at sourceforge.net Sun Jul 24 14:54:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 24 Jul 2005 05:54:57 -0700 Subject: [Patches] [ python-Patches-1243910 ] Patch for (Doc) #1243553 Message-ID: Patches item #1243910, was opened at 2005-07-24 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=1243910&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: Nobody/Anonymous (nobody) Summary: Patch for (Doc) #1243553 Initial Comment: Add documentation to doc-string (copy/paste from Docs/lib) for 'quote' argument in cgi.escape. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1243910&group_id=5470 From noreply at sourceforge.net Mon Jul 25 01:32:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 24 Jul 2005 16:32:49 -0700 Subject: [Patches] [ python-Patches-869468 ] Allow use of embedded Tcl without requiring Tk Message-ID: Patches item #869468, was opened at 2004-01-02 13:22 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=869468&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: Tkinter Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: David Ascher (david_ascher) Assigned to: David Ascher (david_ascher) Summary: Allow use of embedded Tcl without requiring Tk Initial Comment: Two things: 1) docstrings added to most attributes of the _tkinter app object 2) allow the user to create Tkinter.Tcl objects which are just like Tkinter.Tk objects except that they do not initialize Tk. This is useful in circumstances where the script is being run on machines that do not have an X server running -- in those cases, Tk initialization fails, even if no window is ever created. I'll be glad to discuss the implementation choices. This has been tested on Windows, Linux, and Solaris. I'm hoping to figure out how to attach the test file as well. I don't have any documentation patch -- I'm willing to contribute one, but given the state of Tkinter documentation am not sure where to start... ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-07-24 19:32 Message: Logged In: YES user_id=6380 There seems to be a problem with this patch. It introduces __getattr__, __hasattr__ and __delattr__ methods, which attempt to delegate attributes to the self.tk object if they aren't defined on self. This is fine for __getattr__. __hasattr__ is based on a misunderstanding; there is no special __hasattr__ method. Butthe real problem is __delattr__ -- remember the asymmetry between __getattr__ and __setattr__? __getattr__ is only called as a fall-back (when the attribute isn't found using the normal attribute search), but __setattr__, if defined, is *always* called. Well, __delattr__ behaves the same way as __setattr__. The end result is that if someone sets a private attribute on a Tk() instance, it can be set (because __setattr__ is not defined) cannot be deleted (because __delattr__ is). Why do I care? It breaks Tkdnd! Tkdnd stores a private attribute (__dnd) on the Tk() object to indicate that it is active, and deletes it to indicate that it is no longer active. The fix is easy from my perspective: just get rid of the __hasattr__ and __delattr__ methods. But I'd like to ask the author and reviewer of the patch if they remember why this delegation was added in the first place, and if there's something that might be broken by my proposed fix. ---------------------------------------------------------------------- Comment By: David Ascher (david_ascher) Date: 2004-02-18 01:03 Message: Logged In: YES user_id=6114 Checked in. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-01-04 12:21 Message: Logged In: YES user_id=2772 I think that "package require Tk" is commonly broken. It is on RedHat 9 and Fedora Core 1. [jepler at parrot]$ tclsh % package require Tk can't find package Tk ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-01-03 06:58 Message: Logged In: YES user_id=21627 The patch looks fine, please apply. As for documentation: it has been custom to just document the changes (and perhaps write the bare minimum of structure to add the changes) to lib/tkinter.tex. I see no problem with some features being documented and others not - over time, documentation will complete if we continue with this custom. I wonder whether the loading of Tk can be simplified as evaluating "package require Tk" instead of calling Tk_Init(); I don't know what the difference between these two is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=869468&group_id=5470 From noreply at sourceforge.net Mon Jul 25 06:59:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 24 Jul 2005 21:59:09 -0700 Subject: [Patches] [ python-Patches-1244208 ] expat binding for XML_ParserReset (Bug #1208730) Message-ID: Patches item #1244208, was opened at 2005-07-24 21:59 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=1244208&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: John Eikenberry (zhar) Assigned to: Nobody/Anonymous (nobody) Summary: expat binding for XML_ParserReset (Bug #1208730) Initial Comment: This patch adds pyexpat C bindings for XML_ParserReset function. If there are any mistakes I'd appreciate any feedback. This was originally uploaded in relation to bug #1208730, but as nothing seems to be happening with it I guessed that the procedure was to upload a separate patch. Its a forward diff as recommended by the guidelines. I tried to follow them as much as possible. The patch is against the version in CVS as of the time of the original bug (back in May). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1244208&group_id=5470 From noreply at sourceforge.net Tue Jul 26 01:38:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Jul 2005 16:38:19 -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 (Tracker Item Submitted) made by Item Submitter 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1244861&group_id=5470 From noreply at sourceforge.net Tue Jul 26 05:54:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Jul 2005 20:54:02 -0700 Subject: [Patches] [ python-Patches-1244929 ] hide tests from TestProgram Message-ID: Patches item #1244929, was opened at 2005-07-25 20: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=1244929&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: Eric Huss (ehuss) Assigned to: Nobody/Anonymous (nobody) Summary: hide tests from TestProgram Initial Comment: The TestProgram class will find all tests in the file based on whether or not they are subclassed from TestCase. It is not possible to prevent TestProgram from including tests, such as base classes. For example, have BaseTest(unittest.TestCase) class that implements several test functions. However, these test functions can not operate correctly on their own...the class must be subclassed for proper operation (such as TestBlah(BaseTest)). This patch changes the "auto find" feature to ignore any classes that start with an underscore, allowing you to define base classes in the same file, but not have their tests run. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1244929&group_id=5470 From noreply at sourceforge.net Tue Jul 26 18:37:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Jul 2005 09:37:09 -0700 Subject: [Patches] [ python-Patches-1245379 ] Encoding alias "unicode-1-1-utf-7" Message-ID: Patches item #1245379, was opened at 2005-07-26 16: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=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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1245379&group_id=5470 From noreply at sourceforge.net Tue Jul 26 19:20:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Jul 2005 10:20:45 -0700 Subject: [Patches] [ python-Patches-1182394 ] HMAC hexdigest and general review Message-ID: Patches item #1182394, was opened at 2005-04-13 11:08 Message generated for change (Comment added) made by shane_holloway You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1182394&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: Shane Holloway (shane_holloway) Assigned to: Nobody/Anonymous (nobody) Summary: HMAC hexdigest and general review Initial Comment: This patch is primarily aimed at speeding up the HMAC.hexdigest method. The current implementation is:: return "".join([hex(ord(x))[2:].zfill(2) for x in tuple(self.digest())]) Which is correct, but a little too clever. Especially when other tools are available. The attached patch adds HMAC._current that returns the hash object combined from self.inner and self.outter to be used by HMAC.digest and HMAC.hexdigest. This results in an 11 fold speed improvement for md5 and sha digestmod's while also making the code a little easier. Other review points for the HMAC module include removing "_secret_backdoor_key" in favor of using "None" as the sentinel. In this case, it makes sense to use None because it is an invalid key, avoids a global lookup in py2.4 and beyond, and is just as readable. I also moved blocksize to a class level constant. This allows implementations to create different blocksize hashes by inheriting and changing this value. This also involved a change to copy() to use self.__class__(None) instead of directly calling HMAC(None). The final comment is that it would be nice to have a C-level implementation of _strxor in binascii for this module and possibly other uses. However, I don't really know a significantly faster way of implementing this method in python. Thanks, -Shane Holloway ---------------------------------------------------------------------- >Comment By: Shane Holloway (shane_holloway) Date: 2005-07-26 11:20 Message: Logged In: YES user_id=283742 Yes, I was reviewing HMAC to learn how it works, and to see if I could use it for a distributed verification algorithm. I will be make a fair number of hmac.copy() calls, but it will by no means be critical. Mainly, I found the implementation more than a little clunky to read, and significantly slower than it could be. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-16 12:08 Message: Logged In: YES user_id=11375 The HMAC._current() change and adding self.blocksize both look reasonable. I don't see the point of the _secret_backdoor_key change, though; accidentally using None or calling HMAC() will get an object that fails to work, and the speedup seems too small to compensate for this. Do you have a use case that requires making lots of HMAC.copy() calls? If the backdoor_key gets taken out, I don't think we need to keep the name around for backward compatibility; no callers of the module should have been using it. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-04-26 10:32 Message: Logged In: YES user_id=341410 Obviously "always have a length of 4" should have been "always have a length of zero modulo 4". ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-04-26 01:10 Message: Logged In: YES user_id=341410 I think the patch looks good. Though perhaps leaving a... _secret_backdoor_key = None ... for backwards compatibility is a good idea. The fastest method I've found (in pure Python) for xoring strings is to use an array.array, with the largest typecode that is a divisor of your sequence (cooking your strings to always have a length of 4 and to use signed 4 byte longs seems to work well on PII/PIII based systems). Alternatively, writing it in C and compiling it with the new GCC 4 will offer automatic vectorization, and save allocating Python integers. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-14 01:54 Message: Logged In: YES user_id=6656 Attempting to add the ^ for strings is a non-starter. No opinion on the rest of the patch. ---------------------------------------------------------------------- Comment By: Shane Holloway (shane_holloway) Date: 2005-04-13 15:21 Message: Logged In: YES user_id=283742 I would prefer to keep str's interface lean. I think binascii would be a nice home for strxor though. ---------------------------------------------------------------------- Comment By: Antti Louko (alouko) Date: 2005-04-13 12:01 Message: Logged In: YES user_id=116402 This seems good. I would also need strxor. Should we add it to the string type? ^ operator is not currently defined for strings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1182394&group_id=5470 From noreply at sourceforge.net Wed Jul 27 00:50:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Jul 2005 15:50:25 -0700 Subject: [Patches] [ python-Patches-869468 ] Allow use of embedded Tcl without requiring Tk Message-ID: Patches item #869468, was opened at 2004-01-02 10:22 Message generated for change (Comment added) made by david_ascher You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=869468&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: Tkinter Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: David Ascher (david_ascher) Assigned to: David Ascher (david_ascher) Summary: Allow use of embedded Tcl without requiring Tk Initial Comment: Two things: 1) docstrings added to most attributes of the _tkinter app object 2) allow the user to create Tkinter.Tcl objects which are just like Tkinter.Tk objects except that they do not initialize Tk. This is useful in circumstances where the script is being run on machines that do not have an X server running -- in those cases, Tk initialization fails, even if no window is ever created. I'll be glad to discuss the implementation choices. This has been tested on Windows, Linux, and Solaris. I'm hoping to figure out how to attach the test file as well. I don't have any documentation patch -- I'm willing to contribute one, but given the state of Tkinter documentation am not sure where to start... ---------------------------------------------------------------------- >Comment By: David Ascher (david_ascher) Date: 2005-07-26 15:50 Message: Logged In: YES user_id=6114 I'm fine w/ the proposed fix. I don't recall the reason for the delegation, but the proposed logic seems fine. Apologies for the bug. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-07-24 16:32 Message: Logged In: YES user_id=6380 There seems to be a problem with this patch. It introduces __getattr__, __hasattr__ and __delattr__ methods, which attempt to delegate attributes to the self.tk object if they aren't defined on self. This is fine for __getattr__. __hasattr__ is based on a misunderstanding; there is no special __hasattr__ method. Butthe real problem is __delattr__ -- remember the asymmetry between __getattr__ and __setattr__? __getattr__ is only called as a fall-back (when the attribute isn't found using the normal attribute search), but __setattr__, if defined, is *always* called. Well, __delattr__ behaves the same way as __setattr__. The end result is that if someone sets a private attribute on a Tk() instance, it can be set (because __setattr__ is not defined) cannot be deleted (because __delattr__ is). Why do I care? It breaks Tkdnd! Tkdnd stores a private attribute (__dnd) on the Tk() object to indicate that it is active, and deletes it to indicate that it is no longer active. The fix is easy from my perspective: just get rid of the __hasattr__ and __delattr__ methods. But I'd like to ask the author and reviewer of the patch if they remember why this delegation was added in the first place, and if there's something that might be broken by my proposed fix. ---------------------------------------------------------------------- Comment By: David Ascher (david_ascher) Date: 2004-02-17 22:03 Message: Logged In: YES user_id=6114 Checked in. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-01-04 09:21 Message: Logged In: YES user_id=2772 I think that "package require Tk" is commonly broken. It is on RedHat 9 and Fedora Core 1. [jepler at parrot]$ tclsh % package require Tk can't find package Tk ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-01-03 03:58 Message: Logged In: YES user_id=21627 The patch looks fine, please apply. As for documentation: it has been custom to just document the changes (and perhaps write the bare minimum of structure to add the changes) to lib/tkinter.tex. I see no problem with some features being documented and others not - over time, documentation will complete if we continue with this custom. I wonder whether the loading of Tk can be simplified as evaluating "package require Tk" instead of calling Tk_Init(); I don't know what the difference between these two is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=869468&group_id=5470 From noreply at sourceforge.net Wed Jul 27 01:16:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Jul 2005 16:16:48 -0700 Subject: [Patches] [ python-Patches-487738 ] weaklist Message-ID: Patches item #487738, was opened at 2001-12-01 02:36 Message generated for change (Comment added) made by g-lite You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=487738&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: Later Priority: 4 Submitted By: Andres Tuells (atuells) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: weaklist Initial Comment: WeakList are list whose entries are referenced weakly. When the object is gc it is deleted from the weaklist (and from its iterators). To be added to weakref.py ---------------------------------------------------------------------- Comment By: S. Kochen (g-lite) Date: 2005-07-27 01:16 Message: Logged In: YES user_id=890349 Mind if I bring this back up? This doesn't seem to be in yet. I didn't look at the implementation, but as for motivation... Andres mentioned his original motivation on a list: http://aspn.activestate.com/ASPN/Mail/Message/python-list/929285 I've also seen it duplicated in this recipe: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/87056 I'd like to see it in for the same reason. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 06:35 Message: Logged In: YES user_id=3066 Oops, I meant to adjust the priority on this. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 06:31 Message: Logged In: YES user_id=3066 Needs motivation. Without an need for the data structure, this will be rejected. Lowering priority and marking this for consideration for Python 2.3; it's too late to add this for Python 2.2. Set to "pending" while awaiting an explanation of the motivation. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2001-12-02 02:07 Message: Logged In: YES user_id=21627 Thanks for the patch. I would recommend to publish it as a separate package first, to get user feedback. I can't see this as a universally-useful data type, so I'm not sure it should be added to the standard library. *If* it is added, a number of corrections must be made to the code: - remove removes elements by equality, not identity. I believe in removeAll, you are looking for identical objects, not merely equal ones. - Why is it the right thing to remove elements from the list if the underlying object dies? doesn't this have undesirable side effects on indexing, e.g. when the list is being iterated over? - In the standard library, I think inheriting from UserList is deprecated, in favour of inheriting from list. - It seems that the class creates many unnecessary copies of lists, e.g. in extend, or setslice. - The references create cycles involving WeakList. Since the WeakList refers to ref objects through data, and the ref objects refer to the list throught the callback, the list itself will become garbage as long as list elements remain alive (although GC will detect those cycles). That should be avoided. - What is the point of the infinite loop in __getitem__? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=487738&group_id=5470 From noreply at sourceforge.net Wed Jul 27 02:00:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Jul 2005 17:00:30 -0700 Subject: [Patches] [ python-Patches-869468 ] Allow use of embedded Tcl without requiring Tk Message-ID: Patches item #869468, was opened at 2004-01-02 13:22 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=869468&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: Tkinter Group: Python 2.4 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: David Ascher (david_ascher) Assigned to: David Ascher (david_ascher) Summary: Allow use of embedded Tcl without requiring Tk Initial Comment: Two things: 1) docstrings added to most attributes of the _tkinter app object 2) allow the user to create Tkinter.Tcl objects which are just like Tkinter.Tk objects except that they do not initialize Tk. This is useful in circumstances where the script is being run on machines that do not have an X server running -- in those cases, Tk initialization fails, even if no window is ever created. I'll be glad to discuss the implementation choices. This has been tested on Windows, Linux, and Solaris. I'm hoping to figure out how to attach the test file as well. I don't have any documentation patch -- I'm willing to contribute one, but given the state of Tkinter documentation am not sure where to start... ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-07-26 20:00 Message: Logged In: YES user_id=6380 OK, fixed in 2.4 and CVS head. ---------------------------------------------------------------------- Comment By: David Ascher (david_ascher) Date: 2005-07-26 18:50 Message: Logged In: YES user_id=6114 I'm fine w/ the proposed fix. I don't recall the reason for the delegation, but the proposed logic seems fine. Apologies for the bug. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-07-24 19:32 Message: Logged In: YES user_id=6380 There seems to be a problem with this patch. It introduces __getattr__, __hasattr__ and __delattr__ methods, which attempt to delegate attributes to the self.tk object if they aren't defined on self. This is fine for __getattr__. __hasattr__ is based on a misunderstanding; there is no special __hasattr__ method. Butthe real problem is __delattr__ -- remember the asymmetry between __getattr__ and __setattr__? __getattr__ is only called as a fall-back (when the attribute isn't found using the normal attribute search), but __setattr__, if defined, is *always* called. Well, __delattr__ behaves the same way as __setattr__. The end result is that if someone sets a private attribute on a Tk() instance, it can be set (because __setattr__ is not defined) cannot be deleted (because __delattr__ is). Why do I care? It breaks Tkdnd! Tkdnd stores a private attribute (__dnd) on the Tk() object to indicate that it is active, and deletes it to indicate that it is no longer active. The fix is easy from my perspective: just get rid of the __hasattr__ and __delattr__ methods. But I'd like to ask the author and reviewer of the patch if they remember why this delegation was added in the first place, and if there's something that might be broken by my proposed fix. ---------------------------------------------------------------------- Comment By: David Ascher (david_ascher) Date: 2004-02-18 01:03 Message: Logged In: YES user_id=6114 Checked in. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-01-04 12:21 Message: Logged In: YES user_id=2772 I think that "package require Tk" is commonly broken. It is on RedHat 9 and Fedora Core 1. [jepler at parrot]$ tclsh % package require Tk can't find package Tk ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-01-03 06:58 Message: Logged In: YES user_id=21627 The patch looks fine, please apply. As for documentation: it has been custom to just document the changes (and perhaps write the bare minimum of structure to add the changes) to lib/tkinter.tex. I see no problem with some features being documented and others not - over time, documentation will complete if we continue with this custom. I wonder whether the loading of Tk can be simplified as evaluating "package require Tk" instead of calling Tk_Init(); I don't know what the difference between these two is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=869468&group_id=5470 From noreply at sourceforge.net Wed Jul 27 03:19:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Jul 2005 18:19:42 -0700 Subject: [Patches] [ python-Patches-487738 ] weaklist Message-ID: Patches item #487738, was opened at 2001-11-30 20:36 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=487738&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: 4 Submitted By: Andres Tuells (atuells) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: weaklist Initial Comment: WeakList are list whose entries are referenced weakly. When the object is gc it is deleted from the weaklist (and from its iterators). To be added to weakref.py ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-07-26 21:19 Message: Logged In: YES user_id=3066 This might be interesting to have. Would this be more useful than, say, a weak set? Ordering may be important for the publish/subscribe use case, at least to ensure predictability. I've not looked at the contributed code, so can't make any comment on that. ---------------------------------------------------------------------- Comment By: S. Kochen (g-lite) Date: 2005-07-26 19:16 Message: Logged In: YES user_id=890349 Mind if I bring this back up? This doesn't seem to be in yet. I didn't look at the implementation, but as for motivation... Andres mentioned his original motivation on a list: http://aspn.activestate.com/ASPN/Mail/Message/python-list/929285 I've also seen it duplicated in this recipe: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/87056 I'd like to see it in for the same reason. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 00:35 Message: Logged In: YES user_id=3066 Oops, I meant to adjust the priority on this. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 00:31 Message: Logged In: YES user_id=3066 Needs motivation. Without an need for the data structure, this will be rejected. Lowering priority and marking this for consideration for Python 2.3; it's too late to add this for Python 2.2. Set to "pending" while awaiting an explanation of the motivation. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2001-12-01 20:07 Message: Logged In: YES user_id=21627 Thanks for the patch. I would recommend to publish it as a separate package first, to get user feedback. I can't see this as a universally-useful data type, so I'm not sure it should be added to the standard library. *If* it is added, a number of corrections must be made to the code: - remove removes elements by equality, not identity. I believe in removeAll, you are looking for identical objects, not merely equal ones. - Why is it the right thing to remove elements from the list if the underlying object dies? doesn't this have undesirable side effects on indexing, e.g. when the list is being iterated over? - In the standard library, I think inheriting from UserList is deprecated, in favour of inheriting from list. - It seems that the class creates many unnecessary copies of lists, e.g. in extend, or setslice. - The references create cycles involving WeakList. Since the WeakList refers to ref objects through data, and the ref objects refer to the list throught the callback, the list itself will become garbage as long as list elements remain alive (although GC will detect those cycles). That should be avoided. - What is the point of the infinite loop in __getitem__? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=487738&group_id=5470 From noreply at sourceforge.net Wed Jul 27 13:51:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Jul 2005 04:51:13 -0700 Subject: [Patches] [ python-Patches-487738 ] weaklist Message-ID: Patches item #487738, was opened at 2001-12-01 02:36 Message generated for change (Comment added) made by g-lite You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=487738&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: 4 Submitted By: Andres Tuells (atuells) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: weaklist Initial Comment: WeakList are list whose entries are referenced weakly. When the object is gc it is deleted from the weaklist (and from its iterators). To be added to weakref.py ---------------------------------------------------------------------- Comment By: S. Kochen (g-lite) Date: 2005-07-27 13:51 Message: Logged In: YES user_id=890349 I'm not sure if either is more useful than the other, they both seem to have their advantages. It looks like a set would work for the links I mentioned, but I'd personally like to have the ability to connect to a signal/event with priority, thus needing a list. A weak set could possibly be implemented on top of WeakKeyDictionary? Have weak sets already been implemented somewhere? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-07-27 03:19 Message: Logged In: YES user_id=3066 This might be interesting to have. Would this be more useful than, say, a weak set? Ordering may be important for the publish/subscribe use case, at least to ensure predictability. I've not looked at the contributed code, so can't make any comment on that. ---------------------------------------------------------------------- Comment By: S. Kochen (g-lite) Date: 2005-07-27 01:16 Message: Logged In: YES user_id=890349 Mind if I bring this back up? This doesn't seem to be in yet. I didn't look at the implementation, but as for motivation... Andres mentioned his original motivation on a list: http://aspn.activestate.com/ASPN/Mail/Message/python-list/929285 I've also seen it duplicated in this recipe: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/87056 I'd like to see it in for the same reason. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 06:35 Message: Logged In: YES user_id=3066 Oops, I meant to adjust the priority on this. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 06:31 Message: Logged In: YES user_id=3066 Needs motivation. Without an need for the data structure, this will be rejected. Lowering priority and marking this for consideration for Python 2.3; it's too late to add this for Python 2.2. Set to "pending" while awaiting an explanation of the motivation. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2001-12-02 02:07 Message: Logged In: YES user_id=21627 Thanks for the patch. I would recommend to publish it as a separate package first, to get user feedback. I can't see this as a universally-useful data type, so I'm not sure it should be added to the standard library. *If* it is added, a number of corrections must be made to the code: - remove removes elements by equality, not identity. I believe in removeAll, you are looking for identical objects, not merely equal ones. - Why is it the right thing to remove elements from the list if the underlying object dies? doesn't this have undesirable side effects on indexing, e.g. when the list is being iterated over? - In the standard library, I think inheriting from UserList is deprecated, in favour of inheriting from list. - It seems that the class creates many unnecessary copies of lists, e.g. in extend, or setslice. - The references create cycles involving WeakList. Since the WeakList refers to ref objects through data, and the ref objects refer to the list throught the callback, the list itself will become garbage as long as list elements remain alive (although GC will detect those cycles). That should be avoided. - What is the point of the infinite loop in __getitem__? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=487738&group_id=5470 From noreply at sourceforge.net Fri Jul 29 04:40:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Jul 2005 19:40:10 -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-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 Josephine0506 at aol.com Sat Jul 30 14:23:50 2005 From: Josephine0506 at aol.com (Josephine0506@aol.com) Date: Sat, 30 Jul 2005 08:23:50 EDT Subject: [Patches] Buy Phentermine, Viagra & More With NO PRESCRIPTION! Message-ID: <1ea.41b90580.301ccb56@aol.com> where can i get phentermine with no perscription -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20050730/7534c35c/attachment.htm From noreply at sourceforge.net Sun Jul 31 23:10:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 31 Jul 2005 14:10:46 -0700 Subject: [Patches] [ python-Patches-1223381 ] PEP 342 Generator enhancements Message-ID: Patches item #1223381, was opened at 2005-06-18 23:08 Message generated for change (Comment added) made by pje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1223381&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: Phillip J. Eby (pje) Assigned to: Phillip J. Eby (pje) Summary: PEP 342 Generator enhancements Initial Comment: The attached patch implements code and test changes for: * yield expressions * bare yield (short for yield None) * yield in try/finally * generator.send(value) (send value into generator; substituted for PEP 342's next(arg)) * generator.throw(typ[,val[,tb]]) (raise error in generator) * generator.close() (per PEP 343) * GeneratorExit built-in exception type * generator.__del__ (well, the C equivalent) * All necessary mods to the compiler, parser module, and Python 'compiler' package to support these changes. It was necessary to change a small part of the eval loop (well, the initialization, not the loop) and the gc module's has_finalizer() logic in order to support a C equivalent to __del__. Specialists in these areas should probably scrutinize this patch! There is one additional implementation detail that was not contemplated in either PEP. in order to prevent used-up generators from retaining unnecessary references to their frame's contents, I set the generator's gi_frame member to None whenever the generator finishes normally or with an error. Thus, an exhausted generator cannot be part of a cycle, and it releases its frame object sooner than in previous Python versions. For generators used only in a direct "for" loop, this makes no difference, but for generators used with the iterator protocol (i.e. "gen.next()") from Python, this avoids stranding the generator's frame in a traceback cycle. ---------------------------------------------------------------------- >Comment By: Phillip J. Eby (pje) Date: 2005-07-31 21:10 Message: Logged In: YES user_id=56214 mwh, is the only difference in your patch the addition of the incref? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-07-07 14:14 Message: Logged In: YES user_id=6656 You missed an incref in gen_throw (symptom was Fatal Python error: ../Objects/tupleobject.c:169 object at 0x4013807c has negative ref count -606348326 on exit after running test_generators). New patch attached. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-28 07:10 Message: Logged In: YES user_id=6380 Since I've accepted PEP 342+343 last night in my Europython keynote, you can check this in now. ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2005-06-27 15:40 Message: Logged In: YES user_id=56214 I had hoped to be able to avoid dealing with string exceptions, but I guess it makes sense that if somebody has thrown one, it should be able to propagate. So I guess I'll take care of that along with the rest. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-27 15:31 Message: Logged In: YES user_id=6656 Heh heh heh. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-06-27 15:22 Message: Logged In: YES user_id=6380 (Removing 343 from the subject since all this is now in PEP 342.) Playing with the code a bit, I notice that throw() doesn't like string exceptions. That could cause some problems. Also, I think the tb argument should be allowed to be None. Otherwise, great! In a few hours you can check it in. :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-23 23:20 Message: Logged In: YES user_id=6656 Fair enough. I want to use with statements in a presentation at EuroPython next week, so I've hacked together a truly horrible implementation that will do for now and will see about a real one some time after... ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2005-06-23 23:07 Message: Logged In: YES user_id=56214 No, I haven't, and I never really planned to be the person implementing "with". Doesn't mean I might not end up doing it eventually, but it's not currently in my plans. I'm going to have my hands full just updating PEP 342 (Guido has asked me to take it over), and getting docs written to go with this patch. Between all that and my distutils-related work, my pro-bono Python project time is booked up solid for maybe the next 2 months or so. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-22 20:59 Message: Logged In: YES user_id=6656 Argh, I'd hoped you'd done with, too :) Have you done any work on that yet? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-19 07:37 Message: Logged In: YES user_id=1188172 Minor nit: on line 642, 'yield_stmt' should be changed to 'yield_expr'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1223381&group_id=5470