From noreply at sourceforge.net Wed Aug 1 00:44:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jul 2007 15:44:17 -0700 Subject: [Patches] [ python-Patches-1764986 ] generic and more efficient removal of unreachable code Message-ID: Patches item #1764986, was opened at 2007-08-01 01:44 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=1764986&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Pogonyshev (doublep) Assigned to: Nobody/Anonymous (nobody) Summary: generic and more efficient removal of unreachable code Initial Comment: The attached patch removed unreachable code after RAISE_VARARGS, BREAK_LOOP and RETURN_VALUE in generic way (no more tests for LOAD_CONST None RETURN_VALUE, etc.) It is possible to generalize it more for some other bytecodes. The only problem they are already used in switch() in question as labels. Probably not important enough to warrant another switch() or break this out into a function/macro. No speedup is expected, but I think the patch is good with no drawbacks anyway. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1764986&group_id=5470 From noreply at sourceforge.net Wed Aug 1 10:14:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Aug 2007 01:14:34 -0700 Subject: [Patches] [ python-Patches-1765140 ] logging: delay_fh option and configuration kwargs Message-ID: Patches item #1765140, was opened at 2007-08-01 08:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1765140&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Leary (cdleary) Assigned to: Nobody/Anonymous (nobody) Summary: logging: delay_fh option and configuration kwargs Initial Comment: Streams (read: files) are opened in potentially destructive modes when loading logging configurations. This patch provides library users with a method of postponing the opening of streams. The method is simple, powerful, and should be fully compatible with existing infrastructure. The StreamHandler now allows a callback function to be passed as an initialization parameter (@param strm). This function must be callable with no arguments and return a valid stream. A function passed in this manner can be initialized via the initialize_stream() method call; however, if the user chooses not to call initialize_stream() explicitly, the stream is initialized on the first attempt to emit a record. To take advantage of this ability, the FileHandler has been extended with callback-passing functionality. If the delay_fh initialization parameter is asserted, a file-opening closure is passed to the StreamHandler (superclass) initialization method. This ability has also been extended to the module's fileConfig() function. Though fileConfig()'s optional delay_fh parameter, the user may load a configuration from file without undesired file handle opening effects. This is particularly useful when running many instances of the same program on a single file system -- the user now has the ability to change (at runtime) FileHandlers that would otherwise be opened in 'w' mode, clobbering the other instantiation's logs. Another, seemingly tangential portion of the patch adds a kwargs specifier to the configuration file. This is to add the flexibility of adding a delay_fh keyword indicator without specifying other arguments unnecessarily as part of 'args'. It still follows the 1.5 compatible apply() syntax, and it only takes another 4 lines ;) Implementation Notes: - Tested in regtest and with an application I wrote that's quite logging-intensive, and both check out OK so far. - I broke some functions I was working on into helpers for readability, as they were getting too long. They're all initialization functions that shouldn't be performance critical. - Private functions that I added weren't given default values for the delay_fh parameter, since nobody knows about them; however, I gave the private functions that were already there a default value for the delay_fh parameter just to be extra safe and backwards compatible. Hopefully nobody's using those anyway. - I tried my best to follow existing style -- feel free to yell at me if I missed it somewhere :D - Chris Leary ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1765140&group_id=5470 From noreply at sourceforge.net Wed Aug 1 17:48:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Aug 2007 08:48:29 -0700 Subject: [Patches] [ python-Patches-1765558 ] small improvement for peephole conditional jump optimizer Message-ID: Patches item #1765558, was opened at 2007-08-01 18:48 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=1765558&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: Performance Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Pogonyshev (doublep) Assigned to: Nobody/Anonymous (nobody) Summary: small improvement for peephole conditional jump optimizer Initial Comment: This tiny patch adds optimization for the case of conditional jump to UNARY_NOT followed by another conditional jump. Those NOTs are optimized in turn, but this happens later in peephole pass, so this patch does make difference. Net improvement is that jump branches can become shorter by a command sometimes. Bytecode itself shouldn't become shorter, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1765558&group_id=5470 From noreply at sourceforge.net Thu Aug 2 05:13:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Aug 2007 20:13:21 -0700 Subject: [Patches] [ python-Patches-1741308 ] Fix Decimal.sqrt bugs described in #1725899 Message-ID: Patches item #1741308, was opened at 2007-06-22 03:54 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1741308&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.6 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Mark Dickinson (marketdickinson) Assigned to: Facundo Batista (facundobatista) Summary: Fix Decimal.sqrt bugs described in #1725899 Initial Comment: This patch fixes a number of (yet-to-be-confirmed-as-) bugs in Decimal.sqrt(); see bug report 1725899 for details of these. As a side benefit the modified version of Decimal.sqrt() runs significantly faster than the original, since it's based on integer arithmetic instead of carrying out Newton's method entirely in decimal; on my iBook G4 the speedup is between 20 and 25 times with the default precision. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2007-08-02 00:13 Message: Logged In: YES user_id=752496 Originator: NO Applied two modified patchs, see revisions 56654 to 56656. the main difference is that Mark regenerated the diff against the decimal-branch, where I'm developing the decimal module. He is making a great job in this regard, thanks Mark! ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-07-18 00:37 Message: Logged In: YES user_id=703403 Originator: YES Final(?) version of the patch is attached. The extra testcases for sqrt have been vetted, corrected (see below) and slightly expanded by Mike Cowlishaw, and are, I believe, going to be included in the next update on his website. The file squareroot_extra.decTest included in the patch is exactly the file I received back from Cowlishaw, with no changes. The code and comments have been cleaned up a little. The patch also fixes another bug in the _fixexponents method: in the following, the Underflow flag should not be raised. Python 2.5.1 (r251:54863, May 10 2007, 20:59:25) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from decimal import * >>> c = getcontext() >>> c.Emin = -9 >>> c.Emax = 9 >>> Decimal(2).sqrt() # Inexact but not Subnormal Decimal("1.414213562373095048801688724") >>> +Decimal("100E-38") # Subnormal but not Inexact Decimal("1E-36") >>> c Context(prec=28, rounding=ROUND_HALF_EVEN, Emin=-9, Emax=9, capitals=1, flags=[Rounded, Underflow, Subnormal, Inexact], traps=[DivisionByZero, Overflow, InvalidOperation]) There's still one outstanding issue: Cowlishaw says that for a general arithmetic operation, underflow of a nonzero result to zero should result in the Clamped flag being raised; I believe that the current testcases from Cowlishaw's website reflect this, while the older ones in the decimaltestdata directory don't. (This is the source of the only corrections to the previous test cases.) Currently sqrt() does raise Clamped on underflow to 0, but none of the other arithmetic operations do, which is inconsistent. I'd be happy to fix this, but I think discussion is needed first: should sqrt be `fixed' to not raise Clamped here (this would be trivial to do); should the other arithmetic operations be fixed to raise Clamped on underflow to 0 (also trivial, except that it would require updating many of the testcases), or should things be left as they are? Any suggestions? (By the way, I also have a working Decimal.log, if anyone's interested...) Mark Mark File Added: decimal_sqrt_3.patch ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-07-02 11:34 Message: Logged In: YES user_id=703403 Originator: YES File Added: decimal_sqrt_2.patch ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-07-02 11:33 Message: Logged In: YES user_id=703403 Originator: YES Here's an updated patch, with: -- several hundred extra testcases, in a new file squareroot_extra.decTest -- fixes for two bugs in the previous patch; one where the context rounding mode was occasionally used instead of ROUND-HALF-EVEN, and one involving underflow to 0. -- a fix for the following problem in Decimal._fixexponents(): (should I submit a separate patch for this instead?) >>> from decimal import * >>> getcontext().Emax = 9 >>> getcontext().Emin = -9 >>> getcontext()._clamp = 1 >>> +Decimal("1E10") Traceback (most recent call last): File "", line 1, in File "/opt/local/lib/python2.5/decimal.py", line 935, in __pos__ ans = self._fix(context) File "/opt/local/lib/python2.5/decimal.py", line 1530, in _fix ans = self._fixexponents(context) File "/opt/local/lib/python2.5/decimal.py", line 1565, in _fixexponents ans = ans._rescale(Etop, context=context) File "/opt/local/lib/python2.5/decimal.py", line 1913, in _rescale return context._raise_error(InvalidOperation, 'Rescale > prec') File "/opt/local/lib/python2.5/decimal.py", line 2325, in _raise_error raise error, explanation decimal.InvalidOperation: Rescale > prec I've been in contact with Cowlishaw; he's agreed that it looks as though the C reference implementation needs a few changes, but hasn't had a chance to look at things properly yet; I've sent him the extra testcases above as well. Please let me know if there's anything else I can do to help. Mark ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-06-22 09:29 Message: Logged In: YES user_id=752496 Originator: NO Yes, I'll handle this and the mentioned bug. Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-22 04:09 Message: Logged In: YES user_id=33168 Originator: NO Facundo, could you take a look? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1741308&group_id=5470 From noreply at sourceforge.net Thu Aug 2 05:47:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Aug 2007 20:47:36 -0700 Subject: [Patches] [ python-Patches-1765839 ] urllib2-howto - correction Message-ID: Patches item #1765839, was opened at 2007-08-02 09:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1765839&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: O.R.Senthil Kumaran (orsenthil) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2-howto - correction Initial Comment: urllib2 howto mentions that "Currently urllib2 does not support fetching of https locations through a proxy. This can be a problem." This is quite misleading, the following ASPN Cookbook recipe shows otherwise. http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/456195 Included a patch to correct the documentation bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1765839&group_id=5470 From noreply at sourceforge.net Thu Aug 2 06:17:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Aug 2007 21:17:18 -0700 Subject: [Patches] [ python-Patches-1755841 ] Patch for [ 735515 ] urllib2 should cache 301 redir Message-ID: Patches item #1755841, was opened at 2007-07-18 08:02 Message generated for change (Comment added) made by orsenthil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1755841&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: O.R.Senthil Kumaran (orsenthil) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for [ 735515 ] urllib2 should cache 301 redir Initial Comment: Tracker item python.org/sf/735515 mentions about urllib2 to cache 301 redirections. Attached patch tries to implement the same. Comments on Version 1 of patch: a) Initializes a dictionary to store the redirection. b) If req already in cache, return the previous Request object. c) Otherwise handle the same as 302 and store the Request object. d) Checks for loop errors in 301. Just noticed, that it I missed max-redirect checks. Please comment on this patch, with next version I shall add the max redirect check. ---------------------------------------------------------------------- >Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-02 09:47 Message: Logged In: YES user_id=942711 Originator: YES Hi Skip, I have implemented Cache redirection for 301 errors only which will be Permanant redirection. Expiry header is not expected for 301 direction, so we might not purge it. RFC 2616 states that if cache is implemented for 302 redirects ( temporary redirects) than Expiry header should be handled and cache purged. For our change it is not required. Thanks, Senthil ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-07-26 20:08 Message: Logged In: YES user_id=44345 Originator: NO Looks reasonable to me, however I wonder if you shouldn't purge cached information periodically. Does RFC 2616 provide any guidance? Skip ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-07-24 09:26 Message: Logged In: YES user_id=942711 Originator: YES I have made some changes to patch. Made it use just the self.cache to cache and follow the same logic for redirect and loop as 302 would follow. I thought this is ok. Did a basic testing to verify if it caught 301 redirect, yes it does. File Added: urllib2-cache-301.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1755841&group_id=5470 From noreply at sourceforge.net Thu Aug 2 06:38:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Aug 2007 21:38:53 -0700 Subject: [Patches] [ python-Patches-1765140 ] logging: delay_fh option and configuration kwargs Message-ID: Patches item #1765140, was opened at 2007-08-01 08:14 Message generated for change (Settings changed) made by cdleary You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1765140&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Leary (cdleary) >Assigned to: Vinay Sajip (vsajip) Summary: logging: delay_fh option and configuration kwargs Initial Comment: Streams (read: files) are opened in potentially destructive modes when loading logging configurations. This patch provides library users with a method of postponing the opening of streams. The method is simple, powerful, and should be fully compatible with existing infrastructure. The StreamHandler now allows a callback function to be passed as an initialization parameter (@param strm). This function must be callable with no arguments and return a valid stream. A function passed in this manner can be initialized via the initialize_stream() method call; however, if the user chooses not to call initialize_stream() explicitly, the stream is initialized on the first attempt to emit a record. To take advantage of this ability, the FileHandler has been extended with callback-passing functionality. If the delay_fh initialization parameter is asserted, a file-opening closure is passed to the StreamHandler (superclass) initialization method. This ability has also been extended to the module's fileConfig() function. Though fileConfig()'s optional delay_fh parameter, the user may load a configuration from file without undesired file handle opening effects. This is particularly useful when running many instances of the same program on a single file system -- the user now has the ability to change (at runtime) FileHandlers that would otherwise be opened in 'w' mode, clobbering the other instantiation's logs. Another, seemingly tangential portion of the patch adds a kwargs specifier to the configuration file. This is to add the flexibility of adding a delay_fh keyword indicator without specifying other arguments unnecessarily as part of 'args'. It still follows the 1.5 compatible apply() syntax, and it only takes another 4 lines ;) Implementation Notes: - Tested in regtest and with an application I wrote that's quite logging-intensive, and both check out OK so far. - I broke some functions I was working on into helpers for readability, as they were getting too long. They're all initialization functions that shouldn't be performance critical. - Private functions that I added weren't given default values for the delay_fh parameter, since nobody knows about them; however, I gave the private functions that were already there a default value for the delay_fh parameter just to be extra safe and backwards compatible. Hopefully nobody's using those anyway. - I tried my best to follow existing style -- feel free to yell at me if I missed it somewhere :D - Chris Leary ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1765140&group_id=5470 From noreply at sourceforge.net Thu Aug 2 12:55:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Aug 2007 03:55:51 -0700 Subject: [Patches] [ python-Patches-1755841 ] Patch for [ 735515 ] urllib2 should cache 301 redir Message-ID: Patches item #1755841, was opened at 2007-07-17 21:32 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1755841&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: O.R.Senthil Kumaran (orsenthil) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for [ 735515 ] urllib2 should cache 301 redir Initial Comment: Tracker item python.org/sf/735515 mentions about urllib2 to cache 301 redirections. Attached patch tries to implement the same. Comments on Version 1 of patch: a) Initializes a dictionary to store the redirection. b) If req already in cache, return the previous Request object. c) Otherwise handle the same as 302 and store the Request object. d) Checks for loop errors in 301. Just noticed, that it I missed max-redirect checks. Please comment on this patch, with next version I shall add the max redirect check. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2007-08-02 05:55 Message: Logged In: YES user_id=44345 Originator: NO How much extra work would it be to handle 302 redirects and the Expiry header? (I don't want to hold you up from the rest of your SoC tasks. Time's running out.) Note also that you should also include a patch to the urllib2 documentation and, if possible, one or more test cases to exercise the new code. Skip ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-01 23:17 Message: Logged In: YES user_id=942711 Originator: YES Hi Skip, I have implemented Cache redirection for 301 errors only which will be Permanant redirection. Expiry header is not expected for 301 direction, so we might not purge it. RFC 2616 states that if cache is implemented for 302 redirects ( temporary redirects) than Expiry header should be handled and cache purged. For our change it is not required. Thanks, Senthil ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-07-26 09:38 Message: Logged In: YES user_id=44345 Originator: NO Looks reasonable to me, however I wonder if you shouldn't purge cached information periodically. Does RFC 2616 provide any guidance? Skip ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-07-23 22:56 Message: Logged In: YES user_id=942711 Originator: YES I have made some changes to patch. Made it use just the self.cache to cache and follow the same logic for redirect and loop as 302 would follow. I thought this is ok. Did a basic testing to verify if it caught 301 redirect, yes it does. File Added: urllib2-cache-301.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1755841&group_id=5470 From noreply at sourceforge.net Thu Aug 2 18:14:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Aug 2007 09:14:47 -0700 Subject: [Patches] [ python-Patches-1766304 ] improve xrange.__contains__ Message-ID: Patches item #1766304, was opened at 2007-08-02 18:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1766304&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stargaming (stargaming) Assigned to: Nobody/Anonymous (nobody) Summary: improve xrange.__contains__ Initial Comment: Membership tests for xrange result in loss of xrange's laziness by iterating through every single item. This yields a complexity of O(n) and an unbearable runtime when handling larger ranges. This issue can be fixed by using arithmetic decision instead of generic lookup/iteration. This will boil down the complexity to O(1) and make tests near the start of the range as fast as those near the end. The same technique is already used in item lookups. The fix has been inspired by the "optimizing [x]range" thread in the python-3000-devel mailing list (see http://article.gmane.org/gmane.comp.python.python-3000.devel/8732). A patch to Objects/rangeobject.c is attached. It modifies tp_as_sequence in PyRange_Type to include the sq_contains field and implement the procedure range_contains right there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1766304&group_id=5470 From noreply at sourceforge.net Thu Aug 2 21:05:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Aug 2007 12:05:21 -0700 Subject: [Patches] [ python-Patches-1680959 ] Add tests for pipes module (test_pipes) Message-ID: Patches item #1680959, was opened at 2007-03-14 16:48 Message generated for change (Settings changed) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680959&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alan McIntyre (alanmcintyre) >Assigned to: Facundo Batista (facundobatista) Summary: Add tests for pipes module (test_pipes) Initial Comment: The attached file contains a patch to: - remove the "just import it" test for pipes from test_sundry.py - add test_pipes to expected skips on win32 in regrtest.py - remove the "small test program and example" from pipes.py (it seems to me this is best put in either tests or docs instead of the module itself) It also includes a new test_pipes.py module. At the moment this covers about 86% of the pipes.py code; I'll try to get that higher, but I wanted to throw this out there for initial feedback. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-03-17 12:31 Message: Logged In: YES user_id=1115903 Originator: YES I adjusted things to conform to PEP 8 (I hope), changed the exists/unlink as suggested, ran reindent.py on test_pipes.py, and included test_pipes.py in the patch. File Added: pipes-tests-2.diff ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 23:40 Message: Logged In: YES user_id=1344176 Originator: NO Thanks for your patch! Initial comments: * test_pipes does not conform to PEP 8 (whitespace issues, line length, etc). * SVN reports that test_pipes has inconsistent line endings. * Calling os.path.exists() as a check before os.unlink() creates a race condition; just catch the exception. * In the future, please include new files in the patch itself. "svn add" the file, then "svn diff" will include it when creating the diff. Please address these issues. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680959&group_id=5470 From noreply at sourceforge.net Thu Aug 2 21:17:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Aug 2007 12:17:02 -0700 Subject: [Patches] [ python-Patches-1742669 ] "%d" format handling for long values Message-ID: Patches item #1742669, was opened at 2007-06-25 03:24 Message generated for change (Settings changed) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1742669&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 Private: No Submitted By: Gabriel Genellina (gagenellina) >Assigned to: Facundo Batista (facundobatista) Summary: "%d" format handling for long values Initial Comment: String formatting using %d doesn't handle well a long value when the object isn't a PyLong itself. That is: py> "%d" % 42L '42' py> "%d" % 10000000000000000000000000000000L '10000000000000000000000000000000' py> "%d" % 42.0 '42' py> "%d" % 10000000000000000000000000000000.0 Traceback (most recent call last): File "", line 1, in TypeError: int argument required Here it was shown with a float object, but any other object with a __long__ or __int__ method returning a PyLong fails (by example, the gmpy package). Currently PyString_Format, for "%d", checks whether the value *is* a PyLong and processes it, else tries to *convert* it to PyInt (and fails for large values). The attached patch first checks for a number; if it's a number but not PyInt nor PyLong, tries to convert to int; if it fails, tries to convert to long. The resulting value (either a PyInt or PyLong) is formatted the same way as before. If the original object was actually an int or long, it's handled the same way as before. The test ordering was chosen to only convert to long when necesary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1742669&group_id=5470 From noreply at sourceforge.net Fri Aug 3 09:15:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 00:15:49 -0700 Subject: [Patches] [ python-Patches-1766592 ] Fix for test_zipimport Message-ID: Patches item #1766592, was opened at 2007-08-03 10:15 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=1766592&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ??PC?? (zpcz) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for test_zipimport Initial Comment: Changes made: imp.get_magic() - returns bytes loader.get_data() - returns bytes loader.get_source() - returns str (currently thinks everything is in utf-8) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1766592&group_id=5470 From noreply at sourceforge.net Fri Aug 3 09:17:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 00:17:10 -0700 Subject: [Patches] [ python-Patches-1764815 ] Fix for test_socketserver for Py3k Message-ID: Patches item #1764815, was opened at 2007-07-31 21:38 Message generated for change (Settings changed) made by zpcz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1764815&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None >Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ??PC?? (zpcz) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for test_socketserver for Py3k Initial Comment: Well, it's quite small. I think I'm right with changing StringIO to BytesIO ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1764815&group_id=5470 From noreply at sourceforge.net Fri Aug 3 09:53:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 00:53:28 -0700 Subject: [Patches] [ python-Patches-1765839 ] urllib2-howto - correction Message-ID: Patches item #1765839, was opened at 2007-08-02 03:47 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1765839&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: O.R.Senthil Kumaran (orsenthil) >Assigned to: Georg Brandl (gbrandl) Summary: urllib2-howto - correction Initial Comment: urllib2 howto mentions that "Currently urllib2 does not support fetching of https locations through a proxy. This can be a problem." This is quite misleading, the following ASPN Cookbook recipe shows otherwise. http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/456195 Included a patch to correct the documentation bug. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-03 07:53 Message: Logged In: YES user_id=849994 Originator: NO Well, the given recipe enhances urllib2 classes to support that, so the (first) original sentence is correct. Nevertheless, a link to the recipe is helpful. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1765839&group_id=5470 From noreply at sourceforge.net Fri Aug 3 18:14:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 09:14:58 -0700 Subject: [Patches] [ python-Patches-1752175 ] fixing 2.5.1 build with unicode and dynamic loading disabled Message-ID: Patches item #1752175, was opened at 2007-07-11 21:40 Message generated for change (Comment added) made by neundorf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1752175&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexander Neundorf (neundorf) Assigned to: Nobody/Anonymous (nobody) Summary: fixing 2.5.1 build with unicode and dynamic loading disabled Initial Comment: I'm currently porting python to some platforms with limited capabilities and so I thought it would be a good idea to subscribe here. While doing the porting, I found two small problems in Python 2.5.1: If Py_USING_UNICODE is disabled, in Python/ast.c decode_unicode() still calls unicode-related functions, which leads to undefined references when linking. If HAVE_DYNAMIC_LOADING is disabled, in Python/import.c _PyImport_DynLoadFiletab is still initialized, which also leads to undefined references when linking, since then no source file which defines this variable is used. ---------------------------------------------------------------------- >Comment By: Alexander Neundorf (neundorf) Date: 2007-08-03 18:14 Message: Logged In: YES user_id=93933 Originator: YES Any chance this could be committed to the 2.5 branch ? Or should I post a patch against curren trunk ? Alex ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1752175&group_id=5470 From noreply at sourceforge.net Fri Aug 3 20:41:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 11:41:08 -0700 Subject: [Patches] [ python-Patches-1766592 ] Fix for test_zipimport Message-ID: Patches item #1766592, was opened at 2007-08-03 03:15 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1766592&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 3000 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: ??PC?? (zpcz) >Assigned to: Guido van Rossum (gvanrossum) Summary: Fix for test_zipimport Initial Comment: Changes made: imp.get_magic() - returns bytes loader.get_data() - returns bytes loader.get_source() - returns str (currently thinks everything is in utf-8) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-03 14:41 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 56707. This looks fine at cursory inspection. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1766592&group_id=5470 From noreply at sourceforge.net Fri Aug 3 21:03:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 12:03:56 -0700 Subject: [Patches] [ python-Patches-1764815 ] Fix for test_socketserver for Py3k Message-ID: Patches item #1764815, was opened at 2007-07-31 14:38 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1764815&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: ??PC?? (zpcz) >Assigned to: Guido van Rossum (gvanrossum) Summary: Fix for test_socketserver for Py3k Initial Comment: Well, it's quite small. I think I'm right with changing StringIO to BytesIO ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-03 15:03 Message: Logged In: YES user_id=6380 Originator: NO Thanks! Committed revision 56708. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1764815&group_id=5470 From noreply at sourceforge.net Fri Aug 3 21:04:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 12:04:33 -0700 Subject: [Patches] [ python-Patches-1761465 ] struni: Fix test_aepack by converting 4cc's to bytes Message-ID: Patches item #1761465, was opened at 2007-07-26 14:37 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1761465&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: Macintosh Group: Python 3000 >Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Jeffrey Yasskin (jyasskin) Assigned to: Guido van Rossum (gvanrossum) Summary: struni: Fix test_aepack by converting 4cc's to bytes Initial Comment: Also includes a simple fix for test_applesingle. The core of this fix is to change Python/mactoolboxglue.c:PyMac_BuildOSType(OSType) to return a bytes object instead of a str8, and then to go through the python code and change the four-character-codes to bytes. This hits a snag when they're used as dictionary keys, since bytes isn't hashable, so a hacky little b2i() function converts them to ints first. b2i() should go away when someone writes the general bytes/int conversion api. This is discussed some at http://mail.python.org/pipermail/python-3000/2007-July/008935.html. If Talin's and Ronald's preference from that thread is taken, then PyMac_BuildOSType should return their new type instead. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-03 15:04 Message: Logged In: YES user_id=6380 Originator: NO On the list we agreed not to apply the second patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-07-27 08:55 Message: Logged In: YES user_id=6380 Originator: NO Hmm... What if there's a 4CC containing a non-ASCII byte? ---------------------------------------------------------------------- Comment By: Jeffrey Yasskin (jyasskin) Date: 2007-07-27 02:19 Message: Logged In: YES user_id=581856 Originator: YES But I like black'n'white files. ;) I've attached a patch changing b2i to str for using 4CCs in dicts. Since this file, at least, never needs to convert back, nothing's ambiguous about it, and I do like the idea of being able to read these while debugging. The test still passes. File Added: aepack_b2i_to_str.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-07-27 00:42 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 56560. (Except I changed the open mode from the unconventional 'bw' to 'wb'. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1761465&group_id=5470 From noreply at sourceforge.net Fri Aug 3 21:19:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 12:19:34 -0700 Subject: [Patches] [ python-Patches-1762940 ] struni: test_urllib2, test_cookielib Message-ID: Patches item #1762940, was opened at 2007-07-28 21:12 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1762940&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 3000 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Joe Gregorio (jcgregorio) >Assigned to: Guido van Rossum (gvanrossum) Summary: struni: test_urllib2, test_cookielib Initial Comment: This patch fixes the unit tests of both test_urllib2 and test_cookielib. The reason for combining them is that they both needed the changes to urllib.quote(). The largest part of this patch is to urllib.quote(), which would operate on unicode strings, but only so long as they didn't stray out of the ASCII range. The old code would create a dictionary with 256 entries that mapped incoming chars to their 'safe' replacements, and that dict was created once in its entirety when the function was first called and cached for later calls. Since the incoming character string is now unicode that method won't work. The new code does not build the dict in its entirety, instead it memoizes the ASCII range translations as it runs. It does not memoize translations outside of the ASCII range as that would be hole by which you could exhaust a programs memory. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-03 15:19 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 56709. ---------------------------------------------------------------------- Comment By: Joe Gregorio (jcgregorio) Date: 2007-07-29 14:25 Message: Logged In: YES user_id=81604 Originator: YES This is an updated patch that simplifies the translation of characters. Instead of having a closure for the quoting and then wrapping it in a Memoize instance, this patch just creates a simple Quoter class that does the translation and caching. File Added: urllib2-cookie-quote-2.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1762940&group_id=5470 From noreply at sourceforge.net Fri Aug 3 21:21:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 12:21:57 -0700 Subject: [Patches] [ python-Patches-1755133 ] urllib2 tests pass Message-ID: Patches item #1755133, was opened at 2007-07-16 17:27 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1755133&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 3000 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Hasan Diwan (hdiwan650) >Assigned to: Guido van Rossum (gvanrossum) Summary: urllib2 tests pass Initial Comment: Tests pass for urllib2 ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-03 15:21 Message: Logged In: YES user_id=6380 Originator: NO A different patch, by Joe Gregorio, was committed that fixes this in differently. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-07-17 16:56 Message: Logged In: YES user_id=6380 Originator: NO With the latest version I still get three errors: test_basic_and_digest_auth_handlers, test_basic_auth, test_proxy_basic_auth, all failing here: File "Lib/test/test_urllib2.py", line 990, in _test_basic_auth r = opener.open(request_url) File "/usr/local/google/home/guido/python/py3k-struni/Lib/urllib2.py", line 374, in open response = self._open(req, data) File "/usr/local/google/home/guido/python/py3k-struni/Lib/urllib2.py", line 392, in _open '_open', req) File "/usr/local/google/home/guido/python/py3k-struni/Lib/urllib2.py", line 352, in _call_chain result = func(*args) File "Lib/test/test_urllib2.py", line 363, in http_open "http", req, MockFile(), self.code, name, msg) File "/usr/local/google/home/guido/python/py3k-struni/Lib/urllib2.py", line 412, in error result = self._call_chain(*args) File "/usr/local/google/home/guido/python/py3k-struni/Lib/urllib2.py", line 352, in _call_chain result = func(*args) File "/usr/local/google/home/guido/python/py3k-struni/Lib/urllib2.py", line 831, in http_error_407 authority, req, headers) File "/usr/local/google/home/guido/python/py3k-struni/Lib/urllib2.py", line 795, in http_error_auth_reqed return self.retry_http_basic_auth(host, req, realm) File "/usr/local/google/home/guido/python/py3k-struni/Lib/urllib2.py", line 801, in retry_http_basic_auth auth = 'Basic %s' % base64.b64encode(raw).strip() TypeError: strip() takes exactly one argument (0 given) Also: (1) I'd like to see the interact_netscape call fixed rather than commented out (2) I wonder if urllib shouldn't use text strings instead of bytes for headers and values. ---------------------------------------------------------------------- Comment By: Hasan Diwan (hdiwan650) Date: 2007-07-16 18:19 Message: Logged In: YES user_id=1185570 Originator: YES File Added: test_urllib2.pat ---------------------------------------------------------------------- Comment By: Hasan Diwan (hdiwan650) Date: 2007-07-16 17:51 Message: Logged In: YES user_id=1185570 Originator: YES File Added: test_urllib2.pat ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1755133&group_id=5470 From noreply at sourceforge.net Sat Aug 4 01:16:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 16:16:56 -0700 Subject: [Patches] [ python-Patches-1767370 ] Make xmlrpc use HTTP/1.1 and keepalive Message-ID: Patches item #1767370, was opened at 2007-08-04 09:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1767370&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 Private: No Submitted By: Donovan Baarda (abo) Assigned to: Nobody/Anonymous (nobody) Summary: Make xmlrpc use HTTP/1.1 and keepalive Initial Comment: This patch is being submitted by me on behalf of someone else who wrote it. The patch as provided to me was against python2.5. I have applied and regenerated this patch against the current svn trunk. I have not tested it, but the author is using it and reports that it is working well. As the summary indicates, it makes xmlrpc use HTTP/1.1 keepalive with, which makes it much more efficient. I believe it also ads improved buffering. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1767370&group_id=5470 From noreply at sourceforge.net Sat Aug 4 02:11:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 17:11:43 -0700 Subject: [Patches] [ python-Patches-1767398 ] test_csv struni fixes + unicode support in _csv Message-ID: Patches item #1767398, was opened at 2007-08-03 19:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1767398&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Adam Hupp (hupp) Assigned to: Nobody/Anonymous (nobody) Summary: test_csv struni fixes + unicode support in _csv Initial Comment: This patch fixes test_csv.py for the struni branch and modifies _csv.c to support unicode strings. Changes: 1. The test_csv.py failures caused by bytes/str conflicts have been resolved. 2. Uses of mkstemp have been replaced with TemporaryFile in a 'with' block. 3. The _csv.c module now uses unicode for string handling. I've uncommented the unicode read tests in test_csv.py, and added tests for writing unicode content and a unicode delimiter. All tests are now passing on my system (linux). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1767398&group_id=5470 From noreply at sourceforge.net Sat Aug 4 02:18:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 17:18:55 -0700 Subject: [Patches] [ python-Patches-1667546 ] Time zone-capable variant of time.localtime Message-ID: Patches item #1667546, was opened at 2007-02-24 00:25 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&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 Private: No Submitted By: Paul Boddie (pboddie) Assigned to: Georg Brandl (gbrandl) Summary: Time zone-capable variant of time.localtime Initial Comment: Patch related to #1493676: "time.strftime() %z error" This provides a localtime_tz function whose return value is the usual localtime time tuple with an additional field reflecting the underlying tm_gmtoff data. Various internal function signatures are modified to support the flow of time zone information, with the gettmarg most noticably changed (probably quite inelegantly - I don't do Python core development). This patch is against the Python 2.4.4 release sources. ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2007-08-04 02:18 Message: Logged In: YES user_id=226443 Originator: YES I've updated the patch to work around redefinition of the tm_isdst field by mktime, which appeared to defeat the measures put in place to support mktimetz. File Added: time-2.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-07-12 11:51 Message: Logged In: YES user_id=849994 Originator: NO I still have a failing test with the latest patch: ====================================================================== FAIL: test_mktimetz (test.test_time.TimeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/gbr/devel/python/Lib/test/test_time.py", line 272, in test_mktimetz self.assert_(time.mktimetz(lt) == time.mktimetz(gt)) AssertionError ====================================================================== FAIL: test_timegm (test.test_time.TimeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/gbr/devel/python/Lib/test/test_time.py", line 253, in test_timegm self.assert_(0 <= dt < 1) AssertionError ---------------------------------------------------------------------- Ran 17 tests in 1.249s FAILED (failures=2) test test_time failed -- errors occurred; run in verbose mode for details 1 test failed: test_time ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-23 01:21 Message: Logged In: YES user_id=226443 Originator: YES I've enhanced your version of the patch to work with the following defines: #define HAVE_TZNAME 1 #undef HAVE_TM_ZONE #undef HAVE_STRUCT_TM_TM_ZONE #undef HAVE_ALTZONE It now uses struct_time in such an environment to provide the extra offset information used in the unixtime function rather than accessing tm_gmtoff. I suppose one could do that for all cases, in fact, since this is done independently of any mktime invocation. The above defines probably represent the next most "sane" of environments after those which have tm_gmtoff. If one starts to remove other things, other more established tests seem to fail, too. File Added: time-1-improved.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-21 11:25 Message: Logged In: YES user_id=849994 Originator: NO I'm attaching a patch with some corrections of mine. It looks very good now. However, your tests fail if HAVE_STRUCT_TM_TM_ZONE is not defined. Can that be repaired? If not, the tests must be skipped in this case. File Added: time-1.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-20 01:20 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_mktimetz_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-20 01:19 Message: Logged In: YES user_id=226443 Originator: YES Yet another round. Fixed timegm, hopefully. Added mktimetz which uses time zone information to convert local and UMT times to UNIX times. Added tests and updated the docs. The usual caveats apply: I'm new to all this, so some things may need sanity checking. File Added: tm_gmtoff_zone_timegm_mktimetz.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-14 23:43 Message: Logged In: YES user_id=226443 Originator: YES Looking at this a bit more, it seems like timegm (which is a pretty desirable function to have) really is as simple as the calendar.timegm function, as far as I can tell: it just throws time zone information away. So the timegm implementation in the patches so far is actually wrong (and broken in the way it attempts to use tm_gmtoff, anyway). However, it might be nice to have a function which actually interprets times properly in order to produce a UNIX time. In other words, something which returns zero for both time.localtime(0) and time.gmtime(0), along with other times which happen to refer to the epoch but in other time zones. I'll upload a fixed patch in the next day or so, hopefully. Sorry for the noise! ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 15:13 Message: Logged In: YES user_id=849994 Originator: NO The patch looks good so far -- but I'd be comfortable with a few more tests, for example for strptime and strftime. Also, the documentation must be updated for every user-visible change (the addition of timegm(), the additional timetuple fields, the now-working (?) %z and %Z in str[fp]time and behavior changes). ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 22:02 Message: Logged In: YES user_id=226443 Originator: YES SourceForge "replay" added new attachment - now deleted. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 21:15 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 18:00 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 18:00 Message: Logged In: YES user_id=226443 Originator: YES New patches against 2.4.4 and the trunk, providing tm_gmtoff, tm_zone, strptime enhancements, a timegm function, plus tests. Where a platform supports the timezone and altzone module attributes but not tm_gmtoff and tm_zone struct tm fields, the code attempts to populate the struct_time fields appropriately, setting None values only if no timezone information exists whatsoever. Limitations include the inability to parse/obtain timezone information beyond that provided by system calls, which is an existing limitation that affects the strptime implementation amongst other things. Again, testing for "deficient" platforms with limited struct tm definitions has been limited. File Added: tm_gmtoff_zone_timegm.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-10 23:59 Message: Logged In: YES user_id=226443 Originator: YES After some thought, perhaps the population of timezone fields is more difficult than described below. Will need to look at other parts of the module code to see what the complications are. What a headache! ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-09 00:57 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-09 00:57 Message: Logged In: YES user_id=226443 Originator: YES Attached are two patches (for 2.4.4 and against the trunk). Apart from the addition of tm_zone, there's one big change: if no timezone fields/members exist on struct tm, the code attempts to read that data from the module's timezone and tzname attributes in order to populate tm_gmtoff and tm_zone; if that fails then both tm_gmtoff and tm_zone are set to None. The logic for all this is tested in test_time.py, but it really needs checking for suitability and testing on something like HP-UX. Details for the logic here: http://devrsrc1.external.hp.com/STKT/impacts/i117.html File Added: tm_gmtoff_zone.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-08 01:52 Message: Logged In: YES user_id=6380 Originator: NO No immediate time for review, but this sounds encouraging. Would you mind adding tm_zone (a string) as well? And how about working relative to the 2.6 trunk (since that's the earliest version where this new feature can be introduced)? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-08 01:28 Message: Logged In: YES user_id=226443 Originator: YES One learns new things about time and stat tuples every day! Made a much cleaner patch which provides an extra named attribute (tm_gmtoff) whilst preserving the 9-tuple layout. Where no time zone support exists, tm_gmtoff is None; otherwise it's the GMT/UTC offset. I had weird test issues with range(7) giving "TypeError: an integer is required" in the code employed (deep down) in test_strptime at some point during development, probably due to memory issues, so it might be worth checking that I've dealt properly with such things. File Added: tm_gmtoff.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 16:52 Message: Logged In: YES user_id=6380 Originator: NO Without even looking at the patch, IMO it would be much better to add tm_gmtoff and tm_zone (and any other fields) to the record returned by localtime(), but in such a way that when accessed as a tuple it still has only 9 fields. There is infrastructure for doing so somewhere for the stat structure that I'm sure could be borrowed or generalized (if it isn't already general). That's much better than adding a new function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 From noreply at sourceforge.net Sun Aug 5 02:09:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Aug 2007 17:09:42 -0700 Subject: [Patches] [ python-Patches-1767787 ] MSVC++8 x86 tkinter build patch for trunk Message-ID: Patches item #1767787, was opened at 2007-08-05 10: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=1767787&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: brotchie (brotch) Assigned to: Nobody/Anonymous (nobody) Summary: MSVC++8 x86 tkinter build patch for trunk Initial Comment: Project file for building tkinter module with MSVC++8 on trunk does not include paths to tcltk include directory and tcl84.lib, tk84.lib libraries. Modifications to _tkinter.vcproj as follows: - Added preprocessor directive WITH_APPINIT to all x86 configurations. - Added tcltk include path at ../../../tcltk/include - Added tcl/tk libs at ../../../tcltk/lib/tcl84.lib and ../../../tcltk/lib/tk84.lib Assumes trunk is at ........\dist\trunk and tcltk is at ........\dist\tcltk. This maintains the structure specified in PCbuild8\readme.txt. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1767787&group_id=5470 From noreply at sourceforge.net Sun Aug 5 03:04:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Aug 2007 18:04:43 -0700 Subject: [Patches] [ python-Patches-1763387 ] socket close fixed Message-ID: Patches item #1763387, was opened at 2007-07-30 06:38 Message generated for change (Comment added) made by jyasskin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1763387&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Closed Resolution: Rejected Priority: 5 Private: No Submitted By: Hasan Diwan (hdiwan650) Assigned to: Nobody/Anonymous (nobody) Summary: socket close fixed Initial Comment: Patch fixes the race condition causing tests to mysteriously fail. ---------------------------------------------------------------------- Comment By: Jeffrey Yasskin (jyasskin) Date: 2007-08-05 01:04 Message: Logged In: YES user_id=581856 Originator: NO On OSX, I've seen both: Exception in thread Thread-2: Traceback (most recent call last): File "/Users/jyasskin/src/python/test_asyncore/Lib/threading.py", line 464, in __bootstrap self.run() File "/Users/jyasskin/src/python/test_asyncore/Lib/threading.py", line 444, in run self.__target(*self.__args, **self.__kwargs) File "Lib/test/test_asyncore.py", line 59, in capture_server serv.bind(("", PORT)) File "", line 1, in bind socket.error: (48, 'Address already in use') after which the interpreter freezes, and ====================================================================== ERROR: test_send (__main__.DispatcherWithSendTests_UsePoll) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_asyncore.py", line 351, in test_send d.send(data) File "/Users/jyasskin/src/python/test_asyncore/Lib/asyncore.py", line 467, in send self.initiate_send() File "/Users/jyasskin/src/python/test_asyncore/Lib/asyncore.py", line 454, in initiate_send num_sent = dispatcher.send(self, self.out_buffer[:512]) File "/Users/jyasskin/src/python/test_asyncore/Lib/asyncore.py", line 334, in send if why[0] == EWOULDBLOCK: TypeError: 'error' object is unindexable I plan to fix the first by binding to port 0 as kuran suggested and using .getsockname()[1] to retrieve the port number, and the second by figuring out the right way to get the errno out of a socket.error. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-07-30 13:28 Message: Logged In: YES user_id=752496 Originator: NO This patch a) does not address the problem that appeared in the tests (it should be solved in a very different way) b) as kuran correctly says, is conceptually wrong (see his comment) Regards, ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2007-07-30 10:06 Message: Logged In: YES user_id=366566 Originator: NO SO_REUSEADDR is a flag. It's not a period of time measured in seconds. So using it with time.sleep() is conceptually broken, even though it happens to do something without raising an exception. And socket.close() really, really, really should not sleep for any length of time at all. It does what it needs to do by making the low-level call, and then it can return. If the port shouldn't be re-used for some period of time, that is up to the application using the socket to deal with. Since this ticket doesn't actually explain what the test failures _are_, I can't really suggest an alternate solution. I assume it is something to do with binding to ports failing, though. In this case, the tests should just be changed to bind port 0, which will force the platform to select an unused port. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1763387&group_id=5470 From noreply at sourceforge.net Sun Aug 5 03:08:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Aug 2007 18:08:05 -0700 Subject: [Patches] [ python-Patches-1763387 ] socket close fixed Message-ID: Patches item #1763387, was opened at 2007-07-30 06:38 Message generated for change (Comment added) made by jyasskin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1763387&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Closed Resolution: Rejected Priority: 5 Private: No Submitted By: Hasan Diwan (hdiwan650) Assigned to: Nobody/Anonymous (nobody) Summary: socket close fixed Initial Comment: Patch fixes the race condition causing tests to mysteriously fail. ---------------------------------------------------------------------- Comment By: Jeffrey Yasskin (jyasskin) Date: 2007-08-05 01:08 Message: Logged In: YES user_id=581856 Originator: NO Forgot to mention, this is on the p3yk branch. I don't know if it affects the trunk. ---------------------------------------------------------------------- Comment By: Jeffrey Yasskin (jyasskin) Date: 2007-08-05 01:04 Message: Logged In: YES user_id=581856 Originator: NO On OSX, I've seen both: Exception in thread Thread-2: Traceback (most recent call last): File "/Users/jyasskin/src/python/test_asyncore/Lib/threading.py", line 464, in __bootstrap self.run() File "/Users/jyasskin/src/python/test_asyncore/Lib/threading.py", line 444, in run self.__target(*self.__args, **self.__kwargs) File "Lib/test/test_asyncore.py", line 59, in capture_server serv.bind(("", PORT)) File "", line 1, in bind socket.error: (48, 'Address already in use') after which the interpreter freezes, and ====================================================================== ERROR: test_send (__main__.DispatcherWithSendTests_UsePoll) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_asyncore.py", line 351, in test_send d.send(data) File "/Users/jyasskin/src/python/test_asyncore/Lib/asyncore.py", line 467, in send self.initiate_send() File "/Users/jyasskin/src/python/test_asyncore/Lib/asyncore.py", line 454, in initiate_send num_sent = dispatcher.send(self, self.out_buffer[:512]) File "/Users/jyasskin/src/python/test_asyncore/Lib/asyncore.py", line 334, in send if why[0] == EWOULDBLOCK: TypeError: 'error' object is unindexable I plan to fix the first by binding to port 0 as kuran suggested and using .getsockname()[1] to retrieve the port number, and the second by figuring out the right way to get the errno out of a socket.error. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-07-30 13:28 Message: Logged In: YES user_id=752496 Originator: NO This patch a) does not address the problem that appeared in the tests (it should be solved in a very different way) b) as kuran correctly says, is conceptually wrong (see his comment) Regards, ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2007-07-30 10:06 Message: Logged In: YES user_id=366566 Originator: NO SO_REUSEADDR is a flag. It's not a period of time measured in seconds. So using it with time.sleep() is conceptually broken, even though it happens to do something without raising an exception. And socket.close() really, really, really should not sleep for any length of time at all. It does what it needs to do by making the low-level call, and then it can return. If the port shouldn't be re-used for some period of time, that is up to the application using the socket to deal with. Since this ticket doesn't actually explain what the test failures _are_, I can't really suggest an alternate solution. I assume it is something to do with binding to ports failing, though. In this case, the tests should just be changed to bind port 0, which will force the platform to select an unused port. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1763387&group_id=5470 From noreply at sourceforge.net Sun Aug 5 09:10:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Aug 2007 00:10:58 -0700 Subject: [Patches] [ python-Patches-1767834 ] test_asyncore fix Message-ID: Patches item #1767834, was opened at 2007-08-05 00:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1767834&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hasan Diwan (hdiwan650) Assigned to: Nobody/Anonymous (nobody) Summary: test_asyncore fix Initial Comment: Fixes the socket.error(48, 'address already in use') intermittent failure by binding to an arbitrary high port and then using getsockname() to retrieve the port. There is a further error with the socket.error module that I think I'd like some hours of sleep before looking at. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1767834&group_id=5470 From noreply at sourceforge.net Sun Aug 5 15:07:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Aug 2007 06:07:07 -0700 Subject: [Patches] [ python-Patches-1767398 ] test_csv struni fixes + unicode support in _csv Message-ID: Patches item #1767398, was opened at 2007-08-03 19:11 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1767398&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Adam Hupp (hupp) Assigned to: Nobody/Anonymous (nobody) Summary: test_csv struni fixes + unicode support in _csv Initial Comment: This patch fixes test_csv.py for the struni branch and modifies _csv.c to support unicode strings. Changes: 1. The test_csv.py failures caused by bytes/str conflicts have been resolved. 2. Uses of mkstemp have been replaced with TemporaryFile in a 'with' block. 3. The _csv.c module now uses unicode for string handling. I've uncommented the unicode read tests in test_csv.py, and added tests for writing unicode content and a unicode delimiter. All tests are now passing on my system (linux). ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2007-08-05 08:07 Message: Logged In: YES user_id=44345 Originator: NO Adam, I've spent some time looking at this patch. Bear in mind this is my first foray into Py3k. Still, I'm confused about what's going on here. I'm hoping you can help me understand the changes. In parse_save_field, you replaced PyString_FromStringAndSize with PyUnicode_FromUnicode, however in get_nullchar_as_None you replaced it with PyUnicode_DecodeASCII. When I execute the csv tests there are a number of assertion errors related to the default delimiter. The traceback goes something like this: FAIL: test_writer_kw_attrs (__main__.Test_Csv) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_csv.py", line 88, in test_writer_kw_attrs self._test_kw_attrs(csv.writer, StringIO()) File "Lib/test/test_csv.py", line 75, in _test_kw_attrs self.assertEqual(obj.dialect.delimiter, ':') AssertionError: s'\x00' != ':' Any idea how to solve that? It looks to me like some Unicode buffer might be getting interpreted as a char *, but I'm not sure. Skip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1767398&group_id=5470 From noreply at sourceforge.net Sun Aug 5 15:45:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Aug 2007 06:45:10 -0700 Subject: [Patches] [ python-Patches-1767834 ] test_asyncore fix Message-ID: Patches item #1767834, was opened at 2007-08-05 02:10 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1767834&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hasan Diwan (hdiwan650) Assigned to: Nobody/Anonymous (nobody) Summary: test_asyncore fix Initial Comment: Fixes the socket.error(48, 'address already in use') intermittent failure by binding to an arbitrary high port and then using getsockname() to retrieve the port. There is a further error with the socket.error module that I think I'd like some hours of sleep before looking at. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-05 08:45 Message: Logged In: YES user_id=1115903 Originator: NO This change has already been made to test_asyncore.py as part of rev 56604 on July 28, 2007. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1767834&group_id=5470 From noreply at sourceforge.net Sun Aug 5 16:33:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Aug 2007 07:33:56 -0700 Subject: [Patches] [ python-Patches-1767834 ] test_asyncore fix Message-ID: Patches item #1767834, was opened at 2007-08-05 07:10 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1767834&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hasan Diwan (hdiwan650) Assigned to: Nobody/Anonymous (nobody) Summary: test_asyncore fix Initial Comment: Fixes the socket.error(48, 'address already in use') intermittent failure by binding to an arbitrary high port and then using getsockname() to retrieve the port. There is a further error with the socket.error module that I think I'd like some hours of sleep before looking at. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-05 14:33 Message: Logged In: YES user_id=849994 Originator: NO Will it be backported to 2.5? ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-05 13:45 Message: Logged In: YES user_id=1115903 Originator: NO This change has already been made to test_asyncore.py as part of rev 56604 on July 28, 2007. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1767834&group_id=5470 From noreply at sourceforge.net Sun Aug 5 17:04:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Aug 2007 08:04:24 -0700 Subject: [Patches] [ python-Patches-1767834 ] test_asyncore fix Message-ID: Patches item #1767834, was opened at 2007-08-05 02:10 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1767834&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hasan Diwan (hdiwan650) Assigned to: Nobody/Anonymous (nobody) Summary: test_asyncore fix Initial Comment: Fixes the socket.error(48, 'address already in use') intermittent failure by binding to an arbitrary high port and then using getsockname() to retrieve the port. There is a further error with the socket.error module that I think I'd like some hours of sleep before looking at. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-05 10:04 Message: Logged In: YES user_id=1115903 Originator: NO I don't know; I wouldn't mind doing it. Are there any special considerations for moving tests back to an older version? I can port the final set of changes to Py3k as well, since it seems that the discussion of this particular problem made its way over to the 3k mailing list at some point. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-05 09:33 Message: Logged In: YES user_id=849994 Originator: NO Will it be backported to 2.5? ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-05 08:45 Message: Logged In: YES user_id=1115903 Originator: NO This change has already been made to test_asyncore.py as part of rev 56604 on July 28, 2007. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1767834&group_id=5470 From noreply at sourceforge.net Sun Aug 5 18:39:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Aug 2007 09:39:08 -0700 Subject: [Patches] [ python-Patches-1767398 ] test_csv struni fixes + unicode support in _csv Message-ID: Patches item #1767398, was opened at 2007-08-03 19:11 Message generated for change (Comment added) made by hupp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1767398&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Adam Hupp (hupp) Assigned to: Nobody/Anonymous (nobody) Summary: test_csv struni fixes + unicode support in _csv Initial Comment: This patch fixes test_csv.py for the struni branch and modifies _csv.c to support unicode strings. Changes: 1. The test_csv.py failures caused by bytes/str conflicts have been resolved. 2. Uses of mkstemp have been replaced with TemporaryFile in a 'with' block. 3. The _csv.c module now uses unicode for string handling. I've uncommented the unicode read tests in test_csv.py, and added tests for writing unicode content and a unicode delimiter. All tests are now passing on my system (linux). ---------------------------------------------------------------------- >Comment By: Adam Hupp (hupp) Date: 2007-08-05 11:39 Message: Logged In: YES user_id=508906 Originator: YES Skip, I think the error you're seeing is being caused by a conversion from Py_UNICODE -> char -> unicode through get_nullchar_as_None. That function should look like this: static PyObject * get_nullchar_as_None(Py_UNICODE c) { if (c == '\0') { Py_INCREF(Py_None); return Py_None; } else return PyUnicode_FromUnicode((Py_UNICODE*)&c, 1); } Unfortunately I'm on the road right now so I can't test it. Is there something I need to do with my build to trigger those assertions? I didn't see them. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-08-05 08:07 Message: Logged In: YES user_id=44345 Originator: NO Adam, I've spent some time looking at this patch. Bear in mind this is my first foray into Py3k. Still, I'm confused about what's going on here. I'm hoping you can help me understand the changes. In parse_save_field, you replaced PyString_FromStringAndSize with PyUnicode_FromUnicode, however in get_nullchar_as_None you replaced it with PyUnicode_DecodeASCII. When I execute the csv tests there are a number of assertion errors related to the default delimiter. The traceback goes something like this: FAIL: test_writer_kw_attrs (__main__.Test_Csv) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_csv.py", line 88, in test_writer_kw_attrs self._test_kw_attrs(csv.writer, StringIO()) File "Lib/test/test_csv.py", line 75, in _test_kw_attrs self.assertEqual(obj.dialect.delimiter, ':') AssertionError: s'\x00' != ':' Any idea how to solve that? It looks to me like some Unicode buffer might be getting interpreted as a char *, but I'm not sure. Skip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1767398&group_id=5470 From noreply at sourceforge.net Sun Aug 5 21:42:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Aug 2007 12:42:54 -0700 Subject: [Patches] [ python-Patches-1638033 ] Add httponly to Cookie module Message-ID: Patches item #1638033, was opened at 2007-01-17 22:07 Message generated for change (Comment added) made by adalx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1638033&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Arvin Schnell (arvins) Assigned to: Nobody/Anonymous (nobody) Summary: Add httponly to Cookie module Initial Comment: Add the Microsoft extension httponly to the Cookie module. ---------------------------------------------------------------------- Comment By: Adal Chiriliuc (adalx) Date: 2007-08-05 22:42 Message: Logged In: YES user_id=1067739 Originator: NO Any word on this? I've tested the patch and it works. I'd like to use this in a Pylons application. ---------------------------------------------------------------------- Comment By: Arvin Schnell (arvins) Date: 2007-03-24 21:13 Message: Logged In: YES user_id=698939 Originator: YES Maybe you are right about the cookie module. I'm not so much into that. But I just read that Firefox 3.0 Alpha 3 finally has support for the httponly attribute (see http://www.mozilla.org/projects/firefox/3.0a3/releasenotes/) so I think it's time that Python will also have the support. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-02-01 01:17 Message: Logged In: YES user_id=261020 Originator: NO I see. That sounds reasonable, but I won't comment on whether it should be applied since this part of module Cookie didn't really make sense to me in the first place (I explain why in my comment of 2006-12-03 16:49 in http://python.org/sf/1372650). ---------------------------------------------------------------------- Comment By: Arvin Schnell (arvins) Date: 2007-01-30 20:45 Message: Logged In: YES user_id=698939 Originator: YES Anybody who sets a cookie with key="httponly" is likely in trouble. I don't know and can't check how the IE behaves in that case. But disallowing this use shouldn't hurt. Use case: I would like to use the httponly attribute in Django. I think it's also useful for other web-frameworks. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-01-30 02:52 Message: Logged In: YES user_id=261020 Originator: NO This is backwards-incompatible, no? The behaviour of Morsel.set() changes (disallowing key="httponly") hence the behaviour of BaseCookie.__setitem__ changes. Do you have a use case? ---------------------------------------------------------------------- Comment By: Arvin Schnell (arvins) Date: 2007-01-19 19:01 Message: Logged In: YES user_id=698939 Originator: YES Sure, I have added some documentation to the patch. File Added: python.diff ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-01-19 17:06 Message: Logged In: YES user_id=764593 Originator: NO The documentation change should say what the attribute does. (It requests the the cookie be hidden from javascript, and available only to http requests.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1638033&group_id=5470 From noreply at sourceforge.net Sun Aug 5 22:41:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Aug 2007 13:41:16 -0700 Subject: [Patches] [ python-Patches-1755841 ] Patch for [ 735515 ] urllib2 should cache 301 redir Message-ID: Patches item #1755841, was opened at 2007-07-18 08:02 Message generated for change (Comment added) made by orsenthil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1755841&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: O.R.Senthil Kumaran (orsenthil) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for [ 735515 ] urllib2 should cache 301 redir Initial Comment: Tracker item python.org/sf/735515 mentions about urllib2 to cache 301 redirections. Attached patch tries to implement the same. Comments on Version 1 of patch: a) Initializes a dictionary to store the redirection. b) If req already in cache, return the previous Request object. c) Otherwise handle the same as 302 and store the Request object. d) Checks for loop errors in 301. Just noticed, that it I missed max-redirect checks. Please comment on this patch, with next version I shall add the max redirect check. ---------------------------------------------------------------------- >Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-06 02:11 Message: Logged In: YES user_id=942711 Originator: YES File Added: urllib2-301-cache.patch ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-08-02 16:25 Message: Logged In: YES user_id=44345 Originator: NO How much extra work would it be to handle 302 redirects and the Expiry header? (I don't want to hold you up from the rest of your SoC tasks. Time's running out.) Note also that you should also include a patch to the urllib2 documentation and, if possible, one or more test cases to exercise the new code. Skip ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-02 09:47 Message: Logged In: YES user_id=942711 Originator: YES Hi Skip, I have implemented Cache redirection for 301 errors only which will be Permanant redirection. Expiry header is not expected for 301 direction, so we might not purge it. RFC 2616 states that if cache is implemented for 302 redirects ( temporary redirects) than Expiry header should be handled and cache purged. For our change it is not required. Thanks, Senthil ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-07-26 20:08 Message: Logged In: YES user_id=44345 Originator: NO Looks reasonable to me, however I wonder if you shouldn't purge cached information periodically. Does RFC 2616 provide any guidance? Skip ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-07-24 09:26 Message: Logged In: YES user_id=942711 Originator: YES I have made some changes to patch. Made it use just the self.cache to cache and follow the same logic for redirect and loop as 302 would follow. I thought this is ok. Did a basic testing to verify if it caught 301 redirect, yes it does. File Added: urllib2-cache-301.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1755841&group_id=5470 From noreply at sourceforge.net Sun Aug 5 22:42:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Aug 2007 13:42:17 -0700 Subject: [Patches] [ python-Patches-1755841 ] Patch for [ 735515 ] urllib2 should cache 301 redir Message-ID: Patches item #1755841, was opened at 2007-07-18 08:02 Message generated for change (Comment added) made by orsenthil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1755841&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: O.R.Senthil Kumaran (orsenthil) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for [ 735515 ] urllib2 should cache 301 redir Initial Comment: Tracker item python.org/sf/735515 mentions about urllib2 to cache 301 redirections. Attached patch tries to implement the same. Comments on Version 1 of patch: a) Initializes a dictionary to store the redirection. b) If req already in cache, return the previous Request object. c) Otherwise handle the same as 302 and store the Request object. d) Checks for loop errors in 301. Just noticed, that it I missed max-redirect checks. Please comment on this patch, with next version I shall add the max redirect check. ---------------------------------------------------------------------- >Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-06 02:12 Message: Logged In: YES user_id=942711 Originator: YES File Added: test_urllib2-cache.patch ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-06 02:11 Message: Logged In: YES user_id=942711 Originator: YES File Added: urllib2-301-cache.patch ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-08-02 16:25 Message: Logged In: YES user_id=44345 Originator: NO How much extra work would it be to handle 302 redirects and the Expiry header? (I don't want to hold you up from the rest of your SoC tasks. Time's running out.) Note also that you should also include a patch to the urllib2 documentation and, if possible, one or more test cases to exercise the new code. Skip ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-02 09:47 Message: Logged In: YES user_id=942711 Originator: YES Hi Skip, I have implemented Cache redirection for 301 errors only which will be Permanant redirection. Expiry header is not expected for 301 direction, so we might not purge it. RFC 2616 states that if cache is implemented for 302 redirects ( temporary redirects) than Expiry header should be handled and cache purged. For our change it is not required. Thanks, Senthil ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-07-26 20:08 Message: Logged In: YES user_id=44345 Originator: NO Looks reasonable to me, however I wonder if you shouldn't purge cached information periodically. Does RFC 2616 provide any guidance? Skip ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-07-24 09:26 Message: Logged In: YES user_id=942711 Originator: YES I have made some changes to patch. Made it use just the self.cache to cache and follow the same logic for redirect and loop as 302 would follow. I thought this is ok. Did a basic testing to verify if it caught 301 redirect, yes it does. File Added: urllib2-cache-301.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1755841&group_id=5470 From noreply at sourceforge.net Sun Aug 5 22:43:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Aug 2007 13:43:05 -0700 Subject: [Patches] [ python-Patches-1755841 ] Patch for [ 735515 ] urllib2 should cache 301 redir Message-ID: Patches item #1755841, was opened at 2007-07-18 08:02 Message generated for change (Comment added) made by orsenthil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1755841&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: O.R.Senthil Kumaran (orsenthil) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for [ 735515 ] urllib2 should cache 301 redir Initial Comment: Tracker item python.org/sf/735515 mentions about urllib2 to cache 301 redirections. Attached patch tries to implement the same. Comments on Version 1 of patch: a) Initializes a dictionary to store the redirection. b) If req already in cache, return the previous Request object. c) Otherwise handle the same as 302 and store the Request object. d) Checks for loop errors in 301. Just noticed, that it I missed max-redirect checks. Please comment on this patch, with next version I shall add the max redirect check. ---------------------------------------------------------------------- >Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-06 02:13 Message: Logged In: YES user_id=942711 Originator: YES File Added: liburllib2.patch ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-06 02:12 Message: Logged In: YES user_id=942711 Originator: YES File Added: test_urllib2-cache.patch ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-06 02:11 Message: Logged In: YES user_id=942711 Originator: YES File Added: urllib2-301-cache.patch ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-08-02 16:25 Message: Logged In: YES user_id=44345 Originator: NO How much extra work would it be to handle 302 redirects and the Expiry header? (I don't want to hold you up from the rest of your SoC tasks. Time's running out.) Note also that you should also include a patch to the urllib2 documentation and, if possible, one or more test cases to exercise the new code. Skip ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-02 09:47 Message: Logged In: YES user_id=942711 Originator: YES Hi Skip, I have implemented Cache redirection for 301 errors only which will be Permanant redirection. Expiry header is not expected for 301 direction, so we might not purge it. RFC 2616 states that if cache is implemented for 302 redirects ( temporary redirects) than Expiry header should be handled and cache purged. For our change it is not required. Thanks, Senthil ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-07-26 20:08 Message: Logged In: YES user_id=44345 Originator: NO Looks reasonable to me, however I wonder if you shouldn't purge cached information periodically. Does RFC 2616 provide any guidance? Skip ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-07-24 09:26 Message: Logged In: YES user_id=942711 Originator: YES I have made some changes to patch. Made it use just the self.cache to cache and follow the same logic for redirect and loop as 302 would follow. I thought this is ok. Did a basic testing to verify if it caught 301 redirect, yes it does. File Added: urllib2-cache-301.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1755841&group_id=5470 From noreply at sourceforge.net Sun Aug 5 22:59:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Aug 2007 13:59:05 -0700 Subject: [Patches] [ python-Patches-1755841 ] Patch for [ 735515 ] urllib2 should cache 301 redir Message-ID: Patches item #1755841, was opened at 2007-07-18 08:02 Message generated for change (Comment added) made by orsenthil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1755841&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: O.R.Senthil Kumaran (orsenthil) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for [ 735515 ] urllib2 should cache 301 redir Initial Comment: Tracker item python.org/sf/735515 mentions about urllib2 to cache 301 redirections. Attached patch tries to implement the same. Comments on Version 1 of patch: a) Initializes a dictionary to store the redirection. b) If req already in cache, return the previous Request object. c) Otherwise handle the same as 302 and store the Request object. d) Checks for loop errors in 301. Just noticed, that it I missed max-redirect checks. Please comment on this patch, with next version I shall add the max redirect check. ---------------------------------------------------------------------- >Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-06 02:29 Message: Logged In: YES user_id=942711 Originator: YES Hi Skip, Added the updated patch and also added patches to test and documentation also. Did some investigation on Cache redirection and expires for 302. IMHO, it should be handled as a separate feature request (based on the need), as we will have to handle the Cache-Control header values in addition to expires header. This would amount for good amount of change w.r.t the HTTPRedirectHandler itself. [http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html section 14.9] As for the current Tracker item, please verify and if found suitable checkin to the Python trunk. Thanks, Senthil ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-06 02:13 Message: Logged In: YES user_id=942711 Originator: YES File Added: liburllib2.patch ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-06 02:12 Message: Logged In: YES user_id=942711 Originator: YES File Added: test_urllib2-cache.patch ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-06 02:11 Message: Logged In: YES user_id=942711 Originator: YES File Added: urllib2-301-cache.patch ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-08-02 16:25 Message: Logged In: YES user_id=44345 Originator: NO How much extra work would it be to handle 302 redirects and the Expiry header? (I don't want to hold you up from the rest of your SoC tasks. Time's running out.) Note also that you should also include a patch to the urllib2 documentation and, if possible, one or more test cases to exercise the new code. Skip ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-02 09:47 Message: Logged In: YES user_id=942711 Originator: YES Hi Skip, I have implemented Cache redirection for 301 errors only which will be Permanant redirection. Expiry header is not expected for 301 direction, so we might not purge it. RFC 2616 states that if cache is implemented for 302 redirects ( temporary redirects) than Expiry header should be handled and cache purged. For our change it is not required. Thanks, Senthil ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-07-26 20:08 Message: Logged In: YES user_id=44345 Originator: NO Looks reasonable to me, however I wonder if you shouldn't purge cached information periodically. Does RFC 2616 provide any guidance? Skip ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-07-24 09:26 Message: Logged In: YES user_id=942711 Originator: YES I have made some changes to patch. Made it use just the self.cache to cache and follow the same logic for redirect and loop as 302 would follow. I thought this is ok. Did a basic testing to verify if it caught 301 redirect, yes it does. File Added: urllib2-cache-301.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1755841&group_id=5470 From noreply at sourceforge.net Sun Aug 5 23:09:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Aug 2007 14:09:18 -0700 Subject: [Patches] [ python-Patches-1765839 ] urllib2-howto - correction Message-ID: Patches item #1765839, was opened at 2007-08-02 09:17 Message generated for change (Comment added) made by orsenthil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1765839&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: O.R.Senthil Kumaran (orsenthil) Assigned to: Georg Brandl (gbrandl) Summary: urllib2-howto - correction Initial Comment: urllib2 howto mentions that "Currently urllib2 does not support fetching of https locations through a proxy. This can be a problem." This is quite misleading, the following ASPN Cookbook recipe shows otherwise. http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/456195 Included a patch to correct the documentation bug. ---------------------------------------------------------------------- >Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-06 02:39 Message: Logged In: YES user_id=942711 Originator: YES agreed. submitting a new patch after making correction to the sentence. File Added: urllib2-howto.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-03 13:23 Message: Logged In: YES user_id=849994 Originator: NO Well, the given recipe enhances urllib2 classes to support that, so the (first) original sentence is correct. Nevertheless, a link to the recipe is helpful. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1765839&group_id=5470 From noreply at sourceforge.net Mon Aug 6 10:05:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Aug 2007 01:05:34 -0700 Subject: [Patches] [ python-Patches-1765839 ] urllib2-howto - correction Message-ID: Patches item #1765839, was opened at 2007-08-02 03:47 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1765839&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.6 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: O.R.Senthil Kumaran (orsenthil) Assigned to: Georg Brandl (gbrandl) Summary: urllib2-howto - correction Initial Comment: urllib2 howto mentions that "Currently urllib2 does not support fetching of https locations through a proxy. This can be a problem." This is quite misleading, the following ASPN Cookbook recipe shows otherwise. http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/456195 Included a patch to correct the documentation bug. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-06 08:05 Message: Logged In: YES user_id=849994 Originator: NO Fixed in rev. 56764. ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-05 21:09 Message: Logged In: YES user_id=942711 Originator: YES agreed. submitting a new patch after making correction to the sentence. File Added: urllib2-howto.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-03 07:53 Message: Logged In: YES user_id=849994 Originator: NO Well, the given recipe enhances urllib2 classes to support that, so the (first) original sentence is correct. Nevertheless, a link to the recipe is helpful. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1765839&group_id=5470 From noreply at sourceforge.net Mon Aug 6 13:37:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Aug 2007 04:37:40 -0700 Subject: [Patches] [ python-Patches-1766304 ] improve xrange.__contains__ Message-ID: Patches item #1766304, was opened at 2007-08-02 18:14 Message generated for change (Comment added) made by stargaming You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1766304&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stargaming (stargaming) Assigned to: Nobody/Anonymous (nobody) Summary: improve xrange.__contains__ Initial Comment: Membership tests for xrange result in loss of xrange's laziness by iterating through every single item. This yields a complexity of O(n) and an unbearable runtime when handling larger ranges. This issue can be fixed by using arithmetic decision instead of generic lookup/iteration. This will boil down the complexity to O(1) and make tests near the start of the range as fast as those near the end. The same technique is already used in item lookups. The fix has been inspired by the "optimizing [x]range" thread in the python-3000-devel mailing list (see http://article.gmane.org/gmane.comp.python.python-3000.devel/8732). A patch to Objects/rangeobject.c is attached. It modifies tp_as_sequence in PyRange_Type to include the sq_contains field and implement the procedure range_contains right there. ---------------------------------------------------------------------- >Comment By: Stargaming (stargaming) Date: 2007-08-06 13:37 Message: Logged In: YES user_id=1491473 Originator: YES The Python 3000 patch required a rewrite from scratch since we can't issue PyIntObject->ob_ival directly any longer. Instead, we use the PyNumber-API now. File Added: rangeobject.c.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1766304&group_id=5470 From noreply at sourceforge.net Mon Aug 6 21:33:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Aug 2007 12:33:25 -0700 Subject: [Patches] [ python-Patches-1767398 ] test_csv struni fixes + unicode support in _csv Message-ID: Patches item #1767398, was opened at 2007-08-03 20:11 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1767398&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Adam Hupp (hupp) >Assigned to: Guido van Rossum (gvanrossum) Summary: test_csv struni fixes + unicode support in _csv Initial Comment: This patch fixes test_csv.py for the struni branch and modifies _csv.c to support unicode strings. Changes: 1. The test_csv.py failures caused by bytes/str conflicts have been resolved. 2. Uses of mkstemp have been replaced with TemporaryFile in a 'with' block. 3. The _csv.c module now uses unicode for string handling. I've uncommented the unicode read tests in test_csv.py, and added tests for writing unicode content and a unicode delimiter. All tests are now passing on my system (linux). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-06 15:33 Message: Logged In: YES user_id=6380 Originator: NO This looked good enough to submit. I had to clean up the whitespace use in the C code. Please next time set your tabs to 8 spaces when editing C code. Also try to conform to the surrounding code's use of spaces or tab (unfortunately this file is inconsistent and sometimes uses spaces, other times tabs -- that's worth a separate cleanup). Committed revision 56777. ---------------------------------------------------------------------- Comment By: Adam Hupp (hupp) Date: 2007-08-05 12:39 Message: Logged In: YES user_id=508906 Originator: YES Skip, I think the error you're seeing is being caused by a conversion from Py_UNICODE -> char -> unicode through get_nullchar_as_None. That function should look like this: static PyObject * get_nullchar_as_None(Py_UNICODE c) { if (c == '\0') { Py_INCREF(Py_None); return Py_None; } else return PyUnicode_FromUnicode((Py_UNICODE*)&c, 1); } Unfortunately I'm on the road right now so I can't test it. Is there something I need to do with my build to trigger those assertions? I didn't see them. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-08-05 09:07 Message: Logged In: YES user_id=44345 Originator: NO Adam, I've spent some time looking at this patch. Bear in mind this is my first foray into Py3k. Still, I'm confused about what's going on here. I'm hoping you can help me understand the changes. In parse_save_field, you replaced PyString_FromStringAndSize with PyUnicode_FromUnicode, however in get_nullchar_as_None you replaced it with PyUnicode_DecodeASCII. When I execute the csv tests there are a number of assertion errors related to the default delimiter. The traceback goes something like this: FAIL: test_writer_kw_attrs (__main__.Test_Csv) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_csv.py", line 88, in test_writer_kw_attrs self._test_kw_attrs(csv.writer, StringIO()) File "Lib/test/test_csv.py", line 75, in _test_kw_attrs self.assertEqual(obj.dialect.delimiter, ':') AssertionError: s'\x00' != ':' Any idea how to solve that? It looks to me like some Unicode buffer might be getting interpreted as a char *, but I'm not sure. Skip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1767398&group_id=5470 From noreply at sourceforge.net Tue Aug 7 07:19:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Aug 2007 22:19:38 -0700 Subject: [Patches] [ python-Patches-1768976 ] Fix for failing test_scriptpackages in py3k-struni Message-ID: Patches item #1768976, was opened at 2007-08-07 08:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1768976&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: Macintosh Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Antti Rasinen (arsatiki) Assigned to: Jack Jansen (jackjansen) Summary: Fix for failing test_scriptpackages in py3k-struni Initial Comment: The test failed because the imported aetools-module compared types directly instead of using isinstance. Fixed that and removed from types import * as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1768976&group_id=5470 From noreply at sourceforge.net Tue Aug 7 07:42:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Aug 2007 22:42:52 -0700 Subject: [Patches] [ python-Patches-1768976 ] Fix for failing test_scriptpackages in py3k-struni Message-ID: Patches item #1768976, was opened at 2007-08-06 22:19 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1768976&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: Macintosh Group: Python 3000 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Antti Rasinen (arsatiki) >Assigned to: Neal Norwitz (nnorwitz) Summary: Fix for failing test_scriptpackages in py3k-struni Initial Comment: The test failed because the imported aetools-module compared types directly instead of using isinstance. Fixed that and removed from types import * as well. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-06 22:42 Message: Logged In: YES user_id=33168 Originator: NO Thanks! I can't test this one right now, but it looks good. Committed revision 56791. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1768976&group_id=5470 From noreply at sourceforge.net Tue Aug 7 08:38:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Aug 2007 23:38:27 -0700 Subject: [Patches] [ python-Patches-1767787 ] MSVC++8 x86 tkinter build patch for trunk Message-ID: Patches item #1767787, was opened at 2007-08-05 02:09 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1767787&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: brotchie (brotch) >Assigned to: Kristj?n Valur (krisvale) Summary: MSVC++8 x86 tkinter build patch for trunk Initial Comment: Project file for building tkinter module with MSVC++8 on trunk does not include paths to tcltk include directory and tcl84.lib, tk84.lib libraries. Modifications to _tkinter.vcproj as follows: - Added preprocessor directive WITH_APPINIT to all x86 configurations. - Added tcltk include path at ../../../tcltk/include - Added tcl/tk libs at ../../../tcltk/lib/tcl84.lib and ../../../tcltk/lib/tk84.lib Assumes trunk is at ........\dist\trunk and tcltk is at ........\dist\tcltk. This maintains the structure specified in PCbuild8\readme.txt. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2007-08-07 08:38 Message: Logged In: YES user_id=21627 Originator: NO Kristjan, can you take a look? If not, please unassign. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1767787&group_id=5470 From noreply at sourceforge.net Tue Aug 7 08:48:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Aug 2007 23:48:06 -0700 Subject: [Patches] [ python-Patches-1667546 ] Time zone-capable variant of time.localtime Message-ID: Patches item #1667546, was opened at 2007-02-23 15:25 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Boddie (pboddie) Assigned to: Georg Brandl (gbrandl) Summary: Time zone-capable variant of time.localtime Initial Comment: Patch related to #1493676: "time.strftime() %z error" This provides a localtime_tz function whose return value is the usual localtime time tuple with an additional field reflecting the underlying tm_gmtoff data. Various internal function signatures are modified to support the flow of time zone information, with the gettmarg most noticably changed (probably quite inelegantly - I don't do Python core development). This patch is against the Python 2.4.4 release sources. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-06 23:48 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the patch Paul. As you know or learned, code that deals with time is tricky. So I'm trying to be overly cautious with these comments. Georg, I think this patch is fine to go in, but would like to see the comments below addressed. I reviewed time-2.diff. Should the regex for 'z' be tightened up in Lib/_strptime.py? (\d\d[0-5]\d) It currently allows nonsense like: +5350. The correct regex would be: ([01]\d|2[0-3])\d\d. I'm not sure it's worth it to go to that much effort. Maybe [0-2]\d[0-5]\d? Probably best to be consistent with the other regexes. What do the others do that parse hour? No lines should be over 80 columns. I noticed a bunch of problems in the test. Also it would be very helpful to breakup the assertions. This code is likely to break (time calculations always do). The more info we have when it breaks, the easier it will be do debug. So code like this: self.assert_(lt.tm_zone is None and not hasattr(time, "tzname") or lt.tm_zone == time.tzname[lt.tm_isdst]) Is probably better written something like this: if lt.tm_zone is None: self.assert_(not hasattr(time, "tzname")) else: self.assertEqual(lt.tm_zone, time.tzname[lt.tm_isdst]) That will provide a better message if the zones aren't equal and will also be clear if the hasattr() test failed. It will also fix the lines over 80 colums. :-) Use assertEqual rather than assert_(x == y). For cases where you have to use assert_(), it would be good to provide an error message about the value(s). Is the code in _tmtotuple_tz_helper and adjusttime() the same? If not, they look very close, can you use a common utility function? Use METH_O instead of METH_VARARGS for the new functions. That way you don't need to call PyArgs_ParseTuple(). You are assuming that there are always at least 10 items in the structseq. Is that valid? For example, what happens if you pickle a struct in python 2.5 and unpickle it in 2.6. Will it have the original length of 9 or the new length of 10-11? The code around PyType_IsSubtype() looks duplicated too. How about a helper function for that? Why is this code commented out at the end? /* && !defined(__GLIBC__) && !defined(__CYGWIN__) */ ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-08-03 17:18 Message: Logged In: YES user_id=226443 Originator: YES I've updated the patch to work around redefinition of the tm_isdst field by mktime, which appeared to defeat the measures put in place to support mktimetz. File Added: time-2.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-07-12 02:51 Message: Logged In: YES user_id=849994 Originator: NO I still have a failing test with the latest patch: ====================================================================== FAIL: test_mktimetz (test.test_time.TimeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/gbr/devel/python/Lib/test/test_time.py", line 272, in test_mktimetz self.assert_(time.mktimetz(lt) == time.mktimetz(gt)) AssertionError ====================================================================== FAIL: test_timegm (test.test_time.TimeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/gbr/devel/python/Lib/test/test_time.py", line 253, in test_timegm self.assert_(0 <= dt < 1) AssertionError ---------------------------------------------------------------------- Ran 17 tests in 1.249s FAILED (failures=2) test test_time failed -- errors occurred; run in verbose mode for details 1 test failed: test_time ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-22 17:21 Message: Logged In: YES user_id=226443 Originator: YES I've enhanced your version of the patch to work with the following defines: #define HAVE_TZNAME 1 #undef HAVE_TM_ZONE #undef HAVE_STRUCT_TM_TM_ZONE #undef HAVE_ALTZONE It now uses struct_time in such an environment to provide the extra offset information used in the unixtime function rather than accessing tm_gmtoff. I suppose one could do that for all cases, in fact, since this is done independently of any mktime invocation. The above defines probably represent the next most "sane" of environments after those which have tm_gmtoff. If one starts to remove other things, other more established tests seem to fail, too. File Added: time-1-improved.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-21 03:25 Message: Logged In: YES user_id=849994 Originator: NO I'm attaching a patch with some corrections of mine. It looks very good now. However, your tests fail if HAVE_STRUCT_TM_TM_ZONE is not defined. Can that be repaired? If not, the tests must be skipped in this case. File Added: time-1.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-19 17:20 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_mktimetz_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-19 17:19 Message: Logged In: YES user_id=226443 Originator: YES Yet another round. Fixed timegm, hopefully. Added mktimetz which uses time zone information to convert local and UMT times to UNIX times. Added tests and updated the docs. The usual caveats apply: I'm new to all this, so some things may need sanity checking. File Added: tm_gmtoff_zone_timegm_mktimetz.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-14 15:43 Message: Logged In: YES user_id=226443 Originator: YES Looking at this a bit more, it seems like timegm (which is a pretty desirable function to have) really is as simple as the calendar.timegm function, as far as I can tell: it just throws time zone information away. So the timegm implementation in the patches so far is actually wrong (and broken in the way it attempts to use tm_gmtoff, anyway). However, it might be nice to have a function which actually interprets times properly in order to produce a UNIX time. In other words, something which returns zero for both time.localtime(0) and time.gmtime(0), along with other times which happen to refer to the epoch but in other time zones. I'll upload a fixed patch in the next day or so, hopefully. Sorry for the noise! ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 07:13 Message: Logged In: YES user_id=849994 Originator: NO The patch looks good so far -- but I'd be comfortable with a few more tests, for example for strptime and strftime. Also, the documentation must be updated for every user-visible change (the addition of timegm(), the additional timetuple fields, the now-working (?) %z and %Z in str[fp]time and behavior changes). ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 14:02 Message: Logged In: YES user_id=226443 Originator: YES SourceForge "replay" added new attachment - now deleted. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 13:15 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 10:00 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 10:00 Message: Logged In: YES user_id=226443 Originator: YES New patches against 2.4.4 and the trunk, providing tm_gmtoff, tm_zone, strptime enhancements, a timegm function, plus tests. Where a platform supports the timezone and altzone module attributes but not tm_gmtoff and tm_zone struct tm fields, the code attempts to populate the struct_time fields appropriately, setting None values only if no timezone information exists whatsoever. Limitations include the inability to parse/obtain timezone information beyond that provided by system calls, which is an existing limitation that affects the strptime implementation amongst other things. Again, testing for "deficient" platforms with limited struct tm definitions has been limited. File Added: tm_gmtoff_zone_timegm.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-10 14:59 Message: Logged In: YES user_id=226443 Originator: YES After some thought, perhaps the population of timezone fields is more difficult than described below. Will need to look at other parts of the module code to see what the complications are. What a headache! ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-08 15:57 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-08 15:57 Message: Logged In: YES user_id=226443 Originator: YES Attached are two patches (for 2.4.4 and against the trunk). Apart from the addition of tm_zone, there's one big change: if no timezone fields/members exist on struct tm, the code attempts to read that data from the module's timezone and tzname attributes in order to populate tm_gmtoff and tm_zone; if that fails then both tm_gmtoff and tm_zone are set to None. The logic for all this is tested in test_time.py, but it really needs checking for suitability and testing on something like HP-UX. Details for the logic here: http://devrsrc1.external.hp.com/STKT/impacts/i117.html File Added: tm_gmtoff_zone.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-07 16:52 Message: Logged In: YES user_id=6380 Originator: NO No immediate time for review, but this sounds encouraging. Would you mind adding tm_zone (a string) as well? And how about working relative to the 2.6 trunk (since that's the earliest version where this new feature can be introduced)? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-07 16:28 Message: Logged In: YES user_id=226443 Originator: YES One learns new things about time and stat tuples every day! Made a much cleaner patch which provides an extra named attribute (tm_gmtoff) whilst preserving the 9-tuple layout. Where no time zone support exists, tm_gmtoff is None; otherwise it's the GMT/UTC offset. I had weird test issues with range(7) giving "TypeError: an integer is required" in the code employed (deep down) in test_strptime at some point during development, probably due to memory issues, so it might be worth checking that I've dealt properly with such things. File Added: tm_gmtoff.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 07:52 Message: Logged In: YES user_id=6380 Originator: NO Without even looking at the patch, IMO it would be much better to add tm_gmtoff and tm_zone (and any other fields) to the record returned by localtime(), but in such a way that when accessed as a tuple it still has only 9 fields. There is infrastructure for doing so somewhere for the stat structure that I'm sure could be borrowed or generalized (if it isn't already general). That's much better than adding a new function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 From noreply at sourceforge.net Tue Aug 7 09:11:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Aug 2007 00:11:51 -0700 Subject: [Patches] [ python-Patches-1769016 ] Fix for failing test_plistlib in py3k-struni Message-ID: Patches item #1769016, was opened at 2007-08-07 17:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1769016&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: Macintosh Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: brotchie (brotch) Assigned to: Jack Jansen (jackjansen) Summary: Fix for failing test_plistlib in py3k-struni Initial Comment: changes to plistlib.py: - expat expects bytes so changed from using cStringIO to io.BytesIO - renamed readPlistFromString, writePlistToString -> readPlistFromBytes, writePlistToBytes to reflect the change to BytesIO - plistlib.Data now excepts and wraps a bytes object changes to test_plistlib.py: - transitioned To/FromString calls to To/FromBytes - removed StringIO and cStringIO specific tests and replaced with an equivalent BytesIO test test_plistlib.py now passes, tested on OSX Tiger 10.4.10. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1769016&group_id=5470 From noreply at sourceforge.net Tue Aug 7 15:04:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Aug 2007 06:04:30 -0700 Subject: [Patches] [ python-Patches-1767787 ] MSVC++8 x86 tkinter build patch for trunk Message-ID: Patches item #1767787, was opened at 2007-08-05 00:09 Message generated for change (Comment added) made by krisvale You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1767787&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: brotchie (brotch) Assigned to: Kristj?n Valur (krisvale) Summary: MSVC++8 x86 tkinter build patch for trunk Initial Comment: Project file for building tkinter module with MSVC++8 on trunk does not include paths to tcltk include directory and tcl84.lib, tk84.lib libraries. Modifications to _tkinter.vcproj as follows: - Added preprocessor directive WITH_APPINIT to all x86 configurations. - Added tcltk include path at ../../../tcltk/include - Added tcl/tk libs at ../../../tcltk/lib/tcl84.lib and ../../../tcltk/lib/tk84.lib Assumes trunk is at ........\dist\trunk and tcltk is at ........\dist\tcltk. This maintains the structure specified in PCbuild8\readme.txt. ---------------------------------------------------------------------- >Comment By: Kristj?n Valur (krisvale) Date: 2007-08-07 13:04 Message: Logged In: YES user_id=1262199 Originator: NO looks fine to me, at least from viewing the patch file. I couldn??t apply it, it is not a regular patch file. It affects only the tkinter.vcproj project. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-08-07 06:38 Message: Logged In: YES user_id=21627 Originator: NO Kristjan, can you take a look? If not, please unassign. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1767787&group_id=5470 From aopbg at planvista.com Tue Aug 7 16:22:25 2007 From: aopbg at planvista.com (Net) Date: Tue, 7 Aug 2007 10:22:25 -0400 Subject: [Patches] doc Message-ID: <001d01c7d8fe$60c95ad0$eab37e7f@pdj> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20070807/19ab5c47/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: doc.pdf Type: application/pdf Size: 24633 bytes Desc: not available Url : http://mail.python.org/pipermail/patches/attachments/20070807/19ab5c47/attachment-0001.pdf From noreply at sourceforge.net Tue Aug 7 16:27:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Aug 2007 07:27:04 -0700 Subject: [Patches] [ python-Patches-1769016 ] Fix for failing test_plistlib in py3k-struni Message-ID: Patches item #1769016, was opened at 2007-08-07 03:11 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1769016&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: Macintosh Group: Python 3000 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: brotchie (brotch) >Assigned to: Guido van Rossum (gvanrossum) Summary: Fix for failing test_plistlib in py3k-struni Initial Comment: changes to plistlib.py: - expat expects bytes so changed from using cStringIO to io.BytesIO - renamed readPlistFromString, writePlistToString -> readPlistFromBytes, writePlistToBytes to reflect the change to BytesIO - plistlib.Data now excepts and wraps a bytes object changes to test_plistlib.py: - transitioned To/FromString calls to To/FromBytes - removed StringIO and cStringIO specific tests and replaced with an equivalent BytesIO test test_plistlib.py now passes, tested on OSX Tiger 10.4.10. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-07 10:27 Message: Logged In: YES user_id=6380 Originator: NO Thanks! Committed revision 56800. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1769016&group_id=5470 From noreply at sourceforge.net Tue Aug 7 16:27:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Aug 2007 07:27:53 -0700 Subject: [Patches] [ python-Patches-1768976 ] Fix for failing test_scriptpackages in py3k-struni Message-ID: Patches item #1768976, was opened at 2007-08-07 01:19 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1768976&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: Macintosh Group: Python 3000 Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Antti Rasinen (arsatiki) Assigned to: Neal Norwitz (nnorwitz) Summary: Fix for failing test_scriptpackages in py3k-struni Initial Comment: The test failed because the imported aetools-module compared types directly instead of using isinstance. Fixed that and removed from types import * as well. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-07 10:27 Message: Logged In: YES user_id=6380 Originator: NO FYI, test passes. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-07 01:42 Message: Logged In: YES user_id=33168 Originator: NO Thanks! I can't test this one right now, but it looks good. Committed revision 56791. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1768976&group_id=5470 From noreply at sourceforge.net Tue Aug 7 19:49:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Aug 2007 10:49:56 -0700 Subject: [Patches] [ python-Patches-1768976 ] Fix for failing test_scriptpackages in py3k-struni Message-ID: Patches item #1768976, was opened at 2007-08-07 08:19 Message generated for change (Comment added) made by arsatiki You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1768976&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: Macintosh Group: Python 3000 Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Antti Rasinen (arsatiki) Assigned to: Neal Norwitz (nnorwitz) Summary: Fix for failing test_scriptpackages in py3k-struni Initial Comment: The test failed because the imported aetools-module compared types directly instead of using isinstance. Fixed that and removed from types import * as well. ---------------------------------------------------------------------- >Comment By: Antti Rasinen (arsatiki) Date: 2007-08-07 20:49 Message: Logged In: YES user_id=1862041 Originator: YES I re-examined the code again. The comments clearly state that it should be a four-byte element. I changed the isinstance-test to isinstance(signature, bytes) and the test passes, again. I have a fear that the tests do not actually cover that part of code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-07 17:27 Message: Logged In: YES user_id=6380 Originator: NO FYI, test passes. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-07 08:42 Message: Logged In: YES user_id=33168 Originator: NO Thanks! I can't test this one right now, but it looks good. Committed revision 56791. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1768976&group_id=5470 From noreply at sourceforge.net Wed Aug 8 04:47:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Aug 2007 19:47:22 -0700 Subject: [Patches] [ python-Patches-1769767 ] struni: test_xml_etree_c Message-ID: Patches item #1769767, was opened at 2007-08-08 02:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1769767&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joe Gregorio (jcgregorio) Assigned to: Nobody/Anonymous (nobody) Summary: struni: test_xml_etree_c Initial Comment: This patch fixes enough so that all the tests pass, but I'm not sure it fixes all the str to unicode conversion issues. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1769767&group_id=5470 From noreply at sourceforge.net Wed Aug 8 08:56:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Aug 2007 23:56:16 -0700 Subject: [Patches] [ python-Patches-1769767 ] struni: test_xml_etree_c Message-ID: Patches item #1769767, was opened at 2007-08-07 19:47 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1769767&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 3000 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Joe Gregorio (jcgregorio) >Assigned to: Neal Norwitz (nnorwitz) Summary: struni: test_xml_etree_c Initial Comment: This patch fixes enough so that all the tests pass, but I'm not sure it fixes all the str to unicode conversion issues. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-07 23:56 Message: Logged In: YES user_id=33168 Originator: NO This seems like a good start. Thanks for the patch! I suspect all the uses of PyString need to be converted to PyUnicode. Committed revision 56824. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1769767&group_id=5470 From noreply at sourceforge.net Wed Aug 8 09:39:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Aug 2007 00:39:55 -0700 Subject: [Patches] [ python-Patches-1752175 ] fixing 2.5.1 build with unicode and dynamic loading disabled Message-ID: Patches item #1752175, was opened at 2007-07-11 12:40 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1752175&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexander Neundorf (neundorf) Assigned to: Nobody/Anonymous (nobody) Summary: fixing 2.5.1 build with unicode and dynamic loading disabled Initial Comment: I'm currently porting python to some platforms with limited capabilities and so I thought it would be a good idea to subscribe here. While doing the porting, I found two small problems in Python 2.5.1: If Py_USING_UNICODE is disabled, in Python/ast.c decode_unicode() still calls unicode-related functions, which leads to undefined references when linking. If HAVE_DYNAMIC_LOADING is disabled, in Python/import.c _PyImport_DynLoadFiletab is still initialized, which also leads to undefined references when linking, since then no source file which defines this variable is used. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-08 00:39 Message: Logged In: YES user_id=33168 Originator: NO No, hopefully someone will get to this soon. These files aren't likely to have changed between 2.5 and trunk. Although it is generally preferable to provide a patch against trunk in case things have changed. Georg may have fixed one or both of these recently. ---------------------------------------------------------------------- Comment By: Alexander Neundorf (neundorf) Date: 2007-08-03 09:14 Message: Logged In: YES user_id=93933 Originator: YES Any chance this could be committed to the 2.5 branch ? Or should I post a patch against curren trunk ? Alex ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1752175&group_id=5470 From noreply at sourceforge.net Wed Aug 8 14:42:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Aug 2007 05:42:58 -0700 Subject: [Patches] [ python-Patches-1770008 ] Remove cStringIO usage Message-ID: Patches item #1770008, was opened at 2007-08-08 14: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=1770008&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Nobody/Anonymous (nobody) Summary: Remove cStringIO usage Initial Comment: The patch removes the import of cStringIO from all Python files and disabled the cStringIO module. It leaves the file around. Open problems: * How should io.StringIO handle buffer objects? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1770008&group_id=5470 From noreply at sourceforge.net Wed Aug 8 14:52:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Aug 2007 05:52:21 -0700 Subject: [Patches] [ python-Patches-1770008 ] Remove cStringIO usage Message-ID: Patches item #1770008, was opened at 2007-08-08 14:42 Message generated for change (Comment added) made by tiran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1770008&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Nobody/Anonymous (nobody) Summary: Remove cStringIO usage Initial Comment: The patch removes the import of cStringIO from all Python files and disabled the cStringIO module. It leaves the file around. Open problems: * How should io.StringIO handle buffer objects? ---------------------------------------------------------------------- >Comment By: Christian Heimes (tiran) Date: 2007-08-08 14:52 Message: Logged In: YES user_id=560817 Originator: YES File Added: stringio_deprecation.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1770008&group_id=5470 From noreply at sourceforge.net Wed Aug 8 15:06:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Aug 2007 06:06:16 -0700 Subject: [Patches] [ python-Patches-1770008 ] Remove cStringIO usage Message-ID: Patches item #1770008, was opened at 2007-08-08 12:42 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1770008&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Nobody/Anonymous (nobody) Summary: Remove cStringIO usage Initial Comment: The patch removes the import of cStringIO from all Python files and disabled the cStringIO module. It leaves the file around. Open problems: * How should io.StringIO handle buffer objects? ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-08 13:06 Message: Logged In: YES user_id=849994 Originator: NO I guess that if you want to handle buffer objects, you should be using io.BytesIO. ---------------------------------------------------------------------- Comment By: Christian Heimes (tiran) Date: 2007-08-08 12:52 Message: Logged In: YES user_id=560817 Originator: YES File Added: stringio_deprecation.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1770008&group_id=5470 From noreply at sourceforge.net Wed Aug 8 15:57:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Aug 2007 06:57:16 -0700 Subject: [Patches] [ python-Patches-1770008 ] Remove cStringIO usage Message-ID: Patches item #1770008, was opened at 2007-08-08 14:42 Message generated for change (Comment added) made by tiran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1770008&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Nobody/Anonymous (nobody) Summary: Remove cStringIO usage Initial Comment: The patch removes the import of cStringIO from all Python files and disabled the cStringIO module. It leaves the file around. Open problems: * How should io.StringIO handle buffer objects? ---------------------------------------------------------------------- >Comment By: Christian Heimes (tiran) Date: 2007-08-08 15:57 Message: Logged In: YES user_id=560817 Originator: YES The new patch also removes StringIO and adds a facade cStringIO. Importing StringIO and cStringIO is deprecated and the imports fall back to io.StringIO. File Added: remove_stringio.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-08 15:06 Message: Logged In: YES user_id=849994 Originator: NO I guess that if you want to handle buffer objects, you should be using io.BytesIO. ---------------------------------------------------------------------- Comment By: Christian Heimes (tiran) Date: 2007-08-08 14:52 Message: Logged In: YES user_id=560817 Originator: YES File Added: stringio_deprecation.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1770008&group_id=5470 From noreply at sourceforge.net Wed Aug 8 18:09:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Aug 2007 09:09:44 -0700 Subject: [Patches] [ python-Patches-1736190 ] asyncore/asynchat patches Message-ID: Patches item #1736190, was opened at 2007-06-12 19:37 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1736190&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 Private: No Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Josiah Carlson (josiahcarlson) Summary: asyncore/asynchat patches Initial Comment: There are a handful of outstanding asyncore/asynchat related bugs in the tracker. This patch seeks to handle all of the issues with the exception of windows-specific socket errors from 658749 . In particular, it takes pieces of patches 909005 and 1736101, to address some issues raised there, as well as the bugs: 539444, 760475, 777588, 889153, 953599, 1025525, and 1063924. In some cases where it could potentially handle fewer exceptions (see the send method), I have opted to handle more of them due to testing actually producing them. It adds test cases from patch 909005. It adds two new sample methods to asynchat.async_chat _get_data and _collect_incoming_data to be used as examples for handling incoming buffers. It removes the simple_producer and fifo classes from asynchat, but accepts work-alikes to the asynchat.async_chat.push_with_producer method. It further fixes an unreported violated invariant in asynchat.async_chat.handle_read() . It also produces a useful error message when asyncore.dispatcher.handle_expt_evt is called if the base handle_expt has not been overwritten. This patch should be applied to the trunk. The new methods, and removal of the two classes should not be included in patches to 2.5 maintenance (don't add the methods and don't remove the classes). Basically everything else should work as it did before (with better error handling), unless someone was monkey-patching asyncore.dispatcher.handle_expt . ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-08 11:09 Message: Logged In: YES user_id=1115903 Originator: NO This patch removes two public--and documented--classes from asynchat (simple_producer and fifo). Even if the proposed changes to asynchat make them utterly worthless, I thought it was general policy to deprecate public items for a release or two before removing them. Is this the case even when they're as simple as these two classes? ---------------------------------------------------------------------- Comment By: billiejoex (billiejoex) Date: 2007-07-11 10:16 Message: Logged In: YES user_id=1357589 Originator: NO Good work. I would only rencommend to include documentation for asyncore.close_all function, actually not documented yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1736190&group_id=5470 From noreply at sourceforge.net Wed Aug 8 21:51:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Aug 2007 12:51:12 -0700 Subject: [Patches] [ python-Patches-1770355 ] ctypes: c_char now uses bytes and not str (unicode) Message-ID: Patches item #1770355, was opened at 2007-08-08 21:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1770355&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: STINNER Victor (haypo) Assigned to: Nobody/Anonymous (nobody) Summary: ctypes: c_char now uses bytes and not str (unicode) Initial Comment: Hi, I hear Guido's request to fix last py3k-struni bugs. I downloaded subversion trunk and started to work on ctypes tests. The problem is that ctypes c_char (and c_char_p) creates unicode string instead of byte string. I attached a proposition (patch) to change this behaviour (use bytes for c_char). So in next example, it will display 'bytes' and not 'str': from ctypes import c_buffer, c_char buf = c_buffer("abcdef") print (type(buf[0])) Other behaviour changes: - repr(c_char) adds a "b". Eg. repr(c_char('x')) is "c_char(b'x')" instead of "c_char('x')" - bytes is mutable whereas str is not: this may break some modules based on ctypes Victor Stinner aka haypo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1770355&group_id=5470 From noreply at sourceforge.net Wed Aug 8 21:51:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Aug 2007 12:51:37 -0700 Subject: [Patches] [ python-Patches-1770355 ] ctypes: c_char now uses bytes and not str (unicode) Message-ID: Patches item #1770355, was opened at 2007-08-08 21:51 Message generated for change (Settings changed) made by haypo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1770355&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: STINNER Victor (haypo) >Assigned to: Thomas Heller (theller) Summary: ctypes: c_char now uses bytes and not str (unicode) Initial Comment: Hi, I hear Guido's request to fix last py3k-struni bugs. I downloaded subversion trunk and started to work on ctypes tests. The problem is that ctypes c_char (and c_char_p) creates unicode string instead of byte string. I attached a proposition (patch) to change this behaviour (use bytes for c_char). So in next example, it will display 'bytes' and not 'str': from ctypes import c_buffer, c_char buf = c_buffer("abcdef") print (type(buf[0])) Other behaviour changes: - repr(c_char) adds a "b". Eg. repr(c_char('x')) is "c_char(b'x')" instead of "c_char('x')" - bytes is mutable whereas str is not: this may break some modules based on ctypes Victor Stinner aka haypo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1770355&group_id=5470 From noreply at sourceforge.net Wed Aug 8 21:54:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Aug 2007 12:54:36 -0700 Subject: [Patches] [ python-Patches-1770355 ] ctypes: c_char now uses bytes and not str (unicode) Message-ID: Patches item #1770355, was opened at 2007-08-08 21:51 Message generated for change (Comment added) made by haypo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1770355&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 3000 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: STINNER Victor (haypo) Assigned to: Thomas Heller (theller) Summary: ctypes: c_char now uses bytes and not str (unicode) Initial Comment: Hi, I hear Guido's request to fix last py3k-struni bugs. I downloaded subversion trunk and started to work on ctypes tests. The problem is that ctypes c_char (and c_char_p) creates unicode string instead of byte string. I attached a proposition (patch) to change this behaviour (use bytes for c_char). So in next example, it will display 'bytes' and not 'str': from ctypes import c_buffer, c_char buf = c_buffer("abcdef") print (type(buf[0])) Other behaviour changes: - repr(c_char) adds a "b". Eg. repr(c_char('x')) is "c_char(b'x')" instead of "c_char('x')" - bytes is mutable whereas str is not: this may break some modules based on ctypes Victor Stinner aka haypo ---------------------------------------------------------------------- >Comment By: STINNER Victor (haypo) Date: 2007-08-08 21:54 Message: Logged In: YES user_id=365388 Originator: YES Ooops, Thomas Heller already commited it (r56838). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1770355&group_id=5470 From noreply at sourceforge.net Wed Aug 8 22:41:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Aug 2007 13:41:15 -0700 Subject: [Patches] [ python-Patches-1770008 ] Remove cStringIO usage Message-ID: Patches item #1770008, was opened at 2007-08-08 08:42 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1770008&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heimes (tiran) >Assigned to: Guido van Rossum (gvanrossum) Summary: Remove cStringIO usage Initial Comment: The patch removes the import of cStringIO from all Python files and disabled the cStringIO module. It leaves the file around. Open problems: * How should io.StringIO handle buffer objects? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-08 16:41 Message: Logged In: YES user_id=6380 Originator: NO I'll take this. Thanks for the work! There are a few tests that break due to this, I'll look into these. I'll probably kill StringIO and cStringIO hard rather than adding deprecations (there's already a 2to3 fixer that fixes most StringIO references). ---------------------------------------------------------------------- Comment By: Christian Heimes (tiran) Date: 2007-08-08 09:57 Message: Logged In: YES user_id=560817 Originator: YES The new patch also removes StringIO and adds a facade cStringIO. Importing StringIO and cStringIO is deprecated and the imports fall back to io.StringIO. File Added: remove_stringio.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-08 09:06 Message: Logged In: YES user_id=849994 Originator: NO I guess that if you want to handle buffer objects, you should be using io.BytesIO. ---------------------------------------------------------------------- Comment By: Christian Heimes (tiran) Date: 2007-08-08 08:52 Message: Logged In: YES user_id=560817 Originator: YES File Added: stringio_deprecation.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1770008&group_id=5470 From noreply at sourceforge.net Wed Aug 8 22:41:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Aug 2007 13:41:46 -0700 Subject: [Patches] [ python-Patches-1767834 ] test_asyncore fix Message-ID: Patches item #1767834, was opened at 2007-08-05 03:10 Message generated for change (Settings changed) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1767834&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 3000 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Hasan Diwan (hdiwan650) Assigned to: Nobody/Anonymous (nobody) Summary: test_asyncore fix Initial Comment: Fixes the socket.error(48, 'address already in use') intermittent failure by binding to an arbitrary high port and then using getsockname() to retrieve the port. There is a further error with the socket.error module that I think I'd like some hours of sleep before looking at. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-05 11:04 Message: Logged In: YES user_id=1115903 Originator: NO I don't know; I wouldn't mind doing it. Are there any special considerations for moving tests back to an older version? I can port the final set of changes to Py3k as well, since it seems that the discussion of this particular problem made its way over to the 3k mailing list at some point. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-05 10:33 Message: Logged In: YES user_id=849994 Originator: NO Will it be backported to 2.5? ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-05 09:45 Message: Logged In: YES user_id=1115903 Originator: NO This change has already been made to test_asyncore.py as part of rev 56604 on July 28, 2007. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1767834&group_id=5470 From noreply at sourceforge.net Thu Aug 9 03:04:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Aug 2007 18:04:33 -0700 Subject: [Patches] [ python-Patches-1770008 ] Remove cStringIO usage Message-ID: Patches item #1770008, was opened at 2007-08-08 08:42 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1770008&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 3000 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Guido van Rossum (gvanrossum) Summary: Remove cStringIO usage Initial Comment: The patch removes the import of cStringIO from all Python files and disabled the cStringIO module. It leaves the file around. Open problems: * How should io.StringIO handle buffer objects? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-08 21:04 Message: Logged In: YES user_id=6380 Originator: NO Thanks! Committed revision 56841. I had to change some places to use BytesIO instead of StringIO, and I had to work hard on a few modules, esp. uu.py. But now all tests pass (except the ones that didn't pass before). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-08 16:41 Message: Logged In: YES user_id=6380 Originator: NO I'll take this. Thanks for the work! There are a few tests that break due to this, I'll look into these. I'll probably kill StringIO and cStringIO hard rather than adding deprecations (there's already a 2to3 fixer that fixes most StringIO references). ---------------------------------------------------------------------- Comment By: Christian Heimes (tiran) Date: 2007-08-08 09:57 Message: Logged In: YES user_id=560817 Originator: YES The new patch also removes StringIO and adds a facade cStringIO. Importing StringIO and cStringIO is deprecated and the imports fall back to io.StringIO. File Added: remove_stringio.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-08 09:06 Message: Logged In: YES user_id=849994 Originator: NO I guess that if you want to handle buffer objects, you should be using io.BytesIO. ---------------------------------------------------------------------- Comment By: Christian Heimes (tiran) Date: 2007-08-08 08:52 Message: Logged In: YES user_id=560817 Originator: YES File Added: stringio_deprecation.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1770008&group_id=5470 From noreply at sourceforge.net Fri Aug 10 01:16:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Aug 2007 16:16:26 -0700 Subject: [Patches] [ python-Patches-1667546 ] Time zone-capable variant of time.localtime Message-ID: Patches item #1667546, was opened at 2007-02-24 00:25 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Boddie (pboddie) Assigned to: Georg Brandl (gbrandl) Summary: Time zone-capable variant of time.localtime Initial Comment: Patch related to #1493676: "time.strftime() %z error" This provides a localtime_tz function whose return value is the usual localtime time tuple with an additional field reflecting the underlying tm_gmtoff data. Various internal function signatures are modified to support the flow of time zone information, with the gettmarg most noticably changed (probably quite inelegantly - I don't do Python core development). This patch is against the Python 2.4.4 release sources. ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2007-08-10 01:16 Message: Logged In: YES user_id=226443 Originator: YES I've fixed some of the tests and consolidated some common code. I haven't looked at METH_O yet because I'm not familiar with this stuff, and I can't find a usable function to get the length of structure sequences which includes the non-visible elements. I also don't recall why the ifdef was changed, but I can look into that. As for the regexes, there's probably no limit on how many hours an offset can be, so it may not make much sense to be too clever about it. I'd like to look at the glibc code for mktime to verify my assumptions. Right now I don't have that much confidence in the new functions in the patch because I may have misunderstood how certain C library functions work. However, I have tested the revised code in DST and non-DST for CEST and CET respectively (using User Mode Linux). File Added: time-3.diff ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-07 08:48 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the patch Paul. As you know or learned, code that deals with time is tricky. So I'm trying to be overly cautious with these comments. Georg, I think this patch is fine to go in, but would like to see the comments below addressed. I reviewed time-2.diff. Should the regex for 'z' be tightened up in Lib/_strptime.py? (\d\d[0-5]\d) It currently allows nonsense like: +5350. The correct regex would be: ([01]\d|2[0-3])\d\d. I'm not sure it's worth it to go to that much effort. Maybe [0-2]\d[0-5]\d? Probably best to be consistent with the other regexes. What do the others do that parse hour? No lines should be over 80 columns. I noticed a bunch of problems in the test. Also it would be very helpful to breakup the assertions. This code is likely to break (time calculations always do). The more info we have when it breaks, the easier it will be do debug. So code like this: self.assert_(lt.tm_zone is None and not hasattr(time, "tzname") or lt.tm_zone == time.tzname[lt.tm_isdst]) Is probably better written something like this: if lt.tm_zone is None: self.assert_(not hasattr(time, "tzname")) else: self.assertEqual(lt.tm_zone, time.tzname[lt.tm_isdst]) That will provide a better message if the zones aren't equal and will also be clear if the hasattr() test failed. It will also fix the lines over 80 colums. :-) Use assertEqual rather than assert_(x == y). For cases where you have to use assert_(), it would be good to provide an error message about the value(s). Is the code in _tmtotuple_tz_helper and adjusttime() the same? If not, they look very close, can you use a common utility function? Use METH_O instead of METH_VARARGS for the new functions. That way you don't need to call PyArgs_ParseTuple(). You are assuming that there are always at least 10 items in the structseq. Is that valid? For example, what happens if you pickle a struct in python 2.5 and unpickle it in 2.6. Will it have the original length of 9 or the new length of 10-11? The code around PyType_IsSubtype() looks duplicated too. How about a helper function for that? Why is this code commented out at the end? /* && !defined(__GLIBC__) && !defined(__CYGWIN__) */ ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-08-04 02:18 Message: Logged In: YES user_id=226443 Originator: YES I've updated the patch to work around redefinition of the tm_isdst field by mktime, which appeared to defeat the measures put in place to support mktimetz. File Added: time-2.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-07-12 11:51 Message: Logged In: YES user_id=849994 Originator: NO I still have a failing test with the latest patch: ====================================================================== FAIL: test_mktimetz (test.test_time.TimeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/gbr/devel/python/Lib/test/test_time.py", line 272, in test_mktimetz self.assert_(time.mktimetz(lt) == time.mktimetz(gt)) AssertionError ====================================================================== FAIL: test_timegm (test.test_time.TimeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/gbr/devel/python/Lib/test/test_time.py", line 253, in test_timegm self.assert_(0 <= dt < 1) AssertionError ---------------------------------------------------------------------- Ran 17 tests in 1.249s FAILED (failures=2) test test_time failed -- errors occurred; run in verbose mode for details 1 test failed: test_time ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-23 01:21 Message: Logged In: YES user_id=226443 Originator: YES I've enhanced your version of the patch to work with the following defines: #define HAVE_TZNAME 1 #undef HAVE_TM_ZONE #undef HAVE_STRUCT_TM_TM_ZONE #undef HAVE_ALTZONE It now uses struct_time in such an environment to provide the extra offset information used in the unixtime function rather than accessing tm_gmtoff. I suppose one could do that for all cases, in fact, since this is done independently of any mktime invocation. The above defines probably represent the next most "sane" of environments after those which have tm_gmtoff. If one starts to remove other things, other more established tests seem to fail, too. File Added: time-1-improved.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-21 11:25 Message: Logged In: YES user_id=849994 Originator: NO I'm attaching a patch with some corrections of mine. It looks very good now. However, your tests fail if HAVE_STRUCT_TM_TM_ZONE is not defined. Can that be repaired? If not, the tests must be skipped in this case. File Added: time-1.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-20 01:20 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_mktimetz_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-20 01:19 Message: Logged In: YES user_id=226443 Originator: YES Yet another round. Fixed timegm, hopefully. Added mktimetz which uses time zone information to convert local and UMT times to UNIX times. Added tests and updated the docs. The usual caveats apply: I'm new to all this, so some things may need sanity checking. File Added: tm_gmtoff_zone_timegm_mktimetz.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-14 23:43 Message: Logged In: YES user_id=226443 Originator: YES Looking at this a bit more, it seems like timegm (which is a pretty desirable function to have) really is as simple as the calendar.timegm function, as far as I can tell: it just throws time zone information away. So the timegm implementation in the patches so far is actually wrong (and broken in the way it attempts to use tm_gmtoff, anyway). However, it might be nice to have a function which actually interprets times properly in order to produce a UNIX time. In other words, something which returns zero for both time.localtime(0) and time.gmtime(0), along with other times which happen to refer to the epoch but in other time zones. I'll upload a fixed patch in the next day or so, hopefully. Sorry for the noise! ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 15:13 Message: Logged In: YES user_id=849994 Originator: NO The patch looks good so far -- but I'd be comfortable with a few more tests, for example for strptime and strftime. Also, the documentation must be updated for every user-visible change (the addition of timegm(), the additional timetuple fields, the now-working (?) %z and %Z in str[fp]time and behavior changes). ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 22:02 Message: Logged In: YES user_id=226443 Originator: YES SourceForge "replay" added new attachment - now deleted. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 21:15 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 18:00 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 18:00 Message: Logged In: YES user_id=226443 Originator: YES New patches against 2.4.4 and the trunk, providing tm_gmtoff, tm_zone, strptime enhancements, a timegm function, plus tests. Where a platform supports the timezone and altzone module attributes but not tm_gmtoff and tm_zone struct tm fields, the code attempts to populate the struct_time fields appropriately, setting None values only if no timezone information exists whatsoever. Limitations include the inability to parse/obtain timezone information beyond that provided by system calls, which is an existing limitation that affects the strptime implementation amongst other things. Again, testing for "deficient" platforms with limited struct tm definitions has been limited. File Added: tm_gmtoff_zone_timegm.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-10 23:59 Message: Logged In: YES user_id=226443 Originator: YES After some thought, perhaps the population of timezone fields is more difficult than described below. Will need to look at other parts of the module code to see what the complications are. What a headache! ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-09 00:57 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-09 00:57 Message: Logged In: YES user_id=226443 Originator: YES Attached are two patches (for 2.4.4 and against the trunk). Apart from the addition of tm_zone, there's one big change: if no timezone fields/members exist on struct tm, the code attempts to read that data from the module's timezone and tzname attributes in order to populate tm_gmtoff and tm_zone; if that fails then both tm_gmtoff and tm_zone are set to None. The logic for all this is tested in test_time.py, but it really needs checking for suitability and testing on something like HP-UX. Details for the logic here: http://devrsrc1.external.hp.com/STKT/impacts/i117.html File Added: tm_gmtoff_zone.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-08 01:52 Message: Logged In: YES user_id=6380 Originator: NO No immediate time for review, but this sounds encouraging. Would you mind adding tm_zone (a string) as well? And how about working relative to the 2.6 trunk (since that's the earliest version where this new feature can be introduced)? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-08 01:28 Message: Logged In: YES user_id=226443 Originator: YES One learns new things about time and stat tuples every day! Made a much cleaner patch which provides an extra named attribute (tm_gmtoff) whilst preserving the 9-tuple layout. Where no time zone support exists, tm_gmtoff is None; otherwise it's the GMT/UTC offset. I had weird test issues with range(7) giving "TypeError: an integer is required" in the code employed (deep down) in test_strptime at some point during development, probably due to memory issues, so it might be worth checking that I've dealt properly with such things. File Added: tm_gmtoff.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 16:52 Message: Logged In: YES user_id=6380 Originator: NO Without even looking at the patch, IMO it would be much better to add tm_gmtoff and tm_zone (and any other fields) to the record returned by localtime(), but in such a way that when accessed as a tuple it still has only 9 fields. There is infrastructure for doing so somewhere for the stat structure that I'm sure could be borrowed or generalized (if it isn't already general). That's much better than adding a new function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 From noreply at sourceforge.net Fri Aug 10 01:44:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Aug 2007 16:44:31 -0700 Subject: [Patches] [ python-Patches-1770008 ] Remove cStringIO usage Message-ID: Patches item #1770008, was opened at 2007-08-08 08:42 Message generated for change (Comment added) made by avassalotti You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1770008&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 3000 Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Guido van Rossum (gvanrossum) Summary: Remove cStringIO usage Initial Comment: The patch removes the import of cStringIO from all Python files and disabled the cStringIO module. It leaves the file around. Open problems: * How should io.StringIO handle buffer objects? ---------------------------------------------------------------------- Comment By: Alexandre Vassalotti (avassalotti) Date: 2007-08-09 19:44 Message: Logged In: YES user_id=1826340 Originator: NO As George said, io.BytesIO should be used for buffer objects. Thanks for your work, it will help me a lot for testing the new accelerator module for StringIO/BytesIO. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-08 21:04 Message: Logged In: YES user_id=6380 Originator: NO Thanks! Committed revision 56841. I had to change some places to use BytesIO instead of StringIO, and I had to work hard on a few modules, esp. uu.py. But now all tests pass (except the ones that didn't pass before). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-08 16:41 Message: Logged In: YES user_id=6380 Originator: NO I'll take this. Thanks for the work! There are a few tests that break due to this, I'll look into these. I'll probably kill StringIO and cStringIO hard rather than adding deprecations (there's already a 2to3 fixer that fixes most StringIO references). ---------------------------------------------------------------------- Comment By: Christian Heimes (tiran) Date: 2007-08-08 09:57 Message: Logged In: YES user_id=560817 Originator: YES The new patch also removes StringIO and adds a facade cStringIO. Importing StringIO and cStringIO is deprecated and the imports fall back to io.StringIO. File Added: remove_stringio.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-08 09:06 Message: Logged In: YES user_id=849994 Originator: NO I guess that if you want to handle buffer objects, you should be using io.BytesIO. ---------------------------------------------------------------------- Comment By: Christian Heimes (tiran) Date: 2007-08-08 08:52 Message: Logged In: YES user_id=560817 Originator: YES File Added: stringio_deprecation.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1770008&group_id=5470 From noreply at sourceforge.net Fri Aug 10 02:49:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Aug 2007 17:49:35 -0700 Subject: [Patches] [ python-Patches-1770008 ] Remove cStringIO usage Message-ID: Patches item #1770008, was opened at 2007-08-08 14:42 Message generated for change (Comment added) made by tiran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1770008&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 3000 >Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Guido van Rossum (gvanrossum) Summary: Remove cStringIO usage Initial Comment: The patch removes the import of cStringIO from all Python files and disabled the cStringIO module. It leaves the file around. Open problems: * How should io.StringIO handle buffer objects? ---------------------------------------------------------------------- >Comment By: Christian Heimes (tiran) Date: 2007-08-10 02:49 Message: Logged In: YES user_id=560817 Originator: YES One unit test is still import StringIO although it doesn't use it: Index: Lib/ctypes/test/test_loading.py =================================================================== --- Lib/ctypes/test/test_loading.py (Revision 56879) +++ Lib/ctypes/test/test_loading.py (Arbeitskopie) @@ -1,6 +1,6 @@ from ctypes import * import sys, unittest -import os, StringIO +import os from ctypes.util import find_library from ctypes.test import is_resource_enabled ---------------------------------------------------------------------- Comment By: Alexandre Vassalotti (avassalotti) Date: 2007-08-10 01:44 Message: Logged In: YES user_id=1826340 Originator: NO As George said, io.BytesIO should be used for buffer objects. Thanks for your work, it will help me a lot for testing the new accelerator module for StringIO/BytesIO. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-09 03:04 Message: Logged In: YES user_id=6380 Originator: NO Thanks! Committed revision 56841. I had to change some places to use BytesIO instead of StringIO, and I had to work hard on a few modules, esp. uu.py. But now all tests pass (except the ones that didn't pass before). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-08 22:41 Message: Logged In: YES user_id=6380 Originator: NO I'll take this. Thanks for the work! There are a few tests that break due to this, I'll look into these. I'll probably kill StringIO and cStringIO hard rather than adding deprecations (there's already a 2to3 fixer that fixes most StringIO references). ---------------------------------------------------------------------- Comment By: Christian Heimes (tiran) Date: 2007-08-08 15:57 Message: Logged In: YES user_id=560817 Originator: YES The new patch also removes StringIO and adds a facade cStringIO. Importing StringIO and cStringIO is deprecated and the imports fall back to io.StringIO. File Added: remove_stringio.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-08 15:06 Message: Logged In: YES user_id=849994 Originator: NO I guess that if you want to handle buffer objects, you should be using io.BytesIO. ---------------------------------------------------------------------- Comment By: Christian Heimes (tiran) Date: 2007-08-08 14:52 Message: Logged In: YES user_id=560817 Originator: YES File Added: stringio_deprecation.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1770008&group_id=5470 From noreply at sourceforge.net Fri Aug 10 03:02:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Aug 2007 18:02:40 -0700 Subject: [Patches] [ python-Patches-1770008 ] Remove cStringIO usage Message-ID: Patches item #1770008, was opened at 2007-08-08 08:42 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1770008&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 3000 >Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Guido van Rossum (gvanrossum) Summary: Remove cStringIO usage Initial Comment: The patch removes the import of cStringIO from all Python files and disabled the cStringIO module. It leaves the file around. Open problems: * How should io.StringIO handle buffer objects? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-09 21:02 Message: Logged In: YES user_id=6380 Originator: NO Ow, thanks! Committed revision 56880. ---------------------------------------------------------------------- Comment By: Christian Heimes (tiran) Date: 2007-08-09 20:49 Message: Logged In: YES user_id=560817 Originator: YES One unit test is still import StringIO although it doesn't use it: Index: Lib/ctypes/test/test_loading.py =================================================================== --- Lib/ctypes/test/test_loading.py (Revision 56879) +++ Lib/ctypes/test/test_loading.py (Arbeitskopie) @@ -1,6 +1,6 @@ from ctypes import * import sys, unittest -import os, StringIO +import os from ctypes.util import find_library from ctypes.test import is_resource_enabled ---------------------------------------------------------------------- Comment By: Alexandre Vassalotti (avassalotti) Date: 2007-08-09 19:44 Message: Logged In: YES user_id=1826340 Originator: NO As George said, io.BytesIO should be used for buffer objects. Thanks for your work, it will help me a lot for testing the new accelerator module for StringIO/BytesIO. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-08 21:04 Message: Logged In: YES user_id=6380 Originator: NO Thanks! Committed revision 56841. I had to change some places to use BytesIO instead of StringIO, and I had to work hard on a few modules, esp. uu.py. But now all tests pass (except the ones that didn't pass before). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-08 16:41 Message: Logged In: YES user_id=6380 Originator: NO I'll take this. Thanks for the work! There are a few tests that break due to this, I'll look into these. I'll probably kill StringIO and cStringIO hard rather than adding deprecations (there's already a 2to3 fixer that fixes most StringIO references). ---------------------------------------------------------------------- Comment By: Christian Heimes (tiran) Date: 2007-08-08 09:57 Message: Logged In: YES user_id=560817 Originator: YES The new patch also removes StringIO and adds a facade cStringIO. Importing StringIO and cStringIO is deprecated and the imports fall back to io.StringIO. File Added: remove_stringio.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-08 09:06 Message: Logged In: YES user_id=849994 Originator: NO I guess that if you want to handle buffer objects, you should be using io.BytesIO. ---------------------------------------------------------------------- Comment By: Christian Heimes (tiran) Date: 2007-08-08 08:52 Message: Logged In: YES user_id=560817 Originator: YES File Added: stringio_deprecation.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1770008&group_id=5470 From noreply at sourceforge.net Fri Aug 10 03:43:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Aug 2007 18:43:37 -0700 Subject: [Patches] [ python-Patches-1771364 ] Misc improvements for the io module Message-ID: Patches item #1771364, was opened at 2007-08-10 03:43 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=1771364&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Nobody/Anonymous (nobody) Summary: Misc improvements for the io module Initial Comment: My patch fixes small parts of the io module: * replaced all asserts with appropriate TypeError() or ValueError() exceptions * default to buffering = 1 when raw is a tty * added four methods _checkSeekable(msg=None), _checkReadable, _checkWritable and _checkClosed as convenient methods to raise exceptions when a file is closed or not read, write or seekable. * added a unit test to check __all__ * SocketIO.readable/writeable checks for self.closed, too * SocketIO.readinto/write checks for readable, writeable and closed status __all__ references SocketIO but it is not available in io.py. The definition is in socket.py and it doesn't use any socket related code directly. What do you think about moving SocketIO to io.py in the sake of keeping everything together? NOTE: You may want to check my English in the exception messages. ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1771364&group_id=5470 From noreply at sourceforge.net Fri Aug 10 04:11:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Aug 2007 19:11:37 -0700 Subject: [Patches] [ python-Patches-1771364 ] Misc improvements for the io module Message-ID: Patches item #1771364, was opened at 2007-08-10 03:43 Message generated for change (Settings changed) made by tiran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1771364&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heimes (tiran) >Assigned to: Guido van Rossum (gvanrossum) Summary: Misc improvements for the io module Initial Comment: My patch fixes small parts of the io module: * replaced all asserts with appropriate TypeError() or ValueError() exceptions * default to buffering = 1 when raw is a tty * added four methods _checkSeekable(msg=None), _checkReadable, _checkWritable and _checkClosed as convenient methods to raise exceptions when a file is closed or not read, write or seekable. * added a unit test to check __all__ * SocketIO.readable/writeable checks for self.closed, too * SocketIO.readinto/write checks for readable, writeable and closed status __all__ references SocketIO but it is not available in io.py. The definition is in socket.py and it doesn't use any socket related code directly. What do you think about moving SocketIO to io.py in the sake of keeping everything together? NOTE: You may want to check my English in the exception messages. ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1771364&group_id=5470 From noreply at sourceforge.net Fri Aug 10 05:33:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Aug 2007 20:33:36 -0700 Subject: [Patches] [ python-Patches-1667546 ] Time zone-capable variant of time.localtime Message-ID: Patches item #1667546, was opened at 2007-02-23 15:25 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Boddie (pboddie) Assigned to: Georg Brandl (gbrandl) Summary: Time zone-capable variant of time.localtime Initial Comment: Patch related to #1493676: "time.strftime() %z error" This provides a localtime_tz function whose return value is the usual localtime time tuple with an additional field reflecting the underlying tm_gmtoff data. Various internal function signatures are modified to support the flow of time zone information, with the gettmarg most noticably changed (probably quite inelegantly - I don't do Python core development). This patch is against the Python 2.4.4 release sources. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-09 20:33 Message: Logged In: YES user_id=33168 Originator: NO METH_O is easy. Change METH_VARARGS to METH_O and the only difference is that in your function: static void my_meth_func(PyObject* self, PyObject* arg) arg is now the single argument. So you don't need to call PyArg_ParseTuple. The code that originally looked like: static void my_meth_func(PyObject* self, PyObject* args) { PyArg_ParseTuple(args, "O", &my_arg); // use my_arg becomes: static void my_meth_func(PyObject* self, PyObject* my_arg) { // use my_arg Hope that makes sense. As for the length of visible vs non-visible attributes, can't you use the macros as the top of structseq.c file? VISIBLE_SIZE, REAL_SIZE, UNNAMED_FIELDS and the _TP variants? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-08-09 16:16 Message: Logged In: YES user_id=226443 Originator: YES I've fixed some of the tests and consolidated some common code. I haven't looked at METH_O yet because I'm not familiar with this stuff, and I can't find a usable function to get the length of structure sequences which includes the non-visible elements. I also don't recall why the ifdef was changed, but I can look into that. As for the regexes, there's probably no limit on how many hours an offset can be, so it may not make much sense to be too clever about it. I'd like to look at the glibc code for mktime to verify my assumptions. Right now I don't have that much confidence in the new functions in the patch because I may have misunderstood how certain C library functions work. However, I have tested the revised code in DST and non-DST for CEST and CET respectively (using User Mode Linux). File Added: time-3.diff ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-06 23:48 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the patch Paul. As you know or learned, code that deals with time is tricky. So I'm trying to be overly cautious with these comments. Georg, I think this patch is fine to go in, but would like to see the comments below addressed. I reviewed time-2.diff. Should the regex for 'z' be tightened up in Lib/_strptime.py? (\d\d[0-5]\d) It currently allows nonsense like: +5350. The correct regex would be: ([01]\d|2[0-3])\d\d. I'm not sure it's worth it to go to that much effort. Maybe [0-2]\d[0-5]\d? Probably best to be consistent with the other regexes. What do the others do that parse hour? No lines should be over 80 columns. I noticed a bunch of problems in the test. Also it would be very helpful to breakup the assertions. This code is likely to break (time calculations always do). The more info we have when it breaks, the easier it will be do debug. So code like this: self.assert_(lt.tm_zone is None and not hasattr(time, "tzname") or lt.tm_zone == time.tzname[lt.tm_isdst]) Is probably better written something like this: if lt.tm_zone is None: self.assert_(not hasattr(time, "tzname")) else: self.assertEqual(lt.tm_zone, time.tzname[lt.tm_isdst]) That will provide a better message if the zones aren't equal and will also be clear if the hasattr() test failed. It will also fix the lines over 80 colums. :-) Use assertEqual rather than assert_(x == y). For cases where you have to use assert_(), it would be good to provide an error message about the value(s). Is the code in _tmtotuple_tz_helper and adjusttime() the same? If not, they look very close, can you use a common utility function? Use METH_O instead of METH_VARARGS for the new functions. That way you don't need to call PyArgs_ParseTuple(). You are assuming that there are always at least 10 items in the structseq. Is that valid? For example, what happens if you pickle a struct in python 2.5 and unpickle it in 2.6. Will it have the original length of 9 or the new length of 10-11? The code around PyType_IsSubtype() looks duplicated too. How about a helper function for that? Why is this code commented out at the end? /* && !defined(__GLIBC__) && !defined(__CYGWIN__) */ ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-08-03 17:18 Message: Logged In: YES user_id=226443 Originator: YES I've updated the patch to work around redefinition of the tm_isdst field by mktime, which appeared to defeat the measures put in place to support mktimetz. File Added: time-2.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-07-12 02:51 Message: Logged In: YES user_id=849994 Originator: NO I still have a failing test with the latest patch: ====================================================================== FAIL: test_mktimetz (test.test_time.TimeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/gbr/devel/python/Lib/test/test_time.py", line 272, in test_mktimetz self.assert_(time.mktimetz(lt) == time.mktimetz(gt)) AssertionError ====================================================================== FAIL: test_timegm (test.test_time.TimeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/gbr/devel/python/Lib/test/test_time.py", line 253, in test_timegm self.assert_(0 <= dt < 1) AssertionError ---------------------------------------------------------------------- Ran 17 tests in 1.249s FAILED (failures=2) test test_time failed -- errors occurred; run in verbose mode for details 1 test failed: test_time ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-22 17:21 Message: Logged In: YES user_id=226443 Originator: YES I've enhanced your version of the patch to work with the following defines: #define HAVE_TZNAME 1 #undef HAVE_TM_ZONE #undef HAVE_STRUCT_TM_TM_ZONE #undef HAVE_ALTZONE It now uses struct_time in such an environment to provide the extra offset information used in the unixtime function rather than accessing tm_gmtoff. I suppose one could do that for all cases, in fact, since this is done independently of any mktime invocation. The above defines probably represent the next most "sane" of environments after those which have tm_gmtoff. If one starts to remove other things, other more established tests seem to fail, too. File Added: time-1-improved.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-21 03:25 Message: Logged In: YES user_id=849994 Originator: NO I'm attaching a patch with some corrections of mine. It looks very good now. However, your tests fail if HAVE_STRUCT_TM_TM_ZONE is not defined. Can that be repaired? If not, the tests must be skipped in this case. File Added: time-1.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-19 17:20 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_mktimetz_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-19 17:19 Message: Logged In: YES user_id=226443 Originator: YES Yet another round. Fixed timegm, hopefully. Added mktimetz which uses time zone information to convert local and UMT times to UNIX times. Added tests and updated the docs. The usual caveats apply: I'm new to all this, so some things may need sanity checking. File Added: tm_gmtoff_zone_timegm_mktimetz.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-14 15:43 Message: Logged In: YES user_id=226443 Originator: YES Looking at this a bit more, it seems like timegm (which is a pretty desirable function to have) really is as simple as the calendar.timegm function, as far as I can tell: it just throws time zone information away. So the timegm implementation in the patches so far is actually wrong (and broken in the way it attempts to use tm_gmtoff, anyway). However, it might be nice to have a function which actually interprets times properly in order to produce a UNIX time. In other words, something which returns zero for both time.localtime(0) and time.gmtime(0), along with other times which happen to refer to the epoch but in other time zones. I'll upload a fixed patch in the next day or so, hopefully. Sorry for the noise! ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 07:13 Message: Logged In: YES user_id=849994 Originator: NO The patch looks good so far -- but I'd be comfortable with a few more tests, for example for strptime and strftime. Also, the documentation must be updated for every user-visible change (the addition of timegm(), the additional timetuple fields, the now-working (?) %z and %Z in str[fp]time and behavior changes). ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 14:02 Message: Logged In: YES user_id=226443 Originator: YES SourceForge "replay" added new attachment - now deleted. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 13:15 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 10:00 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 10:00 Message: Logged In: YES user_id=226443 Originator: YES New patches against 2.4.4 and the trunk, providing tm_gmtoff, tm_zone, strptime enhancements, a timegm function, plus tests. Where a platform supports the timezone and altzone module attributes but not tm_gmtoff and tm_zone struct tm fields, the code attempts to populate the struct_time fields appropriately, setting None values only if no timezone information exists whatsoever. Limitations include the inability to parse/obtain timezone information beyond that provided by system calls, which is an existing limitation that affects the strptime implementation amongst other things. Again, testing for "deficient" platforms with limited struct tm definitions has been limited. File Added: tm_gmtoff_zone_timegm.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-10 14:59 Message: Logged In: YES user_id=226443 Originator: YES After some thought, perhaps the population of timezone fields is more difficult than described below. Will need to look at other parts of the module code to see what the complications are. What a headache! ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-08 15:57 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-08 15:57 Message: Logged In: YES user_id=226443 Originator: YES Attached are two patches (for 2.4.4 and against the trunk). Apart from the addition of tm_zone, there's one big change: if no timezone fields/members exist on struct tm, the code attempts to read that data from the module's timezone and tzname attributes in order to populate tm_gmtoff and tm_zone; if that fails then both tm_gmtoff and tm_zone are set to None. The logic for all this is tested in test_time.py, but it really needs checking for suitability and testing on something like HP-UX. Details for the logic here: http://devrsrc1.external.hp.com/STKT/impacts/i117.html File Added: tm_gmtoff_zone.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-07 16:52 Message: Logged In: YES user_id=6380 Originator: NO No immediate time for review, but this sounds encouraging. Would you mind adding tm_zone (a string) as well? And how about working relative to the 2.6 trunk (since that's the earliest version where this new feature can be introduced)? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-07 16:28 Message: Logged In: YES user_id=226443 Originator: YES One learns new things about time and stat tuples every day! Made a much cleaner patch which provides an extra named attribute (tm_gmtoff) whilst preserving the 9-tuple layout. Where no time zone support exists, tm_gmtoff is None; otherwise it's the GMT/UTC offset. I had weird test issues with range(7) giving "TypeError: an integer is required" in the code employed (deep down) in test_strptime at some point during development, probably due to memory issues, so it might be worth checking that I've dealt properly with such things. File Added: tm_gmtoff.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 07:52 Message: Logged In: YES user_id=6380 Originator: NO Without even looking at the patch, IMO it would be much better to add tm_gmtoff and tm_zone (and any other fields) to the record returned by localtime(), but in such a way that when accessed as a tuple it still has only 9 fields. There is infrastructure for doing so somewhere for the stat structure that I'm sure could be borrowed or generalized (if it isn't already general). That's much better than adding a new function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 From noreply at sourceforge.net Sat Aug 11 01:47:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Aug 2007 16:47:28 -0700 Subject: [Patches] [ python-Patches-1667546 ] Time zone-capable variant of time.localtime Message-ID: Patches item #1667546, was opened at 2007-02-24 00:25 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Boddie (pboddie) Assigned to: Georg Brandl (gbrandl) Summary: Time zone-capable variant of time.localtime Initial Comment: Patch related to #1493676: "time.strftime() %z error" This provides a localtime_tz function whose return value is the usual localtime time tuple with an additional field reflecting the underlying tm_gmtoff data. Various internal function signatures are modified to support the flow of time zone information, with the gettmarg most noticably changed (probably quite inelegantly - I don't do Python core development). This patch is against the Python 2.4.4 release sources. ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2007-08-11 01:47 Message: Logged In: YES user_id=226443 Originator: YES I've changed the new functions to use METH_O, and I've copied the macros in from structseq.c, although these should really be exposed somewhere common, I imagine. Consequently, tests around usage of the structure are now in place, and I've added a test of unpickling an old time object to the test suite. The reason for the changed ifdef is something I don't recall, so I've reverted that change as it doesn't seem to change the behaviour of the code when tested. File Added: time-4.diff ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-10 05:33 Message: Logged In: YES user_id=33168 Originator: NO METH_O is easy. Change METH_VARARGS to METH_O and the only difference is that in your function: static void my_meth_func(PyObject* self, PyObject* arg) arg is now the single argument. So you don't need to call PyArg_ParseTuple. The code that originally looked like: static void my_meth_func(PyObject* self, PyObject* args) { PyArg_ParseTuple(args, "O", &my_arg); // use my_arg becomes: static void my_meth_func(PyObject* self, PyObject* my_arg) { // use my_arg Hope that makes sense. As for the length of visible vs non-visible attributes, can't you use the macros as the top of structseq.c file? VISIBLE_SIZE, REAL_SIZE, UNNAMED_FIELDS and the _TP variants? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-08-10 01:16 Message: Logged In: YES user_id=226443 Originator: YES I've fixed some of the tests and consolidated some common code. I haven't looked at METH_O yet because I'm not familiar with this stuff, and I can't find a usable function to get the length of structure sequences which includes the non-visible elements. I also don't recall why the ifdef was changed, but I can look into that. As for the regexes, there's probably no limit on how many hours an offset can be, so it may not make much sense to be too clever about it. I'd like to look at the glibc code for mktime to verify my assumptions. Right now I don't have that much confidence in the new functions in the patch because I may have misunderstood how certain C library functions work. However, I have tested the revised code in DST and non-DST for CEST and CET respectively (using User Mode Linux). File Added: time-3.diff ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-07 08:48 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the patch Paul. As you know or learned, code that deals with time is tricky. So I'm trying to be overly cautious with these comments. Georg, I think this patch is fine to go in, but would like to see the comments below addressed. I reviewed time-2.diff. Should the regex for 'z' be tightened up in Lib/_strptime.py? (\d\d[0-5]\d) It currently allows nonsense like: +5350. The correct regex would be: ([01]\d|2[0-3])\d\d. I'm not sure it's worth it to go to that much effort. Maybe [0-2]\d[0-5]\d? Probably best to be consistent with the other regexes. What do the others do that parse hour? No lines should be over 80 columns. I noticed a bunch of problems in the test. Also it would be very helpful to breakup the assertions. This code is likely to break (time calculations always do). The more info we have when it breaks, the easier it will be do debug. So code like this: self.assert_(lt.tm_zone is None and not hasattr(time, "tzname") or lt.tm_zone == time.tzname[lt.tm_isdst]) Is probably better written something like this: if lt.tm_zone is None: self.assert_(not hasattr(time, "tzname")) else: self.assertEqual(lt.tm_zone, time.tzname[lt.tm_isdst]) That will provide a better message if the zones aren't equal and will also be clear if the hasattr() test failed. It will also fix the lines over 80 colums. :-) Use assertEqual rather than assert_(x == y). For cases where you have to use assert_(), it would be good to provide an error message about the value(s). Is the code in _tmtotuple_tz_helper and adjusttime() the same? If not, they look very close, can you use a common utility function? Use METH_O instead of METH_VARARGS for the new functions. That way you don't need to call PyArgs_ParseTuple(). You are assuming that there are always at least 10 items in the structseq. Is that valid? For example, what happens if you pickle a struct in python 2.5 and unpickle it in 2.6. Will it have the original length of 9 or the new length of 10-11? The code around PyType_IsSubtype() looks duplicated too. How about a helper function for that? Why is this code commented out at the end? /* && !defined(__GLIBC__) && !defined(__CYGWIN__) */ ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-08-04 02:18 Message: Logged In: YES user_id=226443 Originator: YES I've updated the patch to work around redefinition of the tm_isdst field by mktime, which appeared to defeat the measures put in place to support mktimetz. File Added: time-2.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-07-12 11:51 Message: Logged In: YES user_id=849994 Originator: NO I still have a failing test with the latest patch: ====================================================================== FAIL: test_mktimetz (test.test_time.TimeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/gbr/devel/python/Lib/test/test_time.py", line 272, in test_mktimetz self.assert_(time.mktimetz(lt) == time.mktimetz(gt)) AssertionError ====================================================================== FAIL: test_timegm (test.test_time.TimeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/gbr/devel/python/Lib/test/test_time.py", line 253, in test_timegm self.assert_(0 <= dt < 1) AssertionError ---------------------------------------------------------------------- Ran 17 tests in 1.249s FAILED (failures=2) test test_time failed -- errors occurred; run in verbose mode for details 1 test failed: test_time ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-23 01:21 Message: Logged In: YES user_id=226443 Originator: YES I've enhanced your version of the patch to work with the following defines: #define HAVE_TZNAME 1 #undef HAVE_TM_ZONE #undef HAVE_STRUCT_TM_TM_ZONE #undef HAVE_ALTZONE It now uses struct_time in such an environment to provide the extra offset information used in the unixtime function rather than accessing tm_gmtoff. I suppose one could do that for all cases, in fact, since this is done independently of any mktime invocation. The above defines probably represent the next most "sane" of environments after those which have tm_gmtoff. If one starts to remove other things, other more established tests seem to fail, too. File Added: time-1-improved.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-21 11:25 Message: Logged In: YES user_id=849994 Originator: NO I'm attaching a patch with some corrections of mine. It looks very good now. However, your tests fail if HAVE_STRUCT_TM_TM_ZONE is not defined. Can that be repaired? If not, the tests must be skipped in this case. File Added: time-1.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-20 01:20 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_mktimetz_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-20 01:19 Message: Logged In: YES user_id=226443 Originator: YES Yet another round. Fixed timegm, hopefully. Added mktimetz which uses time zone information to convert local and UMT times to UNIX times. Added tests and updated the docs. The usual caveats apply: I'm new to all this, so some things may need sanity checking. File Added: tm_gmtoff_zone_timegm_mktimetz.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-14 23:43 Message: Logged In: YES user_id=226443 Originator: YES Looking at this a bit more, it seems like timegm (which is a pretty desirable function to have) really is as simple as the calendar.timegm function, as far as I can tell: it just throws time zone information away. So the timegm implementation in the patches so far is actually wrong (and broken in the way it attempts to use tm_gmtoff, anyway). However, it might be nice to have a function which actually interprets times properly in order to produce a UNIX time. In other words, something which returns zero for both time.localtime(0) and time.gmtime(0), along with other times which happen to refer to the epoch but in other time zones. I'll upload a fixed patch in the next day or so, hopefully. Sorry for the noise! ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 15:13 Message: Logged In: YES user_id=849994 Originator: NO The patch looks good so far -- but I'd be comfortable with a few more tests, for example for strptime and strftime. Also, the documentation must be updated for every user-visible change (the addition of timegm(), the additional timetuple fields, the now-working (?) %z and %Z in str[fp]time and behavior changes). ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 22:02 Message: Logged In: YES user_id=226443 Originator: YES SourceForge "replay" added new attachment - now deleted. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 21:15 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 18:00 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 18:00 Message: Logged In: YES user_id=226443 Originator: YES New patches against 2.4.4 and the trunk, providing tm_gmtoff, tm_zone, strptime enhancements, a timegm function, plus tests. Where a platform supports the timezone and altzone module attributes but not tm_gmtoff and tm_zone struct tm fields, the code attempts to populate the struct_time fields appropriately, setting None values only if no timezone information exists whatsoever. Limitations include the inability to parse/obtain timezone information beyond that provided by system calls, which is an existing limitation that affects the strptime implementation amongst other things. Again, testing for "deficient" platforms with limited struct tm definitions has been limited. File Added: tm_gmtoff_zone_timegm.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-10 23:59 Message: Logged In: YES user_id=226443 Originator: YES After some thought, perhaps the population of timezone fields is more difficult than described below. Will need to look at other parts of the module code to see what the complications are. What a headache! ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-09 00:57 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-09 00:57 Message: Logged In: YES user_id=226443 Originator: YES Attached are two patches (for 2.4.4 and against the trunk). Apart from the addition of tm_zone, there's one big change: if no timezone fields/members exist on struct tm, the code attempts to read that data from the module's timezone and tzname attributes in order to populate tm_gmtoff and tm_zone; if that fails then both tm_gmtoff and tm_zone are set to None. The logic for all this is tested in test_time.py, but it really needs checking for suitability and testing on something like HP-UX. Details for the logic here: http://devrsrc1.external.hp.com/STKT/impacts/i117.html File Added: tm_gmtoff_zone.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-08 01:52 Message: Logged In: YES user_id=6380 Originator: NO No immediate time for review, but this sounds encouraging. Would you mind adding tm_zone (a string) as well? And how about working relative to the 2.6 trunk (since that's the earliest version where this new feature can be introduced)? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-08 01:28 Message: Logged In: YES user_id=226443 Originator: YES One learns new things about time and stat tuples every day! Made a much cleaner patch which provides an extra named attribute (tm_gmtoff) whilst preserving the 9-tuple layout. Where no time zone support exists, tm_gmtoff is None; otherwise it's the GMT/UTC offset. I had weird test issues with range(7) giving "TypeError: an integer is required" in the code employed (deep down) in test_strptime at some point during development, probably due to memory issues, so it might be worth checking that I've dealt properly with such things. File Added: tm_gmtoff.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 16:52 Message: Logged In: YES user_id=6380 Originator: NO Without even looking at the patch, IMO it would be much better to add tm_gmtoff and tm_zone (and any other fields) to the record returned by localtime(), but in such a way that when accessed as a tuple it still has only 9 fields. There is infrastructure for doing so somewhere for the stat structure that I'm sure could be borrowed or generalized (if it isn't already general). That's much better than adding a new function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 From noreply at sourceforge.net Sat Aug 11 11:06:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Aug 2007 02:06:31 -0700 Subject: [Patches] [ python-Patches-1692335 ] Move initial args assignment to BaseException.__new__ Message-ID: Patches item #1692335, was opened at 2007-04-01 13:46 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1692335&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 Private: No Submitted By: Ziga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Move initial args assignment to BaseException.__new__ Initial Comment: Pickling exceptions fails when an Exception class requires an argument in the constructor, but doesn't call its base class' constructor. See this mail for details: http://mail.python.org/pipermail/python-dev/2007-April/072416.html This patch simply moves initial args assignment to BaseException.__new__. This should fix most of the problems, because it is very unlikely that an exception overwrites the __new__ method; exceptions used to be old style classes, which don't support the __new__ special method. The args attribute is still overwritten in all the __init__ methods, so there shouldn't be any backward compatibility problems. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-11 09:06 Message: Logged In: YES user_id=849994 Originator: NO Attaching a new patch that fixes the class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) scenario by keeping the original args to __new__ as an exception attribute. File Added: exception-pickling.diff ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-06-27 18:45 Message: Logged In: YES user_id=393416 Originator: NO Added patch #1744398 as an alternate solution. ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-06-15 00:34 Message: Logged In: YES user_id=393416 Originator: NO I have stumbled across another scenario where unpickling fails. If your exception takes arguments, but you call Exception.__init__ with a different number of arguments, it will fail. As in: class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-01 21:50 Message: Logged In: YES user_id=1326842 Originator: YES I'm attaching a test that Eric Huss sent in private mail. The test fails, because old exception pickles don't have args for the reconstructor, but their __init__() gets called anyway because they are new style classes now. The problem is in cPickle.InstanceNew() and pickle.Unpickler._instantiate(). Those methods behave differently depending on the type of the object instantiated; they avoid the __init__() call when type is an old style class. There is nothing that can be done in the exception classes to fix this issue; the fix would need to be in the pickle and cPickle module. File Added: test_exception_pickle.py ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-01 13:47 Message: Logged In: YES user_id=1326842 Originator: YES File Added: exc_args_25.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1692335&group_id=5470 From noreply at sourceforge.net Sat Aug 11 11:06:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Aug 2007 02:06:48 -0700 Subject: [Patches] [ python-Patches-1692335 ] Move initial args assignment to BaseException.__new__ Message-ID: Patches item #1692335, was opened at 2007-04-01 13:46 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1692335&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 Private: No Submitted By: Ziga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Move initial args assignment to BaseException.__new__ Initial Comment: Pickling exceptions fails when an Exception class requires an argument in the constructor, but doesn't call its base class' constructor. See this mail for details: http://mail.python.org/pipermail/python-dev/2007-April/072416.html This patch simply moves initial args assignment to BaseException.__new__. This should fix most of the problems, because it is very unlikely that an exception overwrites the __new__ method; exceptions used to be old style classes, which don't support the __new__ special method. The args attribute is still overwritten in all the __init__ methods, so there shouldn't be any backward compatibility problems. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-11 09:06 Message: Logged In: YES user_id=849994 Originator: NO Attaching a new patch that fixes the class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) scenario by keeping the original args to __new__ as an exception attribute. File Added: exception-pickling.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-11 09:06 Message: Logged In: YES user_id=849994 Originator: NO Attaching a new patch that fixes the class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) scenario by keeping the original args to __new__ as an exception attribute. File Added: exception-pickling.diff ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-06-27 18:45 Message: Logged In: YES user_id=393416 Originator: NO Added patch #1744398 as an alternate solution. ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-06-15 00:34 Message: Logged In: YES user_id=393416 Originator: NO I have stumbled across another scenario where unpickling fails. If your exception takes arguments, but you call Exception.__init__ with a different number of arguments, it will fail. As in: class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-01 21:50 Message: Logged In: YES user_id=1326842 Originator: YES I'm attaching a test that Eric Huss sent in private mail. The test fails, because old exception pickles don't have args for the reconstructor, but their __init__() gets called anyway because they are new style classes now. The problem is in cPickle.InstanceNew() and pickle.Unpickler._instantiate(). Those methods behave differently depending on the type of the object instantiated; they avoid the __init__() call when type is an old style class. There is nothing that can be done in the exception classes to fix this issue; the fix would need to be in the pickle and cPickle module. File Added: test_exception_pickle.py ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-01 13:47 Message: Logged In: YES user_id=1326842 Originator: YES File Added: exc_args_25.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1692335&group_id=5470 From noreply at sourceforge.net Sat Aug 11 20:27:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Aug 2007 11:27:50 -0700 Subject: [Patches] [ python-Patches-1692335 ] Move initial args assignment to BaseException.__new__ Message-ID: Patches item #1692335, was opened at 2007-04-01 06:46 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1692335&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 Private: No Submitted By: Ziga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Move initial args assignment to BaseException.__new__ Initial Comment: Pickling exceptions fails when an Exception class requires an argument in the constructor, but doesn't call its base class' constructor. See this mail for details: http://mail.python.org/pipermail/python-dev/2007-April/072416.html This patch simply moves initial args assignment to BaseException.__new__. This should fix most of the problems, because it is very unlikely that an exception overwrites the __new__ method; exceptions used to be old style classes, which don't support the __new__ special method. The args attribute is still overwritten in all the __init__ methods, so there shouldn't be any backward compatibility problems. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-11 11:27 Message: Logged In: YES user_id=33168 Originator: NO self->args needs to be initialized to NULL because if the alloc of args failed, self->args would be uninitialized and deallocated. (I realize the alloc of an empty tuple will realistically never fail currently.) I'm not sure if this could cause any new problems because of the behavior change, but the code itself looked fine to me. Hopefully someone with more knowledge of exceptions could take a look at the idea. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-11 02:06 Message: Logged In: YES user_id=849994 Originator: NO Attaching a new patch that fixes the class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) scenario by keeping the original args to __new__ as an exception attribute. File Added: exception-pickling.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-11 02:06 Message: Logged In: YES user_id=849994 Originator: NO Attaching a new patch that fixes the class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) scenario by keeping the original args to __new__ as an exception attribute. File Added: exception-pickling.diff ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-06-27 11:45 Message: Logged In: YES user_id=393416 Originator: NO Added patch #1744398 as an alternate solution. ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-06-14 17:34 Message: Logged In: YES user_id=393416 Originator: NO I have stumbled across another scenario where unpickling fails. If your exception takes arguments, but you call Exception.__init__ with a different number of arguments, it will fail. As in: class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-01 14:50 Message: Logged In: YES user_id=1326842 Originator: YES I'm attaching a test that Eric Huss sent in private mail. The test fails, because old exception pickles don't have args for the reconstructor, but their __init__() gets called anyway because they are new style classes now. The problem is in cPickle.InstanceNew() and pickle.Unpickler._instantiate(). Those methods behave differently depending on the type of the object instantiated; they avoid the __init__() call when type is an old style class. There is nothing that can be done in the exception classes to fix this issue; the fix would need to be in the pickle and cPickle module. File Added: test_exception_pickle.py ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-01 06:47 Message: Logged In: YES user_id=1326842 Originator: YES File Added: exc_args_25.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1692335&group_id=5470 From noreply at sourceforge.net Sat Aug 11 20:31:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Aug 2007 11:31:03 -0700 Subject: [Patches] [ python-Patches-1744398 ] Improve exception pickling support Message-ID: Patches item #1744398, was opened at 2007-06-27 11:44 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1744398&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric Huss (ehuss) Assigned to: Nobody/Anonymous (nobody) Summary: Improve exception pickling support Initial Comment: Due to various issues with how pickle works and new-style classes, pickling exception objects has been somewhat unreliable since Python 2.5. See comments in patch #1692335 for more detail. Attached is a patch that seems to improve pickling exceptions to support various different types of subclasses. It has some limitations (exceptions that use __slots__, doesn't fully support SyntaxError, UnicodeError, SystemExit, or WindowsError). However, it is an improvement for my situation. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-11 11:31 Message: Logged In: YES user_id=33168 Originator: NO Eric, could you comment on the current version of the other patch? Does that work for you? Is that sufficient? If not, how are they different? Should they both be applied, in part or in whole? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1744398&group_id=5470 From noreply at sourceforge.net Sun Aug 12 03:33:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Aug 2007 18:33:19 -0700 Subject: [Patches] [ python-Patches-1692335 ] Move initial args assignment to BaseException.__new__ Message-ID: Patches item #1692335, was opened at 2007-04-01 06:46 Message generated for change (Comment added) made by ehuss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1692335&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 Private: No Submitted By: Ziga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Move initial args assignment to BaseException.__new__ Initial Comment: Pickling exceptions fails when an Exception class requires an argument in the constructor, but doesn't call its base class' constructor. See this mail for details: http://mail.python.org/pipermail/python-dev/2007-April/072416.html This patch simply moves initial args assignment to BaseException.__new__. This should fix most of the problems, because it is very unlikely that an exception overwrites the __new__ method; exceptions used to be old style classes, which don't support the __new__ special method. The args attribute is still overwritten in all the __init__ methods, so there shouldn't be any backward compatibility problems. ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-08-11 18:33 Message: Logged In: YES user_id=393416 Originator: NO Georg's new patch looks good to me, it seems to pass all the scenarios that I know of. You can close out my patch if you check this in. Thanks for looking into this! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-11 11:27 Message: Logged In: YES user_id=33168 Originator: NO self->args needs to be initialized to NULL because if the alloc of args failed, self->args would be uninitialized and deallocated. (I realize the alloc of an empty tuple will realistically never fail currently.) I'm not sure if this could cause any new problems because of the behavior change, but the code itself looked fine to me. Hopefully someone with more knowledge of exceptions could take a look at the idea. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-11 02:06 Message: Logged In: YES user_id=849994 Originator: NO Attaching a new patch that fixes the class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) scenario by keeping the original args to __new__ as an exception attribute. File Added: exception-pickling.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-11 02:06 Message: Logged In: YES user_id=849994 Originator: NO Attaching a new patch that fixes the class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) scenario by keeping the original args to __new__ as an exception attribute. File Added: exception-pickling.diff ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-06-27 11:45 Message: Logged In: YES user_id=393416 Originator: NO Added patch #1744398 as an alternate solution. ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-06-14 17:34 Message: Logged In: YES user_id=393416 Originator: NO I have stumbled across another scenario where unpickling fails. If your exception takes arguments, but you call Exception.__init__ with a different number of arguments, it will fail. As in: class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-01 14:50 Message: Logged In: YES user_id=1326842 Originator: YES I'm attaching a test that Eric Huss sent in private mail. The test fails, because old exception pickles don't have args for the reconstructor, but their __init__() gets called anyway because they are new style classes now. The problem is in cPickle.InstanceNew() and pickle.Unpickler._instantiate(). Those methods behave differently depending on the type of the object instantiated; they avoid the __init__() call when type is an old style class. There is nothing that can be done in the exception classes to fix this issue; the fix would need to be in the pickle and cPickle module. File Added: test_exception_pickle.py ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-01 06:47 Message: Logged In: YES user_id=1326842 Originator: YES File Added: exc_args_25.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1692335&group_id=5470 From noreply at sourceforge.net Sun Aug 12 10:00:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Aug 2007 01:00:52 -0700 Subject: [Patches] [ python-Patches-1692335 ] Move initial args assignment to BaseException.__new__ Message-ID: Patches item #1692335, was opened at 2007-04-01 13:46 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1692335&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 Private: No Submitted By: Ziga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Move initial args assignment to BaseException.__new__ Initial Comment: Pickling exceptions fails when an Exception class requires an argument in the constructor, but doesn't call its base class' constructor. See this mail for details: http://mail.python.org/pipermail/python-dev/2007-April/072416.html This patch simply moves initial args assignment to BaseException.__new__. This should fix most of the problems, because it is very unlikely that an exception overwrites the __new__ method; exceptions used to be old style classes, which don't support the __new__ special method. The args attribute is still overwritten in all the __init__ methods, so there shouldn't be any backward compatibility problems. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-12 08:00 Message: Logged In: YES user_id=849994 Originator: NO The only question left is what to do if something reassigns exceptioninstance.args. ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-08-12 01:33 Message: Logged In: YES user_id=393416 Originator: NO Georg's new patch looks good to me, it seems to pass all the scenarios that I know of. You can close out my patch if you check this in. Thanks for looking into this! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-11 18:27 Message: Logged In: YES user_id=33168 Originator: NO self->args needs to be initialized to NULL because if the alloc of args failed, self->args would be uninitialized and deallocated. (I realize the alloc of an empty tuple will realistically never fail currently.) I'm not sure if this could cause any new problems because of the behavior change, but the code itself looked fine to me. Hopefully someone with more knowledge of exceptions could take a look at the idea. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-11 09:06 Message: Logged In: YES user_id=849994 Originator: NO Attaching a new patch that fixes the class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) scenario by keeping the original args to __new__ as an exception attribute. File Added: exception-pickling.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-11 09:06 Message: Logged In: YES user_id=849994 Originator: NO Attaching a new patch that fixes the class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) scenario by keeping the original args to __new__ as an exception attribute. File Added: exception-pickling.diff ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-06-27 18:45 Message: Logged In: YES user_id=393416 Originator: NO Added patch #1744398 as an alternate solution. ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-06-15 00:34 Message: Logged In: YES user_id=393416 Originator: NO I have stumbled across another scenario where unpickling fails. If your exception takes arguments, but you call Exception.__init__ with a different number of arguments, it will fail. As in: class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-01 21:50 Message: Logged In: YES user_id=1326842 Originator: YES I'm attaching a test that Eric Huss sent in private mail. The test fails, because old exception pickles don't have args for the reconstructor, but their __init__() gets called anyway because they are new style classes now. The problem is in cPickle.InstanceNew() and pickle.Unpickler._instantiate(). Those methods behave differently depending on the type of the object instantiated; they avoid the __init__() call when type is an old style class. There is nothing that can be done in the exception classes to fix this issue; the fix would need to be in the pickle and cPickle module. File Added: test_exception_pickle.py ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-01 13:47 Message: Logged In: YES user_id=1326842 Originator: YES File Added: exc_args_25.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1692335&group_id=5470 From noreply at sourceforge.net Sun Aug 12 10:01:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Aug 2007 01:01:08 -0700 Subject: [Patches] [ python-Patches-1692335 ] Move initial args assignment to BaseException.__new__ Message-ID: Patches item #1692335, was opened at 2007-04-01 13:46 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1692335&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 Private: No Submitted By: Ziga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Move initial args assignment to BaseException.__new__ Initial Comment: Pickling exceptions fails when an Exception class requires an argument in the constructor, but doesn't call its base class' constructor. See this mail for details: http://mail.python.org/pipermail/python-dev/2007-April/072416.html This patch simply moves initial args assignment to BaseException.__new__. This should fix most of the problems, because it is very unlikely that an exception overwrites the __new__ method; exceptions used to be old style classes, which don't support the __new__ special method. The args attribute is still overwritten in all the __init__ methods, so there shouldn't be any backward compatibility problems. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-12 08:01 Message: Logged In: YES user_id=849994 Originator: NO The only question left is what to do if something reassigns exceptioninstance.args. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-12 08:00 Message: Logged In: YES user_id=849994 Originator: NO The only question left is what to do if something reassigns exceptioninstance.args. ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-08-12 01:33 Message: Logged In: YES user_id=393416 Originator: NO Georg's new patch looks good to me, it seems to pass all the scenarios that I know of. You can close out my patch if you check this in. Thanks for looking into this! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-11 18:27 Message: Logged In: YES user_id=33168 Originator: NO self->args needs to be initialized to NULL because if the alloc of args failed, self->args would be uninitialized and deallocated. (I realize the alloc of an empty tuple will realistically never fail currently.) I'm not sure if this could cause any new problems because of the behavior change, but the code itself looked fine to me. Hopefully someone with more knowledge of exceptions could take a look at the idea. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-11 09:06 Message: Logged In: YES user_id=849994 Originator: NO Attaching a new patch that fixes the class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) scenario by keeping the original args to __new__ as an exception attribute. File Added: exception-pickling.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-11 09:06 Message: Logged In: YES user_id=849994 Originator: NO Attaching a new patch that fixes the class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) scenario by keeping the original args to __new__ as an exception attribute. File Added: exception-pickling.diff ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-06-27 18:45 Message: Logged In: YES user_id=393416 Originator: NO Added patch #1744398 as an alternate solution. ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-06-15 00:34 Message: Logged In: YES user_id=393416 Originator: NO I have stumbled across another scenario where unpickling fails. If your exception takes arguments, but you call Exception.__init__ with a different number of arguments, it will fail. As in: class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-01 21:50 Message: Logged In: YES user_id=1326842 Originator: YES I'm attaching a test that Eric Huss sent in private mail. The test fails, because old exception pickles don't have args for the reconstructor, but their __init__() gets called anyway because they are new style classes now. The problem is in cPickle.InstanceNew() and pickle.Unpickler._instantiate(). Those methods behave differently depending on the type of the object instantiated; they avoid the __init__() call when type is an old style class. There is nothing that can be done in the exception classes to fix this issue; the fix would need to be in the pickle and cPickle module. File Added: test_exception_pickle.py ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-01 13:47 Message: Logged In: YES user_id=1326842 Originator: YES File Added: exc_args_25.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1692335&group_id=5470 From noreply at sourceforge.net Sun Aug 12 13:23:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Aug 2007 04:23:06 -0700 Subject: [Patches] [ python-Patches-1692335 ] Move initial args assignment to BaseException.__new__ Message-ID: Patches item #1692335, was opened at 2007-04-01 15:46 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1692335&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 Private: No Submitted By: Ziga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Move initial args assignment to BaseException.__new__ Initial Comment: Pickling exceptions fails when an Exception class requires an argument in the constructor, but doesn't call its base class' constructor. See this mail for details: http://mail.python.org/pipermail/python-dev/2007-April/072416.html This patch simply moves initial args assignment to BaseException.__new__. This should fix most of the problems, because it is very unlikely that an exception overwrites the __new__ method; exceptions used to be old style classes, which don't support the __new__ special method. The args attribute is still overwritten in all the __init__ methods, so there shouldn't be any backward compatibility problems. ---------------------------------------------------------------------- >Comment By: Ziga Seilnacht (zseil) Date: 2007-08-12 13:23 Message: Logged In: YES user_id=1326842 Originator: YES There is also the problem that Jim Fulton mentioned in bug #1742889; if the user modifies the 'message' attribute of an exception (or any other attribute that is not stored in the __dict__), it won't get serialized on pickling. Attaching a new patch that fixes this by using the __getstate__() pickling hook. It uses tp_members and tp_getset members of the type object to find all the attributes that need to be serialized. The 2.5 patch also contains a fix for migrating old exception pickles to Python 2.5. For that I had to change cPickle and pickle. It would be nice if Jim could comment if this change is needed, since ZODB is probably the biggest user of these modules. The downside is that this patch is fairly big. File Added: exception_pickling_25.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-12 10:01 Message: Logged In: YES user_id=849994 Originator: NO The only question left is what to do if something reassigns exceptioninstance.args. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-12 10:00 Message: Logged In: YES user_id=849994 Originator: NO The only question left is what to do if something reassigns exceptioninstance.args. ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-08-12 03:33 Message: Logged In: YES user_id=393416 Originator: NO Georg's new patch looks good to me, it seems to pass all the scenarios that I know of. You can close out my patch if you check this in. Thanks for looking into this! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-11 20:27 Message: Logged In: YES user_id=33168 Originator: NO self->args needs to be initialized to NULL because if the alloc of args failed, self->args would be uninitialized and deallocated. (I realize the alloc of an empty tuple will realistically never fail currently.) I'm not sure if this could cause any new problems because of the behavior change, but the code itself looked fine to me. Hopefully someone with more knowledge of exceptions could take a look at the idea. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-11 11:06 Message: Logged In: YES user_id=849994 Originator: NO Attaching a new patch that fixes the class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) scenario by keeping the original args to __new__ as an exception attribute. File Added: exception-pickling.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-11 11:06 Message: Logged In: YES user_id=849994 Originator: NO Attaching a new patch that fixes the class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) scenario by keeping the original args to __new__ as an exception attribute. File Added: exception-pickling.diff ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-06-27 20:45 Message: Logged In: YES user_id=393416 Originator: NO Added patch #1744398 as an alternate solution. ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-06-15 02:34 Message: Logged In: YES user_id=393416 Originator: NO I have stumbled across another scenario where unpickling fails. If your exception takes arguments, but you call Exception.__init__ with a different number of arguments, it will fail. As in: class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-01 23:50 Message: Logged In: YES user_id=1326842 Originator: YES I'm attaching a test that Eric Huss sent in private mail. The test fails, because old exception pickles don't have args for the reconstructor, but their __init__() gets called anyway because they are new style classes now. The problem is in cPickle.InstanceNew() and pickle.Unpickler._instantiate(). Those methods behave differently depending on the type of the object instantiated; they avoid the __init__() call when type is an old style class. There is nothing that can be done in the exception classes to fix this issue; the fix would need to be in the pickle and cPickle module. File Added: test_exception_pickle.py ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-01 15:47 Message: Logged In: YES user_id=1326842 Originator: YES File Added: exc_args_25.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1692335&group_id=5470 From noreply at sourceforge.net Sun Aug 12 13:24:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Aug 2007 04:24:08 -0700 Subject: [Patches] [ python-Patches-1692335 ] Move initial args assignment to BaseException.__new__ Message-ID: Patches item #1692335, was opened at 2007-04-01 15:46 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1692335&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 Private: No Submitted By: Ziga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Move initial args assignment to BaseException.__new__ Initial Comment: Pickling exceptions fails when an Exception class requires an argument in the constructor, but doesn't call its base class' constructor. See this mail for details: http://mail.python.org/pipermail/python-dev/2007-April/072416.html This patch simply moves initial args assignment to BaseException.__new__. This should fix most of the problems, because it is very unlikely that an exception overwrites the __new__ method; exceptions used to be old style classes, which don't support the __new__ special method. The args attribute is still overwritten in all the __init__ methods, so there shouldn't be any backward compatibility problems. ---------------------------------------------------------------------- >Comment By: Ziga Seilnacht (zseil) Date: 2007-08-12 13:24 Message: Logged In: YES user_id=1326842 Originator: YES File Added: exception_pickling_26.diff ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-08-12 13:23 Message: Logged In: YES user_id=1326842 Originator: YES There is also the problem that Jim Fulton mentioned in bug #1742889; if the user modifies the 'message' attribute of an exception (or any other attribute that is not stored in the __dict__), it won't get serialized on pickling. Attaching a new patch that fixes this by using the __getstate__() pickling hook. It uses tp_members and tp_getset members of the type object to find all the attributes that need to be serialized. The 2.5 patch also contains a fix for migrating old exception pickles to Python 2.5. For that I had to change cPickle and pickle. It would be nice if Jim could comment if this change is needed, since ZODB is probably the biggest user of these modules. The downside is that this patch is fairly big. File Added: exception_pickling_25.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-12 10:01 Message: Logged In: YES user_id=849994 Originator: NO The only question left is what to do if something reassigns exceptioninstance.args. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-12 10:00 Message: Logged In: YES user_id=849994 Originator: NO The only question left is what to do if something reassigns exceptioninstance.args. ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-08-12 03:33 Message: Logged In: YES user_id=393416 Originator: NO Georg's new patch looks good to me, it seems to pass all the scenarios that I know of. You can close out my patch if you check this in. Thanks for looking into this! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-11 20:27 Message: Logged In: YES user_id=33168 Originator: NO self->args needs to be initialized to NULL because if the alloc of args failed, self->args would be uninitialized and deallocated. (I realize the alloc of an empty tuple will realistically never fail currently.) I'm not sure if this could cause any new problems because of the behavior change, but the code itself looked fine to me. Hopefully someone with more knowledge of exceptions could take a look at the idea. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-11 11:06 Message: Logged In: YES user_id=849994 Originator: NO Attaching a new patch that fixes the class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) scenario by keeping the original args to __new__ as an exception attribute. File Added: exception-pickling.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-11 11:06 Message: Logged In: YES user_id=849994 Originator: NO Attaching a new patch that fixes the class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) scenario by keeping the original args to __new__ as an exception attribute. File Added: exception-pickling.diff ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-06-27 20:45 Message: Logged In: YES user_id=393416 Originator: NO Added patch #1744398 as an alternate solution. ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-06-15 02:34 Message: Logged In: YES user_id=393416 Originator: NO I have stumbled across another scenario where unpickling fails. If your exception takes arguments, but you call Exception.__init__ with a different number of arguments, it will fail. As in: class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-01 23:50 Message: Logged In: YES user_id=1326842 Originator: YES I'm attaching a test that Eric Huss sent in private mail. The test fails, because old exception pickles don't have args for the reconstructor, but their __init__() gets called anyway because they are new style classes now. The problem is in cPickle.InstanceNew() and pickle.Unpickler._instantiate(). Those methods behave differently depending on the type of the object instantiated; they avoid the __init__() call when type is an old style class. There is nothing that can be done in the exception classes to fix this issue; the fix would need to be in the pickle and cPickle module. File Added: test_exception_pickle.py ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-01 15:47 Message: Logged In: YES user_id=1326842 Originator: YES File Added: exc_args_25.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1692335&group_id=5470 From noreply at sourceforge.net Sun Aug 12 14:13:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Aug 2007 05:13:47 -0700 Subject: [Patches] [ python-Patches-1692335 ] Move initial args assignment to BaseException.__new__ Message-ID: Patches item #1692335, was opened at 2007-04-01 13:46 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1692335&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 Private: No Submitted By: Ziga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Move initial args assignment to BaseException.__new__ Initial Comment: Pickling exceptions fails when an Exception class requires an argument in the constructor, but doesn't call its base class' constructor. See this mail for details: http://mail.python.org/pipermail/python-dev/2007-April/072416.html This patch simply moves initial args assignment to BaseException.__new__. This should fix most of the problems, because it is very unlikely that an exception overwrites the __new__ method; exceptions used to be old style classes, which don't support the __new__ special method. The args attribute is still overwritten in all the __init__ methods, so there shouldn't be any backward compatibility problems. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-12 12:13 Message: Logged In: YES user_id=849994 Originator: NO I wouldn't care too much about .message; it was new in 2.5 and is already deprecated in 2.6. ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-08-12 11:24 Message: Logged In: YES user_id=1326842 Originator: YES File Added: exception_pickling_26.diff ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-08-12 11:23 Message: Logged In: YES user_id=1326842 Originator: YES There is also the problem that Jim Fulton mentioned in bug #1742889; if the user modifies the 'message' attribute of an exception (or any other attribute that is not stored in the __dict__), it won't get serialized on pickling. Attaching a new patch that fixes this by using the __getstate__() pickling hook. It uses tp_members and tp_getset members of the type object to find all the attributes that need to be serialized. The 2.5 patch also contains a fix for migrating old exception pickles to Python 2.5. For that I had to change cPickle and pickle. It would be nice if Jim could comment if this change is needed, since ZODB is probably the biggest user of these modules. The downside is that this patch is fairly big. File Added: exception_pickling_25.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-12 08:01 Message: Logged In: YES user_id=849994 Originator: NO The only question left is what to do if something reassigns exceptioninstance.args. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-12 08:00 Message: Logged In: YES user_id=849994 Originator: NO The only question left is what to do if something reassigns exceptioninstance.args. ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-08-12 01:33 Message: Logged In: YES user_id=393416 Originator: NO Georg's new patch looks good to me, it seems to pass all the scenarios that I know of. You can close out my patch if you check this in. Thanks for looking into this! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-11 18:27 Message: Logged In: YES user_id=33168 Originator: NO self->args needs to be initialized to NULL because if the alloc of args failed, self->args would be uninitialized and deallocated. (I realize the alloc of an empty tuple will realistically never fail currently.) I'm not sure if this could cause any new problems because of the behavior change, but the code itself looked fine to me. Hopefully someone with more knowledge of exceptions could take a look at the idea. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-11 09:06 Message: Logged In: YES user_id=849994 Originator: NO Attaching a new patch that fixes the class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) scenario by keeping the original args to __new__ as an exception attribute. File Added: exception-pickling.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-11 09:06 Message: Logged In: YES user_id=849994 Originator: NO Attaching a new patch that fixes the class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) scenario by keeping the original args to __new__ as an exception attribute. File Added: exception-pickling.diff ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-06-27 18:45 Message: Logged In: YES user_id=393416 Originator: NO Added patch #1744398 as an alternate solution. ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-06-15 00:34 Message: Logged In: YES user_id=393416 Originator: NO I have stumbled across another scenario where unpickling fails. If your exception takes arguments, but you call Exception.__init__ with a different number of arguments, it will fail. As in: class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-01 21:50 Message: Logged In: YES user_id=1326842 Originator: YES I'm attaching a test that Eric Huss sent in private mail. The test fails, because old exception pickles don't have args for the reconstructor, but their __init__() gets called anyway because they are new style classes now. The problem is in cPickle.InstanceNew() and pickle.Unpickler._instantiate(). Those methods behave differently depending on the type of the object instantiated; they avoid the __init__() call when type is an old style class. There is nothing that can be done in the exception classes to fix this issue; the fix would need to be in the pickle and cPickle module. File Added: test_exception_pickle.py ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-01 13:47 Message: Logged In: YES user_id=1326842 Originator: YES File Added: exc_args_25.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1692335&group_id=5470 From noreply at sourceforge.net Sun Aug 12 14:34:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Aug 2007 05:34:47 -0700 Subject: [Patches] [ python-Patches-1692335 ] Move initial args assignment to BaseException.__new__ Message-ID: Patches item #1692335, was opened at 2007-04-01 15:46 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1692335&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 Private: No Submitted By: Ziga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Move initial args assignment to BaseException.__new__ Initial Comment: Pickling exceptions fails when an Exception class requires an argument in the constructor, but doesn't call its base class' constructor. See this mail for details: http://mail.python.org/pipermail/python-dev/2007-April/072416.html This patch simply moves initial args assignment to BaseException.__new__. This should fix most of the problems, because it is very unlikely that an exception overwrites the __new__ method; exceptions used to be old style classes, which don't support the __new__ special method. The args attribute is still overwritten in all the __init__ methods, so there shouldn't be any backward compatibility problems. ---------------------------------------------------------------------- >Comment By: Ziga Seilnacht (zseil) Date: 2007-08-12 14:34 Message: Logged In: YES user_id=1326842 Originator: YES It's not just the message attribute; the problem is that the current code expects that the exception won't be modified between creation and unpickling. For example: >>> import pickle >>> e = EnvironmentError() >>> e.filename = "x" >>> new = pickle.dumps(pickle.loads(e)) >>> print new.filename None >>> e = SyntaxError() >>> e.lineno = 10 >>> new = pickle.loads(pickle.dumps(e)) >>> print new.lineno None ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-12 14:13 Message: Logged In: YES user_id=849994 Originator: NO I wouldn't care too much about .message; it was new in 2.5 and is already deprecated in 2.6. ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-08-12 13:24 Message: Logged In: YES user_id=1326842 Originator: YES File Added: exception_pickling_26.diff ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-08-12 13:23 Message: Logged In: YES user_id=1326842 Originator: YES There is also the problem that Jim Fulton mentioned in bug #1742889; if the user modifies the 'message' attribute of an exception (or any other attribute that is not stored in the __dict__), it won't get serialized on pickling. Attaching a new patch that fixes this by using the __getstate__() pickling hook. It uses tp_members and tp_getset members of the type object to find all the attributes that need to be serialized. The 2.5 patch also contains a fix for migrating old exception pickles to Python 2.5. For that I had to change cPickle and pickle. It would be nice if Jim could comment if this change is needed, since ZODB is probably the biggest user of these modules. The downside is that this patch is fairly big. File Added: exception_pickling_25.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-12 10:01 Message: Logged In: YES user_id=849994 Originator: NO The only question left is what to do if something reassigns exceptioninstance.args. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-12 10:00 Message: Logged In: YES user_id=849994 Originator: NO The only question left is what to do if something reassigns exceptioninstance.args. ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-08-12 03:33 Message: Logged In: YES user_id=393416 Originator: NO Georg's new patch looks good to me, it seems to pass all the scenarios that I know of. You can close out my patch if you check this in. Thanks for looking into this! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-11 20:27 Message: Logged In: YES user_id=33168 Originator: NO self->args needs to be initialized to NULL because if the alloc of args failed, self->args would be uninitialized and deallocated. (I realize the alloc of an empty tuple will realistically never fail currently.) I'm not sure if this could cause any new problems because of the behavior change, but the code itself looked fine to me. Hopefully someone with more knowledge of exceptions could take a look at the idea. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-11 11:06 Message: Logged In: YES user_id=849994 Originator: NO Attaching a new patch that fixes the class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) scenario by keeping the original args to __new__ as an exception attribute. File Added: exception-pickling.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-11 11:06 Message: Logged In: YES user_id=849994 Originator: NO Attaching a new patch that fixes the class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) scenario by keeping the original args to __new__ as an exception attribute. File Added: exception-pickling.diff ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-06-27 20:45 Message: Logged In: YES user_id=393416 Originator: NO Added patch #1744398 as an alternate solution. ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-06-15 02:34 Message: Logged In: YES user_id=393416 Originator: NO I have stumbled across another scenario where unpickling fails. If your exception takes arguments, but you call Exception.__init__ with a different number of arguments, it will fail. As in: class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-01 23:50 Message: Logged In: YES user_id=1326842 Originator: YES I'm attaching a test that Eric Huss sent in private mail. The test fails, because old exception pickles don't have args for the reconstructor, but their __init__() gets called anyway because they are new style classes now. The problem is in cPickle.InstanceNew() and pickle.Unpickler._instantiate(). Those methods behave differently depending on the type of the object instantiated; they avoid the __init__() call when type is an old style class. There is nothing that can be done in the exception classes to fix this issue; the fix would need to be in the pickle and cPickle module. File Added: test_exception_pickle.py ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-01 15:47 Message: Logged In: YES user_id=1326842 Originator: YES File Added: exc_args_25.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1692335&group_id=5470 From noreply at sourceforge.net Sun Aug 12 15:24:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Aug 2007 06:24:17 -0700 Subject: [Patches] [ python-Patches-1692335 ] Move initial args assignment to BaseException.__new__ Message-ID: Patches item #1692335, was opened at 2007-04-01 13:46 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1692335&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 Private: No Submitted By: Ziga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Move initial args assignment to BaseException.__new__ Initial Comment: Pickling exceptions fails when an Exception class requires an argument in the constructor, but doesn't call its base class' constructor. See this mail for details: http://mail.python.org/pipermail/python-dev/2007-April/072416.html This patch simply moves initial args assignment to BaseException.__new__. This should fix most of the problems, because it is very unlikely that an exception overwrites the __new__ method; exceptions used to be old style classes, which don't support the __new__ special method. The args attribute is still overwritten in all the __init__ methods, so there shouldn't be any backward compatibility problems. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-12 13:24 Message: Logged In: YES user_id=849994 Originator: NO Yes, this is what I meant with my last comment. ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-08-12 12:34 Message: Logged In: YES user_id=1326842 Originator: YES It's not just the message attribute; the problem is that the current code expects that the exception won't be modified between creation and unpickling. For example: >>> import pickle >>> e = EnvironmentError() >>> e.filename = "x" >>> new = pickle.dumps(pickle.loads(e)) >>> print new.filename None >>> e = SyntaxError() >>> e.lineno = 10 >>> new = pickle.loads(pickle.dumps(e)) >>> print new.lineno None ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-12 12:13 Message: Logged In: YES user_id=849994 Originator: NO I wouldn't care too much about .message; it was new in 2.5 and is already deprecated in 2.6. ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-08-12 11:24 Message: Logged In: YES user_id=1326842 Originator: YES File Added: exception_pickling_26.diff ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-08-12 11:23 Message: Logged In: YES user_id=1326842 Originator: YES There is also the problem that Jim Fulton mentioned in bug #1742889; if the user modifies the 'message' attribute of an exception (or any other attribute that is not stored in the __dict__), it won't get serialized on pickling. Attaching a new patch that fixes this by using the __getstate__() pickling hook. It uses tp_members and tp_getset members of the type object to find all the attributes that need to be serialized. The 2.5 patch also contains a fix for migrating old exception pickles to Python 2.5. For that I had to change cPickle and pickle. It would be nice if Jim could comment if this change is needed, since ZODB is probably the biggest user of these modules. The downside is that this patch is fairly big. File Added: exception_pickling_25.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-12 08:01 Message: Logged In: YES user_id=849994 Originator: NO The only question left is what to do if something reassigns exceptioninstance.args. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-12 08:00 Message: Logged In: YES user_id=849994 Originator: NO The only question left is what to do if something reassigns exceptioninstance.args. ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-08-12 01:33 Message: Logged In: YES user_id=393416 Originator: NO Georg's new patch looks good to me, it seems to pass all the scenarios that I know of. You can close out my patch if you check this in. Thanks for looking into this! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-11 18:27 Message: Logged In: YES user_id=33168 Originator: NO self->args needs to be initialized to NULL because if the alloc of args failed, self->args would be uninitialized and deallocated. (I realize the alloc of an empty tuple will realistically never fail currently.) I'm not sure if this could cause any new problems because of the behavior change, but the code itself looked fine to me. Hopefully someone with more knowledge of exceptions could take a look at the idea. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-11 09:06 Message: Logged In: YES user_id=849994 Originator: NO Attaching a new patch that fixes the class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) scenario by keeping the original args to __new__ as an exception attribute. File Added: exception-pickling.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-11 09:06 Message: Logged In: YES user_id=849994 Originator: NO Attaching a new patch that fixes the class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) scenario by keeping the original args to __new__ as an exception attribute. File Added: exception-pickling.diff ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-06-27 18:45 Message: Logged In: YES user_id=393416 Originator: NO Added patch #1744398 as an alternate solution. ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-06-15 00:34 Message: Logged In: YES user_id=393416 Originator: NO I have stumbled across another scenario where unpickling fails. If your exception takes arguments, but you call Exception.__init__ with a different number of arguments, it will fail. As in: class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-01 21:50 Message: Logged In: YES user_id=1326842 Originator: YES I'm attaching a test that Eric Huss sent in private mail. The test fails, because old exception pickles don't have args for the reconstructor, but their __init__() gets called anyway because they are new style classes now. The problem is in cPickle.InstanceNew() and pickle.Unpickler._instantiate(). Those methods behave differently depending on the type of the object instantiated; they avoid the __init__() call when type is an old style class. There is nothing that can be done in the exception classes to fix this issue; the fix would need to be in the pickle and cPickle module. File Added: test_exception_pickle.py ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-01 13:47 Message: Logged In: YES user_id=1326842 Originator: YES File Added: exc_args_25.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1692335&group_id=5470 From noreply at sourceforge.net Sun Aug 12 18:43:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Aug 2007 09:43:07 -0700 Subject: [Patches] [ python-Patches-1772673 ] Replacing char* with const char* Message-ID: Patches item #1772673, was opened at 2007-08-12 18:43 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=1772673&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: eXt (ext-) Assigned to: Nobody/Anonymous (nobody) Summary: Replacing char* with const char* Initial Comment: Many functions use char* where const char* should be used. I've changed this in a few function prototypes which I use while embedding python due to numerous warnings about deprecated casting from string constants to char*. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1772673&group_id=5470 From noreply at sourceforge.net Sun Aug 12 21:05:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Aug 2007 12:05:44 -0700 Subject: [Patches] [ python-Patches-1772721 ] [python-mode] Properly highlight lambda with no arguments Message-ID: Patches item #1772721, was opened at 2007-08-12 21:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1772721&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Demos and tools Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michal Kwiatkowski (rubyjoker) Assigned to: Nobody/Anonymous (nobody) Summary: [python-mode] Properly highlight lambda with no arguments Initial Comment: Currently source highlighter in python-mode doesn't catch lambda forms without arguments, i.e. in: function = lambda: 42 word "lambda" is not highlighted. Attached patch fixes this issue by adding new rule to python-font-lock-keywords list. Patch against current trunk (r56963 now). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1772721&group_id=5470 From noreply at sourceforge.net Mon Aug 13 00:30:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Aug 2007 15:30:14 -0700 Subject: [Patches] [ python-Patches-1736190 ] asyncore/asynchat patches Message-ID: Patches item #1736190, was opened at 2007-06-12 17:37 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1736190&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 Private: No Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Josiah Carlson (josiahcarlson) Summary: asyncore/asynchat patches Initial Comment: There are a handful of outstanding asyncore/asynchat related bugs in the tracker. This patch seeks to handle all of the issues with the exception of windows-specific socket errors from 658749 . In particular, it takes pieces of patches 909005 and 1736101, to address some issues raised there, as well as the bugs: 539444, 760475, 777588, 889153, 953599, 1025525, and 1063924. In some cases where it could potentially handle fewer exceptions (see the send method), I have opted to handle more of them due to testing actually producing them. It adds test cases from patch 909005. It adds two new sample methods to asynchat.async_chat _get_data and _collect_incoming_data to be used as examples for handling incoming buffers. It removes the simple_producer and fifo classes from asynchat, but accepts work-alikes to the asynchat.async_chat.push_with_producer method. It further fixes an unreported violated invariant in asynchat.async_chat.handle_read() . It also produces a useful error message when asyncore.dispatcher.handle_expt_evt is called if the base handle_expt has not been overwritten. This patch should be applied to the trunk. The new methods, and removal of the two classes should not be included in patches to 2.5 maintenance (don't add the methods and don't remove the classes). Basically everything else should work as it did before (with better error handling), unless someone was monkey-patching asyncore.dispatcher.handle_expt . ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2007-08-12 15:30 Message: Logged In: YES user_id=341410 Originator: YES We can leave those two classes in, even though I have never seen them used or subclassed. In Python 3.x, we can remove them without issue. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-08 09:09 Message: Logged In: YES user_id=1115903 Originator: NO This patch removes two public--and documented--classes from asynchat (simple_producer and fifo). Even if the proposed changes to asynchat make them utterly worthless, I thought it was general policy to deprecate public items for a release or two before removing them. Is this the case even when they're as simple as these two classes? ---------------------------------------------------------------------- Comment By: billiejoex (billiejoex) Date: 2007-07-11 08:16 Message: Logged In: YES user_id=1357589 Originator: NO Good work. I would only rencommend to include documentation for asyncore.close_all function, actually not documented yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1736190&group_id=5470 From noreply at sourceforge.net Mon Aug 13 05:33:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Aug 2007 20:33:19 -0700 Subject: [Patches] [ python-Patches-1772833 ] -q (quiet) option for python interpreter Message-ID: Patches item #1772833, was opened at 2007-08-13 05:33 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=1772833&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Marcin Wojdyr (wojdyr) Assigned to: Nobody/Anonymous (nobody) Summary: -q (quiet) option for python interpreter Initial Comment: Implementation of feature request 1728488 Added interpreter option: -q Do not print the version and copyright messages. These messages are also suppressed in non-interactive mode. BTW: Above the usage_* strings in main.c there is a comment: /* Long usage message, split into parts < 512 bytes */ Why do we have this limit? (actually one of the strings was ~570 bytes). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1772833&group_id=5470 From noreply at sourceforge.net Mon Aug 13 06:48:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Aug 2007 21:48:04 -0700 Subject: [Patches] [ python-Patches-1772851 ] Decimal and long hash, compatibly and efficiently Message-ID: Patches item #1772851, was opened at 2007-08-13 04:48 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=1772851&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 Private: No Submitted By: Mark Dickinson (marketdickinson) Assigned to: Nobody/Anonymous (nobody) Summary: Decimal and long hash, compatibly and efficiently Initial Comment: Make hash of int/long periodic with period 2**32-1 (or 2**64-1 on 64-bit systems). This is makes it possible to define an efficient Decimal hash. Hash for int/long is already close to periodic with period 2**32-1; it's a small change to make it genuinely periodic. With this change, it's possible to write a Decimal __hash__ such that: (1) hash(Decimal(n))==hash(n) for all integers n, and (2) Decimal hash can be computed without gross inefficiencies. The current implementation of Decimal hash is almost unusable for very large Decimals: hash(Decimal("1E999999999")) first converts its argument to a long, taking gigabytes of memory and a lot of time. It's simple to satisfy either (1) or (2) above, but it seems impossible to satisfy both without touching the long hash. The patch alters int_hash and long_hash to make them periodic, adds some tests to Lib/test/test_hash.py, and implements an efficient Decimal.__hash__. If there's any chance of the patch being accepted I'll write some additional tests in Lib/test/test_decimal.py to check hash compatibility between longs and Decimals. This patch fixes (most of) bug 1770416. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1772851&group_id=5470 From noreply at sourceforge.net Mon Aug 13 08:16:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Aug 2007 23:16:31 -0700 Subject: [Patches] [ python-Patches-1772833 ] -q (quiet) option for python interpreter Message-ID: Patches item #1772833, was opened at 2007-08-13 03:33 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1772833&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Marcin Wojdyr (wojdyr) Assigned to: Nobody/Anonymous (nobody) Summary: -q (quiet) option for python interpreter Initial Comment: Implementation of feature request 1728488 Added interpreter option: -q Do not print the version and copyright messages. These messages are also suppressed in non-interactive mode. BTW: Above the usage_* strings in main.c there is a comment: /* Long usage message, split into parts < 512 bytes */ Why do we have this limit? (actually one of the strings was ~570 bytes). ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-13 06:16 Message: Logged In: YES user_id=849994 Originator: NO I'd expect the 512 bytes limit was due to some compiler restrictions. Whether these compilers are still in operation, I don't know. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1772833&group_id=5470 From noreply at sourceforge.net Mon Aug 13 08:16:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Aug 2007 23:16:45 -0700 Subject: [Patches] [ python-Patches-1772833 ] -q (quiet) option for python interpreter Message-ID: Patches item #1772833, was opened at 2007-08-13 03:33 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1772833&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Marcin Wojdyr (wojdyr) Assigned to: Nobody/Anonymous (nobody) Summary: -q (quiet) option for python interpreter Initial Comment: Implementation of feature request 1728488 Added interpreter option: -q Do not print the version and copyright messages. These messages are also suppressed in non-interactive mode. BTW: Above the usage_* strings in main.c there is a comment: /* Long usage message, split into parts < 512 bytes */ Why do we have this limit? (actually one of the strings was ~570 bytes). ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-13 06:16 Message: Logged In: YES user_id=849994 Originator: NO I'd expect the 512 bytes limit was due to some compiler restrictions. Whether these compilers are still in operation, I don't know. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-13 06:16 Message: Logged In: YES user_id=849994 Originator: NO I'd expect the 512 bytes limit was due to some compiler restrictions. Whether these compilers are still in operation, I don't know. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1772833&group_id=5470 From noreply at sourceforge.net Mon Aug 13 17:18:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Aug 2007 08:18:21 -0700 Subject: [Patches] [ python-Patches-1772851 ] Decimal and long hash, compatibly and efficiently Message-ID: Patches item #1772851, was opened at 2007-08-13 01:48 Message generated for change (Settings changed) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1772851&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 Private: No Submitted By: Mark Dickinson (marketdickinson) >Assigned to: Facundo Batista (facundobatista) Summary: Decimal and long hash, compatibly and efficiently Initial Comment: Make hash of int/long periodic with period 2**32-1 (or 2**64-1 on 64-bit systems). This is makes it possible to define an efficient Decimal hash. Hash for int/long is already close to periodic with period 2**32-1; it's a small change to make it genuinely periodic. With this change, it's possible to write a Decimal __hash__ such that: (1) hash(Decimal(n))==hash(n) for all integers n, and (2) Decimal hash can be computed without gross inefficiencies. The current implementation of Decimal hash is almost unusable for very large Decimals: hash(Decimal("1E999999999")) first converts its argument to a long, taking gigabytes of memory and a lot of time. It's simple to satisfy either (1) or (2) above, but it seems impossible to satisfy both without touching the long hash. The patch alters int_hash and long_hash to make them periodic, adds some tests to Lib/test/test_hash.py, and implements an efficient Decimal.__hash__. If there's any chance of the patch being accepted I'll write some additional tests in Lib/test/test_decimal.py to check hash compatibility between longs and Decimals. This patch fixes (most of) bug 1770416. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1772851&group_id=5470 From noreply at sourceforge.net Tue Aug 14 07:30:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Aug 2007 22:30:09 -0700 Subject: [Patches] [ python-Patches-1773632 ] Remove references to _xmlrpclib from xmlrpclib.py Message-ID: Patches item #1773632, was opened at 2007-08-14 00:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1773632&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alan McIntyre (alanmcintyre) Assigned to: Nobody/Anonymous (nobody) Summary: Remove references to _xmlrpclib from xmlrpclib.py Initial Comment: The _xmlrpclib accelerator extension for xmlrpclib is long gone from stdlib, but there are still references to it in xmlrpclib.py. This patch removes those references. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1773632&group_id=5470 From noreply at sourceforge.net Wed Aug 15 00:35:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Aug 2007 15:35:14 -0700 Subject: [Patches] [ python-Patches-1774369 ] Unify __builtins__ -> __builtin__ Message-ID: Patches item #1774369, was opened at 2007-08-15 00:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1774369&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Nobody/Anonymous (nobody) Summary: Unify __builtins__ -> __builtin__ Initial Comment: The patch renames __builtins__ to __builtin__ in the C and Python sources and renames builtins to builtin in the C code. Missing: * documentation update * 2to3 fixer ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1774369&group_id=5470 From noreply at sourceforge.net Wed Aug 15 00:38:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Aug 2007 15:38:20 -0700 Subject: [Patches] [ python-Patches-1774370 ] Add Checkbutton get() and set(value) Message-ID: Patches item #1774370, was opened at 2007-08-14 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=1774370&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Graham Horler (grahamh) Assigned to: Martin v. L?wis (loewis) Summary: Add Checkbutton get() and set(value) Initial Comment: Add get() and set(value) methods to the Checkbutton class, providing access to the default variable created by Tk. See man checkbutton(3tk). The get() and set(value) method names are analogous to those in the Variable class. When using get() and set(), you do not have to create a XyzVar instance to pass to a Checkbutton's 'variable' attribute. This is much simpler and more intuitive, and also avoids leaking the default variable. If you do override the 'variable' attribute, the get() and set(value) also give access to your new variable. Setting 'onvalue' and 'offvalue' also work as expected. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1774370&group_id=5470 From noreply at sourceforge.net Wed Aug 15 03:00:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Aug 2007 18:00:32 -0700 Subject: [Patches] [ python-Patches-1774414 ] Make it possible to use SVK to develop Python Message-ID: Patches item #1774414, was opened at 2007-08-14 21:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1774414&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Make it possible to use SVK to develop Python Initial Comment: I want to use SVK instead of SVN when developing Python on my laptop. Currently, the parsing of HEADURL in Python/sysmodule.c:svnversion_init() kills the interpreter at start-up because the HEADURL for SVK looks like /py3k/local/Python/sysmodule.c. The attached patch causes svnversion_init() to use "unknown" for the branch name instead of raising a fatal error when it encounters a mis-formatted HEADURL. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1774414&group_id=5470 From noreply at sourceforge.net Wed Aug 15 03:00:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Aug 2007 18:00:49 -0700 Subject: [Patches] [ python-Patches-1774414 ] Make it possible to use SVK to develop Python Message-ID: Patches item #1774414, was opened at 2007-08-14 21:00 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1774414&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) >Assigned to: Neal Norwitz (nnorwitz) Summary: Make it possible to use SVK to develop Python Initial Comment: I want to use SVK instead of SVN when developing Python on my laptop. Currently, the parsing of HEADURL in Python/sysmodule.c:svnversion_init() kills the interpreter at start-up because the HEADURL for SVK looks like /py3k/local/Python/sysmodule.c. The attached patch causes svnversion_init() to use "unknown" for the branch name instead of raising a fatal error when it encounters a mis-formatted HEADURL. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1774414&group_id=5470 From noreply at sourceforge.net Wed Aug 15 18:13:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Aug 2007 09:13:12 -0700 Subject: [Patches] [ python-Patches-1774828 ] Override flags set by IOBase in io.StringIO Message-ID: Patches item #1774828, was opened at 2007-08-15 12:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1774828&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexandre Vassalotti (avassalotti) Assigned to: Nobody/Anonymous (nobody) Summary: Override flags set by IOBase in io.StringIO Initial Comment: This patch fixes a small bug in the flags of io.StringIO: >>> import io >>> s = io.StringIO() >>> s.writable() False >>> s.seekable() False >>> s.readable() False All the flags should have the value True. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1774828&group_id=5470 From noreply at sourceforge.net Wed Aug 15 18:23:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Aug 2007 09:23:55 -0700 Subject: [Patches] [ python-Patches-1774833 ] Convert str to bytes in io.BytesIO.__init__ Message-ID: Patches item #1774833, was opened at 2007-08-15 12:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1774833&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexandre Vassalotti (avassalotti) Assigned to: Nobody/Anonymous (nobody) Summary: Convert str to bytes in io.BytesIO.__init__ Initial Comment: This patch allows a str object to be used as the initial value of io.BytesIO: >>> x = io.BytesIO('1234') Traceback (most recent call last): File "", line 1, in File "/home/alex/src/python.org/py3k/Lib/io.py", line 592, in __init__ buffer += initial_bytes TypeError: can't concat bytes to str ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1774833&group_id=5470 From noreply at sourceforge.net Wed Aug 15 18:28:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Aug 2007 09:28:51 -0700 Subject: [Patches] [ python-Patches-1774828 ] Override flags set by IOBase in io.StringIO Message-ID: Patches item #1774828, was opened at 2007-08-15 12:13 Message generated for change (Comment added) made by avassalotti You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1774828&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexandre Vassalotti (avassalotti) Assigned to: Nobody/Anonymous (nobody) Summary: Override flags set by IOBase in io.StringIO Initial Comment: This patch fixes a small bug in the flags of io.StringIO: >>> import io >>> s = io.StringIO() >>> s.writable() False >>> s.seekable() False >>> s.readable() False All the flags should have the value True. ---------------------------------------------------------------------- >Comment By: Alexandre Vassalotti (avassalotti) Date: 2007-08-15 12:28 Message: Logged In: YES user_id=1826340 Originator: YES This should probably be fixed in TextIOWrapper too: >>> f = open("+spam", "w") >>> f.writable() False ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1774828&group_id=5470 From noreply at sourceforge.net Thu Aug 16 00:37:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Aug 2007 15:37:50 -0700 Subject: [Patches] [ python-Patches-1775025 ] zipfile: Allow reading duplicate filenames Message-ID: Patches item #1775025, was opened at 2007-08-15 23: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=1775025&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 Private: No Submitted By: Graham Horler (grahamh) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile: Allow reading duplicate filenames Initial Comment: Allow open() 'name' parameter to be a ZipInfo object, which allows opening archive members with duplicate filenames. Also allow read() 'name' parameter to be a ZipInfo object, as it calls open() directly. I got sent a zip file which had duplicate names in it, and the only way I could see to extract it using zipfile.py was to apply this patch. The infolist() and namelist() methods will return information for duplicate filenames, but the open() method takes only a name. This patch also updated the docs for zipfile.py. Python 2.1 -> 2.5 zipfile.py module does not have an open() method, but it would be trivial to backport this patch to enhance the read() method. # Test: # write() optionally warns, but still allows, # creating duplicate file names: import zipfile zf = zipfile.ZipFile('dupzip.zip', 'w') zf.debug = 1 zf.writestr('dupname', 'Hello') zf.writestr('dupname', 'World') zf.close() # Print 'Hello' 'World' zfr = zipfile.ZipFile('dupzip.zip', 'r') for inf in zfr.infolist(): print repr(zfr.read(inf)) zfr.close() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1775025&group_id=5470 From noreply at sourceforge.net Thu Aug 16 00:38:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Aug 2007 15:38:35 -0700 Subject: [Patches] [ python-Patches-1774370 ] Add Tkinter.Checkbutton get() and set(value) Message-ID: Patches item #1774370, was opened at 2007-08-14 23:38 Message generated for change (Settings changed) made by grahamh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1774370&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Graham Horler (grahamh) Assigned to: Martin v. L?wis (loewis) >Summary: Add Tkinter.Checkbutton get() and set(value) Initial Comment: Add get() and set(value) methods to the Checkbutton class, providing access to the default variable created by Tk. See man checkbutton(3tk). The get() and set(value) method names are analogous to those in the Variable class. When using get() and set(), you do not have to create a XyzVar instance to pass to a Checkbutton's 'variable' attribute. This is much simpler and more intuitive, and also avoids leaking the default variable. If you do override the 'variable' attribute, the get() and set(value) also give access to your new variable. Setting 'onvalue' and 'offvalue' also work as expected. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1774370&group_id=5470 From noreply at sourceforge.net Thu Aug 16 07:57:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Aug 2007 22:57:10 -0700 Subject: [Patches] [ python-Patches-1774414 ] Make it possible to use SVK to develop Python Message-ID: Patches item #1774414, was opened at 2007-08-14 18:00 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1774414&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 3000 Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) >Assigned to: Collin Winter (collinwinter) Summary: Make it possible to use SVK to develop Python Initial Comment: I want to use SVK instead of SVN when developing Python on my laptop. Currently, the parsing of HEADURL in Python/sysmodule.c:svnversion_init() kills the interpreter at start-up because the HEADURL for SVK looks like /py3k/local/Python/sysmodule.c. The attached patch causes svnversion_init() to use "unknown" for the branch name instead of raising a fatal error when it encounters a mis-formatted HEADURL. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-15 22:57 Message: Logged In: YES user_id=33168 Originator: NO This is fine. Note the indentation is screwed up. It looks like some mixing of tabs and spaces. It would be good to add a comment near the copying of "unknown" to mention about supporting svk and possibly other SCM systems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1774414&group_id=5470 From noreply at sourceforge.net Thu Aug 16 18:56:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Aug 2007 09:56:41 -0700 Subject: [Patches] [ python-Patches-1775604 ] utt-32 codecs Message-ID: Patches item #1775604, was opened at 2007-08-16 18:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1775604&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: utt-32 codecs Initial Comment: This patch adds three new codecs: utf-32, utf-32-le and utf-32-be. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1775604&group_id=5470 From noreply at sourceforge.net Thu Aug 16 18:56:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Aug 2007 09:56:59 -0700 Subject: [Patches] [ python-Patches-1775604 ] utf-32 codecs Message-ID: Patches item #1775604, was opened at 2007-08-16 18:56 Message generated for change (Settings changed) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1775604&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) >Summary: utf-32 codecs Initial Comment: This patch adds three new codecs: utf-32, utf-32-le and utf-32-be. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1775604&group_id=5470 From noreply at sourceforge.net Fri Aug 17 22:52:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Aug 2007 13:52:46 -0700 Subject: [Patches] [ python-Patches-1776581 ] Minor corrections to smtplib Message-ID: Patches item #1776581, was opened at 2007-08-17 15:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1776581&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alan McIntyre (alanmcintyre) Assigned to: Nobody/Anonymous (nobody) Summary: Minor corrections to smtplib Initial Comment: Two minor changes: - In SMTP.send, there is a check for self.sock, which may not exist if there has been no attempt to connect. This patch adds a check for hasattr(self, 'sock') so that such an attempt to call send() will raise the more helpful SMTPServerDisconnected instead of an AttributeError. - The docstring for SMTP.expn is a copy of that of the verify method. This patch changes it to something more appropriate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1776581&group_id=5470 From noreply at sourceforge.net Fri Aug 17 23:12:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Aug 2007 14:12:13 -0700 Subject: [Patches] [ python-Patches-1776581 ] Minor corrections to smtplib Message-ID: Patches item #1776581, was opened at 2007-08-17 15:52 Message generated for change (Settings changed) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1776581&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alan McIntyre (alanmcintyre) >Assigned to: Facundo Batista (facundobatista) Summary: Minor corrections to smtplib Initial Comment: Two minor changes: - In SMTP.send, there is a check for self.sock, which may not exist if there has been no attempt to connect. This patch adds a check for hasattr(self, 'sock') so that such an attempt to call send() will raise the more helpful SMTPServerDisconnected instead of an AttributeError. - The docstring for SMTP.expn is a copy of that of the verify method. This patch changes it to something more appropriate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1776581&group_id=5470 From noreply at sourceforge.net Sat Aug 18 19:41:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Aug 2007 10:41:57 -0700 Subject: [Patches] [ python-Patches-1771364 ] Misc improvements for the io module Message-ID: Patches item #1771364, was opened at 2007-08-10 01:43 Message generated for change (Comment added) made by tonylownds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1771364&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Guido van Rossum (gvanrossum) Summary: Misc improvements for the io module Initial Comment: My patch fixes small parts of the io module: * replaced all asserts with appropriate TypeError() or ValueError() exceptions * default to buffering = 1 when raw is a tty * added four methods _checkSeekable(msg=None), _checkReadable, _checkWritable and _checkClosed as convenient methods to raise exceptions when a file is closed or not read, write or seekable. * added a unit test to check __all__ * SocketIO.readable/writeable checks for self.closed, too * SocketIO.readinto/write checks for readable, writeable and closed status __all__ references SocketIO but it is not available in io.py. The definition is in socket.py and it doesn't use any socket related code directly. What do you think about moving SocketIO to io.py in the sake of keeping everything together? NOTE: You may want to check my English in the exception messages. ;) ---------------------------------------------------------------------- Comment By: Tony Lownds (tonylownds) Date: 2007-08-18 17:41 Message: Logged In: YES user_id=24100 Originator: NO Your English is fine :) The _checkSeekable etc methods are a good idea. But the message parameter is not used, so why have it? They should be lowercase names to match PEP 8. Also, shouldn't use the internal methods on parameters other than self: - assert raw.seekable() + raw._checkSeekable() I'm not sure it's a good idea to do the first todo without the second here: -XXX need to default buffer size to 1 if isatty() XXX need to support 1 meaning line-buffered ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1771364&group_id=5470 From noreply at sourceforge.net Sat Aug 18 22:34:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Aug 2007 13:34:24 -0700 Subject: [Patches] [ python-Patches-1774369 ] Unify __builtins__ -> __builtin__ Message-ID: Patches item #1774369, was opened at 2007-08-14 18:35 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1774369&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Nobody/Anonymous (nobody) Summary: Unify __builtins__ -> __builtin__ Initial Comment: The patch renames __builtins__ to __builtin__ in the C and Python sources and renames builtins to builtin in the C code. Missing: * documentation update * 2to3 fixer ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-18 16:34 Message: Logged In: YES user_id=6380 Originator: NO Thanks! (Though I wish you'd left the C variable names alone, the patch is unnecessarily big this way.) I am also wondering about some semantic endcases; in 2.x, it is *possible* to have __builtin__ and __builtins__ point to different place, and I am going to do some soul-searching to make sure that's not a loss of functionality. No need to update the patch, I just have to think about it some more. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1774369&group_id=5470 From noreply at sourceforge.net Sun Aug 19 09:34:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Aug 2007 00:34:59 -0700 Subject: [Patches] [ python-Patches-1648102 ] proxy_bypass in urllib handling of macro Message-ID: Patches item #1648102, was opened at 2007-01-30 23:44 Message generated for change (Comment added) made by orsenthil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1648102&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 Private: No Submitted By: Anthony Tuininga (atuining) Assigned to: Nobody/Anonymous (nobody) Summary: proxy_bypass in urllib handling of macro Initial Comment: We have discovered that the handling of the macro in urllib.proxy_bypass is broken. According to the Microsoft documentation for this macro, what should be checked is simply that the host name specified does not contain a period. Since urllib gets its proxy information directly from the Windows registry it would make sense to use the same definitions that Microsoft does. Attached is a patch that does this. Here is a link to the documentation that specifies this: http://msdn2.microsoft.com/en-gb/library/aa384098.aspx Note the section discussing the proxy bypass parameter. In addition, this patch adds code to strip the entries in the proxy bypass settings of any leading and trailing spaces. Internet Explorer supports this although it does not appear to be officially documented. ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-19 13:04 Message: Logged In: YES user_id=942711 Originator: NO >From the documentation: pwszProxyBypass [in] A pointer to a string variable that contains an optional list of host names or IP addresses, or both, that should not be routed through the proxy when dwAccessType is set to WINHTTP_ACCESS_TYPE_NAMED_PROXY. The list can contain wildcard characters. Do not use an empty string, because the WinHttpOpen function uses it as the proxy bypass list. If this parameter specifies the "" macro as the only entry, this function bypasses any host name that does not contain a period. If dwAccessType is not set to WINHTTP_ACCESS_TYPE_NAMED_PROXY, this parameter must be set to WINHTTP_NO_PROXY_BYPASS. Yes,valid patch for urllib.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1648102&group_id=5470 From noreply at sourceforge.net Sun Aug 19 10:22:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Aug 2007 01:22:34 -0700 Subject: [Patches] [ python-Patches-1664522 ] Fix for urllib.ftpwrapper.retrfile() and none existing files Message-ID: Patches item #1664522, was opened at 2007-02-20 23:03 Message generated for change (Comment added) made by orsenthil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1664522&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Phil Knirsch (pknirsch) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for urllib.ftpwrapper.retrfile() and none existing files Initial Comment: When trying to retrieve a none existing file using the urllib.ftpwrapper.retrfile() method the behaviour is that instead of an error message a valid hook is returned and you will recieve a 0 byte file. The current behaviour tries to emulate what one typically sees with http servers and DirIndexes, which means: 1) Try to RETR the file. 2) If that fails, assume it is a directory and LIST it. Unfortunately it doesn't actually check whether the directory actually exists. The attached patch fixes this by remembering the current directory using the PWD command, then temporarily change to that directory and switch back to the previous working directory if it was successfull. If not we raise an IO error, as the file could neither be opened (RETR) nor was it a directory. That way the behaviour is even closer to what happens with http servers where we get a 404 when we try to access a none existing file or directory. Storing the current directory and switching back to it in case of no error will also put the connection back in the proper state and directory, so no unexpected behaviour happens here. The patch is against the current SVN repository at revision 53833. Read ya, Phil ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-19 13:52 Message: Logged In: YES user_id=942711 Originator: NO Yes, a useful patch. Verified and tested it. Works fine. ---------------------------------------------------------------------- Comment By: Phil Knirsch (pknirsch) Date: 2007-03-29 16:21 Message: Logged In: YES user_id=1724367 Originator: YES Oh, and the fix is ofc against the current tree, which would be python-2.6 i guess, so fixed that. Read ya, Phil ---------------------------------------------------------------------- Comment By: Phil Knirsch (pknirsch) Date: 2007-03-29 16:16 Message: Logged In: YES user_id=1724367 Originator: YES Anyone looking at this? ;) Read ya, Phil ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1664522&group_id=5470 From noreply at sourceforge.net Sun Aug 19 10:42:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Aug 2007 01:42:36 -0700 Subject: [Patches] [ python-Patches-1777134 ] minidom pretty xml output improvement Message-ID: Patches item #1777134, was opened at 2007-08-19 10: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=1777134&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 Private: No Submitted By: Teajay (teajay_fr) Assigned to: Nobody/Anonymous (nobody) Summary: minidom pretty xml output improvement Initial Comment: This patch provides a fix to the minidom pretty xml output. In the initial version when outputing textnodes additional line breaks were added at the beginning and the end of the textnode block thus output false textnode content. If you load and save an xml document with textnodes the size of the textnodes increases every time. To fix this, a simple logic has been added to the textnode output function in order to prevent this behavior. This is my first patch submission so I hope I haven't done anything wrong. I so please let me know I'll be glad to improve it. Cheers and keep up the good work. Teajay ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1777134&group_id=5470 From noreply at sourceforge.net Sun Aug 19 15:47:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Aug 2007 06:47:48 -0700 Subject: [Patches] [ python-Patches-1771364 ] Misc improvements for the io module Message-ID: Patches item #1771364, was opened at 2007-08-10 03:43 Message generated for change (Comment added) made by tiran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1771364&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Guido van Rossum (gvanrossum) Summary: Misc improvements for the io module Initial Comment: My patch fixes small parts of the io module: * replaced all asserts with appropriate TypeError() or ValueError() exceptions * default to buffering = 1 when raw is a tty * added four methods _checkSeekable(msg=None), _checkReadable, _checkWritable and _checkClosed as convenient methods to raise exceptions when a file is closed or not read, write or seekable. * added a unit test to check __all__ * SocketIO.readable/writeable checks for self.closed, too * SocketIO.readinto/write checks for readable, writeable and closed status __all__ references SocketIO but it is not available in io.py. The definition is in socket.py and it doesn't use any socket related code directly. What do you think about moving SocketIO to io.py in the sake of keeping everything together? NOTE: You may want to check my English in the exception messages. ;) ---------------------------------------------------------------------- >Comment By: Christian Heimes (tiran) Date: 2007-08-19 15:47 Message: Logged In: YES user_id=560817 Originator: YES I've added the message parameter for the case that we have to use a different error message. For example: self._checkReadable("Can't read from a closed socket") I've done a lot of Zope, twisted and Qt development lately. I prefer camel case but you are right. The Python core has to follow PEP 8. What do you think about _isreadable(), _iswritable(), _isseekable()? ---------------------------------------------------------------------- Comment By: Tony Lownds (tonylownds) Date: 2007-08-18 19:41 Message: Logged In: YES user_id=24100 Originator: NO Your English is fine :) The _checkSeekable etc methods are a good idea. But the message parameter is not used, so why have it? They should be lowercase names to match PEP 8. Also, shouldn't use the internal methods on parameters other than self: - assert raw.seekable() + raw._checkSeekable() I'm not sure it's a good idea to do the first todo without the second here: -XXX need to default buffer size to 1 if isatty() XXX need to support 1 meaning line-buffered ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1771364&group_id=5470 From noreply at sourceforge.net Sun Aug 19 15:50:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Aug 2007 06:50:59 -0700 Subject: [Patches] [ python-Patches-1774369 ] Unify __builtins__ -> __builtin__ Message-ID: Patches item #1774369, was opened at 2007-08-15 00:35 Message generated for change (Comment added) made by tiran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1774369&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Nobody/Anonymous (nobody) Summary: Unify __builtins__ -> __builtin__ Initial Comment: The patch renames __builtins__ to __builtin__ in the C and Python sources and renames builtins to builtin in the C code. Missing: * documentation update * 2to3 fixer ---------------------------------------------------------------------- >Comment By: Christian Heimes (tiran) Date: 2007-08-19 15:50 Message: Logged In: YES user_id=560817 Originator: YES Personally I prefer to have one and just one way to spell a variable. I'd find it confusing to have __builtin__ (singular form) but a C variable named builtins (plural form). I changed it for aesthetic and consistency reasons. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-18 22:34 Message: Logged In: YES user_id=6380 Originator: NO Thanks! (Though I wish you'd left the C variable names alone, the patch is unnecessarily big this way.) I am also wondering about some semantic endcases; in 2.x, it is *possible* to have __builtin__ and __builtins__ point to different place, and I am going to do some soul-searching to make sure that's not a loss of functionality. No need to update the patch, I just have to think about it some more. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1774369&group_id=5470 From noreply at sourceforge.net Sun Aug 19 18:49:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Aug 2007 09:49:47 -0700 Subject: [Patches] [ python-Patches-1771364 ] Misc improvements for the io module Message-ID: Patches item #1771364, was opened at 2007-08-10 01:43 Message generated for change (Comment added) made by tonylownds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1771364&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Guido van Rossum (gvanrossum) Summary: Misc improvements for the io module Initial Comment: My patch fixes small parts of the io module: * replaced all asserts with appropriate TypeError() or ValueError() exceptions * default to buffering = 1 when raw is a tty * added four methods _checkSeekable(msg=None), _checkReadable, _checkWritable and _checkClosed as convenient methods to raise exceptions when a file is closed or not read, write or seekable. * added a unit test to check __all__ * SocketIO.readable/writeable checks for self.closed, too * SocketIO.readinto/write checks for readable, writeable and closed status __all__ references SocketIO but it is not available in io.py. The definition is in socket.py and it doesn't use any socket related code directly. What do you think about moving SocketIO to io.py in the sake of keeping everything together? NOTE: You may want to check my English in the exception messages. ;) ---------------------------------------------------------------------- Comment By: Tony Lownds (tonylownds) Date: 2007-08-19 16:49 Message: Logged In: YES user_id=24100 Originator: NO >I've added the message parameter for the case that we have to use a >different error message. For example: >self._checkReadable("Can't read from a closed socket") Ok, I can see how that would be useful in the future even if it happens not to be used in your patch -- forget my previous comment. >I've done a lot of Zope, twisted and Qt development lately. I prefer camel >case but you are right. The Python core has to follow PEP 8. What do you >think about _isreadable(), _iswritable(), _isseekable()? _is*** names sound like predicate. I think your original names in lowercase would be great: _checkreadable, _checkwritable; or with an extra underscore: _check_readable, _check_writable. Based on my previous comment: >Also, shouldn't use the internal methods on parameters other than self: >- assert raw.seekable() >+ raw._checkSeekable() ...perhaps _checkreadable, etc should be functions? ---------------------------------------------------------------------- Comment By: Christian Heimes (tiran) Date: 2007-08-19 13:47 Message: Logged In: YES user_id=560817 Originator: YES I've added the message parameter for the case that we have to use a different error message. For example: self._checkReadable("Can't read from a closed socket") I've done a lot of Zope, twisted and Qt development lately. I prefer camel case but you are right. The Python core has to follow PEP 8. What do you think about _isreadable(), _iswritable(), _isseekable()? ---------------------------------------------------------------------- Comment By: Tony Lownds (tonylownds) Date: 2007-08-18 17:41 Message: Logged In: YES user_id=24100 Originator: NO Your English is fine :) The _checkSeekable etc methods are a good idea. But the message parameter is not used, so why have it? They should be lowercase names to match PEP 8. Also, shouldn't use the internal methods on parameters other than self: - assert raw.seekable() + raw._checkSeekable() I'm not sure it's a good idea to do the first todo without the second here: -XXX need to default buffer size to 1 if isatty() XXX need to support 1 meaning line-buffered ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1771364&group_id=5470 From noreply at sourceforge.net Mon Aug 20 21:04:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Aug 2007 12:04:30 -0700 Subject: [Patches] [ python-Patches-1771364 ] Misc improvements for the io module Message-ID: Patches item #1771364, was opened at 2007-08-10 03:43 Message generated for change (Comment added) made by tiran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1771364&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Guido van Rossum (gvanrossum) Summary: Misc improvements for the io module Initial Comment: My patch fixes small parts of the io module: * replaced all asserts with appropriate TypeError() or ValueError() exceptions * default to buffering = 1 when raw is a tty * added four methods _checkSeekable(msg=None), _checkReadable, _checkWritable and _checkClosed as convenient methods to raise exceptions when a file is closed or not read, write or seekable. * added a unit test to check __all__ * SocketIO.readable/writeable checks for self.closed, too * SocketIO.readinto/write checks for readable, writeable and closed status __all__ references SocketIO but it is not available in io.py. The definition is in socket.py and it doesn't use any socket related code directly. What do you think about moving SocketIO to io.py in the sake of keeping everything together? NOTE: You may want to check my English in the exception messages. ;) ---------------------------------------------------------------------- >Comment By: Christian Heimes (tiran) Date: 2007-08-20 21:04 Message: Logged In: YES user_id=560817 Originator: YES OK, I'm going to provide a new patch with _checkreadable(self, msg) etc. tomorrow. I like to keep them methods for convenient reasons. What about the SocketIO? Do you want to keep it in socket.py? ---------------------------------------------------------------------- Comment By: Tony Lownds (tonylownds) Date: 2007-08-19 18:49 Message: Logged In: YES user_id=24100 Originator: NO >I've added the message parameter for the case that we have to use a >different error message. For example: >self._checkReadable("Can't read from a closed socket") Ok, I can see how that would be useful in the future even if it happens not to be used in your patch -- forget my previous comment. >I've done a lot of Zope, twisted and Qt development lately. I prefer camel >case but you are right. The Python core has to follow PEP 8. What do you >think about _isreadable(), _iswritable(), _isseekable()? _is*** names sound like predicate. I think your original names in lowercase would be great: _checkreadable, _checkwritable; or with an extra underscore: _check_readable, _check_writable. Based on my previous comment: >Also, shouldn't use the internal methods on parameters other than self: >- assert raw.seekable() >+ raw._checkSeekable() ...perhaps _checkreadable, etc should be functions? ---------------------------------------------------------------------- Comment By: Christian Heimes (tiran) Date: 2007-08-19 15:47 Message: Logged In: YES user_id=560817 Originator: YES I've added the message parameter for the case that we have to use a different error message. For example: self._checkReadable("Can't read from a closed socket") I've done a lot of Zope, twisted and Qt development lately. I prefer camel case but you are right. The Python core has to follow PEP 8. What do you think about _isreadable(), _iswritable(), _isseekable()? ---------------------------------------------------------------------- Comment By: Tony Lownds (tonylownds) Date: 2007-08-18 19:41 Message: Logged In: YES user_id=24100 Originator: NO Your English is fine :) The _checkSeekable etc methods are a good idea. But the message parameter is not used, so why have it? They should be lowercase names to match PEP 8. Also, shouldn't use the internal methods on parameters other than self: - assert raw.seekable() + raw._checkSeekable() I'm not sure it's a good idea to do the first todo without the second here: -XXX need to default buffer size to 1 if isatty() XXX need to support 1 meaning line-buffered ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1771364&group_id=5470 From noreply at sourceforge.net Tue Aug 21 03:06:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Aug 2007 18:06:17 -0700 Subject: [Patches] [ python-Patches-1761786 ] distutils.util.get_platform() return value on 64bit Windows Message-ID: Patches item #1761786, was opened at 2007-07-27 16:11 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1761786&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: Distutils and setup.py Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: distutils.util.get_platform() return value on 64bit Windows Initial Comment: As discussed recently on distutils-sig (http://mail.python.org/pipermail/distutils-sig/2007-July/007877.html), it is desirable for get_platform() to return different values for different Windows architectures, to easily differentiate the files and directories created. This patch arranges for either 'win-x86_64' or 'win-ia64' to be returned for the 2 64bit Windows platforms; all other platforms, including 32bit windows, are unchanged. Patch also includes a change to bdist_msi so get_platform() is used instead of 'win32' to create the final .msi. Note that get_platform() *is* already used for the name of the 'build' directories, so this hard-coding of win32 doesn't appear intentional. No similar patch exists for bdist_wininst, as there is no intention to support x64 with bdist_wininst. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2007-08-21 11:06 Message: Logged In: YES user_id=14198 Originator: YES pilot error caused this to require 2 checkins: util.py, revision 57229. command\bdist_msi.py, 57230. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1761786&group_id=5470 From noreply at sourceforge.net Tue Aug 21 03:11:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Aug 2007 18:11:34 -0700 Subject: [Patches] [ python-Patches-983164 ] MSVC6/7 issues with bdist_wininst and --target-version Message-ID: Patches item #983164, was opened at 2004-07-01 13:26 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983164&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: Distutils and setup.py Group: Python 2.4 >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: MSVC6/7 issues with bdist_wininst and --target-version Initial Comment: bdist_wininst attempts to use the correct MSVC runtime for the current version of Python. This doesn't work correctly when --target-version is set. In that case, bdist_wininst still uses the *current* sys.version (ie, 2.4) rather than the version specified as --target-version. Thus, the msvc7 runtime based executable stub is *always* used. This patch "hard-codes" knowledge of earlier Python versions, providing the correct result when Python 2.4 is used to build Python 2.3 and earlier distributions. As the comments in the patch mention, another alternative is to allow --target-version to specify a Python executable instead of a simple version string, and execute that Python to parse its sys.version. Let me know if you think that is a good/better idea. Assigning to Thomas for review, then please assign back. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2007-08-21 11:11 Message: Logged In: YES user_id=14198 Originator: YES Was open, but marked as "Fixed" - closing. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-12 22:10 Message: Logged In: YES user_id=11105 Hm, it's not as cool as I thought - you only get the new distutils features from the bdist_wininst command, not from other commands. For example, the new 'package_data' option doesn't work for target-version 2.3, since the build tree is still created with the 2.3 distutils. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-07-10 23:47 Message: Logged In: YES user_id=14198 The point is to use a *new* distutils with an old Python version - ie, I want to use the latest distutils features to build a Python 1.5.2 distribution. OK, maybe not 1.5.2 anymore ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-10 21:36 Message: Logged In: YES user_id=21627 I'd like to mention that --target-version isn't really needed, IMO: it is relatively easy to just use the old Python executable to run setup.py, and it will automatically use the old distutils. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-07 05:23 Message: Logged In: YES user_id=11105 Ah, now I understand. I didn't even know that it was possible to use --target-version and --skip-build to build installers for other Python versions, but this is definitely cool. I checked in your patch to make sure it gets into 2.4a1. Your idea to specify an executable makes sense, but imo only when 2.4 is an old version, isn't it? Feel free to provide an additional patch for that, but I think one should still be able to use '2.3' as argument for the --target-version switch. BTW: The short variant of the --target-version switch (-v) conflicts with the --verbose option and doesn't work, so I'm taking this out as well. Checked in as bdist_wininst.py rev 1.49. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-07-02 09:19 Message: Logged In: YES user_id=14198 I'm not exactly sure what you are saying. The current version of bdist_wininst allows you to specify --target-version and --skip-build, thereby allowing this to target *any* version of Python. If target_version != sys.version, the package has extensions and --skip-build is not specified, an error is thrown. So, I *build* the extensions using the "native" version of Python, but want to *package* the installer using CVS trunk disutils. This last step has --skip-build specified, and works fine. So I can't see the problem you allude to. Further, it works just fine with my patch using Python 2.4 to package up my 2.3/2.2 based installers. Unfortunately, I'm not even sure if you are saying Python 2.4 distutils should be able to package 2.3/2.2 based packages. My idea of specifying the executable would be an option. My suggestion is that this would be used simply so Python could extract the sys.version for that version, and parse the C compiler used as it does now for the current version. It would simply allow disutils to extract more information about the target version than "x.y", and may allow us to better support non MS compilers (as a comment in the existing code mentions). Of course, if they are building without that target version available, then they can stick to supplying just the target version number, as now. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-02 05:59 Message: Logged In: YES user_id=11105 Maybe bdist_wininst must be changed to (hard-coded) only accept 2.4 and higher when 2.4 is used to build the installer, and only accept 2.3 and lower otherwise? For the other idea (building the installer on the target system): we could run 'setup.py build_ext' on the source system, maybe repeat this for different Python versions if available, zip up the source and build tree (including compiled extensions), and then run 'setup.py bdist_wininst' on the target system, and then execute the exe? This would also allow to have cross version support, including extensions, in one installer file. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-02 05:39 Message: Logged In: YES user_id=11105 The situation is even worse. --target-version is only available for pure-Python distributions which don't have extension modules, if you want to restrict the installer to only one version of Python, for whatever reason. I could never think of a reason, but now there is one: different MSVC runtimes used in the target Python. Running a Python executable to determine the MSVC runtime does not work: First, usually you build installers for other users, second, some people build windows installers on non-windows systems. I have no idea how this can be solved, except of a very old one of mine: build and execute the installer on the target system ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983164&group_id=5470 From noreply at sourceforge.net Tue Aug 21 11:14:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Aug 2007 02:14:46 -0700 Subject: [Patches] [ python-Patches-1778410 ] removeTest() method patch for unittest.TestSuite Message-ID: Patches item #1778410, was opened at 2007-08-21 04:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1778410&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 Private: No Submitted By: Mark Edgington (edgimar) Assigned to: Nobody/Anonymous (nobody) Summary: removeTest() method patch for unittest.TestSuite Initial Comment: This is a simple patch to add a "removeTest" method to the unittest.TestSuite object. It is called in exactly the same way the "addTest" method is called, except that it removes the provided TestCase from the suite. This is useful if you want to add a bunch of unittests via TestLoader().loadTestsFromModule(), EXCEPT for a few specific cases, which you would like to subsequently remove. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1778410&group_id=5470 From noreply at sourceforge.net Tue Aug 21 11:57:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Aug 2007 02:57:02 -0700 Subject: [Patches] [ python-Patches-1778443 ] robotparser.py fixes Message-ID: Patches item #1778443, was opened at 2007-08-21 12: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=1778443&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 Private: No Submitted By: Indy (indy90) Assigned to: Nobody/Anonymous (nobody) Summary: robotparser.py fixes Initial Comment: Some performance and readability fixes to robotparser.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1778443&group_id=5470 From noreply at sourceforge.net Tue Aug 21 20:29:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Aug 2007 11:29:41 -0700 Subject: [Patches] [ python-Patches-1774828 ] Override flags set by IOBase in io.StringIO Message-ID: Patches item #1774828, was opened at 2007-08-15 12:13 Message generated for change (Comment added) made by avassalotti You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1774828&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 3000 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Alexandre Vassalotti (avassalotti) Assigned to: Nobody/Anonymous (nobody) Summary: Override flags set by IOBase in io.StringIO Initial Comment: This patch fixes a small bug in the flags of io.StringIO: >>> import io >>> s = io.StringIO() >>> s.writable() False >>> s.seekable() False >>> s.readable() False All the flags should have the value True. ---------------------------------------------------------------------- >Comment By: Alexandre Vassalotti (avassalotti) Date: 2007-08-21 14:29 Message: Logged In: YES user_id=1826340 Originator: YES In my alex-py3k branch, I committed, in r57263, a better fix. Closing. ---------------------------------------------------------------------- Comment By: Alexandre Vassalotti (avassalotti) Date: 2007-08-15 12:28 Message: Logged In: YES user_id=1826340 Originator: YES This should probably be fixed in TextIOWrapper too: >>> f = open("+spam", "w") >>> f.writable() False ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1774828&group_id=5470 From noreply at sourceforge.net Tue Aug 21 20:32:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Aug 2007 11:32:16 -0700 Subject: [Patches] [ python-Patches-1774833 ] Convert str to bytes in io.BytesIO.__init__ Message-ID: Patches item #1774833, was opened at 2007-08-15 12:23 Message generated for change (Comment added) made by avassalotti You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1774833&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 3000 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Alexandre Vassalotti (avassalotti) Assigned to: Nobody/Anonymous (nobody) Summary: Convert str to bytes in io.BytesIO.__init__ Initial Comment: This patch allows a str object to be used as the initial value of io.BytesIO: >>> x = io.BytesIO('1234') Traceback (most recent call last): File "", line 1, in File "/home/alex/src/python.org/py3k/Lib/io.py", line 592, in __init__ buffer += initial_bytes TypeError: can't concat bytes to str ---------------------------------------------------------------------- >Comment By: Alexandre Vassalotti (avassalotti) Date: 2007-08-21 14:32 Message: Logged In: YES user_id=1826340 Originator: YES Committed in r57263 in the alex-py3k branch, along with other fixes. Closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1774833&group_id=5470 From noreply at sourceforge.net Tue Aug 21 21:23:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Aug 2007 12:23:38 -0700 Subject: [Patches] [ python-Patches-1731036 ] BufReader, TextReader for PEP 3116 "New I/O" Message-ID: Patches item #1731036, was opened at 2007-06-04 17:52 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731036&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: None Priority: 5 Private: No Submitted By: Ilguiz Latypov (ilgiz) Assigned to: Guido van Rossum (gvanrossum) Summary: BufReader, TextReader for PEP 3116 "New I/O" Initial Comment: Here is a simple implementation of a line-oriented reader deriving from a buffered reader. Unlike the suggested extra derivation of buffered I/O class from a raw I/O class, my BufReader only wraps an "iterable" stream. Besides, I found I had to return an empty string instead of None on EOF because Python2.5's codecs.py assumes the former. Submitting this just in case it is found useful. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-21 15:23 Message: Logged In: YES user_id=6380 Originator: NO Thanks, this has been superseded by the curernt implementation of io.py. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-04 21:44 Message: Logged In: YES user_id=33168 Originator: NO Guido, this might be of interest if you are working on new i/o again. I haven't reviewed it. ---------------------------------------------------------------------- Comment By: Ilguiz Latypov (ilgiz) Date: 2007-06-04 17:57 Message: Logged In: YES user_id=281701 Originator: YES (I did not take into account the suggested newline and codec parameters, either). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731036&group_id=5470 From noreply at sourceforge.net Tue Aug 21 21:24:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Aug 2007 12:24:07 -0700 Subject: [Patches] [ python-Patches-1775604 ] utf-32 codecs Message-ID: Patches item #1775604, was opened at 2007-08-16 12:56 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1775604&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 3000 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Walter D?rwald (doerwalter) >Assigned to: Walter D?rwald (doerwalter) Summary: utf-32 codecs Initial Comment: This patch adds three new codecs: utf-32, utf-32-le and utf-32-be. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-21 15:24 Message: Logged In: YES user_id=6380 Originator: NO This was submitted already. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1775604&group_id=5470 From noreply at sourceforge.net Wed Aug 22 00:09:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Aug 2007 15:09:17 -0700 Subject: [Patches] [ python-Patches-1776581 ] Minor corrections to smtplib Message-ID: Patches item #1776581, was opened at 2007-08-17 15:52 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1776581&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alan McIntyre (alanmcintyre) Assigned to: Facundo Batista (facundobatista) Summary: Minor corrections to smtplib Initial Comment: Two minor changes: - In SMTP.send, there is a check for self.sock, which may not exist if there has been no attempt to connect. This patch adds a check for hasattr(self, 'sock') so that such an attempt to call send() will raise the more helpful SMTPServerDisconnected instead of an AttributeError. - The docstring for SMTP.expn is a copy of that of the verify method. This patch changes it to something more appropriate. ---------------------------------------------------------------------- >Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-21 17:09 Message: Logged In: YES user_id=1115903 Originator: YES The attached file smtplib-misc-fixes-2.diff includes a change to make test_smtplib.GeneralTests.testNotConnected pass when the original change for this patch is made. File Added: smtplib-misc-fixes-2.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1776581&group_id=5470 From noreply at sourceforge.net Wed Aug 22 18:14:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Aug 2007 09:14:37 -0700 Subject: [Patches] [ python-Patches-1779550 ] Remove redundancies inside class logging.Logger Message-ID: Patches item #1779550, was opened at 2007-08-22 18:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1779550&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 Private: No Submitted By: Carsten Grohmann (cgrohmann) Assigned to: Nobody/Anonymous (nobody) Summary: Remove redundancies inside class logging.Logger Initial Comment: The attached patch removes some pieces of redundant code inside the Logger class and unifies the calls of debug(), info(), warning(), error(), critical() as well as log(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1779550&group_id=5470 From noreply at sourceforge.net Wed Aug 22 20:26:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Aug 2007 11:26:05 -0700 Subject: [Patches] [ python-Patches-1779613 ] Replace AtheOS w/ Syllable Message-ID: Patches item #1779613, was opened at 2007-08-22 13: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=1779613&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Replace AtheOS w/ Syllable Initial Comment: AtheOS appears to have croaked several years ago. While checking to see if it was still alive I came across Syllable (www.syllable.org). The Syllable folks would still like to support Python. One of the developers cooked up a patch against Python 2.5.1 which mostly replaces "atheos" with "syllable", though it appears to do a bit more than that. I applied the patch against the trunk and fixed a couple rejects. That patch is attached. Note that at this point the Syllable patch is missing a thread_syllable.h file. I have a request in to get ahold of that. Until that arrives this is on hold. Skip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1779613&group_id=5470 From noreply at sourceforge.net Wed Aug 22 21:48:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Aug 2007 12:48:34 -0700 Subject: [Patches] [ python-Patches-1774414 ] Make it possible to use SVK to develop Python Message-ID: Patches item #1774414, was opened at 2007-08-14 21:00 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1774414&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 3000 >Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Collin Winter (collinwinter) Summary: Make it possible to use SVK to develop Python Initial Comment: I want to use SVK instead of SVN when developing Python on my laptop. Currently, the parsing of HEADURL in Python/sysmodule.c:svnversion_init() kills the interpreter at start-up because the HEADURL for SVK looks like /py3k/local/Python/sysmodule.c. The attached patch causes svnversion_init() to use "unknown" for the branch name instead of raising a fatal error when it encounters a mis-formatted HEADURL. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-08-22 15:48 Message: Logged In: YES user_id=1344176 Originator: YES Committed as r57283. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-16 01:57 Message: Logged In: YES user_id=33168 Originator: NO This is fine. Note the indentation is screwed up. It looks like some mixing of tabs and spaces. It would be good to add a comment near the copying of "unknown" to mention about supporting svk and possibly other SCM systems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1774414&group_id=5470 From noreply at sourceforge.net Thu Aug 23 02:02:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Aug 2007 17:02:35 -0700 Subject: [Patches] [ python-Patches-1779871 ] Make python build with gcc-4.2 on OS X 10.4.9 Message-ID: Patches item #1779871, was opened at 2007-08-23 00:02 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=1779871&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jeffrey Yasskin (jyasskin) Assigned to: Nobody/Anonymous (nobody) Summary: Make python build with gcc-4.2 on OS X 10.4.9 Initial Comment: I tested the change with Apple's gcc and gcc-4.2, but only on an Intel mac. http://gcc.gnu.org/ml/gcc/2005-12/msg00368.html says that -no-cpp-precomp is obsolete, and there weren't any warnings about long doubles, so I just removed those two, and because I'm paranoid, I added a test compile for -mno-fused-madd. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1779871&group_id=5470 From noreply at sourceforge.net Thu Aug 23 06:15:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Aug 2007 21:15:20 -0700 Subject: [Patches] [ python-Patches-1779871 ] Make python build with gcc-4.2 on OS X 10.4.9 Message-ID: Patches item #1779871, was opened at 2007-08-23 00:02 Message generated for change (Comment added) made by marketdickinson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1779871&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jeffrey Yasskin (jyasskin) Assigned to: Nobody/Anonymous (nobody) Summary: Make python build with gcc-4.2 on OS X 10.4.9 Initial Comment: I tested the change with Apple's gcc and gcc-4.2, but only on an Intel mac. http://gcc.gnu.org/ml/gcc/2005-12/msg00368.html says that -no-cpp-precomp is obsolete, and there weren't any warnings about long doubles, so I just removed those two, and because I'm paranoid, I added a test compile for -mno-fused-madd. ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-08-23 04:15 Message: Logged In: YES user_id=703403 Originator: NO Also works for me on a PowerPC mac (OS X 10.4.10/G4), with gcc4.2 from macports: compiles successfully and all tests pass. This should fix bug 1450807. What happens with earlier versions of OS X? It looks as though the -Wno-long-double flag was added just to suppress warnings, so nothing dire should happen if it's removed. Might the -no-cpp-precomp still be required for 10.2 or earlier? Would it make sense to remove these two flags only for 10.3 and above, or only when using non Apple-supplied gcc? Or to test for existence of the -no-cpp-precomp flag? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1779871&group_id=5470