From report at bugs.python.org Sat Sep 1 00:27:20 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 31 Aug 2012 22:27:20 +0000 Subject: [issue15834] 2to3 benchmark not working under Python 3 Message-ID: <1346452040.3.0.632075344934.issue15834@psf.upfronthosting.co.za> New submission from Brett Cannon: 2to3 isn't (ironically) translating lib2to3 so that it can run under Python 3: File "/Users/bcannon/Developer/repo/benchmarks_py3k/lib/2to3/lib2to3/fixes/fix_operator.py", line 89, in _check_method method = getattr(self, "_" + results["method"][0].value.encode("ascii")) Might need to let Python 3 use its stdlib copy of lib2to3. Otherwise will need to come up with a way to have two copies of a library, one for Python 2 and another for Python 3, and then copy the right thing. Maybe a lib3 directory that is only copied over by make_perf3.sh? ---------- assignee: collinwinter components: Benchmarks messages: 169587 nosy: brett.cannon, collinwinter, pitrou priority: normal severity: normal stage: needs patch status: open title: 2to3 benchmark not working under Python 3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 00:40:04 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 31 Aug 2012 22:40:04 +0000 Subject: [issue15833] most failures to write byte-compiled file no longer suppressed In-Reply-To: <1346432246.49.0.876284426658.issue15833@psf.upfronthosting.co.za> Message-ID: <1346452804.97.0.053836600122.issue15833@psf.upfronthosting.co.za> Brett Cannon added the comment: So it might be a change, but I don't know if I would claim it is a regression that needs changing. If you can't write bytecode files for some reason other than permissions or the file already exists then there is something wrong with your setup that you might not be expecting. I don't know what this EIO error code is, but it sounds non-standard for the situation and thus not something we should blindly be ignoring. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 00:42:25 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 31 Aug 2012 22:42:25 +0000 Subject: [issue15834] 2to3 benchmark not working under Python 3 In-Reply-To: <1346452040.3.0.632075344934.issue15834@psf.upfronthosting.co.za> Message-ID: <1346452728.3436.8.camel@localhost.localdomain> Antoine Pitrou added the comment: > Might need to let Python 3 use its stdlib copy of lib2to3. Otherwise > will need to come up with a way to have two copies of a library, one > for Python 2 and another for Python 3, and then copy the right thing. > Maybe a lib3 directory that is only copied over by make_perf3.sh? Sounds like a good idea. Even better if you can find a 3.x copy of lib2to3 which is close the 2.x one :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 01:16:05 2012 From: report at bugs.python.org (Trent Nelson) Date: Fri, 31 Aug 2012 23:16:05 +0000 Subject: [issue15748] Various symlink test failures in test_shutil on FreeBSD In-Reply-To: <1345516038.44.0.114148239105.issue15748@psf.upfronthosting.co.za> Message-ID: <1346454965.49.0.178404805118.issue15748@psf.upfronthosting.co.za> Trent Nelson added the comment: Turns out our unit test uncovered a very subtle corner-case bug in ZFS, requiring the following patch to FreeBSD: a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sa.c b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sa.c index 69374fb..7f61517 100644 --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sa.c +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sa.c @@ -1695,6 +1695,7 @@ sa_modify_attrs(sa_handle_t *hdl, sa_attr_type_t newattr, ASSERT(action == SA_REPLACE); SA_ADD_BULK_ATTR(attr_desc, j, attr, locator, datastart, buflen); + length_idx++; } else { length = SA_REGISTERED_LEN(sa, attr); if (length == 0) { I guess the unit test should probably be patched to to skip the test IFF the underlying filesystem is ZFS and it exhibits the "length 24" problem. (Actually, detecting if the underlying filesystem is ZFS is non-trivial -- just testing for the "length 24" bug is probably sufficient.) I'll look into this later. (According to Andriy Gapon (FreeBSD developer that came up with the patch), the bug is likely to affect all ZFS implementations since the beginning of time.) ---------- resolution: -> postponed stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 01:20:05 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 31 Aug 2012 23:20:05 +0000 Subject: [issue15834] 2to3 benchmark not working under Python 3 In-Reply-To: <1346452728.3436.8.camel@localhost.localdomain> Message-ID: Brett Cannon added the comment: On Fri, Aug 31, 2012 at 6:42 PM, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > > Might need to let Python 3 use its stdlib copy of lib2to3. Otherwise > > will need to come up with a way to have two copies of a library, one > > for Python 2 and another for Python 3, and then copy the right thing. > > Maybe a lib3 directory that is only copied over by make_perf3.sh? > > Sounds like a good idea. > Even better if you can find a 3.x copy of lib2to3 which is close the 2.x > one :-) > I think short of copying the stdlib versions from Python 2.7 and 3.2 I don't think there is much choice short of doing a 2to3+fixes translation ourselves just to have a version that is as close to the same as possible. But looking at the stdlib versions they are practically the same already except that one uses StringIO and the other uses io.StringIO (and Python 3 doesn't need the encode() call that triggered this whole discussion). I don't remember if StringIO or io.StringIO is faster in Python 2.6 and 2.7, but based on that we can either leave it as-is or tweak it to use the other just for benchmarking to make it even. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 01:23:50 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 31 Aug 2012 23:23:50 +0000 Subject: [issue15748] Various symlink test failures in test_shutil on FreeBSD In-Reply-To: <1345516038.44.0.114148239105.issue15748@psf.upfronthosting.co.za> Message-ID: <1346455430.81.0.606932126367.issue15748@psf.upfronthosting.co.za> Larry Hastings added the comment: Could we work around it? Ignore the length we get back from readlink() and just measure the buffer ourselves? Or, if we wanted to be *really* paranoid, write a \0 at the length they give us back and *then* strlen it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 01:52:33 2012 From: report at bugs.python.org (Trent Nelson) Date: Fri, 31 Aug 2012 23:52:33 +0000 Subject: [issue15835] HP-UX build needs to be tweaked to pick up PATH_MAX Message-ID: <1346457153.04.0.0294174797728.issue15835@psf.upfronthosting.co.za> New submission from Trent Nelson: Building on HP-UX with the HP ANSI C compiler: % make cc -Ae -c -O -O -I. -I./Include -DPy_BUILD_CORE -o Python/pythonrun.o Python/pythonrun.c "Python/pythonrun.c", line 805: error #2020: identifier "PATH_MAX" is undefined static wchar_t env_home[PATH_MAX+1]; ^ 1 error detected in the compilation of "Python/pythonrun.c". *** Error exit code 2 Stop. Placeholder bug whilst I do some more digging. ---------- assignee: trent messages: 169593 nosy: trent priority: normal severity: normal status: open title: HP-UX build needs to be tweaked to pick up PATH_MAX type: compile error versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 01:58:55 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 31 Aug 2012 23:58:55 +0000 Subject: [issue15833] most failures to write byte-compiled file no longer suppressed In-Reply-To: <1346432246.49.0.876284426658.issue15833@psf.upfronthosting.co.za> Message-ID: <1346457535.25.0.465470511314.issue15833@psf.upfronthosting.co.za> Eric Snow added the comment: I was thinking along the same lines, though it might make sense for EROFS and a few others. (http://aplawrence.com/Unixart/errors.html) ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 02:03:14 2012 From: report at bugs.python.org (Trent Nelson) Date: Sat, 01 Sep 2012 00:03:14 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346309362.14.0.312540957077.issue15819@psf.upfronthosting.co.za> Message-ID: <1346457794.6.0.454146360174.issue15819@psf.upfronthosting.co.za> Trent Nelson added the comment: > Since the committed patch is already a step in that direction, > I think it now needs to be completed. It's mandatory (IMO) > that the generated files are actually used; that the generators > are not run if not needed is optional and can be fixed later. Martin: I'll work on another patch over the next few days and post it here for review. It seems like your comments regarding our options are still valid (despite this thread getting sidetracked): continue with the premise that all generated files get generated in the build directory, and make sure that build directory gets used during the build (i.e. -I./Include). I'll start with that and see how I get on. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 02:06:55 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 01 Sep 2012 00:06:55 +0000 Subject: [issue15535] Fix pickling of named tuples in 2.7.3 (BUG) In-Reply-To: <1343915086.31.0.252328658724.issue15535@psf.upfronthosting.co.za> Message-ID: <1346458015.0.0.421856074847.issue15535@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 02:26:01 2012 From: report at bugs.python.org (Daniel Wagner-Hall) Date: Sat, 01 Sep 2012 00:26:01 +0000 Subject: [issue15836] unittest assertRaises should verify excClass is actually a BaseException class Message-ID: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za> New submission from Daniel Wagner-Hall: The following code in a unittest test is a no-op: self.assertRaises(lambda: 1) I would expect this to fail the test, because I naively assumed omitting the exception class would act as: self.assertRaises(BaseException, lambda: 1) verifying that *any* Exception is raised. I believe the correct behaviour is to raise a TypeError if excClass is not a BaseException-derived type, similar to if a non-type is passed as the first arg to issubclass. Attached is a patch to do so. It also removes a no-op self.assertRaises from libimport's tests (because it started failing when I ran the tests with the patch). That assertion is redundant, because the two lines above perform the assertion being attempted. ---------- components: Tests files: assertRaises.patch keywords: patch messages: 169596 nosy: illicitonion priority: normal severity: normal status: open title: unittest assertRaises should verify excClass is actually a BaseException class type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file27079/assertRaises.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 02:29:20 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 01 Sep 2012 00:29:20 +0000 Subject: [issue15535] Fix pickling efficiency of named tuples in 2.7.3 In-Reply-To: <1343915086.31.0.252328658724.issue15535@psf.upfronthosting.co.za> Message-ID: <1346459360.34.0.487547307324.issue15535@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, all pickle protocol levels are affected: Point = colletions.namedtuple('Point', ['x', 'y', 'z']) for proto in range(3): pickletools.dis(dumps(Point(10, 20, 30), proto)) I'll look at the proposed fix in more detail when I get a chance -- we want to make sure that subclasses aren't adversely affected and that there aren't any other unintended side-effects. ---------- title: Fix pickling of named tuples in 2.7.3 (BUG) -> Fix pickling efficiency of named tuples in 2.7.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 02:40:29 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 01 Sep 2012 00:40:29 +0000 Subject: [issue15836] unittest assertRaises should verify excClass is actually a BaseException class In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za> Message-ID: <1346460029.46.0.30984569959.issue15836@psf.upfronthosting.co.za> R. David Murray added the comment: Sounds like a reasonable suggestion. However, the patch is not valid for 2.7, since there exceptions can be old style classes. ---------- nosy: +r.david.murray stage: -> patch review versions: -Python 2.6, Python 2.7, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 02:50:13 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 01 Sep 2012 00:50:13 +0000 Subject: [issue15780] IDLE (windows) with PYTHONPATH and multiple python versions In-Reply-To: <1345841085.37.0.939660475067.issue15780@psf.upfronthosting.co.za> Message-ID: <1346460613.33.0.853118645998.issue15780@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 02:56:15 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 01 Sep 2012 00:56:15 +0000 Subject: [issue15786] IDLE code completion window does not scoll/select with mouse In-Reply-To: <1346027701.33.0.908436854594.issue15786@psf.upfronthosting.co.za> Message-ID: <1346460975.86.0.40007862479.issue15786@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +serwy, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 03:01:49 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 01 Sep 2012 01:01:49 +0000 Subject: [issue15836] unittest assertRaises should verify excClass is actually a BaseException class In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za> Message-ID: <1346461309.73.0.887169122069.issue15836@psf.upfronthosting.co.za> R. David Murray added the comment: I put some review comments in rietveld (you should have gotten an email). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 03:23:22 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 01 Sep 2012 01:23:22 +0000 Subject: [issue15820] Add additional info to Resources area on Dev Guide In-Reply-To: <1346312741.02.0.319894267547.issue15820@psf.upfronthosting.co.za> Message-ID: <1346462602.95.0.723404810299.issue15820@psf.upfronthosting.co.za> R. David Murray added the comment: Is the :exc:`KeyboardInterrupt` line supposed to be in there? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 03:23:57 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 01 Sep 2012 01:23:57 +0000 Subject: [issue15809] IDLE console uses incorrect encoding. In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za> Message-ID: <1346462637.06.0.583622579135.issue15809@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 03:35:35 2012 From: report at bugs.python.org (Daniel Wagner-Hall) Date: Sat, 01 Sep 2012 01:35:35 +0000 Subject: [issue15836] unittest assertRaises should verify excClass is actually a BaseException class In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za> Message-ID: <1346463335.79.0.739488694013.issue15836@psf.upfronthosting.co.za> Daniel Wagner-Hall added the comment: I seem to be getting exceptions why trying to upload a new patch to rietveld, either by the web interface (in several browsers), or by upload.py - attaching new patchset here Also, if I wanted to backport to 2.7 including an isinstance(e, types.ClassType) check, how would I go about doing so? Thanks for the quick review! ---------- Added file: http://bugs.python.org/file27080/assertRaises.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 03:39:12 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 01 Sep 2012 01:39:12 +0000 Subject: [issue15826] Increased test coverage of test_glob.py In-Reply-To: <1346381534.69.0.636623200483.issue15826@psf.upfronthosting.co.za> Message-ID: <1346463552.02.0.200940887965.issue15826@psf.upfronthosting.co.za> R. David Murray added the comment: Is test_bytes_glob_directory_with_trailing_slash unique to bytes, or should it be added to the base class instead? What would be useful as bytes-only tests, I think, would be tests of non-ascii stuff. Although that makes me wonder, do we test non-ascii unicode in the string tests? I presume that ought to be tested, too, though I suppose that could be tricky if the default encoding of the system the tests are running on can't handle the selected characters (such as, if it is ASCII). Both of those are extras, though, the main question before committing this patch is the first one. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 04:06:19 2012 From: report at bugs.python.org (Alessandro Moura) Date: Sat, 01 Sep 2012 02:06:19 +0000 Subject: [issue15837] Added test to test_random.py testing Random.shuffle Message-ID: <1346465179.1.0.118516816378.issue15837@psf.upfronthosting.co.za> New submission from Alessandro Moura: Random.shuffle does not have a test in test_random.py; the attached patch adds this test. In addition, I rewrote the documentation string for Random.shuffle, which apparently did not reflect recent changes in the code and was inconsistent with the definition of the method. This change is also part of this patch; I was not sure if this merited a separate issue, so I just included this here. On a related matter: in Random.shuffle there is a third optional argument which looks very odd to me: def shuffle(self, x, random=None, int=int): .... Besides being confusing to a user typing help(shuffle), what the "int" argument does in shuffle is to convert a float to an integer. But one could pass any one-argument function in principle, and it would be then very hard to predict what shuffle would do... it would not "shuffle" any more in the traditional sense - not with a uniform probability distribution. In summary, I don't see how that argument could be useful, although the people who wrote the library must have had something in mind... if so it would be a good idea to document it. ---------- components: Tests messages: 169603 nosy: eng793 priority: normal severity: normal status: open title: Added test to test_random.py testing Random.shuffle type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 04:08:13 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 01 Sep 2012 02:08:13 +0000 Subject: [issue15836] unittest assertRaises should verify excClass is actually a BaseException class In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za> Message-ID: <1346465293.05.0.599341512066.issue15836@psf.upfronthosting.co.za> R. David Murray added the comment: Uploading the new patch here is the correct procedure. It will automatically be uploaded to rietveld as well. If by "how" you mean how to submit a backport, just create a patch against 2.7 tip and upload it separately. Revised patch looks good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 04:08:24 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 01 Sep 2012 02:08:24 +0000 Subject: [issue15836] unittest assertRaises should verify excClass is actually a BaseException class In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za> Message-ID: <1346465303.99.0.343565332587.issue15836@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +michael.foord _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 04:16:14 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 01 Sep 2012 02:16:14 +0000 Subject: [issue15837] Added test to test_random.py testing Random.shuffle In-Reply-To: <1346465179.1.0.118516816378.issue15837@psf.upfronthosting.co.za> Message-ID: <1346465774.79.0.666795647942.issue15837@psf.upfronthosting.co.za> R. David Murray added the comment: The patch seems to be missing. The int=int is probably some sort of micro-optimization and perhaps should be removed. ---------- nosy: +r.david.murray, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 04:39:14 2012 From: report at bugs.python.org (Daniel Wagner-Hall) Date: Sat, 01 Sep 2012 02:39:14 +0000 Subject: [issue15836] unittest assertRaises should verify excClass is actually a BaseException class In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za> Message-ID: <1346467154.86.0.00937527924828.issue15836@psf.upfronthosting.co.za> Daniel Wagner-Hall added the comment: Added patch for 2.7. I'll sign the contributor form just as soon as I can get to a printer. Thanks for taking me through my first contribution. ---------- versions: +Python 2.7 Added file: http://bugs.python.org/file27081/issue15836-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 04:42:33 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 01 Sep 2012 02:42:33 +0000 Subject: [issue15836] unittest assertRaises should verify excClass is actually a BaseException class In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za> Message-ID: <1346467353.37.0.821707237675.issue15836@psf.upfronthosting.co.za> R. David Murray added the comment: You are welcome, and thanks for your contribution. ---------- components: +Library (Lib) -Tests _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 05:16:48 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 01 Sep 2012 03:16:48 +0000 Subject: [issue11839] argparse: unexpected behavior of default for FileType('w') In-Reply-To: <1302638190.31.0.523851627026.issue11839@psf.upfronthosting.co.za> Message-ID: <3X82fR4DqPzQTN@mail.python.org> Roundup Robot added the comment: New changeset 1b614921aefa by R David Murray in branch '3.2': #12776,#11839: call argparse type function only once. http://hg.python.org/cpython/rev/1b614921aefa New changeset 74f6d87cd471 by R David Murray in branch 'default': Merge #12776,#11839: call argparse type function only once. http://hg.python.org/cpython/rev/74f6d87cd471 New changeset 62b5667ef2f4 by R David Murray in branch '2.7': #12776,#11839: call argparse type function only once. http://hg.python.org/cpython/rev/62b5667ef2f4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 05:16:48 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 01 Sep 2012 03:16:48 +0000 Subject: [issue12776] argparse: type conversion function should be called only once In-Reply-To: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za> Message-ID: <3X82fQ5rLKzQTW@mail.python.org> Roundup Robot added the comment: New changeset 1b614921aefa by R David Murray in branch '3.2': #12776,#11839: call argparse type function only once. http://hg.python.org/cpython/rev/1b614921aefa New changeset 74f6d87cd471 by R David Murray in branch 'default': Merge #12776,#11839: call argparse type function only once. http://hg.python.org/cpython/rev/74f6d87cd471 New changeset 62b5667ef2f4 by R David Murray in branch '2.7': #12776,#11839: call argparse type function only once. http://hg.python.org/cpython/rev/62b5667ef2f4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 05:18:25 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 01 Sep 2012 03:18:25 +0000 Subject: [issue12776] argparse: type conversion function should be called only once In-Reply-To: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za> Message-ID: <1346469505.3.0.952174991325.issue12776@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Arnaud and Mike. (And Steven, of course :) ---------- nosy: +r.david.murray resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 06:31:52 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 01 Sep 2012 04:31:52 +0000 Subject: [issue13769] json.dump(ensure_ascii=False) return str instead of unicode In-Reply-To: <1326300079.82.0.279410736545.issue13769@psf.upfronthosting.co.za> Message-ID: <3X84K3355hzQNR@mail.python.org> Roundup Robot added the comment: New changeset a1884b3027c5 by Petri Lehtinen in branch '2.7': #13769: Enhance docs for ensure_ascii semantics in JSON decoding functions http://hg.python.org/cpython/rev/a1884b3027c5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 06:32:58 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Sat, 01 Sep 2012 04:32:58 +0000 Subject: [issue13769] json.dump(ensure_ascii=False) return str instead of unicode In-Reply-To: <1326300079.82.0.279410736545.issue13769@psf.upfronthosting.co.za> Message-ID: <1346473978.41.0.734001408202.issue13769@psf.upfronthosting.co.za> Petri Lehtinen added the comment: Fixed, thanks. ---------- keywords: -needs review resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 09:33:42 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 01 Sep 2012 07:33:42 +0000 Subject: [issue15821] PyMemoryView_FromBuffer() behavior change (possible regression) In-Reply-To: <1346320388.88.0.494685067241.issue15821@psf.upfronthosting.co.za> Message-ID: <1346484822.06.0.174708413595.issue15821@psf.upfronthosting.co.za> Stefan Krah added the comment: In general, the number of calls to PyObject_GetBuffer() must be equal to the number of calls to PyBuffer_Release(), otherwise bad things will happen in the same way as with malloc()/free(). Now, in my test case I omitted the call to PyObject_GetBuffer() *with* the internal knowledge that in the case of the bytes object it does not matter: The releasebufferproc is NULL, so PyBuffer_Release() is just a way of decrementing the reference count of the bytes object. No matter how you turn it, if info.obj != NULL you need some internal knowledge what the obj's releasebufferproc will do. For example, I suspect that many existing releasebufferprocs do not account for the fact that a consumer may change shape, strides and suboffsets. So you need to know the exporter really well. My strategy here is this: I want to keep backwards compatibility for PyMemoryView_FromBuffer(), which I think should be deprecated at some point. A proper function that returns a memoryview with automatic cleanup would not involve getbuffer/releasebuffer at all and could look like this: Flags: ------ PyManagedBuffer_FreeBuf PyManagedBuffer_FreeFormat PyManagedBuffer_FreeArrays // shape, strides, suboffsets PyMemoryView_FromBufferWithCleanup(info, flags) { /* info should never have been obtained by a call to PyObject_GetBuffer(). Hence it should never be released. */ assert(info.obj == NULL); /* buf, format, shape, strides and suboffsets MUST stay valid for the lifetime of the returned memoryview. Usually they will be dynamically allocated using PyMem_Malloc(). This is no problem, since there is automatic cleanup in mbuf_dealloc(). */ mbuf = mbuf_alloc(); mbuf->master = *info; mbuf->flags |= flags; ... return new memoryview } mbuf_dealloc(self) { if (self->flags&PyManagedBuffer_FreeBuf) PyMem_Free(self->master.buf); ... } This is much more flexible than the existing function and does not suffer from any abuse of getbuffer/releasebuffer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 10:37:12 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 01 Sep 2012 08:37:12 +0000 Subject: [issue15837] Added test to test_random.py testing Random.shuffle In-Reply-To: <1346465179.1.0.118516816378.issue15837@psf.upfronthosting.co.za> Message-ID: <1346488632.42.0.629405051315.issue15837@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > The int=int is probably some sort of micro-optimization and perhaps should be removed. Agree, this micro-optimization has no effect here. ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 10:38:56 2012 From: report at bugs.python.org (Alessandro Moura) Date: Sat, 01 Sep 2012 08:38:56 +0000 Subject: [issue15837] Added test to test_random.py testing Random.shuffle In-Reply-To: <1346465179.1.0.118516816378.issue15837@psf.upfronthosting.co.za> Message-ID: <1346488736.72.0.497968779028.issue15837@psf.upfronthosting.co.za> Alessandro Moura added the comment: Sorry, here it is the patch. ---------- keywords: +patch Added file: http://bugs.python.org/file27082/random.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 11:30:08 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 01 Sep 2012 09:30:08 +0000 Subject: [issue14783] Make int() and str() docstrings correct In-Reply-To: <1336751413.58.0.519130225761.issue14783@psf.upfronthosting.co.za> Message-ID: <1346491808.25.0.798760306297.issue14783@psf.upfronthosting.co.za> Ezio Melotti added the comment: The issues about "weird" signatures are being discussed on #15831. > However, this issue is about the docstring. Leave it incorrect? > Change it to the hard-to-parse one liner? Change it to a > two-line signature also? For the docstring it's ok to use the double signature too. The description, while not too comprehensive, is understandable. The description of int() in the docs is instead a bit complicated. The content is good, but IMHO it would be more understandable if it was broken down into paragraphs or into a list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 11:31:59 2012 From: report at bugs.python.org (Alessandro Moura) Date: Sat, 01 Sep 2012 09:31:59 +0000 Subject: [issue15826] Increased test coverage of test_glob.py In-Reply-To: <1346381534.69.0.636623200483.issue15826@psf.upfronthosting.co.za> Message-ID: <1346491919.79.0.989695571241.issue15826@psf.upfronthosting.co.za> Alessandro Moura added the comment: test_bytes_glob_directory_with_trailing_slash already has a counterpart in the main class, but it is not easily handled by overriding self.glob and self.norm. Since it is only a single test, I just decided to override test_glob_directory_with_trailing_slash from the main class. But looking at this now I realize that I actually created another method with a different name by mistake; so the attached patch changes that. ---------- Added file: http://bugs.python.org/file27083/test_glob.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 11:37:35 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Sat, 01 Sep 2012 09:37:35 +0000 Subject: [issue14042] json.dumps() documentation is slightly incorrect. In-Reply-To: <1329494870.59.0.571991231564.issue14042@psf.upfronthosting.co.za> Message-ID: <1346492255.01.0.17055199822.issue14042@psf.upfronthosting.co.za> Petri Lehtinen added the comment: Fixed, see #13769. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 13:02:47 2012 From: report at bugs.python.org (Ned Deily) Date: Sat, 01 Sep 2012 11:02:47 +0000 Subject: [issue15822] installed python may fail incorrectly trying to rebuild lib2to3 grammar pickles In-Reply-To: <1346321126.73.0.788135574831.issue15822@psf.upfronthosting.co.za> Message-ID: <1346497367.11.0.775460914943.issue15822@psf.upfronthosting.co.za> Ned Deily added the comment: The problem here is in the "libinstall" Makefile target and that hidden dependency within lib2to3 that, as Tomi notes, causes lib2to3 to try to recreate the pickles anytime it runs if it thinks they are out of date. The fixes for Issue15645 cause the recipes for that target to create the two grammar pickles in the source Lib directory before files are copied and installed into the destination lib directories. But there is no guarantee that the source files, Grammar.txt and PatternGrammar.txt, are installed into the destination lib before the corresponding pickle files are. lib2to3/pgen2/driver compares the value of os.path.getmtime() for the txt and pickle files (assuming both exist). On many (most) file systems, the copies happen fast enough and the resolution of getmtime is coarse enough that the files are created with the same time value so post-installation use of lib2to3 works OK. But on file systems like ext4 with high-resolution time values, it may happen that one or both of the pickle files is copied first and ends up with a slightly older time value than its corresponding txt file. In that case the first use of lib2to3 will try to recreate the pickle which will most likely fail with a file permission error since the install directories are typically read-only to non-root users. The attached patch tries to work around around the problem by touching the two pickle files after they and all the other relevant lib files have been installed. Since any user could run into this problem on the right configuration, I think the fix (assuming reviewers concur with it) should be cherry-picked for 3.3.0rc2. ---------- components: +Installation keywords: +patch nosy: +ronaldoussoren priority: high -> release blocker stage: -> patch review title: Python 3.3 creates lib2to3 grammar in wrong order -> installed python may fail incorrectly trying to rebuild lib2to3 grammar pickles versions: +Python 2.7, Python 3.2 Added file: http://bugs.python.org/file27084/issue15822_33.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 13:09:50 2012 From: report at bugs.python.org (Trent Nelson) Date: Sat, 01 Sep 2012 11:09:50 +0000 Subject: [issue15748] Various symlink test failures in test_shutil on FreeBSD In-Reply-To: <1345516038.44.0.114148239105.issue15748@psf.upfronthosting.co.za> Message-ID: <1346497790.95.0.662060496326.issue15748@psf.upfronthosting.co.za> Trent Nelson added the comment: Not really... the problem is that the chmod 0007 actually corrupts the ZFS metadata regarding the symlink by always setting the length to 24. Andriy did some debugging here: http://lists.freebsd.org/pipermail/freebsd-fs/2012-August/015005.html So, the link basically becomes invalid once the bug hits. Here's another option I just thought of: change the tests to use something other than 0007, then add another test specifically for this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 13:10:36 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Sat, 01 Sep 2012 11:10:36 +0000 Subject: [issue15802] Nonsensical test for mailbox In-Reply-To: <1346190608.89.0.55767676189.issue15802@psf.upfronthosting.co.za> Message-ID: <1346497836.62.0.297704995689.issue15802@psf.upfronthosting.co.za> Petri Lehtinen added the comment: Techincally, converting to int is not necessary, because the number of digits in the unix timestamp doesn't change until year 2286 :) The patch looks good to me. I don't think comparing pairs would be any more readable than what the proposed patch does. ---------- assignee: -> petri.lehtinen stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 13:22:16 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 01 Sep 2012 11:22:16 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346260029.19.0.320505643782.issue15814@psf.upfronthosting.co.za> Message-ID: <1346498536.77.0.793346305649.issue15814@psf.upfronthosting.co.za> Stefan Krah added the comment: Here's a patch that enforces byte formats. Does everyone agree on (or tolerate at least) allowing 'B', 'b' and 'c'? I think we should at least commit the doc patch for 3.3.0. Otherwise implementors of exporting objects might waste time on a feature that's deprecated. ---------- Added file: http://bugs.python.org/file27085/issue15814-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 13:26:44 2012 From: report at bugs.python.org (Ned Deily) Date: Sat, 01 Sep 2012 11:26:44 +0000 Subject: [issue15838] make install tries to create lib2to3 grammar pickles in source directory Message-ID: <1346498804.77.0.811767404939.issue15838@psf.upfronthosting.co.za> New submission from Ned Deily: With the recent activity around making out-of-tree builds work, while investigating Issue15822 I realized that the lib2to3 grammar pickle files are being built in the source directory by the libinstall target step of the main Makefile rather than in the build directory or just in the install location. The fixes for Issue15645 moved the pickle building to the start of the target recipes: libinstall: build_all $(srcdir)/Lib/$(PLATDIR) $(srcdir)/Modules/xxmodule.c -PYTHONPATH=$(DESTDIR)$(LIBDEST) $(RUNSHARED) \ $(PYTHON_FOR_BUILD) -Wi -c "import lib2to3.pygram, lib2to3.patcomp;lib2to3.patcomp.PatternCompiler()" On reflection, I think the PYTHONPATH definition is bogus here since LIBDEST is populated immediately after this step. More importantly, lib2to3/pgen2/driver:load_grammar ends up writing the pickle files into the source directory. Unlike some other cases in the Makefile, if the source directory is read-only, the failure to create the pickle files is not an error during installation but it may likely cause problems for later users of the installed lib2to3 (like in the Issue15822 scenario), i.e. when the missing pickles are attempted to be created in the read-only install directories. ---------- components: 2to3 (2.x to 3.x conversion tool), Build, Installation messages: 169623 nosy: benjamin.peterson, ned.deily, ronaldoussoren, trent priority: normal severity: normal stage: needs patch status: open title: make install tries to create lib2to3 grammar pickles in source directory versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 13:30:45 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 01 Sep 2012 11:30:45 +0000 Subject: [issue15802] Nonsensical test for mailbox In-Reply-To: <1346190608.89.0.55767676189.issue15802@psf.upfronthosting.co.za> Message-ID: <3X8FcN4YzpzQNS@mail.python.org> Roundup Robot added the comment: New changeset aef4a2ba3210 by Petri Lehtinen in branch '3.2': #15802: Fix test logic in TestMaildir.test_create_tmp http://hg.python.org/cpython/rev/aef4a2ba3210 New changeset 2370e331241b by Petri Lehtinen in branch '2.7': #15802: Fix test logic in TestMaildir.test_create_tmp http://hg.python.org/cpython/rev/2370e331241b New changeset e2fec0144bf8 by Petri Lehtinen in branch 'default': #15802: Fix test logic in TestMaildir.test_create_tmp http://hg.python.org/cpython/rev/e2fec0144bf8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 13:31:53 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Sat, 01 Sep 2012 11:31:53 +0000 Subject: [issue15802] Nonsensical test for mailbox In-Reply-To: <1346190608.89.0.55767676189.issue15802@psf.upfronthosting.co.za> Message-ID: <1346499113.66.0.848738685098.issue15802@psf.upfronthosting.co.za> Petri Lehtinen added the comment: Fixed, thanks. ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 14:13:24 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 01 Sep 2012 12:13:24 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346260029.19.0.320505643782.issue15814@psf.upfronthosting.co.za> Message-ID: <1346501604.71.0.986464138041.issue15814@psf.upfronthosting.co.za> Nick Coghlan added the comment: +1 for docs patch for 3.3.0 and then enforcing the format restriction for 3.3.1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 14:39:58 2012 From: report at bugs.python.org (Alexey Boriskin) Date: Sat, 01 Sep 2012 12:39:58 +0000 Subject: [issue15795] Zipfile.extractall does not preserve file permissions In-Reply-To: <1346106964.12.0.723201722432.issue15795@psf.upfronthosting.co.za> Message-ID: <1346503198.79.0.834107666726.issue15795@psf.upfronthosting.co.za> Changes by Alexey Boriskin : ---------- hgrepos: +147 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 14:40:19 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 01 Sep 2012 12:40:19 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346260029.19.0.320505643782.issue15814@psf.upfronthosting.co.za> Message-ID: <3X8H8d5cmPzQNh@mail.python.org> Roundup Robot added the comment: New changeset 895e123d9476 by Stefan Krah in branch 'default': Issue #15814: Document planned restrictions for memoryview hashes in 3.3.1. http://hg.python.org/cpython/rev/895e123d9476 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 15:08:57 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 01 Sep 2012 13:08:57 +0000 Subject: [issue14223] curses addch broken on Python3.3a1 In-Reply-To: <1331153094.15.0.871612927682.issue14223@psf.upfronthosting.co.za> Message-ID: <3X8Hng6BTDzQQK@mail.python.org> Roundup Robot added the comment: New changeset 27b5bd5f0e4c by Victor Stinner in branch 'default': Close #14223: Fix window.addch(curses.ACS_HLINE) http://hg.python.org/cpython/rev/27b5bd5f0e4c ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 15:09:10 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 01 Sep 2012 13:09:10 +0000 Subject: [issue15795] Zipfile.extractall does not preserve file permissions In-Reply-To: <1346106964.12.0.723201722432.issue15795@psf.upfronthosting.co.za> Message-ID: <1346504950.82.0.844261873084.issue15795@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- hgrepos: -147 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 15:10:53 2012 From: report at bugs.python.org (Alexey Boriskin) Date: Sat, 01 Sep 2012 13:10:53 +0000 Subject: [issue15795] Zipfile.extractall does not preserve file permissions In-Reply-To: <1346106964.12.0.723201722432.issue15795@psf.upfronthosting.co.za> Message-ID: <1346505053.45.0.571060898943.issue15795@psf.upfronthosting.co.za> Alexey Boriskin added the comment: I'm attaching a patch, which solves the issue. Patch intoduces new argument "preserve_permissions" for extract and extractall methods. That argument may accept one of the three values: do not preserve permissions, preserve a safe subset of them or preserve all permissions. Three constants introduced for these options. Patch also contains test and docs. Tests pass for me on OS X 10.5, but I'm not sure if they'll pass on other operating systems. ---------- keywords: +patch Added file: http://bugs.python.org/file27086/issue15795.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 15:24:09 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 01 Sep 2012 13:24:09 +0000 Subject: [issue14223] curses addch broken on Python3.3a1 In-Reply-To: <1331153094.15.0.871612927682.issue14223@psf.upfronthosting.co.za> Message-ID: <1346505849.11.0.443006554822.issue14223@psf.upfronthosting.co.za> STINNER Victor added the comment: > I'm reopening this bug because I've noticed that in Python3.3rc1, > although trying to print curses.ACS_HLINE and other such characters > no long cause an Exception, only blank characters are printed to > the screen. If the Python curses module is compiled in Unicode mode (if curses.unget_wch() is present), addch(int) calls the C function wadd_wch() or mvwadd_wch(), instead of waddch() or mvwaddch(). It looks like the *_wch() family does not support characters like curses.ACS_HLINE. My commit fixes the issue. @Nicholas.Cole: Can you please try the last development version (default branch)? @georg.brandl: Can you please include the important fix 27b5bd5f0e4c in Python 3.3 final? ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 15:25:03 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 01 Sep 2012 13:25:03 +0000 Subject: [issue14223] curses addch broken on Python3.3a1 In-Reply-To: <1331153094.15.0.871612927682.issue14223@psf.upfronthosting.co.za> Message-ID: <1346505903.55.0.953318933477.issue14223@psf.upfronthosting.co.za> STINNER Victor added the comment: (keep the issue open until the fix is included in Georg's repository) ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 15:26:14 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 01 Sep 2012 13:26:14 +0000 Subject: [issue15785] curses.get_wch() returns keypad codes incorrectly In-Reply-To: <1345975778.97.0.705241878581.issue15785@psf.upfronthosting.co.za> Message-ID: <1346505974.92.0.18154342259.issue15785@psf.upfronthosting.co.za> STINNER Victor added the comment: @georg.brandl: Can you please include the important fix c58789634d22 into Python 3.3 final? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 15:52:15 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 01 Sep 2012 13:52:15 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346498536.77.0.793346305649.issue15814@psf.upfronthosting.co.za> Message-ID: <5042130B.1050800@v.loewis.de> Martin v. L?wis added the comment: Am 01.09.12 13:22, schrieb Stefan Krah: > Does everyone agree on (or tolerate at least) allowing 'B', 'b' and 'c'? Why be more permissive than necessary? -0 on the committed version; it should IMO further restrict it to 1D contiguous byte arrays. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 16:09:01 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Sat, 01 Sep 2012 14:09:01 +0000 Subject: [issue15839] SystemError raised by super() should be NameError or RuntimeError Message-ID: <1346508541.04.0.853072474076.issue15839@psf.upfronthosting.co.za> New submission from Ramchandra Apte: Running the erronous code: class X: super_object = super() fails with a SystemError("super(): __class__ cell not found") The exception should be a NameError or SystemError. ---------- components: None messages: 169634 nosy: ramchandra.apte priority: normal severity: normal status: open title: SystemError raised by super() should be NameError or RuntimeError type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 16:09:18 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Sat, 01 Sep 2012 14:09:18 +0000 Subject: [issue15839] SystemError raised by super() in erronous class should be NameError or RuntimeError In-Reply-To: <1346508541.04.0.853072474076.issue15839@psf.upfronthosting.co.za> Message-ID: <1346508558.04.0.310475887355.issue15839@psf.upfronthosting.co.za> Changes by Ramchandra Apte : ---------- title: SystemError raised by super() should be NameError or RuntimeError -> SystemError raised by super() in erronous class should be NameError or RuntimeError _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 16:20:06 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 01 Sep 2012 14:20:06 +0000 Subject: [issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0 In-Reply-To: <1344473974.14.0.584788696764.issue15599@psf.upfronthosting.co.za> Message-ID: <1346509206.92.0.348740002595.issue15599@psf.upfronthosting.co.za> Stefan Krah added the comment: The FreeBSD machine decided to hang for 1h: http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%203.x/builds/3340/steps/test/logs/stdio If I'm running the tests manually, they take over half an hour and I get: ====================================================================== FAIL: test_parallel_meta_path (test.test_threaded_import.ThreadedImportTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/stefan/cpython/Lib/test/test_threaded_import.py", line 133, in test_parallel_meta_path self.assertEqual(finder.x, finder.numcalls) AssertionError: 41 != 42 ---------------------------------------------------------------------- Ran 6 tests in 2090.042s [I hope this is not a threading bug in FreeBSD that appears under high load.] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 16:24:21 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 01 Sep 2012 14:24:21 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346260029.19.0.320505643782.issue15814@psf.upfronthosting.co.za> Message-ID: <1346509461.82.0.800548746043.issue15814@psf.upfronthosting.co.za> Stefan Krah added the comment: Martin v. L??wis wrote: > Why be more permissive than necessary? -0 on the committed version; > it should IMO further restrict it to 1D contiguous byte arrays. Does "byte arrays" include 'b' and 'c' or just 'B'? I don't see a reason to allow 'B' but not the others. I'm +-0 on allowing multi-dimensional arrays, but it would be odd to restrict hashing to contiguous arrays: >>> b = b'abcdefhhijkl' >>> m = memoryview(b) >>> b[::-1] b'lkjihhfedcba' >>> bytes(m[::-1]) b'lkjihhfedcba' >>> hash(b[::-1]) == hash(m[::-1]) True My reasoning was: If non-contiguous arrays are allowed (and I think they should be), why not allow multi-dimensional arrays, too? The definition hash(m) == hash(m.tobytes()) is pretty straightforward. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 16:31:20 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 01 Sep 2012 14:31:20 +0000 Subject: [issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0 In-Reply-To: <1344473974.14.0.584788696764.issue15599@psf.upfronthosting.co.za> Message-ID: <1346509880.57.0.0775970785662.issue15599@psf.upfronthosting.co.za> Stefan Krah added the comment: I see that in the following build test_threading also fails, so I wouldn't spend too much time on debugging test_threaded_import: ====================================================================== FAIL: test_waitfor_timeout (test.test_threading.ConditionTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/lock_tests.py", line 531, in test_waitfor_timeout self.assertEqual(len(success), 1) AssertionError: 0 != 1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 16:42:11 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 01 Sep 2012 14:42:11 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346509461.82.0.800548746043.issue15814@psf.upfronthosting.co.za> Message-ID: <8B95886E-FFE7-4948-94EA-7CABA9AF1ED1@gmail.com> Alexander Belopolsky added the comment: On Sep 1, 2012, at 10:24 AM, Stefan Krah wrote: > > The definition hash(m) == hash(m.tobytes()) is pretty straightforward. I probably missed something from the early discussion, but doesn't this definition only work for 1d (or 0d) views? Shouldn't shape come into calculation for multidimensional views? ---------- nosy: +Alexander.Belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 16:47:38 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 01 Sep 2012 14:47:38 +0000 Subject: [issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0 In-Reply-To: <1346509880.57.0.0775970785662.issue15599@psf.upfronthosting.co.za> Message-ID: <1346510586.3380.0.camel@localhost.localdomain> Antoine Pitrou added the comment: > I see that in the following build test_threading also fails, so I > wouldn't spend too much time on debugging test_threaded_import: Did something change recently on that machine? It's supposed to be a stable buildbot. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 16:57:56 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 01 Sep 2012 14:57:56 +0000 Subject: [issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0 In-Reply-To: <1344473974.14.0.584788696764.issue15599@psf.upfronthosting.co.za> Message-ID: <1346511476.91.0.500747027211.issue15599@psf.upfronthosting.co.za> Stefan Krah added the comment: Nothing changed on the buildbot. -- It appears that FreeBSD is unable to handle the low switchinterval. With the patch test_threaded_import runs in 10s. Since Linux has no problems whatsoever, I'm inclined to think that's a FreeBSD issue. I've yet to check if the other problem in test_threading is related. ---------- keywords: +patch Added file: http://bugs.python.org/file27087/issue15599.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 17:06:29 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 01 Sep 2012 15:06:29 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <8B95886E-FFE7-4948-94EA-7CABA9AF1ED1@gmail.com> Message-ID: <20120901150629.GA15155@sleipnir.bytereef.org> Stefan Krah added the comment: tobytes() is the same as the flattened multi-dimensional list representation with all elements converted to bytes. If I'm not mistaken, that's how NumPy's tostring() behaves. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 17:15:09 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 01 Sep 2012 15:15:09 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <20120901150629.GA15155@sleipnir.bytereef.org> Message-ID: <5C3A1B24-C1FD-49DE-AC58-469F8E97F683@gmail.com> Alexander Belopolsky added the comment: On Sep 1, 2012, at 11:06 AM, Stefan Krah wrote: > tobytes() is the same as the flattened multi-dimensional list representation > with all elements converted to bytes. This is correct, but why is it desirable to have deliberate hash collisions between views with different shapes? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 17:16:45 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 01 Sep 2012 15:16:45 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346260029.19.0.320505643782.issue15814@psf.upfronthosting.co.za> Message-ID: <1346512605.02.0.62559370697.issue15814@psf.upfronthosting.co.za> Nick Coghlan added the comment: Keep in mind that its OK if hash(m) == hash(m.tobytes()) in some cases where "m != m.tobytes()". The only cases we really need to kill are those that break the hash invariant. I don't like the idea of making the definition of hash more complicated just to rule out cases that aren't actually broken. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 17:29:50 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 01 Sep 2012 15:29:50 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <5C3A1B24-C1FD-49DE-AC58-469F8E97F683@gmail.com> Message-ID: <20120901152950.GA15471@sleipnir.bytereef.org> Stefan Krah added the comment: > why is it desirable to have deliberate hash collisions between views with different shapes? Since we're now restricting everything to bytes, the multi-dimensional case is probably not useful at all. As I said above, I would leave it in because it actually saves one check for ndim and as Nick said, the definition is simpler. Now the user only has to remember that hashing works for 'B', 'b' and 'c'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 18:06:18 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 01 Sep 2012 16:06:18 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346509461.82.0.800548746043.issue15814@psf.upfronthosting.co.za> Message-ID: <50423277.1020207@v.loewis.de> Martin v. L?wis added the comment: Am 01.09.12 16:24, schrieb Stefan Krah: > Does "byte arrays" include 'b' and 'c' or just 'B'? I don't see a reason > to allow 'B' but not the others. Either type is fine with me. It's the multi-dimensional aspect I'd like to ban. > My reasoning was: If non-contiguous arrays are allowed (and I think they > should be), why not allow multi-dimensional arrays, too? I think neither should be allowed. The explicit request (from Antoine) was that memoryviews of bytes objects should be hashable. I haven't heard anybody asking for something more general (but I could see that people want to hash other memory blocks as well, such as mmap views). I can see that it is tempting to provide the most general definition, but see where this approach got us. It's always easier to widen an interface later than to narrow it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 18:54:00 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 01 Sep 2012 16:54:00 +0000 Subject: [issue15523] Block on close TCP socket in SocketServer.py In-Reply-To: <1343815668.28.0.0910478510187.issue15523@psf.upfronthosting.co.za> Message-ID: <1346518440.69.0.909465016445.issue15523@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: > So when calling close_request to deallocate the socket, it will > always be waiting to read response until response data is available. > It seems like an issue in SokcetServer.py library. Hum, I don't see what you mean. Even if there is still data in the receive socket buffer, socket.clos() shouldn't block. Actually, it should result in a RST being sent. Could you describe your problem more precisely (with a code snippet it would be better)? ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 19:07:05 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 01 Sep 2012 17:07:05 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1346519225.52.0.108048199781.issue15831@psf.upfronthosting.co.za> Georg Brandl added the comment: +1 for multiple signatures. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 19:20:22 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 01 Sep 2012 17:20:22 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <50423277.1020207@v.loewis.de> Message-ID: <20120901172023.GA16365@sleipnir.bytereef.org> Stefan Krah added the comment: Disallowing non-contiguous arrays leads to very strange situations though. I'm positive that there will be a bug report about this: >>> x = memoryview(b'abc')[::-1] >>> b = b'cba' >>> d = {b'cba': 101} >>> >>> b in d True >>> x == b True >>> x in d Traceback (most recent call last): File "", line 1, in ValueError: memoryiew: hashing is restricted to C-contiguous arrays Could we perhaps take a small poll? My own vote is: 1) Allow bytes hashing at all: +0.5 2) If 1) is allowed, then also non-contiguous hashing is allowed: +1 3) Allow multi-dimensional hashing: +-0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 19:30:04 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 01 Sep 2012 17:30:04 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1346520604.51.0.00250882834378.issue15831@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > (The double signature might be easier to understand, but the original issue should probably be fixed in Sphinx, even if we decide to stop using this kind of signature.) I filed an issue for this in the Sphinx tracker here: https://bitbucket.org/birkenfeld/sphinx/issue/1001/comma-after-leading-optional-argument-in ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 19:35:55 2012 From: report at bugs.python.org (Martijn Pieters) Date: Sat, 01 Sep 2012 17:35:55 +0000 Subject: [issue14385] Support other types than dict for __builtins__ In-Reply-To: <1332380135.46.0.264363154256.issue14385@psf.upfronthosting.co.za> Message-ID: <1346520955.74.0.447345022262.issue14385@psf.upfronthosting.co.za> Martijn Pieters added the comment: I note that the documentation still states a dictionary is required for globals. Should that not be updated as well? See http://docs.python.org/py3k/library/functions.html#exec ---------- nosy: +mjpieters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 19:37:01 2012 From: report at bugs.python.org (Martijn Pieters) Date: Sat, 01 Sep 2012 17:37:01 +0000 Subject: [issue14385] Support other types than dict for __builtins__ In-Reply-To: <1332380135.46.0.264363154256.issue14385@psf.upfronthosting.co.za> Message-ID: <1346521021.69.0.163824578536.issue14385@psf.upfronthosting.co.za> Martijn Pieters added the comment: Apologies, I meant to link to the dev docs: http://docs.python.org/dev/library/functions.html#exec ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 19:37:54 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 01 Sep 2012 17:37:54 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1346521074.72.0.74246496138.issue15831@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I will prepare a patch (multiple signatures, for the Python fix). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 19:43:52 2012 From: report at bugs.python.org (Michael Foord) Date: Sat, 01 Sep 2012 17:43:52 +0000 Subject: [issue15836] unittest assertRaises should verify excClass is actually a BaseException class In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za> Message-ID: <1346521432.52.0.444434346337.issue15836@psf.upfronthosting.co.za> Michael Foord added the comment: Yep, certainly worth fixing. When 3.3 is out the door I will look at applying this to all branches. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 19:44:06 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 01 Sep 2012 17:44:06 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <20120901172023.GA16365@sleipnir.bytereef.org> Message-ID: <50424964.8050806@v.loewis.de> Martin v. L?wis added the comment: Am 01.09.12 19:20, schrieb Stefan Krah: > Disallowing non-contiguous arrays leads to very strange situations though. I don't find that strange. That two object compare equal doesn't imply that they both hash - only that *if* they hash, they should hash equal. In any case, this can happen already: py> x = memoryview(array.array('B',b'cba')) py> b = b'cba' py> d = {b'cba': 101} py> b in d True py> x == b True py> x in d Traceback (most recent call last): File "", line 1, in ValueError: cannot hash writable memoryview object It can also happen with other types (although I had to look around a bit): py> x=set((1,2,3)) py> b=frozenset(x) py> d={b:101} py> b in d True py> x==b True py> x in d Traceback (most recent call last): File "", line 1, in TypeError: unhashable type: 'set' > 1) Allow bytes hashing at all: +0.5 +0 > 2) If 1) is allowed, then also non-contiguous hashing is allowed: +1 -1 > 3) Allow multi-dimensional hashing: +-0 -1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 19:44:44 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 01 Sep 2012 17:44:44 +0000 Subject: [issue15836] unittest assertRaises should verify excClass is actually a BaseException class In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za> Message-ID: <1346521484.52.0.00518296518922.issue15836@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 19:58:49 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 01 Sep 2012 17:58:49 +0000 Subject: [issue11866] race condition in threading._newname() In-Reply-To: <1303126142.97.0.491583907596.issue11866@psf.upfronthosting.co.za> Message-ID: <1346522329.37.0.529800063948.issue11866@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 20:04:54 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 01 Sep 2012 18:04:54 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <20120901172023.GA16365@sleipnir.bytereef.org> Message-ID: <1346522474.3380.4.camel@localhost.localdomain> Antoine Pitrou added the comment: > Could we perhaps take a small poll? My own vote is: > > 1) Allow bytes hashing at all: +0.5 +10. The buffer() object in 2.x was hashable, and a very important use case of memoryview is replacing buffer(). > 2) If 1) is allowed, then also non-contiguous hashing is allowed: +1 > 3) Allow multi-dimensional hashing: +-0 I don't care about these. I kind of agree with Martin that hashability should be motivated by an use case, so -0. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 20:06:31 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 01 Sep 2012 18:06:31 +0000 Subject: [issue11866] race condition in threading._newname() In-Reply-To: <1303126142.97.0.491583907596.issue11866@psf.upfronthosting.co.za> Message-ID: <1346522791.33.0.311847162619.issue11866@psf.upfronthosting.co.za> Antoine Pitrou added the comment: With or without Raymond's suggested change, "global _counter" is not necessary anymore. Note that this fix only works on implementations where itertools.count().next is atomic. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 20:06:33 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 01 Sep 2012 18:06:33 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <50424964.8050806@v.loewis.de> Message-ID: <20120901180633.GA16743@sleipnir.bytereef.org> Stefan Krah added the comment: > py> x = memoryview(array.array('B',b'cba')) I find the array example is different. The user has to remember one thing: memoryviews based on arrays don't hash. For memoryviews based on bytes one would have to remember: - 'B', 'c' and 'b' hash - only C-contiguous arrays hash - b'abc'[::-1] hashes, but memoryview(b'abc')[::-1] does not ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 20:08:16 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 01 Sep 2012 18:08:16 +0000 Subject: [issue15836] unittest assertRaises should verify excClass is actually a BaseException class In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za> Message-ID: <1346522896.25.0.944248852825.issue15836@psf.upfronthosting.co.za> R. David Murray added the comment: Since it is a bugfix it can be applied at any time now. Checkins to default will end up in 3.3.1 and 3.4. (Only features need to wait until after 3.3 is branched in the main repo.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 20:22:28 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 01 Sep 2012 18:22:28 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <20120901180633.GA16743@sleipnir.bytereef.org> Message-ID: <50425262.8030106@v.loewis.de> Martin v. L?wis added the comment: Am 01.09.12 20:06, schrieb Stefan Krah: > - b'abc'[::-1] hashes, but memoryview(b'abc')[::-1] does not I find that memoryview(b'abc')[::-1] is a strange thing to have, anyway, so I'm not bothered by it behaving different. I can accept that it needs to be supported for consistency, but I would recommend against using it in applications. Who needs reversed memory, anyway? The only case were I ever needed reversal is lists (typically sorted, perhaps cronological). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 20:33:44 2012 From: report at bugs.python.org (Alexander Konovalenko) Date: Sat, 01 Sep 2012 18:33:44 +0000 Subject: [issue15840] Ambiguity with regard to the effect of accessing a closed IOBase instance Message-ID: <1346524424.76.0.407141547435.issue15840@psf.upfronthosting.co.za> New submission from Alexander Konovalenko: Two pieces of the documentation for io.IOBase seem to contradict each other: At http://docs.python.org/library/io.html#io.IOBase: "Note that calling any method (even inquiries) on a closed stream is undefined. Implementations may raise IOError in this case." At http://docs.python.org/library/io.html#io.IOBase.close: "Once the file is closed, any operation on the file (e.g. reading or writing) will raise a ValueError." Perhaps the confusion arises in part because it is not clear when a requirement for all IOBase implementations is documented and when the docs merely describe the default behavior of IOBase that implementations are free to override. Those passages are inconsistent on two points: 1) IOError and ValueError are not subclasses one of another. So what should we expect an IOBase implementation to raise? 2) Undefined behavior means literally anything can happen. Technically, that means calling read() or readable() on a closed file (or other kind of stream) could wreak havoc in a totally unrelated part of the system or segfault the Python interpreter. That is definitely a thing to carefully avoid in any production systems. On the other hand, raising an exception, even if we don't know in advance whether it will be ValueError or IOError, is pretty much defined behavior. An exception is easy to deal with and to contain inside a module. So please clarify how dangerous it actually is to access an IOBase stream after it has been closed. ---------- assignee: docs at python components: Documentation messages: 169660 nosy: alexkon, docs at python priority: normal severity: normal status: open title: Ambiguity with regard to the effect of accessing a closed IOBase instance versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 20:49:20 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 01 Sep 2012 18:49:20 +0000 Subject: [issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0 In-Reply-To: <1346511476.91.0.500747027211.issue15599@psf.upfronthosting.co.za> Message-ID: <1346525141.3380.5.camel@localhost.localdomain> Antoine Pitrou added the comment: > Since Linux has no problems whatsoever, I'm inclined to think that's > a FreeBSD issue. Maybe. If you believe it's so, I guess the patch can be committed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 20:59:31 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 01 Sep 2012 18:59:31 +0000 Subject: [issue1528167] Tweak to make string.Templates more customizable Message-ID: <1346525971.77.0.379342921921.issue1528167@psf.upfronthosting.co.za> R. David Murray added the comment: I don't think this closure was appropriate. The idea was accepted twice and argued against once, so it isn't dead (it's just resting). ---------- assignee: barry -> nosy: +r.david.murray resolution: wont fix -> status: closed -> open versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 21:13:59 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 01 Sep 2012 19:13:59 +0000 Subject: [issue15840] Ambiguity with regard to the effect of accessing a closed IOBase instance In-Reply-To: <1346524424.76.0.407141547435.issue15840@psf.upfronthosting.co.za> Message-ID: <1346526839.49.0.306349459602.issue15840@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > 1) IOError and ValueError are not subclasses one of another. So what > should we expect an IOBase implementation to raise? Ideally, ValueError should be raised, but I suspect some methods raise IOError instead. > Undefined behavior means literally anything can happen. In practice, it will either raise an error, or be ignored. For example, calling close() a second time would be ignored. Calling readable() may return the original value (before the file was closed), etc. Any non-trivial behaviour should be reported as a bug, though. Especially, reading or writing methods (read(), write(), readline() etc.) should *never* succeed on a closed file. ---------- components: +IO nosy: +pitrou stage: -> needs patch versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 21:16:54 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 01 Sep 2012 19:16:54 +0000 Subject: [issue15840] Ambiguity with regard to the effect of accessing a closed IOBase instance In-Reply-To: <1346524424.76.0.407141547435.issue15840@psf.upfronthosting.co.za> Message-ID: <1346527014.03.0.308506233513.issue15840@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Actually, I would suggest we standardize the docs on raising ValueError as the official behaviour, and fix non-compliant behaviours as bugs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 21:18:52 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 01 Sep 2012 19:18:52 +0000 Subject: [issue15841] Some StringIO and BytesIO methods can succeed after close Message-ID: <1346527132.85.0.102313792516.issue15841@psf.upfronthosting.co.za> New submission from Antoine Pitrou: >>> f = io.StringIO() >>> f.close() >>> f.readable() True >>> f.read() Traceback (most recent call last): File "", line 1, in ValueError: I/O operation on closed file. >>> f = io.BytesIO() >>> f.close() >>> f.readable() True >>> f.read() Traceback (most recent call last): File "", line 1, in ValueError: I/O operation on closed file ---------- components: IO, Library (Lib) messages: 169665 nosy: pitrou priority: normal severity: normal status: open title: Some StringIO and BytesIO methods can succeed after close type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 21:19:03 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 01 Sep 2012 19:19:03 +0000 Subject: [issue15841] Some StringIO and BytesIO methods can succeed after close In-Reply-To: <1346527132.85.0.102313792516.issue15841@psf.upfronthosting.co.za> Message-ID: <1346527143.43.0.160482210189.issue15841@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +benjamin.peterson, hynek, stutzbach _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 21:19:09 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 01 Sep 2012 19:19:09 +0000 Subject: [issue15840] Ambiguity with regard to the effect of accessing a closed IOBase instance In-Reply-To: <1346524424.76.0.407141547435.issue15840@psf.upfronthosting.co.za> Message-ID: <1346527149.31.0.268114692819.issue15840@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +benjamin.peterson, hynek, stutzbach _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 21:20:13 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 01 Sep 2012 19:20:13 +0000 Subject: [issue15842] Some SocketIO methods can succeed after close() Message-ID: <1346527213.21.0.243179396441.issue15842@psf.upfronthosting.co.za> New submission from Antoine Pitrou: >>> import socket >>> s = socket.socket() >>> f = s.makefile("rb", buffering=0) >>> f >>> f.close() >>> f.writable() False >>> f.readable() False ---------- components: IO, Library (Lib) messages: 169666 nosy: benjamin.peterson, hynek, pitrou, stutzbach priority: normal severity: normal status: open title: Some SocketIO methods can succeed after close() type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 21:20:25 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 01 Sep 2012 19:20:25 +0000 Subject: [issue15840] Ambiguity with regard to the effect of accessing a closed IOBase instance In-Reply-To: <1346524424.76.0.407141547435.issue15840@psf.upfronthosting.co.za> Message-ID: <1346527225.83.0.304537561064.issue15840@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Related: issue15841 and issue15842. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 21:24:23 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 01 Sep 2012 19:24:23 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1346527463.11.0.95514927297.issue2771@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- hgrepos: +148 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 21:24:39 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 01 Sep 2012 19:24:39 +0000 Subject: [issue15826] Increased test coverage of test_glob.py In-Reply-To: <1346381534.69.0.636623200483.issue15826@psf.upfronthosting.co.za> Message-ID: <1346527479.19.0.999628673759.issue15826@psf.upfronthosting.co.za> R. David Murray added the comment: I've modified your patch slightly (cosmetic only). When I run it on default I get the following: /home/rdmurray/python/p33/Lib/os.py:263: BytesWarning: Comparison between bytes and string if tail == curdir: # xxx/newdir/. exists if xxx/newdir exists /home/rdmurray/python/p33/Lib/glob.py:63: BytesWarning: Comparison between bytes and string if basename == '': These presumably represent bugs. Care to investigate and file issues for them? ---------- Added file: http://bugs.python.org/file27088/test_glob.patch.updated _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 21:24:53 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 01 Sep 2012 19:24:53 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1346527493.86.0.124212344152.issue2771@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +patch Added file: http://bugs.python.org/file27089/b17f9a10235f.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 22:23:56 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 01 Sep 2012 20:23:56 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za> Message-ID: <1346531036.04.0.160026956506.issue15510@psf.upfronthosting.co.za> R. David Murray added the comment: Added some review comments on issue-15510-4.patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 1 22:29:12 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 01 Sep 2012 20:29:12 +0000 Subject: [issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0 In-Reply-To: <1346525141.3380.5.camel@localhost.localdomain> Message-ID: <20120901202913.GA17629@sleipnir.bytereef.org> Stefan Krah added the comment: The extreme slowness with a low switch interval is already present in 3430d7329a3b, so it's not related to the finer-grained import lock. The other FreeBSD 9.0 bots don't seem to have that problem, so I'm not sure any more if the patch is a good idea. FWIW, http://buildbot.python.org/all/buildslaves/koobs-freebsd runs in VirtualBox, my system runs in kvm. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 00:13:31 2012 From: report at bugs.python.org (Chris Rebert) Date: Sat, 01 Sep 2012 22:13:31 +0000 Subject: [issue14570] Document json "sort_keys" parameter properly In-Reply-To: <1334284947.71.0.88941407788.issue14570@psf.upfronthosting.co.za> Message-ID: <1346537611.45.0.229801613164.issue14570@psf.upfronthosting.co.za> Changes by Chris Rebert : Added file: http://bugs.python.org/file27090/json.rst.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 00:20:19 2012 From: report at bugs.python.org (Chris Rebert) Date: Sat, 01 Sep 2012 22:20:19 +0000 Subject: [issue14570] Document json "sort_keys" parameter properly In-Reply-To: <1334284947.71.0.88941407788.issue14570@psf.upfronthosting.co.za> Message-ID: <1346538019.38.0.968316026329.issue14570@psf.upfronthosting.co.za> Chris Rebert added the comment: Attached updated patches. ---------- Added file: http://bugs.python.org/file27091/json_init.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 00:31:47 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 01 Sep 2012 22:31:47 +0000 Subject: [issue15822] installed python may fail incorrectly trying to rebuild lib2to3 grammar pickles In-Reply-To: <1346321126.73.0.788135574831.issue15822@psf.upfronthosting.co.za> Message-ID: <1346538707.12.0.721120510659.issue15822@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: > - done > + done; \ Not needed. > + touch $(DESTDIR)$(LIBDEST)/lib2to3/*Grammar*.pickle || true "-" prefix can be used to ignore failure of command: + -touch $(DESTDIR)$(LIBDEST)/lib2to3/*Grammar*.pickle However maybe failure of touch should not be ignored here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 00:33:43 2012 From: report at bugs.python.org (Alastair Porter) Date: Sat, 01 Sep 2012 22:33:43 +0000 Subject: [issue15843] aifc.open expects only str or file pointer Message-ID: <1346538823.6.0.158703748918.issue15843@psf.upfronthosting.co.za> New submission from Alastair Porter: Passing a unicode filename to aifc.open() results in the argument being treated like a filepointer instead of opening the file. The argument check, http://hg.python.org/cpython/file/default/Lib/aifc.py#l332 only checks if the argument is a str. Should this be extended to accept all string-type objects? Example usage: >>> import aifc >>> aifc.open(u"/some/path") Traceback (most recent call last): File "", line 1, in File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/aifc.py", line 924, in open return Aifc_read(f) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/aifc.py", line 335, in __init__ self.initfp(f) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/aifc.py", line 286, in initfp chunk = Chunk(file) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/chunk.py", line 61, in __init__ self.chunkname = file.read(4) AttributeError: 'unicode' object has no attribute 'read' ---------- components: None messages: 169673 nosy: alastairp priority: normal severity: normal status: open title: aifc.open expects only str or file pointer type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 00:34:08 2012 From: report at bugs.python.org (Ned Deily) Date: Sat, 01 Sep 2012 22:34:08 +0000 Subject: [issue15822] installed python may fail incorrectly trying to rebuild lib2to3 grammar pickles In-Reply-To: <1346321126.73.0.788135574831.issue15822@psf.upfronthosting.co.za> Message-ID: <1346538848.72.0.877551071842.issue15822@psf.upfronthosting.co.za> Ned Deily added the comment: I did it that way to ensure that the touch is executed after the copies. And the touch needs to be optional because the creation of the pickles can optionally fail. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 00:36:14 2012 From: report at bugs.python.org (Alessandro Moura) Date: Sat, 01 Sep 2012 22:36:14 +0000 Subject: [issue15826] Increased test coverage of test_glob.py In-Reply-To: <1346381534.69.0.636623200483.issue15826@psf.upfronthosting.co.za> Message-ID: <1346538974.01.0.988462977008.issue15826@psf.upfronthosting.co.za> Alessandro Moura added the comment: Im OK with the patch changes. ''' /home/rdmurray/python/p33/Lib/os.py:263: BytesWarning: Comparison between bytes and string if tail == curdir: # xxx/newdir/. exists if xxx/newdir exists /home/rdmurray/python/p33/Lib/glob.py:63: BytesWarning: Comparison between bytes and string if basename == '': ''' Yes, I do see these warnings running with -b. I will look into them and try to fix them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 00:37:15 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 01 Sep 2012 22:37:15 +0000 Subject: [issue15744] missing tests for {RawIO,BufferedIO,TextIO}.writelines In-Reply-To: <1345500357.29.0.226025015503.issue15744@psf.upfronthosting.co.za> Message-ID: <1346539035.08.0.857973476631.issue15744@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +benjamin.peterson, hynek, stutzbach _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 00:51:53 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 01 Sep 2012 22:51:53 +0000 Subject: [issue15822] installed python may fail incorrectly trying to rebuild lib2to3 grammar pickles In-Reply-To: <1346321126.73.0.788135574831.issue15822@psf.upfronthosting.co.za> Message-ID: <1346539913.67.0.223406139967.issue15822@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: > And the touch needs to be optional because the creation of the pickles can optionally fail. If creation of pickles failed, then touch will create 1 file literally named "*Grammar*.pickle". ... done; \ for i in $(DESTDIR)$(LIBDEST)/lib2to3/*Grammar*.pickle; do \ if test -f "$$i"; then \ touch "$$i"; \ fi; \ done ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 00:57:14 2012 From: report at bugs.python.org (Ned Deily) Date: Sat, 01 Sep 2012 22:57:14 +0000 Subject: [issue15822] installed python may fail incorrectly trying to rebuild lib2to3 grammar pickles In-Reply-To: <1346321126.73.0.788135574831.issue15822@psf.upfronthosting.co.za> Message-ID: <1346540234.55.0.254123385477.issue15822@psf.upfronthosting.co.za> Ned Deily added the comment: Right you are, thanks! I had that in an earlier version. Are you able to verify the fix? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 01:04:11 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 01 Sep 2012 23:04:11 +0000 Subject: [issue15645] 2to3 Grammar pickles not created when upgrading to 3.3.0b2 In-Reply-To: <1344932180.41.0.826216341416.issue15645@psf.upfronthosting.co.za> Message-ID: <1346540651.25.0.130151634047.issue15645@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: libinstall target now contains: -PYTHONPATH=$(DESTDIR)$(LIBDEST) $(RUNSHARED) \ $(PYTHON_FOR_BUILD) -Wi -c "import lib2to3.pygram, lib2to3.patcomp;lib2to3.patcomp.PatternCompiler()" ... @for d in $(LIBSUBDIRS); \ do \ a=$(srcdir)/Lib/$$d; \ if test ! -d $$a; then continue; else true; fi; \ if test `ls $$a | wc -l` -lt 1; then continue; fi; \ b=$(LIBDEST)/$$d; \ for i in $$a/*; \ There is a small chance that with high parallelization the wildcard expansion in the last line will occur for $$a == lib2to3 before creation of pickles has finished, resulting in not installation of pickles. The solution would be to move creation of pickles to a separate target and make it a dependency of libinstall target. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 01:07:56 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 01 Sep 2012 23:07:56 +0000 Subject: [issue15645] 2to3 Grammar pickles not created when upgrading to 3.3.0b2 In-Reply-To: <1344932180.41.0.826216341416.issue15645@psf.upfronthosting.co.za> Message-ID: <1346540876.17.0.275936868777.issue15645@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: I meant $$d == lib2to3 and $$a == $(srcdir)/Lib/lib2to3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 02:53:25 2012 From: report at bugs.python.org (Daniel Swanson) Date: Sun, 02 Sep 2012 00:53:25 +0000 Subject: [issue15844] weird import errors Message-ID: <1346547205.78.0.590339633235.issue15844@psf.upfronthosting.co.za> New submission from Daniel Swanson: I'm dealing with a bunch of nested folders and my imports have gone crazy. When I try to test one of the lower level scripts that imports one of the higher level one it gives me an error message. But, when I run the top one, (which cascadingly imports just about everything) it doesn't. And now I've got one trying to import something on the same level and it says it doesn't exist! This happens whenever I try to use folders, because of this, I only have one file of programs. ---------- components: None messages: 169680 nosy: weirdink13 priority: normal severity: normal status: open title: weird import errors type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 03:16:27 2012 From: report at bugs.python.org (Daniel Swanson) Date: Sun, 02 Sep 2012 01:16:27 +0000 Subject: [issue15844] weird import errors In-Reply-To: <1346547205.78.0.590339633235.issue15844@psf.upfronthosting.co.za> Message-ID: <1346548587.17.0.52487692744.issue15844@psf.upfronthosting.co.za> Daniel Swanson added the comment: correcting self. >>> And now I've got one trying to import something on the same level and it says it doesn't exist! Should have been: And now I've got the top one importing one that's importing one on the same level and saying it doesn't exist! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 03:47:16 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 02 Sep 2012 01:47:16 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346260029.19.0.320505643782.issue15814@psf.upfronthosting.co.za> Message-ID: <1346550436.18.0.371479435017.issue15814@psf.upfronthosting.co.za> Nick Coghlan added the comment: +1 for allowing bytes hashing. As Antoine noted, the 1D bytes variant of memoryview() fills the role previously handled by buffer(). +1 for allowing 1D non-contiguous hashing. This is from a simplicity perspective, as I don't want to have to explain to people why "hash(memoryview(b'12'[::2]))", "hash(memoryview(b'123'[::2]))" and "hash(memoryview(b'12')[::2])" all work, but "hash(memoryview(b'123')[::2])" fails. -1 for allowing hashing when ndim > 1. We don't have a solid use case, and there's no odd value based corner cases to be considered. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 04:19:57 2012 From: report at bugs.python.org (Alessandro Moura) Date: Sun, 02 Sep 2012 02:19:57 +0000 Subject: [issue15845] Fixing some byte-to-string conversion warnings Message-ID: <1346552396.88.0.397419581961.issue15845@psf.upfronthosting.co.za> New submission from Alessandro Moura: This is related to issue 15826. When run with the -b option, some glob.py and os.py functions give warnings due to byte-to-string conversions: amoura at amoura-laptop:~/cpython$ ./python -b -c "import glob; glob.glob(b'cover*/glob.cover')" /home/amoura/cpython/Lib/glob.py:64: BytesWarning: Comparison between bytes and string if basename == '': amoura at amoura-laptop:~/cpython$ ./python -b -c "import os; os.makedirs(b'tst/making/dirs')" /home/amoura/cpython/Lib/os.py:266: BytesWarning: Comparison between bytes and string if tail == cdir: # xxx/newdir/. exists if xxx/newdir exists The attached patch fixes this. There is a rather more mysterious phenomenon with exceptions (which is triggered by test_exceptions for ImportException, but it happens for any Exception class): >>> e = Exception(b'aaa') [60596 refs] >>> e.args[0] b'aaa' [60601 refs] >>> str(e) __main__:1: BytesWarning: str() on a bytes instance "b'aaa'" [60615 refs] >>> e.args[0] b'aaa' [60615 refs] >>> str(e) "b'aaa'" [60615 refs] >>> e.args[0] b'aaa' [60615 refs] In other words, if a bytes argument is given to the exception, the first call to str triggers the warning, but further calls don't. Is this worth pursuing? ---------- components: Library (Lib) files: os_glob_bytes.patch keywords: patch messages: 169683 nosy: eng793 priority: normal severity: normal status: open title: Fixing some byte-to-string conversion warnings type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file27092/os_glob_bytes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 04:49:28 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 02 Sep 2012 02:49:28 +0000 Subject: [issue15844] weird import errors In-Reply-To: <1346547205.78.0.590339633235.issue15844@psf.upfronthosting.co.za> Message-ID: <1346554168.51.0.960369699733.issue15844@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Please provide a reproducable test case. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 04:52:53 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 02 Sep 2012 02:52:53 +0000 Subject: [issue15839] SystemError raised by super() in erronous class should be NameError or RuntimeError In-Reply-To: <1346508541.04.0.853072474076.issue15839@psf.upfronthosting.co.za> Message-ID: <1346554373.55.0.17342464591.issue15839@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- versions: +Python 3.4 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 05:04:47 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 02 Sep 2012 03:04:47 +0000 Subject: [issue15839] SystemError raised by super() in erronous class should be NameError or RuntimeError In-Reply-To: <1346508541.04.0.853072474076.issue15839@psf.upfronthosting.co.za> Message-ID: <3X8fL51WtczQ8t@mail.python.org> Roundup Robot added the comment: New changeset e2e4a0a49d2e by Benjamin Peterson in branch 'default': Make super() internal errors RuntimeError instead of SystemError (closes #15839) http://hg.python.org/cpython/rev/e2e4a0a49d2e ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 08:41:38 2012 From: report at bugs.python.org (Mike Hoy) Date: Sun, 02 Sep 2012 06:41:38 +0000 Subject: [issue15820] Add additional info to Resources area on Dev Guide In-Reply-To: <1346312741.02.0.319894267547.issue15820@psf.upfronthosting.co.za> Message-ID: <1346568098.97.0.663440373019.issue15820@psf.upfronthosting.co.za> Mike Hoy added the comment: >> Is the :exc:`KeyboardInterrupt` line supposed to be in there? Nope. I somehow ended up with that in my index.rst file. I am guessing I was pasting lines to use as reference and didn't delete it later. Here's patch #4. ---------- Added file: http://bugs.python.org/file27093/devguide-resources-4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 10:46:06 2012 From: report at bugs.python.org (David Halter) Date: Sun, 02 Sep 2012 08:46:06 +0000 Subject: [issue15846] literal_eval raises SystemError instead of SyntaxError, because of illegal escape sequence Message-ID: <1346575566.52.0.640732929243.issue15846@psf.upfronthosting.co.za> New submission from David Halter: Hi! I'm the developer of Jedi: https://github.com/davidhalter/jedi, which is an auto-completion library. I try to support Python 2.5-3.2. The bug just appears in Python 3.2. Parsing string literals with literal_eval works normally without a problem, but in this certain constellation, it raises a SystemError (instead of a SyntaxError). The error line is simple: literal_eval(r"'\U'") But: It only raises the error in that particular place: https://github.com/davidhalter/jedi/blob/master/parsing.py#L157 To try and test it: git clone git://github.com/davidhalter/jedi.git cd jedi # uncomment the line after TODO in parsing.Scope.add_docstr python3 test/run.py array The error message: Traceback (most recent call last): File "./run.py", line 51, in run_definition_test result = defs(line_nr, len(line)) File "./run.py", line 49, in defs return set(functions.get_definitions(source, line_nr, indent, path)) File "./functions.py", line 253, in get_definitions scopes = _prepare_goto(source, pos, source_path, f, goto_path) File "./functions.py", line 227, in _prepare_goto scopes = evaluate.follow_statement(stmt) File "./helpers.py", line 23, in __call__ if self.push_stmt(stmt): File "./helpers.py", line 31, in push_stmt self.current = RecursionNode(stmt, self.current) File "./helpers.py", line 75, in __init__ or (self.script == builtin.Builtin.scope) File "./builtin.py", line 408, in scope return self._builtins.parser.module File "./builtin.py", line 42, in parser self._load_module() File "./builtin.py", line 50, in _load_module self._parser = parsing.PyFuzzyParser(source, self.path or self.name) File "./parsing.py", line 1047, in __init__ self.parse() File "./parsing.py", line 1600, in parse stmt, tok = self._parse_statement(self.current) File "./parsing.py", line 1386, in _parse_statement self.scope.add_docstr(self.last_token[1]) File "./parsing.py", line 157, in add_docstr literal_eval(r"'\U'") File "/usr/lib/python3.2/ast.py", line 48, in literal_eval node_or_string = parse(node_or_string, mode='eval') File "/usr/lib/python3.2/ast.py", line 36, in parse return compile(source, filename, mode, PyCF_ONLY_AST) SystemError: ../Objects/tupleobject.c:126: bad argument to internal function Cheers! David ---------- messages: 169687 nosy: davidhalter priority: normal severity: normal status: open title: literal_eval raises SystemError instead of SyntaxError, because of illegal escape sequence versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 11:22:22 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 02 Sep 2012 09:22:22 +0000 Subject: [issue15846] literal_eval raises SystemError instead of SyntaxError, because of illegal escape sequence In-Reply-To: <1346575566.52.0.640732929243.issue15846@psf.upfronthosting.co.za> Message-ID: <1346577742.35.0.0369662052338.issue15846@psf.upfronthosting.co.za> Ezio Melotti added the comment: You can try to remove things until that error goes away to see what is causing the problem and/or print the values of source, filename, mode, and PyCF_ONLY_AST to see if there's anything unusual. ---------- nosy: +ezio.melotti type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 11:44:58 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 02 Sep 2012 09:44:58 +0000 Subject: [issue15846] literal_eval raises SystemError instead of SyntaxError, because of illegal escape sequence In-Reply-To: <1346575566.52.0.640732929243.issue15846@psf.upfronthosting.co.za> Message-ID: <1346579098.29.0.959557540663.issue15846@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +benjamin.peterson, brett.cannon, georg.brandl, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 12:03:27 2012 From: report at bugs.python.org (lilydjwg) Date: Sun, 02 Sep 2012 10:03:27 +0000 Subject: [issue15222] mailbox.mbox writes without empty line after each message In-Reply-To: <1340948825.65.0.977158180544.issue15222@psf.upfronthosting.co.za> Message-ID: <1346580207.75.0.705579255513.issue15222@psf.upfronthosting.co.za> lilydjwg added the comment: The last patch works fine here, thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 12:08:20 2012 From: report at bugs.python.org (Alessandro Moura) Date: Sun, 02 Sep 2012 10:08:20 +0000 Subject: [issue15841] Some StringIO and BytesIO methods can succeed after close In-Reply-To: <1346527132.85.0.102313792516.issue15841@psf.upfronthosting.co.za> Message-ID: <1346580500.15.0.774957010002.issue15841@psf.upfronthosting.co.za> Alessandro Moura added the comment: This also happens for the writable() and seekable() methods. The problem is that those methods do not check whether the buffers have been closed in stringio.c. This is fixed in the attached patch for StringIO. BytesIO should be the same, but bytesio.c is structured differently, and I still have to understand the code. I will try to do this, and then add tests for this issue - which should go in one of the mixins of test_memoryio.py, I presume. ---------- keywords: +patch nosy: +eng793 Added file: http://bugs.python.org/file27094/stringio.c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 12:41:20 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Sun, 02 Sep 2012 10:41:20 +0000 Subject: [issue15843] aifc.open expects only str or file pointer In-Reply-To: <1346538823.6.0.158703748918.issue15843@psf.upfronthosting.co.za> Message-ID: <1346582480.71.0.331430237283.issue15843@psf.upfronthosting.co.za> Petri Lehtinen added the comment: Since this problem is specific to 2.7, the offending line is actually http://hg.python.org/cpython/file/2.7/Lib/aifc.py#l344: 344 if type(f) == type(''): ---------- components: +Library (Lib) -None keywords: +easy nosy: +petri.lehtinen stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 12:43:34 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Sun, 02 Sep 2012 10:43:34 +0000 Subject: [issue14922] mailbox.Maildir.get_message() may fail when Maildir dirname is a unicode string In-Reply-To: <1337986521.77.0.280125876775.issue14922@psf.upfronthosting.co.za> Message-ID: <1346582614.31.0.863252185641.issue14922@psf.upfronthosting.co.za> Changes by Petri Lehtinen : ---------- keywords: +easy nosy: +petri.lehtinen stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 14:17:23 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 02 Sep 2012 12:17:23 +0000 Subject: [issue7652] Merge C version of decimal into py3k. In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za> Message-ID: <1346588243.94.0.985787193458.issue7652@psf.upfronthosting.co.za> Stefan Krah added the comment: My review is done. The Karatsuba function is basically a small stack machine and very hard to prove formally as far as I can see. The algorithm is cited in TAOCP and the subdivision is brute force tested for all combinations of coefficient lengths of the two input operands that are used in libmpdec (currently 256 < nwords <= 1024). ---------- assignee: -> skrah resolution: -> fixed stage: patch review -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 14:18:25 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 02 Sep 2012 12:18:25 +0000 Subject: [issue7652] Merge C version of decimal into py3k. In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za> Message-ID: <1346588305.37.0.233318638543.issue7652@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 14:44:30 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 02 Sep 2012 12:44:30 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346260029.19.0.320505643782.issue15814@psf.upfronthosting.co.za> Message-ID: <1346589870.64.0.0796562503623.issue15814@psf.upfronthosting.co.za> Stefan Krah added the comment: The totals are +11.5 :) for hashing, +1 for allowing non-contiguous and -2 for multi-dimensional. I'll update the docs soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 14:57:20 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 02 Sep 2012 12:57:20 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346260029.19.0.320505643782.issue15814@psf.upfronthosting.co.za> Message-ID: <3X8vTp6X8qzQVV@mail.python.org> Roundup Robot added the comment: New changeset 3b2597c1fe35 by Stefan Krah in branch 'default': Issue #15814: Documentation: disallow hashing of multi-dimensional memoryviews. http://hg.python.org/cpython/rev/3b2597c1fe35 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 15:12:15 2012 From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=) Date: Sun, 02 Sep 2012 13:12:15 +0000 Subject: [issue15847] parse_args stopped accepting tuples Message-ID: <1346591535.01.0.313863035332.issue15847@psf.upfronthosting.co.za> New submission from Zbyszek J?drzejewski-Szmek: After recent change (78307 '#13922: argparse no longer incorrectly strips '--' after the first one.'), parse_args stopped working with a tuple argument. It is easy to pass tuple to argparse by using positional function arguments: def f(*args): parser.parse_args(args) This will fail, because args is a tuple. It is necessary to have at least one positional argument to trigger the bug. ---------- components: Library (Lib) files: argparse_parse_args_tuple.diff keywords: patch messages: 169695 nosy: bethard, r.david.murray, zbysz priority: normal severity: normal status: open title: parse_args stopped accepting tuples type: behavior versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file27095/argparse_parse_args_tuple.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 15:42:18 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 02 Sep 2012 13:42:18 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1346593338.06.0.717427531595.issue15831@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Something to be aware of that may or may not affect the patch I'm preparing: One reason that Sphinx seems able to render some of the more complicated function signatures is that it has logic to bail and print the parameter list verbatim from the reST file whenever its record-keeping logic becomes internally inconsistent: except IndexError: # if there are too few or too many elements on the stack, just give up # and treat the whole argument list as one argument, discarding the # already partially populated paramlist node https://bitbucket.org/birkenfeld/sphinx/src/1f3a2749df39/sphinx/domains/python.py#cl-74 This seems to come into play, for example, when rendering-- sorted(iterable[, key][, reverse]) http://docs.python.org/dev/library/functions.html#sorted ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 15:47:19 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 02 Sep 2012 13:47:19 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1346593639.85.0.102526433053.issue15831@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Here are a couple functions that may need a fix different from multiple signatures: print([object, ...], *, sep=' ', end='\n', file=sys.stdout, flush=False) http://docs.python.org/dev/library/functions.html#print class argparse.ArgumentParser([description][, epilog][, prog][, usage][, add_help][, argument_default][, parents][, prefix_chars][, conflict_handler][, formatter_class]) http://docs.python.org/dev/library/argparse.html#argparse.ArgumentParser ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 16:01:20 2012 From: report at bugs.python.org (Alessandro Moura) Date: Sun, 02 Sep 2012 14:01:20 +0000 Subject: [issue15841] Some StringIO and BytesIO methods can succeed after close In-Reply-To: <1346527132.85.0.102313792516.issue15841@psf.upfronthosting.co.za> Message-ID: <1346594480.23.0.738264368256.issue15841@psf.upfronthosting.co.za> Alessandro Moura added the comment: Here is the patch fixing the issue in both StringIO and BytesIO. In both cases, the problem is that in their respective c files, these methods always returned true, without testing whether the file was closed. Is this a recent rewrite? I am surprised this did not bite someone earlier. I also added a testcase to test_memoryio.py covering this issue; and I added the docstring for these methods, which were missing. This patch compiles and passes the entire test suite in my system. ---------- Added file: http://bugs.python.org/file27096/memio.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 16:08:32 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 02 Sep 2012 14:08:32 +0000 Subject: [issue15841] Some StringIO and BytesIO methods can succeed after close In-Reply-To: <1346527132.85.0.102313792516.issue15841@psf.upfronthosting.co.za> Message-ID: <1346594912.72.0.830375550999.issue15841@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ah, there's a misunderstanding. The methods should raise ValueError when the object has been closed. See issue15840 for reference. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 16:21:49 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 02 Sep 2012 14:21:49 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346589870.64.0.0796562503623.issue15814@psf.upfronthosting.co.za> Message-ID: <8E6973A6-3FB4-4964-9F10-757D810B9351@gmail.com> Alexander Belopolsky added the comment: On Sep 2, 2012, at 8:44 AM, Stefan Krah wrote: > The totals are +11.5 :) for hashing, +1 for allowing non-contiguous and > -2 for multi-dimensional I have refrained from voting because in my line of work buffers or memoryviews deal with large objects that rarely serve as dictionary keys. As a result, I have zero experince with hashing of buffers. This observation supports the current consensus to limit hashing to 1d and 0d cases. My only concern is that with hash(m) == hash(m.tobytes()) implementing multidimensional restriction will require artificial if ndim > 1 check and an extra sentence in the docs while not simplifying anything. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 16:29:27 2012 From: report at bugs.python.org (Robin Schreiber) Date: Sun, 02 Sep 2012 14:29:27 +0000 Subject: [issue15848] PEP 3121, 384 Refactoring applied to xxsubtype module Message-ID: <1346596167.75.0.401355088857.issue15848@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the xxsubtype module! ---------- components: Extension Modules files: xxsubtype_pep3121-384_v0.patch keywords: patch messages: 169701 nosy: Robin.Schreiber, belopolsky priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to xxsubtype module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file27097/xxsubtype_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 16:32:33 2012 From: report at bugs.python.org (Robin Schreiber) Date: Sun, 02 Sep 2012 14:32:33 +0000 Subject: [issue15849] PEP 3121, 384 Refactoring applied to xx module Message-ID: <1346596353.57.0.974507844943.issue15849@psf.upfronthosting.co.za> New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the xx module! ---------- components: Extension Modules files: xxmodule_pep3121-384_v0.patch keywords: patch messages: 169702 nosy: Robin.Schreiber, belopolsky priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to xx module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file27098/xxmodule_pep3121-384_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 16:42:34 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 02 Sep 2012 14:42:34 +0000 Subject: [issue15847] parse_args stopped accepting tuples In-Reply-To: <1346591535.01.0.313863035332.issue15847@psf.upfronthosting.co.za> Message-ID: <1346596954.09.0.523005126042.issue15847@psf.upfronthosting.co.za> R. David Murray added the comment: I wonder if this is problematic enough that it should be treated as a regression and fixed in the next RC? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 16:44:20 2012 From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=) Date: Sun, 02 Sep 2012 14:44:20 +0000 Subject: [issue15847] parse_args stopped accepting tuples In-Reply-To: <1346596954.09.0.523005126042.issue15847@psf.upfronthosting.co.za> Message-ID: <20120902144419.GD25693@in.waw.pl> Zbyszek J?drzejewski-Szmek added the comment: On Sun, Sep 02, 2012 at 02:42:34PM +0000, R. David Murray wrote: > > R. David Murray added the comment: > > I wonder if this is problematic enough that it should be treated as a regression and fixed in the next RC? I believe yes, because I've already hit it in two different projects. It is also causes susceptible programs to fail completely. Zbyszek ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 16:47:45 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 02 Sep 2012 14:47:45 +0000 Subject: [issue15847] parse_args stopped accepting tuples In-Reply-To: <1346591535.01.0.313863035332.issue15847@psf.upfronthosting.co.za> Message-ID: <1346597265.89.0.0765918703204.issue15847@psf.upfronthosting.co.za> R. David Murray added the comment: Let's see what Georg thinks. ---------- nosy: +benjamin.peterson, georg.brandl priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 17:01:50 2012 From: report at bugs.python.org (Berker Peksag) Date: Sun, 02 Sep 2012 15:01:50 +0000 Subject: [issue15843] aifc.open expects only str or file pointer In-Reply-To: <1346538823.6.0.158703748918.issue15843@psf.upfronthosting.co.za> Message-ID: <1346598110.14.0.8573383013.issue15843@psf.upfronthosting.co.za> Berker Peksag added the comment: I've attached a patch with a test case. ---------- keywords: +patch nosy: +berker.peksag Added file: http://bugs.python.org/file27099/issue15843.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 18:25:55 2012 From: report at bugs.python.org (Varun Masuraha) Date: Sun, 02 Sep 2012 16:25:55 +0000 Subject: [issue15850] list.count() results wrong if both booleans & 1's/0's are present in the list Message-ID: <1346603155.58.0.703735136333.issue15850@psf.upfronthosting.co.za> New submission from Varun Masuraha: setup: >>>myList=[1,True,'blah blah'] >>>print(myList.count(1)) Actual result: 2 Expected: 1 ---------- messages: 169707 nosy: varun_masuraha priority: normal severity: normal status: open title: list.count() results wrong if both booleans & 1's/0's are present in the list type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 18:30:43 2012 From: report at bugs.python.org (Alex Gaynor) Date: Sun, 02 Sep 2012 16:30:43 +0000 Subject: [issue15850] list.count() results wrong if both booleans & 1's/0's are present in the list In-Reply-To: <1346603155.58.0.703735136333.issue15850@psf.upfronthosting.co.za> Message-ID: <1346603443.94.0.489700001511.issue15850@psf.upfronthosting.co.za> Alex Gaynor added the comment: list.count() uses == to compare items, 1 and True compare equal, so this behavior is correct. ---------- nosy: +alex resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 18:36:58 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 02 Sep 2012 16:36:58 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1346603818.09.0.309047880371.issue15831@psf.upfronthosting.co.za> Chris Jerdonek added the comment: FWIW, I submitted a patch for the Sphinx issue I created: https://bitbucket.org/birkenfeld/sphinx/issue/1001 Ironically, that patch was probably easier than this patch will be. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 18:45:52 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 02 Sep 2012 16:45:52 +0000 Subject: [issue15840] Ambiguity with regard to the effect of accessing a closed IOBase instance In-Reply-To: <1346524424.76.0.407141547435.issue15840@psf.upfronthosting.co.za> Message-ID: <1346604352.11.0.606266153701.issue15840@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 19:37:55 2012 From: report at bugs.python.org (Steven Bethard) Date: Sun, 02 Sep 2012 17:37:55 +0000 Subject: [issue15847] parse_args stopped accepting tuples In-Reply-To: <1346591535.01.0.313863035332.issue15847@psf.upfronthosting.co.za> Message-ID: <1346607475.11.0.155620163732.issue15847@psf.upfronthosting.co.za> Steven Bethard added the comment: The fix looks about right to me. There's a bug in the tests though: parser.parse_args(('x')) should probably be: parser.parse_args(('x',)) since I assume the intent was to test tuples. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 19:57:43 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 02 Sep 2012 17:57:43 +0000 Subject: [issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0 In-Reply-To: <1344473974.14.0.584788696764.issue15599@psf.upfronthosting.co.za> Message-ID: <1346608663.67.0.371858322787.issue15599@psf.upfronthosting.co.za> Stefan Krah added the comment: One of the Windows bots has the same failure in test_parallel_meta_path: http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/5643/steps/test/logs/stdio ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 19:58:45 2012 From: report at bugs.python.org (Christophe Guillon) Date: Sun, 02 Sep 2012 17:58:45 +0000 Subject: [issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse) In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za> Message-ID: <1346608725.55.0.443462171772.issue9334@psf.upfronthosting.co.za> Christophe Guillon added the comment: As a workaround for this missing feature, the negative number matching regexp can be used for allowing arguments starting with '-' in arguments of option flags. We basically do: parser = argparse.ArgumentParser(...) parser._negative_number_matcher = re.compile(r'^-.+$') This allow cases such as @andersk: $ a2x --asciidoc-opts --safe gitcli.txt where '--safe' is an argument to '--asciidoc-opts' As this behavioral change is quite simple, couldn't the requested feature be implemented like this with an optional setting to the ArgumentParser contructor? ---------- nosy: +Christophe.Guillon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 20:02:48 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 02 Sep 2012 18:02:48 +0000 Subject: [issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0 In-Reply-To: <1344473974.14.0.584788696764.issue15599@psf.upfronthosting.co.za> Message-ID: <1346608968.18.0.068431661924.issue15599@psf.upfronthosting.co.za> Stefan Krah added the comment: I'm convinced now that some systems just can't handle a low switch interval gracefully. Look at: http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/5642/steps/test/logs/stdio ====================================================================== FAIL: test_pending_calls_race (test.test_concurrent_futures.ThreadPoolWaitTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_concurrent_futures.py", line 71, in tearDown self.assertLess(dt, 60, "synchronization issue: test lasted too long") AssertionError: 152.02985382080078 not less than 60 : synchronization issue: test lasted too long ---------------------------------------------------------------------- That test also uses sys.setswitchinterval(1e-6). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 20:05:53 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 02 Sep 2012 18:05:53 +0000 Subject: [issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0 In-Reply-To: <1346608968.18.0.068431661924.issue15599@psf.upfronthosting.co.za> Message-ID: <1346608930.3394.1.camel@localhost.localdomain> Antoine Pitrou added the comment: > I'm convinced now that some systems just can't handle a low switch > interval gracefully. Look at: [...] > > That test also uses sys.setswitchinterval(1e-6). Ok, let's bump it to 1e-5 then. As for the parallel_meta_path failure, it could be a genuine issue (albeit a rather unimportant one; I originally added those tests out of completion). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 20:22:03 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Sun, 02 Sep 2012 18:22:03 +0000 Subject: [issue15843] aifc.open expects only str or file pointer In-Reply-To: <1346538823.6.0.158703748918.issue15843@psf.upfronthosting.co.za> Message-ID: <1346610123.86.0.921470262009.issue15843@psf.upfronthosting.co.za> Petri Lehtinen added the comment: My fellow coredevs confirm that this would be a new feature, so it's out of scope for 2.7 (which is in bugfix-only mode). It's also deterministic in the sense that you can easily work around it by encoding the unicode filename to the filesystem encoding first. Closing as wontfix. ---------- resolution: -> wont fix stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 20:23:43 2012 From: report at bugs.python.org (Varun Masuraha) Date: Sun, 02 Sep 2012 18:23:43 +0000 Subject: [issue15850] list.count() results wrong if both booleans & 1's/0's are present in the list In-Reply-To: <1346603155.58.0.703735136333.issue15850@psf.upfronthosting.co.za> Message-ID: <1346610223.7.0.054398965133.issue15850@psf.upfronthosting.co.za> Varun Masuraha added the comment: Thanks Alex for the reply, Although Booleans & Integers may not be very practical in same list (or tuple, etc.) & the fact that bool is subclass of int, still I feel that the search implementation (count, index, etc.) is too simple in that matter. Comparing both Value AND Data type while searching, looks more exact to me... regards, Varun ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 20:25:25 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 02 Sep 2012 18:25:25 +0000 Subject: [issue15846] literal_eval raises SystemError instead of SyntaxError, because of illegal escape sequence In-Reply-To: <1346575566.52.0.640732929243.issue15846@psf.upfronthosting.co.za> Message-ID: <3X92mN1qCQzQL9@mail.python.org> Roundup Robot added the comment: New changeset 0db75a55145a by Benjamin Peterson in branch '3.2': prevert ast errors from being normalized before ast_error_finish is called (closes #15846) http://hg.python.org/cpython/rev/0db75a55145a New changeset d61424122af5 by Benjamin Peterson in branch 'default': merge 3.2 (#15846) http://hg.python.org/cpython/rev/d61424122af5 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 20:36:04 2012 From: report at bugs.python.org (=?utf-8?q?Eduardo_A=2E_Bustamante_L=C3=B3pez?=) Date: Sun, 02 Sep 2012 18:36:04 +0000 Subject: [issue15851] Lib/robotparser.py doesn't accept setting a user agent string, instead it uses the default. Message-ID: <1346610964.7.0.836759738208.issue15851@psf.upfronthosting.co.za> New submission from Eduardo A. Bustamante L?pez: I found that http://en.wikipedia.org/robots.txt returns 403 if the provided user agent is in a specific blacklist. And since robotparser doesn't provide a mechanism to change the default user agent used by the opener, it becomes unusable for that site (and sites that have a similar policy). I think the user should have the possibility to set a specific user agent string, to better identify their bot. I attach a patch that allows the user to change the opener used by RobotFileParser, in case the need of some specific behavior arises. I also attach a simple example of how it solves the issue, at least with wikipedia. ---------- components: Library (Lib) files: robotparser.py.diff keywords: patch messages: 169718 nosy: Eduardo.A..Bustamante.L?pez priority: normal severity: normal status: open title: Lib/robotparser.py doesn't accept setting a user agent string, instead it uses the default. type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file27100/robotparser.py.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 20:40:21 2012 From: report at bugs.python.org (=?utf-8?q?Eduardo_A=2E_Bustamante_L=C3=B3pez?=) Date: Sun, 02 Sep 2012 18:40:21 +0000 Subject: [issue15851] Lib/robotparser.py doesn't accept setting a user agent string, instead it uses the default. In-Reply-To: <1346610964.7.0.836759738208.issue15851@psf.upfronthosting.co.za> Message-ID: <1346611221.67.0.905329783952.issue15851@psf.upfronthosting.co.za> Changes by Eduardo A. Bustamante L?pez : Added file: http://bugs.python.org/file27101/myrobotparser.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 21:17:08 2012 From: report at bugs.python.org (Alessandro Moura) Date: Sun, 02 Sep 2012 19:17:08 +0000 Subject: [issue15841] Some StringIO and BytesIO methods can succeed after close In-Reply-To: <1346527132.85.0.102313792516.issue15841@psf.upfronthosting.co.za> Message-ID: <1346613428.56.0.903153293244.issue15841@psf.upfronthosting.co.za> Alessandro Moura added the comment: Sorry, I should have seen the related issue (or just read the docs :)). Here is the patch fixing these issues, implementing the behaviour stated in the docs (raising ValueError after close). The tests revealed that the _pyio module also needed fixing, and this is done in the patch as well. ---------- Added file: http://bugs.python.org/file27102/memoryio.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 22:07:34 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 02 Sep 2012 20:07:34 +0000 Subject: [issue15753] No-argument super in method with variable arguments raises SystemError In-Reply-To: <1345549960.82.0.102703520127.issue15753@psf.upfronthosting.co.za> Message-ID: <1346616454.36.0.846940117567.issue15753@psf.upfronthosting.co.za> Andrew Svetlov added the comment: BTW see #15839: super now raises RuntimeError. After that I revoke my objection for exception type changing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 22:26:09 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 02 Sep 2012 20:26:09 +0000 Subject: [issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0 In-Reply-To: <1344473974.14.0.584788696764.issue15599@psf.upfronthosting.co.za> Message-ID: <1346617569.39.0.795953401441.issue15599@psf.upfronthosting.co.za> Stefan Krah added the comment: The Lion bot also hangs in test_threading: http://buildbot.python.org/all/builders/AMD64%20Lion%203.x/builds/383/steps/test/logs/stdio At least the test_threading failures seem to be recent. The test_threaded_import *slowness* (40 min!) on FreeBSD/KVM with low switch interval goes back a long way. I checked revisions way before importlib was bootstrapped. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 22:51:52 2012 From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=) Date: Sun, 02 Sep 2012 20:51:52 +0000 Subject: [issue15847] parse_args stopped accepting tuples In-Reply-To: <1346591535.01.0.313863035332.issue15847@psf.upfronthosting.co.za> Message-ID: <1346619112.42.0.719978770003.issue15847@psf.upfronthosting.co.za> Changes by Zbyszek J?drzejewski-Szmek : Added file: http://bugs.python.org/file27103/argparse_parse_args_tuple.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 22:52:16 2012 From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=) Date: Sun, 02 Sep 2012 20:52:16 +0000 Subject: [issue15847] parse_args stopped accepting tuples In-Reply-To: <1346591535.01.0.313863035332.issue15847@psf.upfronthosting.co.za> Message-ID: <1346619136.79.0.930184746174.issue15847@psf.upfronthosting.co.za> Changes by Zbyszek J?drzejewski-Szmek : Removed file: http://bugs.python.org/file27095/argparse_parse_args_tuple.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 22:52:39 2012 From: report at bugs.python.org (=?utf-8?q?Eduardo_A=2E_Bustamante_L=C3=B3pez?=) Date: Sun, 02 Sep 2012 20:52:39 +0000 Subject: [issue15851] Lib/robotparser.py doesn't accept setting a user agent string, instead it uses the default. In-Reply-To: <1346610964.7.0.836759738208.issue15851@psf.upfronthosting.co.za> Message-ID: <1346619159.71.0.324423617099.issue15851@psf.upfronthosting.co.za> Eduardo A. Bustamante L?pez added the comment: I guess a workaround is to do: robotparser.URLopener.version = 'MyVersion' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 22:52:53 2012 From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=) Date: Sun, 02 Sep 2012 20:52:53 +0000 Subject: [issue15847] parse_args stopped accepting tuples In-Reply-To: <1346591535.01.0.313863035332.issue15847@psf.upfronthosting.co.za> Message-ID: <1346619173.15.0.0557086090572.issue15847@psf.upfronthosting.co.za> Zbyszek J?drzejewski-Szmek added the comment: Thanks for noticing. Replaced patch with the ('x') -> ('x',) bugfix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 23:13:18 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 02 Sep 2012 21:13:18 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1346620398.54.0.168179892827.issue15533@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Maybe better to check cwd in _call_popen_and_assert for child process (like test_cwd does) instead of just checking for successful child execution? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 2 23:41:42 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 02 Sep 2012 21:41:42 +0000 Subject: [issue15852] typos in curses argument error messages Message-ID: <1346622102.83.0.795568790125.issue15852@psf.upfronthosting.co.za> New submission from Chris Jerdonek: It seems like a couple error messages in the curses module need correcting: PyErr_SetString(PyExc_TypeError, "insch requires 1 or 4 arguments"); http://hg.python.org/cpython/file/8ff2f4634ed8/Modules/_cursesmodule.c#l1322 PyErr_SetString(PyExc_TypeError, "instr requires 0 or 3 arguments"); http://hg.python.org/cpython/file/8ff2f4634ed8/Modules/_cursesmodule.c#l1385 In both cases, "or" should be "to". ---------- components: Library (Lib) keywords: easy messages: 169725 nosy: cjerdonek priority: normal severity: normal stage: test needed status: open title: typos in curses argument error messages type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 00:33:54 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 02 Sep 2012 22:33:54 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1346625234.47.0.909901441507.issue15831@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attaching a proposed patch for the default branch. Also, here are several comments and questions. > I think/hope that all the APIs we have in the stdlib are sane enough to have no more than 2-3 signatures I found this one in the curses module with four: window.chgat(attr) window.chgat(num, attr) window.chgat(y, x, attr) window.chgat(y, x, num, attr) Do we like how these look? Is the bare star notation too obscure? inspect.Signature.replace(*[, parameters][, return_annotation]) inspect.Parameter.replace(*[, name][, kind][, default][, annotation]) I was curious what the preferred way to display the following is, since I don't think any comma/bracket placement will work: ArgumentParser([description][, epilog][, prog][, usage][, add_help][, argument_default][, parents][, prefix_chars][, conflict_handler][, formatter_class]) (unless perhaps we use the construction "ArgumentParser(*[, description][, epilog]....") I'm not sure how we want to handle this one using multiple signatures: multiprocessing.Process([group[, target[, name[, args[, kwargs]]]]], *, daemon=None) I put my preferred rendering in the patch, but Sphinx re-renders it in its own way. I also noticed these more unusual signatures: urllib.request.urlopen(url, data=None[, timeout], *, cafile=None, capath=None, cadefault=True) http.client.HTTPSConnection(host, port=None, key_file=None, cert_file=None[, strict[, timeout[, source_address]]], *, context=None, check_hostname=None) By the way, is the * really necessary in these examples? ---------- keywords: +needs review, patch stage: needs patch -> patch review Added file: http://bugs.python.org/file27104/issue-15831-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 00:47:49 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 02 Sep 2012 22:47:49 +0000 Subject: [issue15787] PEP 3121 Refactoring In-Reply-To: <1346038565.61.0.980658052428.issue15787@psf.upfronthosting.co.za> Message-ID: <1346626069.13.0.904695612155.issue15787@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- dependencies: +PEP 3121, 384 Refactoring applied to xx module, PEP 3121, 384 Refactoring applied to xxsubtype module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 01:12:12 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 02 Sep 2012 23:12:12 +0000 Subject: [issue15852] typos in curses argument error messages In-Reply-To: <1346622102.83.0.795568790125.issue15852@psf.upfronthosting.co.za> Message-ID: <1346627532.33.0.428534836534.issue15852@psf.upfronthosting.co.za> R. David Murray added the comment: Given their signatures in the docs, I suspect it is more complicated than that. Perhaps the error messages are even correct. What does the code implement? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 01:12:13 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 02 Sep 2012 23:12:13 +0000 Subject: [issue15849] PEP 3121, 384 Refactoring applied to xx module In-Reply-To: <1346596353.57.0.974507844943.issue15849@psf.upfronthosting.co.za> Message-ID: <1346627533.87.0.669227234698.issue15849@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: xxmodule.c is used as an example in PEP 3121 itself. To the extent the recipe in the PEP is complete, the changes to actual xxmodule.c should follow the text. For example, the text in PEP recommends to leave m_free member of PyModuleDef 0: static struct PyModuleDef xxmodule = { {}, /* m_base */ sizeof(struct xxstate), &xx_methods, 0, /* m_reload */ xx_traverse, xx_clear, 0, /* m_free - not needed, since all is done in m_clear */ } In your patch, member names are not shown in the initializer. The PEP text also omits them when it is obvious from the value. (xx_clear initializes m_clear.) I think all lines in the initializer should include the member name in comments. The reason is that people will use xxmodule.c as a template for their code and may want to replace xx_clear with something that is not as suggestive. You should add some tests demonstrating that module load/unload cycles do not introduce reference leaks. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 01:24:44 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 02 Sep 2012 23:24:44 +0000 Subject: [issue15852] typos in curses argument error messages In-Reply-To: <1346622102.83.0.795568790125.issue15852@psf.upfronthosting.co.za> Message-ID: <1346628284.08.0.369083593891.issue15852@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I just completed a patch to improve the documentation of these signatures (along with many others) in issue 15831. The correction here is consistent with my findings and revised documentation there. As for the code, they are straightforward switch statements similar to many of the other methods in that module. I also did a manual test on one of the methods as a sanity check. I am preparing unit tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 01:28:48 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 02 Sep 2012 23:28:48 +0000 Subject: [issue15852] typos in curses argument error messages In-Reply-To: <1346622102.83.0.795568790125.issue15852@psf.upfronthosting.co.za> Message-ID: <1346628528.93.0.458943704522.issue15852@psf.upfronthosting.co.za> Chris Jerdonek added the comment: The situation is the same in 2.7 (and probably 3.2). ---------- versions: +Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 01:37:12 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 02 Sep 2012 23:37:12 +0000 Subject: [issue15849] PEP 3121, 384 Refactoring applied to xx module In-Reply-To: <1346596353.57.0.974507844943.issue15849@psf.upfronthosting.co.za> Message-ID: <1346629032.47.0.617042779766.issue15849@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: +#define xx_state_global + ((xxstate *)PyModule_GetState(PyState_FindModule(&xxmodule))) This is unsafe: PyState_FindModule(&xxmodule) can return NULL. I think code should account for this possibility and not use this macro. For example, XxoObject_Check(v) should be defined as (PyState_FindModule(&xxmodule) == NULL ? 0 : \ (Py_TYPE(v) == xx_state(PyState_FindModule(&xxmodule))->Xxo_Type)) (Should this also check PyModule_GetState() return?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 02:27:22 2012 From: report at bugs.python.org (David Pietz) Date: Mon, 03 Sep 2012 00:27:22 +0000 Subject: [issue15853] Idle "quit unexpectedly" w/ attempted edit of preferences Message-ID: <1346632042.85.0.745944196118.issue15853@psf.upfronthosting.co.za> New submission from David Pietz: Currently I am trying to edit idle preferences so I can edit a script which appends a log of Idle activity that I may review for study purposes. I could not really interpret much of the crash logs in console but there seem to be two types of memory errors. I have also seen a variety of situations crash Idle and it is hampering my study as my text uses 3.x not the installed 2.x on my Macbook Pro. As I saw an issue track mentioning os x 10.6, I upgraded to Mountain Lion, os x 10.8 but the behavior is the same. This is my first post. ---------- messages: 169732 nosy: David.Pietz priority: normal severity: normal status: open title: Idle "quit unexpectedly" w/ attempted edit of preferences type: crash versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 02:34:19 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 03 Sep 2012 00:34:19 +0000 Subject: [issue15853] Idle "quit unexpectedly" w/ attempted edit of preferences In-Reply-To: <1346632042.85.0.745944196118.issue15853@psf.upfronthosting.co.za> Message-ID: <1346632459.64.0.388519188971.issue15853@psf.upfronthosting.co.za> R. David Murray added the comment: Can you report a specific error and a recipe to reproduce it? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 02:39:54 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 03 Sep 2012 00:39:54 +0000 Subject: [issue15854] curses test_curses test_unget_wch Message-ID: <1346632794.75.0.136590838621.issue15854@psf.upfronthosting.co.za> New submission from Chris Jerdonek: As of: changeset: 78843:8ff2f4634ed8 date: Sun Sep 02 16:37:09 2012 -0400 I am getting this failure: $ ./python.exe -m test -v -u curses test_curses == CPython 3.3.0rc1+ (default:8ff2f4634ed8, Sep 2 2012, 16:02:43) [GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.58)] == Darwin-11.4.0-x86_64-i386-64bit little-endian == .../build/test_python_17427 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1) [1/1] test_curses test test_curses crashed -- Traceback (most recent call last): File ".../Lib/test/regrtest.py", line 1221, in runtest_inner test_runner() File ".../Lib/test/test_curses.py", line 336, in test_main main(stdscr) File ".../Lib/test/test_curses.py", line 322, in main test_unget_wch(stdscr) File ".../Lib/test/test_curses.py", line 283, in test_unget_wch raise AssertionError("%r != %r" % (read, ch)) AssertionError: -61 != '?' Looks like this may be related to issue 15785. ---------- components: Library (Lib) messages: 169734 nosy: cjerdonek priority: normal severity: normal status: open title: curses test_curses test_unget_wch type: crash versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 02:40:35 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 03 Sep 2012 00:40:35 +0000 Subject: [issue15854] curses test_curses.test_unget_wch crash In-Reply-To: <1346632794.75.0.136590838621.issue15854@psf.upfronthosting.co.za> Message-ID: <1346632835.15.0.396874822631.issue15854@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- title: curses test_curses test_unget_wch -> curses test_curses.test_unget_wch crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 03:46:46 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 03 Sep 2012 01:46:46 +0000 Subject: [issue15845] Fixing some byte-to-string conversion warnings In-Reply-To: <1346552396.88.0.397419581961.issue15845@psf.upfronthosting.co.za> Message-ID: <1346636806.98.0.345903780822.issue15845@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Not repeating warnings from the same place is the default warning behavior. You can get all of them by passing -Wall. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 04:06:18 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 03 Sep 2012 02:06:18 +0000 Subject: [issue15852] typos in curses argument error messages In-Reply-To: <1346622102.83.0.795568790125.issue15852@psf.upfronthosting.co.za> Message-ID: <1346637978.06.0.881102680728.issue15852@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attaching a patch with tests and fix for the default branch. ---------- keywords: +patch Added file: http://bugs.python.org/file27105/issue-15831-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 04:06:35 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 03 Sep 2012 02:06:35 +0000 Subject: [issue15852] typos in curses argument error messages In-Reply-To: <1346622102.83.0.795568790125.issue15852@psf.upfronthosting.co.za> Message-ID: <1346637995.98.0.685472700842.issue15852@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- keywords: +needs review stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 04:08:38 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 03 Sep 2012 02:08:38 +0000 Subject: [issue15852] typos in curses argument error messages In-Reply-To: <1346622102.83.0.795568790125.issue15852@psf.upfronthosting.co.za> Message-ID: <1346638118.61.0.491203752783.issue15852@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Uploading correct file. ---------- Added file: http://bugs.python.org/file27106/issue-15852-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 04:10:16 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 03 Sep 2012 02:10:16 +0000 Subject: [issue15852] typos in curses argument error messages In-Reply-To: <1346622102.83.0.795568790125.issue15852@psf.upfronthosting.co.za> Message-ID: <1346638216.12.0.226317480341.issue15852@psf.upfronthosting.co.za> Changes by Chris Jerdonek : Removed file: http://bugs.python.org/file27105/issue-15831-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 04:45:46 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 03 Sep 2012 02:45:46 +0000 Subject: [issue15557] Tests for webbrowser module In-Reply-To: <1344102778.31.0.864118033074.issue15557@psf.upfronthosting.co.za> Message-ID: <1346640346.87.0.845518211751.issue15557@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Anton. I took your last patch just a bit further, mostly to make it easy to break up the test methods that test multiple things into test methods that test just one thing. I also made the test insensitive to the order of the options on the command line, since in theory that shouldn't matter (this makes the tests more robust in the face of changes to the code). I'm pretty sure I transcribed all the tests correctly, but it would be great if you would double check me. ---------- Added file: http://bugs.python.org/file27107/test_webbrowser.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 06:27:24 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 03 Sep 2012 04:27:24 +0000 Subject: [issue15844] weird import errors In-Reply-To: <1346547205.78.0.590339633235.issue15844@psf.upfronthosting.co.za> Message-ID: <1346646444.57.0.0734362116488.issue15844@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 06:28:46 2012 From: report at bugs.python.org (Ned Deily) Date: Mon, 03 Sep 2012 04:28:46 +0000 Subject: [issue15853] IDLE crashes selecting Preferences menu with OS X ActiveState Tcl/Tk 8.5.12.1 In-Reply-To: <1346632042.85.0.745944196118.issue15853@psf.upfronthosting.co.za> Message-ID: <1346646526.01.0.928405738196.issue15853@psf.upfronthosting.co.za> Ned Deily added the comment: The crash on opening Preferences is an unresolved regression with OS X ActiveTcl 8.5.12.1, the current ActiveTcl Community Edition, that causes Tk to crash when selecting the IDLE Preferences.. command. The regression was also in ActiveState 8.5.12 but not in 8.5.11.1. The crash appears to be related to the Tk crash-on-copy problem documented in Issue15574. Until the problem is resolved, if you have access to ActiveTcl 8.5.11.1 (ActiveState only makes the most recent version available to Community Edition users), you can install that. Otherwise, you could either temporarily "deactivate" the ActiveState Tk by renaming it, for example, after quitting IDLE: sudo mv /Library/Frameworks/Tk.framework /Library/Frameworks/Tk_disabled This will revert to the Apple-supplied system Tk, which has some critical bugs in 10.8 Mountain Lion (it's totally unusable for IDLE in 10.6) but might be OK for your usage or, at least, for updating Preferences. To "reactivate" ActiveTk, rename it back: sudo mv /Library/Frameworks/Tk_disabled /Library/Frameworks/Tk.framework Once you've made some preferences changes, it is also possible to manually edit the configuration files created in ~/.idlerc. I will update this issue with a cross-reference to an Tcl/Tk issue when available. ---------- assignee: -> ned.deily components: +IDLE, Macintosh nosy: +ned.deily title: Idle "quit unexpectedly" w/ attempted edit of preferences -> IDLE crashes selecting Preferences menu with OS X ActiveState Tcl/Tk 8.5.12.1 versions: +Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 06:39:53 2012 From: report at bugs.python.org (Ned Deily) Date: Mon, 03 Sep 2012 04:39:53 +0000 Subject: [issue15854] curses test_curses.test_unget_wch crash In-Reply-To: <1346632794.75.0.136590838621.issue15854@psf.upfronthosting.co.za> Message-ID: <1346647193.98.0.0637054847126.issue15854@psf.upfronthosting.co.za> Ned Deily added the comment: This is a duplicate of Issue15037. test_unget_wch fails when linked with ncurses versions earlier than 5.8, which is the case with the Apple-supplied versions of ncurses in OS X versions through 10.8. (The python.org OS X installers for Python 3.3.x link with their own copy of libncursesw 5.9 to avoid this problem.) ---------- nosy: +ned.deily resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> curses.unget_wch and test_curses fail when linked with ncurses 5.7 and earlier type: crash -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 06:44:41 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 03 Sep 2012 04:44:41 +0000 Subject: [issue15854] curses test_curses.test_unget_wch crash In-Reply-To: <1346632794.75.0.136590838621.issue15854@psf.upfronthosting.co.za> Message-ID: <1346647481.66.0.26423827894.issue15854@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Okay, thanks, Ned. Out of curiosity, why is the stack trace here different from the one posted on that issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 06:57:37 2012 From: report at bugs.python.org (Ned Deily) Date: Mon, 03 Sep 2012 04:57:37 +0000 Subject: [issue15854] curses test_curses.test_unget_wch crash In-Reply-To: <1346632794.75.0.136590838621.issue15854@psf.upfronthosting.co.za> Message-ID: <1346648257.98.0.60504947601.issue15854@psf.upfronthosting.co.za> Ned Deily added the comment: Different version of libncurses, different compiler and run time, different version and build options of Python 3.3, etc. The bug in ncurses causes junk to be stored and/or returned. In the one case, the junk triggered an overflow error, in the other, no overflow but still junk. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 07:02:10 2012 From: report at bugs.python.org (David Pietz) Date: Mon, 03 Sep 2012 05:02:10 +0000 Subject: [issue15853] IDLE crashes selecting Preferences menu with OS X ActiveState Tcl/Tk 8.5.12.1 In-Reply-To: <1346632042.85.0.745944196118.issue15853@psf.upfronthosting.co.za> Message-ID: <1346648530.88.0.0561118150798.issue15853@psf.upfronthosting.co.za> David Pietz added the comment: r.david.murray- Thank You for your inquiry. My recipe for this crash is (1) simply to start IDLE 3.2.3 in either Snow Leopard or Mountain Lion (2) click on the Bold "IDLE" menu in the menu bar and (3) click on menu item "preferences". At this point a dialog called "Problem Report for IDLE" appears with gobs of technical data details below a message "IDLE quit unexpectedly". I copied what I thought might be most specific. (The suggested 'click to reopen' does not work) I hope this data from the details section is informative even if it is not the only exception type or code I have seen related to IDLE in similar conditions: Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000024 VM Regions Near 0x24: --> __TEXT 0000000100000000-0000000100001000 [ 4K] r-x/rwx SM=COW /Library/Frameworks/Python.framework/Versions/3.2/Resources/Python.app/Contents/MacOS/Python Application Specific Information: Performing @selector(preferences:) from sender NSMenuItem 0x101b46a90 ---------- Added file: http://bugs.python.org/file27108/GRAB_IDLEquitUnexpectedly.tiff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 07:17:53 2012 From: report at bugs.python.org (Ned Deily) Date: Mon, 03 Sep 2012 05:17:53 +0000 Subject: [issue15853] IDLE crashes selecting Preferences menu with OS X ActiveState Tcl/Tk 8.5.12.1 In-Reply-To: <1346632042.85.0.745944196118.issue15853@psf.upfronthosting.co.za> Message-ID: <1346649473.36.0.699005822513.issue15853@psf.upfronthosting.co.za> Ned Deily added the comment: David, can you verify that you do have ActiveTcl 8.5.12 (.0 or .1) installed and that the problem no longer occurs if you disable ActiveTk by moving it as described above? When Preference is failing, the following Terminal shell command: grep TK_PATCH_LEVEL /Library/Frameworks/Tk.framework/Versions/Current/tkConfig.sh should output: TK_PATCH_LEVEL='.12' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 07:31:29 2012 From: report at bugs.python.org (David Pietz) Date: Mon, 03 Sep 2012 05:31:29 +0000 Subject: [issue15853] IDLE crashes selecting Preferences menu with OS X ActiveState Tcl/Tk 8.5.12.1 In-Reply-To: <1346632042.85.0.745944196118.issue15853@psf.upfronthosting.co.za> Message-ID: <1346650289.72.0.574798440722.issue15853@psf.upfronthosting.co.za> David Pietz added the comment: ned, That is exactly the output I received when I reverted to the ActiveState version, it failed and I ran your grep. Thank You for your interest. djp ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 07:45:36 2012 From: report at bugs.python.org (Georg Brandl) Date: Mon, 03 Sep 2012 05:45:36 +0000 Subject: [issue15847] parse_args stopped accepting tuples In-Reply-To: <1346591535.01.0.313863035332.issue15847@psf.upfronthosting.co.za> Message-ID: <1346651136.16.0.988241239473.issue15847@psf.upfronthosting.co.za> Georg Brandl added the comment: I agree this is a regression and should be fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 07:51:03 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 03 Sep 2012 05:51:03 +0000 Subject: [issue15850] list.count() results wrong if both booleans & 1's/0's are present in the list In-Reply-To: <1346603155.58.0.703735136333.issue15850@psf.upfronthosting.co.za> Message-ID: <1346651463.97.0.421538024409.issue15850@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Varun: what do you think that py> x = [1.0, 2.0, 3.0] py> x.count(3) 1 should give? I think most people will agree that there is one single "three" in the list, as 3 and 3.0 are equal in all other contexts as well (as is 3.0+0j). If types were considered, this would give 0. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 07:52:43 2012 From: report at bugs.python.org (David Pietz) Date: Mon, 03 Sep 2012 05:52:43 +0000 Subject: [issue15853] IDLE crashes selecting Preferences menu with OS X ActiveState Tcl/Tk 8.5.12.1 In-Reply-To: <1346632042.85.0.745944196118.issue15853@psf.upfronthosting.co.za> Message-ID: <1346651563.17.0.746683196062.issue15853@psf.upfronthosting.co.za> David Pietz added the comment: I thank you, gentlemen, for your kind attention to my issue. I hope it helps everyone in the long run. I, myself, became underwhelmed with these results of successfully opening preferences. I had been expecting to have a "|Startup|-|Shells open with command|text box to put a script in for append-logging my Python study in IDLE which follows Head First Python using 3.x- and its not in preferences for IDLE like it is in Terminal! Well, I guess I have some research to do on that matter. Thanks again. It was very gratifying to have my first issue responded to so quickly and intelligently! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 08:07:23 2012 From: report at bugs.python.org (Ned Deily) Date: Mon, 03 Sep 2012 06:07:23 +0000 Subject: [issue15853] IDLE crashes selecting Preferences menu with OS X ActiveState Tcl/Tk 8.5.12.1 In-Reply-To: <1346632042.85.0.745944196118.issue15853@psf.upfronthosting.co.za> Message-ID: <1346652443.28.0.217187903931.issue15853@psf.upfronthosting.co.za> Ned Deily added the comment: Hmm, sorry, I don't know of an easy fool-proof way to automatically log everything you type in IDLE. But it's pretty easy to manually save the contents of the IDLE shell window at the end: with the keyboard focus on the Python Shell window, select the File -> Save menu option. Good luck with exploring! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 09:40:02 2012 From: report at bugs.python.org (Manu Cupcic) Date: Mon, 03 Sep 2012 07:40:02 +0000 Subject: [issue13992] Segfault in PyTrash_destroy_chain In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za> Message-ID: <1346658002.64.0.892316940419.issue13992@psf.upfronthosting.co.za> Manu Cupcic added the comment: Hi, Antoine, thank you for the patch you proposed. It indeed fixed the bug I was seeing (I ran a job that usually crashes in one to two hours over the week end and it is still running). I am not sure what we should do now. Can this patch be integrated as is ? What can I do to help ? Thanks Manu ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 10:46:46 2012 From: report at bugs.python.org (Varun Masuraha) Date: Mon, 03 Sep 2012 08:46:46 +0000 Subject: [issue15850] list.count() results wrong if both booleans & 1's/0's are present in the list In-Reply-To: <1346603155.58.0.703735136333.issue15850@psf.upfronthosting.co.za> Message-ID: <1346662006.41.0.802984578757.issue15850@psf.upfronthosting.co.za> Varun Masuraha added the comment: Hey Martin, I think I got the point. Meanwhile I created my own myCount() for my problem ;-) Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 10:48:41 2012 From: report at bugs.python.org (Nicholas Cole) Date: Mon, 03 Sep 2012 08:48:41 +0000 Subject: [issue14223] curses addch broken on Python3.3a1 In-Reply-To: <1331153094.15.0.871612927682.issue14223@psf.upfronthosting.co.za> Message-ID: <1346662121.89.0.884747895717.issue14223@psf.upfronthosting.co.za> Nicholas Cole added the comment: Unless I'm getting the build process wrong (possible, because I haven't tried testing fixes before), this fix isn't working for me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 12:06:17 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 03 Sep 2012 10:06:17 +0000 Subject: [issue13992] Segfault in PyTrash_destroy_chain In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za> Message-ID: <1346666777.17.0.895251624989.issue13992@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I am not sure what we should do now. Can this patch be integrated as is > ? What can I do to help ? Well, you already helped by testing it, thank you. I have to add a test case to the patch, then hopefully it can be committed. ---------- stage: -> patch review versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 12:43:13 2012 From: report at bugs.python.org (Nicolas Schodet) Date: Mon, 03 Sep 2012 10:43:13 +0000 Subject: [issue14223] curses addch broken on Python3.3a1 In-Reply-To: <1331153094.15.0.871612927682.issue14223@psf.upfronthosting.co.za> Message-ID: <1346668993.4.0.665172547654.issue14223@psf.upfronthosting.co.za> Changes by Nicolas Schodet : ---------- nosy: -schodet _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 12:43:51 2012 From: report at bugs.python.org (Nicolas Schodet) Date: Mon, 03 Sep 2012 10:43:51 +0000 Subject: [issue15785] curses.get_wch() returns keypad codes incorrectly In-Reply-To: <1345975778.97.0.705241878581.issue15785@psf.upfronthosting.co.za> Message-ID: <1346669031.25.0.0579808029166.issue15785@psf.upfronthosting.co.za> Changes by Nicolas Schodet : ---------- nosy: -schodet _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 13:42:52 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 03 Sep 2012 11:42:52 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346260029.19.0.320505643782.issue15814@psf.upfronthosting.co.za> Message-ID: <1346672572.24.0.45066622251.issue15814@psf.upfronthosting.co.za> Nick Coghlan added the comment: The main issue is that it's not quite clear how to deal with problems like C-style vs FORTRAN-style memory layouts and strides vs suboffsets in defining multidimensional hash equality. Without a use case, it's easier to just punt on the question and declare it illegal. The 1D hashing case really just comes from wanting to have 1D bytes views behave as much like a bytes object as is practical. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 13:46:44 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 03 Sep 2012 11:46:44 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346260029.19.0.320505643782.issue15814@psf.upfronthosting.co.za> Message-ID: <3X9Tsv1pX1zQJg@mail.python.org> Roundup Robot added the comment: New changeset c9c9d890400c by Nick Coghlan in branch 'default': Issue #15814: Add NEWS entry regarding intended memoryview hashing restrictions http://hg.python.org/cpython/rev/c9c9d890400c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 14:02:32 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 03 Sep 2012 12:02:32 +0000 Subject: [issue14223] curses addch broken on Python3.3a1 In-Reply-To: <1331153094.15.0.871612927682.issue14223@psf.upfronthosting.co.za> Message-ID: <1346673752.52.0.264877166209.issue14223@psf.upfronthosting.co.za> STINNER Victor added the comment: > Unless I'm getting the build process wrong (possible, because > I haven't tried testing fixes before), this fix isn't working for me. Oh did you compile Python? Did you install it? Do you have libncursesw? => do you have the function curses.unget_wch? What is the version of your libcurses[w] library? There are issues on libncurses 5.7. I think Ned Bat changed the script to compile Python on Mac to use a builtin copy of libncurses 5.9. See: http://bugs.python.org/issue14225#msg163323 ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 14:31:27 2012 From: report at bugs.python.org (Christian Hofstaedtler) Date: Mon, 03 Sep 2012 12:31:27 +0000 Subject: [issue14223] curses addch broken on Python3.3a1 In-Reply-To: <1331153094.15.0.871612927682.issue14223@psf.upfronthosting.co.za> Message-ID: <1346675487.18.0.564839317114.issue14223@psf.upfronthosting.co.za> Changes by Christian Hofstaedtler : ---------- nosy: -zeha _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 14:38:18 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 03 Sep 2012 12:38:18 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346260029.19.0.320505643782.issue15814@psf.upfronthosting.co.za> Message-ID: <1346675898.83.0.337835500195.issue15814@psf.upfronthosting.co.za> Stefan Krah added the comment: Small nitpick: multi-dimensional hashing wasn't really accidental, it was perfectly aligned with the previous statically typed equality definition. When I suggested PyBuffer_Hash = hash(obj.tobytes()) on python-dev for non-contiguous and multi-dimensional arrays, I got a +1 from Raymond (which I now see was a private message). I don't see what could possibly be ill-defined about using the tobytes() definition for ND-arrays. In all places memoryview now uses the logical array, which is displayed by tolist(). Leaving aside static typing, both the previous and the new equality definitions regarded C and Fortran arrays with the same list outputs as equal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 14:56:39 2012 From: report at bugs.python.org (Trent Nelson) Date: Mon, 03 Sep 2012 12:56:39 +0000 Subject: [issue15748] Various symlink test failures in test_shutil on FreeBSD In-Reply-To: <1345516038.44.0.114148239105.issue15748@psf.upfronthosting.co.za> Message-ID: <1346676999.83.0.340476761448.issue15748@psf.upfronthosting.co.za> Trent Nelson added the comment: Link to discussion (initiated by Andriy) on zfs at lists.illumos.org: http://thread.gmane.org/gmane.os.illumos.zfs/69 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 14:57:34 2012 From: report at bugs.python.org (Nicholas Cole) Date: Mon, 03 Sep 2012 12:57:34 +0000 Subject: [issue14223] curses addch broken on Python3.3a1 In-Reply-To: <1331153094.15.0.871612927682.issue14223@psf.upfronthosting.co.za> Message-ID: <1346677054.54.0.619733462979.issue14223@psf.upfronthosting.co.za> Nicholas Cole added the comment: > Unless I'm getting the build process wrong (possible, because > I haven't tried testing fixes before), this fix isn't working for me. Oh did you compile Python? Did you install it? Yes, I tried compiling it. #./configure MACOSX_DEPLOYMENT_TARGET=10.8 --enable-framework --with-universal-archs="64-bit" CFLAGS="-arch x86_64" LDFLAGS="-arch x86_64" && make -j6 && make install Do you have libncursesw? => do you have the function curses.unget_wch? yes... Python 3.3.0rc1+ (default, Sep 3 2012, 09:45:35) [GCC 4.2.1 Compatible Apple Clang 4.0 ((tags/Apple/clang-421.0.57))] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import curses >>> curses.unget_wch() Traceback (most recent call last): File "", line 1, in _curses.error: must call initscr() first >>> curses.version b'2.2' >>> What is the version of your libcurses[w] library? There are issues on libncurses 5.7. I think Ned Bat changed the script to compile Python on Mac to use a builtin copy of libncurses 5.9. See: http://bugs.python.org/issue14225#msg163323 How do I check which version it was built against? The messages from ./configure just say that the tests pass, not which version it has found. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 15:01:21 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 03 Sep 2012 13:01:21 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346675898.83.0.337835500195.issue15814@psf.upfronthosting.co.za> Message-ID: Alexander Belopolsky added the comment: On Mon, Sep 3, 2012 at 8:38 AM, Stefan Krah wrote: > I don't see what could possibly be ill-defined about using the > tobytes() definition for ND-arrays. In all places memoryview now > uses the logical array, which is displayed by tolist(). +1. The key restriction is that to byte views. ND aspect does not complicate the logic once .tobytes() is properly implemented. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 15:04:14 2012 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 03 Sep 2012 13:04:14 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346260029.19.0.320505643782.issue15814@psf.upfronthosting.co.za> Message-ID: <1346677454.29.0.415757431327.issue15814@psf.upfronthosting.co.za> Changes by Stefan Behnel : ---------- nosy: -scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 15:13:21 2012 From: report at bugs.python.org (Anton Barkovsky) Date: Mon, 03 Sep 2012 13:13:21 +0000 Subject: [issue15557] Tests for webbrowser module In-Reply-To: <1344102778.31.0.864118033074.issue15557@psf.upfronthosting.co.za> Message-ID: <1346678001.74.0.565259577218.issue15557@psf.upfronthosting.co.za> Anton Barkovsky added the comment: I think you forgot to write `test_open_with_autoraise_false` for Chrome tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 15:25:50 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 03 Sep 2012 13:25:50 +0000 Subject: [issue15855] memoryview methods are missing docstrings Message-ID: <1346678750.91.0.0208236939901.issue15855@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: With attached patch python -mpydoc memoryview display looks as follows: ... | cast(...) | M.cast(format[, shape]) -> memoryview | | Cast a memoryview to a new format or shape. | | release(...) | M.release() -> None | | Release the underlying buffer exposed by the memoryview object. | | tobytes(...) | M.tobytes() -> bytes | | Return the data in the buffer as a bytestring. | | tolist(...) | M.tobytes() -> list | | Return the data in the buffer as a list of elements. ---------- files: memoryobject-docstrings.diff keywords: patch messages: 169762 nosy: belopolsky, skrah priority: normal severity: normal status: open title: memoryview methods are missing docstrings type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file27109/memoryobject-docstrings.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 15:30:59 2012 From: report at bugs.python.org (Daniel Wagner-Hall) Date: Mon, 03 Sep 2012 13:30:59 +0000 Subject: [issue15836] unittest assertRaises should verify excClass is actually a BaseException class In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za> Message-ID: <1346679059.58.0.34261856995.issue15836@psf.upfronthosting.co.za> Daniel Wagner-Hall added the comment: Cool, my contributor agreement has been received, please merge if happy! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 16:15:01 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 03 Sep 2012 14:15:01 +0000 Subject: [issue14223] curses addch broken on Python3.3a1 In-Reply-To: <1346677054.54.0.619733462979.issue14223@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > How do I check which version it was built against? On Linux, I use: $ ldd /usr/lib/python2.7/lib-dynload/_curses.so |grep curses libncursesw.so.5 => /lib/i386-linux-gnu/libncursesw.so.5 (0xb76d0000) $ ls -l /lib/i386-linux-gnu/libncursesw.so.5 lrwxrwxrwx 1 root root 18 nov. 18 2011 /lib/i386-linux-gnu/libncursesw.so.5 -> libncursesw.so.5.9 => version 5.9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 16:36:35 2012 From: report at bugs.python.org (Nicholas Cole) Date: Mon, 03 Sep 2012 14:36:35 +0000 Subject: [issue14223] curses addch broken on Python3.3a1 In-Reply-To: Message-ID: Nicholas Cole added the comment: On Mon, Sep 3, 2012 at 3:15 PM, STINNER Victor wrote: > > STINNER Victor added the comment: > >> How do I check which version it was built against? > > On Linux, I use: > > $ ldd /usr/lib/python2.7/lib-dynload/_curses.so |grep curses > libncursesw.so.5 => /lib/i386-linux-gnu/libncursesw.so.5 (0xb76d0000) > $ ls -l /lib/i386-linux-gnu/libncursesw.so.5 > lrwxrwxrwx 1 root root 18 nov. 18 2011 > /lib/i386-linux-gnu/libncursesw.so.5 -> libncursesw.so.5.9 > > => version 5.9 I get Version 5.4, which seems very out of date (I'm running the latest release of OS X) but: nicholas$ ls -l /usr/lib/libncurses. libncurses.5.4.dylib libncurses.5.dylib libncurses.dylib NPSC:mnpyscreen nicholas$ ls -l /usr/lib/libncurses.dylib lrwxr-xr-x 1 root wheel 20 25 Jul 18:32 /usr/lib/libncurses.dylib -> libncurses.5.4.dylib nicholas$ ldd /usr/lib/python2.7/lib-dynload/_curses.so |grep curses /usr/lib/python2.7/lib-dynload/_curses.so: /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0) Can that possibly be right?? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 17:00:27 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 03 Sep 2012 15:00:27 +0000 Subject: [issue15557] Tests for webbrowser module In-Reply-To: <1344102778.31.0.864118033074.issue15557@psf.upfronthosting.co.za> Message-ID: <1346684427.72.0.990849059327.issue15557@psf.upfronthosting.co.za> R. David Murray added the comment: I did indeed. ---------- Added file: http://bugs.python.org/file27110/test_webbrowser.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 17:13:44 2012 From: report at bugs.python.org (Thomas Kluyver) Date: Mon, 03 Sep 2012 15:13:44 +0000 Subject: [issue15856] inspect.getsource(SomeClass) doesn't show @decorators Message-ID: <1346685224.9.0.738134714561.issue15856@psf.upfronthosting.co.za> New submission from Thomas Kluyver: Since bug #1006219 was fixed, inspect.getsource(func) has returned the source of a function including any decorators on the function. But doing the same with a class, the returned source doesn't include decorators. With functions, the co_firstlineno attribute of the code object points to the start of the decorators. With classes, that's not possible, so it's likely that a bit more regex trickery will be needed to scan back to decorators. I've confirmed the same thing happens in 3.2 and 2.7, and looking at the code of inspect.py in trunk, it looks like it will do the same thing. ---------- components: Library (Lib) messages: 169767 nosy: takluyver priority: normal severity: normal status: open title: inspect.getsource(SomeClass) doesn't show @decorators type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 18:03:17 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 03 Sep 2012 16:03:17 +0000 Subject: [issue15557] Tests for webbrowser module In-Reply-To: <1344102778.31.0.864118033074.issue15557@psf.upfronthosting.co.za> Message-ID: <1346688197.82.0.475476677512.issue15557@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I added some comments on the latest patch on the review tool. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 18:04:40 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 03 Sep 2012 16:04:40 +0000 Subject: [issue15855] memoryview methods and data members are missing docstrings In-Reply-To: <1346678750.91.0.0208236939901.issue15855@psf.upfronthosting.co.za> Message-ID: <1346688280.1.0.169252770373.issue15855@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: In the new patch, I added docstrings for the data members and now the list of memoryview data descriptors looks as follows in pydoc: | ---------------------------------------------------------------------- | Data descriptors defined here: | | c_contiguous | A bool indicating whether the memory is C contiguous. | | contiguous | A bool indicating whether the memory is contiguous. | | f_contiguous | A bool indicating whether the memory is Fortran contiguous. | | format | A string containing the format (in struct module style) | for each element in the view. | | itemsize | The size in bytes of each element of the memoryview. | | nbytes | The amount of space in bytes that the array would use in | a contiguous representation. | | ndim | An integer indicating how many dimensions of a multi-dimensional | array the memory represents. | | obj | The underlying object of the memoryview. | | readonly | A bool indicating whether the memory is read only. | | shape | A tuple of ndim integers giving the shape of the memory | as a N-dimensional array. | | strides | A tuple of ndim integers giving the size in bytes to access | each element for each dimension of the array or None for C | contiguous. | | suboffsets | A tuple of ndim integers used internally for PIL-style arrays | or None. ---------- title: memoryview methods are missing docstrings -> memoryview methods and data members are missing docstrings Added file: http://bugs.python.org/file27111/issue15855.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 18:04:50 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 03 Sep 2012 16:04:50 +0000 Subject: [issue15855] memoryview methods and data members are missing docstrings In-Reply-To: <1346678750.91.0.0208236939901.issue15855@psf.upfronthosting.co.za> Message-ID: <1346688290.14.0.184219804736.issue15855@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : Removed file: http://bugs.python.org/file27109/memoryobject-docstrings.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 18:15:43 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 03 Sep 2012 16:15:43 +0000 Subject: [issue15509] webbrowser.open sometimes passes zero-length argument to the browser. In-Reply-To: <1343687718.2.0.882765777761.issue15509@psf.upfronthosting.co.za> Message-ID: <1346688943.93.0.03449548724.issue15509@psf.upfronthosting.co.za> R. David Murray added the comment: Given the logic of webbrowser, I think Anton's patch is correct. The null strings are produced by the somewhat twisted logic of UnixBrowser.open, and the problem doesn't apply to the other cases of argument list generation. (In those other cases, getting null strings would indicate a configuration error, which this case is not.) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 18:16:34 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 03 Sep 2012 16:16:34 +0000 Subject: [issue15509] UnixBrowser.open sometimes passes zero-length argument to the browser. In-Reply-To: <1343687718.2.0.882765777761.issue15509@psf.upfronthosting.co.za> Message-ID: <1346688994.0.0.758146760813.issue15509@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- title: webbrowser.open sometimes passes zero-length argument to the browser. -> UnixBrowser.open sometimes passes zero-length argument to the browser. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 18:24:57 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 03 Sep 2012 16:24:57 +0000 Subject: [issue15857] memoryview of a ctypes struct has incompatible invalid format Message-ID: <1346689497.87.0.0543181973017.issue15857@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: Starting with the example in memoryview documentation: >>> from ctypes import BigEndianStructure, c_long >>> class BEPoint(BigEndianStructure): ... _fields_ = [("x", c_long), ("y", c_long)] ... >>> point = BEPoint(100, 200) >>> a = memoryview(point) I am trying to unpack the resulting view: >>> a.tolist() Traceback (most recent call last): File "", line 1, in NotImplementedError: memoryview: unsupported format T{>l:x:>l:y:} >>> struct.unpack_from(a.format,a) Traceback (most recent call last): File "", line 1, in struct.error: bad char in struct format >>> struct.unpack_from('>ll',a) (0, 100) It looks like there is one or more bugs in play here. ---------- messages: 169771 nosy: belopolsky, skrah priority: normal severity: normal status: open title: memoryview of a ctypes struct has incompatible invalid format type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 18:34:16 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 03 Sep 2012 16:34:16 +0000 Subject: [issue15855] memoryview methods and data members are missing docstrings In-Reply-To: <1346678750.91.0.0208236939901.issue15855@psf.upfronthosting.co.za> Message-ID: <1346690056.42.0.514827074242.issue15855@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This should also be fixed in 3.2 (at least for those methods/members which are in 3.2). ---------- nosy: +pitrou versions: +Python 3.2, Python 3.3 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 18:47:27 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 03 Sep 2012 16:47:27 +0000 Subject: [issue15855] memoryview methods and data members are missing docstrings In-Reply-To: <1346678750.91.0.0208236939901.issue15855@psf.upfronthosting.co.za> Message-ID: <1346690847.13.0.193593921276.issue15855@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I am going to commit this tonight. Stefan, please let me know if you have any comments. I copied most of the descriptions from ReST manual with a few minor changes. See shape/strides/suboffsets. ---------- stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 18:53:25 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 03 Sep 2012 16:53:25 +0000 Subject: [issue15447] A file is not properly closed by webbrowser._invoke In-Reply-To: <1343222113.7.0.837887359823.issue15447@psf.upfronthosting.co.za> Message-ID: <3X9cgm3ZxCzQG3@mail.python.org> Roundup Robot added the comment: New changeset 901c790e4417 by R David Murray in branch 'default': #15447: Use subprocess.DEVNULL in webbrowser, instead of opening http://hg.python.org/cpython/rev/901c790e4417 New changeset 5da3b2df38b3 by R David Murray in branch 'default': #15557,#15447,#15509: webbrowser test suite added. http://hg.python.org/cpython/rev/5da3b2df38b3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 18:53:26 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 03 Sep 2012 16:53:26 +0000 Subject: [issue15557] Tests for webbrowser module In-Reply-To: <1344102778.31.0.864118033074.issue15557@psf.upfronthosting.co.za> Message-ID: <3X9cgn21Q6zQG3@mail.python.org> Roundup Robot added the comment: New changeset 5da3b2df38b3 by R David Murray in branch 'default': #15557,#15447,#15509: webbrowser test suite added. http://hg.python.org/cpython/rev/5da3b2df38b3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 18:53:27 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 03 Sep 2012 16:53:27 +0000 Subject: [issue15509] UnixBrowser.open sometimes passes zero-length argument to the browser. In-Reply-To: <1343687718.2.0.882765777761.issue15509@psf.upfronthosting.co.za> Message-ID: <3X9cgp0RmDzQG3@mail.python.org> Roundup Robot added the comment: New changeset 6768aa70c2d3 by R David Murray in branch '3.2': #15509: If %action substitution produces a null string, drop it. http://hg.python.org/cpython/rev/6768aa70c2d3 New changeset 323ca2f0e382 by R David Murray in branch 'default': Merge #15509: If %action substitution produces a null string, drop it. http://hg.python.org/cpython/rev/323ca2f0e382 New changeset 5da3b2df38b3 by R David Murray in branch 'default': #15557,#15447,#15509: webbrowser test suite added. http://hg.python.org/cpython/rev/5da3b2df38b3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 18:53:54 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 03 Sep 2012 16:53:54 +0000 Subject: [issue15857] memoryview: complete support for struct packing/unpacking In-Reply-To: <1346689497.87.0.0543181973017.issue15857@psf.upfronthosting.co.za> Message-ID: <1346691234.25.0.656178020735.issue15857@psf.upfronthosting.co.za> Stefan Krah added the comment: It's deliberately not implemented (and documented): Since memoryview is a complete rewrite, I tried go easy on new features in order to facilitate review. My plan was to implement struct packing/unpacking in 3.3.1 in the same manner as in the new equality function. The struct error you see is tracked in #3132. ---------- components: +Interpreter Core stage: -> needs patch title: memoryview of a ctypes struct has incompatible invalid format -> memoryview: complete support for struct packing/unpacking type: behavior -> enhancement versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 18:54:46 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 03 Sep 2012 16:54:46 +0000 Subject: [issue15509] UnixBrowser.open sometimes passes zero-length argument to the browser. In-Reply-To: <1343687718.2.0.882765777761.issue15509@psf.upfronthosting.co.za> Message-ID: <1346691286.53.0.627038084698.issue15509@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Anton. ---------- resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 18:55:23 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 03 Sep 2012 16:55:23 +0000 Subject: [issue15447] A file is not properly closed by webbrowser._invoke In-Reply-To: <1343222113.7.0.837887359823.issue15447@psf.upfronthosting.co.za> Message-ID: <1346691323.72.0.304058000917.issue15447@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Anton. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 18:56:26 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 03 Sep 2012 16:56:26 +0000 Subject: [issue15557] Tests for webbrowser module In-Reply-To: <1344102778.31.0.864118033074.issue15557@psf.upfronthosting.co.za> Message-ID: <1346691386.24.0.567709492547.issue15557@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Anton. And thank you Chris for the initial reviews. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 18:57:51 2012 From: report at bugs.python.org (Ned Deily) Date: Mon, 03 Sep 2012 16:57:51 +0000 Subject: [issue14223] curses addch broken on Python3.3a1 In-Reply-To: <1331153094.15.0.871612927682.issue14223@psf.upfronthosting.co.za> Message-ID: <1346691471.4.0.743733776816.issue14223@psf.upfronthosting.co.za> Ned Deily added the comment: > Can that possibly be right?? Yes. That's the version of ncurses that Apple ships with current versions of OS X. You can build it yourself and install into /usr/local and rebuild python. For ncurses 5.9, something like: ./configure --enable-widec --enable-shared --with-shared --without-normal && make && sudo make install should work. FWIW, when I run your test script with tip, I now do see the two horizontal bars. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 18:59:36 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 03 Sep 2012 16:59:36 +0000 Subject: [issue15857] memoryview: complete support for struct packing/unpacking In-Reply-To: <1346689497.87.0.0543181973017.issue15857@psf.upfronthosting.co.za> Message-ID: <1346691576.24.0.932551960067.issue15857@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: What about >>> struct.unpack_from('>ll',a) (0, 100) shouldn't that return (100, 200)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 19:22:28 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 03 Sep 2012 17:22:28 +0000 Subject: [issue15855] memoryview methods and data members are missing docstrings In-Reply-To: <1346678750.91.0.0208236939901.issue15855@psf.upfronthosting.co.za> Message-ID: <1346692948.41.0.388052266362.issue15855@psf.upfronthosting.co.za> Stefan Krah added the comment: I've left a couple of comments. -- Personally I'd also prefer if all docstrings go into a separate section. I always perceive docstrings as noise that takes up precious vertical space, so for _decimal I even banned them into docstrings.h. I don't know if there's any kind of convention for that though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 19:24:34 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 03 Sep 2012 17:24:34 +0000 Subject: [issue15557] Tests for webbrowser module In-Reply-To: <1344102778.31.0.864118033074.issue15557@psf.upfronthosting.co.za> Message-ID: <1346693074.42.0.392378763554.issue15557@psf.upfronthosting.co.za> R. David Murray added the comment: Hmm. For some reason I did not get emailed these review comments, and I did not see your note before I did the checkin. I will take a look. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 19:26:21 2012 From: report at bugs.python.org (moijes12) Date: Mon, 03 Sep 2012 17:26:21 +0000 Subject: =?utf-8?q?=5Bissue13518=5D_configparser_can=E2=80=99t_read_file_objects_f?= =?utf-8?q?rom_urlopen?= In-Reply-To: <1322782976.1.0.275624635723.issue13518@psf.upfronthosting.co.za> Message-ID: <1346693181.95.0.148634367166.issue13518@psf.upfronthosting.co.za> Changes by moijes12 : ---------- nosy: -moijes12 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 19:33:57 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 03 Sep 2012 17:33:57 +0000 Subject: [issue15557] Tests for webbrowser module In-Reply-To: <1344102778.31.0.864118033074.issue15557@psf.upfronthosting.co.za> Message-ID: <1346693637.07.0.763559557702.issue15557@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks, David. I wasn't sure if you had seen the comments. They're mostly stylistic, though, so it's not too big of a deal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 19:36:21 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 03 Sep 2012 17:36:21 +0000 Subject: [issue15557] Tests for webbrowser module In-Reply-To: <1344102778.31.0.864118033074.issue15557@psf.upfronthosting.co.za> Message-ID: <1346693781.35.0.112473456079.issue15557@psf.upfronthosting.co.za> R. David Murray added the comment: Yeah, you make some good points, but I think I may already have spent more time on this that is justified by the amount of usage webbrowser gets :) So I think I'm going to leave it as is, as being 'good enough'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 19:39:10 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 03 Sep 2012 17:39:10 +0000 Subject: [issue15557] Tests for webbrowser module In-Reply-To: <1344102778.31.0.864118033074.issue15557@psf.upfronthosting.co.za> Message-ID: <1346693950.49.0.166294976073.issue15557@psf.upfronthosting.co.za> R. David Murray added the comment: Oh, I see. I did get the email, it's just that my email filter put it into a different folder from what I was expected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 19:41:50 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 03 Sep 2012 17:41:50 +0000 Subject: [issue15557] Tests for webbrowser module In-Reply-To: <1344102778.31.0.864118033074.issue15557@psf.upfronthosting.co.za> Message-ID: <1346694110.37.0.0095239780375.issue15557@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Fair enough. :) I may keep a couple of those changes in mind if I ever have a chance to visit this module myself in the future. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 19:43:37 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 03 Sep 2012 17:43:37 +0000 Subject: [issue15857] memoryview: complete support for struct packing/unpacking In-Reply-To: <1346689497.87.0.0543181973017.issue15857@psf.upfronthosting.co.za> Message-ID: <1346694217.28.0.915734084119.issue15857@psf.upfronthosting.co.za> Stefan Krah added the comment: '>' in struct syntax implies "standard size" for 'l', which is 4 bytes. ctypes uses machine size for c_long, so on an LP64 machine you can unpack the data as: >>> struct.unpack_from('>qq', a) (100, 200) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 19:49:20 2012 From: report at bugs.python.org (moijes12) Date: Mon, 03 Sep 2012 17:49:20 +0000 Subject: [issue8911] regrtest.main should have a test skipping argument In-Reply-To: <1275794606.83.0.993053669818.issue8911@psf.upfronthosting.co.za> Message-ID: <1346694560.15.0.1264877112.issue8911@psf.upfronthosting.co.za> Changes by moijes12 : ---------- nosy: +moijes12 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 20:06:24 2012 From: report at bugs.python.org (Alessandro Moura) Date: Mon, 03 Sep 2012 18:06:24 +0000 Subject: [issue15837] Added test to test_random.py testing Random.shuffle In-Reply-To: <1346465179.1.0.118516816378.issue15837@psf.upfronthosting.co.za> Message-ID: <1346695584.84.0.846309894773.issue15837@psf.upfronthosting.co.za> Alessandro Moura added the comment: Comparing the execution time with and without the int=int argument of this command: amoura at amoura-laptop:~/cpython$ time ./python -c "from random import shuffle; lst=list(range(1000000)); shuffle(lst); print (len(lst))" I get with int=int: real 0m13.755s user 0m13.777s sys 0m0.124s and without it: real 0m13.876s user 0m13.701s sys 0m0.116s So it makes no difference in practice. On the other hand, removing this has a chance of braking existing code, if someone somewhere actually uses the third argument for something - I can't image what, but still... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 20:16:49 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 03 Sep 2012 18:16:49 +0000 Subject: [issue15855] memoryview methods and data members are missing docstrings In-Reply-To: <1346692948.41.0.388052266362.issue15855@psf.upfronthosting.co.za> Message-ID: Alexander Belopolsky added the comment: On Sep 3, 2012, at 1:22 PM, Stefan Krah wrote: > Personally I'd also prefer if all > docstrings go into a separate section. I always perceive docstrings > as noise that takes up precious vertical space, so for _decimal I even > banned them into docstrings.h. > > I don't know if there's any kind of convention for that though. I've seen two types of convention: a docs trying before function definition and docstring after function body. I prefer the first because the docstring doubles as a short comment describing the function that follows. If we put docstrings in a separate section, we may see comments above functions diverge from docstrings over time. On the other hand, this is not that important and consolidating the changes in one section will make 3.2 to 3.3 merge easier. I'll consolidate and wait for someone else to complain. :-) ---------- nosy: +Alexander.Belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 20:19:55 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Mon, 03 Sep 2012 18:19:55 +0000 Subject: [issue14922] mailbox.Maildir.get_message() may fail when Maildir dirname is a unicode string In-Reply-To: <1337986521.77.0.280125876775.issue14922@psf.upfronthosting.co.za> Message-ID: <1346696395.46.0.682638371436.issue14922@psf.upfronthosting.co.za> Petri Lehtinen added the comment: This would be considered a new feature, and is thus out of scope for 2.7. An easy workaround is to encode the unicode path to str using the file system encoding first (sys.getfilesystemencoding()). ---------- resolution: -> rejected stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 20:33:45 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 03 Sep 2012 18:33:45 +0000 Subject: [issue8911] regrtest.main should have a test skipping argument In-Reply-To: <1275794606.83.0.993053669818.issue8911@psf.upfronthosting.co.za> Message-ID: <1346697225.93.0.232503730838.issue8911@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 20:39:34 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 03 Sep 2012 18:39:34 +0000 Subject: [issue8911] regrtest.main should have a test skipping argument In-Reply-To: <1275794606.83.0.993053669818.issue8911@psf.upfronthosting.co.za> Message-ID: <1346697574.13.0.498811882203.issue8911@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > If you look at importlib.regrtest you will notice it has to muck with sys.argv in order to get certain tests skipped. This is reminiscent of issue 15132 which I filed, but for unittest.TestProgram() rather than regrtest.main(). > 6. Switch regrtest.py to use argparse instead of optparse. By the way, there is a patch for this from a couple months ago at issue 15302. It is waiting to be reviewed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 20:42:57 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 03 Sep 2012 18:42:57 +0000 Subject: [issue15855] memoryview methods and data members are missing docstrings In-Reply-To: Message-ID: <20120903184258.GA15209@sleipnir.bytereef.org> Stefan Krah added the comment: > On the other hand, this is not that important and consolidating the changes in one section will make 3.2 to 3.3 merge easier. I'll consolidate and wait for someone else to complain. :-) Thanks! I'm certain someone will complain, probably on python-dev right after you commit. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 20:49:08 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 03 Sep 2012 18:49:08 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1346698148.47.0.847369656078.issue15533@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Update patch. ---------- Added file: http://bugs.python.org/file27112/issue-15533-4-default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 21:08:30 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 03 Sep 2012 19:08:30 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1346699309.99.0.759957449698.issue15533@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks, Andrew. Regarding your comment, it was a deliberate choice not to do the additional check because I wanted each test to check only one thing. But I am okay with adding the additional check. Regarding the patch, should all of the methods now do something similar to what test_cwd() does? + # We cannot use os.path.realpath to canonicalize the path, + # since it doesn't expand Tru64 {memb} strings. See bug 1063571. + cwd = os.getcwd() + os.chdir(tmpdir) + tmpdir = os.getcwd() It looks like test_cwd() may have needed to apply this treatment to have more reliable string-matching in the assert. Otherwise, why is tmpdir being re-assigned to? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 21:11:16 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 03 Sep 2012 19:11:16 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za> Message-ID: <1346699476.52.0.477310372263.issue15510@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks a lot for the very thorough review, David. I should be able to update the patch and respond to a couple of your points later today or tomorrow at the latest. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 21:18:47 2012 From: report at bugs.python.org (moijes12) Date: Mon, 03 Sep 2012 19:18:47 +0000 Subject: [issue8911] regrtest.main should have a test skipping argument In-Reply-To: <1275794606.83.0.993053669818.issue8911@psf.upfronthosting.co.za> Message-ID: <1346699927.91.0.711188745142.issue8911@psf.upfronthosting.co.za> Changes by moijes12 : ---------- nosy: -moijes12 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 21:46:39 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 03 Sep 2012 19:46:39 +0000 Subject: [issue15340] OSError with "import random" when /dev/urandom doesn't exist (regression from 2.6) In-Reply-To: <1342132229.15.0.69254682318.issue15340@psf.upfronthosting.co.za> Message-ID: <1346701599.77.0.621861616362.issue15340@psf.upfronthosting.co.za> Antoine Pitrou added the comment: As for the patch: looks good on the principle. However, PyExc_NotImplementedError has no "errno" or "filename", attribute, so you shouldn't use PyErr_SetFromErrnoWithFilename. Instead, simply call PyErr_SetString. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 21:47:40 2012 From: report at bugs.python.org (Tom Lynn) Date: Mon, 03 Sep 2012 19:47:40 +0000 Subject: [issue15858] tarfile missing entries due to omitted uid/gid fields Message-ID: <1346701660.86.0.976031645545.issue15858@psf.upfronthosting.co.za> New submission from Tom Lynn: The tarfile module silently truncates the list of entries when reading a tar file if it sees an entry with a uid/gid field containing only spaces/NULs. I got such a tarball from Java Maven/plexus-archiver. I don't know whether they write such fields deliberately, but it seems reasonable to me, especially since they were providing the user/group names textually. I'd like to see two fixes - a None/-1/0 value for the uid/gid and not silently swallowing HeaderErrors in TarFile.next() (or at least documenting why it's being done). 0 would be consistent with the default value when writing, but None seems more honest. -1 seems hard to defend. Only tested on silly Python versions (2.6, PyPy-1.8), sorry. It's what I've got to hand, but I think this issue also applies to recent Python too going by looking at the hg trunk. ---------- components: Library (Lib) messages: 169799 nosy: tlynn priority: normal severity: normal status: open title: tarfile missing entries due to omitted uid/gid fields type: behavior versions: 3rd party, Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 21:59:03 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 03 Sep 2012 19:59:03 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <8E6973A6-3FB4-4964-9F10-757D810B9351@gmail.com> Message-ID: <50450C05.4010505@v.loewis.de> Martin v. L?wis added the comment: Am 02.09.2012 16:21, schrieb Alexander Belopolsky: > I have refrained from voting because in my line of work buffers or > memoryviews deal with large objects that rarely serve as dictionary > keys. As a result, I have zero experince with hashing of buffers. > This observation supports the current consensus to limit hashing to > 1d and 0d cases. My only concern is that with hash(m) == > hash(m.tobytes()) implementing multidimensional restriction will > require artificial if ndim > 1 check and an extra sentence in the > docs while not simplifying anything. As for the "not simplifying argument": if hashing was restricted to contiguous bytes, then the implementation would certainly be simplified quite a bit: currently, if it's not contiguous, it needs to make a separate copy and hash that. This code could go away if hashing would only work for true memory "blocks". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 22:15:30 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 03 Sep 2012 20:15:30 +0000 Subject: [issue15744] missing tests for {RawIO,BufferedIO,TextIO}.writelines In-Reply-To: <1345500357.29.0.226025015503.issue15744@psf.upfronthosting.co.za> Message-ID: <1346703330.25.0.605863044631.issue15744@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 22:21:49 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 03 Sep 2012 20:21:49 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <50450C05.4010505@v.loewis.de> Message-ID: Alexander Belopolsky added the comment: On Mon, Sep 3, 2012 at 3:59 PM, Martin v. L?wis wrote: > if hashing was restricted > to contiguous bytes, then the implementation would certainly be > simplified quite a bit: currently, if it's not contiguous, it needs > to make a separate copy and hash that. I would be happy if this whole business of "strided" memory layouts would go away. I find it to be a failed attempt of over-generalization. It is failed because it does not cover many important formats even in 2-d: sparse matrices, symmetrical matrices, banded matrices, etc., etc. (Check level 3 BLAS or NAG for a longer list.) It is an over-generalizarion because in practice it is often more efficient to gather your data in contiguous memory, perform vector calculations and then scatter the results than to operate on scattered data to avoid copying. I would much rather see a generalization of suboffsets that would allow me to have views into arrays of pointers to variable width arrays than strides. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 22:29:40 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 03 Sep 2012 20:29:40 +0000 Subject: [issue15855] memoryview methods and data members are missing docstrings In-Reply-To: <1346678750.91.0.0208236939901.issue15855@psf.upfronthosting.co.za> Message-ID: <3X9jTH0cCRzQGB@mail.python.org> Roundup Robot added the comment: New changeset c49f89261d65 by Alexander Belopolsky in branch '3.2': Issue #15855: added docstrings for memoryview methods and data descriptors. http://hg.python.org/cpython/rev/c49f89261d65 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 22:44:09 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 03 Sep 2012 20:44:09 +0000 Subject: [issue15855] memoryview methods and data members are missing docstrings In-Reply-To: <1346678750.91.0.0208236939901.issue15855@psf.upfronthosting.co.za> Message-ID: <3X9jp033drzNWX@mail.python.org> Roundup Robot added the comment: New changeset 16a69ccff5ce by Alexander Belopolsky in branch 'default': Issue #15855: added docstrings for memoryview methods and data descriptors (merge 3.2). http://hg.python.org/cpython/rev/16a69ccff5ce ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 22:51:11 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 03 Sep 2012 20:51:11 +0000 Subject: [issue15855] memoryview methods and data members are missing docstrings In-Reply-To: <1346678750.91.0.0208236939901.issue15855@psf.upfronthosting.co.za> Message-ID: <3X9jy571GNzNk2@mail.python.org> Roundup Robot added the comment: New changeset ba2c1def3710 by Alexander Belopolsky in branch 'default': Issue #15855: added docstrings for memoryview methods and data descriptors new in 3.3. http://hg.python.org/cpython/rev/ba2c1def3710 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 22:58:41 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 03 Sep 2012 20:58:41 +0000 Subject: [issue15855] memoryview methods and data members are missing docstrings In-Reply-To: <1346678750.91.0.0208236939901.issue15855@psf.upfronthosting.co.za> Message-ID: <1346705921.4.0.268007277242.issue15855@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: A few remaining comments: 1) shape being None for 0-d views in 3.2 is probably a bug. I did not mention that behavior in docstring. 2) "a N-dimensional array" typo was copied from ReST. Fixing it does not deserve a separate tracker entry, but I would like to review the whole section and add new/changed in 3.3 as necessary once we resolve (1) above. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 22:59:50 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 03 Sep 2012 20:59:50 +0000 Subject: [issue15837] Added test to test_random.py testing Random.shuffle In-Reply-To: <1346465179.1.0.118516816378.issue15837@psf.upfronthosting.co.za> Message-ID: <1346705990.04.0.0697697692649.issue15837@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Third parameter (int) plays a role only in the presence of a second one (random). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 23:16:13 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 03 Sep 2012 21:16:13 +0000 Subject: [issue15855] memoryview methods and data members are missing docstrings In-Reply-To: <1346705921.4.0.268007277242.issue15855@psf.upfronthosting.co.za> Message-ID: <20120903211613.GA16700@sleipnir.bytereef.org> Stefan Krah added the comment: > 1) shape being None for 0-d views in 3.2 is probably a bug. Probably. I don't know whether it's worth fixing. Several test cases in ctypes as well as in NumPy rely on it. So I guess we should just leave it for 3.2. > 2) "a N-dimensional array" typo was copied from ReST. Fixing it does > not deserve a separate tracker entry, but I would like to review the > whole section and add new/changed in 3.3 as necessary once we resolve > (1) above. There are definitely some places where new/changed could be added (e.g. the empty tuple for 0-d views is not mentioned). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 23:29:34 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 03 Sep 2012 21:29:34 +0000 Subject: [issue15855] memoryview methods and data members are missing docstrings In-Reply-To: <1346678750.91.0.0208236939901.issue15855@psf.upfronthosting.co.za> Message-ID: <3X9kpN2WYYzQGN@mail.python.org> Roundup Robot added the comment: New changeset 82ae284cd5f1 by Alexander Belopolsky in branch 'default': Issue #15855: updated related manual entries. http://hg.python.org/cpython/rev/82ae284cd5f1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 3 23:59:35 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 03 Sep 2012 21:59:35 +0000 Subject: [issue15837] Added test to test_random.py testing Random.shuffle In-Reply-To: <1346465179.1.0.118516816378.issue15837@psf.upfronthosting.co.za> Message-ID: <1346709575.79.0.00666521026481.issue15837@psf.upfronthosting.co.za> R. David Murray added the comment: No, it always has an effect. It means that the name 'int' is bound in locals instead of being looked up via globals. That is what makes it a micro-optimization (LOAD_FAST vs LOAD_GLOBAL, if you do a dis on the two variants). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 00:01:26 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 03 Sep 2012 22:01:26 +0000 Subject: [issue15837] Added test to test_random.py testing Random.shuffle In-Reply-To: <1346465179.1.0.118516816378.issue15837@psf.upfronthosting.co.za> Message-ID: <1346709686.25.0.58273296479.issue15837@psf.upfronthosting.co.za> R. David Murray added the comment: Oh, I see what you are saying. The lookup of int is only done if random is not None. Yes, that is true. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 00:03:39 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 03 Sep 2012 22:03:39 +0000 Subject: [issue15837] Added test to test_random.py testing Random.shuffle In-Reply-To: <1346465179.1.0.118516816378.issue15837@psf.upfronthosting.co.za> Message-ID: <1346709819.41.0.643966102259.issue15837@psf.upfronthosting.co.za> R. David Murray added the comment: If the optimization is actually useful, it can be preserved by just putting 'int=int' (with an 'optimization' comment :) before the loop. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 00:55:56 2012 From: report at bugs.python.org (Alessandro Moura) Date: Mon, 03 Sep 2012 22:55:56 +0000 Subject: [issue15837] Added test to test_random.py testing Random.shuffle In-Reply-To: <1346465179.1.0.118516816378.issue15837@psf.upfronthosting.co.za> Message-ID: <1346712956.3.0.326893344799.issue15837@psf.upfronthosting.co.za> Alessandro Moura added the comment: The int=int still makes no difference, but if the second argument is set to random.random, we get a big speedup, regardless of whether the third argument is there: without int=int: amoura at amoura-laptop:~/cpython$ time ./python -c "import random; lst=list(range(1000000)); random.shuffle(lst,random.random); print (len(lst))" 1000000 real 0m7.082s user 0m6.952s sys 0m0.116s With int=int: amoura at amoura-laptop:~/cpython$ time ./python -c "import random; lst=list(range(1000000)); random.shuffle(lst,random.random); print (len(lst))" 1000000 real 0m7.281s user 0m7.156s sys 0m0.100s Without second argument: amoura at amoura-laptop:~/cpython$ time ./python -c "import random; lst=list(range(1000000)); random.shuffle(lst); print (len(lst))" 1000000 real 0m13.783s user 0m13.609s sys 0m0.108s This could be because of the many tests of whether the 2nd argument is None in the loop. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 01:04:19 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 03 Sep 2012 23:04:19 +0000 Subject: [issue15837] Added test to test_random.py testing Random.shuffle In-Reply-To: <1346712956.3.0.326893344799.issue15837@psf.upfronthosting.co.za> Message-ID: <201209040204.04505.storchaka@gmail.com> Serhiy Storchaka added the comment: > This could be because of the many tests of whether the 2nd argument is None > in the loop. This is because Random._randbelow (and therefore randrange, randint) is relatively slow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 01:14:08 2012 From: report at bugs.python.org (Alessandro Moura) Date: Mon, 03 Sep 2012 23:14:08 +0000 Subject: [issue15837] Added test to test_random.py testing Random.shuffle In-Reply-To: <1346465179.1.0.118516816378.issue15837@psf.upfronthosting.co.za> Message-ID: <1346714048.88.0.629746439147.issue15837@psf.upfronthosting.co.za> Alessandro Moura added the comment: Yup. This is the result of simply eliminating the condition in the loop and just using the second argument (for the purposes of testing this only): amoura at amoura-laptop:~/cpython$ time ./python -c "import random; lst=list(range(1000000)); random.shuffle(lst,random.random); print (len(lst))" 1000000 real 0m7.330s user 0m7.148s sys 0m0.092s ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 01:25:05 2012 From: report at bugs.python.org (Ned Deily) Date: Mon, 03 Sep 2012 23:25:05 +0000 Subject: [issue15858] tarfile missing entries due to omitted uid/gid fields In-Reply-To: <1346701660.86.0.976031645545.issue15858@psf.upfronthosting.co.za> Message-ID: <1346714705.31.0.849215835434.issue15858@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +lars.gustaebel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 06:53:45 2012 From: report at bugs.python.org (The Written Word) Date: Tue, 04 Sep 2012 04:53:45 +0000 Subject: [issue15340] OSError with "import random" when /dev/urandom doesn't exist (regression from 2.6) In-Reply-To: <1342132229.15.0.69254682318.issue15340@psf.upfronthosting.co.za> Message-ID: <1346734425.07.0.0399867477052.issue15340@psf.upfronthosting.co.za> The Written Word added the comment: Hi Antoine, Thanks for the heads up. I've attached a revised patch that doesn't misuse PyErr_SetFromErrnoWithFilename. ---------- Added file: http://bugs.python.org/file27113/hash-randomization-not-implemented.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 07:24:43 2012 From: report at bugs.python.org (Campbell Barton) Date: Tue, 04 Sep 2012 05:24:43 +0000 Subject: [issue15859] PyUnicode_EncodeFSDefault win32 inconsistancy. Message-ID: <1346736283.51.0.0156916220677.issue15859@psf.upfronthosting.co.za> New submission from Campbell Barton: There is an inconsistency in PyUnicode_EncodeFSDefault(), on Linux its argument is checked to be unicode, and NULL is returned when its not. On windows however, this throws an assertion. The problem with this is, in some CAPI code you may pass an argument and check for NULL as an error case, and allow the python API's exception to be exposed to the script author. The problem here is a linux developer can use PyUnicode_EncodeFSDefault() this way, but not a windows developer. A simplified use case below of a case where PyUnicode_EncodeFSDefault would fail. Attached a fix so windows and posix systems behave the same. --- const char *PyC_UnicodeAsByte(PyObject *py_str, PyObject **coerce) { if (PyBytes_Check(py_str)) { return PyBytes_AS_STRING(py_str); } else if ((*coerce = PyUnicode_EncodeFSDefault(py_str))) { return PyBytes_AS_STRING(*coerce); } --- Also: heres a list to the bug report in blenders tracker, where the bug was found. https://projects.blender.org/tracker/index.php?func=detail&aid=31856&group_id=9&atid=498 ---------- files: fix_unicode.diff keywords: patch messages: 169816 nosy: ideasman42 priority: normal severity: normal status: open title: PyUnicode_EncodeFSDefault win32 inconsistancy. Added file: http://bugs.python.org/file27114/fix_unicode.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 07:25:03 2012 From: report at bugs.python.org (Campbell Barton) Date: Tue, 04 Sep 2012 05:25:03 +0000 Subject: [issue15859] PyUnicode_EncodeFSDefault win32 inconsistancy. In-Reply-To: <1346736283.51.0.0156916220677.issue15859@psf.upfronthosting.co.za> Message-ID: <1346736303.94.0.318122996597.issue15859@psf.upfronthosting.co.za> Changes by Campbell Barton : ---------- components: +Unicode, Windows nosy: +ezio.melotti versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 09:22:54 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 04 Sep 2012 07:22:54 +0000 Subject: [issue15340] OSError with "import random" when /dev/urandom doesn't exist (regression from 2.6) In-Reply-To: <1342132229.15.0.69254682318.issue15340@psf.upfronthosting.co.za> Message-ID: <1346743374.99.0.654052149155.issue15340@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 09:46:44 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 04 Sep 2012 07:46:44 +0000 Subject: [issue14774] _sysconfigdata.py doesn't support multiple build configurations In-Reply-To: <1336679254.12.0.498386228703.issue14774@psf.upfronthosting.co.za> Message-ID: <1346744804.84.0.544769050651.issue14774@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 09:47:20 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 04 Sep 2012 07:47:20 +0000 Subject: [issue15298] _sysconfigdata is generated in srcdir, not builddir In-Reply-To: <1341782776.55.0.708234468774.issue15298@psf.upfronthosting.co.za> Message-ID: <1346744840.57.0.239008169432.issue15298@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 09:47:54 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 04 Sep 2012 07:47:54 +0000 Subject: [issue15819] Unable to build Python out-of-tree when source tree is readonly. In-Reply-To: <1346309362.14.0.312540957077.issue15819@psf.upfronthosting.co.za> Message-ID: <1346744874.59.0.977484814336.issue15819@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 09:49:14 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 04 Sep 2012 07:49:14 +0000 Subject: [issue15833] most failures to write byte-compiled file no longer suppressed In-Reply-To: <1346432246.49.0.876284426658.issue15833@psf.upfronthosting.co.za> Message-ID: <1346744954.35.0.714960103966.issue15833@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 09:49:32 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 04 Sep 2012 07:49:32 +0000 Subject: [issue15838] make install tries to create lib2to3 grammar pickles in source directory In-Reply-To: <1346498804.77.0.811767404939.issue15838@psf.upfronthosting.co.za> Message-ID: <1346744972.35.0.739168107468.issue15838@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 09:51:36 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 04 Sep 2012 07:51:36 +0000 Subject: [issue15857] memoryview: complete support for struct packing/unpacking In-Reply-To: <1346689497.87.0.0543181973017.issue15857@psf.upfronthosting.co.za> Message-ID: <1346745096.26.0.404685232475.issue15857@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 09:59:57 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 04 Sep 2012 07:59:57 +0000 Subject: [issue15645] 2to3 Grammar pickles not created when upgrading to 3.3.0b2 In-Reply-To: <1344932180.41.0.826216341416.issue15645@psf.upfronthosting.co.za> Message-ID: <1346745597.97.0.883486130927.issue15645@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Is it really possible that the pickle is created after calculation of the wildcard expansion? The GNU make manual says that make will run multiple recipes in parallel when the -j option is used (that is, multiple targets are build at the same time), not that the commands in a recipe are run at the same time. That latter would break a lot of assumptions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 10:11:56 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 04 Sep 2012 08:11:56 +0000 Subject: [issue15838] make install tries to create lib2to3 grammar pickles in source directory In-Reply-To: <1346498804.77.0.811767404939.issue15838@psf.upfronthosting.co.za> Message-ID: <1346746316.21.0.851506483947.issue15838@psf.upfronthosting.co.za> Ronald Oussoren added the comment: FWIW the patch is issue15645 was a patch that fixed the issue with minimal changes, as it was created close to the first 3.3 release candidate I didn't want to change code when that could be avoided. A fix that writes the generated file into the build tree instead of the source tree requires changes to lib2to3.pgen.driver:load_grammar: it assumes it can derive the path of the pickle file from the path of the grammar file, which wouldn't be true when storing the pickle file in the build directory and the build directory is not the same as the source directory. Now that I look at this code again: the patch is issue15645 was probably make necessary by the introduction of $(PYTHON_FOR_BUILD), that expands to './$(BUILD_PYTHON) -E' on my machine, and that means the PYTHONPATH setting is ignored which is why the file is created in the source directory instead of the installation directory. This means it could be fairly easy to properly fix this issue: - Move the line back to the end of the libinstall recipe - Add "import sys, os; sys.path.insert(0, os.environ['PYTHONPATH']" to the start of the python scriptlet (before "import lib2to3....") I haven't tested yet if that actually works though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 11:13:27 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 04 Sep 2012 09:13:27 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1346750007.37.0.646094856625.issue2771@psf.upfronthosting.co.za> Ezio Melotti added the comment: test issue linking: issue1528167 issue 1528167 #1528167 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 11:27:07 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 04 Sep 2012 09:27:07 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1346750827.07.0.546134450112.issue15533@psf.upfronthosting.co.za> Andrew Svetlov added the comment: I believe it's trick for Tru64 platform. I've asked to support of this in python-dev. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 12:23:20 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 04 Sep 2012 10:23:20 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1346754200.88.0.314768181252.issue15533@psf.upfronthosting.co.za> Chris Jerdonek added the comment: For future reference, here is the beginning of the e-mail thread on python-dev: http://mail.python.org/pipermail/python-dev/2012-September/121584.html We also need to know whether the Tru64 trick needs to be used in 2.7, since this documentation issue also affects 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 12:58:44 2012 From: report at bugs.python.org (Tom Lynn) Date: Tue, 04 Sep 2012 10:58:44 +0000 Subject: [issue15858] tarfile missing entries due to omitted uid/gid fields In-Reply-To: <1346701660.86.0.976031645545.issue15858@psf.upfronthosting.co.za> Message-ID: <1346756324.92.0.378487426828.issue15858@psf.upfronthosting.co.za> Tom Lynn added the comment: I think the default has to be 0 for consistency with how other empty numeric fields are handled. In theory spaces and NULs are supposed to be equivalent terminators in numeric fields, but I've just noticed that plexus-archiver is also using leading spaces rather than leading zeros (against the spec), e.g. ' 10422\x00 '. tarfile currently supports this, which I think is good, so I think the right approach is to lstrip(' ') fields and then treat space as a terminator. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 13:10:26 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 04 Sep 2012 11:10:26 +0000 Subject: [issue15859] PyUnicode_EncodeFSDefault win32 inconsistancy. In-Reply-To: <1346736283.51.0.0156916220677.issue15859@psf.upfronthosting.co.za> Message-ID: <1346757026.49.0.157037533909.issue15859@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +haypo type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 13:16:51 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 04 Sep 2012 11:16:51 +0000 Subject: [issue15836] unittest assertRaises should verify excClass is actually a BaseException class In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za> Message-ID: <1346757411.24.0.106425998915.issue15836@psf.upfronthosting.co.za> Ezio Melotti added the comment: Would using assertRaises to test assertRaises in the tests be to meta? ---------- assignee: -> michael.foord _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 14:21:34 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 04 Sep 2012 12:21:34 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1346761294.85.0.330650517046.issue15533@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Andrew, I seem to be getting a test failure for test_executable_with_cwd() with your updated patch (the child process is outputting an absolute path rather than ''). I will update the patch to fix. There are also some stylistic changes I would like to make to the helper method (updated code comment, etc). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 14:48:31 2012 From: report at bugs.python.org (Julian Berman) Date: Tue, 04 Sep 2012 12:48:31 +0000 Subject: [issue11664] Add patch method to unittest.TestCase In-Reply-To: <1300999439.71.0.376555102459.issue11664@psf.upfronthosting.co.za> Message-ID: <1346762911.74.0.5004605574.issue11664@psf.upfronthosting.co.za> Changes by Julian Berman : ---------- nosy: +Julian _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 14:50:21 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 04 Sep 2012 12:50:21 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1346763021.18.0.342913876705.issue15533@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Here is an updated patch. The changes I made are: (1) Update code comments in _call_popen_and_assert(). (2) Fix test failure. (3) Rename _call_popen_and_assert() to _assert_cwd() since it is a simpler name and the old name did not reflect that the method is specific to the test_cwd_* methods. (4) Add _split_python_path() helper method so that we do not need to call os.path.realpath(sys.executable) in every method. Andrew, you can make changes re: Tru64 (removing old code, etc). Thanks. ---------- Added file: http://bugs.python.org/file27115/issue-15533-5-default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 15:07:00 2012 From: report at bugs.python.org (Julian Berman) Date: Tue, 04 Sep 2012 13:07:00 +0000 Subject: [issue15860] Use TestCase assertion methods in unittest.mock.assert* to make them easier to read Message-ID: <1346764020.36.0.830519299083.issue15860@psf.upfronthosting.co.za> New submission from Julian Berman: Mock's assertion failures can be extremely hard to read for a few reasons -- mostly the noisy default repr that mock objects have, but also because they don't give you the hints that `unittest.TestCase`'s `assert*` methods give you (things like diffing two lists for example). unittest.mock.Mock's `assert*` methods could hook into the TestCase's assertion methods if Mock either gained a MockInTestCase subclass or started taking an arg to `__init__` that was an instance of `TestCase`, so that `assert*` could then use the assertion methods on the instance. #11664 could (should) then obviously use this argument by default when patching. Another added advantage would be that the raised exception could then be `TestCase.failureException`, whatever that might be, rather than `AssertionError`, though I doubt that's that big a deal since that's usually a subclass of `AssertionError` I bet. ---------- components: Library (Lib) messages: 169826 nosy: Julian, michael.foord priority: normal severity: normal status: open title: Use TestCase assertion methods in unittest.mock.assert* to make them easier to read versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 15:07:54 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 04 Sep 2012 13:07:54 +0000 Subject: [issue15836] unittest assertRaises should verify excClass is actually a BaseException class In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za> Message-ID: <1346764074.72.0.0333815489765.issue15836@psf.upfronthosting.co.za> R. David Murray added the comment: Ezio: I don't really care whether or not it would be too meta, if you look at the two versions, it is a *lot* clearer what is being tested in the try/except version than it is in the assertRaises version. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 15:10:30 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 04 Sep 2012 13:10:30 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1346764230.3.0.214391624231.issue15831@psf.upfronthosting.co.za> Ezio Melotti added the comment: > Do we like how these look? Is the bare star notation too obscure? > > inspect.Signature.replace(*[, parameters][, return_annotation]) > inspect.Parameter.replace(*[, name][, kind][, default][, annotation]) Note that if possible, it's better to avoid using the [] and put the default values. However, in these cases the default value seems to be a _void placeholder. The star notation is OK, since it's valid Python. > I was curious what the preferred way to display the following is, > since I don't think any comma/bracket placement will work: > > ArgumentParser([description][, epilog][, prog][, usage][, add_help][, argument_default][, parents][, prefix_chars][, conflict_handler][, formatter_class]) If the default values are known you could use them, otherwise this signature looks OK to me. > (unless perhaps we use the construction "ArgumentParser(*[, > description][, epilog]....") This is OK too, as long as all the arguments (including 'description') are keyword-only. > I'm not sure how we want to handle this one using multiple signatures: > > multiprocessing.Process([group[, target[, name[, args[, kwargs]]]]], *, daemon=None) This is OK too. > I also noticed these more unusual signatures: > > urllib.request.urlopen(url, data=None[, timeout], *, cafile=None, capath=None, cadefault=True) > http.client.HTTPSConnection(host, port=None, key_file=None, cert_file=None[, strict[, timeout[, source_address]]], *, context=None, check_hostname=None) Here the args between [] probably have a placeholder default, or are obtained from somewhere else (e.g. from socket.getdefaulttimeout()). These signature, albeit a bit weird, are understandable IMHO, so, unless you find a better way to write them, I would leave them as they are. > By the way, is the * really necessary in these examples? If the args on the right of the * are keyword-only and the one on the left aren't, then yes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 15:12:32 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 04 Sep 2012 13:12:32 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1346764352.93.0.542977732256.issue15533@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Updating the patch again to tweak the original documentation change. I was concerned that the previous language could be construed to mean that Popen will look in *two* places for the executable (both relative to the current directory and relative to the cwd argument). The change I'm uploading makes this a little more clear. ---------- Added file: http://bugs.python.org/file27116/issue-15533-6-default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 15:14:54 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 04 Sep 2012 13:14:54 +0000 Subject: [issue15836] unittest assertRaises should verify excClass is actually a BaseException class In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za> Message-ID: <1346764494.94.0.38476537264.issue15836@psf.upfronthosting.co.za> Ezio Melotti added the comment: I missed the initial patch. What I was thinking about was to use simply with self.assertRaises(TypeError): self.assertRaises(1) instead of: + ctx = self.assertRaises(TypeError) + with ctx: + self.assertRaises(1) + self.assertIsInstance(ctx.exception, TypeError) or + try: + self.assertRaises(1) + self.fail("Expected TypeError") + except TypeError: + pass Unless I'm missing something, all these should be equivalent. You could even use assertRaisesRegex to check the error message if you think that's appropriate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 15:16:47 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 04 Sep 2012 13:16:47 +0000 Subject: [issue15860] Use TestCase assertion methods in unittest.mock.assert* to make them easier to read In-Reply-To: <1346764020.36.0.830519299083.issue15860@psf.upfronthosting.co.za> Message-ID: <1346764607.56.0.940793252119.issue15860@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 15:20:26 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 04 Sep 2012 13:20:26 +0000 Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7) In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za> Message-ID: <1346764826.06.0.59757322558.issue13241@psf.upfronthosting.co.za> Ronald Oussoren added the comment: The configure script for python 3.3 detects llvm-gcc and automatically selects clang when it is found. That seems to be the best feasible solution for this issue. I therefore propose to close this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 15:35:35 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 04 Sep 2012 13:35:35 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1346765735.9.0.940369831706.issue15831@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks for responding to all of those questions, Ezio. I will update the patch based on your responses. (Likely most of it will remain the same.) > Note that if possible, it's better to avoid using the [] and put the default > values. However, in these cases the default value seems to be a _void > placeholder. Yes, the defaults are "private" in those cases (and in I think pretty much all cases in the patch in which []'s rather than a default value are used to display keyword arguments). > > I was curious what the preferred way to display the following is, > > since I don't think any comma/bracket placement will work: > > > > ArgumentParser([description][, epilog][, prog][, usage][, add_help][, argument_default][, parents][, prefix_chars][, conflict_handler][, formatter_class]) > If the default values are known you could use them, otherwise this signature looks OK to me. The comma not being inside the first bracket is what I was concerned about here (which was the issue raised in the original comment). Using an initial * which you are okay with will address this. (And yes, they are all keyword arguments. In fact, the order of the arguments in the docs does not even match the order in the code.) > > By the way, is the * really necessary in these examples? > If the args on the right of the * are keyword-only and the one on the left aren't, then yes. Okay. I think what threw me is that I don't think we're consistently using the * throughout our docs to denote the beginning of keyword-only arguments. The ArgumentParser constructor above is just one example. So I wasn't sure if this notation was preferred or discouraged. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 16:00:23 2012 From: report at bugs.python.org (Lucas Sinclair) Date: Tue, 04 Sep 2012 14:00:23 +0000 Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7) In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za> Message-ID: <1346767223.09.0.0381826931219.issue13241@psf.upfronthosting.co.za> Lucas Sinclair added the comment: I agree to close the issue. I tried following the steps proposed here: http://docs.python.org/devguide/ And typed these two commands on a OS X 10.8.1 with XCode and command line tools installed. $ hg clone http://hg.python.org/cpython. $ run ./configure --with-pydebug && make -j2 Python built perfectly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 17:17:11 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 04 Sep 2012 15:17:11 +0000 Subject: [issue15859] PyUnicode_EncodeFSDefault win32 inconsistancy. In-Reply-To: <1346736283.51.0.0156916220677.issue15859@psf.upfronthosting.co.za> Message-ID: <1346771831.31.0.339123272579.issue15859@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Sounds reasonable to me. ---------- nosy: +pitrou stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 17:22:01 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 04 Sep 2012 15:22:01 +0000 Subject: [issue15841] Some StringIO and BytesIO methods can succeed after close In-Reply-To: <1346527132.85.0.102313792516.issue15841@psf.upfronthosting.co.za> Message-ID: <1346772121.64.0.713562887123.issue15841@psf.upfronthosting.co.za> Antoine Pitrou added the comment: A couple of nits about the docstrings: +PyDoc_STRVAR(stringio_seekable_doc, +"seekable() -> Bool. Returns True if IO object can be seeked."); First, "bool" should be lowercase. Also, in seekable(), "IO object" should be "the IO object". Otherwise, looks fine to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 18:26:15 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 04 Sep 2012 16:26:15 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1346775975.7.0.187768597721.issue15831@psf.upfronthosting.co.za> Ezio Melotti added the comment: > So I wasn't sure if this notation was preferred or discouraged. We are moving toward using the same signatures that we have in the Python code, but that doesn't always work (e.g. when the meaning of values changes depending on the number of args, when there's some trick with *args/**kwargs involved, when there are default placeholders, etc.). The single * is not so common (yet), and it might be difficult to understand for new users, that's why I said it's OK to leave it out in cases where all the args are keyword args and the [] are used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 20:04:32 2012 From: report at bugs.python.org (Alessandro Moura) Date: Tue, 04 Sep 2012 18:04:32 +0000 Subject: [issue15841] Some StringIO and BytesIO methods can succeed after close In-Reply-To: <1346527132.85.0.102313792516.issue15841@psf.upfronthosting.co.za> Message-ID: <1346781872.02.0.647974329247.issue15841@psf.upfronthosting.co.za> Alessandro Moura added the comment: Thanks. Here is the amended patch with your suggestions implemented. ---------- Added file: http://bugs.python.org/file27117/memoryio.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 21:09:23 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 04 Sep 2012 19:09:23 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1346785763.21.0.0972389676437.issue15533@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Updating the doc portion of the patch one more time. ---------- Added file: http://bugs.python.org/file27118/issue-15533-7-default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 23:41:43 2012 From: report at bugs.python.org (Bryan Oakley) Date: Tue, 04 Sep 2012 21:41:43 +0000 Subject: [issue15861] ttk.Treeview "unmatched open brace in list" Message-ID: <1346794903.35.0.326071924778.issue15861@psf.upfronthosting.co.za> New submission from Bryan Oakley: If you try to insert an item into the treeview, give it a tuple of values for the "values" attribute, and one of those values has unbalanced braces, you'll get an error "unmatched open brace in list" To reproduce: import Tkinter as tk import ttk root = tk.Tk() tree = ttk.Treeview(root) tree.insert("","end",values=("one","two","bam! {")) root.mainloop() ---------- components: Tkinter messages: 169839 nosy: Bryan.Oakley priority: normal severity: normal status: open title: ttk.Treeview "unmatched open brace in list" type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 4 23:43:34 2012 From: report at bugs.python.org (Cemal Duman) Date: Tue, 04 Sep 2012 21:43:34 +0000 Subject: [issue15862] IDLE not working when due to wrong Hard Drive point of os.path.expanduser Message-ID: <1346795014.76.0.789021764596.issue15862@psf.upfronthosting.co.za> New submission from Cemal Duman: Hi Unfortunately i'm using Vista on my corparate laptop I can open my Python CLI without any problem but IDLE is not responding. When i started idle.py by issuing following command: C:\Python27>python.exe Lib\idlelib\idle.py I see following output: C:\Python27> Warning: os.path.expanduser("~") points to H:\, but the path does not exist. H:\ is my network drive. When i run the os.path.expanduser("~") at CLI i get following directory. 'C:\\Users\\edumcem\' Thanks / Cemal ---------- components: IDLE messages: 169840 nosy: Cemal.Duman priority: normal severity: normal status: open title: IDLE not working when due to wrong Hard Drive point of os.path.expanduser versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 00:44:19 2012 From: report at bugs.python.org (Alexander Konovalenko) Date: Tue, 04 Sep 2012 22:44:19 +0000 Subject: [issue15863] Fine-grained info about Python versions which support changes introduced in micro releases Message-ID: <1346798659.62.0.336544157965.issue15863@psf.upfronthosting.co.za> New submission from Alexander Konovalenko: Some security fixes and bug fixes that are simultaneously issued for multiple Python versions require changes to the documentation. I'm now looking at the hash randomization vulnerability that was fixed in 2.6.8 and 2.7.3. The docs always mention the release in which a new feature was added. That's great. But for a security fix such as the bug in question, the set of versions which support it doesn't look like "2.x.y or later". The documentation for the -R command-line option and the PYTHONHASHSEED environment variable says "New in version 2.6.8". A reader who is not familiar with the context would infer that those feature are supported in Python 2.7 through 2.7.2, which is not the case. The docs should say "New in version 2.6.8 and 2.7.3". http://docs.python.org/using/cmdline.html#cmdoption-R http://docs.python.org/using/cmdline.html#envvar-PYTHONHASHSEED The documentation for the sys.flags.hash_randomization attribute says "New in version 2.7.3". Again, that leaves out the version 2.6.8 and future versions in the 2.6.x branch, which presumably support the new attribute. The docs should say "New in version 2.6.8 and 2.7.3". http://docs.python.org/library/sys.html#sys.flags Disclaimer: I did not test the relevant micro releases to see whether they actually support those features. Just checked the release dates and applied common sense. If you know of any other micro release bugfixes that were mentioned in the docs, the same considerations apply to them. Please verify the docs are correct, fix them or file appropriate bugs. ---------- assignee: docs at python components: Documentation messages: 169841 nosy: alexkon, docs at python priority: normal severity: normal status: open title: Fine-grained info about Python versions which support changes introduced in micro releases versions: Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 00:59:35 2012 From: report at bugs.python.org (Daniel Wagner-Hall) Date: Tue, 04 Sep 2012 22:59:35 +0000 Subject: [issue15864] Package cache doesn't cache packages with overlapping sys.path entries Message-ID: <1346799575.05.0.866449286676.issue15864@psf.upfronthosting.co.za> New submission from Daniel Wagner-Hall: Importing the same module twice should only execute its code once, and should only lead to one copy of the classes defined in the module's file. If a subdirectory of $PWD is on $PYTHONPATH, and a package is imported both relative to $PWD and relative to that subdirectory, its code is loaded twice, and its classes are defined twice independently. Downloading the attached file, and running: mkdir folder cd folder tar xf file.tgz PYTHONPATH=$(pwd)/package python main.py should print import once, but does print import twice. ---------- files: packageissue.tgz messages: 169842 nosy: daniel.wagner-hall priority: normal severity: normal status: open title: Package cache doesn't cache packages with overlapping sys.path entries type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file27119/packageissue.tgz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 01:00:51 2012 From: report at bugs.python.org (Roger Serwy) Date: Tue, 04 Sep 2012 23:00:51 +0000 Subject: [issue15862] IDLE not working when due to wrong Hard Drive point of os.path.expanduser In-Reply-To: <1346795014.76.0.789021764596.issue15862@psf.upfronthosting.co.za> Message-ID: <1346799651.29.0.656374950061.issue15862@psf.upfronthosting.co.za> Roger Serwy added the comment: IDLE not responding is likely due to Issue13582, since the warning message would cause IDLE to terminate abruptly when launched with pythonw.exe. What does os.path.expanduser("~") evaluate to when executed from the IDLE shell? ---------- nosy: +serwy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 01:17:16 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 04 Sep 2012 23:17:16 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1346800636.91.0.980405189382.issue15831@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attaching an updated patch after doing another pass at the code and in light of Ezio's comments. Let me know if and when you'd like me to prepare separate patches for 2.7 and 3.2. ---------- Added file: http://bugs.python.org/file27120/issue-15831-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 01:31:47 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 04 Sep 2012 23:31:47 +0000 Subject: [issue15841] Some StringIO and BytesIO methods can succeed after close In-Reply-To: <1346527132.85.0.102313792516.issue15841@psf.upfronthosting.co.za> Message-ID: <1346801507.76.0.565196462272.issue15841@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Alessandro, have you already signed a contributor agreement so that your patch can be integrated? If not, you'll find the instructions at http://www.python.org/psf/contrib/ Thank you! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 01:45:14 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 04 Sep 2012 23:45:14 +0000 Subject: [issue15864] Package cache doesn't cache packages with overlapping sys.path entries In-Reply-To: <1346799575.05.0.866449286676.issue15864@psf.upfronthosting.co.za> Message-ID: <1346802314.0.0.202087026305.issue15864@psf.upfronthosting.co.za> R. David Murray added the comment: Unless I misunderstand you, you are importing the module using two different names, so loading it twice would be the correct behavior. That is, 'foo.bar.baz' is a different thing from 'bar.baz' from Python's point of view. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 01:47:43 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 04 Sep 2012 23:47:43 +0000 Subject: [issue15864] Package cache doesn't cache packages with overlapping sys.path entries In-Reply-To: <1346799575.05.0.866449286676.issue15864@psf.upfronthosting.co.za> Message-ID: <1346802463.22.0.394127957134.issue15864@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Agreed, I don't think this is a bug. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 01:57:32 2012 From: report at bugs.python.org (Daniel Wagner-Hall) Date: Tue, 04 Sep 2012 23:57:32 +0000 Subject: [issue15864] Package cache doesn't cache packages with overlapping sys.path entries In-Reply-To: <1346799575.05.0.866449286676.issue15864@psf.upfronthosting.co.za> Message-ID: <1346803052.68.0.0938995143861.issue15864@psf.upfronthosting.co.za> Daniel Wagner-Hall added the comment: That is indeed the behaviour I'm talking about. In particular I came across this where two libraries imported an exception type using different sys.path traversals, which both led to the same file, and a try-catch didn't catch the exception because it had a different type (even though it had been defined by the same file). This was a pretty horrible bug to track down. That said, messing with sys.path is pretty ugly, so I can see why this would be intentional, but it still feels like the the types of the same class, defined by the same file, should be equal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 02:06:44 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 05 Sep 2012 00:06:44 +0000 Subject: [issue15864] Package cache doesn't cache packages with overlapping sys.path entries In-Reply-To: <1346799575.05.0.866449286676.issue15864@psf.upfronthosting.co.za> Message-ID: <1346803604.98.0.164142909939.issue15864@psf.upfronthosting.co.za> R. David Murray added the comment: It isn't the file things are defined in that matters, it is how the module object is named. As I said, foo.bar.baz and bar.baz are different objects from Python's point of view, as you found out. ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 02:42:31 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 05 Sep 2012 00:42:31 +0000 Subject: [issue15865] reflect bare star * in function signature documentation Message-ID: <1346805751.63.0.697181229134.issue15865@psf.upfronthosting.co.za> New submission from Chris Jerdonek: This issue is to make sure that the bare * in the function signatures of pure Python functions is properly reflected in the documentation. This will bring the signatures in the documentation closer to the signatures that we have in the Python code -- a goal articulated by Ezio in a comment to issue 15831. For example, configparser.RawConfigParser() has this function signature: def __init__(self, defaults=None, dict_type=_default_dict, allow_no_value=False, *, delimiters=('=', ':'), comment_prefixes=('#', ';'), inline_comment_prefixes=None, strict=True, empty_lines_in_values=True, default_section=DEFAULTSECT, interpolation=_UNSET): But its documentation has no *: class configparser.RawConfigParser(defaults=None, dict_type=collections.OrderedDict, allow_no_value=False, delimiters=('=', ':'), comment_prefixes=('#', ';'), inline_comment_prefixes=None, strict=True, empty_lines_in_values=True, default_section=configaparser.DEFAULTSECT, interpolation=None) (from http://docs.python.org/dev/library/configparser.html#configparser.RawConfigParser ) >From a search of the code, there are about 60 occurrences of a bare * in the signature of a pure Python function (not all of which will need to be updated). ---------- assignee: docs at python components: Documentation keywords: easy messages: 169850 nosy: cjerdonek, docs at python, ezio.melotti priority: normal severity: normal status: open title: reflect bare star * in function signature documentation type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 02:46:11 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 05 Sep 2012 00:46:11 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1346805971.38.0.50307686655.issue15831@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > We are moving toward using the same signatures that we have in the Python code.... The single * is not so common (yet), I created issue 15865 to add the single * to the documentation where appropriate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 03:02:53 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 05 Sep 2012 01:02:53 +0000 Subject: [issue15853] IDLE crashes selecting Preferences menu with OS X ActiveState Tcl/Tk 8.5.12.1 In-Reply-To: <1346632042.85.0.745944196118.issue15853@psf.upfronthosting.co.za> Message-ID: <1346806973.33.0.172603728846.issue15853@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I'm observed this happening on a number of machines at my client's site. It started about three weeks ago and has not stopped (even with fresh installs of Py2.7.3 and ActiveTCL). I've not been able to figure-out why it affects some machines and not others. It can happen on 10.6, 10.7, and 10.8. I've hypothesized that some boxes have different XCode updates than others. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 03:06:25 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 05 Sep 2012 01:06:25 +0000 Subject: [issue15626] unittest.main negates -bb option and programmatic warning configuration In-Reply-To: <1344730376.57.0.519562827761.issue15626@psf.upfronthosting.co.za> Message-ID: <1346807185.33.0.131085826996.issue15626@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 03:42:00 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 05 Sep 2012 01:42:00 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za> Message-ID: <1346809320.02.0.957782828783.issue15510@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I responded to David's comments on the review tool. Later today I will update the patch in response to his comments (accommodating all of his suggestions) along with a couple other changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 04:53:09 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 05 Sep 2012 02:53:09 +0000 Subject: [issue15837] Added test to test_random.py testing Random.shuffle In-Reply-To: <1346465179.1.0.118516816378.issue15837@psf.upfronthosting.co.za> Message-ID: <1346813589.22.0.776676584375.issue15837@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 05:11:30 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 05 Sep 2012 03:11:30 +0000 Subject: [issue15837] Added test to test_random.py testing Random.shuffle In-Reply-To: <1346465179.1.0.118516816378.issue15837@psf.upfronthosting.co.za> Message-ID: <1346814690.59.0.269321977281.issue15837@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The patch look fine as-is and it can be applied in 3.4. (BTW, I miss having a Resolution status of Accepted, meaning that the patch passed review and is ready to apply). FWIW, I'll remove the int=int optimization in Py3.4. It doesn't provide much benefit anymore. ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 05:45:03 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 05 Sep 2012 03:45:03 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za> Message-ID: <1346816703.05.0.756682503947.issue15510@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, I agree that the existing behavior should not be changed. Most likely, a change would break some code that is currently working, and there would be little to no gain. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 06:50:09 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 05 Sep 2012 04:50:09 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za> Message-ID: <1346820609.33.0.945313254424.issue15510@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attaching an updated patch as promised in my previous comment. Note that I removed two edge test cases pertaining to leading whitespace. I would rather discuss those cases as part of a different issue to avoid making this thread even longer (and it is off the topic of the original issue). ---------- Added file: http://bugs.python.org/file27121/issue-15510-5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 07:10:56 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 05 Sep 2012 05:10:56 +0000 Subject: [issue15457] consistent treatment of generator terminology In-Reply-To: <1343302676.51.0.168761959505.issue15457@psf.upfronthosting.co.za> Message-ID: <1346821856.08.0.0600570684007.issue15457@psf.upfronthosting.co.za> Chris Jerdonek added the comment: This slipped under my radar. After starting work on this again, I realize that it would make sense to complete issue 15476 first. The reason is that it would improve the process of referencing "code object" in the generator docs (Terry's suggestion) once "code object" is itself properly documented. ---------- dependencies: +Add "code object" to glossary _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 07:12:57 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 05 Sep 2012 05:12:57 +0000 Subject: [issue15476] Add "code object" to glossary In-Reply-To: <1343459471.56.0.370073010984.issue15476@psf.upfronthosting.co.za> Message-ID: <1346821977.24.0.612882842936.issue15476@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I am starting work on this in the next couple days. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 07:35:01 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 05 Sep 2012 05:35:01 +0000 Subject: [issue15476] Add "code object" to glossary In-Reply-To: <1343459471.56.0.370073010984.issue15476@psf.upfronthosting.co.za> Message-ID: <1346823301.32.0.552909563633.issue15476@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I disagree that this should be added. The glossary is not intended to be a dictionary of every possible concept. Ideally, it should remain short enough so that it can be read in a single sitting. Making the docs fatter doesn't make them better. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 07:41:25 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 05 Sep 2012 05:41:25 +0000 Subject: [issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite In-Reply-To: <1242857063.47.0.919073638283.issue6074@psf.upfronthosting.co.za> Message-ID: <1346823685.05.0.842006526461.issue6074@psf.upfronthosting.co.za> Eric Snow added the comment: Well, the workflow on Windows is certainly different. I've run out of time to get this sorted out in the short term. However, the patch should be pretty close to what's needed. Obviously the posix-only bit doesn't fit for a Windows-specific test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 08:01:42 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 05 Sep 2012 06:01:42 +0000 Subject: [issue15476] Add "code object" to glossary In-Reply-To: <1343459471.56.0.370073010984.issue15476@psf.upfronthosting.co.za> Message-ID: <1346824902.67.0.860978238097.issue15476@psf.upfronthosting.co.za> Chris Jerdonek added the comment: That's fine by me. I guess what's more important to me is that "code object" have a central, linkable definition *somewhere* (and not necessarily that this somewhere be a glossary entry). That way references to code object in the docs can link to a definition in the same way that we link to definitions of other words, functions, etc. I was also planning on indexing the word more properly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 09:15:54 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 05 Sep 2012 07:15:54 +0000 Subject: [issue15861] ttk.Treeview "unmatched open brace in list" In-Reply-To: <1346794903.35.0.326071924778.issue15861@psf.upfronthosting.co.za> Message-ID: <1346829354.34.0.700842322089.issue15861@psf.upfronthosting.co.za> Ned Deily added the comment: What behavior do you expect? By accident, I found your reply to this StackOverflow question. I take it from that that you think tkinter should be quoting curly braces found in strings. If that is what you mean, can you specify the set of characters that need to be escaped and in what contexts? http://stackoverflow.com/questions/11566299/unmatched-open-brace-error-when-adding-item-to-ttk-treeview ---------- nosy: +asvetlov, ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 10:49:37 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 05 Sep 2012 08:49:37 +0000 Subject: [issue15853] IDLE crashes selecting Preferences menu with OS X ActiveState Tcl/Tk 8.5.12.1 In-Reply-To: <1346632042.85.0.745944196118.issue15853@psf.upfronthosting.co.za> Message-ID: <1346834977.52.0.838499381132.issue15853@psf.upfronthosting.co.za> Ned Deily added the comment: The problem is a regression in the latest version of ActiveTcl 8.5 for OS X, specifically 8.5.12.1 (and I believe the previous version 8.5.12.0). It has nothing directly to do with Python or how you might build Python other than whether _tkinter.so dynamically links with /Library/Frameworks/Tcl.framework/Verisons/8.5 and /Library/Framework/Tk.framework/Verisons/8.5 (the locations where ActiveTcl install) as opposed to /System/Library/Frameworks/Tcl.framework/... and /System/Library/Frameworks/Tk.framework/..., the Apple-supplied versions. And, if so, which version of ActiveTcl you have installed. The python.org 64-bit Pythons are vulnerable, the 32-bit-obly ones are not because they link with Tcl/Tk 8.4. Unfortunately, ActiveState only makes available the most recent version of ActiveTcl on its Community Edition pages, so, unless you have access to a copy of an older version of ActiveTcl (like 8.5.11.1, the previous version), you're kind of stuck with the behavior, unless you remove ActiveTcl 8.5 and revert to Apple's Tk which is vulnerable to other crashes that have been fixed in ActiveState's (and is totally broken in OS X 10.6). Or you use the 32-bit installer and Tcl/Tk 8.4. Or you build your own version of Tcl/Tk 8.5 (I've stared looking at that). By the way, ActiveState's own ActivePython 2.7 also crashes the same way when using 8.5.12.x. I've pinged the Tcl Mac mailing list. Unless there's an immediate fix, I'll see what I can find in Tk. http://permalink.gmane.org/gmane.comp.lang.tcl.mac/7080 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 11:38:58 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 05 Sep 2012 09:38:58 +0000 Subject: [issue15865] reflect bare star * in function signature documentation In-Reply-To: <1346805751.63.0.697181229134.issue15865@psf.upfronthosting.co.za> Message-ID: <1346837938.52.0.206187782265.issue15865@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +eric.araujo, georg.brandl stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 12:26:35 2012 From: report at bugs.python.org (Alessandro Moura) Date: Wed, 05 Sep 2012 10:26:35 +0000 Subject: [issue15841] Some StringIO and BytesIO methods can succeed after close In-Reply-To: <1346527132.85.0.102313792516.issue15841@psf.upfronthosting.co.za> Message-ID: <1346840795.82.0.394354631711.issue15841@psf.upfronthosting.co.za> Alessandro Moura added the comment: I just emailed my contributor's agreement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 12:55:03 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 05 Sep 2012 10:55:03 +0000 Subject: [issue15298] _sysconfigdata is generated in srcdir, not builddir In-Reply-To: <1341782776.55.0.708234468774.issue15298@psf.upfronthosting.co.za> Message-ID: <1346842503.06.0.268118700396.issue15298@psf.upfronthosting.co.za> Richard Oudkerk added the comment: If sysconfig._generate_posix_vars() creates the build directory and pybuilddir.txt (instead of setup.py) then it could write _sysconfigdata.py in the correct place. Then setup.py would not have to mess with its own sys.path. One issue with having _sysconfigdata.py in the build dir is that distutils copies it (along with everything else in the build dir) to .../lib/python3.x/lib-dynload. So I think Matthias' patch results in two copies of _sysconfigdata.py being installed (plus __pycache__/_sysconfigdata.pyc). ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 13:08:17 2012 From: report at bugs.python.org (Bryan Oakley) Date: Wed, 05 Sep 2012 11:08:17 +0000 Subject: [issue15861] ttk.Treeview "unmatched open brace in list" In-Reply-To: <1346794903.35.0.326071924778.issue15861@psf.upfronthosting.co.za> Message-ID: <1346843297.53.0.490321741119.issue15861@psf.upfronthosting.co.za> Bryan Oakley added the comment: What behavior do I expect? I expect it to not throw an error. I expect whatever string I give to be inserted into the widget unadulterated (ie: if I give the string "foo {" I expect to see "foo {" in the widget). Tkinter is effectively telling me "you have a Tcl syntax error". Since I'm programming in python I should be insulated from that, particularly since the error comes internally after Tkinter transforms my data. How Tkinter does it under the hood, I don't care. Tkinter should make sure that the data it passes to the Tcl interpreter is well-formed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 13:37:17 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 05 Sep 2012 11:37:17 +0000 Subject: [issue15861] ttk.Treeview "unmatched open brace in list" In-Reply-To: <1346794903.35.0.326071924778.issue15861@psf.upfronthosting.co.za> Message-ID: <1346845037.88.0.845856678239.issue15861@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 14:03:44 2012 From: report at bugs.python.org (Jason R. Coombs) Date: Wed, 05 Sep 2012 12:03:44 +0000 Subject: [issue14847] AttributeError: NoneType has no attribute 'utf_8_decode' In-Reply-To: <1337311331.2.0.610588604888.issue14847@psf.upfronthosting.co.za> Message-ID: <1346846624.65.0.928606399714.issue14847@psf.upfronthosting.co.za> Jason R. Coombs added the comment: I've removed the invocation of the wrapper code in our project, but the issue has not exhibited itself. This leads me to suspect a few possibilities of things that have changed since we had the issue in June: 1) Distribute was updated with its fix for this issue. I don't expect that code was being called in our application, but I didn't strictly rule it out. 2) The application launcher was changed. The old system was fork-based and used pkg_resources and multi-installed packages. The modern deployment is a simple, pip-installed process. 3) The code underwent other unrelated but substantial changes. So although I thought I was on to something when I added the wrapper, suppressing the error, I was never able to detect it, and it seems to have gone away now. I was hoping this would shed more light on the problem and describe another use case, but at this point, that may not happen. Unless the problem recurs in our application, or we have another application where the problem arises, I'll focus on the Python side as suggested by Amaury. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 14:18:50 2012 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Wed, 05 Sep 2012 12:18:50 +0000 Subject: [issue15858] tarfile missing entries due to omitted uid/gid fields In-Reply-To: <1346701660.86.0.976031645545.issue15858@psf.upfronthosting.co.za> Message-ID: <1346847530.91.0.722051192067.issue15858@psf.upfronthosting.co.za> Lars Gust?bel added the comment: Could you provide some sample data and code? I see the problem, but I cannot quite reproduce the behaviour you describe. In all of my testcases tarfile either throws an exception or successfully reads the archive, but never silently stops. ---------- assignee: -> lars.gustaebel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 15:01:40 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 05 Sep 2012 13:01:40 +0000 Subject: [issue15298] _sysconfigdata is generated in srcdir, not builddir In-Reply-To: <1341782776.55.0.708234468774.issue15298@psf.upfronthosting.co.za> Message-ID: <1346850100.49.0.285592527541.issue15298@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Alternative patch. ---------- Added file: http://bugs.python.org/file27122/alt_sysconfigdata.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 15:06:16 2012 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 05 Sep 2012 13:06:16 +0000 Subject: [issue15861] ttk.Treeview "unmatched open brace in list" In-Reply-To: <1346794903.35.0.326071924778.issue15861@psf.upfronthosting.co.za> Message-ID: <1346850376.85.0.509703046773.issue15861@psf.upfronthosting.co.za> Eric V. Smith added the comment: I agree with Bryan. Further, if the string is being interpreted as Tcl, then this strikes me as a possible injection attack vector (although I'll admit to not having looked at the code to see how the Tcl code is being used and/or interpreted). ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 16:25:51 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 05 Sep 2012 14:25:51 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1346855151.69.0.197052377927.issue15533@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Here is a proposed patch that attempts to minimize the chance of test breakage for Tru64. The patch follows Martin's recommendation on python-dev of being cautious by following existing code. ---------- Added file: http://bugs.python.org/file27123/issue-15533-8-default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 16:49:02 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 05 Sep 2012 14:49:02 +0000 Subject: [issue15865] reflect bare star * in function signature documentation In-Reply-To: <1346805751.63.0.697181229134.issue15865@psf.upfronthosting.co.za> Message-ID: <1346856542.12.0.696806071061.issue15865@psf.upfronthosting.co.za> ?ric Araujo added the comment: So is the root problem that Sphinx does not handle keyword-only arguments? ---------- versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 16:52:45 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 05 Sep 2012 14:52:45 +0000 Subject: [issue15298] _sysconfigdata is generated in srcdir, not builddir In-Reply-To: <1341782776.55.0.708234468774.issue15298@psf.upfronthosting.co.za> Message-ID: <1346856765.8.0.846430268945.issue15298@psf.upfronthosting.co.za> ?ric Araujo added the comment: I did not test the patch but it does not look bad. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 16:58:47 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 05 Sep 2012 14:58:47 +0000 Subject: [issue15865] reflect bare star * in function signature documentation In-Reply-To: <1346805751.63.0.697181229134.issue15865@psf.upfronthosting.co.za> Message-ID: <1346857127.32.0.662111629318.issue15865@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > So is the root problem that Sphinx does not handle keyword-only arguments? I don't think so. Sphinx renders the * just fine. It's just that in some of the reST files, the * was left out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 17:19:36 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 05 Sep 2012 15:19:36 +0000 Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7) In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za> Message-ID: <1346858376.34.0.0878884089852.issue13241@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I've closed the issue as 'wont fix' because llvm-gcc will miscompile 3.3 due to bugs in that compiler. CPython won't work around that compiler bug (if that's even possible). The workaround: use clang to compile (and on older OSX releases use a different version of GCC that doesn't use the LLVM backend). ---------- resolution: -> wont fix stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 17:30:54 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 05 Sep 2012 15:30:54 +0000 Subject: [issue15865] reflect bare star * in function signature documentation In-Reply-To: <1346805751.63.0.697181229134.issue15865@psf.upfronthosting.co.za> Message-ID: <1346859054.34.0.606368381806.issue15865@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Actually, it looks like configparser is the *only* file with missing single *'s. :) However, I did find a few other typos in the process of checking those signatures in the other files. Patch attached. ---------- keywords: +patch Added file: http://bugs.python.org/file27124/issue-15865-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 17:35:03 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 05 Sep 2012 15:35:03 +0000 Subject: [issue15861] ttk.Treeview "unmatched open brace in list" In-Reply-To: <1346794903.35.0.326071924778.issue15861@psf.upfronthosting.co.za> Message-ID: <1346859303.8.0.286333496912.issue15861@psf.upfronthosting.co.za> Ned Deily added the comment: I agree as well. The bigger question is, as Eric suggests, is this the only such case when mapping between Python and Tcl elements? Since Bryan is a well-known Tcl and Tkinter expert, his insights on that would be very useful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 17:35:30 2012 From: report at bugs.python.org (Matthias Klose) Date: Wed, 05 Sep 2012 15:35:30 +0000 Subject: [issue15298] _sysconfigdata is generated in srcdir, not builddir In-Reply-To: <1341782776.55.0.708234468774.issue15298@psf.upfronthosting.co.za> Message-ID: <1346859330.66.0.569618235502.issue15298@psf.upfronthosting.co.za> Matthias Klose added the comment: looks ok, two issues are: builddir should have added +("-pydebug" if hasattr(sys, "gettotalrefcount") else "") the installation installs this to the lib-dynload directory, which maybe is not desired. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 17:38:03 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 05 Sep 2012 15:38:03 +0000 Subject: [issue15865] reflect bare star * in function signature documentation In-Reply-To: <1346805751.63.0.697181229134.issue15865@psf.upfronthosting.co.za> Message-ID: <1346859483.42.0.318615621731.issue15865@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- keywords: +needs review stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 18:33:22 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 05 Sep 2012 16:33:22 +0000 Subject: [issue15775] Add StopParser() to expat In-Reply-To: <1345796297.89.0.127411549702.issue15775@psf.upfronthosting.co.za> Message-ID: <1346862802.56.0.69160861558.issue15775@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Below is a sample script that shows that it's possible to stop parsing XML in the middle, without an explicit call to XML_StopParser(): raise StopParsing from any handler, and catch it around the Parse() call. This method covers the two proposed use cases. Do we need another way to do it? import xml.parsers.expat class StopParsing(Exception): pass def findFirstElementByName(data, what): def end_element(name): if name == what: raise StopParsing(name) p = xml.parsers.expat.ParserCreate() p.EndElementHandler = end_element try: p.Parse(data, True) except StopParsing as e: print "Element found:", e else: print "Element not found" data = """ Text goes here More text """ findFirstElementByName(data, "child2") # Found findFirstElementByName(data, "child3") # Not found ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 18:55:34 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 05 Sep 2012 16:55:34 +0000 Subject: [issue15298] _sysconfigdata is generated in srcdir, not builddir In-Reply-To: <1341782776.55.0.708234468774.issue15298@psf.upfronthosting.co.za> Message-ID: <1346864134.48.0.412906007408.issue15298@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > builddir should have added > +("-pydebug" if hasattr(sys, "gettotalrefcount") else "") Oops, yes. > the installation installs this to the lib-dynload directory, which > maybe is not desired. The lines + -rm $(DESTDIR)$(DESTSHARED)/_sysconfigdata.py + -rm -r $(DESTDIR)$(DESTSHARED)/__pycache__ in the patch remove them from lib-dynload. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 19:01:28 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 05 Sep 2012 17:01:28 +0000 Subject: [issue15298] _sysconfigdata is generated in srcdir, not builddir In-Reply-To: <1341782776.55.0.708234468774.issue15298@psf.upfronthosting.co.za> Message-ID: <1346864488.77.0.0938799427904.issue15298@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Updated patch. ---------- Added file: http://bugs.python.org/file27125/alt_sysconfigdata.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 19:02:41 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 05 Sep 2012 17:02:41 +0000 Subject: [issue15298] _sysconfigdata is generated in srcdir, not builddir In-Reply-To: <1341782776.55.0.708234468774.issue15298@psf.upfronthosting.co.za> Message-ID: <1346864561.03.0.81954303715.issue15298@psf.upfronthosting.co.za> Changes by Richard Oudkerk : Removed file: http://bugs.python.org/file27125/alt_sysconfigdata.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 19:04:58 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 05 Sep 2012 17:04:58 +0000 Subject: [issue15298] _sysconfigdata is generated in srcdir, not builddir In-Reply-To: <1341782776.55.0.708234468774.issue15298@psf.upfronthosting.co.za> Message-ID: <1346864698.81.0.53888283587.issue15298@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Try again. ---------- Added file: http://bugs.python.org/file27126/alt_sysconfigdata.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 19:05:44 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 05 Sep 2012 17:05:44 +0000 Subject: [issue15298] _sysconfigdata is generated in srcdir, not builddir In-Reply-To: <1341782776.55.0.708234468774.issue15298@psf.upfronthosting.co.za> Message-ID: <1346864744.82.0.368417267449.issue15298@psf.upfronthosting.co.za> Changes by Richard Oudkerk : Added file: http://bugs.python.org/file27127/alt_sysconfigdata.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 19:05:55 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 05 Sep 2012 17:05:55 +0000 Subject: [issue15298] _sysconfigdata is generated in srcdir, not builddir In-Reply-To: <1341782776.55.0.708234468774.issue15298@psf.upfronthosting.co.za> Message-ID: <1346864755.31.0.282852882071.issue15298@psf.upfronthosting.co.za> Changes by Richard Oudkerk : Removed file: http://bugs.python.org/file27126/alt_sysconfigdata.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 19:06:04 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 05 Sep 2012 17:06:04 +0000 Subject: [issue15298] _sysconfigdata is generated in srcdir, not builddir In-Reply-To: <1341782776.55.0.708234468774.issue15298@psf.upfronthosting.co.za> Message-ID: <1346864764.11.0.504845355276.issue15298@psf.upfronthosting.co.za> Changes by Richard Oudkerk : Removed file: http://bugs.python.org/file27122/alt_sysconfigdata.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 19:57:55 2012 From: report at bugs.python.org (Alessandro Moura) Date: Wed, 05 Sep 2012 17:57:55 +0000 Subject: [issue15842] Some SocketIO methods can succeed after close() In-Reply-To: <1346527213.21.0.243179396441.issue15842@psf.upfronthosting.co.za> Message-ID: <1346867875.65.0.650406390693.issue15842@psf.upfronthosting.co.za> Alessandro Moura added the comment: This patch fixes the problem, making those methods raise a ValueError exception after close. I also added one test case for this issue. ---------- keywords: +patch nosy: +eng793 Added file: http://bugs.python.org/file27128/socket.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 20:20:51 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 05 Sep 2012 18:20:51 +0000 Subject: [issue15841] Some StringIO and BytesIO methods can succeed after close In-Reply-To: <1346527132.85.0.102313792516.issue15841@psf.upfronthosting.co.za> Message-ID: <3XBtWj5XX3zPS8@mail.python.org> Roundup Robot added the comment: New changeset 524931e5aebf by Antoine Pitrou in branch '3.2': Issue #15841: The readable(), writable() and seekable() methods of BytesIO http://hg.python.org/cpython/rev/524931e5aebf New changeset fcf097cb5f6b by Antoine Pitrou in branch 'default': Issue #15841: The readable(), writable() and seekable() methods of BytesIO http://hg.python.org/cpython/rev/fcf097cb5f6b New changeset d0ab34d4c733 by Antoine Pitrou in branch '2.7': Issue #15841: The readable(), writable() and seekable() methods of io.BytesIO http://hg.python.org/cpython/rev/d0ab34d4c733 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 20:21:33 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 05 Sep 2012 18:21:33 +0000 Subject: [issue15841] Some StringIO and BytesIO methods can succeed after close In-Reply-To: <1346527132.85.0.102313792516.issue15841@psf.upfronthosting.co.za> Message-ID: <1346869293.81.0.0879773886363.issue15841@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I have now committed the patch. Thank you again! ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 20:54:34 2012 From: report at bugs.python.org (Wim) Date: Wed, 05 Sep 2012 18:54:34 +0000 Subject: [issue15866] encode(..., 'xmlcharrefreplace') produces entities for surrogate pairs Message-ID: <1346871274.13.0.653364801762.issue15866@psf.upfronthosting.co.za> New submission from Wim: Encoding a (well-formed) Unicode string containing a non-BMP character, using the xmlcharrefreplace error handler, will produce two XML entities for surrogate codepoints instead of one entity for the actual character. Here's a transcript (Python 2.7.3, x86_64): >>> b = '\xf0\x9f\x92\x9d' >>> u = b.decode('utf8') >>> u u'\U0001f49d' >>> u.encode('ascii', errors='xmlcharrefreplace') '��' >>> ( u'\U0001f49d' ).encode('ascii', errors='xmlcharrefreplace') '��' >>> list(u) [u'\ud83d', u'\udc9d'] >>> u.encode('utf8', errors='xmlcharrefreplace') '\xf0\x9f\x92\x9d' The utf8 bytestring is correctly decoded, and the print representation shows one single Unicode character. Encoding using xmlcharrefreplace produces two XML entities, which is wrong[1]: a single non-BMP character should be represented in XML as a single entity reference, in this case presumably '💝'. As the last two lines show, I'm using a narrow build (so the unicode strings are represented internally in UTF-16, I guess). Converting the string back to utf8 does the right thing, and emits a single UTF8 sequence representing the supplementary-plane codepoint. (FWIW, the backslashreplace error handler also emits a surrogate pair, but I don't know if there is a complete specification for what that handler does, so it's possible that it's not wrong.) [1] http://www.w3.org/International/questions/qa-escapes#bytheway ---------- components: Library (Lib), Unicode messages: 169886 nosy: ezio.melotti, wiml priority: normal severity: normal status: open title: encode(..., 'xmlcharrefreplace') produces entities for surrogate pairs type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 21:13:34 2012 From: report at bugs.python.org (Tom Lynn) Date: Wed, 05 Sep 2012 19:13:34 +0000 Subject: [issue15858] tarfile missing entries due to omitted uid/gid fields In-Reply-To: <1346701660.86.0.976031645545.issue15858@psf.upfronthosting.co.za> Message-ID: <1346872414.86.0.579163691261.issue15858@psf.upfronthosting.co.za> Tom Lynn added the comment: See attached bad.tar. $ less bad.tar | cat drwxr-xr-x 0/0 0 2012-09-05 20:04 foo/ -rw-rw-r-- uname/gname 0 2012-09-05 20:04 foo/a $ python -c 'import tarfile; print(tarfile.open("bad.tar").getnames())' ['foo'] $ python -c 'import tarfile, patch; patch.patch_tarfile(); print (tarfile.open("bad.tar").getnames())' ['foo', 'foo/a'] I'm only allowed to attach one file via the tracker web UI, so patch.py will follow. Creation code for bad.tar, largely for my benefit: import java.io.FileOutputStream; import java.io.IOException; import org.codehaus.plexus.archiver.tar.TarOutputStream; import org.codehaus.plexus.archiver.tar.TarEntry; class TarTest { public static void main(String[] args) throws IOException { FileOutputStream fos = new FileOutputStream("bad.tar"); TarOutputStream tos = new TarOutputStream(fos); TarEntry entry = new TarEntry("foo/"); entry.setMode(16877); // 0o40755 entry.setUserId(0); entry.setGroupId(0); entry.setUserName(""); entry.setGroupName(""); tos.putNextEntry(entry); TarEntry entry2 = new TarEntry("foo/a"); entry2.setMode(33204); // 0o100664 entry2.setUserId(-1); // XXX: dodgy entry2.setGroupId(-1); // XXX: dodgy entry2.setUserName("uname"); entry2.setGroupName("gname"); tos.putNextEntry(entry2); tos.close(); fos.close(); } } ---------- Added file: http://bugs.python.org/file27129/bad.tar _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 5 21:16:30 2012 From: report at bugs.python.org (Tom Lynn) Date: Wed, 05 Sep 2012 19:16:30 +0000 Subject: [issue15858] tarfile missing entries due to omitted uid/gid fields In-Reply-To: <1346701660.86.0.976031645545.issue15858@psf.upfronthosting.co.za> Message-ID: <1346872590.43.0.0386326953945.issue15858@psf.upfronthosting.co.za> Tom Lynn added the comment: patch.py attached - what I'm using as a workaround at the moment. ---------- Added file: http://bugs.python.org/file27130/patch.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 01:03:49 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 05 Sep 2012 23:03:49 +0000 Subject: [issue13992] Segfault in PyTrash_destroy_chain In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za> Message-ID: <3XC0pD3hB9zQM6@mail.python.org> Roundup Robot added the comment: New changeset 5a2ef447b80d by Antoine Pitrou in branch '2.7': Issue #13992: The trashcan mechanism is now thread-safe. This eliminates http://hg.python.org/cpython/rev/5a2ef447b80d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 01:21:42 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 05 Sep 2012 23:21:42 +0000 Subject: [issue13992] Segfault in PyTrash_destroy_chain In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za> Message-ID: <3XC1Bs07NYzQM6@mail.python.org> Roundup Robot added the comment: New changeset e72cda3f40a2 by Antoine Pitrou in branch '3.2': Issue #13992: The trashcan mechanism is now thread-safe. This eliminates http://hg.python.org/cpython/rev/e72cda3f40a2 New changeset 6bcaba9e8df2 by Antoine Pitrou in branch 'default': Issue #13992: The trashcan mechanism is now thread-safe. This eliminates http://hg.python.org/cpython/rev/6bcaba9e8df2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 01:22:29 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 05 Sep 2012 23:22:29 +0000 Subject: [issue13992] Segfault in PyTrash_destroy_chain In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za> Message-ID: <1346887349.08.0.0169766312794.issue13992@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Georg, I think this should go in 3.3.0, what do you think? ---------- resolution: -> fixed stage: patch review -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 01:25:47 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 05 Sep 2012 23:25:47 +0000 Subject: [issue15535] Fix pickling efficiency of named tuples in 2.7.3 In-Reply-To: <1343915086.31.0.252328658724.issue15535@psf.upfronthosting.co.za> Message-ID: <1346887547.53.0.442622167221.issue15535@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Adding "def __getstate__(self): return None" to the namedtuple template fixes the issue. Here is a patch with test. ---------- nosy: +amaury.forgeotdarc Added file: http://bugs.python.org/file27131/namedtuple-pickle.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 01:30:46 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 05 Sep 2012 23:30:46 +0000 Subject: [issue13992] Segfault in PyTrash_destroy_chain In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za> Message-ID: <1346887846.96.0.245254448093.issue13992@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Oops, forgot to make Georg nosy. Georg, I think this should go in 3.3.0, what do you think? ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 01:30:52 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 05 Sep 2012 23:30:52 +0000 Subject: [issue13992] Segfault in PyTrash_destroy_chain In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za> Message-ID: <1346887852.38.0.039552127975.issue13992@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- Removed message: http://bugs.python.org/msg169891 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 01:45:26 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 05 Sep 2012 23:45:26 +0000 Subject: [issue13992] Segfault in PyTrash_destroy_chain In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za> Message-ID: <1346888726.92.0.0807613408675.issue13992@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +benjamin.peterson priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 01:48:50 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 05 Sep 2012 23:48:50 +0000 Subject: [issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za> Message-ID: <1346888930.58.0.651096483033.issue11549@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm working on a AST optimizer for Python 2.6-3.3: https://bitbucket.org/haypo/astoptimizer It is implemented in Python and is able to optimize much more cases than the current bytecode peepholer. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 02:11:42 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 06 Sep 2012 00:11:42 +0000 Subject: [issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za> Message-ID: <1346890302.71.0.713674854399.issue11549@psf.upfronthosting.co.za> Nick Coghlan added the comment: All of the optimisations that assume globals haven't been shadowed or rebound are invalid in the general case. E.g. print(1.5) and print("1.5") are valid for *our* print function, but we technically have no idea if they're equivalent in user code. In short, if it involves a name lookup and that name isn't reserved to the compiler (e.g. __debug__) then no, you're not allowed to optimise it at compile time if you wish to remain compliant with the language spec. Method calls on literals are always fair game, though (e.g. you could optimise "a b c".split()) Any stdlib AST optimiser would need to be substantially more conservative by default. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 02:25:24 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 06 Sep 2012 00:25:24 +0000 Subject: [issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za> Message-ID: <1346891124.68.0.68758471549.issue11549@psf.upfronthosting.co.za> STINNER Victor added the comment: > All of the optimisations that assume globals haven't been shadowed > or rebound are invalid in the general case. My main idea is that the developer of the application should be able to annotate functions and constants to declare them as "optimizable" (constant). I chose to expect builtins as not being overrided, but if it breaks applications, it can be converted to an option disabled by default. There is a known issue: test_math fails because pow() is an alias to matH.pow() in doctests. The problem is that "from math import *" is called and the result is stored in a namespace, and then "pow(2,4)" is called in the namespace. astoptimizer doesn't detect that pow=math.pow because locals are only set when the code is executed (and not at compilation) with something like: exec(code, namespace). It is a limitation of the optimizer. A workaround is to disable optimizations when running tests. It is possible to detect that builtins are shadowed (ex: print=myprint). astoptimizer has an experimental support of assignments, but it only works on trivial examples yet (like "x=1; print(x)") and is disabled by default (because it is buggy). I also plan to disable some optimizations if globals(), vars() or dir() is called. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 02:40:50 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 06 Sep 2012 00:40:50 +0000 Subject: [issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za> Message-ID: <1346892050.33.0.963985103993.issue11549@psf.upfronthosting.co.za> STINNER Victor added the comment: > Any stdlib AST optimiser would need to be substantially more conservative by default. FYI The test suite of Python 2.7 and 3.3 pass with astoptimizer... except some "minor" (?) failures: * test_math fails for the reason explained above * test_pdb: it looks to be an issue with line number (debuggers don't like optimizers :-)) * test_xml_etree and test_xml_etree_c: reference count of the None singleton The test suite helped me to find bugs in my optimizer :-) I also had to add some hacks (hasattr) for test_ast (test_ast generates invalid AST trees). The configuration should also be adapted for test_peepholer, because CPython peepholer uses a limit of 20 items, whereas astoptimizer uses a limit of 4096 bytes/characters for string by default. All these minor nits are now handled in a specific "cpython_tests" config. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 02:48:57 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 06 Sep 2012 00:48:57 +0000 Subject: [issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za> Message-ID: <1346892537.31.0.84462374765.issue11549@psf.upfronthosting.co.za> Nick Coghlan added the comment: No, you're assuming global program analysis and *that is not a valid assumption*. One of the key features of Python is that *monkeypatching works*. It's not encouraged, but it works. You simply cannot play games with name lookups like this without creating something that is no longer Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 02:50:25 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 06 Sep 2012 00:50:25 +0000 Subject: [issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za> Message-ID: <1346892625.95.0.120456616959.issue11549@psf.upfronthosting.co.za> Nick Coghlan added the comment: You also have to be very careful of the interface to tracing functions, such as profilers and coverage analysis tools. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 03:20:24 2012 From: report at bugs.python.org (Eugene Toder) Date: Thu, 06 Sep 2012 01:20:24 +0000 Subject: [issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za> Message-ID: <1346894424.55.0.169630324232.issue11549@psf.upfronthosting.co.za> Eugene Toder added the comment: > Method calls on literals are always fair game, though (e.g. you could optimise "a b c".split()) What about optimizations that do not change behavior, except for different error messages? E.g. we can change y = [1,2][x] to y = (1,2)[x] where the tuple is constant and is stored in co_consts. This will, however, produce a different text in the exception when x is not 0 or 1. The type of exception is going to be the same. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 03:22:43 2012 From: report at bugs.python.org (Julian Berman) Date: Thu, 06 Sep 2012 01:22:43 +0000 Subject: [issue15867] It's hard to decypher how to build off of the provided objects from the importlib docs Message-ID: <1346894563.49.0.339877810223.issue15867@psf.upfronthosting.co.za> New submission from Julian Berman: I find that the importlib documentation is a bit too low level. Import hooks are not that common, so requiring a bit of reading is OK with me, but I somewhat *understand* PEP 302, so I have a general idea of *what* I want to do and what kind of objects can accomplish that, and still find it hard to figure out how to take the pieces provided by importlib and use them to do what I want. If I provide a specific example, I want to create a path hook that "just" does the usual import behavior, but before executing the module, does some transformation on the source code, say. In trying to figure out the best way to do that I had a hard time using the docs to figure out which pieces I should assemble to do that. I'm going to just describe the rough series of steps I went through, and hopefully that will help give a picture of where in the docs I had trouble. `importlib.abc` has a few things that would appear to help. None of the things seem like an exact match, so immediately I'm confused -- after reading PEP 302 I'd have expected to need to find an object to implement one or both of `get_code` or `get_source` on, or one that has that implemented that I can subclass and extend. The closest thing there that I find is PyPycLoader, which seems to be saying it implements the standard import behavior, but the docs say its deprecated and to use SourceLoader. At this point, after checking out `SourceLoader` and seeing that it has me implementing two methods whose purpose I don't quite understand, even after reading the short descriptions of them, at least not in the context of what I want to do, I begin to suspect that what I really want is to combine SourceLoader with some things from the `imp` module, or maybe `importlib.__import__`, but am left wondering again how much I need to implement before I just can use that. I then notice `importlib.util.module_for_loader`, and add that to the simple loader I've written which I'm still waiting to plug `imp` into, before realizing that that decorator eats the `fullname` attribute and *only* passes along the module, which confuses me, since now I don't know how to retrieve the source for the module object that I'm being passed -- so I save the path name in `__init__` for the class, and assume that's what I should be doing, despite not seeing an example doing that. Assuming that's even correct as-is, it took me quite a bit to put those pieces together. So I apologize for rambling -- I think essentially what'd improve things is providing more examples, or perhaps a HOWTO entry, that targeted assembling the pieces provided in the module into a few clear, complete examples of finders, loaders and importers. ---------- assignee: docs at python components: Documentation messages: 169901 nosy: Julian, docs at python priority: normal severity: normal status: open title: It's hard to decypher how to build off of the provided objects from the importlib docs versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 03:24:44 2012 From: report at bugs.python.org (Julian Berman) Date: Thu, 06 Sep 2012 01:24:44 +0000 Subject: [issue15867] It's hard to decypher how to build off of the provided objects from the importlib docs In-Reply-To: <1346894563.49.0.339877810223.issue15867@psf.upfronthosting.co.za> Message-ID: <1346894684.03.0.912326506987.issue15867@psf.upfronthosting.co.za> Changes by Julian Berman : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 03:45:36 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 06 Sep 2012 01:45:36 +0000 Subject: [issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za> Message-ID: <1346895936.78.0.623295097149.issue11549@psf.upfronthosting.co.za> Nick Coghlan added the comment: The peephole optimiser already makes optimisations like that in a couple of places (e.g. set -> frozenset): >>> def f(x): ... if x in {1, 2}: pass ... >>> f.__code__.co_consts (None, 1, 2, frozenset({1, 2})) It's name lookup semantics that are the real minefield. It's one of the reasons PyPy's JIT can be so much more effective than a static optimiser - because it's monitoring real execution and inserting the appropriate guards it's not relying on invalid assumptions about name bindings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 05:42:50 2012 From: report at bugs.python.org (Eugene Toder) Date: Thu, 06 Sep 2012 03:42:50 +0000 Subject: [issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za> Message-ID: <1346902970.03.0.019944951144.issue11549@psf.upfronthosting.co.za> Eugene Toder added the comment: If I'm not missing something, changing x in [1,2] to x in (1,2) and x in {1,2} to x in frozenset([1,2]) does not change any error messages. Agreed that without dynamic compilation we can pretty much only track literals (including functions and lambdas) assigned to local variables. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 07:12:33 2012 From: report at bugs.python.org (moijes12) Date: Thu, 06 Sep 2012 05:12:33 +0000 Subject: [issue2679] email.feedparser regex duplicate In-Reply-To: <1209045140.34.0.682842030487.issue2679@psf.upfronthosting.co.za> Message-ID: <1346908353.0.0.991286927003.issue2679@psf.upfronthosting.co.za> Changes by moijes12 : ---------- nosy: +moijes12 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 07:18:49 2012 From: report at bugs.python.org (Ahsan Nawroj) Date: Thu, 06 Sep 2012 05:18:49 +0000 Subject: [issue15744] missing tests for {RawIO,BufferedIO,TextIO}.writelines In-Reply-To: <1345500357.29.0.226025015503.issue15744@psf.upfronthosting.co.za> Message-ID: <1346908729.37.0.526677377724.issue15744@psf.upfronthosting.co.za> Changes by Ahsan Nawroj : ---------- nosy: +ainur0160 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 07:22:16 2012 From: report at bugs.python.org (moijes12) Date: Thu, 06 Sep 2012 05:22:16 +0000 Subject: [issue2679] email.feedparser regex duplicate In-Reply-To: <1209045140.34.0.682842030487.issue2679@psf.upfronthosting.co.za> Message-ID: <1346908936.23.0.675921489979.issue2679@psf.upfronthosting.co.za> Changes by moijes12 : ---------- versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 07:33:36 2012 From: report at bugs.python.org (moijes12) Date: Thu, 06 Sep 2012 05:33:36 +0000 Subject: [issue2679] email.feedparser regex duplicate In-Reply-To: <1209045140.34.0.682842030487.issue2679@psf.upfronthosting.co.za> Message-ID: <1346909616.08.0.90726996431.issue2679@psf.upfronthosting.co.za> Changes by moijes12 : ---------- keywords: +patch Added file: http://bugs.python.org/file27132/2679.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 07:36:59 2012 From: report at bugs.python.org (moijes12) Date: Thu, 06 Sep 2012 05:36:59 +0000 Subject: [issue2679] email.feedparser regex duplicate In-Reply-To: <1209045140.34.0.682842030487.issue2679@psf.upfronthosting.co.za> Message-ID: <1346909819.36.0.154358283948.issue2679@psf.upfronthosting.co.za> moijes12 added the comment: Hi I've attached a patch. Its a simple one wherein NLCRE_crack = NLCRE_bol. I found this in Python 3.3.0b2+ and so I've added version 3.3. I executed "./python -m test" after making the change and no failures were reported (340-OK, 30-Skip). Looking forward to your comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 07:49:01 2012 From: report at bugs.python.org (=?utf-8?q?Miguel_Angel_Garc=C3=ADa?=) Date: Thu, 06 Sep 2012 05:49:01 +0000 Subject: [issue13896] Make shelf instances work with 'with' as context managers In-Reply-To: <1327749150.13.0.147725255938.issue13896@psf.upfronthosting.co.za> Message-ID: <1346910541.12.0.0344969516211.issue13896@psf.upfronthosting.co.za> Changes by Miguel Angel Garc?a : ---------- nosy: +Miguel.Angel.Garc?a _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 09:28:31 2012 From: report at bugs.python.org (=?utf-8?q?Nemeskey_D=C3=A1vid?=) Date: Thu, 06 Sep 2012 07:28:31 +0000 Subject: [issue15775] Add StopParser() to expat In-Reply-To: <1345796297.89.0.127411549702.issue15775@psf.upfronthosting.co.za> Message-ID: <1346916511.97.0.807091990866.issue15775@psf.upfronthosting.co.za> Nemeskey D?vid added the comment: Amaury: see my previous comment. There are two problems with the method you proposed: 1. It is not mentioned in the documentation that exceptions are propagated through parse(). 2. Exceptions usually mean that an error has happened, and is not the preferred way for flow control (at least this is the policy in other languages e.g. Java, I don't know about Python). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 11:30:45 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 06 Sep 2012 09:30:45 +0000 Subject: [issue15775] Add StopParser() to expat In-Reply-To: <1345796297.89.0.127411549702.issue15775@psf.upfronthosting.co.za> Message-ID: <1346923845.03.0.525468757098.issue15775@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Your first point is true, even if the Python zen (try "import this") states that "Errors should never pass silently." For your second point: exceptions are a common thing in Python code. This is similar to the EAFP principle http://docs.python.org/glossary.html#term-eafp Also, this example http://docs.python.org/release/2.7.3/library/imp.html#examples shows that exceptions can be part of the normal flow control. ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 11:32:14 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 06 Sep 2012 09:32:14 +0000 Subject: [issue15868] leak in bytesio.c Message-ID: <1346923934.68.0.507975450675.issue15868@psf.upfronthosting.co.za> New submission from Stefan Krah: Coverity found a leak in bytesio.c. Patch attached. ---------- components: Extension Modules files: bytesio_leak.diff keywords: patch messages: 169907 nosy: pitrou, skrah priority: normal severity: normal status: open title: leak in bytesio.c type: resource usage versions: Python 3.3 Added file: http://bugs.python.org/file27133/bytesio_leak.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 11:41:48 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 06 Sep 2012 09:41:48 +0000 Subject: [issue11715] Building Python on multiarch Debian and Ubuntu In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za> Message-ID: <1346924508.08.0.182552351449.issue11715@psf.upfronthosting.co.za> Ezio Melotti added the comment: Today I got the same problem on 3.2 too. I made a distclean and recompiled and got: Python build finished, but the necessary bits to build these modules were not found: _curses _curses_panel _dbm _gdbm _sqlite3 _ssl _tkinter bz2 readline I tried to apply ma.diff and now I get: Python build finished, but the necessary bits to build these modules were not found: _curses _curses_panel _dbm _gdbm _tkinter bz2 ---------- nosy: +ezio.melotti status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 11:53:59 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 06 Sep 2012 09:53:59 +0000 Subject: [issue15866] encode(..., 'xmlcharrefreplace') produces entities for surrogate pairs In-Reply-To: <1346871274.13.0.653364801762.issue15866@psf.upfronthosting.co.za> Message-ID: <1346925239.12.0.585479116706.issue15866@psf.upfronthosting.co.za> Ezio Melotti added the comment: Attached patch against 3.2 seems to fix the problem. ---------- keywords: +patch stage: -> patch review versions: +Python 3.2 Added file: http://bugs.python.org/file27134/issue15866.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 12:26:14 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 06 Sep 2012 10:26:14 +0000 Subject: [issue15866] encode(..., 'xmlcharrefreplace') produces entities for surrogate pairs In-Reply-To: <1346871274.13.0.653364801762.issue15866@psf.upfronthosting.co.za> Message-ID: <1346927174.58.0.860782434908.issue15866@psf.upfronthosting.co.za> Ezio Melotti added the comment: Note that there's similar code in charmap_encoding_error, PyUnicode_EncodeCharmap, PyUnicode_TranslateCharmap, and PyUnicode_EncodeDecimal, however I'm not sure how to reach these paths. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 13:06:51 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 06 Sep 2012 11:06:51 +0000 Subject: [issue15866] encode(..., 'xmlcharrefreplace') produces entities for surrogate pairs In-Reply-To: <1346871274.13.0.653364801762.issue15866@psf.upfronthosting.co.za> Message-ID: <1346929611.41.0.0277445887677.issue15866@psf.upfronthosting.co.za> STINNER Victor added the comment: Thanks to the PEP 393, this issue is already fixed in Python 3.3. $ ./python Python 3.3.0rc1+ (default:ba2c1def3710+, Sep 3 2012, 23:20:25) [GCC 4.6.3 20120306 (Red Hat 4.6.3-2)] on linux >>> ( u'\U0001f49d' ).encode('ascii', errors='xmlcharrefreplace') b'💝' ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 13:11:14 2012 From: report at bugs.python.org (Dominik George) Date: Thu, 06 Sep 2012 11:11:14 +0000 Subject: [issue15869] Include .desktop file and icon Message-ID: <1346929874.07.0.220677915984.issue15869@psf.upfronthosting.co.za> New submission from Dominik George: As a graphical application, IDLE, is shipped, a .desktop file should be included for intallation to /usr/share/applications. Furthermore, a 16x16 pixel version in XPM format of the Python icon should be shipped to accompany the menu entries. Attached is a tarball containing .desktop files for IDLE 2 and 3 as well as the icon. ---------- components: IDLE files: python-freedesktop-files.tar.bz2 messages: 169912 nosy: natureshadow priority: normal severity: normal status: open title: Include .desktop file and icon type: enhancement versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file27135/python-freedesktop-files.tar.bz2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 13:26:29 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 06 Sep 2012 11:26:29 +0000 Subject: [issue15775] Add StopParser(), ResumeParser, and GetParsingStatus to expat In-Reply-To: <1345796297.89.0.127411549702.issue15775@psf.upfronthosting.co.za> Message-ID: <1346930789.95.0.816868694586.issue15775@psf.upfronthosting.co.za> Martin v. L?wis added the comment: D?vid: Another (similar) example is the Python for loop. In it's original form, it would increase an index and invoke __getitem__ until that *raised* IndexError. In the current definition, it converts the iterated-over object into an iterator, and keeps calling .next until that *raises* StopIteration. So raising an exception to indicate that something is finished is an established Python idiom. In any case, I still think adding StopParser is a useful addition, in particular since that would also allow giving True as the "resumable" argument. Any such change needs to be accompanied by also exposing XML_ResumeParser, and possibly XML_GetParsingStatus. Since we all agree that this is not an important change, I don't mind keeping this issue around until someone comes along to contribute code for it. ---------- title: Add StopParser() to expat -> Add StopParser(), ResumeParser, and GetParsingStatus to expat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 13:48:56 2012 From: report at bugs.python.org (Ahsan Nawroj) Date: Thu, 06 Sep 2012 11:48:56 +0000 Subject: [issue1818] Add named tuple reader to CSV module In-Reply-To: <1200263236.24.0.0303258184569.issue1818@psf.upfronthosting.co.za> Message-ID: <1346932136.79.0.356429323568.issue1818@psf.upfronthosting.co.za> Changes by Ahsan Nawroj : ---------- nosy: +ainur0160 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 14:06:51 2012 From: report at bugs.python.org (Ahsan Nawroj) Date: Thu, 06 Sep 2012 12:06:51 +0000 Subject: [issue1818] Add named tuple reader to CSV module In-Reply-To: <1200263236.24.0.0303258184569.issue1818@psf.upfronthosting.co.za> Message-ID: <1346933211.71.0.963599807545.issue1818@psf.upfronthosting.co.za> Changes by Ahsan Nawroj : ---------- nosy: -ainur0160 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 14:22:49 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 06 Sep 2012 12:22:49 +0000 Subject: [issue11715] Building Python on multiarch Debian and Ubuntu In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za> Message-ID: <1346934169.23.0.211291914008.issue11715@psf.upfronthosting.co.za> Ezio Melotti added the comment: 2.7 is affected too: Python build finished, but the necessary bits to build these modules were not found: _bsddb _curses _curses_panel _sqlite3 _ssl _tkinter bsddb185 bz2 dbm gdbm readline sunaudiodev And after applying ma.diff: Python build finished, but the necessary bits to build these modules were not found: _bsddb _curses _curses_panel _tkinter bsddb185 bz2 dbm gdbm sunaudiodev ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 14:28:22 2012 From: report at bugs.python.org (Ahsan Nawroj) Date: Thu, 06 Sep 2012 12:28:22 +0000 Subject: [issue14531] Backtrace should not attempt to open file In-Reply-To: <1333911683.02.0.244330903259.issue14531@psf.upfronthosting.co.za> Message-ID: <1346934502.62.0.259509264195.issue14531@psf.upfronthosting.co.za> Changes by Ahsan Nawroj : ---------- nosy: +ainur0160 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 15:11:03 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 06 Sep 2012 13:11:03 +0000 Subject: [issue15867] It's hard to decypher how to build off of the provided objects from the importlib docs In-Reply-To: <1346894563.49.0.339877810223.issue15867@psf.upfronthosting.co.za> Message-ID: <1346937063.13.0.863191239258.issue15867@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +brett.cannon, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 15:32:19 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 06 Sep 2012 13:32:19 +0000 Subject: [issue15863] Fine-grained info about Python versions which support changes introduced in micro releases In-Reply-To: <1346798659.62.0.336544157965.issue15863@psf.upfronthosting.co.za> Message-ID: <1346938339.71.0.806939709086.issue15863@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Hash randomization is security patch. It is applied to 2.6.8, 2.7.3, 3.2.3 and 3.3. Python doc should not enumerate all affected releases. For example, if you read docs for 2.6 branch it shows you 2.6.8 version only and that's ok. ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 15:40:33 2012 From: report at bugs.python.org (Alexander Konovalenko) Date: Thu, 06 Sep 2012 13:40:33 +0000 Subject: [issue15863] Fine-grained info about Python versions which support changes introduced in micro releases In-Reply-To: <1346798659.62.0.336544157965.issue15863@psf.upfronthosting.co.za> Message-ID: <1346938833.09.0.581613876488.issue15863@psf.upfronthosting.co.za> Alexander Konovalenko added the comment: Andrew, I don't get it. :( Why not? The docs for Python 2.7 generally inform the reader in which Python version every feature appeared. That's really helpful if your code should run on earlier version of Python. You don't have to dig through the docs for older Python releases and compare them one to another; you can just read the latest docs and all information is there. How is the security patch case different? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 15:43:13 2012 From: report at bugs.python.org (Christian Heimes) Date: Thu, 06 Sep 2012 13:43:13 +0000 Subject: [issue15591] when building the extensions, stdout is lost when stdout is redirected In-Reply-To: <1344423177.77.0.190751096511.issue15591@psf.upfronthosting.co.za> Message-ID: <1346938993.92.0.430520590952.issue15591@psf.upfronthosting.co.za> Christian Heimes added the comment: The fix doesn't work for me. With "make -s" I still see the output to stdout. Also there are much simpler ways to test for MAKEFLAGS: ifneq (,$(findstring s,$(MAKEFLAGS))) QUIET="-q" else QUIET="" endif then use $(QUIET) in the call to setup.py ---------- nosy: +christian.heimes resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 15:47:55 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 06 Sep 2012 13:47:55 +0000 Subject: [issue15863] Fine-grained info about Python versions which support changes introduced in micro releases In-Reply-To: <1346798659.62.0.336544157965.issue15863@psf.upfronthosting.co.za> Message-ID: <1346939275.05.0.628290041101.issue15863@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Well, I can try to make patch. Please note: versionadded tag accepts only single version argument, you have to use couple of tags which looks weird. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 15:59:29 2012 From: report at bugs.python.org (Matthias Klose) Date: Thu, 06 Sep 2012 13:59:29 +0000 Subject: [issue15591] when building the extensions, stdout is lost when stdout is redirected In-Reply-To: <1344423177.77.0.190751096511.issue15591@psf.upfronthosting.co.za> Message-ID: <1346939969.19.0.320642066567.issue15591@psf.upfronthosting.co.za> Matthias Klose added the comment: @benjamin: no, the extensions were never built in parallel @christian: no, that again would match the `s' when you have something like --jobserver in MAKEFLAGS. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 16:22:54 2012 From: report at bugs.python.org (Christian Heimes) Date: Thu, 06 Sep 2012 14:22:54 +0000 Subject: [issue15591] when building the extensions, stdout is lost when stdout is redirected In-Reply-To: <1344423177.77.0.190751096511.issue15591@psf.upfronthosting.co.za> Message-ID: <1346941374.76.0.482628509105.issue15591@psf.upfronthosting.co.za> Christian Heimes added the comment: Ah, got it. GNU sorts the arguments in MAKEFLAGS. The "s" flag is always in the first word. $ make -j4 -s "s --jobserver-fds=3,4 -j" $ make --quiet -j4 "s --jobserver-fds=3,4 -j" This make code works well for me: ifeq (s,$(findstring s,$(word 1,$(MAKEFLAGS)))) QUIET=-q else QUIET= endif I've attached a patch that also fixes the quiet option for ctypes configure script. ---------- Added file: http://bugs.python.org/file27136/quiet.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 16:32:41 2012 From: report at bugs.python.org (Matthias Klose) Date: Thu, 06 Sep 2012 14:32:41 +0000 Subject: [issue15591] when building the extensions, stdout is lost when stdout is redirected In-Reply-To: <1344423177.77.0.190751096511.issue15591@psf.upfronthosting.co.za> Message-ID: <1346941961.5.0.452756681405.issue15591@psf.upfronthosting.co.za> Matthias Klose added the comment: even if you pass other options to make, and -s not as the first flag? and does this work for other makes different than GNU make too? But maybe we already require GNU make. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 16:43:06 2012 From: report at bugs.python.org (Christian Heimes) Date: Thu, 06 Sep 2012 14:43:06 +0000 Subject: [issue15591] when building the extensions, stdout is lost when stdout is redirected In-Reply-To: <1344423177.77.0.190751096511.issue15591@psf.upfronthosting.co.za> Message-ID: <1346942586.53.0.696054149451.issue15591@psf.upfronthosting.co.za> Christian Heimes added the comment: The lines under each of my examples are the content of $MAKEFLAGS. It works when I pass the option in a different order and even with alternative spellings for -s like --quiet. It's always the "s" flag: $ make -s --jobs=4 "s --jobserver-fds=3,4 -j" $ make --jobs=4 --silent "s --jobserver-fds=3,4 -j" $ make --jobs=4 --quiet "s --jobserver-fds=3,4 -j" $ make --jobs=4 --quiet -n echo '"sn --jobserver-fds=3,4 -j"' With just the -j flag $MAKEFLAGS starts with a space so the first word is empty: $ make -j4 " --jobserver-fds=3,4 -j" I don't know if other make implementations work similar but I think we require GNU Make, too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 16:44:29 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 06 Sep 2012 14:44:29 +0000 Subject: [issue15867] It's hard to decypher how to build off of the provided objects from the importlib docs In-Reply-To: <1346894563.49.0.339877810223.issue15867@psf.upfronthosting.co.za> Message-ID: <1346942669.12.0.859339091391.issue15867@psf.upfronthosting.co.za> Eric Snow added the comment: As far as the import system goes, Barry Warsaw added a really nice page to the language reference[1]. However, it sounds like your concern is with taking advantage of the tools that importlib provides. First of all, a good thing to recognize is that importlib Python 3.3 exposes a much richer public API, including exposing the "default" import machinery. While importlib.abc is meaningful, importlib.machinery is more useful in your case. In versions prior to 3.3, things aren't as easy. In other Python 3 versions one approach you could take is to **carefully** use the private importlib APIs to get what you want. If you do that, I'd recommend that your code target the public 3.3 APIs and then write a wrapper around the earlier private APIs to get them to be compatible. There really shouldn't be a lot of difference. The key is to target Python 3.3's importlib. For Python 2, I'd still recommend targeting 3.3's importlib API and writing wrappers to make that work. This would likely involve more effort to backport whole chunks of the 3.3 importlib implementation. Better to simply port your code to Python 3. :) Secondly, the import system is a complex piece of machinery. The new reference that Barry did helps pull it all together, but there are simply a lot of moving parts in various layers. Adding examples for the importlib API may help for working with that API, but any activities in hooking into the import system should be done with a firm understanding of how it works since it's easy to break things. Currently there isn't any easy way around that and I doubt any of that will change for a long time (due to the effort required). Lastly, take a look at pylt[2]. It's a project I'm working on for source-to-source translation that hooks into the import system. Though it isn't finished yet, the import side of things is mostly done. Hopefully I'll have all the tests done in the next few days. For pylt I've made use of the 3.3 importlib API along with a couple of things that we should see in 3.4 that I've "backported" [3]. The code there should give you an idea of how I've done essentially what you are looking to do. Ultimately, any recommendations you can give on making the import system more approachable would be awesome. Though it will take a lot of thought, discussion, and effort to make the import system "easy", there is still a lot of room for improvement in making it understandable. Your perspective would be meaningful in working toward a sensible improvement. [1] http://docs.python.org/dev/reference/import.html [2] https://bitbucket.org/ericsnowcurrently/pylt/ [3] http://bugs.python.org/issue15627 ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 17:45:11 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 06 Sep 2012 15:45:11 +0000 Subject: [issue15868] leak in bytesio.c In-Reply-To: <1346923934.68.0.507975450675.issue15868@psf.upfronthosting.co.za> Message-ID: <1346946311.76.0.354524329374.issue15868@psf.upfronthosting.co.za> Benjamin Peterson added the comment: LGTM ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 17:49:26 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 06 Sep 2012 15:49:26 +0000 Subject: [issue15870] PyType_FromSpec should take metaclass as an argument Message-ID: <1346946566.36.0.583610018294.issue15870@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: PyType_FromSpec() is a convenient function to create types dynamically in C extension modules, but its usefulness is limited by the fact that it creates new types using the default metaclass. I suggest adding a new C API function PyObject *PyType_FromSpecEx(PyObject *meta, PyType_Spec *spec) and redefine PyType_FromSpec() as PyType_FromSpecEx((PyObject *)&PyType_Type, spec) This functionality cannot be implemented by user because PyType_FromSpec requires access to private slotoffsets table. A (trivial) patch attached. ---------- assignee: belopolsky components: Interpreter Core files: typeobject.diff keywords: needs review, patch messages: 169925 nosy: belopolsky, loewis priority: normal severity: normal stage: test needed status: open title: PyType_FromSpec should take metaclass as an argument type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file27137/typeobject.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 17:54:14 2012 From: report at bugs.python.org (Brett Cannon) Date: Thu, 06 Sep 2012 15:54:14 +0000 Subject: [issue15867] It's hard to decypher how to build off of the provided objects from the importlib docs In-Reply-To: <1346894563.49.0.339877810223.issue15867@psf.upfronthosting.co.za> Message-ID: <1346946854.71.0.573682859679.issue15867@psf.upfronthosting.co.za> Brett Cannon added the comment: First off, what you want to do isn't easy to begin with. =) You are right that you want get_code() and that SourceLoader is what you want. The problem is that importlib inherited PEP 302s APIs, and there are so many that the docs don't repeat themselves in terms of what methods each ABC implements in order to keep the docs readable. That makes it a little difficult to realize what ABCs implement what without reading the class description and/or looking at the class hierarchy layout to realize that SourceLoader implements ResourceLoader which specifies get_code(). Second, import is just plain hard. It took me over 5 years to write importlib and get it to where it is now, and most of that work was just trying to keep it all straight in my head. This also makes writing an example or two difficult as it becomes a massive undertaking very quickly. And there is the simple issue that everyone wants something different, e.g. you want to transform source while others want an alternative back-end storage solution. That means coming up with the right examples is hard in and of itself. Third, in Python 3.4 your desire to transform source will be much easier to achieve thanks to http://bugs.python.org/issue15627 . IOW, I understand your pain but solving the problem is hard without writing a book on the subject (which who knows, maybe I'll do someday as a $1 ebook or something). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 18:06:55 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 06 Sep 2012 16:06:55 +0000 Subject: [issue15591] when building the extensions, stdout is lost when stdout is redirected In-Reply-To: <1344423177.77.0.190751096511.issue15591@psf.upfronthosting.co.za> Message-ID: <3XCRVk0gHNzNB3@mail.python.org> Roundup Robot added the comment: New changeset 048e13546a7c by Christian Heimes in branch '3.2': Issue #15591: run ctypes' configure in quiet mode when setup.py runs silently http://hg.python.org/cpython/rev/048e13546a7c New changeset e5569b03a287 by Christian Heimes in branch 'default': Issue #15591: run ctypes' configure in quiet mode when setup.py runs silently http://hg.python.org/cpython/rev/e5569b03a287 New changeset 962e8b2a39f3 by Christian Heimes in branch '2.7': Issue #15591: run ctypes' configure in quiet mode when setup.py runs silently http://hg.python.org/cpython/rev/962e8b2a39f3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 18:44:34 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 06 Sep 2012 16:44:34 +0000 Subject: [issue15870] PyType_FromSpec should take metaclass as an argument In-Reply-To: <1346946566.36.0.583610018294.issue15870@psf.upfronthosting.co.za> Message-ID: <1346949874.67.0.253693000849.issue15870@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The patch is a bit light: see how type_new also computes the metaclass from the base classes. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 19:04:58 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 06 Sep 2012 17:04:58 +0000 Subject: [issue15870] PyType_FromSpec should take metaclass as an argument In-Reply-To: <1346949874.67.0.253693000849.issue15870@psf.upfronthosting.co.za> Message-ID: Alexander Belopolsky added the comment: On Thu, Sep 6, 2012 at 12:44 PM, Amaury Forgeot d'Arc wrote: > The patch is a bit light: see how type_new also computes the metaclass from the base classes. This was intentional. I was looking for a lightweight facility to create heap types. I know metaclass when I call PyType_FromSpec. If i wanted to invoke the "metaclass from the base classes" logic, I would just specify an appropriate base class in the spec. This would still leave an open problem of specifying the metatype for the most basic class. This is the problem I am trying to solve. ---------- nosy: +Alexander.Belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 19:14:26 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 06 Sep 2012 17:14:26 +0000 Subject: [issue15871] Online docs: make index search always available. Message-ID: <1346951666.84.0.523873961498.issue15871@psf.upfronthosting.co.za> New submission from Terry J. Reedy: For the Windows Help version of the docs, the left side box has 4 tabs: Contents, Index, Search, Favorites. I now mostly use the Index tab. That means that I can enter an indexed keyword, topic, or object name and jump from place to place in the docs. The left margin of the online docs only has a text search box equivalent to the Windows search tab (which I essentially never use). The index is only available on the front page, possibly not even visible without scrolling. Consequently, people, especially beginners, tend to use the text search box when they should be using the index. The result is often useless. The issue came up on python-list about a beginner entering 'print' and getting nothing useful. With the Windows doc, 'print' in the index search immediately brings up print (builtin function) (twice, I did not look into why). The same thing in the search lists 153 pages, with the builtin functions page at 75. Not too surprising, as it is a long page with only 3 occurrences of 'print'. Also not useful. So I think the online docs should also have an always available index search box in addition to the text search box (which should be properly labeled as such). 'Enter a module, class, for function name.' should be applied to index search, not text search. An alternative is for the one box to give both index search results and text search results, but doing the latter when one only wants the former is a waste of both server and reader resources. ---------- assignee: docs at python components: Documentation messages: 169930 nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, terry.reedy priority: normal severity: normal status: open title: Online docs: make index search always available. type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 19:29:40 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 06 Sep 2012 17:29:40 +0000 Subject: [issue15871] Online docs: make index search always available. In-Reply-To: <1346951666.84.0.523873961498.issue15871@psf.upfronthosting.co.za> Message-ID: <1346952580.52.0.566641592741.issue15871@psf.upfronthosting.co.za> R. David Murray added the comment: The index is available on every page via the link in the upper right corner. An index-specific search might be interesting, though I usually just click the 'index on one page' link and do a text search. But that is a two step process and doesn't give a nice list of hits. I don't think I ever use the text search box, either. I just use google. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 19:31:16 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 06 Sep 2012 17:31:16 +0000 Subject: [issue15871] Online docs: make index search always available. In-Reply-To: <1346951666.84.0.523873961498.issue15871@psf.upfronthosting.co.za> Message-ID: <1346952676.88.0.355075696334.issue15871@psf.upfronthosting.co.za> Ezio Melotti added the comment: I find the current search quite useless. I think index search with a fallback on text search when there are no results would be better. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 20:07:02 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 06 Sep 2012 18:07:02 +0000 Subject: [issue15642] Integrate pickle protocol version 4 GSoC work by Stefan Mihaila In-Reply-To: <1344890920.23.0.695633734046.issue15642@psf.upfronthosting.co.za> Message-ID: <1346954822.96.0.22111654626.issue15642@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Are there also some known techniques on tracking down memory leaks? Nothing more than the usual debugging techniques. It is more of a matter of taste whether you like to add print() (or printf ;-)) calls, or set breakpoints in an actual debugger. > i.e. pickle.dumps(3.0+1j, 4) leaks but pickle.dumps(3.0+1j, 3) does not. Well it looks like you've narrowed things down a bit here. > However, there appears to be no difference in the code that gets > executed in v3 to the one executed in v4. Even the differences in memoization? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 21:22:32 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 06 Sep 2012 19:22:32 +0000 Subject: [issue15871] Online docs: make index search always available. In-Reply-To: <1346951666.84.0.523873961498.issue15871@psf.upfronthosting.co.za> Message-ID: <1346959352.67.0.0648835263695.issue15871@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I am not the only person who finds the 4 lines of Quick search [ ] [go] Enter search terms or a module, class or function name. more eye-catching than the more useful modules | index in the corner. It is not even obvious what those are about. They are in black 'I am not a link' text until the mouse goes over them. So lets make them more prominent. Second, no one finds the current, eye-catching Quick search very useful. For naive beginners, it seems to be off-putting. The python-list thread is "python docs search for 'print'". So lets change it. Combining these ideas, my revised suggestion is: Move the upper right entries to the sidebar above Quick search and expand and capitalize them so the sidebar would then look like Module index General index Quick search [ ]... where the quick search is actually initially quick by first searching only the general index (Ezio's variation). (I am assuming that all modules are in the general index also). If something is found, it reports "Index entries found:" and only offers "Click here to do a full text search". If nothing is in the index, report "No index entries found, doing a full text search ..." (This would still not be as good as the Windows doc, where the index tab starts with the entire index list and responds as each character is entered. That catches typos as mistyped. This would best be done by client-side javascript after loading the entire index list.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 22:07:15 2012 From: report at bugs.python.org (Jakub Wilk) Date: Thu, 06 Sep 2012 20:07:15 +0000 Subject: [issue15872] shutil.rmtree(..., ignore_errors=True) doesn't ignore all errors Message-ID: <1346962035.48.0.664042204164.issue15872@psf.upfronthosting.co.za> New submission from Jakub Wilk: This used to work correctly in Python 3.2: Python 3.3.0rc1 (default, Aug 29 2012, 00:39:20) [GCC 4.7.1] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import shutil >>> shutil.rmtree('/etc/fstab', ignore_errors=True) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.3/shutil.py", line 456, in rmtree "Not a directory: '{}'".format(path)) NotADirectoryError: [Errno 20] Not a directory: '/etc/fstab' ---------- messages: 169936 nosy: jwilk priority: normal severity: normal status: open title: shutil.rmtree(..., ignore_errors=True) doesn't ignore all errors type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 22:09:18 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 06 Sep 2012 20:09:18 +0000 Subject: [issue15871] Online docs: make index search always available. In-Reply-To: <1346951666.84.0.523873961498.issue15871@psf.upfronthosting.co.za> Message-ID: <1346962158.4.0.509096768926.issue15871@psf.upfronthosting.co.za> Stefan Krah added the comment: I like the quick search: It works very well for function names. For the use cases mentioned here I use Google. I never use the index, so for me personally the positioning of the quick search box is perfect. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 22:31:21 2012 From: report at bugs.python.org (Bryan Oakley) Date: Thu, 06 Sep 2012 20:31:21 +0000 Subject: [issue15861] ttk.Treeview "unmatched open brace in list" In-Reply-To: <1346794903.35.0.326071924778.issue15861@psf.upfronthosting.co.za> Message-ID: <1346963481.36.0.430688035483.issue15861@psf.upfronthosting.co.za> Bryan Oakley added the comment: I gave myself an hour or so to play around with this, and the crux of the matter seems to be in the function `_format_optdict()` which converts a dictionary of options and values into something suitable to pass to `tk.call()`. However, I think the same bug is in other `_format*` functions as well, it's just that their nature is such that they have much less of a chance to be passed weird data. `_format_optdict` has some code that does a half-hearted attempt at handling values that are tuples, such as the case with the "values" attribute of the ttk.Treeview widget. However, all it does is protect values that have a space, by surrounding the value with curly braces. Hence, when the value itself has a curly brace, tcl throws the "unmatched open brace" error. What is needed is to create a bona fide tcl list element according to the rules of Tcl. I tried a hack where I simply escaped all problem characters, so instead of returning `{foo bar}` the function returns `foo\ bar`. This seemed to work, at least for the tiny bit of testing that I did. Another solution might be to do something like tk.call("list",*the_tuple), though sadly, `_format_optdict` is a function rather than a method so it doesn't have access to the tcl interpreter. What I think ttk needs (and may already exist somewhere in the Tkinter world; I haven't looked...) is a function that takes a tuple and converts it to a canonical list. Then, the places that do something ad hoc can all call this one function. For more information on the gory details of the string representation of a list see http://www.tcl.tk/cgi-bin/tct/tip/407.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 22:35:27 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 06 Sep 2012 20:35:27 +0000 Subject: [issue15870] PyType_FromSpec should take metaclass as an argument In-Reply-To: <1346946566.36.0.583610018294.issue15870@psf.upfronthosting.co.za> Message-ID: <1346963727.11.0.593615865567.issue15870@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +Robin.Schreiber _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 22:42:44 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 06 Sep 2012 20:42:44 +0000 Subject: [issue7682] Optimisation of if with constant expression In-Reply-To: <1263298923.43.0.408416060324.issue7682@psf.upfronthosting.co.za> Message-ID: <1346964164.35.0.569048701229.issue7682@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm working on a different approach: an AST optimizer. It is already able to replace "if __debug__ and x: ...." with "if x: ..." ("pythonenv" option must be enabled). https://bitbucket.org/haypo/astoptimizer/ ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 22:50:03 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 06 Sep 2012 20:50:03 +0000 Subject: [issue15870] PyType_FromSpec should take metaclass as an argument In-Reply-To: <1346946566.36.0.583610018294.issue15870@psf.upfronthosting.co.za> Message-ID: <1346964603.67.0.430361240082.issue15870@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > see how type_new also computes the metaclass from the base classes. As you can see from my first message, I originally considered PyType_FromSpecEx(PyObject *meta, PyType_Spec *spec) without bases. (In fact I was unaware of the recent addition of PyType_FromSpecWithBases.) Maybe the original signature makes more sense than the one in the patch. Explicitly setting a metaclass is most useful for the most basic type. On the other hand, a fully general function may eventually replace both PyType_FromSpec and PyType_FromSpecWithBases for most uses. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 23:08:50 2012 From: report at bugs.python.org (John Nagle) Date: Thu, 06 Sep 2012 21:08:50 +0000 Subject: [issue15873] "datetime" cannot parse ISO 8601 dates and times Message-ID: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> New submission from John Nagle: The datetime module has support for output to a string of dates and times in ISO 8601 format ("2012-09-09T18:00:00-07:00"), with the object method "isoformat([sep])". But there's no support for parsing such strings. A string to datetime class method should be provided, one capable of parsing at least the RFC 3339 subset of ISO 8601. The problem is parsing time zone information correctly. The allowed formats for time zone are empty - no TZ, date/time is "naive" in the datetime sense Z - zero, or Zulu time, i.e. UTC. [+-]nn.nn - offset from UTC "strptime" does not understand timezone offsets. The "datetime" documentation suggests that the "z" format directive handles time zone info, but that's not actually implemented for input. Pypi has four modules for parsing ISO 8601 dates. Each has least one major problem in time zone handling: iso8601 0.1.4 Abandonware. Mishandles time zone when time zone is "Z" and the default time zone is specified. iso8601.py 0.1dev Always returns a "naive" datetime object, even if zone specified. iso8601plus 0.1.6 Fork of abandonware version above. Same bug. zc.iso8601 0.2.0 Zope version. Imports the pytz module with the full Olsen time zone database, but doesn't actually use that database. Thus, nothing in Pypi provides a good alternative. It would be appropriate to handle this in the datetime module. One small, correct, tested function would be better than the existing five bad alternatives. ---------- components: Library (Lib) messages: 169941 nosy: nagle priority: normal severity: normal status: open title: "datetime" cannot parse ISO 8601 dates and times type: enhancement versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 23:10:01 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 06 Sep 2012 21:10:01 +0000 Subject: [issue15870] PyType_FromSpec should take metaclass as an argument In-Reply-To: <1346946566.36.0.583610018294.issue15870@psf.upfronthosting.co.za> Message-ID: <1346965801.67.0.764613330351.issue15870@psf.upfronthosting.co.za> Martin v. L?wis added the comment: What is your use case for this API? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 23:14:33 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 06 Sep 2012 21:14:33 +0000 Subject: [issue15873] "datetime" cannot parse ISO 8601 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1346966073.39.0.330022005047.issue15873@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 23:43:32 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 06 Sep 2012 21:43:32 +0000 Subject: [issue15873] "datetime" cannot parse ISO 8601 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1346967812.94.0.45427801248.issue15873@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- versions: -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 23:43:42 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 06 Sep 2012 21:43:42 +0000 Subject: [issue15873] "datetime" cannot parse ISO 8601 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1346967822.61.0.813570271557.issue15873@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 6 23:57:05 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 06 Sep 2012 21:57:05 +0000 Subject: [issue15870] PyType_FromSpec should take metaclass as an argument In-Reply-To: <1346965801.67.0.764613330351.issue15870@psf.upfronthosting.co.za> Message-ID: <3D140923-731C-41B1-AF6C-B8AEEB8E8B6F@gmail.com> Alexander Belopolsky added the comment: On Sep 6, 2012, at 5:10 PM, Martin v. L?wis wrote: > > What is your use case for this API? > I can describe my use case, but it is somewhat similar to ctypes. I searched the tracker for a PEP 3121 refactoring applied to ctypes and could not find any. I'll try to come up with a PEP 3121 patch for ctypes using the proposed API. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 00:25:48 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 06 Sep 2012 22:25:48 +0000 Subject: [issue15870] PyType_FromSpec should take metaclass as an argument In-Reply-To: <1346946566.36.0.583610018294.issue15870@psf.upfronthosting.co.za> Message-ID: <1346970348.9.0.769750937748.issue15870@psf.upfronthosting.co.za> Martin v. L?wis added the comment: If it's very special, I'm -0 on this addition. This sounds like this is something very few people would ever need, and they can learn to write more complicated code to achieve the same effect. Convenience API exists to make the common case convenient. I'm -1 on calling it PyType_FromSpecEx. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 00:31:55 2012 From: report at bugs.python.org (Matthias Klose) Date: Thu, 06 Sep 2012 22:31:55 +0000 Subject: [issue11715] Building Python on multiarch Debian and Ubuntu In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za> Message-ID: <1346970715.68.0.817252500629.issue11715@psf.upfronthosting.co.za> Matthias Klose added the comment: I think that the ma.diff can safely go to the 2.7 and 3.2 branches. For the other extensions which are not built you are probably missing the build dependencies (try: apt-get build-dep python2.7 python3.2). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 00:33:54 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 06 Sep 2012 22:33:54 +0000 Subject: [issue11715] Building Python on multiarch Debian and Ubuntu In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za> Message-ID: <1346970834.3.0.371175029941.issue11715@psf.upfronthosting.co.za> Ezio Melotti added the comment: The other missing extensions are not a problem, as long as the one that I need and already have (e.g. readline, _ssl) are built correctly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 00:35:26 2012 From: report at bugs.python.org (Matthias Klose) Date: Thu, 06 Sep 2012 22:35:26 +0000 Subject: [issue15298] _sysconfigdata is generated in srcdir, not builddir In-Reply-To: <1341782776.55.0.708234468774.issue15298@psf.upfronthosting.co.za> Message-ID: <1346970926.92.0.312019685763.issue15298@psf.upfronthosting.co.za> Matthias Klose added the comment: looks fine. from my point of view this should go to the 3.3 branch after the 3.3.0 release, and to the trunk. ---------- keywords: -needs review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 00:35:53 2012 From: report at bugs.python.org (Alessandro Moura) Date: Thu, 06 Sep 2012 22:35:53 +0000 Subject: [issue15872] shutil.rmtree(..., ignore_errors=True) doesn't ignore all errors In-Reply-To: <1346962035.48.0.664042204164.issue15872@psf.upfronthosting.co.za> Message-ID: <1346970953.26.0.916911387993.issue15872@psf.upfronthosting.co.za> Alessandro Moura added the comment: Yes, confirmed. When checking whether the provided path is a directory, rmtree does not check whether ignore_errors is set. According to the docstring, "If ignore_errors is set, errors are ignored". Presumably this means any error, in which case this is not the desired behaviour. The attached patch fixes this. ---------- keywords: +patch nosy: +eng793 Added file: http://bugs.python.org/file27138/shutil.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 00:36:48 2012 From: report at bugs.python.org (Matthias Klose) Date: Thu, 06 Sep 2012 22:36:48 +0000 Subject: [issue15830] make -s no longer silences output from setup.py In-Reply-To: <1346421796.43.0.205634084125.issue15830@psf.upfronthosting.co.za> Message-ID: <1346971008.31.0.558265051766.issue15830@psf.upfronthosting.co.za> Matthias Klose added the comment: now fixed, see http://bugs.python.org/issue15591#msg169927 ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 00:40:26 2012 From: report at bugs.python.org (Christian Heimes) Date: Thu, 06 Sep 2012 22:40:26 +0000 Subject: [issue15830] make -s no longer silences output from setup.py In-Reply-To: <1346421796.43.0.205634084125.issue15830@psf.upfronthosting.co.za> Message-ID: <1346971226.58.0.221139189515.issue15830@psf.upfronthosting.co.za> Christian Heimes added the comment: Matthias: Not yet, my checkin didn't fix the issue. I've just added a minor modification to setup.py that forwards the -q option to ctypes' configure script. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 00:47:48 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 06 Sep 2012 22:47:48 +0000 Subject: [issue15870] PyType_FromSpec should take metaclass as an argument In-Reply-To: <1346970348.9.0.769750937748.issue15870@psf.upfronthosting.co.za> Message-ID: <1B2A3388-0D69-4999-BFDA-86E5101A5260@gmail.com> Alexander Belopolsky added the comment: On Sep 6, 2012, at 6:25 PM, Martin v. L?wis wrote: > I'm -1 on calling it PyType_FromSpecEx. I find it encouraging that you commented on the choice of name. :-) I can live with PyType_FromMetatypeAndSpec and leave out bases. PyType_FromTypeAndSpec is fine too. On the substance, I don't think this API is just convenience. In my application I have to replace meta type after my type is created with PyType_FromSpec. This is fragile and works only for very simple metatypes. Let's get back to this discussion once I have a ctypes patch. I there will be a work-around for ctypes it will probably work for my case. (My case is a little bit more complicated because I extend the size of my type objects to store custom metadata. Ctypes fudge this issue by hiding extra data in a custom tp_dict. ) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 00:51:59 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 06 Sep 2012 22:51:59 +0000 Subject: [issue15867] It's hard to decypher how to build off of the provided objects from the importlib docs In-Reply-To: <1346894563.49.0.339877810223.issue15867@psf.upfronthosting.co.za> Message-ID: <1346971919.98.0.475974076165.issue15867@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 01:08:29 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 06 Sep 2012 23:08:29 +0000 Subject: [issue15873] "datetime" cannot parse ISO 8601 dates and times In-Reply-To: <1346966073.42.0.372075338364.issue15873@psf.upfronthosting.co.za> Message-ID: <4E6188A8-5814-4257-91F7-B0C72654CE0C@gmail.com> Alexander Belopolsky added the comment: %z format is supported, but it cannot accept colon in TZ offset. It can parse offsets like -0600 just fine. What OP is looking for is the GNU date %:z format which datetime does not support. For ISO 8601 compliance, however I think we need a way to specify a parser that will accept any valid 8601 format: with T or space separator and with or without : in time and timezone and with or without dashes in date. I would very much like such promiscuous parser to be implemented in datetime.__new__. So that we can create datetime objects from strings the way we do it with numbers. ---------- nosy: +Alexander.Belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 01:13:13 2012 From: report at bugs.python.org (Mike Hoy) Date: Thu, 06 Sep 2012 23:13:13 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1346973193.82.0.146487736847.issue14468@psf.upfronthosting.co.za> Changes by Mike Hoy : ---------- nosy: -mikehoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 01:14:13 2012 From: report at bugs.python.org (Mike Hoy) Date: Thu, 06 Sep 2012 23:14:13 +0000 Subject: [issue1185124] pydoc doesn't find all module doc strings Message-ID: <1346973253.77.0.368392284828.issue1185124@psf.upfronthosting.co.za> Changes by Mike Hoy : ---------- nosy: -mikehoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 01:19:04 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 06 Sep 2012 23:19:04 +0000 Subject: [issue15591] when building the extensions, stdout is lost when stdout is redirected In-Reply-To: <1344423177.77.0.190751096511.issue15591@psf.upfronthosting.co.za> Message-ID: <3XCd5M3ytRzQXs@mail.python.org> Roundup Robot added the comment: New changeset b9261dd34289 by Christian Heimes in branch '3.2': Issue #15591 and Issue #11715: silence output of setup.py when make is run with -s option. http://hg.python.org/cpython/rev/b9261dd34289 New changeset fcc629208842 by Christian Heimes in branch 'default': Issue #15591 and Issue #11715: silence output of setup.py when make is run with -s option. http://hg.python.org/cpython/rev/fcc629208842 New changeset 2587aeb616b6 by Christian Heimes in branch '2.7': Issue #15591 and Issue #11715: silence output of setup.py when make is run with -s option. http://hg.python.org/cpython/rev/2587aeb616b6 New changeset 4807ed8a627e by Christian Heimes in branch 'default': Issue #15591 and Issue #11715: silence output of setup.py when make is run with -s option. http://hg.python.org/cpython/rev/4807ed8a627e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 01:19:05 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 06 Sep 2012 23:19:05 +0000 Subject: [issue11715] Building Python on multiarch Debian and Ubuntu In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za> Message-ID: <3XCd5N2SlwzQXs@mail.python.org> Roundup Robot added the comment: New changeset b9261dd34289 by Christian Heimes in branch '3.2': Issue #15591 and Issue #11715: silence output of setup.py when make is run with -s option. http://hg.python.org/cpython/rev/b9261dd34289 New changeset fcc629208842 by Christian Heimes in branch 'default': Issue #15591 and Issue #11715: silence output of setup.py when make is run with -s option. http://hg.python.org/cpython/rev/fcc629208842 New changeset 2587aeb616b6 by Christian Heimes in branch '2.7': Issue #15591 and Issue #11715: silence output of setup.py when make is run with -s option. http://hg.python.org/cpython/rev/2587aeb616b6 New changeset 4807ed8a627e by Christian Heimes in branch 'default': Issue #15591 and Issue #11715: silence output of setup.py when make is run with -s option. http://hg.python.org/cpython/rev/4807ed8a627e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 01:19:40 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 06 Sep 2012 23:19:40 +0000 Subject: [issue15870] PyType_FromSpec should take metaclass as an argument In-Reply-To: <1346946566.36.0.583610018294.issue15870@psf.upfronthosting.co.za> Message-ID: <1346973580.42.0.32216229994.issue15870@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This API may make it easier to declare ABCs in C. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 01:20:46 2012 From: report at bugs.python.org (Christian Heimes) Date: Thu, 06 Sep 2012 23:20:46 +0000 Subject: [issue15591] when building the extensions, stdout is lost when stdout is redirected In-Reply-To: <1344423177.77.0.190751096511.issue15591@psf.upfronthosting.co.za> Message-ID: <1346973646.34.0.378661640433.issue15591@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +brett.cannon resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 01:27:09 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 06 Sep 2012 23:27:09 +0000 Subject: [issue15872] shutil.rmtree(..., ignore_errors=True) doesn't ignore all errors In-Reply-To: <1346962035.48.0.664042204164.issue15872@psf.upfronthosting.co.za> Message-ID: <1346974029.6.0.309168662482.issue15872@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Can you also provide a test? ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 01:35:54 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 06 Sep 2012 23:35:54 +0000 Subject: [issue15870] PyType_FromSpec should take metaclass as an argument In-Reply-To: <1346946566.36.0.583610018294.issue15870@psf.upfronthosting.co.za> Message-ID: <1346974554.21.0.489494212008.issue15870@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 01:38:49 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 06 Sep 2012 23:38:49 +0000 Subject: [issue15873] "datetime" cannot parse ISO 8601 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1346974729.4.0.709095782032.issue15873@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 02:04:48 2012 From: report at bugs.python.org (Alessandro Moura) Date: Fri, 07 Sep 2012 00:04:48 +0000 Subject: [issue15872] shutil.rmtree(..., ignore_errors=True) doesn't ignore all errors In-Reply-To: <1346962035.48.0.664042204164.issue15872@psf.upfronthosting.co.za> Message-ID: <1346976288.79.0.0706790462162.issue15872@psf.upfronthosting.co.za> Alessandro Moura added the comment: Added test to patch. ---------- Added file: http://bugs.python.org/file27139/shutil.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 02:04:53 2012 From: report at bugs.python.org (Nat Hillard) Date: Fri, 07 Sep 2012 00:04:53 +0000 Subject: [issue15874] argparse cannot parse bash variable arguments in file-given arguments Message-ID: <1346976291.75.0.854427077128.issue15874@psf.upfronthosting.co.za> New submission from Nat Hillard: When using the argparse argument fromfile_prefix_chars to obtain command line arguments from a file, it is not possible to make use of bash environment variables within this file. Ideally one would be able to `export BAR='/Users/x/Desktop/bar'`, and then give arguments such as: --foo $BAR and have this correctly expanded at read time to --foo '/Users/x/Desktop/bar'. To my knowledge, this is currently only possible if you give the arguments directly via the command line: python test.py --foo $BAR It would be great to be able to use environment variables within files as well! ---------- components: Library (Lib) messages: 169958 nosy: ZhuangZi, bethard priority: normal severity: normal status: open title: argparse cannot parse bash variable arguments in file-given arguments type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 02:27:25 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 07 Sep 2012 00:27:25 +0000 Subject: [issue15591] when building the extensions, stdout is lost when stdout is redirected In-Reply-To: <1344423177.77.0.190751096511.issue15591@psf.upfronthosting.co.za> Message-ID: <3XCfc76cWgzM2t@mail.python.org> Roundup Robot added the comment: New changeset 8cd6acffbcb9 by Christian Heimes in branch '2.7': Issue #15591 and Issue #11715: silence output of setup.py when make is run with -s option. http://hg.python.org/cpython/rev/8cd6acffbcb9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 02:27:25 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 07 Sep 2012 00:27:25 +0000 Subject: [issue11715] Building Python on multiarch Debian and Ubuntu In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za> Message-ID: <3XCfc84ydFzM2t@mail.python.org> Roundup Robot added the comment: New changeset 8cd6acffbcb9 by Christian Heimes in branch '2.7': Issue #15591 and Issue #11715: silence output of setup.py when make is run with -s option. http://hg.python.org/cpython/rev/8cd6acffbcb9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 02:39:15 2012 From: report at bugs.python.org (Christian Heimes) Date: Fri, 07 Sep 2012 00:39:15 +0000 Subject: [issue11715] Building Python on multiarch Debian and Ubuntu In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za> Message-ID: <1346978355.6.0.702563448462.issue11715@psf.upfronthosting.co.za> Christian Heimes added the comment: Sorry for the noise! I confused two tickets. The checkin should have referred to #15830 and #15591 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 03:24:23 2012 From: report at bugs.python.org (Manuke) Date: Fri, 07 Sep 2012 01:24:23 +0000 Subject: [issue15875] tarfile may not make @LongLink for non-ascii character Message-ID: <1346981062.61.0.534239636824.issue15875@psf.upfronthosting.co.za> New submission from Manuke: When I will make a GNU tar-file with 'tarfile', @LongLink may not be made though the name of the archived-file is long, if the name uses non-ascii characters. In tarfile.py, the check code of the filename length is described as follows now: tarfile.py: 1032 < if len(info["name"]) > LENGTH_NAME: But, the type of the value is 'str', it is not encoded. It must be described as follows: > if len(info["name"].encode(encoding, errors)) > LENGTH_NAME: There seems to be the same problem in Line 1029(and the other functions for other formats), but I have not confirmed. ---------- components: Library (Lib) messages: 169962 nosy: Manuke priority: normal severity: normal status: open title: tarfile may not make @LongLink for non-ascii character type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 03:28:05 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 07 Sep 2012 01:28:05 +0000 Subject: [issue15871] Online docs: make index search always available. In-Reply-To: <1346951666.84.0.523873961498.issue15871@psf.upfronthosting.co.za> Message-ID: <1346981285.77.0.709676659015.issue15871@psf.upfronthosting.co.za> Terry J. Reedy added the comment: 'print' *is* a function name ;-) which also happens to be a common word. If the current search box gives you the page where the function is defined, searching the index first should give you the same page. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 03:29:27 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 07 Sep 2012 01:29:27 +0000 Subject: [issue15867] It's hard to decypher how to build off of the provided objects from the importlib docs In-Reply-To: <1346894563.49.0.339877810223.issue15867@psf.upfronthosting.co.za> Message-ID: <1346981367.91.0.641611733536.issue15867@psf.upfronthosting.co.za> Nick Coghlan added the comment: One specific change we should make is that the "see also" at the start of the 3.3 importlib docs should link to the new section of the language reference, rather than Guido's packaging essay. We can probably also cull that long list of PEPs, moving it to the end of the language reference section. Other than that, yeah, we've been working away at this for years, trying to bring it down to a more manageable level of complexity. Brett's efforts in finally purging the last remnants of the old pre-PEP 302 import systems are what made it possible for Barry to finally create a coherent spec for the import system (previously, none of us really wanted to write such a thing, as there would have been *way* too many caveats needed in attempting to grandfather in the legacy import mechanics). Now that that is done, 3.4 will likely include a number of improvements to importlib to make it easier to use as a basis for custom import hooks (as Brett and Eric noted, better support for customisation of the source -> bytecode compilation step will definitely be one of them. As far as books go, I think the evolution of Python's import system might make an interesting entry if they do a third edition of The Architecture of Open Source Applications [1] :) [1] http://www.aosabook.org/en/index.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 03:38:18 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 07 Sep 2012 01:38:18 +0000 Subject: [issue15874] argparse cannot parse bash variable arguments in file-given arguments In-Reply-To: <1346976291.75.0.854427077128.issue15874@psf.upfronthosting.co.za> Message-ID: <1346981898.51.0.124628451129.issue15874@psf.upfronthosting.co.za> R. David Murray added the comment: I'm not sure this is a good idea. $BAR is supported on the command line because your shell supports it. To support it in files, argparse would have to (re)implement shell parsing, and while we do have a parser in the stdlib that can do some of this (shlex), actually implementing environment variable substitution correctly would be a non-trivial undertaking. And what about the csh users? (Assuming there are any left :) ---------- nosy: +r.david.murray type: behavior -> enhancement versions: +Python 3.4 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 03:51:22 2012 From: report at bugs.python.org (John Nagle) Date: Fri, 07 Sep 2012 01:51:22 +0000 Subject: [issue15873] "datetime" cannot parse ISO 8601 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1346982682.26.0.456476239617.issue15873@psf.upfronthosting.co.za> John Nagle added the comment: Re: "%z format is supported". That's platform-specific; the actual parsing is delegated to the C library. It's not in Python 2.7 / Win32: ValueError: 'z' is a bad directive in format '%Y-%m-%dT%H:%M:%S%z' It really shouldn't be platform-specific; the underlying platform is irrelevant to this task. That's more of a documentation error; the features not common to all supported Python platforms should not be mentioned in the documentation. Re: "I would very much like such promiscuous parser to be implemented in datetime.__new__. " For string input, it's probably better to do this conversion in a specific class-level function. Full ISO 8601 dates/times generally come from computer-generated data via a file or API. If invalid text shows up, it should be detected as an error, not be heuristically interpreted as a date. There's already "fromtimestamp" and "fromordinal", and "isoformat" as an instance method, so "fromisoformat" seems reasonable. I'd also suggest providing a standard subclass of tzinfo in datetime for fixed offsets. That's needed to express the time zone information in an ISO 8601 date. The new "fromisoformat" would convert an ISO 8601 date/time would be convertible to a time-zone "aware" datetime object. If converted back to an ISO 8601 string with .isoformat(), the round trip should preserve the original data, including time zone offset. (Several more implementations of this conversion have turned up. In addition to the four already mentioned, there was one in xml.util, and one in feedparser. There are probably more yet to be found.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 04:29:20 2012 From: report at bugs.python.org (Steven Willis) Date: Fri, 07 Sep 2012 02:29:20 +0000 Subject: [issue15676] mmap: add empty file check prior to offset check In-Reply-To: <1345052794.26.0.230448790651.issue15676@psf.upfronthosting.co.za> Message-ID: <1346984960.1.0.496335090244.issue15676@psf.upfronthosting.co.za> Steven Willis added the comment: Here's a patch for 2.7. I don't know if it cleanly applies to the rest. ---------- keywords: +patch Added file: http://bugs.python.org/file27140/issue15676.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 04:36:41 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 07 Sep 2012 02:36:41 +0000 Subject: [issue15873] "datetime" cannot parse ISO 8601 dates and times In-Reply-To: <1346982682.26.0.456476239617.issue15873@psf.upfronthosting.co.za> Message-ID: Alexander Belopolsky added the comment: On Thu, Sep 6, 2012 at 9:51 PM, John Nagle wrote: > It's not in Python 2.7 / Win32. Python 2.x series is closed and cannot accept new features. Both %z and fixed offset tzinfo subclass are implemented in 3.2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 04:55:28 2012 From: report at bugs.python.org (Nat Hillard) Date: Fri, 07 Sep 2012 02:55:28 +0000 Subject: [issue15874] argparse cannot parse shell variable arguments in file-given arguments In-Reply-To: <1346976291.75.0.854427077128.issue15874@psf.upfronthosting.co.za> Message-ID: <1346986527.76.0.411509458281.issue15874@psf.upfronthosting.co.za> Nat Hillard added the comment: Indeed these are all valid points, and as a zsh user myself I certainly considered the alternative shell issue. That said, if it were at all possible, through a combination of os.environ / shlex, subprocess, and even `source` if necessary, to offload this interpretation to the user's shell (pass the shell a given string, receive its interpretation first before further processing), I could see a lot of benefit from this. Relatedly, I have seem similar requests for environment variable support in configparser, here: http://grokbase.com/t/python/python-list/03ckhw75xr/parsing-environment-variables-in-configparser-files This particular proposal is interesting in that it creates an intermediary between the file's environment variable syntax and the shell's own. Presumably if you standardized the presentation of environment variables within this file you could use os.environ once you had recognized it. That said, I can understand, however, if this is prohibitively costly to implement, and it may well be that this option is ill suited to the task I am putting it to. ---------- title: argparse cannot parse bash variable arguments in file-given arguments -> argparse cannot parse shell variable arguments in file-given arguments _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 05:07:34 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 07 Sep 2012 03:07:34 +0000 Subject: [issue15873] "datetime" cannot parse ISO 8601 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1346987254.44.0.108704105615.issue15873@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I am attaching a quick python only prototype for the proposed feature. My goal is to make date/time objects behave like numeric types for which constructors accept strings produced by str(). Since str() format is ISO 8601, it is natural to accept ISO 8601 formats in constructors. ---------- keywords: +patch Added file: http://bugs.python.org/file27141/issue15873-proto.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 05:52:10 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 07 Sep 2012 03:52:10 +0000 Subject: [issue12014] str.format parses replacement field incorrectly In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za> Message-ID: <1346989929.99.0.0259490308093.issue12014@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 05:56:42 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 07 Sep 2012 03:56:42 +0000 Subject: [issue15520] Document datetime.timestamp() in 3.3 What's New In-Reply-To: <1343807157.88.0.373148573533.issue15520@psf.upfronthosting.co.za> Message-ID: <1346990202.08.0.206584399765.issue15520@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Added in 7ca6b3a16e15 ---------- nosy: +belopolsky resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 05:58:36 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 07 Sep 2012 03:58:36 +0000 Subject: [issue5023] Segfault in datetime.time.strftime("%z") In-Reply-To: <1232556285.78.0.999173961019.issue5023@psf.upfronthosting.co.za> Message-ID: <1346990316.16.0.294408737011.issue5023@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 07:47:36 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 07 Sep 2012 05:47:36 +0000 Subject: [issue15870] PyType_FromSpec should take metaclass as an argument In-Reply-To: <1346946566.36.0.583610018294.issue15870@psf.upfronthosting.co.za> Message-ID: <1346996856.15.0.708679934947.issue15870@psf.upfronthosting.co.za> Martin v. L?wis added the comment: As for declaring ABCs: I don't think the API is necessary, or even helps. An ABC is best created by *calling* ABCMeta, with the appropriate name, a possibly-empty bases tuple, and a dict. What FromSpec could do is to fill out slots with custom functions, which won't be necessary or desirable for ABCs. The really tedious part may be to put all the abstract methods into the ABC, for which having a TypeSpec doesn't help at all. (But I would certainly agree that simplifying creation of ABCs in extension modules is a worthwhile reason for an API addition) For the case that Alexander apparently envisions, i.e. metaclasses where the resulting type objects extend the layout of heap types: it should be possible for an extension module to fill out the entire type "from scratch". This will require knowledge of the layout of heap types, so it can't use just the stable ABI - however, doing this through the stable ABI won't be possible, anyway, since the extended layout needs to know how large a HeapType structure is. If filling out a type with all slots one-by-one is considered too tedious, and patching ob_type too hacky - here is another approach: Use FromSpec to create a type with all slots filled out, then call the metatype to create a subtype of that. I.e. the type which is based on a metatype would actually be a derived class of the type which has the slots defined. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 08:36:12 2012 From: report at bugs.python.org (Ross Lagerwall) Date: Fri, 07 Sep 2012 06:36:12 +0000 Subject: [issue15876] test_curses refleak Message-ID: <1346999772.54.0.326284288663.issue15876@psf.upfronthosting.co.za> New submission from Ross Lagerwall: [1/1] test_curses beginning 6 repetitions 123456 . test_curses leaked [1, 1, 1] references, sum=3 1 test failed: test_curses [154814 refs] ---------- assignee: rosslagerwall messages: 169973 nosy: rosslagerwall priority: low severity: normal status: open title: test_curses refleak type: resource usage _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 08:38:03 2012 From: report at bugs.python.org (Dan Callaghan) Date: Fri, 07 Sep 2012 06:38:03 +0000 Subject: [issue15877] xml.dom.minidom cannot parse ISO-2022-JP Message-ID: <1346999883.79.0.0390921600311.issue15877@psf.upfronthosting.co.za> New submission from Dan Callaghan: Python 2.7.3 (default, Jul 24 2012, 10:05:38) [GCC 4.7.0 20120507 (Red Hat 4.7.0-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> c = u'\u65e5\u672c\u8a9e' >>> import xml.dom.minidom Encoded as UTF-8, everything is fine: >>> xml.dom.minidom.parseString('%s' % c.encode('UTF-8')) but not ISO-2022-JP: >>> xml.dom.minidom.parseString('%s' % c.encode('ISO-2022-JP')) Traceback (most recent call last): File "", line 3, in File "/usr/lib64/python2.7/site-packages/_xmlplus/dom/minidom.py", line 1925, in parseString return expatbuilder.parseString(string) File "/usr/lib64/python2.7/site-packages/_xmlplus/dom/expatbuilder.py", line 942, in parseString return builder.parseString(string) File "/usr/lib64/python2.7/site-packages/_xmlplus/dom/expatbuilder.py", line 223, in parseString parser.Parse(string, True) xml.parsers.expat.ExpatError: not well-formed (invalid token): line 1, column 48 lxml can handle it fine though: >>> import lxml.etree >>> lxml.etree.fromstring('%s' % c.encode('ISO-2022-JP')) >>> _.text == c True ---------- components: XML messages: 169974 nosy: dcallagh priority: normal severity: normal status: open title: xml.dom.minidom cannot parse ISO-2022-JP versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 08:38:26 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 07 Sep 2012 06:38:26 +0000 Subject: [issue15876] test_curses refleak In-Reply-To: <1346999772.54.0.326284288663.issue15876@psf.upfronthosting.co.za> Message-ID: <3XCprK3y5rzQDV@mail.python.org> Roundup Robot added the comment: New changeset c82e3a6553fc by Ross Lagerwall in branch 'default': Issue #15876: Fix a refleak in the curses module http://hg.python.org/cpython/rev/c82e3a6553fc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 08:40:44 2012 From: report at bugs.python.org (Ross Lagerwall) Date: Fri, 07 Sep 2012 06:40:44 +0000 Subject: [issue15876] test_curses refleak In-Reply-To: <1346999772.54.0.326284288663.issue15876@psf.upfronthosting.co.za> Message-ID: <1347000044.68.0.140469365773.issue15876@psf.upfronthosting.co.za> Ross Lagerwall added the comment: This didn't get picked up by Antoine's daily refleak test run because test curses only runs when stdout is a TTY. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 09:02:52 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 07 Sep 2012 07:02:52 +0000 Subject: [issue15870] PyType_FromSpec should take metaclass as an argument In-Reply-To: <1346996856.15.0.708679934947.issue15870@psf.upfronthosting.co.za> Message-ID: <1347001137.3323.0.camel@localhost.localdomain> Antoine Pitrou added the comment: > If filling out a type with all slots one-by-one is considered too > tedious, and patching ob_type too hacky - here is another approach: > Use FromSpec to create a type with all slots filled out, then call the > metatype to create a subtype of that. I.e. the type which is based on > a metatype would actually be a derived class of the type which has the > slots defined. As a matter of fact, this is what the io module is doing (except that the derived type is written in Python). It does feel like pointless complication, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 09:24:49 2012 From: report at bugs.python.org (Steven Bethard) Date: Fri, 07 Sep 2012 07:24:49 +0000 Subject: [issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse) In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za> Message-ID: <1347002689.29.0.779143790606.issue9334@psf.upfronthosting.co.za> Steven Bethard added the comment: Interesting idea! The regex would need a little extra care to interoperate properly with prefix_chars, but the approach doesn't seem crazy. I'd probably call the constructor option something like "args_default_to_positional" (the current behavior is essentially that args default to optional arguments if they look like optionals). I'd be happy to review a patch along these lines. It would probably be good if Anders Kaseorg could also review it to make sure it fully solves his problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 09:29:14 2012 From: report at bugs.python.org (Steven Bethard) Date: Fri, 07 Sep 2012 07:29:14 +0000 Subject: [issue15874] argparse cannot parse shell variable arguments in file-given arguments In-Reply-To: <1346976291.75.0.854427077128.issue15874@psf.upfronthosting.co.za> Message-ID: <1347002954.26.0.549850811141.issue15874@psf.upfronthosting.co.za> Steven Bethard added the comment: You could try declaring a type converter and using the type= parameter of add_argument. Your type converter could look something like: def expanded_path(arg): return os.path.expandvars(arg) Would that work? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 09:37:23 2012 From: report at bugs.python.org (Ross Lagerwall) Date: Fri, 07 Sep 2012 07:37:23 +0000 Subject: [issue15876] test_curses refleak In-Reply-To: <1346999772.54.0.326284288663.issue15876@psf.upfronthosting.co.za> Message-ID: <1347003443.59.0.44394783996.issue15876@psf.upfronthosting.co.za> Changes by Ross Lagerwall : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 10:15:46 2012 From: report at bugs.python.org (=?utf-8?b?0KHQtdGA0LPQtdC5INCa0L7QstCx0LA=?=) Date: Fri, 07 Sep 2012 08:15:46 +0000 Subject: [issue15878] struct long type size Message-ID: <1347005746.88.0.0980620754305.issue15878@psf.upfronthosting.co.za> New submission from ?????? ?????: Such code PackageFile.write(struct.pack( "l", PkgHdrSize)) have different behaviour on 32-bit and 64-bit systems. In case 32-bit system it writes to file 4 bytes. and 8 bytes in case 64-bit system, but in http://docs.python.org/library/struct.html p.7.3.2.2 long type have strict 4-byte size. ---------- messages: 169980 nosy: ??????.????? priority: normal severity: normal status: open title: struct long type size type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 11:02:14 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 07 Sep 2012 09:02:14 +0000 Subject: [issue15878] struct long type size In-Reply-To: <1347005746.88.0.0980620754305.issue15878@psf.upfronthosting.co.za> Message-ID: <1347008534.41.0.605975872486.issue15878@psf.upfronthosting.co.za> Mark Dickinson added the comment: This is expected behaviour. By default, struct.pack and struct.unpack use the *native* size and alignment. Use " invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 11:22:33 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 07 Sep 2012 09:22:33 +0000 Subject: [issue15877] xml.dom.minidom cannot parse ISO-2022-JP In-Reply-To: <1346999883.79.0.0390921600311.issue15877@psf.upfronthosting.co.za> Message-ID: <1347009753.46.0.2216601136.issue15877@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: This is similar to issue13612: pyexpat does not support multibytes encodings. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 12:40:09 2012 From: report at bugs.python.org (Arne Babenhauserheide) Date: Fri, 07 Sep 2012 10:40:09 +0000 Subject: [issue14900] cProfile does not take its result headers as sort arguments In-Reply-To: <1337869163.57.0.920578910684.issue14900@psf.upfronthosting.co.za> Message-ID: <1347014409.14.0.791943809429.issue14900@psf.upfronthosting.co.za> Arne Babenhauserheide added the comment: What would be the best way to get this patch reviewed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 12:47:12 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 07 Sep 2012 10:47:12 +0000 Subject: [issue14900] cProfile does not take its result headers as sort arguments In-Reply-To: <1337869163.57.0.920578910684.issue14900@psf.upfronthosting.co.za> Message-ID: <1347014832.26.0.132305623791.issue14900@psf.upfronthosting.co.za> Andrew Svetlov added the comment: I'll take a look next week if nobody else do it before. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 12:49:07 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 07 Sep 2012 10:49:07 +0000 Subject: [issue12370] Use of super overwrites use of __class__ in class namespace In-Reply-To: <1308522510.81.0.637011547356.issue12370@psf.upfronthosting.co.za> Message-ID: <1347014947.73.0.110387541799.issue12370@psf.upfronthosting.co.za> Nick Coghlan added the comment: OK, I think I have a way to fix this that will actually *reduce* the level of special casing needed in the compiler. Specifically, I think we may be able to make the class statement emit *two* scopes, rather than the current one. The outer scope would be created with MAKE_CLOSURE, and thus names defined there would participate in lexical scoping. The inner scope would use the current MAKE_FUNCTION behaviour, and thus names defined there would be ignored by lexical scoping. "__class__" would then be defined in the outer scope *after* the class has been created. It would roughly like the following, except with __qualname__ still set correctly: >>> def outer(): ... class inner: ... def method(self): ... print(the_class) ... the_class = inner ... return inner ... >>> cls = outer() >>> cls.method() Traceback (most recent call last): File "", line 1, in TypeError: method() missing 1 required positional argument: 'self' >>> cls().method() .inner'> The one potential wrinkle I see is whether this might cause a semantic change for name references from the class body to a containing function, but I think the technique is at least worth trying. If this works, __class__ would just become a completely ordinary cell reference, and override it at class scope should work again. super() itself would still need magic to handle the automatic lookup of the first positional argument to the calling function, but at least the symtable magic should be able to go away. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 15:27:50 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 07 Sep 2012 13:27:50 +0000 Subject: [issue15867] make importlib documentation easier to use In-Reply-To: <1346894563.49.0.339877810223.issue15867@psf.upfronthosting.co.za> Message-ID: <1347024470.94.0.562209363276.issue15867@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- title: It's hard to decypher how to build off of the provided objects from the importlib docs -> make importlib documentation easier to use _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 17:44:41 2012 From: report at bugs.python.org (Jon Obermark) Date: Fri, 07 Sep 2012 15:44:41 +0000 Subject: [issue15879] set.__or__, __and__, etc create subclass types, but ignore __new__ Message-ID: <1347032681.85.0.731459990005.issue15879@psf.upfronthosting.co.za> New submission from Jon Obermark: If they are not going to call the __metaclass__ or the class __new__, then they should return `set` objects instead of subclass objects, so that it is clear what is going on. As it is, the results of set operations receive some subclass information but not all. So they are not really obeying the notion of a subclass: the results are neither `set` objects, nor properly-constructed objects of the `set` subclass. e.g. class Fooset(Set): def __new__(cls, s = []): print 'New called' self = super(Fooset, cls).__new__(cls) self.update(s) if isinstance(s, Fooset): self.foo = s.foo else: self.foo = 'default' return self x = Fooset([1,2,5]) y = x|x The object `y` reports being of the type `Fooset`, but has not been constructed by the `type` that makes `Fooset` objects. ---------- messages: 169986 nosy: Jon.Obermark priority: normal severity: normal status: open title: set.__or__, __and__, etc create subclass types, but ignore __new__ _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 18:22:32 2012 From: report at bugs.python.org (Julian Berman) Date: Fri, 07 Sep 2012 16:22:32 +0000 Subject: [issue15867] make importlib documentation easier to use In-Reply-To: <1346894563.49.0.339877810223.issue15867@psf.upfronthosting.co.za> Message-ID: <1347034952.59.0.533299774384.issue15867@psf.upfronthosting.co.za> Julian Berman added the comment: Eric: Yeah I've seen that, it's the one thing that I kept open as I was turning back and forth through the various parts of importlib. So yeah I like that document certainly at least a bit :). Also thanks to both you and Brett for linking that issue, that's certainly something I'll keep an eye on. Just to repeat the specific things that perhaps we could work on -- I strongly agree that the top of importlib's docs would benefit from reworking the See Also at the top. Also, perhaps that monumental undertaking would be a thing that could be wrangled :P -- like you said, import hooks seem to have two broad use cases: changing *where* a module comes from away from a simple file containing Python source code on a filesystem, and secondly changing what happens when a module is being imported. So I guess what I would love to have would be an example for each of those. An example of a Loader that loaded from somewhere else other than a file, and an example of an Importer that did something else when executing. I'm sure you'll correct me if I've missed an important one. If that's reasonable sounding and I manage to succeed in my own use case, perhaps I'll take a shot at that. One thing I certainly understand here is that usually I (we) wouldn't have this problem since blog posts and other third party documentation and code can provide examples that are helpful enough to help developers get a sense of what they need to write. The thing for me here was that I didn't really find anything helpful in that sector. importlib is new obviously, so maybe what's given me trouble will be mitigated after 3.3 gets released and a few people write up some examples on their own. I recognize that there was a huge undertaking here, and that it's still being honed, I hope in no way did this sound disparaging :). Also I hope it didn't sound like a misplaced StackOverflow post -- although certainly the confirmation that I was on the right track should help me finish this off quite easily, so thanks for that as well :). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 18:23:54 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 07 Sep 2012 16:23:54 +0000 Subject: [issue15874] argparse cannot parse shell variable arguments in file-given arguments In-Reply-To: <1346976291.75.0.854427077128.issue15874@psf.upfronthosting.co.za> Message-ID: <1347035034.57.0.292615354316.issue15874@psf.upfronthosting.co.za> R. David Murray added the comment: I had forgotten all about os.path.expandvars. Note, however, that that function is very naive: >>> os.path.expandvars("'$HOME'") "'/home/rdmurray'" That is, it is doing unconditional substitution, not parsing shell syntax. It should work well for simple cases, though. It might be worth throwing up a trial balloon on python-ideas for adding something to shlex that would do a "better" job of environment variable substitution for the version of shell syntax that shlex supports, which would therefore become a sort of platform-independent syntax for doing this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 18:31:16 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 07 Sep 2012 16:31:16 +0000 Subject: [issue15879] set.__or__, __and__, etc create subclass types, but ignore __new__ In-Reply-To: <1347032681.85.0.731459990005.issue15879@psf.upfronthosting.co.za> Message-ID: <1347035476.03.0.415370045514.issue15879@psf.upfronthosting.co.za> R. David Murray added the comment: It is probably true that this is a bug, but subclasses of mutable classes do not normally override __new__. (I'm curious what your use case is for doing so.) ---------- nosy: +benjamin.peterson, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 18:40:15 2012 From: report at bugs.python.org (Kalle Rutanen) Date: Fri, 07 Sep 2012 16:40:15 +0000 Subject: [issue15880] os.path.split() and long UNC names Message-ID: <1347036015.89.0.836232949292.issue15880@psf.upfronthosting.co.za> New submission from Kalle Rutanen: On Windows, long-UNC paths are needed to inspect and modify paths with more than 260 characters. The os.path.split() function behaves incorrectly in the presence of a long-UNC prefix //?/ or \\?\. Consider iterating d = os.path.split(d)[0] with d = '//?/e:/python-test/dir'. Then the values of d are as follows: '//?/e:/python-test/dir' '//?/e:/python-test' '//?/e:' '//?' '//' The two last splits are the incorrect ones, where the splitting should end at '//?/e:'. One consequence of this is that os.makedirs(d) crashes, because it attempts to run os.mkdir('//') at the bottom of its recursion. The same thing happens when replacing all / with \\ in the above. ---------- components: Library (Lib) messages: 169990 nosy: kaba2 priority: normal severity: normal status: open title: os.path.split() and long UNC names type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 18:44:39 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 07 Sep 2012 16:44:39 +0000 Subject: [issue15879] set.__or__, __and__, etc create subclass types, but ignore __new__ In-Reply-To: <1347032681.85.0.731459990005.issue15879@psf.upfronthosting.co.za> Message-ID: <1347036279.99.0.232468930327.issue15879@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: This was already fixed (in the 3.x releases) by issue1721812. ---------- nosy: +amaury.forgeotdarc resolution: -> out of date status: open -> closed superseder: -> A subclass of set doesn't always have __init__ called. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 18:50:50 2012 From: report at bugs.python.org (Kalle Rutanen) Date: Fri, 07 Sep 2012 16:50:50 +0000 Subject: [issue15880] os.path.split() and long UNC names In-Reply-To: <1347036015.89.0.836232949292.issue15880@psf.upfronthosting.co.za> Message-ID: <1347036650.66.0.528985809212.issue15880@psf.upfronthosting.co.za> Kalle Rutanen added the comment: By inspecting the code for os.path.split() in ntpath.py, one sees that the problem is actually in os.path.splitdrive(), which does not handle long-UNC paths. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 18:59:37 2012 From: report at bugs.python.org (Mike Hoy) Date: Fri, 07 Sep 2012 16:59:37 +0000 Subject: [issue12067] Doc: remove errors about mixed-type comparisons. In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za> Message-ID: <1347037177.44.0.583892592532.issue12067@psf.upfronthosting.co.za> Changes by Mike Hoy : ---------- nosy: +mikehoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 19:00:35 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 07 Sep 2012 17:00:35 +0000 Subject: [issue12370] Use of super overwrites use of __class__ in class namespace In-Reply-To: <1308522510.81.0.637011547356.issue12370@psf.upfronthosting.co.za> Message-ID: <1347037235.37.0.307134597927.issue12370@psf.upfronthosting.co.za> Eric Snow added the comment: Wouldn't the following also start working (currently a NameError)? class X: def f(self): print(f.__qualname__) def g(self): f(None) X().f() X().g() How about this[1] (also currently a NameError): class Outer: class Inner: class Worker: pass class InnerSubclass(Inner): class Worker(Inner.Worker): pass I wouldn't mind the semantic change, but it would be a change nonetheless. [1] See http://mail.python.org/pipermail/python-list/2011-April/601605.html ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 19:03:31 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 07 Sep 2012 17:03:31 +0000 Subject: [issue12370] Use of super overwrites use of __class__ in class namespace In-Reply-To: <1308522510.81.0.637011547356.issue12370@psf.upfronthosting.co.za> Message-ID: <1347037411.68.0.879115974689.issue12370@psf.upfronthosting.co.za> Eric Snow added the comment: Actually, that second would still not work (it would have to pass through the non-lexical inner scope that Nick mentioned). Is that also the case for the first one? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 19:06:54 2012 From: report at bugs.python.org (Kalle Rutanen) Date: Fri, 07 Sep 2012 17:06:54 +0000 Subject: [issue15880] os.path.split() and long UNC names In-Reply-To: <1347036015.89.0.836232949292.issue15880@psf.upfronthosting.co.za> Message-ID: <1347037614.49.0.909983525188.issue15880@psf.upfronthosting.co.za> Kalle Rutanen added the comment: It seems to me that this problem can be fixed by replacing splitdrive with splitunc at line 170 in ntpath.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 19:24:47 2012 From: report at bugs.python.org (Chris Kaynor) Date: Fri, 07 Sep 2012 17:24:47 +0000 Subject: [issue6178] Core error in Py_EvalFrameEx 2.6.2 In-Reply-To: <1243956972.97.0.133216910206.issue6178@psf.upfronthosting.co.za> Message-ID: <1347038687.53.0.423812580455.issue6178@psf.upfronthosting.co.za> Chris Kaynor added the comment: Was any resolution found for this? I am debugging some intermittent crashes now which have the same visible callstack as Tim reported. tstate->frame is NULL on line 2717 of ceval.c I am using an in-house compiled Python 2.6.4, compiled with Visual Studio 2008, compiled for x64 and running on Windows 7. The Python code that appears to be executing is calling into the pywin32 module a number of times. ---------- nosy: +Chris.Kaynor _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 19:26:31 2012 From: report at bugs.python.org (Jon Obermark) Date: Fri, 07 Sep 2012 17:26:31 +0000 Subject: [issue15879] set.__or__, __and__, etc create subclass types, but ignore __new__ In-Reply-To: <1347032681.85.0.731459990005.issue15879@psf.upfronthosting.co.za> Message-ID: <1347038791.1.0.909280720771.issue15879@psf.upfronthosting.co.za> Jon Obermark added the comment: The closing author is correct, the use case is adequately covered by __init__, and that has been fixed in 3. It makes sense this will not be backported. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 19:31:55 2012 From: report at bugs.python.org (Tim Savannah) Date: Fri, 07 Sep 2012 17:31:55 +0000 Subject: [issue6178] Core error in Py_EvalFrameEx 2.6.2 In-Reply-To: <1243956972.97.0.133216910206.issue6178@psf.upfronthosting.co.za> Message-ID: <1347039115.03.0.442381164482.issue6178@psf.upfronthosting.co.za> Tim Savannah added the comment: As an update (since someone else has this problem) this issue stopped once we converted from centos to archlinux (www.archlinux.org). May be an underlying issue with something in the centos environment. We used the same modules same configuration basically same compilation for python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 19:46:18 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 07 Sep 2012 17:46:18 +0000 Subject: [issue15822] installed python may fail incorrectly trying to rebuild lib2to3 grammar pickles In-Reply-To: <1346321126.73.0.788135574831.issue15822@psf.upfronthosting.co.za> Message-ID: <1347039978.68.0.987616349226.issue15822@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I think the patch for issue 15645 was incorrect. Instead of generating the pickles in the source tree and copying them, it should have arranged lib2to3 to generate them in the target directory instead (just as all the compileall invocations also generate files in LIBDEST). There are multiple ways to achieve this. The least intrusive (perhaps) is to insert "$(DESTDIR)$(LIBDEST)" into sys.path before importing lib2to3 in the Makefile. The approach that I suggest is to make lib2to3.pgen2.driver a script which expects a .txt path, and generates a pickle next to it, so the installation would do $(PYTHON_FOR_BUILD) -m lib2to3.pgen2.driver $(DESTDIR)$(LIBDEST)/lib2to3/Grammar.txt $(PYTHON_FOR_BUILD) -m lib2to3.pgen2.driver $(DESTDIR)$(LIBDEST)/lib2to3/PatternGrammar.txt ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 20:10:06 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 07 Sep 2012 18:10:06 +0000 Subject: [issue15340] OSError with "import random" when /dev/urandom doesn't exist (regression from 2.6) In-Reply-To: <1342132229.15.0.69254682318.issue15340@psf.upfronthosting.co.za> Message-ID: <1347041406.14.0.881069393981.issue15340@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I disagree that the regression is critical. IIUC, it fails on systems without urandom, such as Tru64 and HPUX. However, failure to support such systems is *not* critical, IMO; I think that OS-specific failures should be considered critical only if they occur on Linux, Windows, or OSX. So I suggest that the priority of this issue is reduced. More relevant than breaking HPUX is, IMO, that urandom is actually documented to raise NotImplementedError, so the patch looks good. For best compatibility, the actual spelling of the error message from 2.6 should be restored. I'm puzzled by https://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=KRNG11I which claims that HPUX 11.11 (at least) *does* have /dev/urandom. Maybe your installation doesn't have KRNG11i in /etc/loadmods? Also, the claim that it breaks Tru64 contradicts with http://en.wikipedia.org/wiki//dev/random which claims that Tru64 5.1B (at least) does have /dev/urandom. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 20:19:32 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 07 Sep 2012 18:19:32 +0000 Subject: [issue15340] OSError with "import random" when /dev/urandom doesn't exist (regression from 2.6) In-Reply-To: <1342132229.15.0.69254682318.issue15340@psf.upfronthosting.co.za> Message-ID: <1347041972.22.0.925244033442.issue15340@psf.upfronthosting.co.za> Martin v. L?wis added the comment: An interesting question is whether the patch should be applied to 2.6 and 3.1. It is not a security fix in itself, which suggests that it shouldn't apply. OTOH, it's a follow-up to an earlier security fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 20:28:16 2012 From: report at bugs.python.org (Ian Wienand) Date: Fri, 07 Sep 2012 18:28:16 +0000 Subject: [issue15340] OSError with "import random" when /dev/urandom doesn't exist (regression from 2.6) In-Reply-To: <1342132229.15.0.69254682318.issue15340@psf.upfronthosting.co.za> Message-ID: <1347042496.3.0.677635881093.issue15340@psf.upfronthosting.co.za> Ian Wienand added the comment: I'm not sure what systems are defined as critical or not. Although python is not really installable/configurable by end-users on ESXi, I noticed during development because we use python very early in the boot, before /dev/urandom appears for us (it comes from a kernel module loaded later). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 20:56:40 2012 From: report at bugs.python.org (Chris McDonough) Date: Fri, 07 Sep 2012 18:56:40 +0000 Subject: [issue15881] multiprocessing 'NoneType' object is not callable Message-ID: <1347044200.13.0.235512745295.issue15881@psf.upfronthosting.co.za> New submission from Chris McDonough: The symptom is an exact duplicate of the symptom reported in the following (closed) issue: http://bugs.python.org/issue9775 The issue is also related to the following other issues: http://bugs.python.org/issue4106 http://bugs.python.org/issue9205 http://bugs.python.org/issue9207 To reproduce the symptom driving the patches that will be attached to this issue: git clone git://github.com/pypa/pip.git cd pip /any/python setup.py dev /any/python setup.py test You can either wait for the entire test suite to finish or you can press ctrl-C at any time (the tests take a long time). In either case, a traceback like the following will be printed to the console. Error in atexit._run_exitfuncs: Traceback (most recent call last): File "/home/chrism/opt/Python-2.7.3/lib/python2.7/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/home/chrism/opt/Python-2.7.3/lib/python2.7/multiprocessing/util.py", line 284, in _exit_function info('process shutting down') TypeError: 'NoneType' object is not callable Error in sys.exitfunc: Traceback (most recent call last): File "/home/chrism/opt/Python-2.7.3/lib/python2.7/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/home/chrism/opt/Python-2.7.3/lib/python2.7/multiprocessing/util.py", line 284, in _exit_function info('process shutting down') TypeError: 'NoneType' object is not callable >From what I understand in other issues, multiprocessing.util._exit_function shouldn't actually be called *after* the containing module's globals are destroyed (it should be called before), but this does indeed happen. Patches will be attached that anticipate the symptom and prevent a shutdown error. One will be attached for Python 2.7 branch, the other for the Python tip. Each causes functions that are called at shutdown time to keep a reference around to other functions and globals used within the function, and each does some checks for the insane state and prevents an error from happening in this insane state. ---------- components: Library (Lib) messages: 170003 nosy: mcdonc priority: normal severity: normal status: open title: multiprocessing 'NoneType' object is not callable type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 21:04:42 2012 From: report at bugs.python.org (The Written Word) Date: Fri, 07 Sep 2012 19:04:42 +0000 Subject: [issue15340] OSError with "import random" when /dev/urandom doesn't exist (regression from 2.6) In-Reply-To: <1342132229.15.0.69254682318.issue15340@psf.upfronthosting.co.za> Message-ID: <1347044682.69.0.0162006882315.issue15340@psf.upfronthosting.co.za> The Written Word added the comment: We're running Tru64 UNIX 5.1A, not 5.1B which definitely doesn't have /dev/urandom. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 21:06:02 2012 From: report at bugs.python.org (The Written Word) Date: Fri, 07 Sep 2012 19:06:02 +0000 Subject: [issue15340] OSError with "import random" when /dev/urandom doesn't exist (regression from 2.6) In-Reply-To: <1342132229.15.0.69254682318.issue15340@psf.upfronthosting.co.za> Message-ID: <1347044762.52.0.601587307714.issue15340@psf.upfronthosting.co.za> The Written Word added the comment: We do not have KRNG11i installed. It did not ship with the original installation of HP-UX 11.11. It needs to be loaded after-the-fact and we cannot be ensured that our customers will have this module installed nor do we wish to make it a requirement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 21:10:54 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 07 Sep 2012 19:10:54 +0000 Subject: [issue15851] Lib/robotparser.py doesn't accept setting a user agent string, instead it uses the default. In-Reply-To: <1346610964.7.0.836759738208.issue15851@psf.upfronthosting.co.za> Message-ID: <1347045054.66.0.127391915664.issue15851@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Enhancements can only be targeted at 3.4, where robotparser is now urllib.robotparser I wonder if documenting the simple solution would be sufficient. ---------- nosy: +orsenthil, terry.reedy versions: +Python 3.4 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 21:11:37 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 07 Sep 2012 19:11:37 +0000 Subject: [issue15851] Lib/robotparser.py doesn't accept setting a user agent string, instead it uses the default. In-Reply-To: <1346610964.7.0.836759738208.issue15851@psf.upfronthosting.co.za> Message-ID: <1347045097.22.0.748407668869.issue15851@psf.upfronthosting.co.za> Terry J. Reedy added the comment: In any case, a doc change *could* go in 2.7 and 3.3/2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 21:13:35 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 07 Sep 2012 19:13:35 +0000 Subject: [issue15881] multiprocessing 'NoneType' object is not callable In-Reply-To: <1347044200.13.0.235512745295.issue15881@psf.upfronthosting.co.za> Message-ID: <1347045215.91.0.110346006119.issue15881@psf.upfronthosting.co.za> Changes by Richard Oudkerk : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 21:15:56 2012 From: report at bugs.python.org (Chris McDonough) Date: Fri, 07 Sep 2012 19:15:56 +0000 Subject: [issue15881] multiprocessing 'NoneType' object is not callable In-Reply-To: <1347044200.13.0.235512745295.issue15881@psf.upfronthosting.co.za> Message-ID: <1347045356.97.0.526795381494.issue15881@psf.upfronthosting.co.za> Chris McDonough added the comment: Patch for tip. ---------- keywords: +patch Added file: http://bugs.python.org/file27142/shutdown_typeerror-tip.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 21:23:28 2012 From: report at bugs.python.org (Chris McDonough) Date: Fri, 07 Sep 2012 19:23:28 +0000 Subject: [issue15881] multiprocessing 'NoneType' object is not callable In-Reply-To: <1347044200.13.0.235512745295.issue15881@psf.upfronthosting.co.za> Message-ID: <1347045808.15.0.441162441845.issue15881@psf.upfronthosting.co.za> Chris McDonough added the comment: 2.7 branch patch. ---------- Added file: http://bugs.python.org/file27143/shutdown_typeerror-27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 21:40:11 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 07 Sep 2012 19:40:11 +0000 Subject: [issue15881] multiprocessing 'NoneType' object is not callable In-Reply-To: <1347044200.13.0.235512745295.issue15881@psf.upfronthosting.co.za> Message-ID: <1347046811.62.0.519434144141.issue15881@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- stage: -> patch review versions: -Python 2.6, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 21:47:08 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 07 Sep 2012 19:47:08 +0000 Subject: [issue15863] Fine-grained info about Python versions which support changes introduced in micro releases In-Reply-To: <1346798659.62.0.336544157965.issue15863@psf.upfronthosting.co.za> Message-ID: <1347047228.12.0.113779159957.issue15863@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I do not think there should be references between the Python 2 docs and Python 3 docs. But within each, I think it ok to have exceptional multiple references for what is, I believe, a unique situation: a security fix that required a new feature. Do it however seems most graceful. My first thought was that someone seeing "added in 2.6.8' should know that adding a feature in a bugfix release is almost never done, hence it might not be in 2.7.0. But then I remembered that this fix is mainly for web sites, and the reader selecting which Python versions to use might not be a Python programmer. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 21:56:17 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 07 Sep 2012 19:56:17 +0000 Subject: [issue15863] Fine-grained info about Python versions which support changes introduced in micro releases In-Reply-To: <1346798659.62.0.336544157965.issue15863@psf.upfronthosting.co.za> Message-ID: <1347047777.54.0.396676656936.issue15863@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Well, the patch is welcome. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 23:07:54 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 07 Sep 2012 21:07:54 +0000 Subject: [issue15865] reflect bare star * in function signature documentation In-Reply-To: <1346805751.63.0.697181229134.issue15865@psf.upfronthosting.co.za> Message-ID: <1347052074.52.0.442494261924.issue15865@psf.upfronthosting.co.za> Terry J. Reedy added the comment: By looking at x.py, I confirmed that the added stars are correct. Also, the correction of 'header' to 'hdr' is correct. However, for threading.py in 3.3.0, I see class Thread: ... def __init__(self, group=None, target=None, name=None, args=(), kwargs=None, *, daemon=None): whereas the patch and existing .rst -.. class:: Thread(group=None, target=None, name=None, args=(), kwargs={}, +.. class:: Thread(group=None, target=None, name=None, args=(), kwargs={}, \ verbose=None, *, daemon=None) has an extra 'verbose=None' that should be removed there and in any explanatory text that follows. (The fact that we found 2 doc signature errors other than the 4 missing *s suggests that we need a tool to systematically compare doc signature to code signature.) ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 23:43:08 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 07 Sep 2012 21:43:08 +0000 Subject: [issue15865] reflect bare star * in function signature documentation In-Reply-To: <1346805751.63.0.697181229134.issue15865@psf.upfronthosting.co.za> Message-ID: <1347054188.9.0.567736992255.issue15865@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks, Terry. If anyone is curious, it looks like the verbose keyword argument was added to the docs (and to threading.py) in revision f71acc4b2341, and then subsequently removed (but not from the docs) in revision 8ec51b2e57c2. > (The fact that we found 2 doc signature errors other than the 4 missing *s suggests that we need a tool to systematically compare doc signature to code signature.) Out of curiosity, can anyone summarize what our existing tooling might already be able to do in this regard (e.g. Sphinx or pydoc)? I will update the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 23:56:06 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 07 Sep 2012 21:56:06 +0000 Subject: [issue15340] OSError with "import random" when /dev/urandom doesn't exist (regression from 2.6) In-Reply-To: <1342132229.15.0.69254682318.issue15340@psf.upfronthosting.co.za> Message-ID: <3XDCC861T1zQ0h@mail.python.org> Roundup Robot added the comment: New changeset 2e8b01583839 by Antoine Pitrou in branch '3.2': Issue #15340: Fix importing the random module when /dev/urandom cannot be opened. http://hg.python.org/cpython/rev/2e8b01583839 New changeset a53fc9982e2a by Antoine Pitrou in branch 'default': Issue #15340: Fix importing the random module when /dev/urandom cannot be opened. http://hg.python.org/cpython/rev/a53fc9982e2a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 7 23:58:47 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 07 Sep 2012 21:58:47 +0000 Subject: [issue15340] OSError with "import random" when /dev/urandom doesn't exist (regression from 2.6) In-Reply-To: <1342132229.15.0.69254682318.issue15340@psf.upfronthosting.co.za> Message-ID: <3XDCGG4ZN0zQ9B@mail.python.org> Roundup Robot added the comment: New changeset edbf37ace03c by Antoine Pitrou in branch '2.7': Issue #15340: Fix importing the random module when /dev/urandom cannot be opened. http://hg.python.org/cpython/rev/edbf37ace03c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 00:00:17 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 07 Sep 2012 22:00:17 +0000 Subject: [issue15340] OSError with "import random" when /dev/urandom doesn't exist (regression from 2.6) In-Reply-To: <1342132229.15.0.69254682318.issue15340@psf.upfronthosting.co.za> Message-ID: <1347055217.17.0.443441074321.issue15340@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, this is now fixed in 3.2/3.3/2.7. I'll leave it to Martin and Benjamin whether this should be backported to 2.6 and 3.1. (Georg, this changeset should probably be ported to 3.3.0 too) ---------- priority: release blocker -> high versions: -Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 00:47:55 2012 From: report at bugs.python.org (Aaron) Date: Fri, 07 Sep 2012 22:47:55 +0000 Subject: [issue15882] _decimal.Decimal constructed from tuple Message-ID: <1347058075.63.0.395926246222.issue15882@psf.upfronthosting.co.za> New submission from Aaron: I think I may have found a problem with the code that constructs Infinity from tuples in the C _decimal module. # pure python (3.x or 2.x) >>> decimal.Decimal( (0, (0, ), 'F')) Decimal('Infinity') # _decimal >>> decimal.Decimal( (0, (0, ), 'F')) Traceback (most recent call last): File "", line 1, in decimal.InvalidOperation: [] Also, there is no unit test coverage for constructing these special values from tuples either. I have provided some that pass with the existing pure python code and with the modifications to the _decimal C code. The unit tests can be applied to Python 2.7.x as well, if desired. They would go in the ExplicitConstructionTest.test_explicit_from_tuples() method. ---------- components: Extension Modules files: _decimal.diff keywords: patch messages: 170017 nosy: hac.man priority: normal severity: normal status: open title: _decimal.Decimal constructed from tuple versions: Python 3.3 Added file: http://bugs.python.org/file27144/_decimal.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 01:01:05 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 07 Sep 2012 23:01:05 +0000 Subject: [issue15882] _decimal.Decimal constructed from tuple In-Reply-To: <1347058075.63.0.395926246222.issue15882@psf.upfronthosting.co.za> Message-ID: <1347058865.51.0.796232694126.issue15882@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 01:17:31 2012 From: report at bugs.python.org (Arne Babenhauserheide) Date: Fri, 07 Sep 2012 23:17:31 +0000 Subject: [issue14900] cProfile does not take its result headers as sort arguments In-Reply-To: <1337869163.57.0.920578910684.issue14900@psf.upfronthosting.co.za> Message-ID: <1347059851.95.0.671150665285.issue14900@psf.upfronthosting.co.za> Arne Babenhauserheide added the comment: Thank you! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 02:40:26 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 08 Sep 2012 00:40:26 +0000 Subject: [issue12370] Use of super overwrites use of __class__ in class namespace In-Reply-To: <1347037411.68.0.879115974689.issue12370@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: Yep. The only name in the new scope would be "__class__". Everything else, including method names, should remain invisible from method bodies. I'm not 100% sure it will work as we want, but that's because I'm not sure if we can avoid causing a semantic change for classes at module scope. I just figure it's worth trying. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 03:10:53 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 08 Sep 2012 01:10:53 +0000 Subject: [issue15865] reflect bare star * in function signature documentation In-Reply-To: <1346805751.63.0.697181229134.issue15865@psf.upfronthosting.co.za> Message-ID: <1347066653.54.0.0291109648306.issue15865@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Here is an updated patch that incorporates Terry's suggestion. ---------- Added file: http://bugs.python.org/file27145/issue-15865-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 03:46:48 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 08 Sep 2012 01:46:48 +0000 Subject: [issue12370] Use of super overwrites use of __class__ in class namespace In-Reply-To: <1308522510.81.0.637011547356.issue12370@psf.upfronthosting.co.za> Message-ID: <1347068808.85.0.244662883557.issue12370@psf.upfronthosting.co.za> Eric Snow added the comment: sounds like it would be worth a shot ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 06:24:29 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 08 Sep 2012 04:24:29 +0000 Subject: [issue15881] multiprocessing 'NoneType' object is not callable In-Reply-To: <1347044200.13.0.235512745295.issue15881@psf.upfronthosting.co.za> Message-ID: <1347078269.4.0.0311402048639.issue15881@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: The patch makes sense. I'll take another look over the weekend, but it seems to be ready to be applied. ---------- assignee: -> belopolsky nosy: +belopolsky stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 07:21:31 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 08 Sep 2012 05:21:31 +0000 Subject: [issue15881] multiprocessing 'NoneType' object is not callable In-Reply-To: <1347044200.13.0.235512745295.issue15881@psf.upfronthosting.co.za> Message-ID: <1347081691.4.0.192366102991.issue15881@psf.upfronthosting.co.za> Chris Jerdonek added the comment: + # NB: we hold on to references to functions in the arglist due to the This is a nit, but I think adding "NB:", "Note:", etc. to the beginning of a comment is redundant because by being a comment it is already implicit that it should be noted. ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 07:33:53 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Sat, 08 Sep 2012 05:33:53 +0000 Subject: [issue15822] installed python may fail incorrectly trying to rebuild lib2to3 grammar pickles In-Reply-To: <1346321126.73.0.788135574831.issue15822@psf.upfronthosting.co.za> Message-ID: <1347082433.71.0.216001195431.issue15822@psf.upfronthosting.co.za> Ronald Oussoren added the comment: See als Issue15838. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 07:34:20 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Sat, 08 Sep 2012 05:34:20 +0000 Subject: [issue15645] 2to3 Grammar pickles not created when upgrading to 3.3.0b2 In-Reply-To: <1344932180.41.0.826216341416.issue15645@psf.upfronthosting.co.za> Message-ID: <1347082460.93.0.679429006676.issue15645@psf.upfronthosting.co.za> Ronald Oussoren added the comment: See also Issue15838 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 07:42:06 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Sat, 08 Sep 2012 05:42:06 +0000 Subject: [issue15822] installed python may fail incorrectly trying to rebuild lib2to3 grammar pickles In-Reply-To: <1346321126.73.0.788135574831.issue15822@psf.upfronthosting.co.za> Message-ID: <1347082926.13.0.951309433256.issue15822@psf.upfronthosting.co.za> Ronald Oussoren added the comment: The other alternative to fix this is to revert the patch in issue 15645 and then remove the -E flag from PYTHON_FOR_BUILD. PYTHON_FOR_BUILD was introduced by a, possibly incomplete, attempt to introduce support for cross compiling. In particular, the variable was introduced in issue 14330. Neither the patch, nor the tracker discussion explains why the -E is necessary. It might be because all uses of $(BUILDPYTHON) that were replaced by PYTHON_FOR_BUILD had the -E flag at the time. BTW. There also doesn't seem to documentation for cross building. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 07:48:26 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 08 Sep 2012 05:48:26 +0000 Subject: [issue15340] OSError with "import random" when /dev/urandom doesn't exist (regression from 2.6) In-Reply-To: <1342132229.15.0.69254682318.issue15340@psf.upfronthosting.co.za> Message-ID: <1347083306.07.0.256232571512.issue15340@psf.upfronthosting.co.za> Georg Brandl added the comment: Now picked into the 3.3.0 release clone as 6a782496f90a. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 07:49:03 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 08 Sep 2012 05:49:03 +0000 Subject: [issue15781] test_threaded_import fails with -j4 In-Reply-To: <1345883620.41.0.296577026972.issue15781@psf.upfronthosting.co.za> Message-ID: <1347083343.06.0.6255522352.issue15781@psf.upfronthosting.co.za> Georg Brandl added the comment: Now picked into 3.3.0 release clone as 85070f284fd2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 07:49:26 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 08 Sep 2012 05:49:26 +0000 Subject: [issue15784] OSError.__str__() should distinguish between errno and winerror In-Reply-To: <1345920277.5.0.279969365859.issue15784@psf.upfronthosting.co.za> Message-ID: <1347083366.06.0.611017036592.issue15784@psf.upfronthosting.co.za> Georg Brandl added the comment: Done in 4e941113e4fa. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 07:49:50 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 08 Sep 2012 05:49:50 +0000 Subject: [issue15785] curses.get_wch() returns keypad codes incorrectly In-Reply-To: <1345975778.97.0.705241878581.issue15785@psf.upfronthosting.co.za> Message-ID: <1347083390.09.0.131096942028.issue15785@psf.upfronthosting.co.za> Georg Brandl added the comment: Now picked into 3.3.0 release clone in 23377e88487b. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 07:52:25 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 08 Sep 2012 05:52:25 +0000 Subject: [issue15828] imp.load_module doesn't support C_EXTENSION type In-Reply-To: <1346398348.83.0.242228991466.issue15828@psf.upfronthosting.co.za> Message-ID: <1347083545.06.0.870837452854.issue15828@psf.upfronthosting.co.za> Georg Brandl added the comment: Picked as 4f6f59303146 and a4a9c5717204. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 07:53:43 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 08 Sep 2012 05:53:43 +0000 Subject: [issue14223] curses addch broken on Python3.3a1 In-Reply-To: <1331153094.15.0.871612927682.issue14223@psf.upfronthosting.co.za> Message-ID: <1347083623.41.0.489310568658.issue14223@psf.upfronthosting.co.za> Georg Brandl added the comment: Done in d6d632f254ee. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 07:58:36 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 08 Sep 2012 05:58:36 +0000 Subject: [issue15847] parse_args stopped accepting tuples In-Reply-To: <1346591535.01.0.313863035332.issue15847@psf.upfronthosting.co.za> Message-ID: <1347083916.56.0.497124313264.issue15847@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed in release clone as 8c2e87aeb707. Please apply to the main branches as usual. ---------- priority: release blocker -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 08:06:53 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 08 Sep 2012 06:06:53 +0000 Subject: [issue13992] Segfault in PyTrash_destroy_chain In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za> Message-ID: <1347084413.53.0.797671220329.issue13992@psf.upfronthosting.co.za> Georg Brandl added the comment: Picked as 5aa1bc2f00ad. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 08:50:46 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 08 Sep 2012 06:50:46 +0000 Subject: [issue15882] _decimal.Decimal constructed from tuple In-Reply-To: <1347058075.63.0.395926246222.issue15882@psf.upfronthosting.co.za> Message-ID: <1347087046.72.0.347569613082.issue15882@psf.upfronthosting.co.za> Stefan Krah added the comment: Infinities do not have payloads. It's a bug in decimal.py that it accepts non-empty coefficients when constructing infinities. Since there was a corresponding unit test for as_tuple(), I've kept the wrong representation for _decimal: # XXX non-compliant infinity payload. d = Decimal("Infinity") self.assertEqual(d.as_tuple(), (0, (0,), 'F') ) But this unit test is only executed for the Python version: # XXX coefficient in infinity should raise an error if self.decimal == P: d = Decimal( (0, (4, 5, 3, 4), 'F') ) self.assertEqual(d.as_tuple(), (0, (0,), 'F')) d = Decimal( (1, (0, 2, 7, 1), 'F') ) self.assertEqual(d.as_tuple(), (1, (0,), 'F')) My suggestion is to disallow non-empty tuples for decimal.py and change the infinity tuple to (0, (), 'F'). ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 09:13:27 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 08 Sep 2012 07:13:27 +0000 Subject: [issue15882] _decimal.Decimal constructed from tuple In-Reply-To: <1347058075.63.0.395926246222.issue15882@psf.upfronthosting.co.za> Message-ID: <1347088407.52.0.225791361476.issue15882@psf.upfronthosting.co.za> Mark Dickinson added the comment: > It's a bug in decimal.py that it > accepts non-empty coefficients when constructing infinities. On what grounds is it a bug? I might call it a poor design decision, but it's clearly intentional. There's even a unit test for it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 09:36:38 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 08 Sep 2012 07:36:38 +0000 Subject: [issue15882] _decimal.Decimal constructed from tuple In-Reply-To: <1347088407.52.0.225791361476.issue15882@psf.upfronthosting.co.za> Message-ID: <20120908073638.GA26843@sleipnir.bytereef.org> Stefan Krah added the comment: Mark Dickinson wrote: > On what grounds is it a bug? I might call it a poor design decision, > but it's clearly intentional. There's even a unit test for it. Maybe "bug" is not the right word. I'd call it a deviation from the specification then. Do you happen to know what the intention was? If from_tuple(..., 'F') accepts coefficients, logically Decimal("Infinity0"), Decimal("Infinity123") etc. should be accepted as well. But they're not part of the grammar and decimal.py rejects them. http://speleotrove.com/decimal/daconvs.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 09:57:05 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 08 Sep 2012 07:57:05 +0000 Subject: [issue15882] _decimal.Decimal constructed from tuple In-Reply-To: <1347058075.63.0.395926246222.issue15882@psf.upfronthosting.co.za> Message-ID: <1347091025.98.0.766946254476.issue15882@psf.upfronthosting.co.za> Mark Dickinson added the comment: > I'd call it a deviation from the specification then. > Do you happen to know what the intention was? Well, we're kinda outside the specification here. Rightly or wrongly, Decimal('infinity').as_tuple() was originally implemented to return (0, (0,), 'F'); I'm fairly sure that was intentional, and I think that the Decimal constructor should continue to accept that tuple as a representation of infinity---else we're risking breaking existing code. I think I may have muddied the waters at some later stage by modifying the constructor to ignore the second argument on input, so that (0, (), 'F') and (0, (0,), 'F') both work on input. Or maybe it was already the case that the second argument was ignored; I'm not sure about that. I do agree that (0, (), 'F') is a better representation of infinity, and it would have been a little better if that had been used from the start, but I don't think it's worth the potential breakage or the deprecation cycles involved in 'fixing' this. If it helps at all, it would probably be safe to disallow tuples other than () and (0,); I doubt anyone's intentionally passing anything else here. So: +1 on allowing ((0, (0,), 'F')) as input in _decimal. I do see this report as a regression from 3.2 that should be fixed. -0 on changing Infinity.as_tuple() to (0, (), 'F'), and perhaps then deprecating ((0, (0,), 'F') as a legal input. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 10:04:27 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 08 Sep 2012 08:04:27 +0000 Subject: [issue15629] Add to regrtest the ability to run Lib and Doc doctests In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1347091467.44.0.958598013156.issue15629@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attached is a patch that adds to regrtest the ability to run doctests in both library modules and documentation files (specifically, in the non-test modules in Lib/ and in the *.rst files in Doc/). The syntax to run all doctests is-- python -m test --doctests --docdir If --docdir is left out, only module doctests are run. You can run the doctests for individual files and modules by including test names of the form "fdoc:library/builtins.rst" and "mdoc:html.parser" (for file doctests and module doctests, respectively). Doctests for a module are only run if the module has a variable `_doctest_safe` that evaluates to True. I haven't yet added a mechanism to mark a documentation file as "doctest safe" or to skip importing a library module entirely (when running all tests). ---------- components: +Tests keywords: +patch title: Run doctests in Doc/*.rst as part of regrtest -> Add to regrtest the ability to run Lib and Doc doctests Added file: http://bugs.python.org/file27146/issue-15629-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 11:26:34 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 08 Sep 2012 09:26:34 +0000 Subject: [issue15868] leak in bytesio.c In-Reply-To: <1346923934.68.0.507975450675.issue15868@psf.upfronthosting.co.za> Message-ID: <3XDVWr67VQzQ7Z@mail.python.org> Roundup Robot added the comment: New changeset df663603e67a by Stefan Krah in branch '3.2': Issue #15868: Fix refleak in bytesio.c (Coverity #715365). http://hg.python.org/cpython/rev/df663603e67a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 11:27:42 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 08 Sep 2012 09:27:42 +0000 Subject: [issue15868] leak in bytesio.c In-Reply-To: <1346923934.68.0.507975450675.issue15868@psf.upfronthosting.co.za> Message-ID: <1347096462.92.0.173432944993.issue15868@psf.upfronthosting.co.za> Stefan Krah added the comment: Thanks for taking a look! ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 12:14:17 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 08 Sep 2012 10:14:17 +0000 Subject: [issue15882] _decimal.Decimal constructed from tuple In-Reply-To: <1347058075.63.0.395926246222.issue15882@psf.upfronthosting.co.za> Message-ID: <1347099257.31.0.150215662464.issue15882@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 12:29:27 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 08 Sep 2012 10:29:27 +0000 Subject: [issue15340] OSError with "import random" when /dev/urandom doesn't exist (regression from 2.6) In-Reply-To: <1342132229.15.0.69254682318.issue15340@psf.upfronthosting.co.za> Message-ID: <1347100167.28.0.579337514713.issue15340@psf.upfronthosting.co.za> Martin v. L?wis added the comment: It's actually up to Barry (and Benjamin) to decide whether to apply this to 2.6 (and 3.1). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 12:44:24 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 08 Sep 2012 10:44:24 +0000 Subject: [issue15882] _decimal.Decimal constructed from tuple In-Reply-To: <1347058075.63.0.395926246222.issue15882@psf.upfronthosting.co.za> Message-ID: <1347101064.12.0.601326403117.issue15882@psf.upfronthosting.co.za> Stefan Krah added the comment: It's an implementation detail of decimal.py to represent infinity with a coefficient of '0' instead of the empty string: >>> Decimal("inf")._int '0' So IMO the tuple representation exposes that implementation detail. I'm still not sure why that was done or what the benefit was. For cdecimal, initializing a coefficient for infinity is completely meaningless, since infinities simply don't have a coefficient. So the representation DecimalTuple(sign=0, digits=(0,), exponent='F'), which I took over for compatibility, is factually wrong for cdecimal. Of course, exponent='F' is also wrong. I don't mind that as much, because there is a direct mapping to the input strings of the grammar. I think the tuple representation isn't that useful to begin with. In all use cases I've seen, people are a) reading the tuple an b) converting the coefficient tuple back to a Python integer. So, I'd really like to deprecate the whole interface in favor of either a read-only interface: x.sign -> 0 or 1 (perhaps even 1 or -1) x.coeff -> Python integer x.exp -> Python integer If x is special, raise InvalidOperation. People usually need to check for specials anyhow. Or a tuple interface with an integer coefficient (sign=0, coeff=12345, exponent=99), where special numbers are not allowed in accordance with http://speleotrove.com/decimal/damodel.html: "Finite numbers are defined by three integer parameters" "When a number has one of these special values, its coefficient and exponent are undefined." That said, I don't mind if construction continues to work with the implementation specific value of (0,), so let's do that. ---------- assignee: -> skrah type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 12:51:09 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 08 Sep 2012 10:51:09 +0000 Subject: [issue15882] _decimal.Decimal constructed from tuple In-Reply-To: <1347058075.63.0.395926246222.issue15882@psf.upfronthosting.co.za> Message-ID: <1347101469.55.0.975090293256.issue15882@psf.upfronthosting.co.za> Mark Dickinson added the comment: > So, I'd really like to deprecate the whole interface in favor of either a > read-only interface: > > x.sign -> 0 or 1 (perhaps even 1 or -1) > x.coeff -> Python integer > x.exp -> Python integer > > If x is special, raise InvalidOperation. People usually need to check for > specials anyhow. Sure; that works for me. I don't like the current interface any more than you do, and I've always found it unnecessarily awkward to turn finite decimals into triples and back again. But I think that's a different issue. What we have here is a real regression that seems likely to break existing code, and I think that should be fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 12:54:05 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 08 Sep 2012 10:54:05 +0000 Subject: [issue15882] _decimal.Decimal constructed from tuple In-Reply-To: <1347058075.63.0.395926246222.issue15882@psf.upfronthosting.co.za> Message-ID: <1347101645.33.0.184435703603.issue15882@psf.upfronthosting.co.za> Mark Dickinson added the comment: > read-only interface: > > x.sign -> 0 or 1 (perhaps even 1 or -1) > x.coeff -> Python integer > x.exp -> Python integer The only slightly awkward thing with this (for high-precision decimals) is the quadratic conversion (well, okay, perhaps subquadratic depending on what algorithms are being used, but still ...) required to get from the decimal coefficient to a Python integer, and vice versa. It may be better to use a (byte)string of digits instead of a Python integer for the coefficient. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 13:00:37 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 08 Sep 2012 11:00:37 +0000 Subject: [issue15882] _decimal.Decimal constructed from tuple In-Reply-To: <1347101469.55.0.975090293256.issue15882@psf.upfronthosting.co.za> Message-ID: <20120908110037.GA28789@sleipnir.bytereef.org> Stefan Krah added the comment: Mark Dickinson wrote: > > So, I'd really like to deprecate the whole interface in favor of either a > > read-only interface: > > But I think that's a different issue. Yep. I was using all this as a rationale that the current tuple interface does not matter all that much. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 14:36:34 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 08 Sep 2012 12:36:34 +0000 Subject: [issue15822] installed python may fail incorrectly trying to rebuild lib2to3 grammar pickles In-Reply-To: <1346321126.73.0.788135574831.issue15822@psf.upfronthosting.co.za> Message-ID: <1347107794.64.0.81816290765.issue15822@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I think PYTHON_FOR_BUILD includes -E to make sure that if PYTHONPATH (or PYTHONHOME) is set that it then won't affect the build. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 14:51:30 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 08 Sep 2012 12:51:30 +0000 Subject: [issue15871] Online docs: make index search always available. In-Reply-To: <1346951666.84.0.523873961498.issue15871@psf.upfronthosting.co.za> Message-ID: <1347108690.53.0.103884042484.issue15871@psf.upfronthosting.co.za> Ezio Melotti added the comment: If I search for "random", at the top of the result lists I want to see at least the "random" module and the "random.random" function. Currently the "random" module is the 4th result, and "random.random" is buried down in the list (17th place) among all the other random.* functions. The results are generated by the query() function in searchtools.js, and AFAIU it generates 3 lists, importantResults, objectResults, unimportantResults, that get then sorted independently in alphabetic order by the object fullname, and concatenated. I experimented a bit and one way to get exact matches to the top is to add before the switch at line 370 something like if (fullname == object) { importantResults.push(result); continue; } This will include "random", but not "random.random". Other possible variations are if ((fullname == object) || (fullname.split('.').pop() == object)) { or if ((fullname == object) || $.inArray(object, fullname.split('.')) > -1) Here fullname is e.g. "random.random", "$.inArray(object, fullname.split('.')) > -1" is the jquery equivalent of Python's "object in fullname.split('.')". Another way to address the problem is to change the sorting algorithm to move near the top results like "random" and "random.random". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 15:14:37 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 08 Sep 2012 13:14:37 +0000 Subject: [issue15882] _decimal.Decimal constructed from tuple In-Reply-To: <1347058075.63.0.395926246222.issue15882@psf.upfronthosting.co.za> Message-ID: <1347110077.66.0.204973314413.issue15882@psf.upfronthosting.co.za> Stefan Krah added the comment: Aaron, did you encounter this problem in a real world application? I'm asking because it would be interesting to know if people use this. Google is pretty silent on "Decimal((0, (0,), 'F'))", but perhaps that is not an ideal search term. Mark, I'm uploading a minimal patch. I'm OK with that going into 3.3.0, if you manage to convince Georg. :) ---------- Added file: http://bugs.python.org/file27147/issue15882.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 15:35:03 2012 From: report at bugs.python.org (Christian Heimes) Date: Sat, 08 Sep 2012 13:35:03 +0000 Subject: [issue15883] Add Py_errno to work around multiple CRT issue Message-ID: <1347111302.92.0.306708953598.issue15883@psf.upfronthosting.co.za> New submission from Christian Heimes: errno is usually implemented as thread local variable, more precisely as a macro that calls a function which returns the memory address of a thread local variable. Each C runtime library has its own function and TLS which introduces an issue when a Python extension uses a different CRT than the core. AFAIK that an issue only an issue on Windows with other versions of Visual Studio. This means that mixed CRTs break the three PyErr_SetFromErrno* functions as they always access the errno of the core's CRT. The patch adds a Py_errno macro that must be used in extensions before a PyErr_SetFromErrno() function is used. Example: fd = open(filename, O_RDONLY); if (fd == -1) { Py_errno = errno; return PyErr_SetFromErrnoWithFilename(PyExc_OSError, filename); } The issue was discovered by me a about two weeks ago and further analyzed by Martin. http://mail.python.org/pipermail/python-dev/2012-August/121460.html ---------- components: Build, Extension Modules, Interpreter Core files: pyerrno.patch keywords: patch messages: 170050 nosy: christian.heimes, georg.brandl, loewis, pitrou priority: normal severity: normal stage: patch review status: open title: Add Py_errno to work around multiple CRT issue type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file27148/pyerrno.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 15:41:25 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 08 Sep 2012 13:41:25 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346260029.19.0.320505643782.issue15814@psf.upfronthosting.co.za> Message-ID: <3XDc9w2J4FzQGV@mail.python.org> Roundup Robot added the comment: New changeset ca81b9a3a015 by Stefan Krah in branch 'default': Issue #15814: Update whatsnew to the current state of hashing memoryviews. http://hg.python.org/cpython/rev/ca81b9a3a015 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 15:51:44 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 08 Sep 2012 13:51:44 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346260029.19.0.320505643782.issue15814@psf.upfronthosting.co.za> Message-ID: <1347112304.06.0.132304088302.issue15814@psf.upfronthosting.co.za> Stefan Krah added the comment: Georg, thanks for including all changes that I've asked for! If you still have the patience for the constant stream of memoryview doc changes, there are three new ones that might be worth including: 3b2597c1fe35 c9c9d890400c ca81b9a3a015 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 16:05:59 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 08 Sep 2012 14:05:59 +0000 Subject: [issue15883] Add Py_errno to work around multiple CRT issue In-Reply-To: <1347111302.92.0.306708953598.issue15883@psf.upfronthosting.co.za> Message-ID: <1347113159.95.0.421855635337.issue15883@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Since this is a new feature, it needs to go into 3.4. ---------- versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 16:59:27 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Sat, 08 Sep 2012 14:59:27 +0000 Subject: [issue15871] Online docs: make index search always available. In-Reply-To: <1346951666.84.0.523873961498.issue15871@psf.upfronthosting.co.za> Message-ID: <1347116367.76.0.0248804739654.issue15871@psf.upfronthosting.co.za> Changes by Ramchandra Apte : ---------- nosy: +ramchandra.apte _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 17:04:12 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 08 Sep 2012 15:04:12 +0000 Subject: [issue15844] weird import errors In-Reply-To: <1346547205.78.0.590339633235.issue15844@psf.upfronthosting.co.za> Message-ID: <1347116652.58.0.290123176871.issue15844@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 17:06:11 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 08 Sep 2012 15:06:11 +0000 Subject: [issue15845] Fixing some byte-to-string conversion warnings In-Reply-To: <1346552396.88.0.397419581961.issue15845@psf.upfronthosting.co.za> Message-ID: <1347116771.68.0.249082663592.issue15845@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 17:07:18 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 08 Sep 2012 15:07:18 +0000 Subject: [issue15852] typos in curses argument error messages In-Reply-To: <1346622102.83.0.795568790125.issue15852@psf.upfronthosting.co.za> Message-ID: <1347116838.97.0.158362054381.issue15852@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 17:08:04 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 08 Sep 2012 15:08:04 +0000 Subject: [issue15851] Lib/robotparser.py doesn't accept setting a user agent string, instead it uses the default. In-Reply-To: <1346610964.7.0.836759738208.issue15851@psf.upfronthosting.co.za> Message-ID: <1347116884.42.0.692827994111.issue15851@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 17:24:32 2012 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Sat, 08 Sep 2012 15:24:32 +0000 Subject: [issue15875] tarfile may not make @LongLink for non-ascii character In-Reply-To: <1346981062.61.0.534239636824.issue15875@psf.upfronthosting.co.za> Message-ID: <1347117872.43.0.913341253767.issue15875@psf.upfronthosting.co.za> Changes by Lars Gust?bel : ---------- assignee: -> lars.gustaebel nosy: +lars.gustaebel versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 18:27:04 2012 From: report at bugs.python.org (Brett Cannon) Date: Sat, 08 Sep 2012 16:27:04 +0000 Subject: [issue10224] Build 3.x documentation using python3.x In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za> Message-ID: <1347121624.45.0.338383162505.issue10224@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 18:35:06 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 08 Sep 2012 16:35:06 +0000 Subject: [issue13922] argparse handling multiple "--" in args improperly In-Reply-To: <1328132556.72.0.92385645061.issue13922@psf.upfronthosting.co.za> Message-ID: <3XDh2J74SQzQDJ@mail.python.org> Roundup Robot added the comment: New changeset 5d8454fcc629 by R David Murray in branch '3.2': #15847: allow args to be a tuple in parse_args http://hg.python.org/cpython/rev/5d8454fcc629 New changeset 76655483c5c8 by R David Murray in branch 'default': merge #15847: allow args to be a tuple in parse_args http://hg.python.org/cpython/rev/76655483c5c8 New changeset a2147bbf7868 by R David Murray in branch '2.7': #15847: allow args to be a tuple in parse_args http://hg.python.org/cpython/rev/a2147bbf7868 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 18:35:07 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 08 Sep 2012 16:35:07 +0000 Subject: [issue15847] parse_args stopped accepting tuples In-Reply-To: <1346591535.01.0.313863035332.issue15847@psf.upfronthosting.co.za> Message-ID: <3XDh2K5fLwzQDJ@mail.python.org> Roundup Robot added the comment: New changeset 5d8454fcc629 by R David Murray in branch '3.2': #15847: allow args to be a tuple in parse_args http://hg.python.org/cpython/rev/5d8454fcc629 New changeset 76655483c5c8 by R David Murray in branch 'default': merge #15847: allow args to be a tuple in parse_args http://hg.python.org/cpython/rev/76655483c5c8 New changeset a2147bbf7868 by R David Murray in branch '2.7': #15847: allow args to be a tuple in parse_args http://hg.python.org/cpython/rev/a2147bbf7868 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 18:36:44 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 08 Sep 2012 16:36:44 +0000 Subject: [issue15847] parse_args stopped accepting tuples In-Reply-To: <1346591535.01.0.313863035332.issue15847@psf.upfronthosting.co.za> Message-ID: <1347122204.76.0.155428563617.issue15847@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Zbyszek. I'm glad you caught this. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 19:16:03 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 08 Sep 2012 17:16:03 +0000 Subject: [issue15842] Some SocketIO methods can succeed after close() In-Reply-To: <1346527213.21.0.243179396441.issue15842@psf.upfronthosting.co.za> Message-ID: <1347124563.51.0.308538236405.issue15842@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Actually, I've found a couple of issues with the patch: - it doesn't address seekable(); seekable() should also raise ValueError - the test should be done with makefile(..., buffering=0), so that SocketIO is actually tested, rather than the buffered object wrapping it ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 19:42:42 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 08 Sep 2012 17:42:42 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za> Message-ID: <3XDjXJ68t3zPsv@mail.python.org> Roundup Robot added the comment: New changeset 65e5f28801e1 by R David Murray in branch '3.2': #15510: clarify textwrap's handling of whitespace, and add confirming tests. http://hg.python.org/cpython/rev/65e5f28801e1 New changeset 0e9ad455355b by R David Murray in branch 'default': Merge #15510: clarify textwrap's handling of whitespace, and add confirming tests. http://hg.python.org/cpython/rev/0e9ad455355b New changeset fca48971ac35 by R David Murray in branch '2.7': #15510: clarify textwrap's handling of whitespace, and add confirming tests. http://hg.python.org/cpython/rev/fca48971ac35 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 19:43:19 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 08 Sep 2012 17:43:19 +0000 Subject: [issue15510] textwrap.wrap('') returns empty list In-Reply-To: <1343697979.41.0.629576632811.issue15510@psf.upfronthosting.co.za> Message-ID: <1347126199.56.0.219979431331.issue15510@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Chris. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 19:53:10 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 08 Sep 2012 17:53:10 +0000 Subject: [issue15865] reflect bare star * in function signature documentation In-Reply-To: <1346805751.63.0.697181229134.issue15865@psf.upfronthosting.co.za> Message-ID: <3XDjmP4q5jzQMT@mail.python.org> Roundup Robot added the comment: New changeset a30b3915228b by Ezio Melotti in branch '3.2': #15865: add "*" in the signature to document keyword-only args in the docs. Patch by Chris Jerdonek. http://hg.python.org/cpython/rev/a30b3915228b New changeset 694c725f241a by Ezio Melotti in branch 'default': #15865: merge with 3.2. http://hg.python.org/cpython/rev/694c725f241a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 19:54:54 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 08 Sep 2012 17:54:54 +0000 Subject: [issue15865] reflect bare star * in function signature documentation In-Reply-To: <1346805751.63.0.697181229134.issue15865@psf.upfronthosting.co.za> Message-ID: <1347126894.23.0.220753982611.issue15865@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! ---------- assignee: docs at python -> ezio.melotti resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 19:59:36 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 08 Sep 2012 17:59:36 +0000 Subject: [issue15884] PEP 3121, 384 Refactoring applied to ctypes module Message-ID: <1347127176.13.0.489231744375.issue15884@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- assignee: belopolsky nosy: belopolsky priority: normal severity: normal status: open title: PEP 3121, 384 Refactoring applied to ctypes module type: resource usage versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 20:01:10 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 08 Sep 2012 18:01:10 +0000 Subject: [issue15787] PEP 3121 Refactoring In-Reply-To: <1346038565.61.0.980658052428.issue15787@psf.upfronthosting.co.za> Message-ID: <1347127270.57.0.798946612686.issue15787@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- dependencies: +PEP 3121, 384 Refactoring applied to ctypes module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 21:26:47 2012 From: report at bugs.python.org (Aaron) Date: Sat, 08 Sep 2012 19:26:47 +0000 Subject: [issue15882] _decimal.Decimal constructed from tuple In-Reply-To: <1347058075.63.0.395926246222.issue15882@psf.upfronthosting.co.za> Message-ID: <1347132407.81.0.728702066463.issue15882@psf.upfronthosting.co.za> Aaron added the comment: I did not encounter this in a regular application. I do use the decimal module, and was excited to see the adoption of a faster C version, so I was just reading through the code to see how it worked. I can't think of a situation where I would need to construct a decimal from a tuple and not a string or some other numeric type, though. For what it's worth, I think that as long as construction from tuples is supported, Decimal(d.as_tuple()) should work for all Decimal objects d. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 22:04:35 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 08 Sep 2012 20:04:35 +0000 Subject: [issue15222] mailbox.mbox writes without empty line after each message In-Reply-To: <1340948825.65.0.977158180544.issue15222@psf.upfronthosting.co.za> Message-ID: <1347134675.26.0.446669441821.issue15222@psf.upfronthosting.co.za> R. David Murray added the comment: Looks like reitveld doesn't recognize your patch format, Petri. Instead of having the write_line flag, how about doing the newline write in the if body? A 'lastline=line' at the end of the loop in the buffer loop case is probably less expensive than doing the if test every time through that loop. Otherwise, it looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 22:48:37 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 08 Sep 2012 20:48:37 +0000 Subject: [issue5088] optparse: inconsistent default value for append actions In-Reply-To: <1233140307.53.0.685208172708.issue5088@psf.upfronthosting.co.za> Message-ID: <3XDnfq6RgDzQLL@mail.python.org> Roundup Robot added the comment: New changeset 8c60bb098eff by R David Murray in branch '3.2': #5088: document behavior of optparse defaults with 'append' action. http://hg.python.org/cpython/rev/8c60bb098eff New changeset 0c2bdd2c2032 by R David Murray in branch 'default': Merge #5088: document behavior of optparse defaults with 'append' action. http://hg.python.org/cpython/rev/0c2bdd2c2032 New changeset 79f6d4aff39d by R David Murray in branch '2.7': closes #5088: document behavior of optparse defaults with 'append' action. http://hg.python.org/cpython/rev/79f6d4aff39d ---------- nosy: +python-dev resolution: accepted -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 22:57:42 2012 From: report at bugs.python.org (Kyle Roberts) Date: Sat, 08 Sep 2012 20:57:42 +0000 Subject: [issue15744] missing tests for {RawIO,BufferedIO,TextIO}.writelines In-Reply-To: <1345500357.29.0.226025015503.issue15744@psf.upfronthosting.co.za> Message-ID: <1347137862.59.0.0660706528628.issue15744@psf.upfronthosting.co.za> Changes by Kyle Roberts : ---------- nosy: +kyle.roberts _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 23:51:43 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 08 Sep 2012 21:51:43 +0000 Subject: [issue15820] Add additional info to Resources area on Dev Guide In-Reply-To: <1346312741.02.0.319894267547.issue15820@psf.upfronthosting.co.za> Message-ID: <3XDq3f32CFzQVv@mail.python.org> Roundup Robot added the comment: New changeset 18e31605b161 by R David Murray in branch 'default': #15820: Improve the Helping with the Devguide section http://hg.python.org/devguide/rev/18e31605b161 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 8 23:54:14 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 08 Sep 2012 21:54:14 +0000 Subject: [issue15820] Add additional info to Resources area on Dev Guide In-Reply-To: <1346312741.02.0.319894267547.issue15820@psf.upfronthosting.co.za> Message-ID: <1347141254.02.0.155057515966.issue15820@psf.upfronthosting.co.za> R. David Murray added the comment: I incorporated your ideas into the update I made, including at least one that Ezio may have rejected...he can blame me :) Thanks, Mike. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 00:37:55 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Sat, 08 Sep 2012 22:37:55 +0000 Subject: [issue15871] Online docs: make index search always available. In-Reply-To: <1346951666.84.0.523873961498.issue15871@psf.upfronthosting.co.za> Message-ID: <1347143875.42.0.442611553829.issue15871@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 01:43:33 2012 From: report at bugs.python.org (Kevin Chen) Date: Sat, 08 Sep 2012 23:43:33 +0000 Subject: [issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite In-Reply-To: <1242857063.47.0.919073638283.issue6074@psf.upfronthosting.co.za> Message-ID: <1347147813.58.0.394174136425.issue6074@psf.upfronthosting.co.za> Kevin Chen added the comment: Hi Eric, I am happy to install Python 3.3 on Windows and help you test this. Can you please give me some ideas on what I need to do? Do I sync to the latest Python 3.3 branch and compile? Then run some unit-test code? Which test files should I run? What should I be expecting? Also, do you know if anyone is working on adding the fix and test to Python 2.7? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 01:51:06 2012 From: report at bugs.python.org (Alessandro Moura) Date: Sat, 08 Sep 2012 23:51:06 +0000 Subject: [issue15842] Some SocketIO methods can succeed after close() In-Reply-To: <1346527213.21.0.243179396441.issue15842@psf.upfronthosting.co.za> Message-ID: <1347148266.89.0.749640329645.issue15842@psf.upfronthosting.co.za> Alessandro Moura added the comment: Fixed seekable(), and amended tests; see patch. ---------- Added file: http://bugs.python.org/file27149/socket.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 01:55:22 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 08 Sep 2012 23:55:22 +0000 Subject: [issue15844] weird import errors In-Reply-To: <1346547205.78.0.590339633235.issue15844@psf.upfronthosting.co.za> Message-ID: <1347148522.4.0.910291669551.issue15844@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 02:05:28 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 09 Sep 2012 00:05:28 +0000 Subject: [issue15848] PEP 3121, 384 Refactoring applied to xxsubtype module In-Reply-To: <1346596167.75.0.401355088857.issue15848@psf.upfronthosting.co.za> Message-ID: <1347149128.4.0.0823755293087.issue15848@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: It looks like your patch will result in reference leaks if type creation fails. I think you should add Py_DECREF(m) before error returns. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 02:15:38 2012 From: report at bugs.python.org (Albert Zeyer) Date: Sun, 09 Sep 2012 00:15:38 +0000 Subject: [issue15885] @staticmethod __getattr__ doesn't work Message-ID: <1347149709.6.0.110064908732.issue15885@psf.upfronthosting.co.za> New submission from Albert Zeyer: Code: ``` class Wrapper: @staticmethod def __getattr__(item): return repr(item) # dummy a = Wrapper() print(a.foo) ``` Expected output: 'foo' Actual output with Python 2.7: Traceback (most recent call last): File "test_staticmethodattr.py", line 7, in print(a.foo) TypeError: 'staticmethod' object is not callable Python 3.2 does return the expected ('foo'). PyPy returns the expected 'foo'. ---------- components: Interpreter Core messages: 170070 nosy: Albert.Zeyer priority: normal severity: normal status: open title: @staticmethod __getattr__ doesn't work versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 04:08:55 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 09 Sep 2012 02:08:55 +0000 Subject: [issue15822] installed python may fail incorrectly trying to rebuild lib2to3 grammar pickles In-Reply-To: <1346321126.73.0.788135574831.issue15822@psf.upfronthosting.co.za> Message-ID: <3XDwmP1r4wzQLZ@mail.python.org> Roundup Robot added the comment: New changeset 2def9ef683da by Ned Deily in branch '2.7': Issue #15822: Fix installation of lib2to3 grammar pickles to ensure http://hg.python.org/cpython/rev/2def9ef683da New changeset adc5e6aca251 by Ned Deily in branch '3.2': Issue #15822: Fix installation of lib2to3 grammar pickles to ensure http://hg.python.org/cpython/rev/adc5e6aca251 New changeset a829889f96b0 by Ned Deily in branch 'default': Issue #15822: Fix installation of lib2to3 grammar pickles to ensure http://hg.python.org/cpython/rev/a829889f96b0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 04:32:18 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 09 Sep 2012 02:32:18 +0000 Subject: [issue15822] installed python may fail incorrectly trying to rebuild lib2to3 grammar pickles In-Reply-To: <1346321126.73.0.788135574831.issue15822@psf.upfronthosting.co.za> Message-ID: <1347157938.56.0.0896531659038.issue15822@psf.upfronthosting.co.za> Ned Deily added the comment: I like Martin's suggested approach. It is explicit and much cleaner than the changes we introduced for Issue15645 as well as the original. The applied changes revert the previous changes and instead implement an explicit build of the two pickles directly in the installed lib2to3 during "make install" regardless of the presence of pickles in the build directory. This also resolves Issue15838. Georg, I think a829889f96b0 should be considered for inclusion in 3.3.0. Ronald, if you want to pursue the $PYTHON_FOR_BUILD -E issue, it would be best to use another specific issue for that. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 04:32:51 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 09 Sep 2012 02:32:51 +0000 Subject: [issue15822] installed python may fail incorrectly trying to rebuild lib2to3 grammar pickles In-Reply-To: <1346321126.73.0.788135574831.issue15822@psf.upfronthosting.co.za> Message-ID: <1347157971.1.0.802794073463.issue15822@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- status: pending -> open Removed file: http://bugs.python.org/file27084/issue15822_33.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 04:38:26 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 09 Sep 2012 02:38:26 +0000 Subject: [issue15838] make install tries to create lib2to3 grammar pickles in source directory In-Reply-To: <1346498804.77.0.811767404939.issue15838@psf.upfronthosting.co.za> Message-ID: <1347158306.06.0.319853098335.issue15838@psf.upfronthosting.co.za> Ned Deily added the comment: This problem is resolved by the fixes for Issue15822 which implements a more explicit way of installing the grammar pickles. ---------- resolution: -> duplicate stage: needs patch -> committed/rejected status: open -> closed superseder: -> installed python may fail incorrectly trying to rebuild lib2to3 grammar pickles _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 04:48:16 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 09 Sep 2012 02:48:16 +0000 Subject: [issue15645] 2to3 Grammar pickles not created when upgrading to 3.3.0b2 In-Reply-To: <1344932180.41.0.826216341416.issue15645@psf.upfronthosting.co.za> Message-ID: <1347158896.82.0.039598874805.issue15645@psf.upfronthosting.co.za> Ned Deily added the comment: >Is it really possible that the pickle is created after calculation of the wildcard expansion? With the current GNUmake, it seems it is not possible. GNUmake appears to serializes the individual steps in a target's recipe although I did not find an explicit guarantee in its documentation that that could never happen. (I did find at least one proprietary "make" replacement that does try to parallelize the individual steps in one target.) In any case, there were other problems with the approach implemented here and these changes have been superseded by those of Issue15822. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 04:52:32 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 09 Sep 2012 02:52:32 +0000 Subject: [issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite In-Reply-To: <1242857063.47.0.919073638283.issue6074@psf.upfronthosting.co.za> Message-ID: <1347159152.02.0.978428861719.issue6074@psf.upfronthosting.co.za> Nick Coghlan added the comment: It's still on my list to follow up (along with the other contributions from the PyCon AU sprints). However, if Eric gets a Windows environment up and running before I get to it, I'm happy to hand the issue over (I rely on the buildbots to sanity check Windows fixes). ---------- versions: -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 05:04:18 2012 From: report at bugs.python.org (Eric Snow) Date: Sun, 09 Sep 2012 03:04:18 +0000 Subject: [issue15885] @staticmethod __getattr__ doesn't work In-Reply-To: <1347149709.6.0.110064908732.issue15885@psf.upfronthosting.co.za> Message-ID: <1347159858.1.0.205137504837.issue15885@psf.upfronthosting.co.za> Eric Snow added the comment: In Python 2 the code example generates an old-style class. When I tried it with a new style class, it worked fine: class Wrapper(object): @staticmethod def __getattr__(item): return repr(item) # dummy a = Wrapper() print(a.foo) # 'foo' Chalk this up to another reason to move to Python 3. ---------- nosy: +eric.snow resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 06:40:18 2012 From: report at bugs.python.org (Chris Rebert) Date: Sun, 09 Sep 2012 04:40:18 +0000 Subject: [issue15873] "datetime" cannot parse ISO 8601 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1347165618.06.0.878628365177.issue15873@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 07:03:04 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 09 Sep 2012 05:03:04 +0000 Subject: [issue14649] doctest.DocTestSuite error misleading when module has no docstrings In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za> Message-ID: <1347166984.45.0.339910867449.issue14649@psf.upfronthosting.co.za> R. David Murray added the comment: OK, 3.2 passes now, but when I merge to 3.3 I get failures. test_zipimport_support doesn't work on 2.7 either, but there we could just not backport the tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 07:22:03 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 09 Sep 2012 05:22:03 +0000 Subject: [issue14649] doctest.DocTestSuite error misleading when module has no docstrings In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za> Message-ID: <1347168123.63.0.0220511764659.issue14649@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I prepared the patch against 3.3 (default), so I wouldn't have expected it to work against 3.2 without further changes. The behavior in 3.3 after merging is also surprising given that it worked in 3.2 (and for me with direct application). I will look into it and report back -- providing 3.2 and a "delta" patch, if necessary. I just wanted to be sure you were okay with the patch for the default branch before doing that extra work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 08:12:33 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 09 Sep 2012 06:12:33 +0000 Subject: [issue14649] doctest.DocTestSuite error misleading when module has no docstrings In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za> Message-ID: <1347171153.31.0.824014548541.issue14649@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I tried applying the latest patch (patch #6) to 3.2, merging to default, and then running all tests in default, and the tests seem to all pass for me (in both default and 3.2). Also, the "diff" for the change in default after that process seems to be identical to the uploaded patch. Is it possible that you applied the wrong patch at some point in the process? What test failure were you getting? Can you try applying the patch as is to the default branch (i.e. without going through 3.2) and see if you still get test failures? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 08:57:07 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 09 Sep 2012 06:57:07 +0000 Subject: [issue15822] installed python may fail incorrectly trying to rebuild lib2to3 grammar pickles In-Reply-To: <1346321126.73.0.788135574831.issue15822@psf.upfronthosting.co.za> Message-ID: <1347173827.26.0.194400415807.issue15822@psf.upfronthosting.co.za> Georg Brandl added the comment: Picked to release clone as 411d500e56a1. ---------- priority: release blocker -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 08:59:54 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 09 Sep 2012 06:59:54 +0000 Subject: [issue15822] installed python may fail incorrectly trying to rebuild lib2to3 grammar pickles In-Reply-To: <1346321126.73.0.788135574831.issue15822@psf.upfronthosting.co.za> Message-ID: <1347173994.9.0.63958879395.issue15822@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 09:17:30 2012 From: report at bugs.python.org (Masato HASHIMOTO) Date: Sun, 09 Sep 2012 07:17:30 +0000 Subject: [issue15886] Doc: same word iteration Message-ID: <1347175050.22.0.936746811947.issue15886@psf.upfronthosting.co.za> New submission from Masato HASHIMOTO: Same word () is iterated in Doc/library/os.rst. 1858 This function can support :ref:`specifying a file descriptor 1859 `, :ref:`specifying a file descriptor ` and :ref:`not 1860 following symlinks `. version: releasing/3.3.0 @ 78787:c5bc19ce4d2b ---------- assignee: docs at python components: Documentation messages: 170081 nosy: docs at python, hashimo priority: normal severity: normal status: open title: Doc: same word iteration versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 11:18:51 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 09 Sep 2012 09:18:51 +0000 Subject: [issue13992] Segfault in PyTrash_destroy_chain In-Reply-To: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za> Message-ID: <3XF6JT6stMzQQ4@mail.python.org> Roundup Robot added the comment: New changeset 5aa1bc2f00ad by Antoine Pitrou in branch 'default': Issue #13992: The trashcan mechanism is now thread-safe. This eliminates http://hg.python.org/cpython/rev/5aa1bc2f00ad ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 11:18:51 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 09 Sep 2012 09:18:51 +0000 Subject: [issue14223] curses addch broken on Python3.3a1 In-Reply-To: <1331153094.15.0.871612927682.issue14223@psf.upfronthosting.co.za> Message-ID: <3XF6JV5QG2zQQ4@mail.python.org> Roundup Robot added the comment: New changeset d6d632f254ee by Victor Stinner in branch 'default': Close #14223: Fix window.addch(curses.ACS_HLINE) http://hg.python.org/cpython/rev/d6d632f254ee ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 11:18:52 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 09 Sep 2012 09:18:52 +0000 Subject: [issue15724] Add "versionchanged" to memoryview docs In-Reply-To: <1345377223.09.0.176185074566.issue15724@psf.upfronthosting.co.za> Message-ID: <3XF6JW3tPZzQQ4@mail.python.org> Roundup Robot added the comment: New changeset 144d649764cf by Stefan Krah in branch 'default': Issue #15724: Add versionchanged tags to the memoryview documentation. http://hg.python.org/cpython/rev/144d649764cf ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 11:18:53 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 09 Sep 2012 09:18:53 +0000 Subject: [issue10650] decimal.py: quantize(): excess digits with watchexp=0 In-Reply-To: <1291816575.32.0.784106881295.issue10650@psf.upfronthosting.co.za> Message-ID: <3XF6JX2btyzQXX@mail.python.org> Roundup Robot added the comment: New changeset e4ca4edee8bd by Stefan Krah in branch 'default': Closes #10650: Deprecate the watchexp parameter of Decimal.quantize(). http://hg.python.org/cpython/rev/e4ca4edee8bd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 11:18:54 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 09 Sep 2012 09:18:54 +0000 Subject: [issue15340] OSError with "import random" when /dev/urandom doesn't exist (regression from 2.6) In-Reply-To: <1342132229.15.0.69254682318.issue15340@psf.upfronthosting.co.za> Message-ID: <3XF6JY12TwzQXj@mail.python.org> Roundup Robot added the comment: New changeset 6a782496f90a by Antoine Pitrou in branch 'default': Issue #15340: Fix importing the random module when /dev/urandom cannot be opened. http://hg.python.org/cpython/rev/6a782496f90a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 11:18:55 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 09 Sep 2012 09:18:55 +0000 Subject: [issue15781] test_threaded_import fails with -j4 In-Reply-To: <1345883620.41.0.296577026972.issue15781@psf.upfronthosting.co.za> Message-ID: <3XF6JY6cNtzQXB@mail.python.org> Roundup Robot added the comment: New changeset 85070f284fd2 by Antoine Pitrou in branch 'default': Issue #15781: Fix two small race conditions in import's module locking. http://hg.python.org/cpython/rev/85070f284fd2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 11:18:55 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 09 Sep 2012 09:18:55 +0000 Subject: [issue15822] installed python may fail incorrectly trying to rebuild lib2to3 grammar pickles In-Reply-To: <1346321126.73.0.788135574831.issue15822@psf.upfronthosting.co.za> Message-ID: <3XF6JZ59BYzQYZ@mail.python.org> Roundup Robot added the comment: New changeset 411d500e56a1 by Ned Deily in branch 'default': Issue #15822: Fix installation of lib2to3 grammar pickles to ensure http://hg.python.org/cpython/rev/411d500e56a1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 11:18:56 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 09 Sep 2012 09:18:56 +0000 Subject: [issue15784] OSError.__str__() should distinguish between errno and winerror In-Reply-To: <1345920277.5.0.279969365859.issue15784@psf.upfronthosting.co.za> Message-ID: <3XF6Jb3jjZzQY8@mail.python.org> Roundup Robot added the comment: New changeset 4e941113e4fa by Richard Oudkerk in branch 'default': Issue #15784: Modify OSError.__str__() to better distinguish between http://hg.python.org/cpython/rev/4e941113e4fa ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 11:18:57 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 09 Sep 2012 09:18:57 +0000 Subject: [issue15785] curses.get_wch() returns keypad codes incorrectly In-Reply-To: <1345975778.97.0.705241878581.issue15785@psf.upfronthosting.co.za> Message-ID: <3XF6Jc2N9zzQXl@mail.python.org> Roundup Robot added the comment: New changeset 23377e88487b by Victor Stinner in branch 'default': Issue #15785: Modify window.get_wch() API of the curses module: return a http://hg.python.org/cpython/rev/23377e88487b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 11:18:58 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 09 Sep 2012 09:18:58 +0000 Subject: [issue15828] imp.load_module doesn't support C_EXTENSION type In-Reply-To: <1346398348.83.0.242228991466.issue15828@psf.upfronthosting.co.za> Message-ID: <3XF6Jd0vJWzQXX@mail.python.org> Roundup Robot added the comment: New changeset 4f6f59303146 by Nick Coghlan in branch 'default': Issue #15828: Restore support for C extension modules in imp.load_module() http://hg.python.org/cpython/rev/4f6f59303146 New changeset a4a9c5717204 by Brett Cannon in branch 'default': Issue #15828: Don't try to close a file if imp.find_module() doesn't http://hg.python.org/cpython/rev/a4a9c5717204 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 11:18:59 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 09 Sep 2012 09:18:59 +0000 Subject: [issue15814] memoryview: equality-hash invariant In-Reply-To: <1346260029.19.0.320505643782.issue15814@psf.upfronthosting.co.za> Message-ID: <3XF6Jd6YYkzQQF@mail.python.org> Roundup Robot added the comment: New changeset 7734eb2707a1 by Stefan Krah in branch 'default': Issue #15814: Document planned restrictions for memoryview hashes in 3.3.1. http://hg.python.org/cpython/rev/7734eb2707a1 New changeset 71f4d80400f2 by Stefan Krah in branch 'default': Issue #15814: Documentation: disallow hashing of multi-dimensional memoryviews. http://hg.python.org/cpython/rev/71f4d80400f2 New changeset 3ffd6ad93fe4 by Nick Coghlan in branch 'default': Issue #15814: Add NEWS entry regarding intended memoryview hashing restrictions http://hg.python.org/cpython/rev/3ffd6ad93fe4 New changeset 88a0792e8ba3 by Stefan Krah in branch 'default': Issue #15814: Update whatsnew to the current state of hashing memoryviews. http://hg.python.org/cpython/rev/88a0792e8ba3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 12:09:54 2012 From: report at bugs.python.org (Albert Zeyer) Date: Sun, 09 Sep 2012 10:09:54 +0000 Subject: [issue15885] @staticmethod __getattr__ doesn't work In-Reply-To: <1347149709.6.0.110064908732.issue15885@psf.upfronthosting.co.za> Message-ID: <1347185394.77.0.697083850737.issue15885@psf.upfronthosting.co.za> Albert Zeyer added the comment: I don't quite understand. Shouldn't __getattr__ also work in old-style classes? And the error itself ('staticmethod' object is not callable), shouldn't that be impossible? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 12:18:57 2012 From: report at bugs.python.org (Simonas Kazlauskas) Date: Sun, 09 Sep 2012 10:18:57 +0000 Subject: [issue15887] urlencode should accept generators or two elements tuples Message-ID: <1347185937.29.0.747427121658.issue15887@psf.upfronthosting.co.za> New submission from Simonas Kazlauskas: ``urllib.parse.urlencode([('i', i) for i in range(1000)])`` works, but ``urlencode(('i', i) for i in range(1000))`` raises a ``TypeError: not a valid non-string sequence or mapping object``. Allowing urlencode to accept generators would make life a bit easier. ---------- components: Library (Lib) messages: 170094 nosy: nagisa priority: normal severity: normal status: open title: urlencode should accept generators or two elements tuples type: enhancement versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 12:41:16 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 09 Sep 2012 10:41:16 +0000 Subject: [issue15886] os.stat() docs repeat "specifying a file descriptor" support In-Reply-To: <1347175050.22.0.936746811947.issue15886@psf.upfronthosting.co.za> Message-ID: <1347187276.15.0.545711982235.issue15886@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Here is where the typo was introduced: http://hg.python.org/cpython/rev/c890cbad4748#l1.69 ---------- nosy: +cjerdonek title: Doc: same word iteration -> os.stat() docs repeat "specifying a file descriptor" support _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 12:50:35 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Sun, 09 Sep 2012 10:50:35 +0000 Subject: [issue15122] Always rewrite single-file mailboxes in-place In-Reply-To: <1340275550.98.0.309231550082.issue15122@psf.upfronthosting.co.za> Message-ID: <1347187835.32.0.706272048154.issue15122@psf.upfronthosting.co.za> Petri Lehtinen added the comment: Attaching a patch that changes all single-file mailboxes to be rewritten in-place instead of rewriting and renaming. The patch doesn't add an option, because IMO this should be the default behavior. In addition to solving the locking problems, this makes it significantly faster and less disk space consuming to remove or replace messages in very large mailbox files, because the whole mailbox is not rewritten. With this patch, the code now writes messages to a temporary file, starting from the first changed message to the end of the mailbox file. After this, the contents of the temporary file are copied back to the mailbox file and the mailbox file is truncated to the correct length. Care is taken that the process can be restarted if a crash (e.g. KeyboardInterrupt) occurs before starting to copy the changes back to the mailbox file, by altering self._toc and self._pending at the right moment. I'm not sure whether this would be a bug fix or a new feature. Suggestions? ---------- keywords: +needs review, patch stage: -> patch review title: Add an option to always rewrite single-file mailboxes in-place. -> Always rewrite single-file mailboxes in-place _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 12:51:24 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Sun, 09 Sep 2012 10:51:24 +0000 Subject: [issue15122] Always rewrite single-file mailboxes in-place In-Reply-To: <1340275550.98.0.309231550082.issue15122@psf.upfronthosting.co.za> Message-ID: <1347187884.01.0.762271668048.issue15122@psf.upfronthosting.co.za> Changes by Petri Lehtinen : Added file: http://bugs.python.org/file27150/issue15122.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 13:32:30 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 09 Sep 2012 11:32:30 +0000 Subject: [issue15888] ipaddress HOWTO examples have some errors Message-ID: <1347190349.96.0.156720503481.issue15888@psf.upfronthosting.co.za> New submission from Chris Jerdonek: The ipaddress HOWTO seems to have some errors in its interactive doctest examples. Below are the errors after running the doctests for it using the regrtest patch posted to issue 15629. (This is the first doc file for which I have used the modified script to open an issue.) The errors seem valid to me on casual inspection. Note that you need to add an initial ">>> import ipaddress" at the beginning of the first doctest example to have these actually run. ---------------------------------------------------------------------- File "Doc/howto/ipaddress.rst", line 146, in ipaddress.rst Failed example: ipaddress.ip_network('2001:db8::1/96') Exception raised: Traceback (most recent call last): File "Lib/doctest.py", line 1287, in __run compileflags, 1), test.globs) File "", line 1, in ipaddress.ip_network('2001:db8::1/96') File "Lib/ipaddress.py", line 79, in ip_network return IPv6Network(address, strict) File "Lib/ipaddress.py", line 2056, in __init__ raise ValueError('%s has host bits set' % self) ValueError: 2001:db8::1/96 has host bits set ---------------------------------------------------------------------- File "Doc/howto/ipaddress.rst", line 181, in ipaddress.rst Failed example: net4.numhosts Exception raised: Traceback (most recent call last): File "Lib/doctest.py", line 1287, in __run compileflags, 1), test.globs) File "", line 1, in net4.numhosts AttributeError: 'IPv4Network' object has no attribute 'numhosts' ---------------------------------------------------------------------- File "Doc/howto/ipaddress.rst", line 184, in ipaddress.rst Failed example: net6.numhosts Exception raised: Traceback (most recent call last): File "Lib/doctest.py", line 1287, in __run compileflags, 1), test.globs) File "", line 1, in net6.numhosts AttributeError: 'IPv6Network' object has no attribute 'numhosts' ---------------------------------------------------------------------- File "Doc/howto/ipaddress.rst", line 190, in ipaddress.rst Failed example: for x in net4.hosts(): Exception raised: Traceback (most recent call last): File "Lib/doctest.py", line 1287, in __run compileflags, 1), test.globs) File "", line 1 for x in net4.hosts(): ^ SyntaxError: unexpected EOF while parsing ---------------------------------------------------------------------- File "Doc/howto/ipaddress.rst", line 219, in ipaddress.rst Failed example: addr6.exploded Expected: '2001:0db8:0000:0000:0000:0000:0000:0000' Got: '2001:0db8:0000:0000:0000:0000:0000:0001' ---------------------------------------------------------------------- File "Doc/howto/ipaddress.rst", line 221, in ipaddress.rst Failed example: addr6.compressed Expected: '2001:db8::' Got: '2001:db8::1' ---------------------------------------------------------------------- File "Doc/howto/ipaddress.rst", line 244, in ipaddress.rst Failed example: net6[1] Expected: IPv6Address('2001::1') Got: IPv6Address('2001:db8::1') ---------------------------------------------------------------------- File "Doc/howto/ipaddress.rst", line 246, in ipaddress.rst Failed example: net6[-1] Expected: IPv6Address('2001::ffff:ffff') Got: IPv6Address('2001:db8::ffff:ffff') ---------- assignee: docs at python components: Documentation keywords: easy messages: 170097 nosy: cjerdonek, docs at python, ncoghlan, pmoody priority: normal severity: normal stage: needs patch status: open title: ipaddress HOWTO examples have some errors type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 14:15:03 2012 From: report at bugs.python.org (Roy Smith) Date: Sun, 09 Sep 2012 12:15:03 +0000 Subject: [issue15873] "datetime" cannot parse ISO 8601 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1347192903.1.0.815479107193.issue15873@psf.upfronthosting.co.za> Roy Smith added the comment: We need to define the scope of what input strings will be accepted. ISO-8601 defines a lot of stuff which we may not wish to accept. Do we want to accept both basic format (YYYYMMDD) and extended format (YYYY-MM-DD)? Do we want to accept things like "1985-W15-5", which is (if I understand this correctly(), the 5th day of the 15th week of 1985 [section 4.1.4.2]. Do we want to accept [section 4.2.2.4], "23:20,8", which is 23 hours, 20 minutes, 8 tenths of a minute. I suspect most people who have been following the recent thread (https://groups.google.com/d/topic/comp.lang.python/Q2w4R89Nq1w/discussion) would say none of the above are needed. All that's needed is if you have an existing datetime object, d1, you can do: s = str(d1) d2 = datetime.datetime(s) assert d1 == d2 for all values of d1. But, let's at least agree on that. Or, in the alternative, agree on something else. Then we know what we're shooting for. ---------- nosy: +roysmith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 14:20:19 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 09 Sep 2012 12:20:19 +0000 Subject: [issue15889] regrtest --start option raises AttributeError in many scenarios Message-ID: <1347193219.18.0.453057488599.issue15889@psf.upfronthosting.co.za> New submission from Chris Jerdonek: The --start option to regrtest raises an AttributeError in many scenarios. For example, these both raise an error: $ ./python.exe -m test --start test_random $ ./python.exe -m test --start test_random test_binascii test_random Traceback (most recent call last): File ".../Lib/runpy.py", line 160, in _run_module_as_main "__main__", fname, loader, pkg_name) File ".../Lib/runpy.py", line 73, in _run_code exec(code, run_globals) File ".../Lib/test/__main__.py", line 13, in regrtest.main() File ".../Lib/test/regrtest.py", line 562, in main del tests[:tests.index(start)] AttributeError: 'NoneType' object has no attribute 'index' Patch attached. ---------- components: Tests files: issue-regrtest-start-1.patch keywords: easy, patch messages: 170099 nosy: cjerdonek, ezio.melotti, michael.foord, pitrou priority: normal severity: normal stage: patch review status: open title: regrtest --start option raises AttributeError in many scenarios type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file27151/issue-regrtest-start-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 14:28:15 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 09 Sep 2012 12:28:15 +0000 Subject: [issue15889] regrtest --start option raises AttributeError in many scenarios In-Reply-To: <1347193219.18.0.453057488599.issue15889@psf.upfronthosting.co.za> Message-ID: <1347193695.89.0.173219122981.issue15889@psf.upfronthosting.co.za> Chris Jerdonek added the comment: This issue also affects 3.2 (but not 2.7; there is no --start option in 2.7). ---------- versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 16:11:28 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 09 Sep 2012 14:11:28 +0000 Subject: [issue15888] ipaddress HOWTO examples have some errors In-Reply-To: <1347190349.96.0.156720503481.issue15888@psf.upfronthosting.co.za> Message-ID: <1347199888.94.0.544042413829.issue15888@psf.upfronthosting.co.za> Chris Jerdonek added the comment: While we are here, the corresponding Python file also has a couple errors in one of its doctest examples. File "Lib/ipaddress.py", line 209, in ipaddress.summarize_address_range Failed example: summarize_address_range(IPv4Address('192.0.2.0'), Exception raised: Traceback (most recent call last): File "Lib/doctest.py", line 1287, in __run compileflags, 1), test.globs) File "", line 1 summarize_address_range(IPv4Address('192.0.2.0'), ^ SyntaxError: unexpected EOF while parsing ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 16:21:24 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 09 Sep 2012 14:21:24 +0000 Subject: [issue14649] doctest.DocTestSuite error misleading when module has no docstrings In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za> Message-ID: <1347200484.79.0.173487500477.issue14649@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, my mistake. I forgot to do the hg add for the new files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 16:30:06 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 09 Sep 2012 14:30:06 +0000 Subject: [issue15888] ipaddress doctest examples have some errors In-Reply-To: <1347190349.96.0.156720503481.issue15888@psf.upfronthosting.co.za> Message-ID: <1347201006.48.0.207443728699.issue15888@psf.upfronthosting.co.za> Chris Jerdonek added the comment: And also the main doc file Lib/ipaddress.rst (along with some formatting issues, and after adding needed imports): File "Doc/library/ipaddress.rst", line 115, in ipaddress.rst Failed example: ipaddress.IPv4Address(3221225985) Expected: IPv4Address('192.168.0.1') Got: IPv4Address('192.0.2.1') ---------- title: ipaddress HOWTO examples have some errors -> ipaddress doctest examples have some errors _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 16:38:17 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 09 Sep 2012 14:38:17 +0000 Subject: [issue15873] "datetime" cannot parse ISO 8601 dates and times In-Reply-To: <1347192903.1.0.815479107193.issue15873@psf.upfronthosting.co.za> Message-ID: <741D9384-E541-41E7-9D81-DB2A4C910844@gmail.com> Alexander Belopolsky added the comment: On Sep 9, 2012, at 8:15 AM, Roy Smith wrote: > We need to define the scope of what input strings will be accepted. Since it is easier to widen the domain of acceptable arguments than to narrow it in the future, I would say let's start by accepting str(x) only where x is date, time, timezone or datetime. I would leave out timedelta for now because it's str(x) does not resemble ISO at all. Either that or full ISO 8601. Anything in between is just too hard to explain. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 16:40:27 2012 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Sun, 09 Sep 2012 14:40:27 +0000 Subject: [issue15875] tarfile may not make @LongLink for non-ascii character In-Reply-To: <1346981062.61.0.534239636824.issue15875@psf.upfronthosting.co.za> Message-ID: <1347201627.14.0.128599813045.issue15875@psf.upfronthosting.co.za> Lars Gust?bel added the comment: I prepared a patch that fixes this issue and adds a few tests. Please try if it works for you. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file27152/issue15875.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 16:52:16 2012 From: report at bugs.python.org (Steven Willis) Date: Sun, 09 Sep 2012 14:52:16 +0000 Subject: [issue15676] mmap: add empty file check prior to offset check In-Reply-To: <1345052794.26.0.230448790651.issue15676@psf.upfronthosting.co.za> Message-ID: <1347202336.2.0.398107660516.issue15676@psf.upfronthosting.co.za> Steven Willis added the comment: Here's a patch for 3.1 ---------- Added file: http://bugs.python.org/file27153/issue15676-3.1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 17:00:00 2012 From: report at bugs.python.org (Steven Willis) Date: Sun, 09 Sep 2012 15:00:00 +0000 Subject: [issue15676] mmap: add empty file check prior to offset check In-Reply-To: <1345052794.26.0.230448790651.issue15676@psf.upfronthosting.co.za> Message-ID: <1347202800.49.0.201893261231.issue15676@psf.upfronthosting.co.za> Steven Willis added the comment: Here's a patch for 3.2 ---------- Added file: http://bugs.python.org/file27154/issue15676-3.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 17:06:06 2012 From: report at bugs.python.org (Steven Willis) Date: Sun, 09 Sep 2012 15:06:06 +0000 Subject: [issue15676] mmap: add empty file check prior to offset check In-Reply-To: <1345052794.26.0.230448790651.issue15676@psf.upfronthosting.co.za> Message-ID: <1347203166.25.0.141198116743.issue15676@psf.upfronthosting.co.za> Steven Willis added the comment: Here's a branch against the default branch in mercurial. I couldn't find a branch for 3.3 or 3.4. ---------- Added file: http://bugs.python.org/file27155/issue15676-default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 17:06:50 2012 From: report at bugs.python.org (Roy Smith) Date: Sun, 09 Sep 2012 15:06:50 +0000 Subject: [issue15873] "datetime" cannot parse ISO 8601 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1347203210.73.0.88674021706.issue15873@psf.upfronthosting.co.za> Roy Smith added the comment: I see I mis-stated my example. When I wrote: s = str(d1) d2 = datetime.datetime(s) assert d1 == d2 what I really meant was: s = d1.isoformat() d2 = datetime.datetime(s) assert d1 == d2 But, now I realize that while that is certainly an absolute lower bound, it's almost certainly not sufficient. The most common use case I see on a daily basis is parsing strings that look like "2012-09-07T23:59:59+00:00". This is also John Nagle's original use case from the cited mailing list thread: > I want to parse standard ISO date/time strings such as > 2012-09-09T18:00:00-07:00 Datetime.isoformat() returns something that matches the beginning of that, but doesn't have the time zone offset. And it's the offset that makes strptime() not usable as a soluation, because "%z" isn't portable. If we don't satisfy the "2012-09-07T23:59:59+00:00" case, then we won't have really done anything useful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 17:08:08 2012 From: report at bugs.python.org (Steven Willis) Date: Sun, 09 Sep 2012 15:08:08 +0000 Subject: [issue15676] mmap: add empty file check prior to offset check In-Reply-To: <1345052794.26.0.230448790651.issue15676@psf.upfronthosting.co.za> Message-ID: <1347203288.43.0.131274243007.issue15676@psf.upfronthosting.co.za> Changes by Steven Willis : ---------- versions: +Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 17:37:08 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 09 Sep 2012 15:37:08 +0000 Subject: [issue14649] doctest.DocTestSuite error misleading when module has no docstrings In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za> Message-ID: <1347205028.67.0.402283078894.issue14649@psf.upfronthosting.co.za> Chris Jerdonek added the comment: What workflow/command are you using to apply and then merge the patch? I didn't need to run "hg add" at any point to go from 3.2 to default, and run the tests, etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 17:39:37 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 09 Sep 2012 15:39:37 +0000 Subject: [issue15676] mmap: add empty file check prior to offset check In-Reply-To: <1345052794.26.0.230448790651.issue15676@psf.upfronthosting.co.za> Message-ID: <1347205177.55.0.0369778032625.issue15676@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Thanks for the patches. Note that you don't have to provide a patch for each branch, it's usually the committer's job. The patch looks good, but the test could be rewritten with assertRaisesRegex(): http://docs.python.org/dev/library/unittest.html#unittest.TestCase.assertRaisesRegex ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 18:06:55 2012 From: report at bugs.python.org (John Nagle) Date: Sun, 09 Sep 2012 16:06:55 +0000 Subject: [issue15873] "datetime" cannot parse ISO 8601 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1347206815.98.0.877495935369.issue15873@psf.upfronthosting.co.za> John Nagle added the comment: For what parts of ISO 8601 to accept, there's a standard: RFC3339, "Date and Time on the Internet: Timestamps". See section 5.6: date-fullyear = 4DIGIT date-month = 2DIGIT ; 01-12 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on ; month/year time-hour = 2DIGIT ; 00-23 time-minute = 2DIGIT ; 00-59 time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap second ; rules time-secfrac = "." 1*DIGIT time-numoffset = ("+" / "-") time-hour ":" time-minute time-offset = "Z" / time-numoffset partial-time = time-hour ":" time-minute ":" time-second [time-secfrac] full-date = date-fullyear "-" date-month "-" date-mday full-time = partial-time time-offset date-time = full-date "T" full-time NOTE: Per [ABNF] and ISO8601, the "T" and "Z" characters in this syntax may alternatively be lower case "t" or "z" respectively. ISO 8601 defines date and time separated by "T". Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character. That's straightforward, and can be expressed as a regular expression. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 18:09:58 2012 From: report at bugs.python.org (=?utf-8?q?D=C3=A1niel_Darabos?=) Date: Sun, 09 Sep 2012 16:09:58 +0000 Subject: [issue15419] distutils: build_py_2to3 should use a separate build directory In-Reply-To: <1342945976.47.0.537572255215.issue15419@psf.upfronthosting.co.za> Message-ID: <1347206998.28.0.821923501054.issue15419@psf.upfronthosting.co.za> D?niel Darabos added the comment: I've had the same issue. I was installing Pyglet. I first installed it under Python 2, then: $ sudo python3 setup.py install running install running build running build_py running install_lib [...] creating /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pyglet/window/xlib copying build/lib/pyglet/window/xlib/__init__.py -> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pyglet/window/xlib byte-compiling /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pyglet/__init__.py to __init__.cpython-32.pyc File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pyglet/__init__.py", line 276 print '[%d] %s%s %s' % (thread, indent, name, location) ^ SyntaxError: invalid syntax Deleting the 'build' directory from the Python 2 run fixed the problem and I could install the package under Python 3. ---------- nosy: +darabos _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 18:11:01 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 09 Sep 2012 16:11:01 +0000 Subject: [issue15873] "datetime" cannot parse ISO 8601 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1347207061.21.0.978594637144.issue15873@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > I realize that while that is certainly an absolute lower bound, > it's almost certainly not sufficient. The most common use case > I see on a daily basis is parsing strings that look like > "2012-09-07T23:59:59+00:00". This is exactly what isoformat() of an aware datetime looks like: >>> datetime.now(timezone.utc).isoformat() '2012-09-09T16:09:46.165886+00:00' str() is the same up to T replaced by space: >>> print(datetime.now(timezone.utc)) 2012-09-09 15:19:12.567692+00:00 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 18:13:49 2012 From: report at bugs.python.org (Aaron) Date: Sun, 09 Sep 2012 16:13:49 +0000 Subject: [issue2716] Reimplement audioop because of copyright issues In-Reply-To: <1209428570.75.0.48368829493.issue2716@psf.upfronthosting.co.za> Message-ID: <1347207229.53.0.594816592232.issue2716@psf.upfronthosting.co.za> Aaron added the comment: The license from http://sox.sourcearchive.com/documentation/12.17.7/g711_8c-source.html /* * This source code is a product of Sun Microsystems, Inc. and is provided * for unrestricted use. Users may copy or modify this source code without * charge. * * SUN SOURCE CODE IS PROVIDED AS IS WITH NO WARRANTIES OF ANY KIND INCLUDING * THE WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS FOR A PARTICULAR * PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE PRACTICE. * * Sun source code is provided with no support and without any obligation on * the part of Sun Microsystems, Inc. to assist in its use, correction, * modification or enhancement. * * SUN MICROSYSTEMS, INC. SHALL HAVE NO LIABILITY WITH RESPECT TO THE * INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY THIS SOFTWARE * OR ANY PART THEREOF. * * In no event will Sun Microsystems, Inc. be liable for any lost revenue * or profits or other special, indirect and consequential damages, even if * Sun has been advised of the possibility of such damages. * * Sun Microsystems, Inc. * 2550 Garcia Avenue * Mountain View, California 94043 */ That seems compatible with Python's licensing, no? It seems like adding this license text to the file and also to the documentation in http://docs.python.org/license.html#licenses-and-acknowledgements-for-incorporated-software would make this a non-issue. Assessment of the module's contents and whether it should be rewritten or removed seems like a separate issue. I could write up a patch if people think that this would solve the problem. ---------- nosy: +hac.man _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 18:25:32 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 09 Sep 2012 16:25:32 +0000 Subject: [issue15873] "datetime" cannot parse ISO 8601 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1347207932.54.0.0195661755073.issue15873@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > For what parts of ISO 8601 to accept, there's a standard: RFC3339 This is almost indistinguishable from the idea of accepting .isoformat() and str() results. From what I see the only difference is that 't' is accepted for date/time separator and 'z' is accepted as a timezone. Let's start with this. As an ultimate solution, I would like to see something like codec registry so that we can do things like datetime(.., format='rfc3339') or date(.., format='gnu') for GNU parse_datetime. I think this will look more pythonic than strptime(). Of course, strptime format can also be accepted as the value for the format keyword. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 18:51:58 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 09 Sep 2012 16:51:58 +0000 Subject: [issue15888] ipaddress doctest examples have some errors In-Reply-To: <1347190349.96.0.156720503481.issue15888@psf.upfronthosting.co.za> Message-ID: <1347209518.77.0.000810640456908.issue15888@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I will prepare a patch for these three files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 19:24:40 2012 From: report at bugs.python.org (Nicholas Cole) Date: Sun, 09 Sep 2012 17:24:40 +0000 Subject: [issue14223] curses addch broken on Python3.3a1 In-Reply-To: <1331153094.15.0.871612927682.issue14223@psf.upfronthosting.co.za> Message-ID: <1347211480.14.0.371838591088.issue14223@psf.upfronthosting.co.za> Nicholas Cole added the comment: I've just tried the OS X build of 3.3rc2, and this has been fixed. Thank you! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 19:28:07 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 09 Sep 2012 17:28:07 +0000 Subject: [issue15881] multiprocessing 'NoneType' object is not callable In-Reply-To: <1347044200.13.0.235512745295.issue15881@psf.upfronthosting.co.za> Message-ID: <3XFK920NhWzQW8@mail.python.org> Roundup Robot added the comment: New changeset 27d410dd5431 by Alexander Belopolsky in branch '3.2': Issue #15881: Fixed atexit hook in multiprocessing. http://hg.python.org/cpython/rev/27d410dd5431 New changeset 08c680918ff8 by Alexander Belopolsky in branch 'default': Issue #15881: Fixed atexit hook in multiprocessing. http://hg.python.org/cpython/rev/08c680918ff8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 19:31:21 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 09 Sep 2012 17:31:21 +0000 Subject: [issue15881] multiprocessing 'NoneType' object is not callable In-Reply-To: <1347044200.13.0.235512745295.issue15881@psf.upfronthosting.co.za> Message-ID: <3XFKDm2N8HzQXs@mail.python.org> Roundup Robot added the comment: New changeset db67b848ddc3 by Alexander Belopolsky in branch '3.2': Issue #15881: Fixed 3.2 backport. http://hg.python.org/cpython/rev/db67b848ddc3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 19:55:39 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 09 Sep 2012 17:55:39 +0000 Subject: [issue15881] multiprocessing 'NoneType' object is not callable In-Reply-To: <1347044200.13.0.235512745295.issue15881@psf.upfronthosting.co.za> Message-ID: <1347213339.65.0.969742506603.issue15881@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Applied to 3.2 and 3.3. Thanks for the patch! Leaving it open pending 2.7 commit. ---------- resolution: -> fixed stage: commit review -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 20:12:01 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 09 Sep 2012 18:12:01 +0000 Subject: [issue15881] multiprocessing 'NoneType' object is not callable In-Reply-To: <1347044200.13.0.235512745295.issue15881@psf.upfronthosting.co.za> Message-ID: <3XFL7h3XHhzQRs@mail.python.org> Roundup Robot added the comment: New changeset b05547e8ff92 by Alexander Belopolsky in branch '3.2': Issue #15881: Added NEWS entry and proper credit. http://hg.python.org/cpython/rev/b05547e8ff92 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 20:12:05 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 09 Sep 2012 18:12:05 +0000 Subject: [issue14649] doctest.DocTestSuite error misleading when module has no docstrings In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za> Message-ID: <1347214325.78.0.504781995912.issue14649@psf.upfronthosting.co.za> R. David Murray added the comment: I have separate working directories for 3.2 vs 3.3. If you have a single working directory, the files would continue to be present even without the add. The add is definitely needed for a correctly committed changeset. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 20:27:06 2012 From: report at bugs.python.org (=?utf-8?q?Tomi_Pievil=C3=A4inen?=) Date: Sun, 09 Sep 2012 18:27:06 +0000 Subject: [issue15890] lib2to3 pickles created with wrong permissions Message-ID: <1347215226.9.0.69518719078.issue15890@psf.upfronthosting.co.za> New submission from Tomi Pievil?inen: The fix of #15822 caused another break. After installing 3.3rc2 from source, ls -ltc --full-time /usr/local/lib/python3.3/lib2to3/ shows: -rw-------. 1 root root 1455 2012-09-09 20:55:36.475519602 +0300 PatternGrammar3.3.0.candidate.2.pickle -rw-------. 1 root root 20862 2012-09-09 20:55:36.425520211 +0300 Grammar3.3.0.candidate.2.pickle drwx------. 2 root root 4096 2012-09-09 20:55:33.681520171 +0300 __pycache__/ drwxr-xr-x. 4 root root 4096 2012-09-09 20:55:30.087520195 +0300 tests/ drwxr-xr-x. 3 root root 4096 2012-09-09 20:55:30.063457702 +0300 pgen2/ drwxr-xr-x. 3 root root 4096 2012-09-09 20:55:30.028520614 +0300 fixes/ -rw-r--r--. 1 root root 28046 2012-09-09 20:55:09.319519773 +0300 refactor.py -rw-r--r--. 1 root root 28386 2012-09-09 20:55:09.279456945 +0300 pytree.py -rw-r--r--. 1 root root 1114 2012-09-09 20:55:09.242458183 +0300 pygram.py -rw-r--r--. 1 root root 793 2012-09-09 20:55:09.205457004 +0300 PatternGrammar.txt -rw-r--r--. 1 root root 7075 2012-09-09 20:55:09.168457078 +0300 patcomp.py -rw-r--r--. 1 root root 11624 2012-09-09 20:55:09.131457019 +0300 main.py -rw-r--r--. 1 root root 67 2012-09-09 20:55:09.091644598 +0300 __main__.py -rw-r--r--. 1 root root 7 2012-09-09 20:55:09.052457036 +0300 __init__.py -rw-r--r--. 1 root root 6589 2012-09-09 20:55:09.014519602 +0300 Grammar.txt -rw-r--r--. 1 root root 14533 2012-09-09 20:55:08.977519642 +0300 fixer_util.py -rw-r--r--. 1 root root 6706 2012-09-09 20:55:08.940519615 +0300 fixer_base.py -rw-r--r--. 1 root root 10011 2012-09-09 20:55:08.903519608 +0300 btm_utils.py -rw-r--r--. 1 root root 6833 2012-09-09 20:55:08.865457147 +0300 btm_matcher.py The pickles are now correctly newer than the Grammar texts, but are readable only by root. Quick chmod fixes this, but has to be done manually on systems with strict UMASK for root. ---------- components: 2to3 (2.x to 3.x conversion tool) messages: 170124 nosy: tpievila priority: normal severity: normal status: open title: lib2to3 pickles created with wrong permissions versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 20:44:25 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 09 Sep 2012 18:44:25 +0000 Subject: [issue15890] lib2to3 pickles created with wrong permissions In-Reply-To: <1347215226.9.0.69518719078.issue15890@psf.upfronthosting.co.za> Message-ID: <1347216265.28.0.0395575009002.issue15890@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I propose to postpone the fix for that to 3.3.1. Meanwhile, users should either set umask to 022 before installing, or chmod the files afterwards. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 21:08:04 2012 From: report at bugs.python.org (Julian Berman) Date: Sun, 09 Sep 2012 19:08:04 +0000 Subject: [issue15891] A public facing API for __unittest = True Message-ID: <1347217684.87.0.845437270023.issue15891@psf.upfronthosting.co.za> New submission from Julian Berman: Can `__unittest = True`, which is used to hide stack frames from tracebacks inside the testing framework, be documented as being public, or, if that's not acceptable, be replaced by something that is? `_exc_info_to_string` is a hairy function to need to rewrite when authoring a testing framework, but it's a rather common thing to want, and would be nice if it was easily done by integrating with what `TestCase` is already doing. It's also (with or without formal blessing) being used in the wild in at least one place I know of here http://bazaar.launchpad.net/~testtools-committers/testtools/trunk/view/head:/testtools/testcase.py#L798 and since it's not terribly critical and will fail rather nicely even if the API changes suddenly I'd bet other places are using it too, though I haven't bothered to check. See also http://twistedmatrix.com/trac/ticket/4127 which would be easier to implement if this were acceptable to use for external code. ---------- components: Library (Lib) messages: 170126 nosy: Julian, michael.foord priority: normal severity: normal status: open title: A public facing API for __unittest = True type: enhancement versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 21:15:43 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 09 Sep 2012 19:15:43 +0000 Subject: [issue15890] lib2to3 pickles created with wrong permissions In-Reply-To: <1347215226.9.0.69518719078.issue15890@psf.upfronthosting.co.za> Message-ID: <1347218143.31.0.76987879143.issue15890@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever, ned.deily versions: +Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 21:19:33 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 09 Sep 2012 19:19:33 +0000 Subject: [issue15890] lib2to3 pickles created with wrong permissions In-Reply-To: <1347215226.9.0.69518719078.issue15890@psf.upfronthosting.co.za> Message-ID: <1347218373.6.0.436846178862.issue15890@psf.upfronthosting.co.za> Ned Deily added the comment: AFAIK, the pickles are created with exactly the same permissions as the cached pyc and pyo files have been all along. So, if you propose to change the permissions for the pickles, the compileall steps should be changed as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 21:36:08 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 09 Sep 2012 19:36:08 +0000 Subject: [issue15891] A public facing API for __unittest = True In-Reply-To: <1347217684.87.0.845437270023.issue15891@psf.upfronthosting.co.za> Message-ID: <1347219368.78.0.4469814188.issue15891@psf.upfronthosting.co.za> R. David Murray added the comment: This is a duplicate of issue 1705520. Since Michael obviously hasn't gotten to it yet, a proposed patch might move things along. ---------- nosy: +r.david.murray stage: -> committed/rejected status: open -> closed superseder: -> API for excluding methods from unittest stack traces _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 21:36:25 2012 From: report at bugs.python.org (Michael Foord) Date: Sun, 09 Sep 2012 19:36:25 +0000 Subject: [issue15891] A public facing API for __unittest = True In-Reply-To: <1347217684.87.0.845437270023.issue15891@psf.upfronthosting.co.za> Message-ID: <1347219385.38.0.578919927524.issue15891@psf.upfronthosting.co.za> Michael Foord added the comment: Whatever we do must be backwards compatible. The question is, is a better api that doesn't use stack frames (which is a hack in my opinion) even possible? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 21:36:44 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 09 Sep 2012 19:36:44 +0000 Subject: [issue1705520] API for excluding methods from unittest stack traces Message-ID: <1347219404.45.0.361610308465.issue1705520@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +Julian stage: test needed -> needs patch versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 21:46:21 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 09 Sep 2012 19:46:21 +0000 Subject: [issue15890] lib2to3 pickles created with wrong permissions In-Reply-To: <1347215226.9.0.69518719078.issue15890@psf.upfronthosting.co.za> Message-ID: <1347219981.62.0.745165221174.issue15890@psf.upfronthosting.co.za> Ned Deily added the comment: BTW, AFAICT, you'll get exactly the same behavior (with distribute failing due to pickle write permission) with earlier releases, like 3.2.3, if you happen to do a "make install" with an inappropriate umask value. So it appears that setting umask properly has been an existing, if perhaps undocumented, requirement. Ensuring permissions for all installed files are set to sane values seems like a good idea, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 22:06:07 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 09 Sep 2012 20:06:07 +0000 Subject: [issue15890] lib2to3 pickles created with wrong permissions In-Reply-To: <1347215226.9.0.69518719078.issue15890@psf.upfronthosting.co.za> Message-ID: <1347221167.74.0.498810222532.issue15890@psf.upfronthosting.co.za> R. David Murray added the comment: It occurs to me that ignoring the user's selected umask could be considered a bug by some people. A package manager for a distribution should presumably ensure the correct umask during install, but if a user is doing a direct install, it seems reasonable to think they are responsible for setting the umask they want used. There is a fuzzy line here, though, because distutils is also a bit of a package manager... Regardless, though, Ned's observation seems to indicate this is not a regression. Tomi, do you find a different behavior in 3.2? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 22:12:34 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 09 Sep 2012 20:12:34 +0000 Subject: [issue14223] curses addch broken on Python3.3a1 In-Reply-To: <1347211480.14.0.371838591088.issue14223@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > I've just tried the OS X build of 3.3rc2, and this has been fixed. Thank you! Great! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 22:16:45 2012 From: report at bugs.python.org (Steven Willis) Date: Sun, 09 Sep 2012 20:16:45 +0000 Subject: [issue15676] mmap: add empty file check prior to offset check In-Reply-To: <1345052794.26.0.230448790651.issue15676@psf.upfronthosting.co.za> Message-ID: <1347221805.47.0.513728807557.issue15676@psf.upfronthosting.co.za> Steven Willis added the comment: Sorry, I thought that's what jcea was asking for. Here's an updated patch for the default branch in mercurial that uses assertRaisesRegex in the test. ---------- Added file: http://bugs.python.org/file27156/issue15676-default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 22:49:49 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 09 Sep 2012 20:49:49 +0000 Subject: [issue15437] Merge Doc/ACKS.txt names into Misc/ACKS In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za> Message-ID: <1347223789.29.0.653799471897.issue15437@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I was reminded of this issue by the following e-mail today: http://mail.python.org/pipermail/python-dev/2012-September/121639.html I updated the script I attached earlier to ensure that it can also be run against the names in 2.7 (attaching now as script #3). I also checked that this latest script can still be run against 3.2 and default with the names that have been added since the last time I checked. Let me know if you would like any assistance in how to run the script and what to check for, etc. ---------- Added file: http://bugs.python.org/file27157/merge-acks-3.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 22:57:05 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 09 Sep 2012 20:57:05 +0000 Subject: [issue15419] distutils: build_py_2to3 should use a separate build directory In-Reply-To: <1342945976.47.0.537572255215.issue15419@psf.upfronthosting.co.za> Message-ID: <1347224225.12.0.103306378089.issue15419@psf.upfronthosting.co.za> Ned Deily added the comment: It seems to me this is just a special case of the more general issue of building multiple versions of the same distribution, say with multiple versions of Python 2. In general, anytime you change your build environment, you should start with no existing build directory. That's just good practice. Distutils doesn't keep track of every change you might make in a build environment between invocations of setup.py. I suggest that this be closed as "won't fix". ---------- nosy: +ned.deily versions: -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 23:37:59 2012 From: report at bugs.python.org (=?utf-8?q?Eduardo_A=2E_Bustamante_L=C3=B3pez?=) Date: Sun, 09 Sep 2012 21:37:59 +0000 Subject: [issue15851] Lib/robotparser.py doesn't accept setting a user agent string, instead it uses the default. In-Reply-To: <1347045054.66.0.127391915664.issue15851@psf.upfronthosting.co.za> Message-ID: <20120909213740.GB5726@claret.lan> Eduardo A. Bustamante L?pez added the comment: I'm not sure what's the best approach here. 1. Avoid changes in the Lib, and document a work-around, which involves installing an opener with the specific User-agent. The draw-back is that it modifies the behaviour of urlopen() globally, so that change affects any other call to urllib.request.urlopen. 2. Revert to the old way, using an instance of a FancyURLopener (or URLopener), in the RobotFileParser class. This requires a modification of the Lib, but allows us to modify only the behaviour of that specific instance of RobotFileParser. The user could sub-class FancyURLopener, set the appropiate version string. I attach a script, tested against the ``default`` branch of the mercurial repository. It shows the work around for python3.3. ---------- Added file: http://bugs.python.org/file27158/test.py _______________________________________ Python tracker _______________________________________ -------------- next part -------------- import urllib.robotparser import urllib.request opener = urllib.request.build_opener() opener.addheaders = [('User-agent', 'MyUa/0.1')] urllib.request.install_opener(opener) rp = urllib.robotparser.RobotFileParser('http://localhost:9999') rp.read() From report at bugs.python.org Sun Sep 9 23:45:19 2012 From: report at bugs.python.org (=?utf-8?q?Eduardo_A=2E_Bustamante_L=C3=B3pez?=) Date: Sun, 09 Sep 2012 21:45:19 +0000 Subject: [issue15851] Lib/robotparser.py doesn't accept setting a user agent string, instead it uses the default. In-Reply-To: <20120909213740.GB5726@claret.lan> Message-ID: <20120909214501.GC5726@claret.lan> Eduardo A. Bustamante L?pez added the comment: I forgot to mention that I ran a nc process in parallel, to see what data is being sent: ``nc -l -p 9999``. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 9 23:56:02 2012 From: report at bugs.python.org (Christian Heimes) Date: Sun, 09 Sep 2012 21:56:02 +0000 Subject: [issue15892] _PyImport_GetDynLoadFunc() doesn't check return value of fstat() Message-ID: <1347227762.77.0.329908285172.issue15892@psf.upfronthosting.co.za> New submission from Christian Heimes: The function _PyImport_GetDynLoadFunc() in Python/dynload_shlib.c doesn't check the return value of fstat() CID 486250: Other violation (CHECKED_RETURN)At (3): Calling function "fstat(fileno(fp), &statb)" without checking return value. This library function may fail and return an error code. At (4): No check of the return value of "fstat(fileno(fp), &statb)". 93 fstat(fileno(fp), &statb); Suggested fix: if (fstat(fileno(fp), &statb) == -1) { PyErr_SetFromErrnoWithFilename(PyExc_IOError, pathname); return NULL; } } ---------- components: Interpreter Core messages: 170138 nosy: christian.heimes priority: normal severity: normal stage: patch review status: open title: _PyImport_GetDynLoadFunc() doesn't check return value of fstat() type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 00:09:58 2012 From: report at bugs.python.org (Christian Heimes) Date: Sun, 09 Sep 2012 22:09:58 +0000 Subject: [issue15893] Py_FrozenMain() resource leak and missing malloc checks Message-ID: <1347228598.43.0.424519630485.issue15893@psf.upfronthosting.co.za> New submission from Christian Heimes: In Python/frozenmain.c the function Py_FrozenMain() doesn't handle argv_copy and argv_copy2 correctly. Both variables contain memory that is allocated with PyMem_Malloc(). argv_copy2 is never checked for NULL and both variables are not correctly cleaned up in error cases. CID 486834: Resource leak (RESOURCE_LEAK)At (11): Variable "argv_copy" going out of scope leaks the storage it points to. CID 486835: Resource leak (RESOURCE_LEAK)At (9): Variable "argv_copy2" going out of scope leaks the storage it points to. Suggested fix: Separate var declaration from PyMem_Malloc() calls and use a goto label to clean up the variables and its content at the end of the function. ---------- components: Interpreter Core messages: 170139 nosy: christian.heimes priority: normal severity: normal status: open title: Py_FrozenMain() resource leak and missing malloc checks type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 00:15:45 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Sun, 09 Sep 2012 22:15:45 +0000 Subject: [issue15676] mmap: add empty file check prior to offset check In-Reply-To: <1345052794.26.0.230448790651.issue15676@psf.upfronthosting.co.za> Message-ID: <1347228945.58.0.105631557585.issue15676@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Having separate patches is useful if the patch can not be applied cleanly to different python branches. This is specially true with 2.7/3.x. Checking the fix and committing it to 2.7, 3.2 and 3.3 (probably available in 3.3.1, not 3.3.0, already in release candidate). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 00:23:14 2012 From: report at bugs.python.org (Christian Heimes) Date: Sun, 09 Sep 2012 22:23:14 +0000 Subject: [issue15894] _PyImport_ReInitLock() doesn't check return value of PyThread_acquire_lock Message-ID: <1347229394.03.0.409721609393.issue15894@psf.upfronthosting.co.za> New submission from Christian Heimes: Coverity claims that the call to PyThread_acquire_lock with NOWAIT_LOCK can fail. It sounds plausible as you don't wait for the lock to succeed. CID 486861: Unchecked return value (CHECKED_RETURN)At (3): Calling function "PyThread_acquire_lock(PyThread_type_lock, int)" without checking return value (as is done elsewhere 22 out of 23 times). At (9): No check of the return value of "PyThread_acquire_lock(import_lock, 0)". 205 PyThread_acquire_lock(import_lock, 0); 206 /* XXX: can the previous line fail? */ By the way the code would be more readable with NOWAIT_LOCK instead of 0. ---------- assignee: brett.cannon components: Interpreter Core messages: 170141 nosy: brett.cannon, christian.heimes priority: normal severity: normal status: open title: _PyImport_ReInitLock() doesn't check return value of PyThread_acquire_lock type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 00:50:50 2012 From: report at bugs.python.org (Christian Heimes) Date: Sun, 09 Sep 2012 22:50:50 +0000 Subject: [issue15895] PyRun_SimpleFileExFlags() can leak a FILE pointer Message-ID: <1347231050.54.0.0211027720618.issue15895@psf.upfronthosting.co.za> New submission from Christian Heimes: In Python/pythonrun.c PyRun_SimpleFileExFlags() may leak a FILE pointer if closeit is False and maybe_pyc_file returns true. This happens when the filename ends with ".pyc" or ".pyc". In this case the file is opened a second time with fopen() a few lines lower and assigned to the same variable "fp". However "fp" is never closed. The bug was found by Coverity as CID 719689. Georg: I've set the priority to release blocker as a resource leak of a file pointer and therefore rare file descriptor is IMHO a severe issue. ---------- assignee: georg.brandl files: closeown.patch keywords: patch messages: 170142 nosy: brett.cannon, christian.heimes, georg.brandl priority: release blocker severity: normal stage: patch review status: open title: PyRun_SimpleFileExFlags() can leak a FILE pointer type: resource usage Added file: http://bugs.python.org/file27159/closeown.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 01:04:03 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 09 Sep 2012 23:04:03 +0000 Subject: [issue15890] lib2to3 pickles created with wrong permissions In-Reply-To: <1347215226.9.0.69518719078.issue15890@psf.upfronthosting.co.za> Message-ID: <1347231843.38.0.0132931376126.issue15890@psf.upfronthosting.co.za> Martin v. L?wis added the comment: It appears that it is tradition of (BSD) install(1) to ignore umask. For consistency, all installed files should get the same ACL (+-x where necessary). So I think this behavior is a bug (although apparently not a regression). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 01:04:39 2012 From: report at bugs.python.org (Vitaly) Date: Sun, 09 Sep 2012 23:04:39 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS Message-ID: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za> New submission from Vitaly: Python 2.6.7 on Mac OS 10.7.4 running on MacBookPro laptop. run attachment as: python test_pipe_error.py The test() function makes multiple calls to _execute_child() in a loop. Every other call to _execute_child() fails with: ===== os.read(3, 1048576) self pid: 43953 EINVAL FROM TEST: Traceback (most recent call last): File "test_pipe_error.py", line 127, in test _execute_child() File "test_pipe_error.py", line 95, in _execute_child newData = os.read(errpipe_read, rSize) OSError: [Errno 22] Invalid argument ===== _execute_child() is based on subprocess.Popen._execute_child, but with most Popen code removed and errpipe_read configured as os.O_NONBLOCK in the parent process. Raising of an Exception() instance is used to simulate failure in os.execvp() instead of calling os.execvp(). We initially experienced the EINVAL issue in the parent process' os.read call when os.execvp failed in the child (e.g., errno=2, "file not found"), so I stripped the code to bare minimum in order to reproduce the problem with a smaller code snippet. ---------- components: Library (Lib) files: test_pipe_error.py messages: 170144 nosy: vitaly priority: normal severity: normal status: open title: Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS type: crash versions: Python 2.6 Added file: http://bugs.python.org/file27160/test_pipe_error.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 01:24:44 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 09 Sep 2012 23:24:44 +0000 Subject: [issue15676] mmap: add empty file check prior to offset check In-Reply-To: <1345052794.26.0.230448790651.issue15676@psf.upfronthosting.co.za> Message-ID: <3XFT4W3HL1zQZJ@mail.python.org> Roundup Robot added the comment: New changeset d85f80b31b54 by Jesus Cea in branch '3.2': Closes #15676: mmap: add empty file check prior to offset check http://hg.python.org/cpython/rev/d85f80b31b54 New changeset f962ec8e47a1 by Jesus Cea in branch 'default': Closes #15676: mmap: add empty file check prior to offset check http://hg.python.org/cpython/rev/f962ec8e47a1 New changeset 27837a33790d by Jesus Cea in branch '2.7': Closes #15676: mmap: add empty file check prior to offset check http://hg.python.org/cpython/rev/27837a33790d ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 02:08:38 2012 From: report at bugs.python.org (Christian Heimes) Date: Mon, 10 Sep 2012 00:08:38 +0000 Subject: [issue15897] zipimport.c doesn't check return value of fseek() Message-ID: <1347235718.45.0.529510656833.issue15897@psf.upfronthosting.co.za> New submission from Christian Heimes: The code im zipimport.c doesn't check the return value of fseek() in at least four places. The missing checks may hide issues with the file or file system. Solution: Check for -1 and return with an appropriate call to PyErr_SetFromErrno() ---------- components: Extension Modules keywords: easy messages: 170146 nosy: christian.heimes priority: normal severity: normal status: open title: zipimport.c doesn't check return value of fseek() type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 02:48:24 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 10 Sep 2012 00:48:24 +0000 Subject: [issue15870] PyType_FromSpec should take metaclass as an argument In-Reply-To: <1346946566.36.0.583610018294.issue15870@psf.upfronthosting.co.za> Message-ID: <1347238104.67.0.474449662463.issue15870@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 02:53:07 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 10 Sep 2012 00:53:07 +0000 Subject: [issue15873] "datetime" cannot parse ISO 8601 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1347238387.69.0.963496783499.issue15873@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 02:58:14 2012 From: report at bugs.python.org (Andrew Moffat) Date: Mon, 10 Sep 2012 00:58:14 +0000 Subject: [issue15898] OSX TTY bug Message-ID: <1347238694.31.0.649838162085.issue15898@psf.upfronthosting.co.za> New submission from Andrew Moffat: I'm getting some kind of race condition on OSX when trying to read the output from a pseudoterminal of a forked process. This race conditional only occurs if I run tty.tcsetattr on the master side of the pty, regardless of if I actually change the mode or not. Try running the following code on OSX multiple times. Sometimes you'll see "testing", sometimes you won't, sometimes it hangs. If you comment out "tty.tcsetattr", you will consistently see "testing". import os import pty import resource import signal import tty master, slave = pty.openpty() pid = os.fork() # BUG IS HERE # we're not making any changes to the tty mode, but # the mere act of setting a mode causes the output to only # show up sometimes. # # comment out "tty.tcsetattr" and the bug goes away mode = tty.tcgetattr(master) tty.tcsetattr(master, tty.TCSANOW, mode) # child process if pid == 0: os.setsid() os.close(master) os.dup2(slave, 0) os.dup2(slave, 1) os.dup2(slave, 2) max_fd = resource.getrlimit(resource.RLIMIT_NOFILE)[0] os.closerange(3, max_fd) # make controlling terminal. taken from pty.fork tmp_fd = os.open(os.ttyname(1), os.O_RDWR) os.close(tmp_fd) os.write(1, "testing".encode()) os._exit(255) # parent process else: os.close(slave) try: print(os.read(master, 1024)) finally: os.kill(pid, signal.SIGKILL) ---------- messages: 170147 nosy: amoffat priority: normal severity: normal status: open title: OSX TTY bug type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 03:06:28 2012 From: report at bugs.python.org (Manuke) Date: Mon, 10 Sep 2012 01:06:28 +0000 Subject: [issue15875] tarfile may not make @LongLink for non-ascii character In-Reply-To: <1346981062.61.0.534239636824.issue15875@psf.upfronthosting.co.za> Message-ID: <1347239188.02.0.620400554462.issue15875@psf.upfronthosting.co.za> Manuke added the comment: I have tried your patch and it have worked completely for my test code. The patch is efficient. Thank you for your speedy work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 03:06:31 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 10 Sep 2012 01:06:31 +0000 Subject: [issue15719] Sort dict items in urlencode() In-Reply-To: <1345236293.12.0.120802358061.issue15719@psf.upfronthosting.co.za> Message-ID: <1347239191.1.0.046410442452.issue15719@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 03:13:42 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 10 Sep 2012 01:13:42 +0000 Subject: [issue15723] Python breaks OS' append guarantee on file writes In-Reply-To: <1345321177.26.0.0602208919047.issue15723@psf.upfronthosting.co.za> Message-ID: <1347239622.0.0.314748039252.issue15723@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 04:12:15 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 10 Sep 2012 02:12:15 +0000 Subject: [issue15751] Support subinterpreters in the GIL state API In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> Message-ID: <1347243135.01.0.87715104149.issue15751@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 04:12:51 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 10 Sep 2012 02:12:51 +0000 Subject: [issue15756] subprocess.poll() does not handle errno.ECHILD "No child processes" In-Reply-To: <1345576517.75.0.906463701582.issue15756@psf.upfronthosting.co.za> Message-ID: <1347243171.49.0.790939892343.issue15756@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 04:17:59 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 10 Sep 2012 02:17:59 +0000 Subject: [issue15883] Add Py_errno to work around multiple CRT issue In-Reply-To: <1347111302.92.0.306708953598.issue15883@psf.upfronthosting.co.za> Message-ID: <1347243479.5.0.317567740686.issue15883@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 04:20:55 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 10 Sep 2012 02:20:55 +0000 Subject: [issue15897] zipimport.c doesn't check return value of fseek() In-Reply-To: <1347235718.45.0.529510656833.issue15897@psf.upfronthosting.co.za> Message-ID: <1347243655.76.0.409068609995.issue15897@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 04:24:50 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 10 Sep 2012 02:24:50 +0000 Subject: [issue15895] PyRun_SimpleFileExFlags() can leak a FILE pointer In-Reply-To: <1347231050.54.0.0211027720618.issue15895@psf.upfronthosting.co.za> Message-ID: <1347243890.43.0.362302100918.issue15895@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: LGTM. Instead of using a flag variable, could you use something like "if (fp!=NULL) fclose(fp);"? ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 04:25:39 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 10 Sep 2012 02:25:39 +0000 Subject: [issue15894] _PyImport_ReInitLock() doesn't check return value of PyThread_acquire_lock In-Reply-To: <1347229394.03.0.409721609393.issue15894@psf.upfronthosting.co.za> Message-ID: <1347243939.83.0.0327093338216.issue15894@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 04:25:45 2012 From: report at bugs.python.org (Ned Deily) Date: Mon, 10 Sep 2012 02:25:45 +0000 Subject: [issue15898] OSX TTY bug In-Reply-To: <1347238694.31.0.649838162085.issue15898@psf.upfronthosting.co.za> Message-ID: <1347243945.3.0.797663996169.issue15898@psf.upfronthosting.co.za> Ned Deily added the comment: I have not been able to reproduce the behavior you report using various Pythons on OS X 10.8 or on OS X 10.5. Can you give more specifics on the environment that fails for you? I certainly don't claim to have any experience with these tty/pty modules or with the underlying system calls and I'm not sure what you are trying to do here but isn't it a bit risky to be calling tty.tcsetattr() from both the parent and child processes simultaneously, since the call is after the fork? tcsetattr is dealing with a job-wide data structure and, under the covers, the tcsetattr() function currently reads and writes various field non-atomically. What happens if you move the tcgetattr and tcsetattr to before the os.fork call or into the parent-only code after the "else"? http://hg.python.org/cpython/file/default/Modules/termios.c ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 04:25:56 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 10 Sep 2012 02:25:56 +0000 Subject: [issue15893] Py_FrozenMain() resource leak and missing malloc checks In-Reply-To: <1347228598.43.0.424519630485.issue15893@psf.upfronthosting.co.za> Message-ID: <1347243956.91.0.600975197201.issue15893@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 04:26:19 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 10 Sep 2012 02:26:19 +0000 Subject: [issue15892] _PyImport_GetDynLoadFunc() doesn't check return value of fstat() In-Reply-To: <1347227762.77.0.329908285172.issue15892@psf.upfronthosting.co.za> Message-ID: <1347243979.38.0.14970112722.issue15892@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 04:28:15 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 10 Sep 2012 02:28:15 +0000 Subject: [issue15725] PyType_FromSpecWithBases bugfix In-Reply-To: <1345381967.41.0.932282182002.issue15725@psf.upfronthosting.co.za> Message-ID: <1347244095.59.0.97022588615.issue15725@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 04:29:28 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 10 Sep 2012 02:29:28 +0000 Subject: [issue15726] PyState_FindModule false length-comparison fix In-Reply-To: <1345382232.77.0.93004938409.issue15726@psf.upfronthosting.co.za> Message-ID: <1347244168.34.0.482069402866.issue15726@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Antoine, you applied a patch, but market this issue as "invalid". What that a mistake?. Should it be "closed"?. ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 04:30:06 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 10 Sep 2012 02:30:06 +0000 Subject: [issue15726] PyState_FindModule false length-comparison fix In-Reply-To: <1345382232.77.0.93004938409.issue15726@psf.upfronthosting.co.za> Message-ID: <1347244206.37.0.340941125623.issue15726@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: I meant "fixed". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 04:32:08 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 10 Sep 2012 02:32:08 +0000 Subject: [issue15727] PyType_FromSpecWithBases tp_new bugfix In-Reply-To: <1345391866.4.0.54341725267.issue15727@psf.upfronthosting.co.za> Message-ID: <1347244328.92.0.715200178426.issue15727@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 04:33:14 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 10 Sep 2012 02:33:14 +0000 Subject: [issue15695] Correct __sizeof__ support for StgDict In-Reply-To: <1345144416.71.0.984691068113.issue15695@psf.upfronthosting.co.za> Message-ID: <1347244393.99.0.2579062932.issue15695@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 04:33:21 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 10 Sep 2012 02:33:21 +0000 Subject: [issue15696] Correct __sizeof__ support for mmap In-Reply-To: <1345145499.47.0.489635799937.issue15696@psf.upfronthosting.co.za> Message-ID: <1347244401.88.0.150877878368.issue15696@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 04:42:20 2012 From: report at bugs.python.org (Andrew Moffat) Date: Mon, 10 Sep 2012 02:42:20 +0000 Subject: [issue15898] OSX TTY bug In-Reply-To: <1347238694.31.0.649838162085.issue15898@psf.upfronthosting.co.za> Message-ID: <1347244940.67.0.761365045318.issue15898@psf.upfronthosting.co.za> Andrew Moffat added the comment: If I move tcsetattr into the parent, the race condition still exists. If I move it into the child, before the write(), it works. My environment is OSX 10.7.2 inside of Virtualbox (maybe this is the problem?) I've shuffled some code around, and found case that fails consistently in python 3, but succeeds consistently on python 2.7. It doesn't use tcsetattr at all, which is making me realize the problem may be deeper than I originally thought. Are you able to confirm this, Ned? import os import pty import resource import signal import tty import time master, slave = pty.openpty() pid = os.fork() # child process if pid == 0: os.setsid() os.close(master) os.dup2(slave, 0) os.dup2(slave, 1) os.dup2(slave, 2) max_fd = resource.getrlimit(resource.RLIMIT_NOFILE)[0] os.closerange(3, max_fd) # make controlling terminal. taken from pty.fork tmp_fd = os.open(os.ttyname(1), os.O_RDWR) os.close(tmp_fd) os.write(1, "testing".encode()) os._exit(255) # parent process else: time.sleep(0.5) os.close(slave) try: print(os.read(master, 1024)) finally: os.kill(pid, signal.SIGKILL) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 04:46:41 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 10 Sep 2012 02:46:41 +0000 Subject: [issue15390] PEP 3121, 384 refactoring applied to datetime module In-Reply-To: <1342647232.82.0.0763290244077.issue15390@psf.upfronthosting.co.za> Message-ID: <1347245201.49.0.718958706554.issue15390@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: For some reason there are no review links, so I'll review in this message. Include/datetime.h +typedef struct { .. +} _datetimemodulestate; Names exposed in public headers (datetime.h is a public header) should start with Py or _Py. Other offenders include _datetimemodule_state, _datetimemodule, _datetimemodulestate_global. I don't think these names need to be defined in the header file at all. +typedef struct { + /* Forward declarations. */ + PyObject *PyDateTime_DateType; + PyObject *PyDateTime_DateTimeType; ... These are not forward declarations anymore. There is no need for PyDateTime_ prefix. Use names from PyDateTime_CAPI struct. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 04:56:50 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 10 Sep 2012 02:56:50 +0000 Subject: [issue15695] Correct __sizeof__ support for StgDict In-Reply-To: <1345144416.71.0.984691068113.issue15695@psf.upfronthosting.co.za> Message-ID: <1347245810.05.0.287946739367.issue15695@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: What is the point of providing a __sizeof__ method to a purely internal type? I don't think it is possible to expose StgDict at the python level. It is always hidden behind a mapping proxy. Furthemore, StgDict is only used inside type objects and the size of type objects is not relevant for __sizeof__ calculations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 05:05:35 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 10 Sep 2012 03:05:35 +0000 Subject: [issue15725] PyType_FromSpecWithBases bugfix In-Reply-To: <1345381967.41.0.932282182002.issue15725@psf.upfronthosting.co.za> Message-ID: <1347246335.96.0.34436707757.issue15725@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Why is this a problem? ISTM all that is happening is that null tp_base is set to null if Py_tp_base slot is specified as null. If this is somehow a problem - the user should not specify Py_tp_base slot. ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 05:17:59 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 10 Sep 2012 03:17:59 +0000 Subject: [issue15727] PyType_FromSpecWithBases tp_new bugfix In-Reply-To: <1345391866.4.0.54341725267.issue15727@psf.upfronthosting.co.za> Message-ID: <1347247079.55.0.231463590001.issue15727@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Can you give an example of the situation that you described? Perhaps you encountered it while refactoring some particular extension module. Which? In your patch new code is commented out. PySpec_New() is not a good name. It should be something like PyObject_FailingNew(). ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 05:19:34 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 10 Sep 2012 03:19:34 +0000 Subject: [issue15873] "datetime" cannot parse ISO 8601 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1347247174.4.0.357759337011.issue15873@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- assignee: -> belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 06:51:17 2012 From: report at bugs.python.org (Aaron) Date: Mon, 10 Sep 2012 04:51:17 +0000 Subject: [issue13212] json library is decoding/encoding when it should not In-Reply-To: <1318960832.41.0.586770861075.issue13212@psf.upfronthosting.co.za> Message-ID: <1347252676.97.0.502258640558.issue13212@psf.upfronthosting.co.za> Aaron added the comment: I think it's worth pointing out that both Firefox and Chrome support the non-standard JSON that Python supports (serializing and deserializing basic types). I'm guessing that communicating with web browsers is the vast majority of JSON IPC. That is to say, supporting the de-facto standard implemented by web browsers may be better than adhering to the exact specifications of the RFC. Maybe someone else wants to check what IE, Safari, Opera, and the various phone browsers allow as that might influece the discussion one way or another. ---------- nosy: +hac.man _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 08:23:01 2012 From: report at bugs.python.org (=?utf-8?q?Tomi_Pievil=C3=A4inen?=) Date: Mon, 10 Sep 2012 06:23:01 +0000 Subject: [issue15890] lib2to3 pickles created with wrong permissions In-Reply-To: <1347215226.9.0.69518719078.issue15890@psf.upfronthosting.co.za> Message-ID: <1347258181.67.0.722926318399.issue15890@psf.upfronthosting.co.za> Tomi Pievil?inen added the comment: > Tomi, do you find a different behavior in 3.2? No, the behaviour is the same in 2.6-3.2: no compiled files have permissions for other than root, and all non-compiled files do (because install is run with "-m 644"). What made me report this bug was that 3.3rc1 does not have this behaviour: while the pickles had a bad timestamp, the permissions were just fine, so I assumed that someone had changed the this intentionally. Also this hasn't been a problem in Python2.x. I can install 2.6.8 and 2.7.3 from source without fixing any permissions, and still have a working Python installation. 3.2.3 requires chmoding the lib2to3 pickles, but no other compiled files need to be touched (it seems that they aren't really needed). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 08:47:27 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 10 Sep 2012 06:47:27 +0000 Subject: [issue12947] doctest directive examples in library/doctest.html lack the flags In-Reply-To: <1315588954.16.0.979263107509.issue12947@psf.upfronthosting.co.za> Message-ID: <1347259647.05.0.255865878311.issue12947@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I discovered this today as well while reading the doctest documentation. One thing that I never noticed before (and that doesn't seem to be reflected in the comments above) is that many of the code snippet rectangles in the doctest documentation have a small rectangle in the upper-right corner with the text ">>>". If you click on one of these small rectangles, most of the text inside the code snippet rectangle disappears. I haven't confirmed this, but I suspect that it is the code snippets with a doctest directive that have this clickable corner. Is this a feature? What is it for? :) ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 08:55:04 2012 From: report at bugs.python.org (Ned Deily) Date: Mon, 10 Sep 2012 06:55:04 +0000 Subject: [issue15898] OSX TTY bug In-Reply-To: <1347238694.31.0.649838162085.issue15898@psf.upfronthosting.co.za> Message-ID: <1347260104.99.0.564462755899.issue15898@psf.upfronthosting.co.za> Ned Deily added the comment: Sorry, all I can tell you is that, for me, your test produces an empty string as output with either Python 2.7 or 3.3 and, if I remove the time.sleep() call or remove the os.close(slave), "testing" or b"testing" is output. I'm not sure what you believe the problem to be or what behavior you expect; you're covering a lot of ground here and much of it is very close to the OS. You are going to need to be a lot more specific than "OSX TTY bug". You should describe exactly what failing behavior you observe with what component of Python, 2. how to reproduce it, and 3. exactly what behavior you expect of that component, and 4. if possible, the results of testing on another supported platform. Otherwise, it will be very difficult to help. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 08:56:43 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 10 Sep 2012 06:56:43 +0000 Subject: [issue15676] mmap: add empty file check prior to offset check In-Reply-To: <3XFT4W3HL1zQZJ@mail.python.org> Message-ID: Charles-Fran?ois Natali added the comment: You forgot to add an entry in Misc/ACKS. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 09:27:07 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 10 Sep 2012 07:27:07 +0000 Subject: [issue15888] ipaddress doctest examples have some errors In-Reply-To: <1347190349.96.0.156720503481.issue15888@psf.upfronthosting.co.za> Message-ID: <1347262027.82.0.766282315954.issue15888@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attaching patch. The doctests for these three files now all pass (using a newer version of the patch I uploaded to issue 15629). ---------- keywords: +patch Added file: http://bugs.python.org/file27161/issue-15888-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 09:42:22 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 10 Sep 2012 07:42:22 +0000 Subject: [issue15898] OSX TTY bug In-Reply-To: <1347238694.31.0.649838162085.issue15898@psf.upfronthosting.co.za> Message-ID: <1347262942.08.0.533963656487.issue15898@psf.upfronthosting.co.za> Martin v. L?wis added the comment: If you want to analyse this further, please provide "dtruss -f" output of the script. Most likely, this is a glitch in the operating system, but not a bug in Python. Unless you can provide more details, or a patch, we are likely to close this issue as "works for me". ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 10:05:17 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 10 Sep 2012 08:05:17 +0000 Subject: [issue15629] Add to regrtest the ability to run Lib and Doc doctests In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1347264317.42.0.826696474506.issue15629@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I am attaching an updated version of the patch for feedback. The latest version of the patch I developed and used in the real-world example of fixing both the module and documentation file doctests for the ipaddress module (and its HOWTO) in issue 15888. The patch includes the following additional features: (1) the user is warned if a user-selected test file contains no tests (2) tests to run can be specified using one or more globs (e.g. fdoc:howto*) (3) the doc directory can be specified relatively (e.g. --docdir Doc) (4) passing --docall adds all doctests to the test run selection (5) passing --docunsafe runs doctests for all selected tests, whether or not the test files are marked "doctest safe" The patch also includes usage documentation towards the beginning. ---------- Added file: http://bugs.python.org/file27162/issue-15629-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 10:57:03 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 10 Sep 2012 08:57:03 +0000 Subject: [issue15726] PyState_FindModule false length-comparison fix In-Reply-To: <1345382232.77.0.93004938409.issue15726@psf.upfronthosting.co.za> Message-ID: <1347267423.61.0.850184502919.issue15726@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Oops, sorry, that was a mistake. ---------- resolution: invalid -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 11:01:56 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 10 Sep 2012 09:01:56 +0000 Subject: [issue15899] howto/unicode.rst doctest corrections Message-ID: <1347267716.91.0.310284408834.issue15899@psf.upfronthosting.co.za> New submission from Chris Jerdonek: This issue is to fix Doc/howto/unicode.rst so that its doctests pass when using the doctest module. Patch forthcoming. ---------- assignee: docs at python components: Documentation keywords: easy messages: 170167 nosy: cjerdonek, docs at python priority: normal severity: normal status: open title: howto/unicode.rst doctest corrections versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 11:05:33 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 10 Sep 2012 09:05:33 +0000 Subject: [issue15899] howto/unicode.rst doctest corrections In-Reply-To: <1347267716.91.0.310284408834.issue15899@psf.upfronthosting.co.za> Message-ID: <1347267933.09.0.504282046374.issue15899@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attaching patch for the default branch. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file27163/issue-15899-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 11:25:06 2012 From: report at bugs.python.org (Denis Bilenko) Date: Mon, 10 Sep 2012 09:25:06 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za> Message-ID: <1347269106.5.0.912392711558.issue15896@psf.upfronthosting.co.za> Changes by Denis Bilenko : ---------- nosy: +Denis.Bilenko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 11:31:35 2012 From: report at bugs.python.org (Christian Heimes) Date: Mon, 10 Sep 2012 09:31:35 +0000 Subject: [issue15895] PyRun_SimpleFileExFlags() can leak a FILE pointer In-Reply-To: <1347231050.54.0.0211027720618.issue15895@psf.upfronthosting.co.za> Message-ID: <1347269495.37.0.512777937767.issue15895@psf.upfronthosting.co.za> Christian Heimes added the comment: No, that's not possible. 'fp' is part of the argument to PyRun_SimpleFileExFlags() and never NULL. We need some way to distinguish a externally provided fp from a self-opened fp and fclose(fp) in the latter case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 11:37:20 2012 From: report at bugs.python.org (Matej Cepl) Date: Mon, 10 Sep 2012 09:37:20 +0000 Subject: [issue15873] "datetime" cannot parse ISO 8601 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1347269840.04.0.961075540513.issue15873@psf.upfronthosting.co.za> Changes by Matej Cepl : ---------- nosy: +mcepl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 11:58:22 2012 From: report at bugs.python.org (Christian Heimes) Date: Mon, 10 Sep 2012 09:58:22 +0000 Subject: [issue15900] Memory leak in PyUnicode_TranslateCharmap() Message-ID: <1347271102.51.0.468950657705.issue15900@psf.upfronthosting.co.za> New submission from Christian Heimes: Objects/unicodeobject.c:PyUnicode_TranslateCharmap() leaks a reference to the variable unicode. PyUnicode_Translate() is also implemented around the helper function _PyUnicode_TranslateCharmap() but it properly decrefs the reference to the first argument. PyUnicode_Translate() also has an obsolete onError goto label. The patch fixes the leak and simplifies PyUnicode_Translate(). CID 719686 ---------- components: Interpreter Core files: translate_leak.patch keywords: 3.3regression, patch messages: 170170 nosy: christian.heimes priority: normal severity: normal status: open title: Memory leak in PyUnicode_TranslateCharmap() type: resource usage versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file27164/translate_leak.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 11:59:39 2012 From: report at bugs.python.org (Simon R) Date: Mon, 10 Sep 2012 09:59:39 +0000 Subject: [issue15901] multiprocessing sharedctypes Array don't accept strings Message-ID: <1347271179.81.0.646236436369.issue15901@psf.upfronthosting.co.za> New submission from Simon R: I've simply tested the example reported in the py3k documentation, and it don't works. See the site: http://docs.python.org/py3k/library/multiprocessing.html?highlight=multiprocessing#module-multiprocessing.sharedctypes The program exit with this error: > python sha.py Traceback (most recent call last): File "sha.py", line 21, in s = Array('c', 'hello world', lock=lock) File "/usr/lib/python3.2/multiprocessing/sharedctypes.py", line 112, in Array obj = RawArray(typecode_or_type, size_or_initializer) File "/usr/lib/python3.2/multiprocessing/sharedctypes.py", line 89, in RawArray result.__init__(*size_or_initializer) TypeError: one character string expected Observe that the following code works correctly with python2! I'm using python 3.2.3 and gcc 4.7.1 under ArchLinx Te code is: http://docs.python.org/py3k/library/multiprocessing.html?highlight=multiprocessing#module-multiprocessing.sharedctypes #################################################################### from multiprocessing import Process, Lock from multiprocessing.sharedctypes import Value, Array from ctypes import Structure, c_double class Point(Structure): _fields_ = [('x', c_double), ('y', c_double)] def modify(n, x, s, A): n.value **= 2 x.value **= 2 s.value = s.value.upper() for a in A: a.x **= 2 a.y **= 2 if __name__ == '__main__': lock = Lock() n = Value('i', 7) x = Value(c_double, 1.0/3.0, lock=False) s = Array('c', 'hello world', lock=lock) A = Array(Point, [(1.875,-6.25), (-5.75,2.0), (2.375,9.5)], lock=lock) p = Process(target=modify, args=(n, x, s, A)) p.start() p.join() print((n.value)) print((x.value)) print((s.value)) print([(a.x, a.y) for a in A]) ---------- components: ctypes messages: 170171 nosy: bred priority: normal severity: normal status: open title: multiprocessing sharedctypes Array don't accept strings type: crash versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 12:18:21 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 10 Sep 2012 10:18:21 +0000 Subject: [issue15901] multiprocessing sharedctypes Array don't accept strings In-Reply-To: <1347271179.81.0.646236436369.issue15901@psf.upfronthosting.co.za> Message-ID: <1347272301.17.0.910547912235.issue15901@psf.upfronthosting.co.za> Richard Oudkerk added the comment: The documentation needs updating for Python 3 so that a byte string is used. So the line becomes s = Array('c', b'hello world', lock=lock) ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 12:31:57 2012 From: report at bugs.python.org (Simon) Date: Mon, 10 Sep 2012 10:31:57 +0000 Subject: [issue15901] multiprocessing sharedctypes Array don't accept strings In-Reply-To: <1347271179.81.0.646236436369.issue15901@psf.upfronthosting.co.za> Message-ID: <1347273117.03.0.59052729317.issue15901@psf.upfronthosting.co.za> Changes by Simon : ---------- assignee: -> docs at python components: +Documentation -ctypes nosy: +docs at python type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 12:43:44 2012 From: report at bugs.python.org (Paul Moore) Date: Mon, 10 Sep 2012 10:43:44 +0000 Subject: [issue15828] imp.load_module doesn't support C_EXTENSION type In-Reply-To: <1346398348.83.0.242228991466.issue15828@psf.upfronthosting.co.za> Message-ID: <1347273824.58.0.835401292428.issue15828@psf.upfronthosting.co.za> Paul Moore added the comment: The applied fix appears to have a regression - the file argument is not allowed to be None. The pywin32 post-install script calls imp.load_module for a C extension with file=None, so presumably this worked in earlier versions. The regression breaks the postinstall script for pywin32, meaning that the start menu shortcuts do not get installed. I do not know if it has any more serious consequences for pywin32. ---------- nosy: +pmoore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 12:47:51 2012 From: report at bugs.python.org (Tim Golden) Date: Mon, 10 Sep 2012 10:47:51 +0000 Subject: [issue15828] imp.load_module doesn't support C_EXTENSION type In-Reply-To: <1347273824.58.0.835401292428.issue15828@psf.upfronthosting.co.za> Message-ID: <504DC554.1040908@timgolden.me.uk> Tim Golden added the comment: Paul, are you using the hg tip of pywin32? pywin32_postintall.py was patched a couple of months ago to use imp.load_dynamic (essentially to work around this issue). ---------- nosy: +tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 13:30:48 2012 From: report at bugs.python.org (Paul Moore) Date: Mon, 10 Sep 2012 11:30:48 +0000 Subject: [issue15828] imp.load_module doesn't support C_EXTENSION type In-Reply-To: <504DC554.1040908@timgolden.me.uk> Message-ID: Paul Moore added the comment: On 10 September 2012 11:47, Tim Golden wrote: > > Tim Golden added the comment: > > Paul, are you using the hg tip of pywin32? pywin32_postintall.py was > patched a couple of months ago to use imp.load_dynamic (essentially to > work around this issue). No, this is the 217 release. Looks like they may need a new release then... Paul ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 13:49:09 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 10 Sep 2012 11:49:09 +0000 Subject: [issue15828] imp.load_module doesn't support C_EXTENSION type In-Reply-To: Message-ID: Nick Coghlan added the comment: Paul, could you please report that issue/question separately? If it's a regression, it's likely in the importlib migration in general and was hidden by this bug rather than being introduced by the fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 14:01:16 2012 From: report at bugs.python.org (Gilles Louppe) Date: Mon, 10 Sep 2012 12:01:16 +0000 Subject: [issue7358] cStringIO not 64-bit safe In-Reply-To: <1258645822.27.0.150067328286.issue7358@psf.upfronthosting.co.za> Message-ID: <1347278476.44.0.0202854335673.issue7358@psf.upfronthosting.co.za> Gilles Louppe added the comment: Hi, Any solution regarding that issue? We are currently encountering the exact same bug when pickling too large objects. Best, Gilles ---------- nosy: +Gilles.Louppe _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 14:04:49 2012 From: report at bugs.python.org (Paul Moore) Date: Mon, 10 Sep 2012 12:04:49 +0000 Subject: [issue15902] imp.load_module won't accept None for the file argument for a C extension Message-ID: <1347278689.78.0.295593798435.issue15902@psf.upfronthosting.co.za> New submission from Paul Moore: imp.load_module appears to have a regression - the file argument is not allowed to be None when loading a C_EXTENSION. The pywin32 post-install script for version 217 calls imp.load_module for a C extension with file=None, so presumably this worked in earlier versions. Note that apparently pywin32 tip no longer calls load_module in this way, and load_module is marked as deprecated in the documentation, so it is not clear if this issue actually needs fixing. See #15828 for some background. ---------- components: Library (Lib) keywords: 3.3regression messages: 170178 nosy: brett.cannon, georg.brandl, ncoghlan, pmoore priority: normal severity: normal status: open title: imp.load_module won't accept None for the file argument for a C extension type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 14:05:34 2012 From: report at bugs.python.org (Paul Moore) Date: Mon, 10 Sep 2012 12:05:34 +0000 Subject: [issue15828] imp.load_module doesn't support C_EXTENSION type In-Reply-To: <1346398348.83.0.242228991466.issue15828@psf.upfronthosting.co.za> Message-ID: <1347278734.05.0.0949614661793.issue15828@psf.upfronthosting.co.za> Paul Moore added the comment: Logged as #15902. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 14:06:01 2012 From: report at bugs.python.org (Roy Smith) Date: Mon, 10 Sep 2012 12:06:01 +0000 Subject: [issue15873] "datetime" cannot parse ISO 8601 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1347278761.23.0.235221088658.issue15873@psf.upfronthosting.co.za> Roy Smith added the comment: I've started collecting some test cases. I'll keep adding to the collection. I'm going to start trolling ISO 8601:2004(E) for more. Let me know if there are other sources I should be considering. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 14:07:49 2012 From: report at bugs.python.org (Roy Smith) Date: Mon, 10 Sep 2012 12:07:49 +0000 Subject: [issue15873] "datetime" cannot parse ISO 8601 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1347278869.44.0.093163212445.issue15873@psf.upfronthosting.co.za> Roy Smith added the comment: Ooops, clicked the wrong button. ---------- Added file: http://bugs.python.org/file27165/test-cases.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 14:08:02 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 10 Sep 2012 12:08:02 +0000 Subject: [issue15901] multiprocessing sharedctypes Array don't accept strings In-Reply-To: <1347271179.81.0.646236436369.issue15901@psf.upfronthosting.co.za> Message-ID: <3XFp1F4WjfzQfW@mail.python.org> Roundup Robot added the comment: New changeset ddb406904be1 by Richard Oudkerk in branch '3.2': Issue #15901: Change example to use byte string instead of string http://hg.python.org/cpython/rev/ddb406904be1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 14:09:27 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 10 Sep 2012 12:09:27 +0000 Subject: [issue15901] multiprocessing sharedctypes Array don't accept strings In-Reply-To: <1347271179.81.0.646236436369.issue15901@psf.upfronthosting.co.za> Message-ID: <1347278967.83.0.286069300226.issue15901@psf.upfronthosting.co.za> Changes by Richard Oudkerk : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 14:23:03 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 10 Sep 2012 12:23:03 +0000 Subject: [issue15903] Make rawiobase_read() read directly to bytes object Message-ID: <1347279783.86.0.217898740398.issue15903@psf.upfronthosting.co.za> New submission from Richard Oudkerk: Currently rawiobase_read() reads to a bytearray object and then copies the data to a bytes object. There is a TODO comment saying that the bytes object should be created directly. The attached patch does that. ---------- files: iobase_read.patch keywords: patch messages: 170183 nosy: sbt priority: normal severity: normal status: open title: Make rawiobase_read() read directly to bytes object Added file: http://bugs.python.org/file27166/iobase_read.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 14:30:52 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 10 Sep 2012 12:30:52 +0000 Subject: [issue12947] doctest directive examples in library/doctest.html lack the flags In-Reply-To: <1315588954.16.0.979263107509.issue12947@psf.upfronthosting.co.za> Message-ID: <1347280252.18.0.66203011555.issue12947@psf.upfronthosting.co.za> Ezio Melotti added the comment: > Is this a feature? What is it for? :) The >>> is added to every example that contains an interactive session to hide the '>>>' and '...' prompts and the output and make the code copy/pastable, and it's not specific to doctests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 15:01:50 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 10 Sep 2012 13:01:50 +0000 Subject: [issue15902] imp.load_module won't accept None for the file argument for a C extension In-Reply-To: <1347278689.78.0.295593798435.issue15902@psf.upfronthosting.co.za> Message-ID: <1347282110.88.0.0576769297539.issue15902@psf.upfronthosting.co.za> Brett Cannon added the comment: How can you load a C extension without a file path? Are C extensions being inappropriately flagged as built-in modules on Windows? What does imp.find_module() return for the module being checked? I need more debugging info on what imp.find_module() and imp.load_module() returns in 3.2 and 3.3 before I can make a call on where the actual breakage is. ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 15:03:23 2012 From: report at bugs.python.org (Paul Moore) Date: Mon, 10 Sep 2012 13:03:23 +0000 Subject: [issue15902] imp.load_module won't accept None for the file argument for a C extension In-Reply-To: <1347282110.88.0.0576769297539.issue15902@psf.upfronthosting.co.za> Message-ID: Paul Moore added the comment: It's the open file object argument, not the path. I assume that if you supplied None, the code opened the file for you. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 15:07:59 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 10 Sep 2012 13:07:59 +0000 Subject: [issue15881] multiprocessing 'NoneType' object is not callable In-Reply-To: <1347044200.13.0.235512745295.issue15881@psf.upfronthosting.co.za> Message-ID: <1347282479.97.0.889385312068.issue15881@psf.upfronthosting.co.za> Richard Oudkerk added the comment: I see the same error on Windows (when pressing ^C), but on Linux I get Error in sys.exitfunc: Traceback (most recent call last): File "/usr/lib/python2.7/atexit.py", line 28, in _run_exitfuncs import traceback File "/usr/lib/python2.7/traceback.py", line 3, in import linecache File "/usr/lib/python2.7/linecache.py", line 9, in import os File "/usr/lib/python2.7/os.py", line 119, in sys.modules['os.path'] = path AttributeError: 'module' object has no attribute 'modules' This also suggests that module teardown has begun before/while sys.exitfunc is running. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 16:16:38 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 10 Sep 2012 14:16:38 +0000 Subject: [issue15904] file,close() can fail assert on Windows in 2.7 Message-ID: <1347286598.53.0.580767825859.issue15904@psf.upfronthosting.co.za> New submission from Richard Oudkerk: With Python 2.7 on Windows the following crashes with an assertion: >>> import os [43042 refs] >>> f = open("foobar", "wb") [43048 refs] >>> os.close(f.fileno()) [43048 refs] >>> f.close() A box pops up with Program: C:\Repos\cpython-27\PCbuild\python_d.exe File: f:\dd\vctools\crt_bld\self_x86\crt\src\close.c Line: 48 Expression: (_osfile(fh) & FOPEN) Python 3.2 and 3.3 give IOError(EBADF, ...) as expected. Compare #15261 and #15263. ---------- messages: 170188 nosy: sbt priority: normal severity: normal stage: needs patch status: open title: file,close() can fail assert on Windows in 2.7 type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 16:17:32 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 10 Sep 2012 14:17:32 +0000 Subject: [issue14649] doctest.DocTestSuite error misleading when module has no docstrings In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za> Message-ID: <3XFrtg4VKnzM0Q@mail.python.org> Roundup Robot added the comment: New changeset d012f645b8b2 by R David Murray in branch '3.2': #14649: clarify DocTestSuite error when there are no docstrings. http://hg.python.org/cpython/rev/d012f645b8b2 New changeset 6544fc92b528 by R David Murray in branch 'default': Merge #14649: clarify DocTestSuite error when there are no docstrings. http://hg.python.org/cpython/rev/6544fc92b528 New changeset b48ef168d8c5 by R David Murray in branch '2.7': #14649: clarify DocTestSuite error when there are no docstrings. http://hg.python.org/cpython/rev/b48ef168d8c5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 16:19:40 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 10 Sep 2012 14:19:40 +0000 Subject: [issue14649] doctest.DocTestSuite error misleading when module has no docstrings In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za> Message-ID: <1347286780.09.0.943160780847.issue14649@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Chris. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 16:32:46 2012 From: report at bugs.python.org (Eric Snow) Date: Mon, 10 Sep 2012 14:32:46 +0000 Subject: [issue15891] A public facing API for __unittest = True In-Reply-To: <1347217684.87.0.845437270023.issue15891@psf.upfronthosting.co.za> Message-ID: <1347287566.0.0.380460469554.issue15891@psf.upfronthosting.co.za> Eric Snow added the comment: yeah, I keep thinking we need a better API for managing tracebacks. One of these days... ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 16:44:08 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 10 Sep 2012 14:44:08 +0000 Subject: [issue15904] file,close() can fail assert on Windows in 2.7 In-Reply-To: <1347286598.53.0.580767825859.issue15904@psf.upfronthosting.co.za> Message-ID: <1347288248.3.0.726604114095.issue15904@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Is it also the case for other file operations? Here is a list that may use a closed FILE object: f.write('something') f.read(1) print >>f, 'something' f.seek(0) f.tell() f.truncate(0) f.flush() f.isatty() f.readlines() f.writelines(['x']) list(f) ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 16:53:06 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 10 Sep 2012 14:53:06 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za> Message-ID: <1347288786.8.0.891403529442.issue15896@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Looks like - another - OS-X bug. What happens if you reduce the size argument when reading from the error pipe? Try setting it to a value like 512 (minimum guaranteed PIPE_BUF): """ newData = os.read(errpipe_read, min(512, rSize)) """ You could also try to put a short sleep before exiting the child process (after pickling the exception) to see what happens if the reader reads before the pipe is closed by the other end (that would be a huge bug, but hey, who knows...). ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 16:56:36 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 10 Sep 2012 14:56:36 +0000 Subject: [issue13212] json library is decoding/encoding when it should not In-Reply-To: <1318960832.41.0.586770861075.issue13212@psf.upfronthosting.co.za> Message-ID: <1347288996.29.0.298538184159.issue13212@psf.upfronthosting.co.za> ?ric Araujo added the comment: > I don't think it should be called "strict" though, as that would imply that we comply with RFC 4627 strictly > (which is not true without passing allow_nan=False for dump() or passing a parse_constant function for load()) What if the strict mode implied both of these things? FWIW, I?m +1 for a doc section about how to achieve strict mode with special arguments and callbacks (if the recent doc patch does not already have that), and +0 on adding it to the code itself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 16:57:24 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 10 Sep 2012 14:57:24 +0000 Subject: [issue15904] file,close() can fail assert on Windows in 2.7 In-Reply-To: <1347286598.53.0.580767825859.issue15904@psf.upfronthosting.co.za> Message-ID: <1347289044.38.0.323250319987.issue15904@psf.upfronthosting.co.za> Richard Oudkerk added the comment: If buffering is off then they all fail the assertion except isatty(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 17:08:40 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 10 Sep 2012 15:08:40 +0000 Subject: [issue15419] distutils: build should use a version-specific build directory In-Reply-To: <1342945976.47.0.537572255215.issue15419@psf.upfronthosting.co.za> Message-ID: <1347289720.15.0.939545761725.issue15419@psf.upfronthosting.co.za> ?ric Araujo added the comment: > It seems to me this is just a special case of the more general issue of building multiple versions of the > same distribution, say with multiple versions of Python 2. In general, anytime you change your build > environment, you should start with no existing build directory. Maybe Distutils could do that for you. > Distutils doesn't keep track of every change you might make in a build environment between invocations > of setup.py. Could you detail what you mean with ?change in a build environment?? Timestamps are tracked, C headers dependencies too, changes to setup.py (and maybe setup.cfg too), so I think it wouldn?t be a stretch to also track the Python version used to run setup.py. On the other hand, even with the same version there can be differences in the command-line options, the available modules (using Pythons with the same version from different virtual environments), etc. Anyway, using one build directory per version (X.Y.Z) could easily solve a part of these issues. What do people think? ---------- title: distutils: build_py_2to3 should use a separate build directory -> distutils: build should use a version-specific build directory versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 17:20:58 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 10 Sep 2012 15:20:58 +0000 Subject: [issue14649] doctest.DocTestSuite error misleading when module has no docstrings In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za> Message-ID: <3XFtHs1PrvzQhj@mail.python.org> Roundup Robot added the comment: New changeset c5fc49bc7a5f by R David Murray in branch '2.7': #14649: add sample files omitted from previous checkin. http://hg.python.org/cpython/rev/c5fc49bc7a5f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 18:04:02 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 10 Sep 2012 16:04:02 +0000 Subject: [issue15902] imp.load_module won't accept None for the file argument for a C extension In-Reply-To: <1347278689.78.0.295593798435.issue15902@psf.upfronthosting.co.za> Message-ID: <1347293042.6.0.334060983539.issue15902@psf.upfronthosting.co.za> Brett Cannon added the comment: Well, that's extremely annoying as that doesn't work for .py or .pyc files:: >>> import imp >>> stuff = imp.find_module('blah') >>> stuff (<_io.TextIOWrapper name=4 mode='U' encoding='utf-8'>, 'blah.py', ('.py', 'U', 1)) >>> stuff[0].close() >>> imp.load_module('blah', None, 'blah.py', stuff[2]) Traceback (most recent call last): File "", line 1, in ValueError: file object required for import (type code 1) I really hate these functions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 18:04:19 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 10 Sep 2012 16:04:19 +0000 Subject: [issue15902] imp.load_module won't accept None for the file argument for a C extension In-Reply-To: <1347278689.78.0.295593798435.issue15902@psf.upfronthosting.co.za> Message-ID: <1347293059.75.0.523586021337.issue15902@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 18:08:55 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 10 Sep 2012 16:08:55 +0000 Subject: [issue14649] doctest.DocTestSuite error misleading when module has no docstrings In-Reply-To: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za> Message-ID: <1347293335.81.0.174395221876.issue14649@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks a lot, David. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 18:09:46 2012 From: report at bugs.python.org (Christian Heimes) Date: Mon, 10 Sep 2012 16:09:46 +0000 Subject: [issue15905] Copy to fixed size buffer w/o check in sys_update_path Message-ID: <1347293386.49.0.00561600810364.issue15905@psf.upfronthosting.co.za> New submission from Christian Heimes: In Python/sysmodule.c the function sys_update_path() uses wcscpy to copy data to a fixed size buffer. The input comes from an external source (argv[0]) and could theoretically be larger than the buffer. Suggested solution: Increase the buffer a bit: wchar_t argv0copy[sizeof(wchar_t)* (MAXPATHLEN+1)]; and use wcsncpy: wcsncpy(argv0copy, argv0, MAXPATHLEN); argv0copy[MAXPATHLEN] = L'\0'; CID 486850 ---------- components: Interpreter Core messages: 170200 nosy: christian.heimes priority: normal severity: normal stage: needs patch status: open title: Copy to fixed size buffer w/o check in sys_update_path type: behavior versions: Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 18:15:51 2012 From: report at bugs.python.org (Christian Heimes) Date: Mon, 10 Sep 2012 16:15:51 +0000 Subject: [issue15905] Copy to fixed size buffer w/o check in sys_update_path In-Reply-To: <1347293386.49.0.00561600810364.issue15905@psf.upfronthosting.co.za> Message-ID: <1347293751.28.0.772476658542.issue15905@psf.upfronthosting.co.za> Christian Heimes added the comment: search_for_prefix() and search_for_exec_prefix() contain similar code. CID 486612 CID 486611 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 18:35:13 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 10 Sep 2012 16:35:13 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default=[], action='append' Message-ID: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> New submission from Barry A. Warsaw: Run the following code snippet: -----snip snip----- import argparse parser = argparse.ArgumentParser() parser.add_argument("--test", dest="test", type=str, default=[], action='append') args = parser.parse_args() print args.test, repr(args.test) -----snip snip----- In Python 3.3 (with the appropriate syntactic changes), args.test is clearly a list. In Python 2.7 and 3.2, args.test is the string "[]". I can't tell from reading the docs what the expected value should be, but intuitively, the Python 3.3 behavior makes the most sense, i.e. that args.test is a list, not the string representation of a list! Removing type=str from add_argument() "fixes" the value, but that doesn't seem right because str is the default type so that should have no effect. We discovered this when we tried to do args.test.append('foo') and tracebacked because args.test wasn't a list. Original bug report in Ubuntu: https://launchpad.net/bugs/1048710 but I've tested this with upstream hg head for 2.7, 3.2, and 3.3. It works in Ubuntu's 3.3rc2 but not in upstream head 3.3rc2+, so from reading Misc/NEWS I think the fix for issue #12776 and issue #11839 might be involved. ---------- messages: 170202 nosy: barry priority: normal severity: normal status: open title: argparse add_argument() confusing behavior when type=str, default=[], action='append' versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 18:39:10 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 10 Sep 2012 16:39:10 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default=[], action='append' In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347295150.67.0.706939653283.issue15906@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +benjamin.peterson, georg.brandl priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 18:39:44 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 10 Sep 2012 16:39:44 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default=[], action='append' In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347295184.69.0.41889302207.issue15906@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Marking it as a release blocker and adding 3.3 since 3.3 hg trunk is affected. ---------- versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 19:00:59 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 10 Sep 2012 17:00:59 +0000 Subject: [issue15907] move doctest test-data files into a subdirectory of Lib/test Message-ID: <1347296459.35.0.660655246065.issue15907@psf.upfronthosting.co.za> New submission from Chris Jerdonek: doctest currently has 8 "data" files used for testing that are spread across Lib/test (in addition to the main test files test_doctest.py and test_doctest2.py): doctest_aliases.py sample_doctest.py sample_doctest_no_docstrings.py sample_doctest_no_doctests.py test_doctest.txt test_doctest2.txt test_doctest3.txt test_doctest4.txt This issue is to move these files into a common subdirectory of Lib/test (e.g. Lib/test/doctest). This will simplify the organization of doctest's tests (e.g. by making the supporting files easier to discover) and reduce clutter in the main test directory. Note that test_zipimport_support (and perhaps also test_pyclbr) will also require changes. This issue came out of discussions with R. David Murray in the context of working on issue 14649. ---------- components: Library (Lib), Tests messages: 170204 nosy: cjerdonek, r.david.murray priority: normal severity: normal status: open title: move doctest test-data files into a subdirectory of Lib/test versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 19:08:59 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 10 Sep 2012 17:08:59 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default=[], action='append' In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347296939.12.0.581281974534.issue15906@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +bethard _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 19:20:18 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 10 Sep 2012 17:20:18 +0000 Subject: [issue15899] howto/unicode.rst doctest corrections In-Reply-To: <1347267716.91.0.310284408834.issue15899@psf.upfronthosting.co.za> Message-ID: <1347297618.13.0.135204610284.issue15899@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- versions: +Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 19:21:00 2012 From: report at bugs.python.org (Georg Brandl) Date: Mon, 10 Sep 2012 17:21:00 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default=[], action='append' In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347297660.04.0.285328772518.issue15906@psf.upfronthosting.co.za> Georg Brandl added the comment: I don't see how this affects 3.3: you seem to be saying the behavior is fine there. ---------- versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 19:24:00 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 10 Sep 2012 17:24:00 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347297660.04.0.285328772518.issue15906@psf.upfronthosting.co.za> Message-ID: <20120910132356.15eb2de6@resist.wooz.org> Barry A. Warsaw added the comment: On Sep 10, 2012, at 05:21 PM, Georg Brandl wrote: >I don't see how this affects 3.3: you seem to be saying the behavior is fine >there. No, I thought it was because I tested the Ubuntu rc2 version, but the problem exists in upstream hg 3.3rc2+ head. ---------- title: argparse add_argument() confusing behavior when type=str, default=[], action='append' -> argparse add_argument() confusing behavior when type=str, default= _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 19:25:26 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 10 Sep 2012 17:25:26 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347297926.58.0.350238822786.issue15906@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 19:42:06 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 10 Sep 2012 17:42:06 +0000 Subject: [issue15882] _decimal.Decimal constructed from tuple In-Reply-To: <1347058075.63.0.395926246222.issue15882@psf.upfronthosting.co.za> Message-ID: <3XFxQj143szQgp@mail.python.org> Roundup Robot added the comment: New changeset 97e53273f423 by Stefan Krah in branch 'default': Issue #15882: Change _decimal to accept any coefficient tuple when http://hg.python.org/cpython/rev/97e53273f423 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 19:58:01 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 10 Sep 2012 17:58:01 +0000 Subject: [issue15895] PyRun_SimpleFileExFlags() can leak a FILE pointer In-Reply-To: <1347231050.54.0.0211027720618.issue15895@psf.upfronthosting.co.za> Message-ID: <1347299881.53.0.539540690619.issue15895@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Look good to me, then. Are you committing the patch yourself?. You can patch 2.7, 3.2 and default, and bug Georg for 3.3.0 inclusion (patches to default will be in 3.3.1), unless Georg is notified and chooses to cherry pick it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 19:59:24 2012 From: report at bugs.python.org (Georg Brandl) Date: Mon, 10 Sep 2012 17:59:24 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347299964.31.0.400310264593.issue15906@psf.upfronthosting.co.za> Georg Brandl added the comment: But it's not a release blocker for 3.3 then. ---------- priority: release blocker -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 20:01:46 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 10 Sep 2012 18:01:46 +0000 Subject: [issue15903] Make rawiobase_read() read directly to bytes object In-Reply-To: <1347279783.86.0.217898740398.issue15903@psf.upfronthosting.co.za> Message-ID: <1347300106.41.0.202475139125.issue15903@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea stage: -> patch review versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 20:05:51 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 10 Sep 2012 18:05:51 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347299964.31.0.400310264593.issue15906@psf.upfronthosting.co.za> Message-ID: <20120910140548.00fa1b90@resist.wooz.org> Barry A. Warsaw added the comment: On Sep 10, 2012, at 05:59 PM, Georg Brandl wrote: >But it's not a release blocker for 3.3 then. Fair enough! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 20:10:05 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 10 Sep 2012 18:10:05 +0000 Subject: [issue15900] Memory leak in PyUnicode_TranslateCharmap() In-Reply-To: <1347271102.51.0.468950657705.issue15900@psf.upfronthosting.co.za> Message-ID: <1347300605.62.0.604255022924.issue15900@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Looks good to me. Are 2.7/3.2 not affected?. Christian, Please, commit the patch and notify Georg for 3.3.0 inclusion. ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 20:20:18 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 10 Sep 2012 18:20:18 +0000 Subject: [issue15676] mmap: add empty file check prior to offset check In-Reply-To: <1345052794.26.0.230448790651.issue15676@psf.upfronthosting.co.za> Message-ID: <3XFyGn53P1zQ4M@mail.python.org> Roundup Robot added the comment: New changeset 9ed2e8307e60 by Jesus Cea in branch '2.7': #15676: Proper attribution in Misc/ACKS http://hg.python.org/cpython/rev/9ed2e8307e60 New changeset 4f21f7532038 by Jesus Cea in branch '3.2': #15676: Proper attribution in Misc/ACKS http://hg.python.org/cpython/rev/4f21f7532038 New changeset 4fdc6c501e63 by Jesus Cea in branch 'default': MERGE: #15676: Proper attribution in Misc/ACKS http://hg.python.org/cpython/rev/4fdc6c501e63 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 20:36:34 2012 From: report at bugs.python.org (Nat Hillard) Date: Mon, 10 Sep 2012 18:36:34 +0000 Subject: [issue15874] argparse cannot parse shell variable arguments in file-given arguments In-Reply-To: <1346976291.75.0.854427077128.issue15874@psf.upfronthosting.co.za> Message-ID: <1347302194.28.0.428645718558.issue15874@psf.upfronthosting.co.za> Nat Hillard added the comment: Thank you, everyone. Defining a new type for this is just what I needed. No additional modifications are necessary on top of this new type. ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 20:39:12 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 10 Sep 2012 18:39:12 +0000 Subject: [issue15908] SHA1 crashes in 64 bits when the string to hash is Message-ID: <1347302352.79.0.333687005709.issue15908@psf.upfronthosting.co.za> New submission from Jes?s Cea Avi?n: #14888 solves this for MD5, but SHA1 is affected too. ---------- assignee: jcea messages: 170214 nosy: jcea, pitrou priority: normal severity: normal status: open title: SHA1 crashes in 64 bits when the string to hash is versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 20:41:46 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 10 Sep 2012 18:41:46 +0000 Subject: [issue15881] multiprocessing 'NoneType' object is not callable In-Reply-To: <1347044200.13.0.235512745295.issue15881@psf.upfronthosting.co.za> Message-ID: <1347302506.46.0.238881614726.issue15881@psf.upfronthosting.co.za> Richard Oudkerk added the comment: I suspect the problem is caused by nose's isolate plugin. With this enabled, a copy of sys.modules is saved before each test and then restored after the test. This causes garbage collection of newly imported modules. The destructor for the module type causes all globals to be replaced by None. This will break the atexit function registered by multiprocessing since it depends on globals. PS. A simple work-around (which does not require people to upgrade to a bugfixed version of Python) is to put try: import multiprocessing except ImportError: pass near the beginning of setup.py. After this change I don't get the error when running "python setup.py test". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 20:47:54 2012 From: report at bugs.python.org (Andrew Moffat) Date: Mon, 10 Sep 2012 18:47:54 +0000 Subject: [issue15898] OSX TTY bug In-Reply-To: <1347238694.31.0.649838162085.issue15898@psf.upfronthosting.co.za> Message-ID: <1347302874.66.0.533532232098.issue15898@psf.upfronthosting.co.za> Andrew Moffat added the comment: @Ned, Ok, give me a little time to work up those suggestions. On my machine, the previous script prints "testing" consistently on 2.7, "" consistently on 3.2. I guess this is the behavior that is unexpected...it should print the same thing for both versions. But if you are unable to confirm it, that's no good. Let me work on this a little more before you guys close this. @Martin, Thanks for the tip. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 20:56:48 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 10 Sep 2012 18:56:48 +0000 Subject: [issue15909] test_mmap failure on Windows buildbots Message-ID: <1347303408.84.0.405583449019.issue15909@psf.upfronthosting.co.za> New submission from Stefan Krah: All Windows bots have multiple failures in test_mmap: ====================================================================== ERROR: test_entire_file (test.test_mmap.MmapTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "E:\Data\buildslave\cpython\3.x.snakebite-win2k3r2sp2-x86\build\lib\test\test_mmap.py", line 19, in setUp os.unlink(TESTFN) PermissionError: [WinError 32] The process cannot access the file because it is being used by another process: '@test_8132_tmp' ====================================================================== ERROR: test_error (test.test_mmap.MmapTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "E:\Data\buildslave\cpython\3.x.snakebite-win2k3r2sp2-x86\build\lib\test\test_mmap.py", line 19, in setUp os.unlink(TESTFN) PermissionError: [WinError 32] The process cannot access the file because it is being used by another process: '@test_8132_tmp' [...] ---------- components: Tests messages: 170217 nosy: skrah priority: normal severity: normal stage: needs patch status: open title: test_mmap failure on Windows buildbots type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 20:59:19 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 10 Sep 2012 18:59:19 +0000 Subject: [issue15908] SHA1 crashes in 64 bits when the string to hash is bigger than 2**32 bytes In-Reply-To: <1347302352.79.0.333687005709.issue15908@psf.upfronthosting.co.za> Message-ID: <1347303559.43.0.959518641991.issue15908@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- title: SHA1 crashes in 64 bits when the string to hash is -> SHA1 crashes in 64 bits when the string to hash is bigger than 2**32 bytes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 21:04:58 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 10 Sep 2012 19:04:58 +0000 Subject: [issue15908] SHA1 crashes in 64 bits when the string to hash is bigger than 2**32 bytes In-Reply-To: <1347302352.79.0.333687005709.issue15908@psf.upfronthosting.co.za> Message-ID: <3XFzGK1KtVzQD6@mail.python.org> Roundup Robot added the comment: New changeset a13bfc238f27 by Jesus Cea in branch '2.7': Closes #15908: SHA1 crashes in 64 bits when the string to hash is bigger than 2**32 bytes http://hg.python.org/cpython/rev/a13bfc238f27 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 21:20:56 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 10 Sep 2012 19:20:56 +0000 Subject: [issue15910] MD5 and SHA1 crash when "updated" with strings bigger than 2**32 bytes Message-ID: <1347304856.87.0.716554283125.issue15910@psf.upfronthosting.co.za> New submission from Jes?s Cea Avi?n: #14888 and #15908 solve the issue for "hash.new()", but "hash.update()" is failing too. ---------- assignee: jcea messages: 170219 nosy: jcea, pitrou priority: normal severity: normal status: open title: MD5 and SHA1 crash when "updated" with strings bigger than 2**32 bytes versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 21:23:02 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 10 Sep 2012 19:23:02 +0000 Subject: [issue15902] imp.load_module won't accept None for the file argument for a C extension In-Reply-To: <1347278689.78.0.295593798435.issue15902@psf.upfronthosting.co.za> Message-ID: <1347304982.74.0.792208414095.issue15902@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 21:23:33 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 10 Sep 2012 19:23:33 +0000 Subject: [issue15881] multiprocessing 'NoneType' object is not callable In-Reply-To: <1347044200.13.0.235512745295.issue15881@psf.upfronthosting.co.za> Message-ID: <1347305013.93.0.971477680426.issue15881@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Actually, I am not so sure it is the isolate plugin. But I do think that sys.modules is being manipulated somewhere before shutdown. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 21:30:36 2012 From: report at bugs.python.org (Jean-Paul Calderone) Date: Mon, 10 Sep 2012 19:30:36 +0000 Subject: [issue15911] Debugging import problems is hard Message-ID: <1347305436.8.0.778141669429.issue15911@psf.upfronthosting.co.za> New submission from Jean-Paul Calderone: Debugging problems involving the frozen importlib._bootstrap is difficult, because the source for importlib._bootstrap is not available to pdb. The bootstrap code can be stepped through, but with only function names and line numbers available, not source lines. The value of having importlib written in Python would be greatly enhanced if it were more like a regular Python module that, eg, pdb could display source lines from. ---------- components: Interpreter Core, Library (Lib) messages: 170221 nosy: exarkun priority: normal severity: normal status: open title: Debugging import problems is hard versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 21:39:26 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 10 Sep 2012 19:39:26 +0000 Subject: [issue15910] MD5 and SHA1 crash when "updated" with strings bigger than 2**32 bytes In-Reply-To: <1347304856.87.0.716554283125.issue15910@psf.upfronthosting.co.za> Message-ID: <3XG02540FdzQFd@mail.python.org> Roundup Robot added the comment: New changeset 4d36e56b56d9 by Jesus Cea in branch '2.7': Closes #15910: MD5 and SHA1 crash when "updated" with strings bigger than 2**32 bytes http://hg.python.org/cpython/rev/4d36e56b56d9 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 21:41:17 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 10 Sep 2012 19:41:17 +0000 Subject: [issue11943] Add TLS-SRP (RFC 5054) support to ssl, _ssl, http, and urllib In-Reply-To: <1303943331.28.0.343800117154.issue11943@psf.upfronthosting.co.za> Message-ID: <1347306077.6.0.292329621079.issue11943@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Ping!. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 21:42:32 2012 From: report at bugs.python.org (Eric Snow) Date: Mon, 10 Sep 2012 19:42:32 +0000 Subject: [issue15911] Debugging import problems is hard In-Reply-To: <1347305436.8.0.778141669429.issue15911@psf.upfronthosting.co.za> Message-ID: <1347306152.03.0.676754363267.issue15911@psf.upfronthosting.co.za> Eric Snow added the comment: This comes back to #14657, which addressed the frozen vs. non-frozen copies of importlib. It sounds like one useful solution for your situation would be for _frozen_importlib to be used only long enough for bootstrap purposes. This was discussed in that other issue. ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 21:48:08 2012 From: report at bugs.python.org (Jean-Paul Calderone) Date: Mon, 10 Sep 2012 19:48:08 +0000 Subject: [issue15912] Intermittent import failure Message-ID: <1347306488.32.0.579862468215.issue15912@psf.upfronthosting.co.za> New submission from Jean-Paul Calderone: The attached unit test fails with an ImportError... sometimes. Here's a little blob of shell that seems to make the failure come up more quickly: while ~/Projects/cpython/3.3/python -m unittest -v test_broken_import; do rm -rf test_broken_import; rm -rf __pycache__/; done An example of the output when I run it: exarkun at top:/tmp$ while ~/Projects/cpython/3.3/python -m unittest -v test_broken_import_minimal; do rm -rf test_broken_import; rm -rf __pycache__/; done test_renamedSource (test_broken_import_minimal.BrokenTests) ... ok ---------------------------------------------------------------------- Ran 1 test in 0.004s OK test_renamedSource (test_broken_import_minimal.BrokenTests) ... ok ---------------------------------------------------------------------- Ran 1 test in 0.005s OK test_renamedSource (test_broken_import_minimal.BrokenTests) ... > /tmp/test_broken_import_minimal.py(53)test_renamedSource() -> print(e) (Pdb) c No module named 'twisted_renamed_helper' ERROR ====================================================================== ERROR: test_renamedSource (test_broken_import_minimal.BrokenTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "./test_broken_import_minimal.py", line 50, in test_renamedSource from twisted_renamed_helper import module ImportError: No module named 'twisted_renamed_helper' ---------------------------------------------------------------------- Ran 1 test in 0.759s FAILED (errors=1) ---------- components: Interpreter Core files: test_broken_import_minimal.py messages: 170225 nosy: exarkun priority: normal severity: normal status: open title: Intermittent import failure versions: Python 3.3 Added file: http://bugs.python.org/file27168/test_broken_import_minimal.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 22:01:10 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 10 Sep 2012 20:01:10 +0000 Subject: [issue15903] Make rawiobase_read() read directly to bytes object In-Reply-To: <1347279783.86.0.217898740398.issue15903@psf.upfronthosting.co.za> Message-ID: <1347307270.91.0.883729625848.issue15903@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: It works as along as the bytes object cannot leak to Python code, (imagine a custom readinto() method which plays with gc.get_referrers, then calls hash(b)...) This is OK with this patch. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 22:09:54 2012 From: report at bugs.python.org (Vitaly) Date: Mon, 10 Sep 2012 20:09:54 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za> Message-ID: <1347307794.95.0.475369174532.issue15896@psf.upfronthosting.co.za> Vitaly added the comment: Per Charles-Fran?ois Natali (neologix), I tried the following: 1. Reduce the initial read size argument (rSize in my code snippet) from 1048576 (1MB, the same amount as used by subprocess.Popen._executeChild) to 1000000: the problem appears to go away (could be just red herring, though); this actually makes me think that it's a Python implementation problem on MacOS - why should an initial read request with 1048576 read size trigger EINVAL every other time (1,3,5,9, etc.), but using the initial size of 1000000 doesn't? 2. "put a short sleep before exiting the child process (after pickling the exception) to see what happens if the reader reads before the pipe is closed by the other end" -- I took that to mean a delay after the "os.write(errpipe_write, pickle.dumps(exc_value))" call in my snippet: I tried 1, 2, and 4-second delays (via time.sleep()). One time, I saw the Invalid Argument in only one of the 9 iterations, but in all the other runs Invalid Argument showed up as before on iterations: 1, 3, 5, 7, 9 3. put the delay (tried with 1 and 2 seconds) before "os.write(errpipe_write, pickle.dumps(exc_value))": Invalid Argument showed up as before on iterations: 1, 3, 5, 7, 9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 22:12:11 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 10 Sep 2012 20:12:11 +0000 Subject: [issue15676] mmap: add empty file check prior to offset check In-Reply-To: <1345052794.26.0.230448790651.issue15676@psf.upfronthosting.co.za> Message-ID: <1347307930.98.0.417844712891.issue15676@psf.upfronthosting.co.za> Stefan Krah added the comment: For some reason all Windows buildbots are failing since f962ec8e47a1: ====================================================================== ERROR: test_entire_file (test.test_mmap.MmapTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_mmap.py", line 19, in setUp os.unlink(TESTFN) PermissionError: [WinError 32] The process cannot access the file because it is being used by another process: '@test_2636_tmp' ====================================================================== ERROR: test_error (test.test_mmap.MmapTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_mmap.py", line 19, in setUp os.unlink(TESTFN) PermissionError: [WinError 32] The process cannot access the file because it is being used by another process: '@test_2636_tmp' ====================================================================== [...] ---------- nosy: +skrah resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 22:13:09 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 10 Sep 2012 20:13:09 +0000 Subject: [issue15909] test_mmap failure on Windows buildbots In-Reply-To: <1347303408.84.0.405583449019.issue15909@psf.upfronthosting.co.za> Message-ID: <1347307989.07.0.0167087898839.issue15909@psf.upfronthosting.co.za> Stefan Krah added the comment: Duplicate. ---------- resolution: -> duplicate stage: needs patch -> committed/rejected status: open -> closed superseder: -> mmap: add empty file check prior to offset check _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 22:22:45 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 10 Sep 2012 20:22:45 +0000 Subject: [issue15881] multiprocessing 'NoneType' object is not callable In-Reply-To: <1347044200.13.0.235512745295.issue15881@psf.upfronthosting.co.za> Message-ID: <1347308565.51.0.260444612017.issue15881@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Actually it is test.with_project_on_sys_path() in setuptools/commands/test.py that does the save/restore of sys.modules. See http://www.eby-sarna.com/pipermail/peak/2010-May/003357.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 22:28:16 2012 From: report at bugs.python.org (Eric Snow) Date: Mon, 10 Sep 2012 20:28:16 +0000 Subject: [issue15912] Intermittent import failure In-Reply-To: <1347306488.32.0.579862468215.issue15912@psf.upfronthosting.co.za> Message-ID: <1347308896.42.0.696278455172.issue15912@psf.upfronthosting.co.za> Eric Snow added the comment: The FileFinder class (a "path entry finder") uses a cache to efficiently track changes to files. You can manually clear this cache by calling importlib.invalidate_caches(). The Python test suite has several examples of clearing the FileFinder cache in this way. I've verified the failure as described. Using importlib.invalidate_caches() at the spot where the script cleans up sys.modules, the failure goes away. Depending on OS filesystem timestamp resolution, you could see the behavior just as you've described it. Since normally you wouldn't remove and re-add modules like this, it isn't normally an issue. ---------- nosy: +eric.snow stage: -> test needed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 22:33:32 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 10 Sep 2012 20:33:32 +0000 Subject: [issue15676] mmap: add empty file check prior to offset check In-Reply-To: <1345052794.26.0.230448790651.issue15676@psf.upfronthosting.co.za> Message-ID: <1347309212.17.0.455786688061.issue15676@psf.upfronthosting.co.za> Stefan Krah added the comment: This gets rid of the permission error: diff -r f962ec8e47a1 Lib/test/test_mmap.py --- a/Lib/test/test_mmap.py Mon Sep 10 01:23:05 2012 +0200 +++ b/Lib/test/test_mmap.py Mon Sep 10 22:22:38 2012 +0200 @@ -491,11 +491,11 @@ def test_empty_file (self): f = open (TESTFN, 'w+b') f.close() - f = open(TESTFN, "rb") - self.assertRaisesRegex(ValueError, - "cannot mmap an empty file", - mmap.mmap, f.fileno(), 0, access=mmap.ACCESS_READ) - f.close() + with open(TESTFN, "rb") as f: + self.assertRaisesRegex(ValueError, + "cannot mmap an empty file", + mmap.mmap, f.fileno(), 0, + access=mmap.ACCESS_READ) def test_offset (self): f = open (TESTFN, 'w+b') But the test still fails: == CPython 3.3.0rc2+ (default, Sep 10 2012, 22:01:26) [MSC v.1600 64 bit (AMD64)] == Windows-7-6.1.7601-SP1 little-endian == C:\Users\stefan\pydev\cpython\build\test_python_2908 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_use r_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1) [1/1] test_mmap test_empty_file (test.test_mmap.MmapTests) ... FAIL ====================================================================== FAIL: test_empty_file (test.test_mmap.MmapTests) ---------------------------------------------------------------------- ValueError: mmap offset is greater than file size During handling of the above exception, another exception occurred: Traceback (most recent call last): File "C:\Users\stefan\pydev\cpython\lib\test\test_mmap.py", line 498, in test_empty_file access=mmap.ACCESS_READ) AssertionError: "cannot mmap an empty file" does not match "mmap offset is greater than file size" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 22:33:49 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 10 Sep 2012 20:33:49 +0000 Subject: [issue8109] Server-side support for TLS Server Name Indication extension In-Reply-To: <1268234047.5.0.702223567094.issue8109@psf.upfronthosting.co.za> Message-ID: <1347309229.8.0.272640561043.issue8109@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Daniel, your patch looks quite interesting. Please, send a contributor agreement to the PSF: http://www.python.org/psf/contrib/contrib-form-python/ . Let me know when you status have changed. Why are you changing "Lib/test/keycert2.pem"? Please, provide also a documentation patch. This is a feature enhancement. Would be applied to 3.4, it is too late for 3.3 :-(. Too bad! :( ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 22:34:02 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 10 Sep 2012 20:34:02 +0000 Subject: [issue8109] Server-side support for TLS Server Name Indication extension In-Reply-To: <1268234047.5.0.702223567094.issue8109@psf.upfronthosting.co.za> Message-ID: <1347309242.04.0.172629243307.issue8109@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 22:46:00 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 10 Sep 2012 20:46:00 +0000 Subject: [issue15676] mmap: add empty file check prior to offset check In-Reply-To: <1345052794.26.0.230448790651.issue15676@psf.upfronthosting.co.za> Message-ID: <3XG1Vv4B0xzQXX@mail.python.org> Roundup Robot added the comment: New changeset 25d477647a2d by Jesus Cea in branch '2.7': #15676: mmap: add empty file check prior to offset check <- Previous patch was incomplete http://hg.python.org/cpython/rev/25d477647a2d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 22:50:44 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 10 Sep 2012 20:50:44 +0000 Subject: [issue15676] mmap: add empty file check prior to offset check In-Reply-To: <1345052794.26.0.230448790651.issue15676@psf.upfronthosting.co.za> Message-ID: <3XG1cM56DzzQWP@mail.python.org> Roundup Robot added the comment: New changeset 88a88c32661e by Jesus Cea in branch '3.2': #15676: mmap: add empty file check prior to offset check <- Previous patch was incomplete http://hg.python.org/cpython/rev/88a88c32661e New changeset 0ac94ae29abe by Jesus Cea in branch 'default': #15676: mmap: add empty file check prior to offset check <- Previous patch was incomplete http://hg.python.org/cpython/rev/0ac94ae29abe ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 22:55:08 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 10 Sep 2012 20:55:08 +0000 Subject: [issue15676] mmap: add empty file check prior to offset check In-Reply-To: <1345052794.26.0.230448790651.issue15676@psf.upfronthosting.co.za> Message-ID: <1347310508.81.0.958480064187.issue15676@psf.upfronthosting.co.za> Stefan Krah added the comment: I think Py_DECREF(m_obj) is missing (at least in 3.3, I didn't look at the other versions). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 22:58:51 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 10 Sep 2012 20:58:51 +0000 Subject: [issue15676] mmap: add empty file check prior to offset check In-Reply-To: <1345052794.26.0.230448790651.issue15676@psf.upfronthosting.co.za> Message-ID: <3XG1nk04RWzQVD@mail.python.org> Roundup Robot added the comment: New changeset 39efccf7a167 by Jesus Cea in branch '2.7': #15676: mmap: add empty file check prior to offset check <- Previous patch was incomplete (fix 2) http://hg.python.org/cpython/rev/39efccf7a167 New changeset 56a2e862561c by Jesus Cea in branch '3.2': #15676: mmap: add empty file check prior to offset check <- Previous patch was incomplete (fix 2) http://hg.python.org/cpython/rev/56a2e862561c New changeset 306b2ecb1a3e by Jesus Cea in branch 'default': MERGE: #15676: mmap: add empty file check prior to offset check <- Previous patch was incomplete (fix 2) http://hg.python.org/cpython/rev/306b2ecb1a3e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 23:02:08 2012 From: report at bugs.python.org (Eric Snow) Date: Mon, 10 Sep 2012 21:02:08 +0000 Subject: [issue15912] Intermittent import failure In-Reply-To: <1347306488.32.0.579862468215.issue15912@psf.upfronthosting.co.za> Message-ID: <1347310928.93.0.89178828545.issue15912@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 23:14:53 2012 From: report at bugs.python.org (Berker Peksag) Date: Mon, 10 Sep 2012 21:14:53 +0000 Subject: [issue13896] Make shelf instances work with 'with' as context managers In-Reply-To: <1327749150.13.0.147725255938.issue13896@psf.upfronthosting.co.za> Message-ID: <1347311693.59.0.769370990536.issue13896@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 23:19:43 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 10 Sep 2012 21:19:43 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347307794.95.0.475369174532.issue15896@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > 1. Reduce the initial read size argument (rSize in my code snippet) from 1048576 (1MB, the same amount as used by subprocess.Popen._executeChild) to 1000000: the problem appears to go away (could be just red herring, though); this actually makes me think that it's a Python implementation problem on MacOS - why should an initial read request with 1048576 read size trigger EINVAL every other time (1,3,5,9, etc.), but using the initial size of 1000000 doesn't? That's not a Python issue. os.read() juste calls the read() syscall, nothing more. Failing with EBADF could maybe have an explanation if we endup up calling read() on a closed FD, but nothing can explain EINVAL. We've had many cases of strange OS-X bugs, like this one (EINVAL too): http://bugs.python.org/issue15594 One last thing I'd like to make sure of, is trying to put a delay before reading the exception from the pipe. There may be cases where read() returns EINVAL instead of EAGAIN when there's no data in the pipe. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 23:27:24 2012 From: report at bugs.python.org (Ellery Newcomer) Date: Mon, 10 Sep 2012 21:27:24 +0000 Subject: [issue15913] PyBuffer_SizeFromFormat is missing Message-ID: <1347312444.09.0.484126652005.issue15913@psf.upfronthosting.co.za> New submission from Ellery Newcomer: this function is listed in the buffer docs and in abstract.h, but there is no implementation anywhere. ---------- components: None messages: 170239 nosy: ellery.newcomer priority: normal severity: normal status: open title: PyBuffer_SizeFromFormat is missing versions: Python 2.7, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 23:29:48 2012 From: report at bugs.python.org (Sean B. Palmer) Date: Mon, 10 Sep 2012 21:29:48 +0000 Subject: [issue15914] multiprocessing.SyncManager connection hang Message-ID: <1347312588.21.0.484965926655.issue15914@psf.upfronthosting.co.za> New submission from Sean B. Palmer: create.py: import multiprocessing manager = multiprocessing.Manager() namespace = manager.Namespace() print("create.py complete") run.py: import create print("run.py complete") Correct behaviour occurs for create.py: $ python3 create.py create.py complete INCORRECT behaviour occurs for run.py: $ python3 run.py No output, because it hangs. On SIGINT: ^CTraceback (most recent call last): File "run.py", line 1, in import create File "[...]/create.py", line 7, in test() File "[...]/create.py", line 5, in test namespace = manager.Namespace() File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/multiprocessing/managers.py", line 670, in temp token, exp = self._create(typeid, *args, **kwds) File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/multiprocessing/managers.py", line 568, in _create conn = self._Client(self._address, authkey=self._authkey) File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/multiprocessing/connection.py", line 175, in Client answer_challenge(c, authkey) File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/multiprocessing/connection.py", line 412, in answer_challenge message = connection.recv_bytes(256) # reject large message KeyboardInterrupt $ python3 Python 3.2.3 (v3.2.3:3d0686d90f55, Apr 10 2012, 11:25:50) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin This appears to be a duplicate of this *closed* bug: http://bugs.python.org/issue7474 This was closed because nobody could reproduce the behaviour on Python 3. I have reproduced it, but I don't know how to reopen that bug, so I'm filing this one. The test case in 7474 also fails for me. ---------- messages: 170240 nosy: palmer priority: normal severity: normal status: open title: multiprocessing.SyncManager connection hang type: crash versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 23:35:41 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 10 Sep 2012 21:35:41 +0000 Subject: [issue15676] mmap: add empty file check prior to offset check In-Reply-To: <1345052794.26.0.230448790651.issue15676@psf.upfronthosting.co.za> Message-ID: <1347312941.18.0.98396850197.issue15676@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Thanks for the heads-up, Stefan. ---------- assignee: -> jcea resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 23:53:19 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 10 Sep 2012 21:53:19 +0000 Subject: [issue15914] multiprocessing.SyncManager connection hang In-Reply-To: <1347312588.21.0.484965926655.issue15914@psf.upfronthosting.co.za> Message-ID: <1347313999.34.0.744096369201.issue15914@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 10 23:54:07 2012 From: report at bugs.python.org (Ellery Newcomer) Date: Mon, 10 Sep 2012 21:54:07 +0000 Subject: [issue15915] array.array does not support the buffer interface Message-ID: <1347314047.19.0.593208170998.issue15915@psf.upfronthosting.co.za> New submission from Ellery Newcomer: According to http://docs.python.org/library/array.html, array.array supports the buffer interface; however in python 2.7, PyObject_CheckBuffer says this is not the case. all is well in python 3.2, though. ---------- files: test.c messages: 170242 nosy: ellery.newcomer priority: normal severity: normal status: open title: array.array does not support the buffer interface versions: Python 2.7 Added file: http://bugs.python.org/file27169/test.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 00:00:29 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 10 Sep 2012 22:00:29 +0000 Subject: [issue15915] array.array does not support the buffer interface In-Reply-To: <1347314047.19.0.593208170998.issue15915@psf.upfronthosting.co.za> Message-ID: <1347314429.83.0.357462891259.issue15915@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 00:41:46 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 10 Sep 2012 22:41:46 +0000 Subject: [issue15881] multiprocessing 'NoneType' object is not callable In-Reply-To: <1347044200.13.0.235512745295.issue15881@psf.upfronthosting.co.za> Message-ID: <1347316906.14.0.772321114087.issue15881@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 00:43:52 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 10 Sep 2012 22:43:52 +0000 Subject: [issue15419] distutils: build should use a version-specific build directory In-Reply-To: <1342945976.47.0.537572255215.issue15419@psf.upfronthosting.co.za> Message-ID: <1347317032.47.0.55335111804.issue15419@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 00:48:35 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 10 Sep 2012 22:48:35 +0000 Subject: [issue7358] cStringIO not 64-bit safe In-Reply-To: <1258645822.27.0.150067328286.issue7358@psf.upfronthosting.co.za> Message-ID: <1347317315.33.0.901017801606.issue7358@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Gilles: it's really puzzling that you run into the issue. This is an assert, so in a regular build of Python, it should never trigger. Instead, it should trigger only in a debug build. Why are you running a debug build? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 00:54:32 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 10 Sep 2012 22:54:32 +0000 Subject: [issue15915] array.array does not support the buffer interface In-Reply-To: <1347314047.19.0.593208170998.issue15915@psf.upfronthosting.co.za> Message-ID: <1347317672.59.0.186040020699.issue15915@psf.upfronthosting.co.za> Benjamin Peterson added the comment: array.array supports the old buffer interface not the new one, which PyObject_CheckBuffer is part of. ---------- nosy: +benjamin.peterson resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 00:54:49 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 10 Sep 2012 22:54:49 +0000 Subject: [issue15419] distutils: build should use a version-specific build directory In-Reply-To: <1342945976.47.0.537572255215.issue15419@psf.upfronthosting.co.za> Message-ID: <1347317689.19.0.716072883936.issue15419@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: Currently users can run e.g.: $ python2.7 setup.py build -b build-2.7 install $ python3.2 setup.py build -b build-3.2 install If default name of build directory had to be changed, then it would be useful to also include name of Python implementation (e.g. "build-cpython-2.7"). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 00:57:37 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 10 Sep 2012 22:57:37 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347317857.56.0.273745768762.issue15906@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 01:19:22 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 10 Sep 2012 23:19:22 +0000 Subject: [issue7358] cStringIO not 64-bit safe In-Reply-To: <1258645822.27.0.150067328286.issue7358@psf.upfronthosting.co.za> Message-ID: <1347319162.83.0.572423904232.issue7358@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Antoine: if you look at http://svn.python.org/view/python/branches/ssize_t/Modules/cStringIO.c?revision=41731&view=markup&pathrev=42382 you'll notice that IOobject and Iobject have pos and stringsize as int, whereas Oobject has it as Py_ssize_t. This must have been a bug; I think the structures were meant as compatible. If they all should have been defined in terms of int, the assert would make sense. That said, what actually got merged included all the fields as Py_ssize_t, in which case the assert makes no sense. OTOH, it prevents the cast below (of (int)l) to produce bogus results, so it actually helped to detect the bugs :-) What is now needed (from people running into the issue) is a patch that resolves all aspects of >2GB handling in these modules. I believe the issue is resolved in Python 3 (by both StringIO and BytesIO properly using Py_ssize_t throughout there), so unless somebody interested in this problem actually contributes a patch, the issue is unlikely to advance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 01:20:06 2012 From: report at bugs.python.org (Ellery Newcomer) Date: Mon, 10 Sep 2012 23:20:06 +0000 Subject: [issue15915] array.array does not support the buffer interface In-Reply-To: <1347314047.19.0.593208170998.issue15915@psf.upfronthosting.co.za> Message-ID: <1347319206.76.0.0424661256417.issue15915@psf.upfronthosting.co.za> Ellery Newcomer added the comment: relevant question, then, is why does array not support the new buffer interface while str and bytearray support both old and new? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 01:23:09 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 10 Sep 2012 23:23:09 +0000 Subject: [issue15915] array.array does not support the buffer interface In-Reply-To: <1347314047.19.0.593208170998.issue15915@psf.upfronthosting.co.za> Message-ID: <1347319389.38.0.138299890452.issue15915@psf.upfronthosting.co.za> Benjamin Peterson added the comment: It simply wasn't converted in time for the 2.7 release. The new buffer API is considered something of a technical preview in Python 2.x. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 01:29:02 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 10 Sep 2012 23:29:02 +0000 Subject: [issue15390] PEP 3121, 384 refactoring applied to datetime module In-Reply-To: <1342647232.82.0.0763290244077.issue15390@psf.upfronthosting.co.za> Message-ID: <1347319742.1.0.87140110608.issue15390@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I would like to split this issue to separate PEP 3121 changes from PEP 384. PEP 3121 state cleanup implementation is clearly an improvement "from a resource management point of view." On the other hand, I don't see much benefit for the datetime module from using a stable ABI. Unless I am missing something, PEP 384 is primarily benefiting 3rd party developers who distribute binary modules that should run under multiple Python versions. ABI stability is not a concern for the stdlib modules. On the other hand, the price for multi-version support is rather steep. Statically allocated types are more efficient. For example, with static types, PyDate_CheckExact() is a simple macro that expands into a dereference and a pointer comparison - a couple of instructions at the CPU level. On the other hand, with a proposed patch, it will involve a function call to locate the module (PyState_FindModule), followed by another function call to locate the state (PyModule_GetState) and several more dereferences that may lead to cache misses and other pessimizations. There is an important behavior change related to multiple interpreters. Currently dates created by different interpreters have the same type. With the proposed change they will have different types. I don't think this is desirable. In short, let's go in baby steps. Let's implement PEP 3121 cleanup first and start a debate on the role of PEP 384 in stdlib. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 01:33:29 2012 From: report at bugs.python.org (Berker Peksag) Date: Mon, 10 Sep 2012 23:33:29 +0000 Subject: [issue15887] urlencode should accept generators or two elements tuples In-Reply-To: <1347185937.29.0.747427121658.issue15887@psf.upfronthosting.co.za> Message-ID: <1347320009.91.0.261031617496.issue15887@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 01:54:55 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 10 Sep 2012 23:54:55 +0000 Subject: [issue15916] change doctest DocTestSuite not to raise ValueError if no docstrings Message-ID: <1347321295.19.0.66061447718.issue15916@psf.upfronthosting.co.za> New submission from Chris Jerdonek: Currently, calling doctest.DocTestSuite() raises a ValueError if the module passed to it has no docstrings. This was the subject of issue 14649. This issue is to discuss and possibly change DocTestSuite's behavior not to raise an exception in that situation. In the discussion for issue 14649 (in particular with R. David Murray), it was acknowledged that the current behavior probably isn't correct or desirable. However, treating the behavior as a bug and fixing it in maintenance branches would have been too big of a change. Thus, if this change is made, it could be slated for the next feature release. ---------- components: Library (Lib) keywords: easy messages: 170250 nosy: asvetlov, cjerdonek, r.david.murray priority: normal severity: normal status: open title: change doctest DocTestSuite not to raise ValueError if no docstrings type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 01:56:05 2012 From: report at bugs.python.org (Vitaly) Date: Mon, 10 Sep 2012 23:56:05 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za> Message-ID: <1347321365.37.0.984637837781.issue15896@psf.upfronthosting.co.za> Changes by Vitaly : Added file: http://bugs.python.org/file27170/test_fork_pipe_error.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 02:19:03 2012 From: report at bugs.python.org (Vitaly) Date: Tue, 11 Sep 2012 00:19:03 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za> Message-ID: <1347322743.79.0.801221142759.issue15896@psf.upfronthosting.co.za> Vitaly added the comment: os.read() must also be allocating the read buffer in addition to calling the system read() function. I just uploaded a new test script "test_fork_pipe_error.py" that iterates in increasing or decreasing order over initial pipe read sizes and accumulates failed size values. It iterates in multiples of 1024 (1024*1, 1024*2, 1024*3, ... 1024*1024 or in reverse) . It makes some interesting (possibly also red-herring) discoveries: 1. When iterating the initial read size in increasing order (1024, 2048, 3072, ...) the test doesn't trigger the EINVAL error. 2. When iterating the initial read size in decreasing order, the test triggers EINVAL every 4KB (1024*1024, 1024*1020, 1024*1016, etc.) all the way down to 1024*128. However, the test doesn't trigger any more EINVAL errors for initial read sizes of 127KB and lower (1024*127, 1024*126, 1024*125, ... 1024*1). Failed initialReadSize multipliers of 1024: [1024, 1020, 1016, 1012, 1008, 1004, 1000, 996, 992, 988, 984, 980, 976, 972, 968, 964, 960, 956, 952, 948, 944, 940, 936, 932, 928, 924, 920, 916, 912, 908, 904, 900, 896, 892, 888, 884, 880, 876, 872, 868, 864, 860, 856, 852, 848, 844, 840, 836, 832, 828, 824, 820, 816, 812, 808, 804, 800, 796, 792, 788, 784, 780, 776, 772, 768, 764, 760, 756, 752, 748, 744, 740, 736, 732, 728, 724, 720, 716, 712, 708, 704, 700, 696, 692, 688, 684, 680, 676, 672, 668, 664, 660, 656, 652, 648, 644, 640, 636, 632, 628, 624, 620, 616, 612, 608, 604, 600, 596, 592, 588, 584, 580, 576, 572, 568, 564, 560, 556, 552, 548, 544, 540, 536, 532, 528, 524, 520, 516, 512, 508, 504, 500, 496, 492, 488, 484, 480, 476, 472, 468, 464, 460, 456, 452, 448, 444, 440, 436, 432, 428, 424, 420, 416, 412, 408, 404, 400, 396, 392, 388, 384, 380, 376, 372, 368, 364, 360, 356, 352, 348, 344, 340, 336, 332, 328, 324, 320, 316, 312, 308, 304, 300, 296, 292, 288, 284, 280, 276, 272, 268, 264, 260, 256, 252, 248, 244, 240, 236, 232, 228, 224, 220, 216, 212, 208, 204, 200, 196, 192, 188, 184, 180, 176, 172, 168, 164, 160, 156, 152, 148, 144, 140, 136, 132, 128] The reason I said above that those might be red-herring discoveries is this: if I insert a short time.sleep(0.001) delay before the outer pipe-read loop, the EINVAL errors don't get triggered either. Still, these remain a mystery: 1. Why doesn't the test encounter EINVAL in the range 127KB ... 1KB (when iterating initialReadSize in *decreasing* order). If the pre-read delay is significant, then does it take significantly more time to allocate a 127KB chunk of memory than it does a 128KB chunk? 2. Why doesn't the test encounter EINVAL at all when iterating initialReadSize in *increasing* order? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 02:24:02 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 11 Sep 2012 00:24:02 +0000 Subject: [issue15793] Stack corruption in ssl.RAND_egd() In-Reply-To: <1346102240.18.0.678395188074.issue15793@psf.upfronthosting.co.za> Message-ID: <3XG6LP4Nt4zP53@mail.python.org> Roundup Robot added the comment: New changeset 706115cb2cdb by Jesus Cea in branch '2.7': Closes #15793: Stack corruption in ssl.RAND_egd(). Python 2.7 hasn't any issue about this, but add a test just to be sure http://hg.python.org/cpython/rev/706115cb2cdb New changeset 827bb0554f1f by Jesus Cea in branch '3.2': Closes #15793: Stack corruption in ssl.RAND_egd() http://hg.python.org/cpython/rev/827bb0554f1f New changeset 7619a400d318 by Jesus Cea in branch 'default': MERGE: Closes #15793: Stack corruption in ssl.RAND_egd() http://hg.python.org/cpython/rev/7619a400d318 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 02:24:43 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 11 Sep 2012 00:24:43 +0000 Subject: [issue15793] Stack corruption in ssl.RAND_egd() In-Reply-To: <1346102240.18.0.678395188074.issue15793@psf.upfronthosting.co.za> Message-ID: <1347323083.82.0.941288435518.issue15793@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Thanks for the detection and patch. I added a test to 2.7, even knowing it doesn't need it (2.7 is a dead end), for consistence. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 02:39:46 2012 From: report at bugs.python.org (Eric Snow) Date: Tue, 11 Sep 2012 00:39:46 +0000 Subject: [issue15912] Intermittent import failure In-Reply-To: <1347306488.32.0.579862468215.issue15912@psf.upfronthosting.co.za> Message-ID: <1347323986.45.0.527598302968.issue15912@psf.upfronthosting.co.za> Eric Snow added the comment: Thinking about it, it may be worth adding a note to the docs for sys.modules making it clear about importlib.invalidate_caches(). I'll see about writing up a patch when I get a chance. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 03:01:59 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 11 Sep 2012 01:01:59 +0000 Subject: [issue15629] Add to regrtest the ability to run Lib and Doc doctests In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1347325319.94.0.99508281558.issue15629@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > You should also see if there are more doctest-safe or more doctest-unsafe tests, and mark the ones in the smallest group. Running the doctests for all .rst files in the Doc/ directory using the latest patch gave me the following: 299 tests [files] OK. 126 tests failed (and 6 that I manually skipped) Following the suggestion above from Ezio, we should have a doc file marker to skip a file as opposed to including a file. This means that doctests would be included by default, which I think would be a good way to go. How do people feel about something like the following for a marker? .. doctest-skip-file (to distinguish from skipping an individual test) Or perhaps (to go with something like Nick's original suggestion) .. doctest-unsafe ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 03:09:12 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 11 Sep 2012 01:09:12 +0000 Subject: [issue15886] os.stat() docs repeat "specifying a file descriptor" support In-Reply-To: <1347175050.22.0.936746811947.issue15886@psf.upfronthosting.co.za> Message-ID: <3XG7Lb3c1kzPGC@mail.python.org> Roundup Robot added the comment: New changeset d7ea7ec671ba by R David Murray in branch 'default': #15886: remove redundant phrase http://hg.python.org/cpython/rev/d7ea7ec671ba ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 03:10:00 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 11 Sep 2012 01:10:00 +0000 Subject: [issue15886] os.stat() docs repeat "specifying a file descriptor" support In-Reply-To: <1347175050.22.0.936746811947.issue15886@psf.upfronthosting.co.za> Message-ID: <1347325800.5.0.830195801972.issue15886@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks Masato. ---------- nosy: +r.david.murray resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 03:19:54 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 11 Sep 2012 01:19:54 +0000 Subject: [issue15629] Add to regrtest the ability to run Lib and Doc doctests In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1347326394.53.0.219409445997.issue15629@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > Integrating this with regrtest requires some work, for example you would have to count successes/failures, add skips for certain tests and resources to control what tests should be run (there's currently a turtle going around on my screen when I run `make doctest`). Fortunately, we get a lot of this for free when integrating with regrtest because the infrastructure is already there for the other tests. For example, the test counts for my previous comment were automatic, operating in a clean temp cwd is something else taken care of, a command-line interface is already present, etc. The main doctest-specific things that needed to be added were (1) doctest discovery (which involves walking the Lib/ and Doc/ directory hierarchies), and (2) creating TestSuite instances differently (by invoking DocTestSuite and DocFileSuite as opposed to calling TestLoader.loadTestsFromModule()). I would still like to decouple the code a bit more and perhaps even add some unit tests for some of the newly added code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 05:42:27 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 11 Sep 2012 03:42:27 +0000 Subject: [issue15629] Add to regrtest the ability to run Lib and Doc doctests In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1347334947.35.0.170926497914.issue15629@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > Sphinx does have a way to mark doctest snippets as "run this", "don't run this". I believe that requires using 'make doctest' as the runner, The doctest module supports this natively (i.e. without the need for Sphinx) via its "skip" directive ("#doctest: +SKIP"): http://docs.python.org/dev/library/doctest.html#doctest.SKIP Sphinx will even hide doctest directives like this when rendering the HTML, so the additional annotation won't be visible to the end user/reader and clutter up the interactive examples (cf. issue 12947). Also, it looks like the Sphinx "doctest" directive gets most or all of its functionality via the options already exposed by doctest: http://sphinx.pocoo.org/ext/doctest.html?#directive-doctest ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 06:07:04 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 11 Sep 2012 04:07:04 +0000 Subject: [issue15629] Add to regrtest the ability to run Lib and Doc doctests In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1347336424.01.0.367320477664.issue15629@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > The reason is that Sphinx has extra facilities that allow docttests to work without having to have "boilerplate" code in places where doing so would disrupt the narrative flow. Yes, this seems to be true. Sphinx has a "testsetup" directive which lets you avoid adding boilerplate to interactive examples: http://sphinx.pocoo.org/ext/doctest.html?#directive-testsetup I did a quick search, though, and it looks like this is used in only 7 documentation files out of the 430+ -- one of which is library/turtle.rst. :) Similarly, the "testcode" directive (a variant of the doctest format) seems to be used in just 5 files. In any case, we could still benefit from running the doctests from regrtest that don't require use of testsetup. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 06:19:30 2012 From: report at bugs.python.org (Andrew Moffat) Date: Tue, 11 Sep 2012 04:19:30 +0000 Subject: [issue15898] OSX TTY bug In-Reply-To: <1347238694.31.0.649838162085.issue15898@psf.upfronthosting.co.za> Message-ID: <1347337170.8.0.208818111589.issue15898@psf.upfronthosting.co.za> Andrew Moffat added the comment: Below I attached a script that reproduces the behavior of an assertion error on a specific fork condition for a process with a pty. Here are the results Xubuntu x64: Python 2.7, parent_close_slave_before_child_write = False: WORKS Python 2.7, parent_close_slave_before_child_write = True: WORKS Python 3.2, parent_close_slave_before_child_write = False: WORKS Python 3.2, parent_close_slave_before_child_write = True: WORKS Mac OSX 10.7.2: Python 2.7, parent_close_slave_before_child_write = False: WORKS Python 2.7, parent_close_slave_before_child_write = True: WORKS Python 3.2, parent_close_slave_before_child_write = False: >> FAILS << Python 3.2, parent_close_slave_before_child_write = True: WORKS Here's dtruss -f for python 2.7 and 3.0 on Mac OSX: 2.7, parent_close_slave_before_child_write = False (WORKS) PID/THRD SYSCALL(args) = return 356/0xc4a: open_nocancel("/dev/ptmx\0", 0x20002, 0x0) = 3 0 356/0xc4a: ioctl(0x3, 0x20007454, 0xFFFFFFFF) = 0 0 356/0xc4a: ioctl(0x3, 0x20007452, 0x0) = 0 0 356/0xc4a: ioctl(0x3, 0x40807453, 0x10041AD20) = 0 0 356/0xc4a: stat64("/dev/ttys003\0", 0x7FFF5FBFF030, 0x0) = 0 0 356/0xc4a: open_nocancel("/dev/ttys003\0", 0x20002, 0x0) = 4 0 356/0xc4a: fork() = 362 0 362/0xc61: fork() = 0 0 362/0xc61: thread_selfid(0x100420BE0, 0x3, 0x1) = 3169 0 362/0xc61: getpid(0x100420BE0, 0x3, 0x0) = 362 0 362/0xc61: select(0x0, 0x0, 0x0, 0x0, 0x7FFF5FBFF3C0) = 0 0 362/0xc61: setsid(0x0, 0x0, 0x1001A7B40) = 362 0 362/0xc61: close(0x3) = 0 0 362/0xc61: dup2(0x4, 0x0, 0x0) = 0 0 362/0xc61: dup2(0x4, 0x1, 0x0) = 1 0 362/0xc61: dup2(0x4, 0x2, 0x0) = 2 0 362/0xc61: getrlimit(0x1008, 0x7FFF5FBFF3D0, 0x0) = 0 0 ... close range ... 362/0xc61: ioctl(0x1, 0x40487413, 0x7FFF5FBFF360) = 0 0 362/0xc61: fstat64(0x1, 0x7FFF5FBFF2D0, 0x0) = 0 0 362/0xc61: open_nocancel("/dev/\0", 0x100004, 0x0) = 3 0 362/0xc61: fcntl_nocancel(0x3, 0x2, 0x1) = 0 0 362/0xc61: fstatfs64(0x3, 0x7FFF5FBFE7B0, 0x0) = 0 0 362/0xc61: getdirentries64(0x3, 0x1010AB600, 0x1000) = 3080 0 ... lots of lstat64 ... 362/0xc61: close_nocancel(0x3) = 0 0 362/0xc61: open("/dev/ttys003\0", 0x2, 0x1FF) = 3 0 362/0xc61: close(0x3) = 0 0 362/0xc61: write(0x1, "testing\0", 0x7) = 7 0 362/0xc61: close(0x1) = 0 0 356/0xc4a: select(0x0, 0x0, 0x0, 0x0, 0x7FFF5FBFF3C0) = 0 0 356/0xc4a: close(0x4) = 0 0 356/0xc4a: read(0x3, "testing\0", 0x400) = 7 0 356/0xc4a: write_nocancel(0x1, "'testing'\n\0", 0xA) = 10 0 356/0xc4a: wait4(0x16A, 0x7FFF5FBFF3D4, 0x0) = 362 0 356/0xc4a: sigaction(0x2, 0x7FFF5FBFF800, 0x7FFF5FBFF830) = 0 0 3.0, parent_close_slave_before_child_write = False (FAILS) PID/THRD SYSCALL(args) = return 385/0xe53: open_nocancel("/dev/ptmx\0", 0x20002, 0xD15EB8) = 3 0 385/0xe53: ioctl(0x3, 0x20007454, 0xBFFFF1BC) = 0 0 385/0xe53: ioctl(0x3, 0x20007452, 0xBFFFF1BC) = 0 0 385/0xe53: ioctl(0x3, 0x40807453, 0x64F220) = 0 0 385/0xe53: stat64("/dev/ttys003\0", 0xBFFFF164, 0x64F220) = 0 0 385/0xe53: open_nocancel("/dev/ttys003\0", 0x20002, 0x0) = 4 0 385/0xe53: fork() = 389 0 389/0xe5c: fork() = 0 0 389/0xe5c: thread_selfid(0x0, 0x0, 0x0) = 3676 0 389/0xe5c: getpid(0x0, 0x0, 0x0) = 389 0 389/0xe5c: select_nocancel(0x0, 0x0, 0x0) = 0 0 389/0xe5c: setsid(0x0, 0x0, 0x0) = 389 0 389/0xe5c: close_nocancel(0x3) = 0 0 389/0xe5c: dup2(0x4, 0x0, 0x0) = 0 0 389/0xe5c: dup2(0x4, 0x1, 0x0) = 1 0 389/0xe5c: dup2(0x4, 0x2, 0x0) = 2 0 389/0xe5c: getrlimit(0x8, 0xBFFFF46C, 0x0) = 0 0 ... close range ... 389/0xe5c: ioctl(0x1, 0x402C7413, 0xBFFFF410) = 0 0 389/0xe5c: fstat64(0x1, 0xBFFFF3A4, 0xBFFFF410) = 0 0 389/0xe5c: open_nocancel("/dev/\0", 0x100004, 0xBFFFE968) = 3 0 389/0xe5c: fcntl_nocancel(0x3, 0x2, 0x1) = 0 0 389/0xe5c: fstatfs64(0x3, 0xBFFFE8D8, 0x1) = 0 0 389/0xe5c: getdirentries64(0x3, 0x10DFC00, 0x1000) = 3080 0 ... lots of lstat64 ... 389/0xe5c: close_nocancel(0x3) = 0 0 389/0xe5c: open_nocancel("/dev/ttys003\0", 0x20002, 0x0) = 3 0 389/0xe5c: close_nocancel(0x3) = 0 0 389/0xe5c: write_nocancel(0x1, "testing\0", 0x7) = 7 0 389/0xe5c: close_nocancel(0x1) = 0 0 385/0xe53: select_nocancel(0x0, 0x0, 0x0) = 0 0 385/0xe53: close_nocancel(0x4) = 0 0 385/0xe53: read_nocancel(0x3, "\0", 0x400) = 0 0 385/0xe53: write_nocancel(0x1, "b''\n\0", 0x4) = 4 0 385/0xe53: wait4_nocancel(0x185, 0xBFFFF474, 0x0) = 389 0 385/0xe53: sigaction(0x2, 0xBFFFF800, 0xBFFFF838) = 0 0 385/0xe53: madvise(0xDA0000, 0x20000, 0x9) = 0 0 385/0xe53: madvise(0xDC0000, 0x20000, 0x9) = 0 0 385/0xe53: madvise(0xD80000, 0x20000, 0x9) = 0 0 2.7, parent_close_slave_before_child_write = True (WORkS) PID/THRD SYSCALL(args) = return 363/0xcab: open_nocancel("/dev/ptmx\0", 0x20002, 0x0) = 3 0 363/0xcab: ioctl(0x3, 0x20007454, 0xFFFFFFFF) = 0 0 363/0xcab: ioctl(0x3, 0x20007452, 0x0) = 0 0 363/0xcab: ioctl(0x3, 0x40807453, 0x10041AD20) = 0 0 363/0xcab: stat64("/dev/ttys003\0", 0x7FFF5FBFF030, 0x0) = 0 0 363/0xcab: open_nocancel("/dev/ttys003\0", 0x20002, 0x0) = 4 0 363/0xcab: fork() = 368 0 368/0xcb5: fork() = 0 0 368/0xcb5: thread_selfid(0x100420BE0, 0x3, 0x1) = 3253 0 368/0xcb5: getpid(0x100420BE0, 0x3, 0x0) = 368 0 363/0xcab: select(0x0, 0x0, 0x0, 0x0, 0x7FFF5FBFF3C0) = 0 0 363/0xcab: close(0x4) = 0 0 368/0xcb5: select(0x0, 0x0, 0x0, 0x0, 0x7FFF5FBFF3C0) = 0 0 368/0xcb5: setsid(0x0, 0x0, 0x1001A7B40) = 368 0 368/0xcb5: close(0x3) = 0 0 368/0xcb5: dup2(0x4, 0x0, 0x0) = 0 0 368/0xcb5: dup2(0x4, 0x1, 0x0) = 1 0 368/0xcb5: dup2(0x4, 0x2, 0x0) = 2 0 368/0xcb5: getrlimit(0x1008, 0x7FFF5FBFF3D0, 0x0) = 0 0 ... close range ... 368/0xcb5: ioctl(0x1, 0x40487413, 0x7FFF5FBFF360) = 0 0 368/0xcb5: fstat64(0x1, 0x7FFF5FBFF2D0, 0x0) = 0 0 368/0xcb5: open_nocancel("/dev/\0", 0x100004, 0x0) = 3 0 368/0xcb5: fcntl_nocancel(0x3, 0x2, 0x1) = 0 0 368/0xcb5: fstatfs64(0x3, 0x7FFF5FBFE7B0, 0x0) = 0 0 368/0xcb5: getdirentries64(0x3, 0x1010AB600, 0x1000) = 3080 0 ... lots of lstat64 ... 368/0xcb5: close_nocancel(0x3) = 0 0 368/0xcb5: open("/dev/ttys003\0", 0x2, 0x1FF) = 3 0 368/0xcb5: close(0x3) = 0 0 368/0xcb5: write(0x1, "testing\0", 0x7) = 7 0 368/0xcb5: close(0x1) = 0 0 363/0xcab: read(0x3, "testing\0", 0x400) = 7 0 363/0xcab: write_nocancel(0x1, "'testing'\n\0", 0xA) = 10 0 363/0xcab: wait4(0x170, 0x7FFF5FBFF3D4, 0x0) = 368 0 363/0xcab: sigaction(0x2, 0x7FFF5FBFF800, 0x7FFF5FBFF830) = 0 0 3.0, parent_close_slave_before_child_write = True (WORkS) PID/THRD SYSCALL(args) = return 393/0xed3: open_nocancel("/dev/ptmx\0", 0x20002, 0xD15EB8) = 3 0 393/0xed3: ioctl(0x3, 0x20007454, 0xBFFFF1BC) = 0 0 393/0xed3: ioctl(0x3, 0x20007452, 0xBFFFF1BC) = 0 0 393/0xed3: ioctl(0x3, 0x40807453, 0x64F220) = 0 0 393/0xed3: stat64("/dev/ttys003\0", 0xBFFFF164, 0x64F220) = 0 0 393/0xed3: open_nocancel("/dev/ttys003\0", 0x20002, 0x0) = 4 0 393/0xed3: fork() = 399 0 399/0xee3: fork() = 0 0 399/0xee3: thread_selfid(0x0, 0x0, 0x0) = 3811 0 399/0xee3: getpid(0x0, 0x0, 0x0) = 399 0 393/0xed3: select_nocancel(0x0, 0x0, 0x0) = 0 0 393/0xed3: close_nocancel(0x4) = 0 0 399/0xee3: select_nocancel(0x0, 0x0, 0x0) = 0 0 399/0xee3: setsid(0x0, 0x0, 0x0) = 399 0 399/0xee3: close_nocancel(0x3) = 0 0 399/0xee3: dup2(0x4, 0x0, 0x0) = 0 0 399/0xee3: dup2(0x4, 0x1, 0x0) = 1 0 399/0xee3: dup2(0x4, 0x2, 0x0) = 2 0 399/0xee3: getrlimit(0x8, 0xBFFFF46C, 0x0) = 0 0 ... close range ... 399/0xee3: ioctl(0x1, 0x402C7413, 0xBFFFF410) = 0 0 399/0xee3: fstat64(0x1, 0xBFFFF3A4, 0xBFFFF410) = 0 0 399/0xee3: open_nocancel("/dev/\0", 0x100004, 0xBFFFE968) = 3 0 399/0xee3: fcntl_nocancel(0x3, 0x2, 0x1) = 0 0 399/0xee3: fstatfs64(0x3, 0xBFFFE8D8, 0x1) = 0 0 399/0xee3: getdirentries64(0x3, 0x10DFC00, 0x1000) = 3080 0 ... lots of lstat64 ... 399/0xee3: close_nocancel(0x3) = 0 0 399/0xee3: open_nocancel("/dev/ttys003\0", 0x20002, 0x0) = 3 0 399/0xee3: close_nocancel(0x3) = 0 0 399/0xee3: write_nocancel(0x1, "testing\0", 0x7) = 7 0 399/0xee3: close_nocancel(0x1) = 0 0 393/0xed3: read_nocancel(0x3, "testing\0", 0x400) = 7 0 393/0xed3: write_nocancel(0x1, "b'testing'\n\0", 0xB) = 11 0 393/0xed3: wait4_nocancel(0x18F, 0xBFFFF474, 0x0) = 399 0 393/0xed3: sigaction(0x2, 0xBFFFF800, 0xBFFFF838) = 0 0 393/0xed3: madvise(0xDA0000, 0x20000, 0x9) = 0 0 393/0xed3: madvise(0xDC0000, 0x20000, 0x9) = 0 0 393/0xed3: madvise(0xD80000, 0x20000, 0x9) = 0 0 ----------- import os import pty import resource import signal import tty import time import sys PY3 = sys.version_info.major == 3 if PY3: raw_input = input # change this to False for failure on py3 parent_close_slave_before_child_write = True print("pid: %d" % os.getpid()) raw_input("hit enter when 'dtruss -f' is ready> ") send_from_child = "testing123".encode() master, slave = pty.openpty() pid = os.fork() # child process if pid == 0: if parent_close_slave_before_child_write: time.sleep(2) else: time.sleep(1) os.setsid() os.close(master) os.dup2(slave, 0) os.dup2(slave, 1) os.dup2(slave, 2) max_fd = resource.getrlimit(resource.RLIMIT_NOFILE)[0] os.closerange(3, max_fd) # make controlling terminal. taken from pty.fork tmp_fd = os.open(os.ttyname(1), os.O_RDWR) os.close(tmp_fd) os.write(1, send_from_child) os.close(1) os._exit(255) # parent process else: if parent_close_slave_before_child_write: time.sleep(1) else: time.sleep(2) os.close(slave) actual_output = os.read(master, 1024) os.waitpid(pid, 0) assert(actual_output == send_from_child) print("correct output") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 06:44:57 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 11 Sep 2012 04:44:57 +0000 Subject: [issue15851] Lib/robotparser.py doesn't accept setting a user agent string, instead it uses the default. In-Reply-To: <20120909214501.GC5726@claret.lan> Message-ID: Senthil Kumaran added the comment: Hello Eduardo, I fail to see the bug in here. Robotparser module is for reading and parsing the robot.txt file, the module responsible for fetching it could urllib. robots.txt is always available from web-server and you can download the robot.txt by any means, even by using robotparser.read by providing the full url to robots.txt. You do not need to set user-agent to read/fetch the robots.txt file. Once fetched, now when you are crawling the site using your custom written crawler or using urllib, you can honor the User-Agent requirement by sending proper headers with your request. That can be done using urllib module itself and there is documentation on adding headers I believe. I think, this is way most folks would be (or I believe are ) using it. Am I missing something? If my above explanation is okay, then we can close this bug as invalid. Thanks, Senthil ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 07:13:11 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 11 Sep 2012 05:13:11 +0000 Subject: [issue15917] hg hook to detect unmerged changesets Message-ID: <1347340391.86.0.248701031918.issue15917@psf.upfronthosting.co.za> New submission from Ezio Melotti: The attached Mercurial hook checks that all the changesets in a 3.x branch are merged with either another cset in the same branch or a cset in the following 3.x branch. This is to detect and prevent situations where people commit something on e.g. 3.2 and push it without merging it with default. ---------- files: checkmerge.py messages: 170263 nosy: ezio.melotti, georg.brandl, loewis, pitrou priority: normal severity: normal stage: patch review status: open title: hg hook to detect unmerged changesets type: enhancement Added file: http://bugs.python.org/file27171/checkmerge.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 07:19:18 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 11 Sep 2012 05:19:18 +0000 Subject: [issue15898] OSX TTY bug In-Reply-To: <1347238694.31.0.649838162085.issue15898@psf.upfronthosting.co.za> Message-ID: <1347340758.99.0.371144801224.issue15898@psf.upfronthosting.co.za> Martin v. L?wis added the comment: To me, this still looks like an OS bug. The difference between 2.7 and 3.2 seems to be that 3.2 will call the _nocancel syscalls, which I guess results from using a different version of the C library, or OSX deployment target, or something. However, the system calls are almost identical, see http://fxr.watson.org/fxr/source/bsd/kern/sys_generic.c?v=xnu-1699.24.8#L448 (i.e. the "cancel" version calls __pthread_testcancel, which may result in EINTR, but not in this trace). So ISTM that in the failing case, the child successfully writes to the file descriptor (7 bytes written), yet the parent reads only 0 bytes out of the pty, which makes it look like the kernel discards the data. The trace isn't exactly from the script you provided, right? Because the script sends the string "testing123", whereas the trace shows "testing". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 07:45:27 2012 From: report at bugs.python.org (=?utf-8?q?Eduardo_A=2E_Bustamante_L=C3=B3pez?=) Date: Tue, 11 Sep 2012 05:45:27 +0000 Subject: [issue15851] Lib/robotparser.py doesn't accept setting a user agent string, instead it uses the default. In-Reply-To: Message-ID: <20120911054504.GA1146@claret.lan> Eduardo A. Bustamante L?pez added the comment: Hi Senthil, > I fail to see the bug in here. Robotparser module is for reading and > parsing the robot.txt file, the module responsible for fetching it > could urllib. You're right, but robotparser's read() does a call to urllib.request.urlopen to fetch the robots.txt file. If robotparser took a file object, or something like that instead of a Url, I wouldn't think of this as a bug, but it doesn't. The default behaviour is for it to fetch the file itself, using urlopen. Also, I'm aware that you shouldn't normally worry about setting a specific user-agent to fetch the file. But that's not the case of Wikipedia. In my case, Wikipedia returned 403 for the urllib user-agent. And since there's no documented way of specifying a particular user-agent in robotparser, or to feed a file object to robotparser, I decided to report this. Only after reading the source of 2.7.x and 3.x, one can find work-arounds for that problem, since it's not really clear how these make the requests for the robots.txt in the documentation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 08:55:48 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 11 Sep 2012 06:55:48 +0000 Subject: [issue15882] _decimal.Decimal constructed from tuple In-Reply-To: <1347132407.81.0.728702066463.issue15882@psf.upfronthosting.co.za> Message-ID: <20120911065548.GA26639@sleipnir.bytereef.org> Stefan Krah added the comment: Thanks for the report and the patch. I used another approach that still validates the digits in the coefficient tuple even if it is not used. decimal.py allows any coefficient: >>> Decimal((0, ('n', 'a', 'n'), 'F')) Decimal('Infinity') _decimal raises: >>> Decimal((0, ('n', 'a', 'n'), 'F')) Traceback (most recent call last): File "", line 1, in ValueError: coefficient must be a tuple of digits I'm leaving the issue open: If some release blocker arises, we could get this into 3.3.0-rc3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 08:56:50 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 11 Sep 2012 06:56:50 +0000 Subject: [issue15882] _decimal.Decimal constructed from tuple In-Reply-To: <1347058075.63.0.395926246222.issue15882@psf.upfronthosting.co.za> Message-ID: <1347346610.66.0.016985007761.issue15882@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- resolution: -> fixed stage: -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 09:11:29 2012 From: report at bugs.python.org (Andrew Moffat) Date: Tue, 11 Sep 2012 07:11:29 +0000 Subject: [issue15898] OSX TTY bug In-Reply-To: <1347238694.31.0.649838162085.issue15898@psf.upfronthosting.co.za> Message-ID: <1347347489.99.0.712013874119.issue15898@psf.upfronthosting.co.za> Andrew Moffat added the comment: Sorry about that, I refactored out the string at the last minute and typed "testing123" instead of the original "testing" from the trace. I'm not sure I follow the problem exactly. So you're saying that the failing version uses _cancel sys calls, and that __pthread_testcancel may result in EINTR. But that this is not happening in the trace, and data is being written successfully. I guess I'm wondering where the written bytes went and if there's any way to retrieve them? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 09:22:29 2012 From: report at bugs.python.org (Vitaly) Date: Tue, 11 Sep 2012 07:22:29 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za> Message-ID: <1347348149.34.0.995608971096.issue15896@psf.upfronthosting.co.za> Vitaly added the comment: I wrote a C-language program to reproduce this issue on Mac OS without Python. It reproduces the issue in both increasing and decreasing order of initial read sizes, and it reliably reproduces it for each KB from 128KB to 1024KB ; the Python version reproduced the issue every 4K and only in decreasing order (probably something related to Python's memory management optimizations). A new caveat: if the read buffer is allocated once before entering the read loop, then we don't get any EINVAL in the entire run; however, if the read buffer is allocated for each read request inside the loop, then we get EINVAL every other time in the range from 128KB and up. I would like to file this issue with apple/Mac OS. What's the appropriate URL for this? ---------- Added file: http://bugs.python.org/file27172/test_fork_pipe_error.cpp _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 09:22:48 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 11 Sep 2012 07:22:48 +0000 Subject: [issue15913] PyBuffer_SizeFromFormat is missing In-Reply-To: <1347312444.09.0.484126652005.issue15913@psf.upfronthosting.co.za> Message-ID: <1347348168.6.0.224363534596.issue15913@psf.upfronthosting.co.za> Stefan Krah added the comment: Even though it's documented, the function is probably a new feature and should go into 3.4. Meanwhile, you can call struct.calcsize(format). Any non-trivial implementation of PyBuffer_SizeFromFormat() would likely do the same. ---------- components: +Interpreter Core -None nosy: +skrah type: -> enhancement versions: +Python 3.4 -Python 2.7, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 09:23:18 2012 From: report at bugs.python.org (Vitaly) Date: Tue, 11 Sep 2012 07:23:18 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za> Message-ID: <1347348198.72.0.703873217673.issue15896@psf.upfronthosting.co.za> Vitaly added the comment: The C-language program for reproducing the same issue is attached as test_fork_pipe_error.cpp ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 09:27:54 2012 From: report at bugs.python.org (Vitaly) Date: Tue, 11 Sep 2012 07:27:54 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za> Message-ID: <1347348474.45.0.881651759964.issue15896@psf.upfronthosting.co.za> Vitaly added the comment: I used g++ to compile test_fork_pipe_error.cpp on both Mac OS and on Linux. EINVAL showed up only on Mac OS. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 09:32:17 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 11 Sep 2012 07:32:17 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za> Message-ID: <1347348737.86.0.58448198006.issue15896@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: > The reason I said above that those might be red-herring discoveries is this: if I insert a short time.sleep(0.001) delay before the outer pipe-read loop, the EINVAL errors don't get triggered either. That's interesting. So it really seems that under certain conditions, a non-blocking read from an empty pipe could fail with EINVAL instead of EAGAIN. But this is definitely a bug, in such cases read() should return EAGAIN. > 1. Why doesn't the test encounter EINVAL in the range 127KB ... 1KB (when iterating initialReadSize in *decreasing* order). If the pre-read delay is significant, then does it take significantly more time to allocate a 127KB chunk of memory than it does a 128KB chunk? > > 2. Why doesn't the test encounter EINVAL at all when iterating initialReadSize in *increasing* order? I'm not sure it's a delay issue in this case. It may have more to do with the aligment of the buffer passed to read(). You can for example imagine that this error would show up only when the buffer is (or is not) aligned on a page boundary (usually 4K). As for the gap between 127KB and 128KB, it could be that we're allocating a new arena (we have a custom memory allocator over malloc()/mmap()), or that we switch between brk() and mmap(), but that's mere speculation, and there's nothing we can (and should) do here. I'm not sure about what to do with this, though: - adding a delay is out of question - retrying on EINVAL like on EAGAIN is not a good idead, since it could mask real bugs One thing we could do would be to limit the the call to read() to, let's say 64KB per call: """ newData = os.read(errpipe_read, min(65536, rSize)) """ But this would only work here, there are probably other places where this bug could be encountered (and I don't like adding hacks to avoid platform bugs). > I wrote a C-language program to reproduce this issue on Mac OS without Python. > I would like to file this issue with apple/Mac OS. What's the appropriate URL for this? > I used g++ to compile test_fork_pipe_error.cpp on both Mac OS and on Linux. EINVAL showed up only on Mac OS. Told you it was an OS-X bug (we've had several of those) ;-) As for where to report it, I'm making some OS-X enclined devs nosy. I'm suggest closing this bug as invalid (unless someone considers that we should try to work around it with the above trick). ---------- nosy: +hynek, ned.deily, ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 09:32:39 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 11 Sep 2012 07:32:39 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za> Message-ID: <1347348759.16.0.50797310974.issue15896@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 09:44:06 2012 From: report at bugs.python.org (Vitaly) Date: Tue, 11 Sep 2012 07:44:06 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za> Message-ID: <1347349446.98.0.496451846522.issue15896@psf.upfronthosting.co.za> Vitaly added the comment: By the way, the existing code in subprocess.Popen (at least on 2.6.7) reads the pipe incorrectly: It doesn't loop to read all the data until EOF -- it only loops over EINTR until it gets a single successful os.read() call. However, since this is a pipe read (not a real file read), the system doesn't guarantee that the blocking read will read everything up to requested read size or EOF, whichever comes first. So, the single os.read call could return a partial read, and the subsequent un-pickling of the exception would fail. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 09:54:41 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 11 Sep 2012 07:54:41 +0000 Subject: [issue15851] Lib/robotparser.py doesn't accept setting a user agent string, instead it uses the default. In-Reply-To: <20120911054504.GA1146@claret.lan> Message-ID: Senthil Kumaran added the comment: Hi Eduardo, I tested further and do observe some very strange oddities. On Mon, Sep 10, 2012 at 10:45 PM, Eduardo A. Bustamante L?pez wrote: > Also, I'm aware that you shouldn't normally worry about setting a specific > user-agent to fetch the file. But that's not the case of Wikipedia. In my case, > Wikipedia returned 403 for the urllib user-agent. Yeah, this really surprised me. I would normally assume robots.txt to be readable by any agent, but I think something odd is happening. In 2.7, I do not see the problem because, the implementation is: import urllib class URLOpener(urllib.FancyURLopener): def __init__(self, *args): urllib.FancyURLopener.__init__(self, *args) self.errcode = 200 opener = URLOpener() fobj = opener.open('http://en.wikipedia.org/robots.txt') print opener.errcode This will print 200 and everything is fine. Also, look at it that robots.txt is accessible. In 3.3, the implementation is: import urllib.request try: fobj = urllib.request.urlopen('http://en.wikipedia.org/robots.txt') except urllib.error.HTTPError as err: print(err.code) This gives 403. I would normally expect this to work without any issues. But according to my analysis, what is happening is when the User-agent is set to something which has '-' in that, the server is rejecting it with 403. In the above code, what is happening underlying is this: import urllib.request opener = urllib.request.build_opener() opener.addheaders = [('User-agent', 'Python-urllib/3.3')] fobj = opener.open('http://en.wikipedia.org/robots.txt') print(fobj.getcode()) This would give 403. In order to see it work, change the addheaders line to opener.addheaders = [('', '')] opener.addheaders = [('User-agent', 'Pythonurllib/3.3')] opener.addheaders = [('User-agent', 'KillerSpamBot')] All should work (as expected). So, thing which surrprises me is, if sending "Python-urllib/3.3" is a mistake for "THAT Server". Is this a server oddity at Wikipedia part? ( Coz, I refered to hg log to see from when we are sending Python-urllib/version and it seems that it's being sent for long time). Can't see how should this be fixed in urllib. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 10:18:35 2012 From: report at bugs.python.org (Vitaly) Date: Tue, 11 Sep 2012 08:18:35 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za> Message-ID: <1347351515.21.0.748737564783.issue15896@psf.upfronthosting.co.za> Vitaly added the comment: I filed this issue with apple: Problem ID: 12274650: https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa/64/wo/VE1RGG9qEL5OS9KdzFSDHw/19.66 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 10:19:59 2012 From: report at bugs.python.org (Vitaly) Date: Tue, 11 Sep 2012 08:19:59 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za> Message-ID: <1347351599.24.0.50469131311.issue15896@psf.upfronthosting.co.za> Vitaly added the comment: Apple bug report URL correction: https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa/64/wo/VE1RGG9qEL5OS9KdzFSDHw/17.66 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 10:23:23 2012 From: report at bugs.python.org (Vitaly) Date: Tue, 11 Sep 2012 08:23:23 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za> Message-ID: <1347351803.95.0.77101651425.issue15896@psf.upfronthosting.co.za> Vitaly added the comment: Sorry, I don't know why the URL comes out all messed up. I can't seem to find the correct syntax for this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 10:38:33 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 11 Sep 2012 08:38:33 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347349446.98.0.496451846522.issue15896@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > By the way, the existing code in subprocess.Popen (at least on 2.6.7) reads the pipe incorrectly: It doesn't loop to read all the data until EOF -- it only loops over EINTR until it gets a single successful os.read() call. However, since this is a pipe read (not a real file read), the system doesn't guarantee that the blocking read will read everything up to requested read size or EOF, whichever comes first. So, the single os.read call could return a partial read, and the subsequent un-pickling of the exception would fail. Indeed. Do you want to open a new issue for that (and provide a patch)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 11:06:17 2012 From: report at bugs.python.org (Vitaly) Date: Tue, 11 Sep 2012 09:06:17 +0000 Subject: [issue15918] subprocess.Popen reads errpipe_read incorrectly, can result in short read Message-ID: <1347354377.74.0.358322632323.issue15918@psf.upfronthosting.co.za> New submission from Vitaly: subprocess.Popen (at least on 2.6.7) reads the pipe incorrectly: It doesn't loop to read all the data until EOF -- it only loops over EINTR until it gets a single successful os.read() call. However, since this is a pipe read (not a real file read), the system doesn't guarantee that the blocking read will read everything up to requested read size or EOF, whichever comes first. So, the single os.read call could return a partial read, and the subsequent un-pickling of the exception would fail/crash. Sorry, I can't submit a patch as I am merely a Python user, not a Python developer, and it would take me too long to set up and figure out Python build just for this one issue. ---------- components: Library (Lib) messages: 170279 nosy: vitaly priority: normal severity: normal status: open title: subprocess.Popen reads errpipe_read incorrectly, can result in short read type: crash versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 11:07:44 2012 From: report at bugs.python.org (Vitaly) Date: Tue, 11 Sep 2012 09:07:44 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za> Message-ID: <1347354464.41.0.590577323077.issue15896@psf.upfronthosting.co.za> Vitaly added the comment: Filed http://bugs.python.org/issue15918 for the incorrect pipe read logic in subprocess.Popen. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 11:08:21 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 11 Sep 2012 09:08:21 +0000 Subject: [issue15887] urlencode should accept generators or two elements tuples In-Reply-To: <1347185937.29.0.747427121658.issue15887@psf.upfronthosting.co.za> Message-ID: <1347354501.8.0.970244066149.issue15887@psf.upfronthosting.co.za> Senthil Kumaran added the comment: This is a feature request. urlencode tries to prepare the data in the form items are submitted. It has been like form is list of key,value pairs and that's what is reflect in the current behavior. That said, I am not -1 if see if some frameworks adopting generator approach or if it cna considered useful without any confusion. I still have soem doubts, namely if it can be just key,value pairs then why have a list at all? ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 11:20:25 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 11 Sep 2012 09:20:25 +0000 Subject: [issue11943] Add TLS-SRP (RFC 5054) support to ssl, _ssl, http, and urllib In-Reply-To: <1347306077.6.0.292329621079.issue11943@psf.upfronthosting.co.za> Message-ID: Senthil Kumaran added the comment: 2012/9/10 Jes?s Cea Avi?n : > > Ping!. Guess, it is still for 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 12:14:58 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 11 Sep 2012 10:14:58 +0000 Subject: [issue15899] howto/unicode.rst doctest corrections In-Reply-To: <1347267933.09.0.504282046374.issue15899@psf.upfronthosting.co.za> Message-ID: Senthil Kumaran added the comment: Thanks!. Verified the patch, it is fine and can be applied directly on 3.2 and 3.3 branch. Tested it as well. On 2.7, some changes would be required. ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 12:20:31 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 11 Sep 2012 10:20:31 +0000 Subject: [issue15899] howto/unicode.rst doctest corrections In-Reply-To: <1347267716.91.0.310284408834.issue15899@psf.upfronthosting.co.za> Message-ID: <3XGMZk1gVxzQ9W@mail.python.org> Roundup Robot added the comment: New changeset 8a40bc71c072 by Senthil Kumaran in branch '3.2': Fix issue #15899: Make the unicode.rst doctests pass. Patch by Chris Jerdonek. http://hg.python.org/cpython/rev/8a40bc71c072 New changeset 1d9e89f6abec by Senthil Kumaran in branch 'default': merge. Fix issue #15899: Make the unicode.rst doctests pass. Patch by Chris Jerdonek. http://hg.python.org/cpython/rev/1d9e89f6abec ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 12:28:46 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 11 Sep 2012 10:28:46 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za> Message-ID: <1347359326.31.0.701894142631.issue15896@psf.upfronthosting.co.za> Ronald Oussoren added the comment: What's wrong with working around this bug by reading a smaller amount? How much data is there supposed to be? BTW. URLs for reports in Apple's tracker are fairly useless as bugreports are private (only you and Apple's engineers can see the report). The bug number is useful though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 12:30:11 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 11 Sep 2012 10:30:11 +0000 Subject: [issue15899] howto/unicode.rst doctest corrections In-Reply-To: <1347267716.91.0.310284408834.issue15899@psf.upfronthosting.co.za> Message-ID: <1347359411.85.0.368078247221.issue15899@psf.upfronthosting.co.za> Senthil Kumaran added the comment: I shall make the changes 2.7, keeping this open for that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 12:50:27 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 11 Sep 2012 10:50:27 +0000 Subject: [issue15899] howto/unicode.rst doctest corrections In-Reply-To: <1347267716.91.0.310284408834.issue15899@psf.upfronthosting.co.za> Message-ID: <1347360627.57.0.849985766691.issue15899@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks, Senthil! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 12:57:17 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 11 Sep 2012 10:57:17 +0000 Subject: [issue15888] ipaddress doctest examples have some errors In-Reply-To: <1347190349.96.0.156720503481.issue15888@psf.upfronthosting.co.za> Message-ID: <1347361037.33.0.305845411148.issue15888@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Adding Eli to this because he did some work on the HOWTO for this module in issue 14814. ---------- nosy: +eli.bendersky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 13:00:46 2012 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Tue, 11 Sep 2012 11:00:46 +0000 Subject: [issue15803] Incorrect docstring on ConfigParser.items() In-Reply-To: <1346202745.06.0.103510250689.issue15803@psf.upfronthosting.co.za> Message-ID: <1347361246.01.0.178732608932.issue15803@psf.upfronthosting.co.za> Changes by ?ukasz Langa : ---------- assignee: -> lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 13:04:37 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 11 Sep 2012 11:04:37 +0000 Subject: [issue15917] hg hook to detect unmerged changesets In-Reply-To: <1347340391.86.0.248701031918.issue15917@psf.upfronthosting.co.za> Message-ID: <1347361477.01.0.50123101897.issue15917@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 13:06:22 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 11 Sep 2012 11:06:22 +0000 Subject: [issue15917] hg hook to detect unmerged changesets In-Reply-To: <1347340391.86.0.248701031918.issue15917@psf.upfronthosting.co.za> Message-ID: <1347361582.93.0.906778594323.issue15917@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: We need something like this. I can not review, I am not familiar with mercurial hooks internals. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 13:28:20 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 11 Sep 2012 11:28:20 +0000 Subject: [issue15919] hg.python.org: log page entries don't always link to revision Message-ID: <1347362900.6.0.139284928383.issue15919@psf.upfronthosting.co.za> New submission from Chris Jerdonek: On hg.python.org, it seems like the entries on the "log" page don't always link to the corresponding revision, for example some of the rows in-- http://hg.python.org/cpython/shortlog/1d9e89f6abec This seems to happen whenever the revision description begins with text that results in a link to something else (e.g. an issue number). See, for example, the row for-- "#15886: remove redundant phrase" In contrast, the "graph" page seems always to link to the revision: http://hg.python.org/cpython/graph Related to this, if the description field contains text that results in a link to something else, then the UI doesn't make a distinction between the portion of the description that links to the revision and the portion that links to the something else. For example, with description text "Fix for fcc629208842", "Fix for" links to the revision for the log entry, but "fcc629208842" links to the named revision, and there is no separation or visual indicator that the two portions of text link to different things. It might be better if the revision link was separate from the description text. That would be one way to address both of the issues above. (This was originally posted to python-dev here: http://mail.python.org/pipermail/python-dev/2012-September/121635.html ) ---------- messages: 170290 nosy: cjerdonek, ezio.melotti, pitrou priority: normal severity: normal status: open title: hg.python.org: log page entries don't always link to revision _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 13:35:51 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 11 Sep 2012 11:35:51 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1347363351.07.0.553173579574.issue15533@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Andrew, do you think my changes to the patch are adequate given the response on python-dev to your question? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 13:59:59 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 11 Sep 2012 11:59:59 +0000 Subject: [issue15917] hg hook to detect unmerged changesets In-Reply-To: <1347340391.86.0.248701031918.issue15917@psf.upfronthosting.co.za> Message-ID: <1347364799.23.0.889264844817.issue15917@psf.upfronthosting.co.za> Christian Heimes added the comment: +1 for the feature ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 14:03:34 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 11 Sep 2012 12:03:34 +0000 Subject: [issue15900] Memory leak in PyUnicode_TranslateCharmap() In-Reply-To: <1347271102.51.0.468950657705.issue15900@psf.upfronthosting.co.za> Message-ID: <3XGPsd5JRxzQKZ@mail.python.org> Roundup Robot added the comment: New changeset 4f2811e5e462 by Christian Heimes in branch 'default': Issue #15900: Fixed reference leak in PyUnicode_TranslateCharmap() http://hg.python.org/cpython/rev/4f2811e5e462 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 14:05:27 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 11 Sep 2012 12:05:27 +0000 Subject: [issue15900] Memory leak in PyUnicode_TranslateCharmap() In-Reply-To: <1347271102.51.0.468950657705.issue15900@psf.upfronthosting.co.za> Message-ID: <1347365127.4.0.813941526961.issue15900@psf.upfronthosting.co.za> Christian Heimes added the comment: Yes, 3.2 and earlier are not affected. Georg, I'm assigning the bug to you so you can decide if you like to cherry pick the fix. ---------- assignee: -> georg.brandl nosy: +georg.brandl resolution: -> fixed stage: -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 14:07:30 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 11 Sep 2012 12:07:30 +0000 Subject: [issue15920] make howto/regex.rst doctests pass Message-ID: <1347365250.51.0.50908200461.issue15920@psf.upfronthosting.co.za> New submission from Chris Jerdonek: This issue is to make the doctests in howto/regex.rst pass using vanilla doctest. After this issue, 10 out of the 17 HOWTO's will pass with vanilla doctest. Patch attached. ---------- assignee: docs at python components: Documentation files: issue-doctest-howto-regex-1.patch keywords: patch messages: 170295 nosy: cjerdonek, docs at python, orsenthil priority: normal severity: normal stage: patch review status: open title: make howto/regex.rst doctests pass versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file27173/issue-doctest-howto-regex-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 14:12:33 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 11 Sep 2012 12:12:33 +0000 Subject: [issue15895] PyRun_SimpleFileExFlags() can leak a FILE pointer In-Reply-To: <1347231050.54.0.0211027720618.issue15895@psf.upfronthosting.co.za> Message-ID: <3XGQ3z69BszQC3@mail.python.org> Roundup Robot added the comment: New changeset 4754c4a710e6 by Christian Heimes in branch 'default': Issue #15895: Fix FILE pointer leak in PyRun_SimpleFileExFlags() when filename points to a pyc/pyo file and closeit is false. http://hg.python.org/cpython/rev/4754c4a710e6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 14:13:50 2012 From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Anjos?=) Date: Tue, 11 Sep 2012 12:13:50 +0000 Subject: [issue13773] Support sqlite3 uri filenames In-Reply-To: <1326313998.63.0.583537561643.issue13773@psf.upfronthosting.co.za> Message-ID: <1347365630.32.0.28607588312.issue13773@psf.upfronthosting.co.za> Andr? Anjos added the comment: A question concerning this patch: is this going to be applied only to 3.3 or to 2.7 as well? Python-2.7.x also does not have this functionality which would be interesting to get. ---------- nosy: +anjos _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 14:15:11 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 11 Sep 2012 12:15:11 +0000 Subject: [issue15895] PyRun_SimpleFileExFlags() can leak a FILE pointer In-Reply-To: <1347231050.54.0.0211027720618.issue15895@psf.upfronthosting.co.za> Message-ID: <1347365711.45.0.7219911733.issue15895@psf.upfronthosting.co.za> Christian Heimes added the comment: The bug was a 3.3 regression, possibly introduced with the merge of importlib. I forgot to tick the 3,3regression keyword. I've applied the fix. I'm leaving this ticket open and assigned to Georg for 3.3.0. ---------- keywords: +3.3regression resolution: -> fixed stage: patch review -> committed/rejected versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 14:46:34 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 11 Sep 2012 12:46:34 +0000 Subject: [issue15921] select module uses uninitialized value "tv.tv_usec" Message-ID: <1347367594.05.0.129732037388.issue15921@psf.upfronthosting.co.za> New submission from Christian Heimes: Starting with Python 3.3 the select module access the uninitialized tv.tv_usec member of a timeval struct. I don't see the point of initializing the local variable long tv_usec from tv.tv_usec. The comment above the code states that long tv_usec is required as a workaround for Mac OS X. http://hg.python.org/cpython/file/4754c4a710e6/Modules/selectmodule.c#l242 Coverity message: CID 719694: Uninitialized scalar variable (UNINIT)At (5): Using uninitialized value "tv.tv_usec". 242 long tv_usec = tv.tv_usec; 243 if (_PyTime_ObjectToTimeval(tout, &tv.tv_sec, &tv_usec) == -1) 244 return NULL; 245 tv.tv_usec = tv_usec; Suggested fix: change line 242 to "long tv_usec;" ---------- keywords: 3.3regression messages: 170299 nosy: christian.heimes priority: normal severity: normal stage: patch review status: open title: select module uses uninitialized value "tv.tv_usec" type: resource usage versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 14:50:29 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 11 Sep 2012 12:50:29 +0000 Subject: [issue15912] Intermittent import failure In-Reply-To: <1347306488.32.0.579862468215.issue15912@psf.upfronthosting.co.za> Message-ID: <1347367829.09.0.326845573163.issue15912@psf.upfronthosting.co.za> Brett Cannon added the comment: I don't think sys.modules is the right place about a warning regarding importlib.invalidate_caches(); this has nothing to do with sys.modules but instead import itself. Probably something more along those lines would be more fitting. This is also mentioned the 3.3 What's New on how to port your code, so at least that's covered. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 15:09:40 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 11 Sep 2012 13:09:40 +0000 Subject: [issue15911] can't step through _frozen_importlib/importlib._bootstrap using gdb In-Reply-To: <1347305436.8.0.778141669429.issue15911@psf.upfronthosting.co.za> Message-ID: <1347368980.79.0.300695408958.issue15911@psf.upfronthosting.co.za> Brett Cannon added the comment: I'm going to guess this is a shortcoming of pdb when it comes to frozen modules as I can get to the source using inspect (which pdb leans on):: >>> len(inspect.findsource(_frozen_importlib)[0]) 1761 >>> len(inspect.findsource(importlib._bootstrap)[0]) 1761 Which are accurate line counts:: $ wc Lib/importlib/_bootstrap.py 1761 6236 62517 Lib/importlib/_bootstrap.py So why gdb can't output the source line when it has the line number of the file I don't know when it can already get access to the source without issue. And yes, debugging imports are hard. =) Still, it's better than before as you can easily toss in a print statement or two and then just regenerate the frozen object. But I do agree it would be nice to get gdb to play along with the whole situation (and thus the title change for this bug). ---------- nosy: +brett.cannon stage: -> test needed title: Debugging import problems is hard -> can't step through _frozen_importlib/importlib._bootstrap using gdb type: -> behavior versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 15:14:21 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 11 Sep 2012 13:14:21 +0000 Subject: [issue15719] Sort dict items in urlencode() In-Reply-To: <1345236293.12.0.120802358061.issue15719@psf.upfronthosting.co.za> Message-ID: <1347369261.01.0.0454355262165.issue15719@psf.upfronthosting.co.za> Chris Jerdonek added the comment: As an aside, I noticed a doctest affected by this in the urllib HOWTO: >>> url_values = urllib.parse.urlencode(data) >>> print(url_values) name=Somebody+Here&language=Python&location=Northampton http://docs.python.org/dev/howto/urllib2.html#data (search for the string "Somebody"). This is merely a curiosity though (i.e. don't construe this as an argument on the issue :)). ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 15:15:13 2012 From: report at bugs.python.org (Michael Foord) Date: Tue, 11 Sep 2012 13:15:13 +0000 Subject: [issue15860] Use TestCase assertion methods in unittest.mock.assert* to make them easier to read In-Reply-To: <1346764020.36.0.830519299083.issue15860@psf.upfronthosting.co.za> Message-ID: <1347369313.76.0.883087930195.issue15860@psf.upfronthosting.co.za> Michael Foord added the comment: Yep, interesting idea. In Python 3 you can't import unittest.mock without importing unittest, so there could even be a "default testcase" to fall back on. For the external release I'd rather not have unittest as a dependency, but allowing a testcase to be provided at instantiation would be fine. ---------- assignee: -> michael.foord _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 15:15:38 2012 From: report at bugs.python.org (Michael Foord) Date: Tue, 11 Sep 2012 13:15:38 +0000 Subject: [issue15860] Use TestCase assertion methods in unittest.mock.assert* to make them easier to read In-Reply-To: <1346764020.36.0.830519299083.issue15860@psf.upfronthosting.co.za> Message-ID: <1347369338.1.0.190957027663.issue15860@psf.upfronthosting.co.za> Michael Foord added the comment: The only issue is that the testcase would have to be propagated to child mocks too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 15:28:23 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 11 Sep 2012 13:28:23 +0000 Subject: [issue15922] make howto/urllib2.rst doctests pass Message-ID: <1347370103.61.0.784697754485.issue15922@psf.upfronthosting.co.za> New submission from Chris Jerdonek: This issue is to make the doctests in howto/urllib2.rst pass using vanilla doctest. Patch attached. ---------- assignee: docs at python components: Documentation files: issue-doctest-howto-urllib-1.patch keywords: easy, patch messages: 170305 nosy: cjerdonek, docs at python, orsenthil priority: normal severity: normal status: open title: make howto/urllib2.rst doctests pass versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file27174/issue-doctest-howto-urllib-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 15:28:34 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 11 Sep 2012 13:28:34 +0000 Subject: [issue15922] make howto/urllib2.rst doctests pass In-Reply-To: <1347370103.61.0.784697754485.issue15922@psf.upfronthosting.co.za> Message-ID: <1347370114.49.0.921856082366.issue15922@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 15:47:39 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 11 Sep 2012 13:47:39 +0000 Subject: [issue15895] PyRun_SimpleFileExFlags() can leak a FILE pointer In-Reply-To: <1347231050.54.0.0211027720618.issue15895@psf.upfronthosting.co.za> Message-ID: <3XGS9k27JMzQK4@mail.python.org> Roundup Robot added the comment: New changeset c3539eb02470 by Christian Heimes in branch 'default': Issue #15895: my analysis was slightly off. The FILE pointer is only leaked when set_main_loader() fails for a pyc file with closeit=0. In the success case run_pyc_file() does its own cleanup of the fp. I've changed the code to use another FILE ptr for pyc files and moved the fclose() to PyRun_SimpleFileExFlags() to make it more obvious what's happening. http://hg.python.org/cpython/rev/c3539eb02470 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 15:52:55 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 11 Sep 2012 13:52:55 +0000 Subject: [issue11943] Add TLS-SRP (RFC 5054) support to ssl, _ssl, http, and urllib In-Reply-To: <1303943331.28.0.343800117154.issue11943@psf.upfronthosting.co.za> Message-ID: <1347371575.55.0.716293496244.issue11943@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Yes, 3.4. I would hate to rush, in two years, because this issue was neglected during 18 months :) No reason for not starting now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 16:05:25 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 11 Sep 2012 14:05:25 +0000 Subject: [issue11943] Add TLS-SRP (RFC 5054) support to ssl, _ssl, http, and urllib In-Reply-To: <1347371575.55.0.716293496244.issue11943@psf.upfronthosting.co.za> Message-ID: <1347372308.3367.2.camel@localhost.localdomain> Antoine Pitrou added the comment: Le mardi 11 septembre 2012 ? 13:52 +0000, Jes?s Cea Avi?n a ?crit : > No reason for not starting now. There's no point in being pushy, though. If you want to "start", the best thing is to work on the patch and update it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 16:39:26 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 11 Sep 2012 14:39:26 +0000 Subject: [issue15917] hg hook to detect unmerged changesets In-Reply-To: <1347340391.86.0.248701031918.issue15917@psf.upfronthosting.co.za> Message-ID: <1347374366.83.0.784749555228.issue15917@psf.upfronthosting.co.za> Ezio Melotti added the comment: Attached a set up script to reproduce a test environment for the hook. Create an empty dir and run ``sh setup.sh`` in it. This will: 1) create a 'c1' subdir which is a cpython-like repo with the branches 2.7, 3.1, 3.2, default; 2) download and set up the hook for this repo; 3) create a 'c2' clone of 'c1'; Once the clones are created, cd in 'c2', try to commit something, and push it. Use `hg up ` to switch between branches. If you `hg up 3.1`, change something, commit, and push, the hook will tell you that you have to merge with 3.2, if you do the same on 3.2 it will say you have to merge with default. You can try unusual combinations (e.g. null merges, rollbacks, multiple commits per branch, etc.) to see how well the hook works. ---------- Added file: http://bugs.python.org/file27175/setup.sh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 16:42:38 2012 From: report at bugs.python.org (Eric Snow) Date: Tue, 11 Sep 2012 14:42:38 +0000 Subject: [issue15912] Intermittent import failure In-Reply-To: <1347306488.32.0.579862468215.issue15912@psf.upfronthosting.co.za> Message-ID: <1347374558.96.0.471764418893.issue15912@psf.upfronthosting.co.za> Eric Snow added the comment: The relationship between invalidate_caches() and sys.modules is definitely tenuous. However, my rationale was that people would look for an explanation on why modifying sys.modules was not working as expected. The sys.modules doc entry was the one that seemed to make the most sense. However, this is a pretty uncommon case and you're right that the What's New entry should be enough. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 17:00:36 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 11 Sep 2012 15:00:36 +0000 Subject: [issue15860] Use TestCase assertion methods in unittest.mock.assert* to make them easier to read In-Reply-To: <1346764020.36.0.830519299083.issue15860@psf.upfronthosting.co.za> Message-ID: <1347375636.79.0.153330297619.issue15860@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 17:02:41 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 11 Sep 2012 15:02:41 +0000 Subject: [issue13773] Support sqlite3 uri filenames In-Reply-To: <1326313998.63.0.583537561643.issue13773@psf.upfronthosting.co.za> Message-ID: <1347375761.88.0.978313565332.issue13773@psf.upfronthosting.co.za> ?ric Araujo added the comment: 2.7 and 3.2 are stable versions which only get bug fixes. 3.3 is in release candidate stage, so this new feature can only go into 3.4. See the devguide and PEPs for more info about the process we follow. ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 17:16:32 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 11 Sep 2012 15:16:32 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347376592.28.0.212655487579.issue15906@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Okay, this bug is clearly caused by the patch applied for issue 12776. Here's the patch set url: http://hg.python.org/cpython/rev/74f6d87cd471 Now, if you look at this, I think this changes the semantics for non-string default with a type converter, but the question then becomes, what is the intended semantics? The documentation at: http://docs.python.org/py3k/library/argparse.html#the-add-argument-method says: type - The type to which the command-line argument should be converted. Okay, that makes perfect sense, because the command line arguments will always be strings in need of conversion. What *doesn't* make sense, IMHO, is that the type conversion should be applied to the default value. This is not documented behavior, but more importantly, is unnecessary, because the .add_argument() call site can just as easily provide a default that's already been converted. However, if you do this with the change, then the default value will get converted twice, once explicitly at the .add_argument() call site, and again, implicitly by argparse. Also, as this bug report indicates, it then becomes impossible to provide a default that is not converted. So I believe that the test added for issue 12776 is not correct (specifically test_type_function_call_with_non_string_default), and should be removed. I'm not even sure the original analysis of that bug is correct, but there is a serious semantic ambiguity that needs to be resolved. Specifically, should you support both the use case given in that bug and this bug's use case, and if so, how? E.g. should you even expect this to work: .add_argument('--foo', type=open, default='/etc/passwd') ? Maybe another way to look at it is that the conversion should only happen if the action is 'store'. It definitely should not happen if the action is 'append'. Let's say that the latter is the intended semantics. Attached is a patch that implements these semantics, with a test. If approved, I think we also need to describe the exact semantics in the documentation. I will do that, add a NEWS entry, and back port. ---------- keywords: +patch Added file: http://bugs.python.org/file27176/15906-1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 17:17:11 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 11 Sep 2012 15:17:11 +0000 Subject: [issue15914] multiprocessing.SyncManager connection hang In-Reply-To: <1347312588.21.0.484965926655.issue15914@psf.upfronthosting.co.za> Message-ID: <1347376631.75.0.88661504355.issue15914@psf.upfronthosting.co.za> Richard Oudkerk added the comment: I get the same hang on Linux with Python 3.2. For Windows the documentation does warn against starting a process as a side effect of importing a process. There is no explicit warning for Unix, but I would still consider it bad form to do such things as a side effect of importing a module. It appears that it is the import of the hmac module inside deliver_challenge() that is hanging. I expect forking a process while an import is in progress may cause the import machinery (which I am not familiar with) to be in an inconsistent state. The import lock should have been reset automatically after the fork, but maybe that is not enough. Maybe the fact that the import is being done by a non-main thread is relevant. I would suggest just rewriting the code as create.py: import multiprocessing def main(): manager = multiprocessing.Manager() namespace = manager.Namespace() print("create.py complete") if __name__ == '__main__': main() run.py: import create create.main() print("run.py complete") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 17:26:44 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 11 Sep 2012 15:26:44 +0000 Subject: [issue15914] multiprocessing.SyncManager connection hang In-Reply-To: <1347312588.21.0.484965926655.issue15914@psf.upfronthosting.co.za> Message-ID: <1347377204.88.0.766571265064.issue15914@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Here is a reproduction without using multiprocessing: create.py: import threading, os def foo(): print("Trying import") import sys print("Import successful") pid = os.fork() if pid == 0: try: t = threading.Thread(target=foo) t.start() t.join() finally: os._exit(0) os.waitpid(pid, 0) print("create.py complete") run.py: import create print("run.py complete") Using python2.7 and python3.3 this works as expected, but with python3.2 I get user at mint-vm /tmp $ python3 create.py Trying import Import successful create.py complete user at mint-vm /tmp $ python3 run.py Trying import ^CTraceback (most recent call last): File "run.py", line 1, in import create File "/tmp/create.py", line 17, in os.waitpid(pid, 0) KeyboardInterrupt ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 17:27:27 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 11 Sep 2012 15:27:27 +0000 Subject: [issue15914] multiprocessing.SyncManager connection hang In-Reply-To: <1347312588.21.0.484965926655.issue15914@psf.upfronthosting.co.za> Message-ID: <1347377247.54.0.507209778874.issue15914@psf.upfronthosting.co.za> Changes by Richard Oudkerk : ---------- type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 17:52:52 2012 From: report at bugs.python.org (Vitaly) Date: Tue, 11 Sep 2012 15:52:52 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za> Message-ID: <1347378772.36.0.335567578428.issue15896@psf.upfronthosting.co.za> Vitaly added the comment: > What's wrong with working around this bug by reading a smaller amount? How much data is there supposed to be? This makes sense for working around the issue. Even in the blocking-read case, such as in subprocess.Popen, attempting to read a 1MB chunk of data in a single os.read call is unhelpful anyway - see http://bugs.python.org/issue15918. Also, the 1MB read forces os.read() to unnecessarily allocate a huge !MB buffer (even if only for a short lifetime) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 17:56:08 2012 From: report at bugs.python.org (Vitaly) Date: Tue, 11 Sep 2012 15:56:08 +0000 Subject: [issue15918] subprocess.Popen reads errpipe_read incorrectly, can result in short read In-Reply-To: <1347354377.74.0.358322632323.issue15918@psf.upfronthosting.co.za> Message-ID: <1347378968.67.0.51861041889.issue15918@psf.upfronthosting.co.za> Vitaly added the comment: Also, attempting to read a 1MB chunk of data in a single os.read call forces os.read() to unnecessarily allocate a huge !MB buffer (even if only for a short lifetime). Using something like 4KB read calls in a loop is more practical (and looping is necessary anyway). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 17:57:26 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 11 Sep 2012 15:57:26 +0000 Subject: [issue15918] subprocess.Popen reads errpipe_read incorrectly, can result in short read In-Reply-To: <1347354377.74.0.358322632323.issue15918@psf.upfronthosting.co.za> Message-ID: <1347379046.94.0.190398184202.issue15918@psf.upfronthosting.co.za> Antoine Pitrou added the comment: 2.6 doesn't receive bug fixes anymore. Can you at least test with a recent 2.7? ---------- nosy: +gregory.p.smith, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 17:32:47 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 11 Sep 2012 15:32:47 +0000 Subject: [issue15917] hg hook to detect unmerged changesets In-Reply-To: <1347340391.86.0.248701031918.issue15917@psf.upfronthosting.co.za> Message-ID: <1347377567.48.0.410049935507.issue15917@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I might be wrong, but the logic in your hook looks a bit complicated. Wouldn't it be simpler to find all topological heads in the new csets (a topological head is a cset without any child), and check that none of them is on a 3.* branch? Finding topological heads is very easy, so http://hg.python.org/hooks/file/72aaeb80a55a/checkwhitespace.py#l85 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 18:02:18 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 11 Sep 2012 16:02:18 +0000 Subject: [issue15917] hg hook to detect unmerged changesets In-Reply-To: <1347340391.86.0.248701031918.issue15917@psf.upfronthosting.co.za> Message-ID: <1347379338.09.0.654301815493.issue15917@psf.upfronthosting.co.za> Ezio Melotti added the comment: > I might be wrong, but the logic in your hook looks a bit complicated. This might be true. The logic I followed is that once a cset is merged, it becomes a parent of another cset (either in the same branch or in the "next" one). So, if the cset is in 3.x and is not a parent, it should be merged. > Wouldn't it be simpler to find all topological heads in the new csets > (a topological head is a cset without any child), and check that none > of them is on a 3.* branch? If it's not a parent, it also means that it doesn't have any child, so we are looking at the same thing from two different points of view. If I'm reading the code you linked correctly, it's adding all the incoming changesets in a set, and for each changeset added to the set, all its parent are removed, so that eventually only the childless changesets (the topological heads) are left. This should also be equivalent to "set(allcsets) - set(allparents)". On the other hand my code checks for specific branches, so if you commit on 3.1 and merge on default, the cset in 3.1 is not a topological head so it's not detected by the version you linked, whereas my script will complain saying that it should be merged with 3.2 and then with default (even if maybe it should complain because you merged it in the wrong branch). ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 18:03:11 2012 From: report at bugs.python.org (Vitaly) Date: Tue, 11 Sep 2012 16:03:11 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za> Message-ID: <1347379391.37.0.245870800885.issue15896@psf.upfronthosting.co.za> Changes by Vitaly : ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 18:04:05 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 11 Sep 2012 16:04:05 +0000 Subject: [issue15914] multiprocessing.SyncManager connection hang In-Reply-To: <1347312588.21.0.484965926655.issue15914@psf.upfronthosting.co.za> Message-ID: <1347379445.35.0.563964880184.issue15914@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Python 3.2 has extra code in _PyImport_ReInitLock() which means that when a fork happens as a side effect of an import, the main thread of the forked process owns the import lock. Therefore other threads in the forked process cannot import anything. _PyImport_ReInitLock(void) { if (import_lock != NULL) import_lock = PyThread_allocate_lock(); if (import_lock_level > 1) { /* Forked as a side effect of import */ long me = PyThread_get_thread_ident(); PyThread_acquire_lock(import_lock, 0); /* XXX: can the previous line fail? */ import_lock_thread = me; import_lock_level--; } else { import_lock_thread = -1; import_lock_level = 0; } } I think the reason this code is not triggered in Python 3.3 is the introduction of per-module import locks. ---------- type: behavior -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 18:05:24 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 11 Sep 2012 16:05:24 +0000 Subject: [issue15921] select module uses uninitialized value "tv.tv_usec" In-Reply-To: <1347367594.05.0.129732037388.issue15921@psf.upfronthosting.co.za> Message-ID: <3XGWDg0ll7zQ7k@mail.python.org> Roundup Robot added the comment: New changeset 6cdc72f4d82c by Benjamin Peterson in branch 'default': remove useless and defined initialization (closes #15921) http://hg.python.org/cpython/rev/6cdc72f4d82c ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 18:15:29 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 11 Sep 2012 16:15:29 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347380129.84.0.674520916135.issue15906@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I'm not sure of all the implications of this, but it seems like this is a relevant piece of information from the docs: "type= can take any callable that takes a single string argument and returns the converted value:" (from http://docs.python.org/dev/library/argparse.html#type ) In particular, it doesn't seem like it's meant to be supported to be calling "type" on an argument (e.g. a default argument) that's not a string. That's what's happening in the code snippet in the first comment above, where the default argument is a list. I haven't thought about this very long, but what would happen if the "type" conversion is only called on arguments and default arguments that are strings, and otherwise left alone? It seems like that would at least address the use case in the first comment, and maybe the type=open one as well. Either way, it seems like you still might need to track whether an argument has been converted (e.g. if type converts string to another string type). ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 18:20:26 2012 From: report at bugs.python.org (Ethan Furman) Date: Tue, 11 Sep 2012 16:20:26 +0000 Subject: [issue14617] confusing docs with regard to __hash__ In-Reply-To: <1334771728.14.0.513778784524.issue14617@psf.upfronthosting.co.za> Message-ID: <1347380426.34.0.704868840631.issue14617@psf.upfronthosting.co.za> Ethan Furman added the comment: RC2 has just been released. Any chance of this getting in to the final release? Nobobdy has pointed out any problems with the last update... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 18:40:31 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 11 Sep 2012 16:40:31 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347381631.69.0.75948744462.issue15906@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Along the lines of my previous comment, I notice that the following str type check was removed in the patch for issue 12776: - if isinstance(action.default, str): - default = self._get_value(action, default) - setattr(namespace, action.dest, default) But it was not preserved when the call to _get_value() was added back elsewhere: + if (action.default is not None and + hasattr(namespace, action.dest) and + action.default is getattr(namespace, action.dest)): + setattr(namespace, action.dest, + self._get_value(action, action.default)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 18:43:29 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 11 Sep 2012 16:43:29 +0000 Subject: [issue15914] multiprocessing.SyncManager connection hang In-Reply-To: <1347312588.21.0.484965926655.issue15914@psf.upfronthosting.co.za> Message-ID: <1347381809.73.0.0587666131481.issue15914@psf.upfronthosting.co.za> Richard Oudkerk added the comment: It looks like the problem was caused be the fix for http://bugs.python.org/issue9573 I think the usage this was intended to enable is evil since one of the forked processes should always be terminated with os._exit(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 19:02:27 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 11 Sep 2012 17:02:27 +0000 Subject: [issue14617] confusing docs with regard to __hash__ In-Reply-To: <1334771728.14.0.513778784524.issue14617@psf.upfronthosting.co.za> Message-ID: <3XGXVV1sZ7zQNX@mail.python.org> Roundup Robot added the comment: New changeset 957e1eef3296 by R David Murray in branch '3.2': #14617: clarify discussion of interrelationship of __eq__ and __hash__. http://hg.python.org/cpython/rev/957e1eef3296 New changeset c8d60d0c736b by R David Murray in branch 'default': Merge #14617: clarify discussion of interrelationship of __eq__ and __hash__. http://hg.python.org/cpython/rev/c8d60d0c736b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 19:05:55 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 11 Sep 2012 17:05:55 +0000 Subject: [issue14617] confusing docs with regard to __hash__ In-Reply-To: <1334771728.14.0.513778784524.issue14617@psf.upfronthosting.co.za> Message-ID: <1347383155.13.0.283842840542.issue14617@psf.upfronthosting.co.za> R. David Murray added the comment: I rewrote the section a bit differently than you did in your patch...if you think my changes are not an improvement please let me know. ---------- nosy: +r.david.murray resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 19:11:27 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 11 Sep 2012 17:11:27 +0000 Subject: [issue15918] subprocess.Popen reads errpipe_read incorrectly, can result in short read In-Reply-To: <1347354377.74.0.358322632323.issue15918@psf.upfronthosting.co.za> Message-ID: <1347383487.46.0.105344668354.issue15918@psf.upfronthosting.co.za> Gregory P. Smith added the comment: fyi - i suspect Python 3.2 and the backport of that to 2.x http://code.google.com/p/python-subprocess32/ do not have this issue. but you didn't give enough information in the bug report for me to know which pipe and which read call you're talking about to really be sure. (show tracebacks, mention specific version source lines, etc..). If the bug is present in 2.7, we'll consider a fix for it. regardless, I recommend *everyone* using Python 2.x use the subprocess32 module rather than the built in subprocess module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 19:14:50 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 11 Sep 2012 17:14:50 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347383690.1.0.978837240042.issue15906@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Here is a type of test case that I think should be considered for addition (to confirm that the code doesn't double-convert strings in at least one case). Maybe there is already a test case like this: class MyString(str): pass def convert(s): return MyString("*" + s) parser = ArgumentParser() parser.add_argument("--test", dest="test", type=convert, default="foo") args = parser.parse_args() print(args.test) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 19:15:20 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 11 Sep 2012 17:15:20 +0000 Subject: [issue15629] Add to regrtest the ability to run Lib and Doc doctests In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1347383720.67.0.746592558414.issue15629@psf.upfronthosting.co.za> R. David Murray added the comment: turtle uses it because that was the file that I made work when I was playing with 'make doctest'. I think being able to use the testsetup directive would be good. It could also them be used (I think!) to put resource directives in the docs that would control whether or not (eg) turtle was run via regertest '-u', making it not run by default. What make doctest does is to write the doctests out to to a file and then run them with the normal doctest tools, so there ought to be a way to integrate with it. I guess how easy that is depends on how easy it is to run sphinx on just one file...which might not be easy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 19:18:26 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 11 Sep 2012 17:18:26 +0000 Subject: [issue15917] hg hook to detect unmerged changesets In-Reply-To: <1347340391.86.0.248701031918.issue15917@psf.upfronthosting.co.za> Message-ID: <1347383906.51.0.496300706214.issue15917@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 19:28:53 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 11 Sep 2012 17:28:53 +0000 Subject: [issue15895] PyRun_SimpleFileExFlags() can leak a FILE pointer In-Reply-To: <1347231050.54.0.0211027720618.issue15895@psf.upfronthosting.co.za> Message-ID: <3XGY4z4mRjzQ7Z@mail.python.org> Roundup Robot added the comment: New changeset 6fea947edead by Christian Heimes in branch 'default': Updates NEWS for issue #15895 http://hg.python.org/cpython/rev/6fea947edead ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 19:42:34 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 11 Sep 2012 17:42:34 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347385354.77.0.883022349554.issue15906@psf.upfronthosting.co.za> R. David Murray added the comment: I believe you've identified the broken part of the change, Chris. So to restore previous behavior we need to add that back correctly. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 19:42:45 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 11 Sep 2012 17:42:45 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347385365.97.0.858129001981.issue15906@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- priority: high -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 19:52:48 2012 From: report at bugs.python.org (Vitaly) Date: Tue, 11 Sep 2012 17:52:48 +0000 Subject: [issue15918] subprocess.Popen reads errpipe_read incorrectly, can result in short read In-Reply-To: <1347354377.74.0.358322632323.issue15918@psf.upfronthosting.co.za> Message-ID: <1347385968.8.0.625404409147.issue15918@psf.upfronthosting.co.za> Vitaly added the comment: My bug report refers to the following code block in subprocess.py. The problem is the same in 2.6.7 and 2.7.3: === From subprocess.py in Python 2.7.3 Source Distribution: # Wait for exec to fail or succeed; possibly raising exception # Exception limited to 1M data = _eintr_retry_call(os.read, errpipe_read, 1048576) finally: # be sure the FD is closed no matter what os.close(errpipe_read) === However, Python 3.2.3 appears to be doing this correctly; it loops, gathers the data from multiple os.read calls, and doesn't make huge (1048576) os.read requests: === from subprocess.py in 3.2.3 source distribution # Wait for exec to fail or succeed; possibly raising an # exception (limited in size) data = bytearray() while True: part = _eintr_retry_call(os.read, errpipe_read, 50000) data += part if not part or len(data) > 50000: break === ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 19:57:58 2012 From: report at bugs.python.org (Ethan Furman) Date: Tue, 11 Sep 2012 17:57:58 +0000 Subject: [issue14617] confusing docs with regard to __hash__ In-Reply-To: <1347383155.13.0.283842840542.issue14617@psf.upfronthosting.co.za> Message-ID: <504F7F73.3070707@stoneleaf.us> Ethan Furman added the comment: R. David Murray wrote: > I rewrote the section a bit differently than you did in your patch...if you think my changes are not an improvement please let me know. This line is incorrect: A class which defines its own :meth:`__hash__` that explicitly raises a :exc:`TypeError` would be incorrectly identified as hashable by an ``isinstance(obj, collections.Hashable)`` call. It should be "would not be correctly identified as hashable". Otherwise, looks great. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 19:58:50 2012 From: report at bugs.python.org (Vitaly) Date: Tue, 11 Sep 2012 17:58:50 +0000 Subject: [issue15918] subprocess.Popen reads errpipe_read incorrectly, can result in short read In-Reply-To: <1347354377.74.0.358322632323.issue15918@psf.upfronthosting.co.za> Message-ID: <1347386330.28.0.562230216355.issue15918@psf.upfronthosting.co.za> Vitaly added the comment: Sorry, there is no traceback. The issue was identified in code review. 'man 2 read' states: === The system guaran- tees to read the number of bytes requested if the descriptor references a normal file that has that many bytes left before the end-of-file, but in no other case. === Since a pipe is not a "normal file", the guarantee to "read the number of bytes requested" does not apply. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 20:01:01 2012 From: report at bugs.python.org (Ethan Furman) Date: Tue, 11 Sep 2012 18:01:01 +0000 Subject: [issue14617] confusing docs with regard to __hash__ In-Reply-To: <504F7F73.3070707@stoneleaf.us> Message-ID: <504F802A.30002@stoneleaf.us> Ethan Furman added the comment: Ethan Furman wrote: > Ethan Furman added the comment: > > R. David Murray wrote: >> I rewrote the section a bit differently than you did in your patch...if you think my changes are not an improvement please let me know. > > This line is incorrect: > > A class which defines its own :meth:`__hash__` that explicitly raises a > :exc:`TypeError` would be incorrectly identified as hashable by an > ``isinstance(obj, collections.Hashable)`` call. > > It should be "would not be correctly identified as hashable". > > Otherwise, looks great. Argh. Nevermind! It all looks good. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 20:05:11 2012 From: report at bugs.python.org (Vitaly) Date: Tue, 11 Sep 2012 18:05:11 +0000 Subject: [issue15918] subprocess.Popen reads errpipe_read incorrectly, can result in short read In-Reply-To: <1347354377.74.0.358322632323.issue15918@psf.upfronthosting.co.za> Message-ID: <1347386711.07.0.719976737828.issue15918@psf.upfronthosting.co.za> Vitaly added the comment: The prior 'man 2 read' quote was from Mac OS X; On amazon (centos) Linux, 'man 2 read' makes the same claim, albeit in different verbiage: === It is not an error if this number is smaller than the number of bytes requested; this may happen for example because fewer bytes are actually available right now (maybe because we were close to end-of-file, or because we are reading from a pipe, or from a terminal), or because read() was interrupted by a signal. === ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 20:14:24 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 11 Sep 2012 18:14:24 +0000 Subject: [issue15918] subprocess.Popen reads errpipe_read incorrectly, can result in short read In-Reply-To: <1347385968.8.0.625404409147.issue15918@psf.upfronthosting.co.za> Message-ID: Gregory P. Smith added the comment: Yeah, sounds like _eintr_retry_call alone isn't appropriate here in 2.7. I'll fix it. In practice I doubt this matters much as this error string is likely to be less than one page (depends on pathnames involved) but it is still technically incorrect as written. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 20:16:57 2012 From: report at bugs.python.org (Ethan Furman) Date: Tue, 11 Sep 2012 18:16:57 +0000 Subject: [issue15209] Re-raising exceptions from an expression In-Reply-To: <1340821665.84.0.121596566188.issue15209@psf.upfronthosting.co.za> Message-ID: <1347387417.42.0.0813013161326.issue15209@psf.upfronthosting.co.za> Ethan Furman added the comment: Can we also get this committed before 3.3.0 final? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 20:22:14 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 11 Sep 2012 18:22:14 +0000 Subject: [issue15209] Re-raising exceptions from an expression In-Reply-To: <1340821665.84.0.121596566188.issue15209@psf.upfronthosting.co.za> Message-ID: <1347387734.1.0.899161455672.issue15209@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 20:45:43 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 11 Sep 2012 18:45:43 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347380129.84.0.674520916135.issue15906@psf.upfronthosting.co.za> Message-ID: <20120911144538.51f73b3d@resist.wooz.org> Barry A. Warsaw added the comment: On Sep 11, 2012, at 04:15 PM, Chris Jerdonek wrote: >I haven't thought about this very long, but what would happen if the "type" >conversion is only called on arguments and default arguments that are >strings, and otherwise left alone? I thought about that, and actually, my first take on a fix was almost exactly to restore the isinstance check for str-ness. When I thought about it longer, it occurred to me that the type conversion for default only made sense when action was 'store'. Still, either approach would solve the problem. >It seems like that would at least address the use case in the first comment, >and maybe the type=open one as well. > >Either way, it seems like you still might need to track whether an argument >has been converted (e.g. if type converts string to another string type). That would be more complicated, so we'd really have to decide whether to back port such changes, and whether we can sneak that into 3.3 given how late in the process we are. I'd be in favor either of my patch, or restoring the isinstance check (probably in that order). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 20:55:27 2012 From: report at bugs.python.org (Vitaly) Date: Tue, 11 Sep 2012 18:55:27 +0000 Subject: [issue15918] subprocess.Popen reads errpipe_read incorrectly, can result in short read In-Reply-To: <1347354377.74.0.358322632323.issue15918@psf.upfronthosting.co.za> Message-ID: <1347389727.15.0.188261319805.issue15918@psf.upfronthosting.co.za> Vitaly added the comment: > In practice I doubt this matters much as this error string is likely to be less than one page (depends on pathnames involved) but it is still technically incorrect as written. Agreed. Thank you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 21:00:13 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 11 Sep 2012 19:00:13 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347390013.08.0.0244019835572.issue15906@psf.upfronthosting.co.za> R. David Murray added the comment: To repeat: there is no change to be made for 3.3. 3.3.0 will go out the door with the pre-12776 behavior. So any backward compatibility concerns that apply to 2.7 and 3.2 also apply to 3.3. Thus I suggest we restore the string check, and consider an enhancement patch at more leisure for 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 21:15:04 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 11 Sep 2012 19:15:04 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347390013.08.0.0244019835572.issue15906@psf.upfronthosting.co.za> Message-ID: <20120911151457.26aa52ec@resist.wooz.org> Barry A. Warsaw added the comment: On Sep 11, 2012, at 07:00 PM, R. David Murray wrote: >To repeat: there is no change to be made for 3.3. 3.3.0 will go out the door >with the pre-12776 behavior. So any backward compatibility concerns that >apply to 2.7 and 3.2 also apply to 3.3. Thus I suggest we restore the string >check, and consider an enhancement patch at more leisure for 3.4. Okay, I missed that Georg has a separate branch for the 3.3.0 release, so we don't have to worry about it there. But yes, 2.7, 3.2, and 3.3.1 must be fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 11 23:13:59 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 11 Sep 2012 21:13:59 +0000 Subject: [issue15923] Building from a fresh clone breaks on Parser/asdl_c.py Message-ID: <1347398039.31.0.775610002592.issue15923@psf.upfronthosting.co.za> New submission from Barry A. Warsaw: After a fresh clone, configure && make fails due to a fairly obvious bug in the code. Note that if you `hg revert --all`, configure && make will succeed, probably because the timestamps get updated enough to fool make. @resist[~/projects/python:1043]% hg clone ssh://hg at hg.python.org/releasing/3.3.0 [...] @resist[~/projects/python:1044]% cd 3.3.0/ @resist[~/projects/python/3.3.0:1045]% ./configure && make [...] gcc -pthread -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Python/_warnings.o Python/_warnings.c ./Parser/asdl_c.py -h ./Include ./Parser/Python.asdl ./Parser/asdl_c.py -c ./Python ./Parser/Python.asdl Error visitingSum([Constructor(Load, []), Constructor(Store, []), Constructor(Del, []), Constructor(AugLoad, []), Constructor(AugStore, []), Constructor(Param, [])], []) not all arguments converted during string formatting Traceback (most recent call last): File "/home/barry/projects/python/3.3.0/Parser/asdl.py", line 309, in visit meth(object, *args) File "./Parser/asdl_c.py", line 1043, in visitSum self.simpleSum(sum, name) File "./Parser/asdl_c.py", line 1067, in simpleSum self.emit("default:" % name, 2) TypeError: not all arguments converted during string formatting make: *** [Python/Python-ast.c] Error 1 ---------- messages: 170344 nosy: barry, georg.brandl, loewis priority: normal severity: normal status: open title: Building from a fresh clone breaks on Parser/asdl_c.py versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 00:09:54 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 11 Sep 2012 22:09:54 +0000 Subject: [issue15923] Building from a fresh clone breaks on Parser/asdl_c.py In-Reply-To: <1347398039.31.0.775610002592.issue15923@psf.upfronthosting.co.za> Message-ID: <1347401394.89.0.297291707613.issue15923@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 00:26:38 2012 From: report at bugs.python.org (Joshua Landau) Date: Tue, 11 Sep 2012 22:26:38 +0000 Subject: [issue15924] 404 link on Python about page Message-ID: <1347402398.06.0.816784008055.issue15924@psf.upfronthosting.co.za> New submission from Joshua Landau: http://www.python.org/about/ section "Python plays well with others", last paragraph, link "extension modules" links to http://www.python.org/doc/ext/intro.html, a 404 page. http://www.python.org/doc/ext/ redirects to http://docs.python.org/extending/ ---------- components: None messages: 170345 nosy: Joshua.Landau priority: normal severity: normal status: open title: 404 link on Python about page _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 00:41:32 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 11 Sep 2012 22:41:32 +0000 Subject: [issue5766] Mac/scripts/BuildApplet.py reset of sys.executable during install can cause it to use wrong modules In-Reply-To: <1239840739.74.0.413438515887.issue5766@psf.upfronthosting.co.za> Message-ID: <1347403292.97.0.682457051076.issue5766@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- versions: +Python 2.7 -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 00:42:41 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 11 Sep 2012 22:42:41 +0000 Subject: [issue1005895] curses for win32 Message-ID: <1347403361.12.0.980355118501.issue1005895@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 00:45:30 2012 From: report at bugs.python.org (Brian Curtin) Date: Tue, 11 Sep 2012 22:45:30 +0000 Subject: [issue1005895] curses for win32 Message-ID: <1347403530.65.0.241415496371.issue1005895@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- nosy: -brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 00:49:23 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 11 Sep 2012 22:49:23 +0000 Subject: [issue8964] platform._sys_version does not parse correctly IronPython 2.x version In-Reply-To: <1276204295.1.0.731236969654.issue8964@psf.upfronthosting.co.za> Message-ID: <1347403763.37.0.820798588828.issue8964@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy versions: +Python 3.3 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 00:53:48 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 11 Sep 2012 22:53:48 +0000 Subject: [issue10445] _ast py3k : add lineno back to "args" node In-Reply-To: <1290003328.01.0.315649649266.issue10445@psf.upfronthosting.co.za> Message-ID: <1347404028.79.0.361585540958.issue10445@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- components: +Interpreter Core -None nosy: +ncoghlan stage: -> needs patch versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 00:54:54 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 11 Sep 2012 22:54:54 +0000 Subject: [issue11385] TextTestRunner methods are not documented In-Reply-To: <1299176734.52.0.359265322214.issue11385@psf.upfronthosting.co.za> Message-ID: <1347404094.44.0.869798081454.issue11385@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti versions: +Python 3.4 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 00:57:40 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 11 Sep 2012 22:57:40 +0000 Subject: [issue15315] Can't build Python extension with mingw32 on Windows In-Reply-To: <1341895923.16.0.599445307566.issue15315@psf.upfronthosting.co.za> Message-ID: <1347404260.56.0.361529590853.issue15315@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- dependencies: +Remove -mno-cygwin from distutils type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 00:59:49 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 11 Sep 2012 22:59:49 +0000 Subject: [issue13990] Benchmarks: 2to3 failures on the py3 side In-Reply-To: <1328895154.39.0.105937484663.issue13990@psf.upfronthosting.co.za> Message-ID: <1347404389.43.0.891008918279.issue13990@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 01:04:29 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 11 Sep 2012 23:04:29 +0000 Subject: [issue15923] Building from a fresh clone breaks on Parser/asdl_c.py In-Reply-To: <1347398039.31.0.775610002592.issue15923@psf.upfronthosting.co.za> Message-ID: <1347404669.29.0.32258252334.issue15923@psf.upfronthosting.co.za> Martin v. L?wis added the comment: It's really puzzling that this has ever worked; the buggy code has been there since 2008, yet apparently executed successfully many times since. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 01:16:03 2012 From: report at bugs.python.org (Chris Kaynor) Date: Tue, 11 Sep 2012 23:16:03 +0000 Subject: [issue12680] cPickle.loads is not thread safe due to non-thread-safe imports In-Reply-To: <1312272969.55.0.673755441724.issue12680@psf.upfronthosting.co.za> Message-ID: <1347405363.59.0.173328023973.issue12680@psf.upfronthosting.co.za> Changes by Chris Kaynor : ---------- nosy: +DragonFireCK _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 02:37:46 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 12 Sep 2012 00:37:46 +0000 Subject: [issue15925] email.utils.parsedate(), email.utils.parsedate_tz() and email.utils.parsedate_to_datetime() should return None when date cannot be parsed Message-ID: <1347410265.94.0.383870526813.issue15925@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis: Documentation (in Python 3.3) says that None is returned when date cannot be parsed. In Python 3.2: >>> email.utils.parsedate("0") >>> email.utils.parsedate_tz("0") >>> In Python 3.3: >>> email.utils.parsedate("0") Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.3/email/utils.py", line 232, in parsedate return _parsedate(data) File "/usr/lib64/python3.3/email/_parseaddr.py", line 172, in parsedate t = parsedate_tz(data) File "/usr/lib64/python3.3/email/_parseaddr.py", line 51, in parsedate_tz if res[9] is None: TypeError: 'NoneType' object is not subscriptable >>> email.utils.parsedate_tz("0") Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.3/email/utils.py", line 238, in parsedate_tz return _parsedate_tz(data) File "/usr/lib64/python3.3/email/_parseaddr.py", line 51, in parsedate_tz if res[9] is None: TypeError: 'NoneType' object is not subscriptable >>> email.utils.parsedate_to_datetime("0") Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.3/email/utils.py", line 243, in parsedate_to_datetime *dtuple, tz = __parsedate_tz(data) TypeError: 'NoneType' object is not iterable >>> ---------- messages: 170347 nosy: Arfrever priority: release blocker severity: normal status: open title: email.utils.parsedate(), email.utils.parsedate_tz() and email.utils.parsedate_to_datetime() should return None when date cannot be parsed versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 02:38:51 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 12 Sep 2012 00:38:51 +0000 Subject: [issue15925] email.utils.parsedate(), email.utils.parsedate_tz() and email.utils.parsedate_to_datetime() should return None when date cannot be parsed In-Reply-To: <1347410265.94.0.383870526813.issue15925@psf.upfronthosting.co.za> Message-ID: <1347410331.57.0.869645701949.issue15925@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- components: +email nosy: +barry, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 03:12:03 2012 From: report at bugs.python.org (Max) Date: Wed, 12 Sep 2012 01:12:03 +0000 Subject: [issue9592] Limitations in objects returned by multiprocessing Pool In-Reply-To: <1281726168.11.0.648826556363.issue9592@psf.upfronthosting.co.za> Message-ID: <1347412323.52.0.814342000584.issue9592@psf.upfronthosting.co.za> Max added the comment: I propose to close this issue as fixed. The first two problems in the OP are now resolved through patches to pickle. The third problem is addressed by issue5370: it is a documented feature of pickle that anyone who defines __setattr__ / __getattr__ that depend on an internal state must also take care to restore that state during unpickling. Otherwise, the code is not pickle-safe, and by extension, not multiprocessing-safe. ---------- nosy: +max _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 05:12:34 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 12 Sep 2012 03:12:34 +0000 Subject: [issue15925] email.utils.parsedate(), email.utils.parsedate_tz() and email.utils.parsedate_to_datetime() should return None when date cannot be parsed In-Reply-To: <1347410265.94.0.383870526813.issue15925@psf.upfronthosting.co.za> Message-ID: <1347419554.16.0.786536545624.issue15925@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- keywords: +3.3regression _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 05:13:01 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 12 Sep 2012 03:13:01 +0000 Subject: [issue15926] Segmentation fault after multiple reinitializations Message-ID: <1347419581.97.0.0354883385349.issue15926@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis: #include #include int main() { int i; for (i = 0; i < 100; i++) { printf("%d\n", i); Py_Initialize(); Py_Finalize(); } return 0; } The above code succeeds with Python 3.2, but causes segmentation fault with Python 3.3: $ ./reinitializations 0 1 2 3 4 5 6 7 8 9 Segmentation fault $ ---------- keywords: 3.3regression messages: 170349 nosy: Arfrever priority: high severity: normal status: open title: Segmentation fault after multiple reinitializations versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 06:13:05 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 12 Sep 2012 04:13:05 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <3XGqMt6bypzQWt@mail.python.org> Roundup Robot added the comment: New changeset 739606bdcba4 by Barry Warsaw in branch '2.7': - Issue #15906: Fix a regression in argparse caused by the preceding change, http://hg.python.org/cpython/rev/739606bdcba4 New changeset bc342cd7ed96 by Barry Warsaw in branch '3.2': - Issue #15906: Fix a regression in argparse caused by the preceding change, http://hg.python.org/cpython/rev/bc342cd7ed96 New changeset 25e41fdc4e60 by Barry Warsaw in branch 'default': - Issue #15906: Fix a regression in argparse caused by the preceding change, http://hg.python.org/cpython/rev/25e41fdc4e60 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 06:16:26 2012 From: report at bugs.python.org (Trent Nelson) Date: Wed, 12 Sep 2012 04:16:26 +0000 Subject: [issue15923] Building from a fresh clone breaks on Parser/asdl_c.py In-Reply-To: <1347398039.31.0.775610002592.issue15923@psf.upfronthosting.co.za> Message-ID: <1347423386.61.0.465551677121.issue15923@psf.upfronthosting.co.za> Changes by Trent Nelson : ---------- nosy: +trent _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 06:18:28 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 12 Sep 2012 04:18:28 +0000 Subject: [issue15923] Building from a fresh clone breaks on Parser/asdl_c.py In-Reply-To: <1347398039.31.0.775610002592.issue15923@psf.upfronthosting.co.za> Message-ID: <1347423508.12.0.637928906907.issue15923@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 06:22:28 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 12 Sep 2012 04:22:28 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347423748.82.0.977111638704.issue15906@psf.upfronthosting.co.za> Chris Jerdonek added the comment: [From python-dev: http://mail.python.org/pipermail/python-dev/2012-September/121683.html ] > I've tried the various suggestions out, and I think from a practical point of view, a fix for the regression in the 2.7, 3.2 and 3.3 branches should be to apply the one line check for action being a _StoreAction instance. This seems to be the easiest way to preserve the current behavior (the fix for issues #12776 and #11839) and fix issue #15906. I'll update the issue and apply this change to the three branches. This change doesn't seem right to me. It also seems like it may cause other regressions. The argparse documentation makes it pretty clear that 'type' is meant to be applied only to strings. Also, the parse_args() documentation says, "Convert argument strings to objects and assign them as attributes of the namespace," but it doesn't say anything about also converting non-string defaults. Thirdly, the documentation for the "default" keyword argument says, "The default keyword argument of add_argument(), whose value defaults to None, specifies what value should be used if the command-line argument is not present." It doesn't say that the value should be converted before being used. Also, here is what the change does from a behavior perspective for a couple test cases (compared to some other points in time): parser = ArgumentParser() parser.add_argument("--test", dest="test", action='store', type=str, default=False) args = parser.parse_args() print(repr(args.test)) to_str = lambda s: s.lower() parser = ArgumentParser() parser.add_argument("--test", dest="test", action='store', type=to_str, default=False) args = parser.parse_args() print(repr(args.test)) 2.7.3: False False Python 3.3 (815b88454e3e; before issue 12776 patch): False False Python 3.3.0rc2+: 'False' Traceback (most recent call last): ... AttributeError: 'bool' object has no attribute 'lower' Python 3.3.0rc2+15906-1.diff: 'False' Traceback (most recent call last): ... AttributeError: 'bool' object has no attribute 'lower' So with the change, code that previously didn't raise an error will now raise an AttributeError. In other words, it seems like the change imposes restrictions on what default values are allowed relative to the 'type' callable where such restrictions didn't exist before. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 06:49:50 2012 From: report at bugs.python.org (Kalon Mills) Date: Wed, 12 Sep 2012 04:49:50 +0000 Subject: [issue15927] cvs.reader does not support escaped newline when quoting=cvs.QUOTE_NONE Message-ID: <1347425390.54.0.862014726204.issue15927@psf.upfronthosting.co.za> New submission from Kalon Mills: cvs.reader improperly prematurely ends row parsing when parsing a row with an escaped newline but with quoting turned off. cvs.reader properly handles quoted newlines. cvs.writer properly handles writing escaped unquoted newlines so only the reader has an issue. Given a dialect with escapechar='\\', quoting=csv.QUOTE_NONE, lineterminator='\n': writer.writerow(['one\nelement']) will correctly write 'one\\\nelement\n' however pass that back into a reader and it will produce two rows: ['one\n'] ['element'] I would expect the reader to parse it correctly and return the original value of ['one\nelement'] I've attached a test script that exhibits the improper behavior. It uses a dialect to set an escapechar and disable quoting. ---------- components: None files: test_csv.py messages: 170352 nosy: kalaxy priority: normal severity: normal status: open title: cvs.reader does not support escaped newline when quoting=cvs.QUOTE_NONE type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file27177/test_csv.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 07:17:42 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 12 Sep 2012 05:17:42 +0000 Subject: [issue15899] howto/unicode.rst doctest corrections In-Reply-To: <1347267716.91.0.310284408834.issue15899@psf.upfronthosting.co.za> Message-ID: <3XGrpT0SzxzQZQ@mail.python.org> Roundup Robot added the comment: New changeset 142fbadd0ae1 by Senthil Kumaran in branch '2.7': Fix issue #15899 - howto/unicode.rst doctest corrections for 2.7 branch. http://hg.python.org/cpython/rev/142fbadd0ae1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 07:19:45 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 12 Sep 2012 05:19:45 +0000 Subject: [issue15899] howto/unicode.rst doctest corrections In-Reply-To: <1347267716.91.0.310284408834.issue15899@psf.upfronthosting.co.za> Message-ID: <1347427185.3.0.454860777785.issue15899@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 07:19:58 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 12 Sep 2012 05:19:58 +0000 Subject: [issue15899] howto/unicode.rst doctest corrections In-Reply-To: <1347267716.91.0.310284408834.issue15899@psf.upfronthosting.co.za> Message-ID: <1347427198.76.0.174680974199.issue15899@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- stage: patch review -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 07:45:02 2012 From: report at bugs.python.org (zhang kai) Date: Wed, 12 Sep 2012 05:45:02 +0000 Subject: [issue15928] Open url with proxy causes TypeError Message-ID: <1347428702.03.0.0537807562119.issue15928@psf.upfronthosting.co.za> New submission from zhang kai: Here is the code which causes this bug: proxy_handler = urllib2.ProxyHandler({'https': proxy}) opener = urllib2.build_opener(proxy_handler) f = opener.open(url+'?'+params) Here are the traceback information: Traceback (most recent call last): File "proxy.py", line 65, in main() File "proxy.py", line 62, in main print proxy_manager.get_proxy() File "proxy.py", line 45, in get_proxy make_request(TEST_URL, proxy=one["proxy_server"]) File "proxy.py", line 27, in make_request f = opener.open(url+'?'+params) File "/usr/lib/python2.7/urllib2.py", line 400, in open response = self._open(req, data) File "/usr/lib/python2.7/urllib2.py", line 418, in _open '_open', req) File "/usr/lib/python2.7/urllib2.py", line 378, in _call_chain result = func(*args) File "/usr/lib/python2.7/urllib2.py", line 1215, in https_open return self.do_open(httplib.HTTPSConnection, req) File "/usr/lib/python2.7/urllib2.py", line 1174, in do_open h.request(req.get_method(), req.get_selector(), req.data, headers) File "/usr/lib/python2.7/httplib.py", line 958, in request self._send_request(method, url, body, headers) File "/usr/lib/python2.7/httplib.py", line 992, in _send_request self.endheaders(body) File "/usr/lib/python2.7/httplib.py", line 954, in endheaders self._send_output(message_body) File "/usr/lib/python2.7/httplib.py", line 814, in _send_output self.send(msg) File "/usr/lib/python2.7/httplib.py", line 776, in send self.connect() File "/usr/lib/python2.7/httplib.py", line 1160, in connect self._tunnel() File "/usr/lib/python2.7/httplib.py", line 748, in _tunnel line = response.fp.readline(_MAXLINE + 1) TypeError: readline() takes exactly 1 argument (2 given) ---------- components: Library (Lib) messages: 170354 nosy: zhang.kai priority: normal severity: normal status: open title: Open url with proxy causes TypeError type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 08:14:00 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 12 Sep 2012 06:14:00 +0000 Subject: [issue15928] Open url with proxy causes TypeError In-Reply-To: <1347428702.03.0.0537807562119.issue15928@psf.upfronthosting.co.za> Message-ID: <1347430440.98.0.5433971799.issue15928@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Have a look at the ProxyHandler example in the Examples here - http://docs.python.org/library/urllib2.html#examples Also, construct the full url properly with urlencoded data as params. Your report does not give any details of problem. ---------- nosy: +orsenthil resolution: -> invalid stage: -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 08:14:11 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 12 Sep 2012 06:14:11 +0000 Subject: [issue15928] Open url with proxy causes TypeError In-Reply-To: <1347428702.03.0.0537807562119.issue15928@psf.upfronthosting.co.za> Message-ID: <1347430451.28.0.0388728046084.issue15928@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 08:25:18 2012 From: report at bugs.python.org (zhang kai) Date: Wed, 12 Sep 2012 06:25:18 +0000 Subject: [issue15928] Open url with proxy causes TypeError In-Reply-To: <1347428702.03.0.0537807562119.issue15928@psf.upfronthosting.co.za> Message-ID: <1347431118.13.0.340730519606.issue15928@psf.upfronthosting.co.za> zhang kai added the comment: Well, I do have encoded the params, that is not the problem. Also these code did work for most of the time, I don't know why this bug happen so I don't know any details about the problem. Sorry about that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 09:33:17 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 12 Sep 2012 07:33:17 +0000 Subject: [issue15926] Segmentation fault after multiple reinitializations In-Reply-To: <1347419581.97.0.0354883385349.issue15926@psf.upfronthosting.co.za> Message-ID: <1347435197.37.0.0557201717289.issue15926@psf.upfronthosting.co.za> Stefan Krah added the comment: The segfault occurs in a path in import.c that has a comment "XXX this this should really not happen.": Program received signal SIGSEGV, Segmentation fault. 0x000000000047d733 in type_dealloc (type=0x8381e0) at Objects/typeobject.c:2694 2694 _PyObject_GC_UNTRACK(type); (gdb) bt #0 0x000000000047d733 in type_dealloc (type=0x8381e0) at Objects/typeobject.c:2694 #1 0x000000000045d8ef in free_keys_object (keys=0x8eb810) at Objects/dictobject.c:374 #2 0x0000000000463513 in dict_dealloc (mp=0x8fa9c0) at Objects/dictobject.c:1392 #3 0x0000000000503118 in _PyImport_FixupExtensionObject (mod=0xa0cd40, name=0xb1fa90, filename=0xb1fa90) at Python/import.c:498 (gdb) f 3 #3 0x0000000000503118 in _PyImport_FixupExtensionObject (mod=0xa0cd40, name=0xb1fa90, filename=0xb1fa90) at Python/import.c:498 498 Py_DECREF(def->m_base.m_copy); (gdb) l 493 if (def->m_size == -1) { 494 if (def->m_base.m_copy) { 495 /* Somebody already imported the module, 496 likely under a different name. 497 XXX this should really not happen. */ 498 Py_DECREF(def->m_base.m_copy); 499 def->m_base.m_copy = NULL; 500 } 501 dict = PyModule_GetDict(mod); 502 if (dict == NULL) ---------- nosy: +brett.cannon, eric.snow, pitrou, skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 09:38:34 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 12 Sep 2012 07:38:34 +0000 Subject: [issue15926] Segmentation fault after multiple reinitializations In-Reply-To: <1347419581.97.0.0354883385349.issue15926@psf.upfronthosting.co.za> Message-ID: <1347435514.56.0.913648199196.issue15926@psf.upfronthosting.co.za> Stefan Krah added the comment: Maybe related: If you increase the number of passes in Modules/_testembed.c, pass 9 fails: --- Pass 9 --- _testembed: Objects/typeobject.c:2693: type_dealloc: Assertion `type->tp_flags & (1L<<9)' failed. Aborted ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 09:40:20 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 12 Sep 2012 07:40:20 +0000 Subject: [issue15926] Segmentation fault after multiple reinitializations In-Reply-To: <1347419581.97.0.0354883385349.issue15926@psf.upfronthosting.co.za> Message-ID: <1347435620.57.0.855994967506.issue15926@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- components: +Interpreter Core stage: -> needs patch type: -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 09:55:49 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 12 Sep 2012 07:55:49 +0000 Subject: [issue5766] Mac/scripts/BuildApplet.py reset of sys.executable during install can cause it to use wrong modules In-Reply-To: <1239840739.74.0.413438515887.issue5766@psf.upfronthosting.co.za> Message-ID: <1347436549.45.0.890199984494.issue5766@psf.upfronthosting.co.za> Ned Deily added the comment: This problem was caused by a conflict between the expat parser included with Python and the expat parser included with the MacPorts ports of the obsolete pyxml package. The MacPorts project has subsequently deleted the py*-xml ports. A solution for this issue is to remove the obsolete port, something like: sudo port uninstall py26-xml See https://trac.macports.org/ticket/32090 for a similar case and its resolution. ---------- nosy: +ned.deily resolution: -> out of date stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 10:42:20 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 12 Sep 2012 08:42:20 +0000 Subject: [issue15898] OSX TTY bug In-Reply-To: <1347347489.99.0.712013874119.issue15898@psf.upfronthosting.co.za> Message-ID: <50504AD6.2010209@v.loewis.de> Martin v. L?wis added the comment: Am 11.09.2012 09:11, schrieb Andrew Moffat: > I'm not sure I follow the problem exactly. So you're saying that the > failing version uses _cancel sys calls, and that __pthread_testcancel > may result in EINTR. But that this is not happening in the trace, > and data is being written successfully. I guess I'm wondering where > the written bytes went and if there's any way to retrieve them? That's exactly the question, and why I say that is must be an OS bug. According to the trace, the OS accepted the data, so if they got lost, it's their "fault". Unfortunately, the dtruss doesn't decode the ioctl arguments, so it's not easy to tell whether they are right. You could try running it with -a to see whether this gives more information. Please don't paste the traces, though, but attach them (the editing is surely appreciated, though). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 10:48:37 2012 From: report at bugs.python.org (Mitar) Date: Wed, 12 Sep 2012 08:48:37 +0000 Subject: [issue15881] multiprocessing 'NoneType' object is not callable In-Reply-To: <1347044200.13.0.235512745295.issue15881@psf.upfronthosting.co.za> Message-ID: <1347439717.48.0.822595465114.issue15881@psf.upfronthosting.co.za> Changes by Mitar : ---------- nosy: +mitar _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 11:00:57 2012 From: report at bugs.python.org (Julien Castets) Date: Wed, 12 Sep 2012 09:00:57 +0000 Subject: [issue15929] argparse non alphanum characters replacement Message-ID: <1347440457.56.0.780058714044.issue15929@psf.upfronthosting.co.za> New submission from Julien Castets: argparse.add_argument replaces dashes with underscores. If an argument contains another non alphanum character, accessing to it will result to a syntax error. #! /usr/bin/env python import argparse if __name__ == '__main__': argParser = argparse.ArgumentParser() argParser.add_argument('--foo+', action='store_true') arguments = argParser.parse_args() print 'getattr foo+: %s' % getattr(arguments, 'foo+') # ok print arguments.foo+ # syntax error The patch replaces every non alnum character with an underscore. ---------- components: None files: argparse.patch keywords: patch messages: 170361 nosy: brmzkw priority: normal severity: normal status: open title: argparse non alphanum characters replacement type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file27178/argparse.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 12:15:44 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 12 Sep 2012 10:15:44 +0000 Subject: [issue15928] Open url with proxy causes TypeError In-Reply-To: <1347428702.03.0.0537807562119.issue15928@psf.upfronthosting.co.za> Message-ID: <1347444944.93.0.947792250553.issue15928@psf.upfronthosting.co.za> R. David Murray added the comment: What is proxy? Perhaps it does not implement readline correctly. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 12:24:56 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 12 Sep 2012 10:24:56 +0000 Subject: [issue15929] argparse non alphanum characters replacement In-Reply-To: <1347440457.56.0.780058714044.issue15929@psf.upfronthosting.co.za> Message-ID: <1347445496.59.0.963329528372.issue15929@psf.upfronthosting.co.za> R. David Murray added the comment: It would probably be better to have the namespace object support subscripting in order to satisfy this use case. You can use getattr to do it now. (Note that the namespace object should probably use a real dict and a __getattr__ method, since I don't think the language guarantees that you can put non-identifiers in an attribute dict). ---------- nosy: +bethard, r.david.murray type: behavior -> enhancement versions: -Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 12:39:03 2012 From: report at bugs.python.org (Steven Bethard) Date: Wed, 12 Sep 2012 10:39:03 +0000 Subject: [issue15929] argparse non alphanum characters replacement In-Reply-To: <1347440457.56.0.780058714044.issue15929@psf.upfronthosting.co.za> Message-ID: <1347446343.61.0.429676960409.issue15929@psf.upfronthosting.co.za> Steven Bethard added the comment: If you need to get things that aren't valid Python identifiers, use vars() to get the dictionary: http://docs.python.org/dev/library/argparse.html#the-namespace-object Changing all non-alphanumeric characters to underscores would be a backwards incompatible change for argparse (it would break existing code). That means we'd need to have a long deprecation period before the change. I'm not sure it's really worth it for this feature when vars() already gives you what you need easily. I'm therefore closing this a "won't fix", but if you feel really strongly that vars() doesn't solve your problem and you want to push through the long deprecation process, feel free to re-open. @R. David Murray: I wouldn't worry about non-identifiers in an attribute dict. This has worked for ages, and changing this would be a seriously backwards incompatible change that couldn't be possible before Python 4. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 12:39:38 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 12 Sep 2012 10:39:38 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347446378.45.0.756311283048.issue15906@psf.upfronthosting.co.za> R. David Murray added the comment: I agree with Chris here. We also need to add the various tests he's come up with. IMO the easiest way to restore the original behavior and the preserve the fixes is to make the following single line change: diff --git a/Lib/argparse.py b/Lib/argparse.py --- a/Lib/argparse.py +++ b/Lib/argparse.py @@ -1962,7 +1962,8 @@ # only if it was defined already in the namespace if (action.default is not None and hasattr(namespace, action.dest) and - action.default is getattr(namespace, action.dest)): + action.default is getattr(namespace, action.dest) and + isinstance(action.default, str)): setattr(namespace, action.dest, self._get_value(action, action.default)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 12:57:00 2012 From: report at bugs.python.org (Steven Bethard) Date: Wed, 12 Sep 2012 10:57:00 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347447420.69.0.762158386812.issue15906@psf.upfronthosting.co.za> Steven Bethard added the comment: It looks like the correct fix was already applied, but just to chime in here: (1) Yes, the error is that the isinstance(action.default, str) check was lost (2) Yes, it is intended that you can use a string value as your default and the type= converter will be called on that. This feature allows DRY for people that have a complex object that can be specified by a simple string. (3) Yes, the type= converter function should be applied to the default for all action types, not just for the store action. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 13:50:13 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 12 Sep 2012 11:50:13 +0000 Subject: [issue15929] argparse non alphanum characters replacement In-Reply-To: <1347440457.56.0.780058714044.issue15929@psf.upfronthosting.co.za> Message-ID: <1347450613.3.0.246989467188.issue15929@psf.upfronthosting.co.za> R. David Murray added the comment: Oh, it wasn't CPython that that comment was directed at. But I think you are right: because CPython supports it, I think other implementations will as well, whatever the language spec says or doesn't say (I didn't double check, I'm going on a fuzzy memory of a conversation on python-dev from the pypy folks). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 13:52:32 2012 From: report at bugs.python.org (Julian Berman) Date: Wed, 12 Sep 2012 11:52:32 +0000 Subject: [issue11385] TextTestRunner methods are not documented In-Reply-To: <1299176734.52.0.359265322214.issue11385@psf.upfronthosting.co.za> Message-ID: <1347450752.56.0.524070924535.issue11385@psf.upfronthosting.co.za> Changes by Julian Berman : ---------- nosy: +Julian _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 13:52:49 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 12 Sep 2012 11:52:49 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347450769.8.0.45536258572.issue15906@psf.upfronthosting.co.za> R. David Murray added the comment: The correct fix has not been applied yet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 13:55:10 2012 From: report at bugs.python.org (Ask Solem) Date: Wed, 12 Sep 2012 11:55:10 +0000 Subject: [issue9592] Limitations in objects returned by multiprocessing Pool In-Reply-To: <1281726168.11.0.648826556363.issue9592@psf.upfronthosting.co.za> Message-ID: <1347450910.08.0.989786570384.issue9592@psf.upfronthosting.co.za> Ask Solem added the comment: I vote to close too as it's very hard to fix in a clean way. A big problem though is that there is a standard for defining exceptions, that also ensures that the exception is pickleable (always call Exception.__init__ with original args), that is not documented (http://docs.python.org/tutorial/errors.html#user-defined-exceptions). Celery has an elaborate mechanism to rewrite unpickleable exceptions, but it's a massive workaround just to keep the workers running, and shouldn't be part of the stdlib. It would help if the Python documentation mentioned this though. Related: http://docs.celeryproject.org/en/latest/userguide/tasks.html#creating-pickleable-exceptions ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 14:02:04 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 12 Sep 2012 12:02:04 +0000 Subject: [issue14617] confusing docs with regard to __hash__ In-Reply-To: <1334771728.14.0.513778784524.issue14617@psf.upfronthosting.co.za> Message-ID: <1347451324.12.0.920690328777.issue14617@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This can wait until after the release. We will have periodic point releases where further doc updates can go in. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 14:06:16 2012 From: report at bugs.python.org (Steven Bethard) Date: Wed, 12 Sep 2012 12:06:16 +0000 Subject: [issue15929] argparse non alphanum characters replacement In-Reply-To: <1347440457.56.0.780058714044.issue15929@psf.upfronthosting.co.za> Message-ID: <1347451576.44.0.800058317921.issue15929@psf.upfronthosting.co.za> Steven Bethard added the comment: I haven't been following python-dev recently, but the only discussion I remember was for non-strings in __dict__, not non-identifiers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 14:08:15 2012 From: report at bugs.python.org (Steven Bethard) Date: Wed, 12 Sep 2012 12:08:15 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347451695.94.0.0412388237627.issue15906@psf.upfronthosting.co.za> Steven Bethard added the comment: Oh, I see, you're right - the recent changes from the Roundup Robot are exactly the wrong changes - special casing _StoreAction, not string defaults. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 14:37:02 2012 From: report at bugs.python.org (Christian Heimes) Date: Wed, 12 Sep 2012 12:37:02 +0000 Subject: [issue15930] buffer overrun in wcstombs_errorpos() Message-ID: <1347453422.44.0.810518034926.issue15930@psf.upfronthosting.co.za> New submission from Christian Heimes: Coverity has found a buffer overrun in wcstombs_errorpos() defined at http://hg.python.org/cpython/file/25e41fdc4e60/Objects/unicodeobject.c#l3237 Message: CID 719672: Out-of-bounds access (OVERRUN)At (2): Overrunning array "buf" of 2 4-byte elements by passing it to a function which accesses it at element index 15 (byte offset 60) using argument "16UL". On a 64bit Linux system SIZE_OF_WCHAR_T is 4 and MB_LEN_MAX 16. In this constellation buf is 8 bytes long (wchar_t[2]) but outbuf has a size of 16 bytes. This causes a buffer overrun in wcstombs(outbuf, buf, sizeof(outbuf)). ---------- keywords: 3.3regression messages: 170373 nosy: christian.heimes, haypo priority: normal severity: normal status: open title: buffer overrun in wcstombs_errorpos() type: resource usage versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 14:48:17 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 12 Sep 2012 12:48:17 +0000 Subject: [issue13990] Benchmarks: 2to3 failures on the py3 side In-Reply-To: <1328895154.39.0.105937484663.issue13990@psf.upfronthosting.co.za> Message-ID: <1347454097.01.0.864820770489.issue13990@psf.upfronthosting.co.za> Brett Cannon added the comment: It's translating properly for me now as well (but on a different machine). I will give it another try when I get home to see if I can reproduce success on the machine that was failing for me previously. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 14:48:25 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 12 Sep 2012 12:48:25 +0000 Subject: [issue13990] Benchmarks: 2to3 failures on the py3 side In-Reply-To: <1328895154.39.0.105937484663.issue13990@psf.upfronthosting.co.za> Message-ID: <1347454105.19.0.486785205644.issue13990@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: benjamin.peterson -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 15:00:08 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 12 Sep 2012 13:00:08 +0000 Subject: [issue12680] cPickle.loads is not thread safe due to non-thread-safe imports In-Reply-To: <1312272969.55.0.673755441724.issue12680@psf.upfronthosting.co.za> Message-ID: <1347454808.66.0.412205084319.issue12680@psf.upfronthosting.co.za> Brett Cannon added the comment: I just checked and this is no longer an issue in Python 3.3. The sys.modules "bug" isn't a bug as that's how it is supposed to work to prevent partially initialized modules. As for how pickle is doing stuff, that could change if it wouldn't break backwards-compatibility. ---------- versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 15:00:26 2012 From: report at bugs.python.org (Christian Heimes) Date: Wed, 12 Sep 2012 13:00:26 +0000 Subject: [issue15930] buffer overrun in wcstombs_errorpos() In-Reply-To: <1347453422.44.0.810518034926.issue15930@psf.upfronthosting.co.za> Message-ID: <1347454826.91.0.816492989414.issue15930@psf.upfronthosting.co.za> Christian Heimes added the comment: Georg, this issue might be security relevant and should be reviewed before the next release. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 15:09:55 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 12 Sep 2012 13:09:55 +0000 Subject: [issue15930] buffer overrun in wcstombs_errorpos() In-Reply-To: <1347453422.44.0.810518034926.issue15930@psf.upfronthosting.co.za> Message-ID: <1347455395.18.0.0515260553686.issue15930@psf.upfronthosting.co.za> Stefan Krah added the comment: buf[1] contains NUL if SIZE_OF_WCHAR_T is 4. The man page says: size_t wcstombs(char *dest, const wchar_t *src, size_t n) The conversion can stop for three reasons: 3. The wide-character string has been completely converted, including the terminating L'\0'. In this case the conversion ends in the initial state. The number of bytes written to dest, exclud- ing the terminating '\0' byte, is returned. To me this sounds like there cannot be an invalid write. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 15:52:51 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 12 Sep 2012 13:52:51 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347447420.69.0.762158386812.issue15906@psf.upfronthosting.co.za> Message-ID: <20120912095228.2a4f285b@limelight.wooz.org> Barry A. Warsaw added the comment: On Sep 12, 2012, at 10:57 AM, Steven Bethard wrote: >(1) Yes, the error is that the isinstance(action.default, str) check was lost Except that it won't work any more in the original location. I tried it and it broke other tests. Maybe I did it wrong, so please verify by actually applying that patch, backing mine out, and running the full test suite. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 16:04:30 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 12 Sep 2012 14:04:30 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347446378.45.0.756311283048.issue15906@psf.upfronthosting.co.za> Message-ID: <20120912100426.3cc5d2c7@limelight.wooz.org> Barry A. Warsaw added the comment: On Sep 12, 2012, at 10:39 AM, R. David Murray wrote: >diff --git a/Lib/argparse.py b/Lib/argparse.py >--- a/Lib/argparse.py >+++ b/Lib/argparse.py >@@ -1962,7 +1962,8 @@ > # only if it was defined already in the namespace > if (action.default is not None and > hasattr(namespace, action.dest) and >- action.default is getattr(namespace, action.dest)): >+ action.default is getattr(namespace, action.dest) and >+ isinstance(action.default, str)): > setattr(namespace, action.dest, > self._get_value(action, action.default)) For me, this results in the following failure. [307/371/1] test_argparse NS(foo='foo_converted') Namespace(foo=0) NS(foo='foo_converted') Namespace(foo=0) test test_argparse failed -- Traceback (most recent call last): File "/home/barry/projects/python/cpython/Lib/test/test_argparse.py", line 4608, in test_type_function_call_with_non_string_default self.assertEqual(NS(foo='foo_converted'), args) File "/home/barry/projects/python/cpython/Lib/test/test_argparse.py", line 29, in assertEqual super(TestCase, self).assertEqual(obj1, obj2) AssertionError: NS(foo='foo_converted') != Namespace(foo=0) This test was added for the issue #12776 and #11839 fix, and it's pretty obvious why it fails. In the test, default=0 (i.e. a non-string). Do you think test_type_function_call_with_non_string_default() is a valid test of expected semantics? If not, then the test should be removed, and the changeset for #12667 and #11839 should be re-evaluated, at least to determine whether accurate tests of those bugs were applied. If that test is removed, then the above suggested change can be made to fix #15906. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 16:12:46 2012 From: report at bugs.python.org (Christian Heimes) Date: Wed, 12 Sep 2012 14:12:46 +0000 Subject: [issue10167] ESET Trojan Alert [python-3.1.2.amd64 ON Win7-64] In-Reply-To: <1287677105.85.0.830529518835.issue10167@psf.upfronthosting.co.za> Message-ID: <1347459166.82.0.672976260028.issue10167@psf.upfronthosting.co.za> Christian Heimes added the comment: We haven't received any similar report and 3.1.2 is outdated, too. I'm closing this bug. ---------- nosy: +christian.heimes resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 16:14:02 2012 From: report at bugs.python.org (Christian Heimes) Date: Wed, 12 Sep 2012 14:14:02 +0000 Subject: [issue11783] email parseaddr and formataddr should be IDNA aware In-Reply-To: <1302099121.47.0.140525796896.issue11783@psf.upfronthosting.co.za> Message-ID: <1347459242.33.0.943427573583.issue11783@psf.upfronthosting.co.za> Christian Heimes added the comment: 3.3 is in feature freeze mode. This new feature has to go into 3.4. ---------- nosy: +christian.heimes versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 16:14:22 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 12 Sep 2012 14:14:22 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347423748.82.0.977111638704.issue15906@psf.upfronthosting.co.za> Message-ID: <20120912101419.3bcd0e35@limelight.wooz.org> Barry A. Warsaw added the comment: On Sep 12, 2012, at 04:22 AM, Chris Jerdonek wrote: >The argparse documentation makes it pretty clear that 'type' is meant to be >applied only to strings. Then test_type_function_call_with_non_string_default() which was added to fix #12776 and #11839 is a bogus test, because it converts default=0 to 'foo_converted'. This is the test that fails if you restore the isinstance(action.default, str) test. >Also, the parse_args() documentation says, "Convert argument strings to >objects and assign them as attributes of the namespace," but it doesn't say >anything about also converting non-string defaults. > >Thirdly, the documentation for the "default" keyword argument says, "The >default keyword argument of add_argument(), whose value defaults to None, >specifies what value should be used if the command-line argument is not >present." It doesn't say that the value should be converted before being >used. In which case, doing *any* conversion of default seems wrong. Meaning, you can't expect the following to work: p.add_argument('--file', type=open, default='/etc/passwd') a = p.parse_args([]) a.file.read() because no --file argument was given, and a.file will be a string. This implies that if the command line argument is not given, then user code must test the type of a.file, and explicitly open it if it's a string, because it will only be a file object if --file *was* given on the command line. Then why use type=open at all? You're better off always expecting a.file to be a string and do the conversion explicitly after you've parsed the arguments. But maybe that's the right interpretation given the documentation. However, the original fix for #12776 and #11839 does not follow those semantics. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 16:19:54 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 12 Sep 2012 14:19:54 +0000 Subject: [issue15930] buffer overrun in wcstombs_errorpos() In-Reply-To: <1347453422.44.0.810518034926.issue15930@psf.upfronthosting.co.za> Message-ID: <1347459594.84.0.59903944878.issue15930@psf.upfronthosting.co.za> Stefan Krah added the comment: I'm convinced that this is a false positive: size_t wcstombs(char *dest, const wchar_t *src, size_t n); We have: 1) buf[0] = *wstr and buf[1] = 0. So: 2) wcstombs(NULL, buf, 0) <= 4. Then the man page says: "... the programmer should make sure n is greater or equal to wcstombs(NULL,src,0)+1." In this case, wcstombs(NULL, buf, 0) + 1 <= 5 and we call: wcstombs(char *dest, const wchar_t *src, 16); ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 16:44:01 2012 From: report at bugs.python.org (Christian Heimes) Date: Wed, 12 Sep 2012 14:44:01 +0000 Subject: [issue15930] buffer overrun in wcstombs_errorpos() In-Reply-To: <1347453422.44.0.810518034926.issue15930@psf.upfronthosting.co.za> Message-ID: <1347461041.5.0.215147553428.issue15930@psf.upfronthosting.co.za> Christian Heimes added the comment: Stefan, I agree with your analysis. With the terminating null wide char wcstombs will never read beyond the end of buf. ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 16:48:37 2012 From: report at bugs.python.org (Steven Bethard) Date: Wed, 12 Sep 2012 14:48:37 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347461317.33.0.363280197202.issue15906@psf.upfronthosting.co.za> Steven Bethard added the comment: I see. So right now, both string defaults and non-string defaults are being converted with the type= function. That seems suspect to me since the documentation explicitly says "type= can take any callable that takes a single string argument and returns the converted value", so non-string defaults don't make sense to pass to that function. I believe test_type_function_call_with_non_string_default() comes from Arnaud Fontaine. Arnaud, can you comment on the intent of that test? My thoughts: * We should not be converting non-string defaults, or the documentation's description of the type= argument doesn't make sense. * For the string defaults, I can see the argument for not converting them, and the argparse docs never show them being converted from strings. I thought there was a discussion somewhere where someone had requested the current behavior, but I can't for the life of me find that discussion, so perhaps I'm imagining it... In terms of potential for breaking code, I'm not too worried about removing type conversion for non-string defaults - this never happened before the fix for #12776 and #11839, so I doubt much code depends on it. I am more worried about removing type conversion for string defaults - this has worked for a long time, so there probably is some code that depends on it. ---------- nosy: +arnau _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 17:01:58 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 12 Sep 2012 15:01:58 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347462118.05.0.610150566761.issue15906@psf.upfronthosting.co.za> R. David Murray added the comment: *No* code should depend on it: this fix is very recent and is not in any released version of Python, not even the RCs. The bogus test should be removed. When I committed that patch I did not understand the correct (documented) semantics of default conversion, and so did not realize the test was bogus. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 17:03:00 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 12 Sep 2012 15:03:00 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347462180.7.0.480939964287.issue15906@psf.upfronthosting.co.za> R. David Murray added the comment: Actually, no, the test should not be removed, it should be reversed so as to test the documented behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 17:10:50 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 12 Sep 2012 15:10:50 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347462180.7.0.480939964287.issue15906@psf.upfronthosting.co.za> Message-ID: <20120912111047.04e47da1@limelight.wooz.org> Barry A. Warsaw added the comment: On Sep 12, 2012, at 03:03 PM, R. David Murray wrote: >Actually, no, the test should not be removed, it should be reversed so as to >test the documented behavior. Good point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 17:32:22 2012 From: report at bugs.python.org (Gabor Kovacs) Date: Wed, 12 Sep 2012 15:32:22 +0000 Subject: [issue15931] inspect.findsource fails after directory change Message-ID: <1347463942.49.0.408409423071.issue15931@psf.upfronthosting.co.za> New submission from Gabor Kovacs: The attached script works in 2.6(.4) but not in 2.7(.3); the script cannot locate its own source code if invoked by relative path and work directory has changed. If line 8 uncommented, everything is fine due to caching. I think this is related to issue #4050 changes in inspect.py. ~ kgabor$ python ./instest.py None ./instest.py Traceback (most recent call last): File "./instest.py", line 10, in print inspect.getsourcefile(A), inspect.getfile(A),inspect.findsource(A) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/inspect.py", line 529, in findsource raise IOError('source code not available') IOError: source code not available ~ kgabor$ pwd /Users/kgabor ~ kgabor$ python /Users/kgabor/instest.py /Users/kgabor/instest.py /Users/kgabor/instest.py (['import inspect\n', 'import os\n', '\n', 'class A:\n', ' def __init__(self):\n', ' self.a=1\n', '\n', '#print inspect.getsourcefile(A),inspect.getfile(A),inspect.findsource(A)\n', "os.chdir('/')\n", 'print inspect.getsourcefile(A), inspect.getfile(A),inspect.findsource(A)\n'], 3) ---------- components: Library (Lib) files: instest.py messages: 170389 nosy: kgabor79 priority: normal severity: normal status: open title: inspect.findsource fails after directory change type: behavior versions: Python 2.6, Python 2.7 Added file: http://bugs.python.org/file27179/instest.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 17:40:51 2012 From: report at bugs.python.org (Steven Bethard) Date: Wed, 12 Sep 2012 15:40:51 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347464451.48.0.294293404896.issue15906@psf.upfronthosting.co.za> Steven Bethard added the comment: Ok, sounds good. Let's make the test check the documented behavior, and then add back the isinstance(action.default, str) check. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 17:43:05 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 12 Sep 2012 15:43:05 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347464585.41.0.776869378671.issue15906@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : Added file: http://bugs.python.org/file27180/15906-3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 17:47:21 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 12 Sep 2012 15:47:21 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347461317.33.0.363280197202.issue15906@psf.upfronthosting.co.za> Message-ID: <20120912114717.31479941@resist.wooz.org> Barry A. Warsaw added the comment: On Sep 12, 2012, at 02:48 PM, Steven Bethard wrote: >We should not be converting non-string defaults, or the documentation's >description of the type= argument doesn't make sense. Agreed. If we also take RDM's suggestion of reversing the sense of test_type_function_call_only_once(), then patch 15906-3.diff would do this[*], restore the isinstance test of action.default, and retain the fix for the regression noted in this issue's description. >For the string defaults, I can see the argument for not converting them, and >the argparse docs never show them being converted from strings. I thought >there was a discussion somewhere where someone had requested the current >behavior, but I can't for the life of me find that discussion, so perhaps I'm >imagining it... > >In terms of potential for breaking code, I'm not too worried about removing >type conversion for non-string defaults - this never happened before the fix >for #12776 and #11839, so I doubt much code depends on it. I am more worried >about removing type conversion for string defaults - this has worked for a >long time, so there probably is some code that depends on it. Agreed. Removing the conversion of non-string defaults, but retaining the conversion of string defaults is probably the safest course of action. Do we need a new test for conversion of string defaults? [*] Patch is against 2.7, but if we all agree this is the appropriate fix, I will port it to 3.2 and 3.3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 17:47:58 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 12 Sep 2012 15:47:58 +0000 Subject: [issue15931] inspect.findsource fails after directory change In-Reply-To: <1347463942.49.0.408409423071.issue15931@psf.upfronthosting.co.za> Message-ID: <1347464878.28.0.660071216534.issue15931@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 17:48:39 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 12 Sep 2012 15:48:39 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347464451.48.0.294293404896.issue15906@psf.upfronthosting.co.za> Message-ID: <20120912114836.07a023de@resist.wooz.org> Barry A. Warsaw added the comment: On Sep 12, 2012, at 03:40 PM, Steven Bethard wrote: >Ok, sounds good. Let's make the test check the documented behavior, and then >add back the isinstance(action.default, str) check. See patch 15906-3.diff for Python 2.7. If acceptable, I will apply and forward port it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 17:49:42 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 12 Sep 2012 15:49:42 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347464982.48.0.700246859663.issue15906@psf.upfronthosting.co.za> R. David Murray added the comment: Looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 17:56:31 2012 From: report at bugs.python.org (berdario) Date: Wed, 12 Sep 2012 15:56:31 +0000 Subject: [issue15932] files in the csv documentation's examples are not closed Message-ID: <1347465391.09.0.1751065548.issue15932@psf.upfronthosting.co.za> New submission from berdario: I changed the examples to use the with statement ---------- assignee: docs at python components: Documentation files: doc.diff keywords: patch messages: 170394 nosy: berdario, docs at python, ezio.melotti priority: normal severity: normal status: open title: files in the csv documentation's examples are not closed Added file: http://bugs.python.org/file27181/doc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 17:57:37 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 12 Sep 2012 15:57:37 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347465457.03.0.319260996647.issue15906@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Oops, one small correction for 15906-3.diff: In Python 2.7, s/str/basestring/ Obviously isinstance should just check for str-y-ness in Python 3.{2,3} ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 17:59:04 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 12 Sep 2012 15:59:04 +0000 Subject: [issue15923] Building from a fresh clone breaks on Parser/asdl_c.py In-Reply-To: <1347398039.31.0.775610002592.issue15923@psf.upfronthosting.co.za> Message-ID: <1347465544.7.0.994592851719.issue15923@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: It's most probably related to issue15801: if 'name' is an instance of Python-defined class, then it was considered as a mapping... ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 18:02:45 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 12 Sep 2012 16:02:45 +0000 Subject: [issue15926] Segmentation fault after multiple reinitializations In-Reply-To: <1347419581.97.0.0354883385349.issue15926@psf.upfronthosting.co.za> Message-ID: <3XH7784DJlzQZQ@mail.python.org> Roundup Robot added the comment: New changeset 8d22d9528164 by Antoine Pitrou in branch 'default': Issue #15926: Fix crash after multiple reinitializations of the interpreter. http://hg.python.org/cpython/rev/8d22d9528164 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 18:03:51 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 12 Sep 2012 16:03:51 +0000 Subject: [issue15926] Segmentation fault after multiple reinitializations In-Reply-To: <1347419581.97.0.0354883385349.issue15926@psf.upfronthosting.co.za> Message-ID: <1347465831.35.0.0100903279988.issue15926@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This should be fixed now. Georg, this is up to you whether this deserves being ported to 3.3.0 or not. ---------- assignee: -> georg.brandl nosy: +georg.brandl resolution: -> fixed stage: needs patch -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 18:03:58 2012 From: report at bugs.python.org (Steven Bethard) Date: Wed, 12 Sep 2012 16:03:58 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347465838.85.0.0659806606462.issue15906@psf.upfronthosting.co.za> Steven Bethard added the comment: Patch, with the basestring amendment, looks good. > Do we need a new test for conversion of string defaults? Yeah, I guess go ahead and add one. That will at least document our intentions here, and if we decide to change that later, then it will force us to deprecate the conversion of string defaults first (which we probably should if we're going to.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 18:09:50 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 12 Sep 2012 16:09:50 +0000 Subject: [issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0 In-Reply-To: <1344473974.14.0.584788696764.issue15599@psf.upfronthosting.co.za> Message-ID: <1347466190.13.0.330049469493.issue15599@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Stefan, do you plan to commit this patch (or a similar one)? The FreeBSD buildbot is crashing again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 18:20:16 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 12 Sep 2012 16:20:16 +0000 Subject: [issue15933] flaky test in test_datetime Message-ID: <1347466816.36.0.945599436453.issue15933@psf.upfronthosting.co.za> New submission from Antoine Pitrou: Seen on a buildbot: ====================================================================== FAIL: test_today (test.datetimetester.TestSubclassDateTime_Fast) ---------------------------------------------------------------------- Traceback (most recent call last): File "/export/home/buildbot/32bits/3.2.cea-indiana-x86/build/Lib/test/datetimetester.py", line 1009, in test_today abs(todayagain - today) < timedelta(seconds=0.5)) AssertionError: False is not true http://buildbot.python.org/all/builders/x86%20OpenIndiana%203.2/builds/1341/steps/test/logs/stdio ---------- components: Tests keywords: easy messages: 170401 nosy: belopolsky, pitrou priority: normal severity: normal stage: needs patch status: open title: flaky test in test_datetime type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 18:21:35 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 12 Sep 2012 16:21:35 +0000 Subject: [issue15934] flaky test in test_ftplib Message-ID: <1347466895.7.0.169569796798.issue15934@psf.upfronthosting.co.za> New submission from Antoine Pitrou: Seen on a buildbot: ====================================================================== ERROR: test_storlines (test.test_ftplib.TestTLS_FTPClassMixin) ---------------------------------------------------------------------- Traceback (most recent call last): File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_ftplib.py", line 583, in test_storlines self.client.storlines('stor', f) File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/ftplib.py", line 811, in storlines conn.unwrap() File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/ssl.py", line 495, in unwrap s = self._sslobj.shutdown() socket.timeout: The read operation timed out http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%203.x/builds/4429/steps/test/logs/stdio ---------- components: Tests messages: 170402 nosy: giampaolo.rodola, pitrou priority: normal severity: normal status: open title: flaky test in test_ftplib type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 18:30:54 2012 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 12 Sep 2012 16:30:54 +0000 Subject: [issue15934] flaky test in test_ftplib In-Reply-To: <1347466895.7.0.169569796798.issue15934@psf.upfronthosting.co.za> Message-ID: <1347467454.05.0.934205079241.issue15934@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Assigning to me but I won't be able to look into it for a while. ---------- assignee: -> giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 19:01:43 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 12 Sep 2012 17:01:43 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347469303.54.0.58691424901.issue15906@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > Do we need a new test for conversion of string defaults? I think we should also update the documentation of the "default" keyword argument (and/or the "type" argument) to remove any ambiguity and make the behavior more clear. Maybe one way to view what is happening (and maybe one way to describe it in the documentation) is that if a default value is a string, the parser treats it as a default for the command-line *argument*, otherwise it treats it as a default for the final *attribute*. Lastly, can we also add the test from one of my first comments above to check that "double conversion" of strings doesn't take place? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 19:19:40 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 12 Sep 2012 17:19:40 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347470380.9.0.782450019868.issue15906@psf.upfronthosting.co.za> R. David Murray added the comment: All three of those sound like good ideas (testing string conversion, clarifying docs, adding the no-double conversion test). Do you want to prepare the patch, Chris? Barry can apply his any time and yours can be a followup. We should also make a doc update equivalent to that we made for optparse in issue 5088, but that should probably be a different issue, where we discuss how/whether to change that behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 19:24:52 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 12 Sep 2012 17:24:52 +0000 Subject: [issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0 In-Reply-To: <1344473974.14.0.584788696764.issue15599@psf.upfronthosting.co.za> Message-ID: <1347470692.16.0.0283814851772.issue15599@psf.upfronthosting.co.za> Stefan Krah added the comment: I was hesitating because the other FreeBSD bots don't have that problem. The other option would be to kick out the FreeBSD/kvm bot in favor of FreeBSD/Virtualbox. http://buildbot.python.org/all/buildslaves/koobs-freebsd-clang seems to be very stable. I could take down FreeBSD/kvm altogether. Is Python supposed to work with gil_interval = 1 or is some potential flakiness expected? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 19:26:50 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 12 Sep 2012 17:26:50 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347470810.57.0.660317020705.issue15906@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > Do you want to prepare the patch, Chris? Sure, I should be able to get to this today or tomorrow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 19:32:03 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 12 Sep 2012 17:32:03 +0000 Subject: [issue15932] files in the csv documentation's examples are not closed In-Reply-To: <1347465391.09.0.1751065548.issue15932@psf.upfronthosting.co.za> Message-ID: <1347471123.81.0.76303429861.issue15932@psf.upfronthosting.co.za> Brett Cannon added the comment: Quick glance at the patch LGTM. I don't have commit access handy so I can't do it myself ATM. ---------- nosy: +brett.cannon stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 19:35:20 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 12 Sep 2012 17:35:20 +0000 Subject: [issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0 In-Reply-To: <1347470692.16.0.0283814851772.issue15599@psf.upfronthosting.co.za> Message-ID: <1347471303.3320.1.camel@localhost.localdomain> Antoine Pitrou added the comment: > I was hesitating because the other FreeBSD bots don't have that problem. > The other option would be to kick out the FreeBSD/kvm bot in favor of > FreeBSD/Virtualbox. Well, if the test is just running too slow, changing the switch interval sounds easier to me than deploying a whole new setup. > Is Python supposed to work with gil_interval = 1 or is some > potential flakiness expected? I don't know. It's not supposed to be widely tunable, though. Most legitimate uses would be to lower or raise the interval a bit, not choose insane values. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 19:35:43 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 12 Sep 2012 17:35:43 +0000 Subject: [issue15926] Segmentation fault after multiple reinitializations In-Reply-To: <1347419581.97.0.0354883385349.issue15926@psf.upfronthosting.co.za> Message-ID: <1347471343.42.0.495720581363.issue15926@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: +1 for including the fix in 3.3.0. This segmentation fault was reproducible in test suite of dbus-python: http://cgit.freedesktop.org/dbus/dbus-python/tree/test/import-repeatedly.c ---------- priority: high -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 19:39:29 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 12 Sep 2012 17:39:29 +0000 Subject: [issue15933] flaky test in test_datetime In-Reply-To: <1347466816.36.0.945599436453.issue15933@psf.upfronthosting.co.za> Message-ID: <1347471569.16.0.344244114185.issue15933@psf.upfronthosting.co.za> Brett Cannon added the comment: First off, that assertEquals should have a custom error message stating what values the date objects had to better tell how off things were. Second, this can probably be solved by upping the timedelta to something like a minute or something for when it's run on a really slow machine (I mean the test itself is wonky based on the the definition of date.today() and not being able to freeze time, so being upwards of a minute off should be acceptable to verify it's still "today"). ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 19:41:14 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 12 Sep 2012 17:41:14 +0000 Subject: [issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0 In-Reply-To: <1347471303.3320.1.camel@localhost.localdomain> Message-ID: <20120912174114.GA32232@sleipnir.bytereef.org> Stefan Krah added the comment: OK, I'll commit the patch soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 19:59:31 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 12 Sep 2012 17:59:31 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347470380.9.0.782450019868.issue15906@psf.upfronthosting.co.za> Message-ID: <20120912135927.3273d060@limelight.wooz.org> Barry A. Warsaw added the comment: On Sep 12, 2012, at 05:19 PM, R. David Murray wrote: >All three of those sound like good ideas (testing string conversion, >clarifying docs, adding the no-double conversion test). Do you want to >prepare the patch, Chris? Barry can apply his any time and yours can be a >followup. I will add the no-double-conversion test. I think that will just leave the doc updates for Chris once my patch lands in all three branches. That will be RSN, modulo local test suite runs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 21:09:57 2012 From: report at bugs.python.org (Uzume) Date: Wed, 12 Sep 2012 19:09:57 +0000 Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ... In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za> Message-ID: <1347476997.39.0.459436175583.issue7475@psf.upfronthosting.co.za> Uzume added the comment: Many have chimed in on this topic but I thought I would lend my stance--for whatever it is worth. I also believe most of these do not fit concept of a character codec and some sort of transforms would likely be useful, however most are sort of specialized (e.g., there should probably be a generalized compression library interface al la hashlib): rot13: a (albeit simplistic) text cipher (str to str; though bytes to bytes could be argued since since many crypto functions do that) zlib, bz2, etc. (lzma/xz should also be here): all bytes to bytes compression transforms hex(adecimal) uu, base64, etc.: these more or less fit the description of a character codec as they map between bytes and str, however, I am not sure they are really the same thing as these are basically doing a radix transformation to character symbols and the mapping it not strictly from bytes to a single character and back as a true character codec seems to imply. As evidenced by by int() format() and bytes.fromhex(), float.hex(), float.fromhex(), etc., these are more generalized conversions for serializing strings of bits into a textual representation (possibly for human consumption). I personally feel any .hex(), etc. method would be better off as a format() style formatter if they are to exist in such a space at all (i.e., not some more generalized conversion library--which we have but since 3.x could probably use to be updated and cleaned up). ---------- nosy: +uzume _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 21:11:51 2012 From: report at bugs.python.org (Uzume) Date: Wed, 12 Sep 2012 19:11:51 +0000 Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ... In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za> Message-ID: <1347477111.94.0.235462871647.issue7475@psf.upfronthosting.co.za> Changes by Uzume : ---------- nosy: -uzume _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 21:31:55 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 12 Sep 2012 19:31:55 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <3XHCmT2wHQzQYl@mail.python.org> Roundup Robot added the comment: New changeset 8f847f66a49f by Barry Warsaw in branch '2.7': A follow up for issue #15906: change the test for calling the type conversion http://hg.python.org/cpython/rev/8f847f66a49f New changeset 088b16bd6396 by Barry Warsaw in branch '3.2': A follow up for issue #15906: change the test for calling the type conversion http://hg.python.org/cpython/rev/088b16bd6396 New changeset 9ae9326cd79a by Barry Warsaw in branch 'default': Merge 3.2 fix updates and tests for issue #15906. http://hg.python.org/cpython/rev/9ae9326cd79a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 21:37:55 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 12 Sep 2012 19:37:55 +0000 Subject: [issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0 In-Reply-To: <1344473974.14.0.584788696764.issue15599@psf.upfronthosting.co.za> Message-ID: <3XHCvQ0fX8zQVk@mail.python.org> Roundup Robot added the comment: New changeset 9b40d018e4cf by Stefan Krah in branch 'default': Issue #15599: FreeBSD on KVM cannot handle a very low switch interval. http://hg.python.org/cpython/rev/9b40d018e4cf ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 21:39:05 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 12 Sep 2012 19:39:05 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347478745.58.0.281888169821.issue15906@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Chris, it's all yours. I am however going to close the bug as fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 21:39:15 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 12 Sep 2012 19:39:15 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347478755.33.0.302194669977.issue15906@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 21:49:05 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 12 Sep 2012 19:49:05 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347479345.33.0.225998401136.issue15906@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks for committing the change. However-- + def test_no_double_type_conversion_of_default(self): + def extend(str_to_convert): + return str_to_convert + '*' + + parser = argparse.ArgumentParser() + parser.add_argument('--test', type=extend, default='*') + args = parser.parse_args([]) + # The test argument will be two stars, one coming from the default + # value and one coming from the type conversion being called exactly + # once. + self.assertEqual(NS(test='**'), args) This was actually my concern, that the type conversion would be applied twice, and the reason for my suggesting the test. This expected value is not the one we want, because it shows that the argument is getting "double converted," though the test is supposed to assert that double conversion doesn't take place. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 21:50:25 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 12 Sep 2012 19:50:25 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347479425.82.0.0919488388943.issue15906@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Oh, never mind. The initial default value has one star to begin with. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 22:15:07 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 12 Sep 2012 20:15:07 +0000 Subject: [issue4356] Add "key" argument to "bisect" module functions In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za> Message-ID: <1347480907.82.0.88255546152.issue4356@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 23:08:52 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 12 Sep 2012 21:08:52 +0000 Subject: [issue13990] Benchmarks: 2to3 failures on the py3 side In-Reply-To: <1328895154.39.0.105937484663.issue13990@psf.upfronthosting.co.za> Message-ID: <1347484132.63.0.133200646606.issue13990@psf.upfronthosting.co.za> Brett Cannon added the comment: I can't reproduce the problem anymore. ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 23:26:15 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 12 Sep 2012 21:26:15 +0000 Subject: [issue15935] clarify argparse docs re: add_argument() type and default arguments Message-ID: <1347485175.79.0.860808168134.issue15935@psf.upfronthosting.co.za> New submission from Chris Jerdonek: This issue is to clarify in the documentation the argparse behavior for which tests were added in issue 15906. The behavior involves when the type callable should be applied to default arguments. See, for example, the following comment for what roughly needs to be added: http://bugs.python.org/issue15906#msg170404 I will provide a patch. ---------- assignee: docs at python components: Documentation keywords: easy messages: 170421 nosy: barry, bethard, cjerdonek, docs at python, r.david.murray priority: normal severity: normal stage: needs patch status: open title: clarify argparse docs re: add_argument() type and default arguments type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 23:27:24 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 12 Sep 2012 21:27:24 +0000 Subject: [issue15906] argparse add_argument() confusing behavior when type=str, default= In-Reply-To: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za> Message-ID: <1347485244.69.0.144540739699.issue15906@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > I think that will just leave the doc updates for Chris once my patch lands in all three branches. I created an issue for this here: http://bugs.python.org/issue15935 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 23:36:20 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 12 Sep 2012 21:36:20 +0000 Subject: [issue10224] Build 3.x documentation using python3.x In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za> Message-ID: <1347485780.51.0.872948254048.issue10224@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 12 23:47:54 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 12 Sep 2012 21:47:54 +0000 Subject: [issue10224] Build 3.x documentation using python3.x In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za> Message-ID: <1347486474.4.0.181361381274.issue10224@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 00:09:02 2012 From: report at bugs.python.org (Jacek Bzdak) Date: Wed, 12 Sep 2012 22:09:02 +0000 Subject: [issue15936] Add link from os.urandom to random.SystemRandom Message-ID: <1347487742.57.0.57747338883.issue15936@psf.upfronthosting.co.za> New submission from Jacek Bzdak: It would be great if one sentence was added to os.urandom description: "For easy to use interface to system randomness please see random.SystemRandom class". The reason for this change is that many references quote only os.urandom as a cryptographically strong randomeness source in python, and for some people it might be not obvious that there already exists such easy to use api to use cryptographically strong randomness (that is random.SystemRandom class). It would be good to point such people to right class. Myself for example spent last hour trying to create makeshift Random subclass that uses os.urandom as it's randomness source. ---------- assignee: docs at python components: Documentation messages: 170423 nosy: Jacek.Bzdak, docs at python priority: normal severity: normal status: open title: Add link from os.urandom to random.SystemRandom type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 01:18:46 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 12 Sep 2012 23:18:46 +0000 Subject: [issue15935] clarify argparse docs re: add_argument() type and default arguments In-Reply-To: <1347485175.79.0.860808168134.issue15935@psf.upfronthosting.co.za> Message-ID: <1347491926.87.0.93690273317.issue15935@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attaching patch. ---------- keywords: +patch Added file: http://bugs.python.org/file27182/issue-15935-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 02:12:36 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 13 Sep 2012 00:12:36 +0000 Subject: [issue15437] Merge Doc/ACKS.txt names into Misc/ACKS In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za> Message-ID: <1347495156.1.0.999738926994.issue15437@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Just an FYI that Ezio asked Georg about this issue on IRC yesterday or the day before, and Georg said +1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 05:32:08 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 13 Sep 2012 03:32:08 +0000 Subject: [issue15927] csv.reader() does not support escaped newline when quoting=csv.QUOTE_NONE In-Reply-To: <1347425390.54.0.862014726204.issue15927@psf.upfronthosting.co.za> Message-ID: <1347507128.46.0.599941820352.issue15927@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- components: +Library (Lib) -None title: cvs.reader does not support escaped newline when quoting=cvs.QUOTE_NONE -> csv.reader() does not support escaped newline when quoting=csv.QUOTE_NONE _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 06:06:42 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 13 Sep 2012 04:06:42 +0000 Subject: [issue15924] 404 link on Python about page In-Reply-To: <1347402398.06.0.816784008055.issue15924@psf.upfronthosting.co.za> Message-ID: <1347509202.45.0.740364302529.issue15924@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks for the report. However, for this issue, you should e-mail webmaster at python.org instead, as this page describes: http://www.python.org/about/website/ The part of the Python web site affected by this issue is maintained separately from the parts of the web site about the Python language, which is what this bug tracker is for. ---------- nosy: +cjerdonek resolution: -> invalid _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 06:07:58 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 13 Sep 2012 04:07:58 +0000 Subject: [issue15924] 404 link on Python about page In-Reply-To: <1347402398.06.0.816784008055.issue15924@psf.upfronthosting.co.za> Message-ID: <1347509278.69.0.587159719425.issue15924@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 07:04:37 2012 From: report at bugs.python.org (Ned Deily) Date: Thu, 13 Sep 2012 05:04:37 +0000 Subject: [issue15924] 404 link on Python about page In-Reply-To: <1347402398.06.0.816784008055.issue15924@psf.upfronthosting.co.za> Message-ID: <1347512677.14.0.571051476006.issue15924@psf.upfronthosting.co.za> Ned Deily added the comment: The link has since been fixed thanks to your suggestion. ---------- components: +Tests -None nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 07:21:52 2012 From: report at bugs.python.org (Berker Peksag) Date: Thu, 13 Sep 2012 05:21:52 +0000 Subject: [issue15924] 404 link on Python about page In-Reply-To: <1347402398.06.0.816784008055.issue15924@psf.upfronthosting.co.za> Message-ID: <1347513712.62.0.894781408283.issue15924@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- components: +None -Tests _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 10:24:44 2012 From: report at bugs.python.org (Steven Bethard) Date: Thu, 13 Sep 2012 08:24:44 +0000 Subject: [issue15935] clarify argparse docs re: add_argument() type and default arguments In-Reply-To: <1347485175.79.0.860808168134.issue15935@psf.upfronthosting.co.za> Message-ID: <1347524684.37.0.968066665949.issue15935@psf.upfronthosting.co.za> Steven Bethard added the comment: Looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 10:54:51 2012 From: report at bugs.python.org (Cioroianu Nicolin) Date: Thu, 13 Sep 2012 08:54:51 +0000 Subject: [issue15937] Assertion failure (C:\Delphi\progs32\Python\PythonIDE\cPyRemoteDebugger.pas, line 1175). Message-ID: <1347526491.38.0.848154883344.issue15937@psf.upfronthosting.co.za> New submission from Cioroianu Nicolin: Hello, Running the following script frame: import re #import modulefinder #m=str(raw_input("Get a string:")) m= "IT_SetBusParameters(param1,param2,param3,param4,param5,param6)" if m: cnt=m.count(',') if cnt: nr=0 s=re.split(',',m) for nr in cnt: print s[i] i=i+1 #PendingDeprecationWarning else: return print "finished" I have used PyScripter as running ide. I received the following failure: Assertion failure (C:\Delphi\progs32\Python\PythonIDE\cPyRemoteDebugger.pas, line 1175). Exception class: EAssertionFailed Exception message: Assertion failure (C:\Delphi\progs32\Python\PythonIDE\cPyRemoteDebugger.pas, line 1175). Exception address: 00908B3E ------------------------------------------------------------------------------ PyScripter version : 2.5.3.0 x86 Python DLL : python27.dll Python Engine : peRemote ------------------------------------------------------------------------------ Stack list, generated 13.09.2012 09:45:16 (00507B39){PyScripter.exe} [00908B39] cPyRemoteDebugger.TPyRemoteInterpreter.ShutDownServer (Line 1175, "cPyRemoteDebugger.pas" + 41) + $1B (00006609){PyScripter.exe} [00407609] System. at Assert + $25 (00507B39){PyScripter.exe} [00908B39] cPyRemoteDebugger.TPyRemoteInterpreter.ShutDownServer (Line 1175, "cPyRemoteDebugger.pas" + 41) + $1B (00505F0D){PyScripter.exe} [00906F0D] cPyRemoteDebugger.TPyRemoteInterpreter.ReInitialize (Line 831, "cPyRemoteDebugger.pas" + 32) + $2 (003A45C5){PyScripter.exe} [007A55C5] cPyBaseDebugger.TPythonControl.PrepareRun (Line 871, "cPyBaseDebugger.pas" + 18) + $4 (003A469D){PyScripter.exe} [007A569D] cPyBaseDebugger.TPythonControl.Run (Line 897, "cPyBaseDebugger.pas" + 5) + $3 (00516455){PyScripter.exe} [00917455] frmPyIDEMain.TPyIDEMainForm.actRunExecute (Line 1901, "frmPyIDEMain.pas" + 8) + $A (0005A8E3){PyScripter.exe} [0045B8E3] System.Classes.TBasicAction.Execute + $F (000895F5){PyScripter.exe} [0048A5F5] Vcl.ActnList.TContainedAction.Execute + $31 (0008A350){PyScripter.exe} [0048B350] Vcl.ActnList.TCustomAction.Execute + $50 (0005A7A7){PyScripter.exe} [0045B7A7] System.Classes.TBasicActionLink.Execute + $13 (0020B1C9){PyScripter.exe} [0060C1C9] TB2Item.TTBCustomItem.Click (Line 1474, "TB2Item.pas" + 23) + $7 (0022FBA8){PyScripter.exe} [00630BA8] SpTBXItem.TSpTBXCustomItem.Click (Line 4400, "SpTBXItem.pas" + 2) + $2 (0020B0C2){PyScripter.exe} [0060C0C2] TB2Item.TTBCustomItem.ClickWndProc (Line 1423, "TB2Item.pas" + 29) + $5 (0005B5D8){PyScripter.exe} [0045C5D8] System.Classes.StdWndProc + $14 (001550C7){PyScripter.exe} [005560C7] Vcl.Forms.TApplication.ProcessMessage + $F3 (0015510A){PyScripter.exe} [0055610A] Vcl.Forms.TApplication.HandleMessage + $A (00155449){PyScripter.exe} [00556449] Vcl.Forms.TApplication.Run + $C9 (00564A59){PyScripter.exe} [00965A59] PyScripter.PyScripter (Line 136, "" + 14) + $2 ------------------------------------------------------------------------------ System : Windows 7 Professional, Version: 6.1, Build: 1DB1, "Service Pack 1" Processor: Intel, Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2490 MHz MMX SSE SSE2 SSE3 SSSE3 SSE41 SSE42 64 bits DEP Memory: 8142; free 5122 Display : 1600x900 pixels, 32 bpp ------------------------------------------------------------------------------ List of loaded modules: [00400000] C:\Program Files (x86)\PyScripter\PyScripter.exe 2.5.3.0 - 2.5.3.0 [05BC0000] C:\Python27\DLLs\_socket.pyd <1E1D0000> (no module version info) [10000000] C:\Python27\DLLs\_ssl.pyd (no module version info) [1D110000] C:\Python27\DLLs\select.pyd (no module version info) [1D120000] C:\Python27\DLLs\unicodedata.pyd (no module version info) [1E000000] C:\Windows\system32\python27.dll 2.7.150.1013 - 2.7 Python Core [1E7A0000] C:\Windows\system32\pywintypes27.dll 2.7.217.0 - 2.7.217.0 [1EA10000] C:\Python27\lib\site-packages\win32\win32file.pyd 2.7.217.0 - 2.7.217.0 [1EB90000] C:\Python27\lib\site-packages\win32\win32pipe.pyd 2.7.217.0 - 2.7.217.0 [65DF0000] C:\Windows\System32\itircl.dll 6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850) Microsoft? InfoTech IR Local DLL [65E20000] C:\Windows\system32\hhctrl.ocx 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Microsoft? HTML Help Control [66320000] C:\Windows\System32\itss.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Microsoft? InfoTech Storage System Library [66710000] C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.17825_none_72d273598668a06b\gdiplus.dll 6.1.7601.17825 - 6.1.7601.17825 (win7sp1_gdr.120420-1503) Microsoft GDI+ [668E0000] C:\Windows\system32\NetworkExplorer.dll 6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255) Network Explorer [66C20000] C:\Windows\system32\WMVCore.DLL 12.0.7601.17514 - 12.0.7601.17514 (win7sp1_rtm.101119-1850) Windows Media Playback/Authoring DLL [66E90000] C:\Windows\system32\wpdshext.dll 6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255) Portable Devices Shell Extension [670D0000] C:\Windows\system32\LINKINFO.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Windows Volume Tracking [671B0000] C:\Windows\System32\shdocvw.dll 6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255) Shell Doc Object and Control Library [67210000] C:\Windows\system32\EhStorAPI.dll 6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255) Windows Enhanced Storage API [67240000] C:\Windows\system32\audiodev.dll 6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255) Portable Media Devices Shell Extension [67280000] C:\Windows\system32\PortableDeviceApi.dll 6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255) Windows Portable Device API Components [67310000] C:\Windows\system32\ntshrui.dll 6.1.7601.17755 - 6.1.7600.16385 (win7_rtm.090713-1255) Shell extensions for sharing [67380000] C:\Windows\system32\WMASF.DLL 12.0.7600.16385 - 12.0.7600.16385 (win7_rtm.090713-1255) Windows Media ASF DLL [673C0000] C:\Windows\System32\DAVHLPR.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) DAV Helper DLL [673D0000] C:\Windows\System32\davclnt.dll 6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850) Web DAV Client DLL [673F0000] C:\Windows\system32\EhStorShell.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Windows Enhanced Storage Shell Extension DLL [67430000] C:\Windows\System32\ntlanman.dll 6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255) Microsoft? Lan Manager [67450000] C:\Windows\System32\drprov.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Microsoft Remote Desktop Session Host Server Network Provider [67460000] C:\Windows\system32\IconCodecService.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Converts a PNG part of the icon to a legacy bmp icon [68130000] C:\Windows\system32\slc.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Software Licensing Client Dll [68140000] C:\Windows\system32\olepro32.dll 6.1.7601.17514 - 6.1.7601.17514 [686F0000] C:\Windows\SysWOW64\mshtml.dll 8.0.7601.17874 - 8.00.7600.16385 (win7_rtm.090713-1255) Microsoft (R) HTML Viewer [68D50000] C:\Windows\system32\DUI70.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Windows DirectUI Engine [69190000] C:\Windows\SysWOW64\ATL.DLL 3.5.2284.0 - 3.05.2284 ATL Module for Windows XP (Unicode) [691B0000] C:\Windows\SysWOW64\msls31.dll 3.10.349.0 - 3.10.349.0 Microsoft Line Services library file [691E0000] C:\Windows\system32\explorerframe.dll 6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255) ExplorerFrame [69410000] C:\Windows\system32\WindowsCodecs.dll 6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850) Microsoft Windows Codecs Library [6C8C0000] C:\Windows\SysWOW64\pngfilt.dll 8.0.7600.16385 - 8.00.7600.16385 (win7_rtm.090713-1255) IE PNG plugin image decoder [6C910000] C:\Windows\system32\MLANG.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Multi Language Support DLL [6D090000] C:\Windows\SysWOW64\ieframe.dll 8.0.7601.17874 - 8.00.7600.16385 (win7_rtm.090713-1255) Internet Browser [6E3F0000] C:\Windows\system32\ImgUtil.dll 8.0.7601.17514 - 8.00.7601.17514 (win7sp1_rtm.101119-1850) IE plugin image decoder support DLL [6E400000] C:\Windows\system32\DUser.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Windows DirectUser Engine [70580000] C:\Windows\System32\netshell.dll 6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255) Network Connections Shell [70A60000] C:\Windows\System32\msxml6.dll 6.30.7601.17857 - 6.30.7601.17857 MSXML 6.0 SP3 [71740000] C:\Windows\system32\msimtf.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Active IMM Server DLL [71750000] C:\Windows\system32\xmllite.dll 1.3.1001.0 - 1.3.1001.0 Microsoft XmlLite Library [71960000] C:\Program Files (x86)\Internet Explorer\ieproxy.dll 8.0.7601.17874 - 8.00.7601.17874 (win7sp1_gdr.120626-1620) IE ActiveX Interface Marshaling Library [71AC0000] C:\Windows\system32\browcli.dll 6.1.7601.17887 - 6.1.7601.17887 (win7sp1_gdr.120704-0720) Browser Service Client DLL [71AD0000] C:\Windows\system32\dfscli.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Windows NT Distributed File System Client DLL [71AE0000] C:\Windows\SysWOW64\fdWNet.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Function Discovery WNet Provider Dll [71AF0000] C:\Windows\System32\wcnapi.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Windows Connect Now - API Helper DLL [71B10000] C:\Windows\System32\fdwcn.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Windows Connect Now - Config Function Discovery Provider DLL [71B30000] C:\Windows\SysWOW64\FunDisc.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Function Discovery Dll [71B60000] C:\Windows\system32\SearchFolder.dll 6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255) SearchFolder [71C00000] C:\Windows\SysWOW64\actxprxy.dll 6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850) ActiveX Interface Marshaling Library [71C50000] C:\Windows\System32\StructuredQuery.dll 7.0.7601.17514 - 7.00.7601.17514 (win7sp1_rtm.101119-1850) Structured Query [71CB0000] C:\Program Files (x86)\Common Files\microsoft shared\ink\tiptsf.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Tablet PC Input Panel Text Services Framework [722A0000] C:\Windows\SysWOW64\fdproxy.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Function Discovery Proxy Dll [722B0000] C:\Windows\System32\npmproxy.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Network List Manager Proxy [72380000] C:\Windows\SysWOW64\thumbcache.dll 6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255) Microsoft Thumbnail Cache [72480000] C:\Windows\system32\RICHED20.DLL 5.31.23.1230 - 5.31.23.1230 Rich Text Edit Control, v3.1 [72500000] C:\Windows\system32\msimg32.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) GDIEXT Client DLL [72810000] C:\Windows\system32\dtsh.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Detection and Sharing Status API [729F0000] C:\Windows\system32\FirewallAPI.dll 6.1.7600.16385 - 6.1.7601.17514 (win7sp1_rtm.101119-1850) Windows Firewall API [72AB0000] C:\Windows\system32\SXS.DLL 6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255) Fusion 2.5 [72B20000] C:\Windows\system32\NTDSAPI.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Active Directory Domain Services API [72B40000] C:\Windows\system32\wbem\fastprox.dll 6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850) WMI Custom Marshaller [72D20000] C:\Windows\system32\wbem\wbemsvc.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) WMI [73070000] C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll 6.10.7601.17514 - 6.10 (win7_rtm.090713-1255) User Experience Controls Library [73470000] C:\Windows\system32\NetworkItemFactory.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) NetworkItem Factory [73630000] C:\Windows\System32\Secur32.dll 6.1.7601.17856 - 6.1.7601.17856 (win7sp1_gdr.120601-1505) Security Support Provider Interface [73640000] C:\Windows\system32\dwmapi.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Microsoft Desktop Window Manager API [73660000] C:\Windows\system32\sfc_os.DLL 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Windows File Protection [73670000] C:\Windows\system32\sfc.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Windows File Protection [736B0000] C:\Windows\system32\uxtheme.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Microsoft UxTheme Library [73950000] C:\Windows\system32\Userenv.dll 6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255) Userenv [73AA0000] C:\Windows\system32\WINSTA.dll 6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850) Winstation Library [73B30000] C:\Windows\System32\wship6.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Winsock2 Helper DLL (TL/IPv6) [73B70000] C:\Windows\system32\RpcRtRemote.dll 6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850) Remote RPC Extension [73B80000] C:\Windows\system32\rsaenh.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Microsoft Enhanced Cryptographic Provider [73BC0000] C:\Windows\system32\CRYPTSP.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Cryptographic Service Provider API [73BE0000] C:\Windows\system32\wbemcomn.dll 6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850) WMI [73C40000] C:\Windows\system32\wbem\wbemprox.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) WMI [73CF0000] C:\Windows\system32\PROPSYS.dll 7.0.7601.17514 - 7.00.7600.16385 (win7_rtm.090713-1255) Microsoft Property System [73E30000] C:\Windows\system32\oleacc.dll 7.0.0.0 - 7.0.0.0 (win7sp1_gdr.110826-1504) Active Accessibility Core Component [73E70000] C:\Windows\system32\winspool.drv 6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255) Windows Spooler Driver [73ED0000] C:\Windows\system32\wtsapi32.dll 6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850) Windows Remote Desktop Session Host Server SDK APIs [73EE0000] C:\Windows\system32\mpr.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Multiple Provider Router DLL [73F00000] C:\Windows\system32\winmm.dll 6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255) MCI API DLL [73F40000] C:\Windows\system32\cscapi.dll 6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850) Offline Files Win32 API [73F50000] C:\Windows\system32\rasadhlp.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Remote Access AutoDial Helper [73F60000] C:\Windows\System32\fwpuclnt.dll 6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255) FWP/IPsec User-Mode API [73FA0000] C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57\MSVCR90.dll 9.0.30729.6161 - 9.00.30729.6161 Microsoft? C Runtime Library [740E0000] C:\Windows\system32\ntmarta.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Windows NT MARTA provider [74370000] C:\Windows\system32\version.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Version Checking and File Installation Libraries [743C0000] C:\Windows\System32\nlaapi.dll 6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850) Network Location Awareness 2 [743D0000] C:\Windows\system32\wkscli.dll 6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850) Workstation Service Client DLL [743E0000] C:\Windows\system32\srvcli.dll 6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850) Server Service Client DLL [74400000] C:\Windows\system32\netutils.dll 6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850) Net Win32 API Helpers DLL [74410000] C:\Windows\system32\MSWSOCK.dll 6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255) Microsoft Windows Sockets 2.0 Service Provider [74450000] C:\Windows\system32\profapi.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) User Profile Basic API [744F0000] C:\Windows\system32\DNSAPI.dll 6.1.7601.17570 - 6.1.7600.16385 (win7_rtm.090713-1255) DNS Client API DLL [748E0000] C:\Windows\system32\WSOCK32.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Windows Socket 32-Bit DLL [749F0000] C:\Windows\system32\NETAPI32.DLL 6.1.7601.17887 - 6.1.7601.17887 (win7sp1_gdr.120704-0720) Net Win32 API DLL [74A10000] C:\Windows\System32\wshtcpip.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Winsock2 Helper DLL (TL/IPv4) [74A80000] C:\Windows\system32\apphelp.dll 6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255) Application Compatibility Client Library [74AD0000] C:\Windows\system32\WINNSI.DLL 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Network Store Information RPC interface [74AE0000] C:\Windows\system32\IPHLPAPI.DLL 6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255) IP Helper API [74CB0000] C:\Windows\syswow64\CRYPTBASE.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Base cryptographic API DLL [74CC0000] C:\Windows\syswow64\SspiCli.dll 6.1.7601.17856 - 6.1.7601.17856 (win7sp1_gdr.120601-1505) Security Support Provider Interface [74D20000] C:\Windows\syswow64\msvcrt.dll 7.0.7601.17744 - 7.0.7601.17744 (win7sp1_gdr.111215-1535) Windows NT CRT DLL [74DD0000] C:\Windows\syswow64\RPCRT4.dll 6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255) Remote Procedure Call Runtime [74EC0000] C:\Windows\syswow64\DEVOBJ.dll 6.1.7601.17621 - 6.1.7601.17621 (win7sp1_gdr.110523-2108) Device Information Set DLL [74F10000] C:\Windows\syswow64\ole32.dll 6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255) Microsoft OLE for Windows [75070000] C:\Windows\system32\IMM32.DLL 6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850) Multi-User Windows IMM32 API Client DLL [75160000] C:\Windows\syswow64\LPK.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Language Pack [75170000] C:\Windows\syswow64\WLDAP32.dll 6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255) Win32 LDAP API DLL [751C0000] C:\Windows\syswow64\PSAPI.DLL 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Process Status Helper [751D0000] C:\Windows\syswow64\USER32.dll 6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850) Multi-User Windows USER API Client DLL [752D0000] C:\Windows\syswow64\WINTRUST.dll 6.1.7601.17787 - 6.1.7601.17787 (win7sp1_gdr.120229-1502) Microsoft Trust Verification APIs [75300000] C:\Windows\syswow64\GDI32.dll 6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850) GDI Client DLL [753F0000] C:\Windows\syswow64\CFGMGR32.dll 6.1.7601.17621 - 6.1.7601.17621 (win7sp1_gdr.110523-2108) Configuration Manager DLL [75420000] C:\Windows\syswow64\CLBCatQ.DLL 2001.12.8530.16385 - 2001.12.8530.16385 (win7_rtm.090713-1255) COM+ Configuration Catalog [754B0000] C:\Windows\SysWOW64\sechost.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) Host for SCM/SDDL/LSA Lookup APIs [754D0000] C:\Windows\syswow64\oleaut32.dll 6.1.7601.17676 - 6.1.7601.17676 [75560000] C:\Windows\syswow64\kernel32.dll 6.1.7601.17651 - 6.1.7600.16385 (win7_rtm.090713-1255) Windows NT BASE API Client DLL [75670000] C:\Windows\syswow64\NSI.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) NSI User-mode interface DLL [75680000] C:\Windows\syswow64\SHLWAPI.dll 6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255) Shell Light-weight Utility Library [756E0000] C:\Windows\syswow64\SETUPAPI.dll 6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255) Windows Setup API [75880000] C:\Windows\syswow64\CRYPT32.dll 6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255) Crypto API32 [759A0000] C:\Windows\syswow64\wininet.dll 8.0.7601.17874 - 8.00.7600.16385 (win7_rtm.090713-1255) Internet Extensions for Win32 [75AA0000] C:\Windows\syswow64\urlmon.dll 8.0.7601.17874 - 8.00.7600.16385 (win7_rtm.090713-1255) OLE32 Extensions for Win32 [75BE0000] C:\Windows\syswow64\WS2_32.dll 6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255) Windows Socket 2.0 32-Bit DLL [75C20000] C:\Windows\syswow64\comdlg32.dll 6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255) Common Dialogs DLL [75CA0000] C:\Windows\syswow64\KERNELBASE.dll 6.1.7601.17651 - 6.1.7600.16385 (win7_rtm.090713-1255) Windows NT BASE API Client DLL [75CF0000] C:\Windows\syswow64\USP10.dll 1.626.7601.17514 - 1.0626.7601.17514 (win7sp1_rtm.101119-1850) Uniscribe Unicode script processor [75DA0000] C:\Windows\syswow64\shell32.dll 6.1.7601.17859 - 6.1.7601.17514 (win7sp1_rtm.101119-1850) Windows Shell Common Dll [769F0000] C:\Windows\syswow64\iertutil.dll 8.0.7601.17874 - 8.00.7601.17874 (win7sp1_gdr.120626-1620) Run time utility for Internet Explorer [76BF0000] C:\Windows\syswow64\MSCTF.dll 6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255) MSCTF Server DLL [76CC0000] C:\Windows\syswow64\ADVAPI32.dll 6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255) Advanced Windows 32 Base API [77130000] C:\Windows\syswow64\MSASN1.dll 6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850) ASN.1 Runtime APIs [77160000] C:\Windows\SysWOW64\ntdll.dll 6.1.7601.17725 - 6.1.7600.16385 (win7_rtm.090713-1255) NT Layer DLL ------------------------------------------------------------------------------ Active Controls hierarchy: TPyIDEMainForm "PyIDEMainForm" ------------------------------------------------------------------------------ ---------- components: Regular Expressions messages: 170429 nosy: ezio.melotti, mrabarnett, nicolincioroianu priority: normal severity: normal status: open title: Assertion failure (C:\Delphi\progs32\Python\PythonIDE\cPyRemoteDebugger.pas, line 1175). type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 13:12:42 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 13 Sep 2012 11:12:42 +0000 Subject: [issue15938] expose way to count examples in doctest.DocFileSuite() Message-ID: <1347534762.13.0.990789726192.issue15938@psf.upfronthosting.co.za> New submission from Chris Jerdonek: This issue is to add to the doctest module an easy way to obtain the number of doctest examples in a unittest.TestSuite instance returned by a call to the doctest.DocFileSuite() function. The unittest.TestSuite class currently exposes a countTestCases() method that gives the number of TestCase instances inside a test suite. However, this method isn't useful for determining how many doctest examples that the TestSuite instance returned by a call to DocFileSuite() contains, nor in particular whether the instance contains any actual tests. Calling countTestCases() on the return value returns the number of files that were parsed and not the number of doctest examples. In fact, getting the number of doctest examples contained in such a TestSuite is surprisingly obscure and seems to rely on implementation details and accessing private attributes. Here is one way to do it (annotated with comments): paths = ['Doc/howto/ipaddress.rst', 'Doc/howto/unicode.rst'] # The return value of DocFileSuite is a unittest.TestCase instance, and # each item in the return value is a doctest.DocFileCase instance (which # in turn is also a doctest.DocTestCase and unittest.TestCase instance). suite = doctest.DocFileSuite(*paths, module_relative=False) total = 0 for case in suite: doc_test = case._dt_test # a doctest.DocTest instance. total += len(doc_test.examples) print("total test cases: %s" % suite.countTestCases()) print("total examples: %s" % total) Ideally, you would just be able to do something like this instead: suite.countExamples() Exposing a method like that would probably involve converting DocFileSuite from a simple function that returns a unittest.TestSuite into a class that subclasses unittest.TestSuite (so that the function becomes a constructor). ---------- components: Library (Lib) messages: 170430 nosy: cjerdonek priority: normal severity: normal status: open title: expose way to count examples in doctest.DocFileSuite() type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 13:29:57 2012 From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=) Date: Thu, 13 Sep 2012 11:29:57 +0000 Subject: [issue13990] Benchmarks: 2to3 failures on the py3 side In-Reply-To: <1328895154.39.0.105937484663.issue13990@psf.upfronthosting.co.za> Message-ID: <1347535797.14.0.143937077682.issue13990@psf.upfronthosting.co.za> Francisco Mart?n Brugu? added the comment: Just info: I still can reproduce that. (It's maybe just something wrong with my setup?) ---------- Added file: http://bugs.python.org/file27183/testsResult.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 13:33:29 2012 From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=) Date: Thu, 13 Sep 2012 11:33:29 +0000 Subject: [issue13990] Benchmarks: 2to3 failures on the py3 side In-Reply-To: <1328895154.39.0.105937484663.issue13990@psf.upfronthosting.co.za> Message-ID: <1347536009.37.0.813512627121.issue13990@psf.upfronthosting.co.za> Francisco Mart?n Brugu? added the comment: The actual tip for me is: ci at random:~/Prog/cpython/benchmarks/py2$ hg tip changeset: 164:61768f86170c tag: tip user: Brett Cannon date: Fri Aug 31 18:58:24 2012 -0400 summary: Allow for the specification of a base directory for either interpreter ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 14:28:37 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 13 Sep 2012 12:28:37 +0000 Subject: [issue15937] Assertion failure (C:\Delphi\progs32\Python\PythonIDE\cPyRemoteDebugger.pas, line 1175). In-Reply-To: <1347526491.38.0.848154883344.issue15937@psf.upfronthosting.co.za> Message-ID: <1347539317.13.0.912783100544.issue15937@psf.upfronthosting.co.za> R. David Murray added the comment: That isn't a valid Python program, and you appear to be reporting a bug in a third party tool. You should report your problem to the appropriate community for your IDE tool. ---------- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 14:40:10 2012 From: report at bugs.python.org (Brett Cannon) Date: Thu, 13 Sep 2012 12:40:10 +0000 Subject: [issue13990] Benchmarks: 2to3 failures on the py3 side In-Reply-To: <1328895154.39.0.105937484663.issue13990@psf.upfronthosting.co.za> Message-ID: <1347540010.06.0.0474287881084.issue13990@psf.upfronthosting.co.za> Brett Cannon added the comment: Can you copy-and-paste the exact commands you are using to build and run the benchmarks (along with version info for the interpreter used to do the building) as I'm on the same revision and can't reproduce anymore? $ mkdir benchmarks_py3k $ cd benchmarks_py3k/ $ $ /usr/bin/python2.6 -V Python 2.6.5 $ PYTHON=/usr/bin/python2.6 ../benchmarks/make_perf3.sh ../benchmarks # ... 2to3 output $ python3 -V Python 3.2.3 $ python3 perf.py -f -b 2to3 `which python3` `which python3` Running 2to3... INFO:root:Running /usr/bin/python3 lib/2to3/2to3 -f all lib/2to3/lib2to3/refactor.py INFO:root:Running `['/usr/bin/python3', 'lib/2to3/2to3', '-f', 'all', 'lib/2to3/lib2to3/refactor.py']` 1 time INFO:root:Running /usr/bin/python3 lib/2to3/2to3 -f all lib/2to3/lib2to3/refactor.py INFO:root:Running `['/usr/bin/python3', 'lib/2to3/2to3', '-f', 'all', 'lib/2to3/lib2to3/refactor.py']` 1 time Report on Linux importthis.wat.corp.google.com 3.2.5-gg944 #1 SMP Thu Aug 2 02:35:13 PDT 2012 x86_64 x86_64 Total CPU cores: 12 ### 2to3 ### 0.540000 -> 0.560000: 1.04x slower ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 14:40:40 2012 From: report at bugs.python.org (Cioroianu Nicolin) Date: Thu, 13 Sep 2012 12:40:40 +0000 Subject: [issue15937] Assertion failure (C:\Delphi\progs32\Python\PythonIDE\cPyRemoteDebugger.pas, line 1175). In-Reply-To: <1347539317.13.0.912783100544.issue15937@psf.upfronthosting.co.za> Message-ID: <1347540038.82508.YahooMailNeo@web161302.mail.bf1.yahoo.com> Cioroianu Nicolin added the comment: Hello David, I'm beginner with this tool, also a beginner programmer. I submitted the problem to IDE tool PyScripter. Just wanted to help Python improvement. I'm looking to improve also my experience. Have a nice day!:) Regards,? Nicolin ________________________________ From: R. David Murray To: nicolincioroianu at yahoo.com Sent: Thursday, September 13, 2012 2:28 PM Subject: [issue15937] Assertion failure (C:\Delphi\progs32\Python\PythonIDE\cPyRemoteDebugger.pas, line 1175). R. David Murray added the comment: That isn't a valid Python program, and you appear to be reporting a bug in a third party tool.? You should report your problem to the appropriate community for your IDE tool. ---------- nosy: +r.david.murray resolution:? -> invalid stage:? -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 14:43:32 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 13 Sep 2012 12:43:32 +0000 Subject: [issue15937] Assertion failure (C:\Delphi\progs32\Python\PythonIDE\cPyRemoteDebugger.pas, line 1175). In-Reply-To: <1347526491.38.0.848154883344.issue15937@psf.upfronthosting.co.za> Message-ID: <1347540212.86.0.131233347891.issue15937@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for wanting to help. If the PyScripter folks trace it back to a problem with Python, please feel free to reopen this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 14:58:13 2012 From: report at bugs.python.org (Cioroianu Nicolin) Date: Thu, 13 Sep 2012 12:58:13 +0000 Subject: [issue15937] Assertion failure (C:\Delphi\progs32\Python\PythonIDE\cPyRemoteDebugger.pas, line 1175). In-Reply-To: <1347540212.86.0.131233347891.issue15937@psf.upfronthosting.co.za> Message-ID: <1347541091.31685.YahooMailNeo@web161301.mail.bf1.yahoo.com> Cioroianu Nicolin added the comment: Hello David, PyScripter Answer: Thanks for the bug report. This?assertion?happens when PyScripter is waiting for the remote engine to?shut-down?for a long time without success. ?This might mean that either the system is very busy or more likely something is preventing the remote engine from shutting?down, such as waiting in a blocked state. ?What you can do in such cases is to use the task manager to kill the engine (appears as a process "python.exe") and then reinitialize the remote engine. Regards? Kiriakos PS ?Maybe the problem happens with the statement: m= "IT_SetBusParameters(param1,param2,param3,param4,param5,param6)"?? I think that can't be a problem with the upper line with that assignation. Regards, Nicolin ________________________________ From: R. David Murray To: nicolincioroianu at yahoo.com Sent: Thursday, September 13, 2012 2:43 PM Subject: [issue15937] Assertion failure (C:\Delphi\progs32\Python\PythonIDE\cPyRemoteDebugger.pas, line 1175). R. David Murray added the comment: Thanks for wanting to help.? If the PyScripter folks trace it back to a problem with Python, please feel free to reopen this issue. ---------- _______________________________________ Python tracker _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 15:15:39 2012 From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=) Date: Thu, 13 Sep 2012 13:15:39 +0000 Subject: [issue13990] Benchmarks: 2to3 failures on the py3 side In-Reply-To: <1328895154.39.0.105937484663.issue13990@psf.upfronthosting.co.za> Message-ID: <1347542139.73.0.527978949493.issue13990@psf.upfronthosting.co.za> Francisco Mart?n Brugu? added the comment: The box is a debian (wheezy): ci at random:~/Prog/cpython/benchmarks/py2$ uname -a Linux random 3.2.0-3-amd64 #1 SMP Mon Jul 23 02:45:17 UTC 2012 x86_64 GNU/Linux The source repository dir: ci at random:~/Prog/cpython/benchmarks/py2$ dir lib LICENSE.txt make_perf3.sh performance perf.py perf.pyc README.txt test_perf.py Then: ci at random:~/Prog/cpython/benchmarks/py2$ cd .. ci at random:~/Prog/cpython/benchmarks$ mkdir benchmarks_py3k ci at random:~/Prog/cpython/benchmarks$ dir benchmarks_py3k py2 ci at random:~/Prog/cpython/benchmarks$ cd benchmarks_py3k/ ci at random:~/Prog/cpython/benchmarks/benchmarks_py3k$ ci at random:~/Prog/cpython/benchmarks/benchmarks_py3k$ /usr/bin/python2.6 -V Python 2.6.8 ci at random:~/Prog/cpython/benchmarks/benchmarks_py3k$ PYTHON=/usr/bin/python2.6 ../py2/make_perf3.sh ../py2 RefactoringTool: Skipping implicit fixer: buffer RefactoringTool: Skipping implicit fixer: idioms ... RefactoringTool: Warnings/messages while refactoring: RefactoringTool: ### In file lib/2to3/example.py ### RefactoringTool: Line 371: You should use a for loop here RefactoringTool: Line 372: You should use a for loop here RefactoringTool: Line 373: You should use a for loop here RefactoringTool: Line 374: You should use a for loop here RefactoringTool: Line 375: You should use a for loop here RefactoringTool: ### In file lib/2to3/example.py ### RefactoringTool: Line 393: You should use 'hasattr(foo, '__call__')' here. RefactoringTool: Line 394: You should use 'operator.contains(foo, bar)' here. RefactoringTool: Skipping implicit fixer: buffer ... RefactoringTool: lib/mako/test/templates/subdir/foo/modtest.html.py ci at random:~/Prog/cpython/benchmarks/benchmarks_py3k$ python3 -V Python 3.2.3 python3 perf.py -f -b 2to3 `which python3` `which python3` Running 2to3... INFO:root:Running /usr/bin/python3 lib/2to3/2to3 -f all lib/2to3/lib2to3/refactor.py INFO:root:Running `['/usr/bin/python3', 'lib/2to3/2to3', '-f', 'all', 'lib/2to3/lib2to3/refactor.py']` 1 time INFO:root:Running /usr/bin/python3 lib/2to3/2to3 -f all lib/2to3/lib2to3/refactor.py INFO:root:Running `['/usr/bin/python3', 'lib/2to3/2to3', '-f', 'all', 'lib/2to3/lib2to3/refactor.py']` 1 time Report on Linux random 3.2.0-3-amd64 #1 SMP Mon Jul 23 02:45:17 UTC 2012 x86_64 Total CPU cores: 4 ### 2to3 ### 0.616038 -> 0.624039: 1.01x slower And further: ci at random:~/Prog/cpython/benchmarks/benchmarks_py3k$ dir lib performance perf.py cd lib/2to3 ci at random:~/Prog/cpython/benchmarks/benchmarks_py3k/lib/2to3$ dir 2to3 example.py HACKING lib2to3 README scripts test.py ci at random:~/Prog/cpython/benchmarks/benchmarks_py3k/lib/2to3$ python3 test.py 2> testsResult2.txt ---------- Added file: http://bugs.python.org/file27184/testsResult2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 15:41:38 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 13 Sep 2012 13:41:38 +0000 Subject: [issue15939] make *.rst files in Doc/ parseable by doctest Message-ID: <1347543698.43.0.179468389771.issue15939@psf.upfronthosting.co.za> New submission from Chris Jerdonek: Currently, when trying to parse the *.rst files in the Doc/ folder (i.e. not actually running them but simply generating unittest.TestCase instances from them by passing them to doctest.DocFileSuite()), five files yield errors. This issue is to make it so that all of the *.rst files in our Doc/ folder are at least parseable by doctest without error. I will submit a patch. Below are the errors that currently occur: (1) test fdoc:library/ctypes.rst crashed -- Traceback (most recent call last): ... ValueError: line 55 of the doctest for ctypes.rst has an invalid option: '+WINDOWS' (2) test fdoc:library/doctest.rst crashed -- Traceback (most recent call last): ... ValueError: line 1592 of the docstring for doctest.rst has inconsistent leading whitespace: ' """))' (3) test fdoc:library/multiprocessing.rst crashed -- Traceback (most recent call last): ... ValueError: line 1016 of the docstring for multiprocessing.rst lacks blank after >>>: '>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>' (4) test fdoc:whatsnew/2.4.rst crashed -- Traceback (most recent call last): ... ValueError: line 1422 of the docstring for 2.4.rst lacks blank after >>>: ' >>>"""' (5) test fdoc:whatsnew/2.7.rst crashed -- Traceback (most recent call last): ... ValueError: line 1531 of the docstring for 2.7.rst lacks blank after .: ' ...' ---------- assignee: docs at python components: Documentation messages: 170441 nosy: cjerdonek, docs at python priority: normal severity: normal status: open title: make *.rst files in Doc/ parseable by doctest versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 15:48:14 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 13 Sep 2012 13:48:14 +0000 Subject: [issue15938] expose way to count examples in doctest.DocFileSuite() In-Reply-To: <1347534762.13.0.990789726192.issue15938@psf.upfronthosting.co.za> Message-ID: <1347544094.06.0.685487781992.issue15938@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > # The return value of DocFileSuite is a unittest.TestCase instance, and s/unittest.TestCase/unittest.TestSuite/ (as elsewhere in the comment) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 15:53:01 2012 From: report at bugs.python.org (Brett Cannon) Date: Thu, 13 Sep 2012 13:53:01 +0000 Subject: [issue13990] Benchmarks: 2to3 failures on the py3 side In-Reply-To: <1328895154.39.0.105937484663.issue13990@psf.upfronthosting.co.za> Message-ID: <1347544381.65.0.641785832704.issue13990@psf.upfronthosting.co.za> Brett Cannon added the comment: So the tests failed but the benchmarks finished without issue? I'm not too worried about the tests since they are almost all str/bytes interaction issues (although I don't get the .decode() failure). If the benchmarks run without errors then I'm satisfied, else we figure out what this fails ever or we have a already translated copy kept in a lib3 directory to prevent problems. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 15:53:51 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 13 Sep 2012 13:53:51 +0000 Subject: [issue15939] make *.rst files in Doc/ parseable by doctest In-Reply-To: <1347543698.43.0.179468389771.issue15939@psf.upfronthosting.co.za> Message-ID: <1347544431.6.0.19277446377.issue15939@psf.upfronthosting.co.za> Chris Jerdonek added the comment: The attached patch addresses all but Doc/library/ctypes.rst. See the following python-dev e-mail for a question about how best to handle that case: http://mail.python.org/pipermail/python-dev/2012-September/121721.html ---------- keywords: +patch Added file: http://bugs.python.org/file27185/issue-15935-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 17:10:03 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 13 Sep 2012 15:10:03 +0000 Subject: [issue15939] make *.rst files in Doc/ parseable by doctest In-Reply-To: <1347543698.43.0.179468389771.issue15939@psf.upfronthosting.co.za> Message-ID: <1347549003.72.0.456514577303.issue15939@psf.upfronthosting.co.za> Changes by Chris Jerdonek : Removed file: http://bugs.python.org/file27185/issue-15935-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 17:10:24 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 13 Sep 2012 15:10:24 +0000 Subject: [issue15939] make *.rst files in Doc/ parseable by doctest In-Reply-To: <1347543698.43.0.179468389771.issue15939@psf.upfronthosting.co.za> Message-ID: <1347549024.98.0.936301790287.issue15939@psf.upfronthosting.co.za> Changes by Chris Jerdonek : Added file: http://bugs.python.org/file27186/issue-15939-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 18:23:41 2012 From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=) Date: Thu, 13 Sep 2012 16:23:41 +0000 Subject: [issue13990] Benchmarks: 2to3 failures on the py3 side In-Reply-To: <1347544381.65.0.641785832704.issue13990@psf.upfronthosting.co.za> Message-ID: <505208D6.70809@email.de> Francisco Mart?n Brugu? added the comment: > So the tests failed but the benchmarks finished without issue? Yes. But the apparent diff is that I've used 2.6.8 If the benchmarks run without errors then I'm satisfied, else we figure out what this fails ever or we have a already translated copy kept in a lib3 directory to prevent problems. The actual trunk revision for 2to3 from: https://svn.python.org/projects/sandbox/trunk/2to3/ is Revision 88981: /sandbox/trunk/2to3 the README.txt says: 2to3: r72994 from http://svn.python.org/projects/sandbox/trunk/2to3 I've just updated to that version but nothing changed: same errors (and a new test test_formfeed (lib2to3.tests.test_parser.TestDriver) that was ok) cheers, francis ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 18:28:18 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 13 Sep 2012 16:28:18 +0000 Subject: [issue15881] multiprocessing 'NoneType' object is not callable In-Reply-To: <1347044200.13.0.235512745295.issue15881@psf.upfronthosting.co.za> Message-ID: <3XHlf92YJgzQkH@mail.python.org> Roundup Robot added the comment: New changeset 2b79b4848f44 by Richard Oudkerk in branch 'default': Issue #15881: Clarify comment in exit function http://hg.python.org/cpython/rev/2b79b4848f44 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 18:58:26 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 13 Sep 2012 16:58:26 +0000 Subject: [issue15629] Add to regrtest the ability to run Lib and Doc doctests In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1347555506.62.0.0226280736311.issue15629@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attached is a file of doctest statistics (counts of example failures, exceptions, and successes) for almost every file in the Doc directory when running the doctests with vanilla doctest. I did this to get a sense of which files it would be easiest to get into a "passing" state, and to see how many files actually have doctest examples. It was actually non-trivial to get fine-grained test result data like this because doctest only exposes the ability to create a unittest.TestCase for each file (i.e. an entire file either registers as a success or failure). >From the API, you can't get results down to the level of individual doctest examples. See also issue 15938 that I recently created which would be a small step in this direction (getting a total example count independent of successes and failures). ---------- Added file: http://bugs.python.org/file27187/doctest-stats-1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 20:03:47 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 13 Sep 2012 18:03:47 +0000 Subject: [issue15940] Time module: effect of locale Message-ID: <1347559427.35.0.589419592153.issue15940@psf.upfronthosting.co.za> New submission from Terry J. Reedy: "Module locale Internationalization services. The locale settings can affect the return values for some of the functions in the time module." This is vague and perhaps misleading. The doc also says "Locale information is not used by asctime()." "Locale information is not used by ctime()." Since ctime() = asctime(localtime()), this implies to me that locale is also not used by localtime. Otherwise, locale information would indirectly be used by ctime. (I did not test this directly because I do not know what a legal locale name is on Windows. The doc example 'de_DE' does not work.) Doc also says "time.strftime(format[, t]) %a Locale?s abbreviated weekday name. ... " So perhaps the doc should say "The locale setting affects the interpretation of many format specifiers in strftime and strptime". If is does anything else, what? ---------- assignee: docs at python components: Documentation messages: 170448 nosy: belopolsky, docs at python, haypo, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Time module: effect of locale versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 20:07:05 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Thu, 13 Sep 2012 18:07:05 +0000 Subject: [issue15222] mailbox.mbox writes without empty line after each message In-Reply-To: <1340948825.65.0.977158180544.issue15222@psf.upfronthosting.co.za> Message-ID: <1347559625.86.0.799782991788.issue15222@psf.upfronthosting.co.za> Petri Lehtinen added the comment: Attached an updated version of the second patch. David: Is this what you meant? Also, the patch format should now be rietveld compatible :) ---------- Added file: http://bugs.python.org/file27188/issue15222_v2_0002_insert_blank_after_each_message_in_mbox.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 20:07:21 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 13 Sep 2012 18:07:21 +0000 Subject: [issue15941] Time module: effect of time.timezone change Message-ID: <1347559641.51.0.772200483389.issue15941@psf.upfronthosting.co.za> New submission from Terry J. Reedy: "time.timezone The offset of the local (non-DST) timezone, in seconds west of UTC (negative in most of Western Europe, positive in the US, zero in the UK)." Quite aside from #9305 (UTC is not a place), this does not specify the effect of setting this attribute. It does not change the output of localtime, asctime, or ctime (on Windows). Does is affect anything else? strftime? If setting it has no effect, the doc should say so. (And then perhaps it should be made read-only in the future, as setting it expecting an effect would be a bug.) ---------- assignee: docs at python components: Documentation messages: 170450 nosy: belopolsky, docs at python, haypo, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Time module: effect of time.timezone change versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 20:07:47 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Thu, 13 Sep 2012 18:07:47 +0000 Subject: [issue15222] mailbox.mbox writes without empty line after each message In-Reply-To: <1340948825.65.0.977158180544.issue15222@psf.upfronthosting.co.za> Message-ID: <1347559667.57.0.133096807287.issue15222@psf.upfronthosting.co.za> Changes by Petri Lehtinen : Removed file: http://bugs.python.org/file27188/issue15222_v2_0002_insert_blank_after_each_message_in_mbox.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 20:07:58 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Thu, 13 Sep 2012 18:07:58 +0000 Subject: [issue15222] mailbox.mbox writes without empty line after each message In-Reply-To: <1340948825.65.0.977158180544.issue15222@psf.upfronthosting.co.za> Message-ID: <1347559678.17.0.334242280583.issue15222@psf.upfronthosting.co.za> Changes by Petri Lehtinen : Added file: http://bugs.python.org/file27189/issue15222_v2_0002_insert_blank_after_each_message_in_mbox.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 20:26:29 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 13 Sep 2012 18:26:29 +0000 Subject: [issue15222] mailbox.mbox writes without empty line after each message In-Reply-To: <1340948825.65.0.977158180544.issue15222@psf.upfronthosting.co.za> Message-ID: <1347560789.17.0.499396530618.issue15222@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, that looks better. I haven't worked through the rest of the logic in detail, I'll trust your months of cogitation and the tests on that part. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 20:32:29 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 13 Sep 2012 18:32:29 +0000 Subject: [issue15940] Time module: effect of locale In-Reply-To: <1347559427.35.0.589419592153.issue15940@psf.upfronthosting.co.za> Message-ID: <1347561149.11.0.494155701848.issue15940@psf.upfronthosting.co.za> R. David Murray added the comment: Since localtime() returns numbers, it is trivially true that localtime is not affected by locale. Your more specific phrasing is correct, I think. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 21:00:08 2012 From: report at bugs.python.org (Julian Berman) Date: Thu, 13 Sep 2012 19:00:08 +0000 Subject: [issue9253] argparse: optional subparsers In-Reply-To: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za> Message-ID: <1347562808.55.0.0249068462588.issue9253@psf.upfronthosting.co.za> Changes by Julian Berman : ---------- nosy: +Julian _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 21:02:47 2012 From: report at bugs.python.org (Garrett Cooper) Date: Thu, 13 Sep 2012 19:02:47 +0000 Subject: [issue15942] Time representation for Windows incorrect when BIOS clock set to localtime when calling time.localtime() Message-ID: <1347562967.67.0.94049562536.issue15942@psf.upfronthosting.co.za> New submission from Garrett Cooper: Windows doesn't return sane values for localtime(3) (per POSIX [1]) when the BIOS is set to the local time (the host is a Win2k8-R2 machine): $ python -V; python -c 'import time; print time.strftime("%m-%d-%y %H:%M:%S", time.localtime())'; date; uname -a Python 2.6.1 09-13-12 19:56:03 Thu, Sep 13, 2012 11:56:03 AM CYGWIN_NT-6.1-WOW64 QAQA-ORPTO8B466 1.7.11(0.260/5/3) 2012-02-24 14:05 i686 Cygwin This seems to be a conscious design choice on Microsoft's part: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724961%28v=vs.85%29.aspx I'll try and follow this up with the POSIX folks or maybe Microsoft, but for the time being this needs to be documentation as an issue with downstream consumers (perl 5.8.9 also illustrates this issue). ---------- components: Library (Lib) messages: 170453 nosy: yaneurabeya priority: normal severity: normal status: open title: Time representation for Windows incorrect when BIOS clock set to localtime when calling time.localtime() type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 21:25:30 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 13 Sep 2012 19:25:30 +0000 Subject: [issue9253] argparse: optional subparsers In-Reply-To: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za> Message-ID: <1347564330.41.0.706301167111.issue9253@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: needs patch -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 22:15:48 2012 From: report at bugs.python.org (Garrett Cooper) Date: Thu, 13 Sep 2012 20:15:48 +0000 Subject: [issue15942] Time representation for Windows incorrect when BIOS clock set to localtime when calling time.localtime() In-Reply-To: <1347562967.67.0.94049562536.issue15942@psf.upfronthosting.co.za> Message-ID: <1347567348.04.0.388612040481.issue15942@psf.upfronthosting.co.za> Garrett Cooper added the comment: 1. http://pubs.opengroup.org/onlinepubs/009695299/functions/localtime.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 23:14:57 2012 From: report at bugs.python.org (Anthony Kong) Date: Thu, 13 Sep 2012 21:14:57 +0000 Subject: [issue4188] test_threading hang when running as verbose In-Reply-To: <1224793703.28.0.169476277835.issue4188@psf.upfronthosting.co.za> Message-ID: <1347570897.52.0.0307020830144.issue4188@psf.upfronthosting.co.za> Changes by Anthony Kong : ---------- nosy: +Anthony.Kong _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 23:21:44 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 13 Sep 2012 21:21:44 +0000 Subject: [issue15942] Time representation for Windows incorrect when BIOS clock set to localtime when calling time.localtime() In-Reply-To: <1347562967.67.0.94049562536.issue15942@psf.upfronthosting.co.za> Message-ID: <1347571304.53.0.114613606999.issue15942@psf.upfronthosting.co.za> R. David Murray added the comment: It seems to me this is more likely a bug in cygwin and/or the cygwin Python port, since I find it hard to believe our windows users would be putting up with getting incorrect localtime results. ---------- nosy: +belopolsky, r.david.murray, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 23:37:53 2012 From: report at bugs.python.org (Garrett Cooper) Date: Thu, 13 Sep 2012 21:37:53 +0000 Subject: [issue15942] Time representation for Windows incorrect when BIOS clock set to localtime when calling time.localtime() In-Reply-To: <1347562967.67.0.94049562536.issue15942@psf.upfronthosting.co.za> Message-ID: <1347572273.68.0.678691248323.issue15942@psf.upfronthosting.co.za> Garrett Cooper added the comment: Except it wasn't built within the Cygwin environment... $ python -c 'import sys; print sys.version' 2.6.1 (r261:67515, Dec 5 2008, 13:58:38) [MSC v.1500 32 bit (Intel)] $ ldd `which python` | grep -i ygwin || echo "not cygwin" not cygwin ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 13 23:41:01 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 13 Sep 2012 21:41:01 +0000 Subject: [issue15942] Time representation for Windows incorrect when BIOS clock set to localtime when calling time.localtime() In-Reply-To: <1347562967.67.0.94049562536.issue15942@psf.upfronthosting.co.za> Message-ID: <1347572461.29.0.902832812223.issue15942@psf.upfronthosting.co.za> R. David Murray added the comment: Perhaps that is the problem then: running a non-cygwin python from a cygwin environment? I don't really know, which is why I added Terry to the nosy list...he's got more Windows experience, though maybe not cygwin experience. I myself no longer have access to a windows/cygwin box, though I may try setting one up again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 00:11:19 2012 From: report at bugs.python.org (Garrett Cooper) Date: Thu, 13 Sep 2012 22:11:19 +0000 Subject: [issue15942] Time representation for Windows incorrect when BIOS clock set to localtime when calling time.localtime() In-Reply-To: <1347562967.67.0.94049562536.issue15942@psf.upfronthosting.co.za> Message-ID: <1347574279.86.0.277163139356.issue15942@psf.upfronthosting.co.za> Garrett Cooper added the comment: Ok. Turns out I got this backwards. The BIOS clock is set to UTC (which works with the CentOS install on the same drive) and Windows assumes the clock is set to local time [1]. I'll follow it up with the my $work lab team, but it would be nice if this could be tuned properly to report the proper time according to Windows (even if the bloody clock/tz was wrong to begin with). 1. https://help.ubuntu.com/community/UbuntuTime ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 00:26:39 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 13 Sep 2012 22:26:39 +0000 Subject: [issue15942] Time representation for Windows incorrect when BIOS clock set to localtime when calling time.localtime() In-Reply-To: <1347562967.67.0.94049562536.issue15942@psf.upfronthosting.co.za> Message-ID: <1347575199.22.0.41631913541.issue15942@psf.upfronthosting.co.za> R. David Murray added the comment: I'm not sure it can be. Windows is screwed up in the way it handles time. Last I looked they still didn't support having the BIOS clock set to UTC (but is has been a while since I looked). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 00:32:53 2012 From: report at bugs.python.org (Garrett Cooper) Date: Thu, 13 Sep 2012 22:32:53 +0000 Subject: [issue15942] Time representation for Windows incorrect when BIOS clock set to localtime when calling time.localtime() In-Reply-To: <1347562967.67.0.94049562536.issue15942@psf.upfronthosting.co.za> Message-ID: <1347575573.6.0.488093867644.issue15942@psf.upfronthosting.co.za> Garrett Cooper added the comment: Hahaha... you're right: $ perl -e 'use POSIX; print strftime("%m-%d-%y %H:%M:%S", localtime)."\n";'; date 09-13-12 23:25:49 Thu, Sep 13, 2012 3:25:49 PM $ python -c 'import time; print time.strftime("%m-%d-%y %H:%M:%S", time.localtime())'; date 09-13-12 23:26:25 Thu, Sep 13, 2012 3:26:25 PM $ python -c 'import time; print time.strftime("%m-%d-%y %H:%M:%S", time.localtime())'; env TZ=utc date 09-13-12 23:27:35 Thu, Sep 13, 2012 10:27:35 PM Now I've just moved the dang clock ahead 8 hours because the timezone is screwed up (now python assumes UTC, Cygwin assumes local time, and Windows assumes UTC), I guess I'll have to recommend `fixing` our Linux installs to use local time (dog gone Windows). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 00:52:03 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 13 Sep 2012 22:52:03 +0000 Subject: [issue15942] Time representation for Windows incorrect when BIOS clock set to localtime when calling time.localtime() In-Reply-To: <1347562967.67.0.94049562536.issue15942@psf.upfronthosting.co.za> Message-ID: <1347576723.79.0.202155994873.issue15942@psf.upfronthosting.co.za> R. David Murray added the comment: OK, I'm going to close this, then. ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 00:59:52 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 13 Sep 2012 22:59:52 +0000 Subject: [issue15437] Merge Doc/ACKS.txt names into Misc/ACKS In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za> Message-ID: <3XHwKZ2596zQkd@mail.python.org> Roundup Robot added the comment: New changeset 48185b0f7b8a by Ezio Melotti in branch '3.2': #15437, #15439: merge Doc/ACKS.txt with Misc/ACKS and modify Doc/about.rst accordingly. http://hg.python.org/cpython/rev/48185b0f7b8a New changeset 2b4a89f82485 by Ezio Melotti in branch 'default': #15437, #15439: merge with 3.2. http://hg.python.org/cpython/rev/2b4a89f82485 New changeset 76dd082d332e by Ezio Melotti in branch '2.7': #15437, #15439: merge Doc/ACKS.txt with Misc/ACKS and modify Doc/about.rst accordingly. http://hg.python.org/cpython/rev/76dd082d332e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 00:59:52 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 13 Sep 2012 22:59:52 +0000 Subject: [issue15439] Include Misc/ACKS names into the documentation In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za> Message-ID: <3XHwKb0T1qzQjv@mail.python.org> Roundup Robot added the comment: New changeset 48185b0f7b8a by Ezio Melotti in branch '3.2': #15437, #15439: merge Doc/ACKS.txt with Misc/ACKS and modify Doc/about.rst accordingly. http://hg.python.org/cpython/rev/48185b0f7b8a New changeset 2b4a89f82485 by Ezio Melotti in branch 'default': #15437, #15439: merge with 3.2. http://hg.python.org/cpython/rev/2b4a89f82485 New changeset 76dd082d332e by Ezio Melotti in branch '2.7': #15437, #15439: merge Doc/ACKS.txt with Misc/ACKS and modify Doc/about.rst accordingly. http://hg.python.org/cpython/rev/76dd082d332e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 01:04:43 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 13 Sep 2012 23:04:43 +0000 Subject: [issue15942] Time representation for Windows incorrect when BIOS clock set to localtime when calling time.localtime() In-Reply-To: <1347562967.67.0.94049562536.issue15942@psf.upfronthosting.co.za> Message-ID: <1347577483.72.0.837742228096.issue15942@psf.upfronthosting.co.za> Terry J. Reedy added the comment: For future reference: 2.6 is no longer supported except for security issues The same will soon (a month?) be true of 3.2. Win2k is no longer supported in 3.3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 01:11:41 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 13 Sep 2012 23:11:41 +0000 Subject: [issue15437] Merge Doc/ACKS.txt names into Misc/ACKS In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za> Message-ID: <1347577901.44.0.0287868483358.issue15437@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the script! ---------- assignee: docs at python -> ezio.melotti resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 01:12:14 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 13 Sep 2012 23:12:14 +0000 Subject: [issue15439] Include Misc/ACKS names into the documentation In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za> Message-ID: <1347577934.25.0.588340568537.issue15439@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: docs at python -> ezio.melotti resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed type: -> enhancement versions: +Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 01:17:00 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 13 Sep 2012 23:17:00 +0000 Subject: [issue15437] Merge Doc/ACKS.txt names into Misc/ACKS In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za> Message-ID: <1347578220.75.0.438043444468.issue15437@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks for committing, Ezio! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 02:51:23 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 14 Sep 2012 00:51:23 +0000 Subject: [issue15941] Time module: effect of time.timezone change In-Reply-To: <1347559641.51.0.772200483389.issue15941@psf.upfronthosting.co.za> Message-ID: <1347583883.07.0.712199985255.issue15941@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Isn't this a duplicate of issue 8810? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 03:02:39 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 14 Sep 2012 01:02:39 +0000 Subject: [issue15941] Time module: effect of time.timezone change In-Reply-To: <1347559641.51.0.772200483389.issue15941@psf.upfronthosting.co.za> Message-ID: <1347584559.69.0.586430204713.issue15941@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I've read this more carefully and I now understand the issue. Indeed, setting time.timezone or time.altzone has no effect on say time.strftime('%z'). I think this should be documented and the doc should refer to time.tzset() for a proper way to change these variables. As for making them read only, I don't think there is a non-hackish way to make module globals read-only. I also believe that rather than improving these variables we should encourage people to use datetime module's new timezone features because at almost any location on Earth timezone offset is not a constant and varies over time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 04:00:37 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 14 Sep 2012 02:00:37 +0000 Subject: [issue15941] Time module: effect of time.timezone change In-Reply-To: <1347559641.51.0.772200483389.issue15941@psf.upfronthosting.co.za> Message-ID: <1347588037.03.0.680489739789.issue15941@psf.upfronthosting.co.za> Terry J. Reedy added the comment: #8810 and #9305 seem related, if not dups. You are right about module vars. They are all instances of one module class with one __setattr__. How about "Setting this attribute has no effect. See time.TZset or even better, the datetime module." (I had not noticed .altzone) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 04:48:24 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 14 Sep 2012 02:48:24 +0000 Subject: [issue15941] Time module: effect of time.timezone change In-Reply-To: <1347559641.51.0.772200483389.issue15941@psf.upfronthosting.co.za> Message-ID: <1347590904.67.0.455086375317.issue15941@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > Setting this attribute has no effect. Strictly speaking, setting this attribute has the effect of changing the value of this attribute. I cannot come up with a better wording at this hour, but I would say something about it being "informational" only. We should also mention that these attributes are set by time.tzset(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 06:00:54 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 14 Sep 2012 04:00:54 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <3XJ30w0RZ0zQhN@mail.python.org> Roundup Robot added the comment: New changeset b01eb870f84f by Ezio Melotti in branch '3.2': #15831: document multiple signatures on different lines. Patch by Chris Jerdonek. http://hg.python.org/cpython/rev/b01eb870f84f New changeset 0ed61ee823d8 by Ezio Melotti in branch 'default': #15831: merge with 3.2 http://hg.python.org/cpython/rev/0ed61ee823d8 New changeset 2291aff20a05 by Ezio Melotti in branch '2.7': #15831: document multiple signatures on different lines. Patch by Chris Jerdonek. http://hg.python.org/cpython/rev/2291aff20a05 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 06:04:05 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 14 Sep 2012 04:04:05 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1347595445.57.0.931962527437.issue15831@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! ---------- assignee: docs at python -> ezio.melotti resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 12:47:29 2012 From: report at bugs.python.org (Santiago Velasco) Date: Fri, 14 Sep 2012 10:47:29 +0000 Subject: [issue15943] urllib2 always sends header connection: close Message-ID: <1347619649.5.0.736297150545.issue15943@psf.upfronthosting.co.za> New submission from Santiago Velasco: I have noticed that urllib2 will always send the 'connection: close' in the headers, looking at the code there is no way to override this from outside of the open method. I am currently working with a server that kills connection upon reading the header, and content will not get served, or only a partial bit of the content gets served, I have tried with several other agents, all are able to download the full content served by the server. I created a modified version without the 'connection: close' header and that solved the problem for me. I do not always have problems with that header, but I would like the ability to define my own headers, and since the connection: close header gets slapped inside an objects internal method, there is currently no other way I can bypass it. ---------- components: Library (Lib) messages: 170473 nosy: sanxiago priority: normal severity: normal status: open title: urllib2 always sends header connection: close type: behavior versions: Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 15:16:25 2012 From: report at bugs.python.org (danblack) Date: Fri, 14 Sep 2012 13:16:25 +0000 Subject: [issue8109] Server-side support for TLS Server Name Indication extension In-Reply-To: <1268234047.5.0.702223567094.issue8109@psf.upfronthosting.co.za> Message-ID: <1347628585.92.0.152329641116.issue8109@psf.upfronthosting.co.za> danblack added the comment: > Daniel, your patch looks quite interesting. Please, send a contributor agreement to the PSF: http://www.python.org/psf/contrib/contrib-form-python/ . Let me know when you status have changed. Already done. Has been accepted and I've got an acknowledgement email. > Why are you changing "Lib/test/keycert2.pem"? I was mistakely assuming that this was the only test that used it. Fixed now. Also added a CA key and server for validating key chains. I didn't end up using it however thought it would be handy. > Please, provide also a documentation patch. Done. Also improved error checking and reference counting. > This is a feature enhancement. Would be applied to 3.4, it is too late for 3.3 :-(. Too bad! :( Was expected. Its been 2.5 years since the bug opened. A little more won't hurt. I've also changed SSLSocket.context to be a property. Its not quite working. The current test case as is working however using an assignment as per line 1958 of Lib/test/test_ssl.py. ---------- Added file: http://bugs.python.org/file27190/issue8109_server_side_sni.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 15:16:58 2012 From: report at bugs.python.org (danblack) Date: Fri, 14 Sep 2012 13:16:58 +0000 Subject: [issue8109] Server-side support for TLS Server Name Indication extension In-Reply-To: <1268234047.5.0.702223567094.issue8109@psf.upfronthosting.co.za> Message-ID: <1347628618.37.0.362900766108.issue8109@psf.upfronthosting.co.za> Changes by danblack : Removed file: http://bugs.python.org/file26950/issue8109_server_side_sni.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 15:26:21 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 14 Sep 2012 13:26:21 +0000 Subject: [issue15943] urllib2 always sends header connection: close In-Reply-To: <1347619649.5.0.736297150545.issue15943@psf.upfronthosting.co.za> Message-ID: <1347629181.38.0.844202550498.issue15943@psf.upfronthosting.co.za> R. David Murray added the comment: This is a duplicate of issue 12849. I'm not sure that we support keep-alive using urllib. We do using httplib, if I understand correctly. ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> urllib2 headers issue _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 15:28:57 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 14 Sep 2012 13:28:57 +0000 Subject: [issue12849] urllib2 headers issue In-Reply-To: <1314559168.55.0.630424901631.issue12849@psf.upfronthosting.co.za> Message-ID: <1347629337.65.0.352337157605.issue12849@psf.upfronthosting.co.za> R. David Murray added the comment: I've closed issue 15943 as a duplicate of this one. As I said there, I'm not sure that we (can?) support keep-alive in urllib, though we do in httplib (which is the http package in python3). ---------- nosy: +r.david.murray, sanxiago versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 15:29:47 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 14 Sep 2012 13:29:47 +0000 Subject: [issue12849] Cannot override 'connection: close' in urllib2 headers In-Reply-To: <1314559168.55.0.630424901631.issue12849@psf.upfronthosting.co.za> Message-ID: <1347629387.35.0.880970860045.issue12849@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- title: urllib2 headers issue -> Cannot override 'connection: close' in urllib2 headers _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 17:05:30 2012 From: report at bugs.python.org (David Beazley) Date: Fri, 14 Sep 2012 15:05:30 +0000 Subject: [issue15944] memoryviews and ctypes Message-ID: <1347635130.32.0.649142152247.issue15944@psf.upfronthosting.co.za> New submission from David Beazley: I've been playing with the interaction of ctypes and memoryviews and am curious about intended behavior. Consider the following: >>> import ctypes >>> d = ctypes.c_double() >>> m = memoryview(d) >>> m.ndim 0 >>> m.shape () >>> m.readonly False >>> m.itemsize 8 >>> As you can see, you have a memory view for the ctypes double object. However, the fact that it has a 0-dimension and no shape seems to cause all sorts of weird behavior. For instance, indexing and slicing don't work: >>> m[0] Traceback (most recent call last): File "", line 1, in TypeError: invalid indexing of 0-dim memory >>> m[:] Traceback (most recent call last): File "", line 1, in TypeError: invalid indexing of 0-dim memory >>> As such, you can't really seem to do anything interesting with the resulting memory view. For example, you can't pull data out of it. Nor can you overwrite the contents (i.e., replacing the contents with an 8-byte byte string). Attempting to cast the memory view to something else doesn't work either. >>> d = ctypes.c_double() >>> m = memoryview(d) >>> m2 = m.cast('c') Traceback (most recent call last): File "", line 1, in ValueError: memoryview: source format must be a native single character format prefixed with an optional '@' >>> I must be missing something really obvious here. Is there no way to get access to the memory behind a ctypes object? ---------- messages: 170477 nosy: dabeaz priority: normal severity: normal status: open title: memoryviews and ctypes type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 17:34:17 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 14 Sep 2012 15:34:17 +0000 Subject: [issue15842] Some SocketIO methods can succeed after close() In-Reply-To: <1346527213.21.0.243179396441.issue15842@psf.upfronthosting.co.za> Message-ID: <3XJLPN39Z2zLw8@mail.python.org> Roundup Robot added the comment: New changeset fad797916266 by Antoine Pitrou in branch '3.2': Issue #15842: the SocketIO.{readable,writable,seekable} methods now raise ValueError when the file-like object is closed. http://hg.python.org/cpython/rev/fad797916266 New changeset 3b0e20f71d8a by Antoine Pitrou in branch 'default': Issue #15842: the SocketIO.{readable,writable,seekable} methods now raise ValueError when the file-like object is closed. http://hg.python.org/cpython/rev/3b0e20f71d8a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 17:34:51 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 14 Sep 2012 15:34:51 +0000 Subject: [issue15842] Some SocketIO methods can succeed after close() In-Reply-To: <1346527213.21.0.243179396441.issue15842@psf.upfronthosting.co.za> Message-ID: <1347636891.41.0.160014994568.issue15842@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, I've committed the patch. Thanks Alessandro! ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 17:37:42 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 14 Sep 2012 15:37:42 +0000 Subject: [issue15944] memoryviews and ctypes In-Reply-To: <1347635130.32.0.649142152247.issue15944@psf.upfronthosting.co.za> Message-ID: <1347637062.17.0.919394373571.issue15944@psf.upfronthosting.co.za> Antoine Pitrou added the comment: You can still read the underlying representation: >>> d = ctypes.c_double(0.6) >>> m = memoryview(d) >>> bytes(m) b'333333\xe3?' >>> d.value = 0.7 >>> bytes(m) b'ffffff\xe6?' ---------- nosy: +pitrou, skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 17:43:06 2012 From: report at bugs.python.org (David Beazley) Date: Fri, 14 Sep 2012 15:43:06 +0000 Subject: [issue15944] memoryviews and ctypes In-Reply-To: <1347635130.32.0.649142152247.issue15944@psf.upfronthosting.co.za> Message-ID: <1347637386.79.0.464131186713.issue15944@psf.upfronthosting.co.za> David Beazley added the comment: I don't want to read the representation by copying it into a bytes object. I want direct access to the underlying memory--including the ability to modify it. As it stands now, it's completely useless. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 18:01:23 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 14 Sep 2012 16:01:23 +0000 Subject: [issue15944] memoryviews and ctypes In-Reply-To: <1347635130.32.0.649142152247.issue15944@psf.upfronthosting.co.za> Message-ID: <1347638483.64.0.949152972898.issue15944@psf.upfronthosting.co.za> Stefan Krah added the comment: 0-dim memory is indexed by x[()]. The ctypes example has an additional problem, because format=">> x = ndarray(3.14, shape=[], format='d', flags=ND_WRITABLE) >>> x[()] 3.14 >>> tau = 6.28 >>> x[()] = tau >>> x[()] 6.28 >>> m = memoryview(x) >>> m[()] 6.28 >>> m[()] = 100.111 >>> m[()] 100.111 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 18:08:09 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 14 Sep 2012 16:08:09 +0000 Subject: [issue15944] memoryviews and ctypes In-Reply-To: <1347635130.32.0.649142152247.issue15944@psf.upfronthosting.co.za> Message-ID: <1347638889.95.0.452176540848.issue15944@psf.upfronthosting.co.za> Stefan Krah added the comment: BTW, if c_double means "native machine double", then ctypes should fill in Py_buffer.format with "d" and not " _______________________________________ From report at bugs.python.org Fri Sep 14 18:19:37 2012 From: report at bugs.python.org (David Beazley) Date: Fri, 14 Sep 2012 16:19:37 +0000 Subject: [issue15944] memoryviews and ctypes In-Reply-To: <1347635130.32.0.649142152247.issue15944@psf.upfronthosting.co.za> Message-ID: <1347639577.63.0.484657410971.issue15944@psf.upfronthosting.co.za> David Beazley added the comment: Even with the _______________________________________ From report at bugs.python.org Fri Sep 14 18:21:27 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 14 Sep 2012 16:21:27 +0000 Subject: [issue15898] OSX TTY bug In-Reply-To: <1347238694.31.0.649838162085.issue15898@psf.upfronthosting.co.za> Message-ID: <1347639687.31.0.995688959458.issue15898@psf.upfronthosting.co.za> Changes by Ronald Oussoren : ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 18:32:36 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 14 Sep 2012 16:32:36 +0000 Subject: [issue15419] distutils: build should use a version-specific build directory In-Reply-To: <1342945976.47.0.537572255215.issue15419@psf.upfronthosting.co.za> Message-ID: <1347640356.29.0.399502868362.issue15419@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I'd change the name of the subdirectories of build instead of the name of the build directory itself. That way distutils will still create one build directory regardless of how many python versions you use, and the name of that directory is easily predicatble (which is nice when using basic tools to clean up a directory). The distribute/setuptools projects do this as well, and implementing this should only require a fairly trival patch to distutils.commands.build (the defaults for the various build_ directories need to be updated). BTW. How likely is the acceptance of such a patch? IIRC distutils is more or less closed for development w.r.t. new features. Would that also apply to this feature request? ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 18:41:12 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 14 Sep 2012 16:41:12 +0000 Subject: [issue15419] distutils: build should use a version-specific build directory In-Reply-To: <1342945976.47.0.537572255215.issue15419@psf.upfronthosting.co.za> Message-ID: <1347640872.7.0.412995757082.issue15419@psf.upfronthosting.co.za> ?ric Araujo added the comment: > I'd change the name of the subdirectories of build instead of the name of the build directory itself. Yep that?s what I was thinking about (or if I wasn?t, I should have been :) > IIRC distutils is more or less closed for development w.r.t. new features. Not more or less: it is frozen. The only exceptions are changes required by other changes like the pycache or ABI tag PEPs. > Would that also apply to this feature request? If we agree this is a bug, we can fix it. What do RMs think? ---------- nosy: +benjamin.peterson, georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 18:42:23 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 14 Sep 2012 16:42:23 +0000 Subject: [issue15944] memoryviews and ctypes In-Reply-To: <1347639577.63.0.484657410971.issue15944@psf.upfronthosting.co.za> Message-ID: <20120914164203.GA6660@sleipnir.bytereef.org> Stefan Krah added the comment: The decision was made in order to be able to cast back and forth between known formats. Otherwise one would be able to cast from '>> import ctypes, struct >>> d = ctypes.c_double() >>> m = memoryview(d) >>> struct.pack_into(m.format, m, 0, 22.7) >>> struct.unpack_from(m.format, m, 0)[0] 22.7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 18:47:26 2012 From: report at bugs.python.org (David Beazley) Date: Fri, 14 Sep 2012 16:47:26 +0000 Subject: [issue15944] memoryviews and ctypes In-Reply-To: <1347635130.32.0.649142152247.issue15944@psf.upfronthosting.co.za> Message-ID: <1347641246.33.0.953411775837.issue15944@psf.upfronthosting.co.za> David Beazley added the comment: I don't think memoryviews should be imposing any casting restrictions at all. It's low level. Get out of the way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 18:53:41 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 14 Sep 2012 16:53:41 +0000 Subject: [issue15944] memoryviews and ctypes In-Reply-To: <1347641246.33.0.953411775837.issue15944@psf.upfronthosting.co.za> Message-ID: <20120914165321.GA17624@sleipnir.bytereef.org> Stefan Krah added the comment: So you want to be able to segfault the core interpreter using the builtins? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 19:00:27 2012 From: report at bugs.python.org (David Beazley) Date: Fri, 14 Sep 2012 17:00:27 +0000 Subject: [issue15944] memoryviews and ctypes In-Reply-To: <1347635130.32.0.649142152247.issue15944@psf.upfronthosting.co.za> Message-ID: <1347642027.59.0.570448315359.issue15944@psf.upfronthosting.co.za> David Beazley added the comment: No, I want to be able to access the raw bytes sitting behind a memoryview as bytes without all of this casting and reinterpretation. Just show me the raw bytes. Not doubles, not ints, not structure packing, not copying into byte strings, or whatever. Is this really impossible? It sure seems so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 19:08:04 2012 From: report at bugs.python.org (Benjamin West) Date: Fri, 14 Sep 2012 17:08:04 +0000 Subject: [issue9253] argparse: optional subparsers In-Reply-To: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za> Message-ID: <1347642484.95.0.546168103672.issue9253@psf.upfronthosting.co.za> Benjamin West added the comment: https://gist.github.com/1202975#file_test_opt_subcommand.py I sketched out a sloppy test earlier. I think this test is probably not quite comprehensive enough, and I'm not sure it fits into the python style either. I suppose there are other tests I can more or less copy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 19:09:18 2012 From: report at bugs.python.org (David Beazley) Date: Fri, 14 Sep 2012 17:09:18 +0000 Subject: [issue15944] memoryviews and ctypes In-Reply-To: <1347635130.32.0.649142152247.issue15944@psf.upfronthosting.co.za> Message-ID: <1347642558.9.0.419903385921.issue15944@psf.upfronthosting.co.za> David Beazley added the comment: Just to be specific, why is something like this not possible? >>> d = ctypes.c_double() >>> m = memoryview(d) >>> m[0:8] = b'abcdefgh' >>> d.value 8.540883223036124e+194 >>> (Doesn't have to be exactly like this, but what's wrong with overwriting bytes with bytes of a compatible size?). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 19:19:04 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 14 Sep 2012 17:19:04 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1347643144.43.0.224553762668.issue15831@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks, Ezio! By the way, I didn't do a thorough check, but I noticed this difference in the 2.7 application of the patch. The *key* argument for max() needs to be marked keyword-only. This difference doesn't exist for the min() function. Or are we not using the "bare *" notation in the 2.7 docs? If not, the min() docs need to be changed instead (and possibly in several other places). Default branch: -.. function:: max(iterable[, args...], *[, key]) +.. function:: max(iterable, *[, key]) + max(arg1, arg2, *args[, key]) 2.7 branch: -.. function:: max(iterable[, args...][key]) +.. function:: max(iterable[, key]) + max(arg1, arg2, *args[, key]) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 19:31:10 2012 From: report at bugs.python.org (David Beazley) Date: Fri, 14 Sep 2012 17:31:10 +0000 Subject: [issue15944] memoryviews and ctypes In-Reply-To: <1347635130.32.0.649142152247.issue15944@psf.upfronthosting.co.za> Message-ID: <1347643870.04.0.0376711754309.issue15944@psf.upfronthosting.co.za> David Beazley added the comment: I should add that 0-dim indexing doesn't work as described either: >>> import ctypes >>> d = ctypes.c_double() >>> m = memoryview(d) >>> m[()] Traceback (most recent call last): File "", line 1, in NotImplementedError: memoryview: unsupported format >> ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 19:34:13 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 14 Sep 2012 17:34:13 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1347644053.71.0.434190606172.issue15831@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Someone pointed out that keyword-only arguments were introduced only in 3.0, but I'm not sure whether that means we can't use them as a notational device in the 2.7 docs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 19:45:18 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 14 Sep 2012 17:45:18 +0000 Subject: [issue15880] os.path.split() and long UNC names In-Reply-To: <1347036015.89.0.836232949292.issue15880@psf.upfronthosting.co.za> Message-ID: <1347644718.74.0.290988268066.issue15880@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 19:49:39 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 14 Sep 2012 17:49:39 +0000 Subject: [issue15883] Add Py_errno to work around multiple CRT issue In-Reply-To: <1347111302.92.0.306708953598.issue15883@psf.upfronthosting.co.za> Message-ID: <1347644979.86.0.954885340487.issue15883@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 20:12:07 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 14 Sep 2012 18:12:07 +0000 Subject: [issue15944] memoryviews and ctypes In-Reply-To: <1347643870.04.0.0376711754309.issue15944@psf.upfronthosting.co.za> Message-ID: <20120914181147.GA28740@sleipnir.bytereef.org> Stefan Krah added the comment: Please read msg170482. It even contains a copy and paste example! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 21:11:44 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 14 Sep 2012 19:11:44 +0000 Subject: [issue15887] urlencode should accept iterables of pairs In-Reply-To: <1347185937.29.0.747427121658.issue15887@psf.upfronthosting.co.za> Message-ID: <1347649904.4.0.834081817551.issue15887@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The first sentence of the urlencode entry is a bit garbled as something is clearly missing. "Convert a mapping object or a sequence of two-element tuples, which may either be a str or a bytes, to a ?percent-encoded? string." Mappings, duple sequences, and duples cannot be str or bytes. I presume the query argument can be a string (as stated in the docstring, but not here, though only vacuously true since only empty strings are accepted -- see below), mapping, or duple sequence, and that the phrase "which may either be a str or a bytes" refers to the unstated string option. This sentence should be fixed after deciding that the new truth should be. The stated requirement of 'two-element tuples' is overly strict. The two loop headers for k, v in query: only requires pairs, or rather iterables that produce two items, just as in two-target assignment statements. The enhancement proposal should be the expansion of 'sequence' to 'iterable'. This is in line with the general trend in 3.x of replacing list or sequence with iterable. There is no good reason to force the creation of an temporary list. The two loops for k, v in query: work perfectly well with any key-value iterable. In fact, dict (mapping) queries are now (in Python3) handled by replacing them with a key-value iterable that is not a sequence. if hasattr(query, "items"): query = query.items() So directly passing dict.items(), for instance, should be allowed. The only change needed is to the query argument rejection logic. Currently, non-empty strings are rejected, even though the doc string and docs state or imply that query may be a string. They should state that only empty strings are accepted (though I do not see the point of accepting and returning an empty string, so maybe empty strings should also be disallowed). I believe the following reproduces current behavior as regards strings except for giving a more accurate error message. if isinstance(query, (str, bytes)): if len(query): raise TypeError("non empty strings not allowed") else: return query .with_traceback is meant for when one replaces one exception type with another or modified the tb object. The current usage in the code does neither and is a no-op and should be omitted in a patch. The main part of the code can be wrapped with try-except to customize an error message if query is not iterable or if the items produced by iterating query are not iterables of pairs. ---------- nosy: +terry.reedy title: urlencode should accept generators or two elements tuples -> urlencode should accept iterables of pairs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 14 21:33:54 2012 From: report at bugs.python.org (Julian Berman) Date: Fri, 14 Sep 2012 19:33:54 +0000 Subject: [issue15627] Add a method to importlib.abc.SourceLoader for converting source to a code object In-Reply-To: <1344732276.83.0.543554641885.issue15627@psf.upfronthosting.co.za> Message-ID: <1347651234.23.0.823761282927.issue15627@psf.upfronthosting.co.za> Changes by Julian Berman : ---------- nosy: +Julian _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 03:00:47 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 15 Sep 2012 01:00:47 +0000 Subject: [issue15935] clarify argparse docs re: add_argument() type and default arguments In-Reply-To: <1347485175.79.0.860808168134.issue15935@psf.upfronthosting.co.za> Message-ID: <1347670847.71.0.033233465393.issue15935@psf.upfronthosting.co.za> Chris Jerdonek added the comment: If this looks good, can one of you three (Steven, Barry, or David) commit it in the three branches? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 03:10:31 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 15 Sep 2012 01:10:31 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1347671431.93.0.92031245001.issue15831@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Since the bare * notation wasn't added until 3.0, my guess is that we want to remove the * below (from the 2.7 application of the patch) rather than adding it back in the max() function I pasted above: -.. function:: min(iterable[, args...][key]) +.. function:: min(iterable, *[, key]) + min(arg1, arg2, *args[, key]) ---------- resolution: fixed -> stage: committed/rejected -> needs patch status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 03:46:12 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 15 Sep 2012 01:46:12 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <3XJbzR3WFCzQ4V@mail.python.org> Roundup Robot added the comment: New changeset 881acdf9133f by Ezio Melotti in branch '2.7': #15831: avoid using 3.x syntax for keyword-only args. http://hg.python.org/cpython/rev/881acdf9133f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 03:47:49 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 15 Sep 2012 01:47:49 +0000 Subject: [issue15831] comma after leading optional argument is after bracket in docs In-Reply-To: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za> Message-ID: <1347673669.29.0.668959791801.issue15831@psf.upfronthosting.co.za> Ezio Melotti added the comment: The * is not supposed to be used on 2.7, but I missed that. Thanks for noticing! ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 04:52:52 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 15 Sep 2012 02:52:52 +0000 Subject: [issue15932] files in the csv documentation's examples are not closed In-Reply-To: <1347465391.09.0.1751065548.issue15932@psf.upfronthosting.co.za> Message-ID: <3XJdSM05frzQ8k@mail.python.org> Roundup Robot added the comment: New changeset ade667076c14 by Ezio Melotti in branch '2.7': #15932: use with statement in csv doc examples. http://hg.python.org/cpython/rev/ade667076c14 New changeset 8a06fb321074 by Ezio Melotti in branch '3.2': #15932: use with statement in csv doc examples. Patch by Dario Bertini. http://hg.python.org/cpython/rev/8a06fb321074 New changeset a5a8d255daee by Ezio Melotti in branch 'default': #15932: merge with 3.2. http://hg.python.org/cpython/rev/a5a8d255daee ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 04:53:49 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 15 Sep 2012 02:53:49 +0000 Subject: [issue15932] files in the csv documentation's examples are not closed In-Reply-To: <1347465391.09.0.1751065548.issue15932@psf.upfronthosting.co.za> Message-ID: <1347677629.31.0.989666875177.issue15932@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! ---------- assignee: docs at python -> ezio.melotti resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed type: -> enhancement versions: +Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 05:00:31 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 15 Sep 2012 03:00:31 +0000 Subject: [issue15922] make howto/urllib2.rst doctests pass In-Reply-To: <1347370103.61.0.784697754485.issue15922@psf.upfronthosting.co.za> Message-ID: <1347678031.96.0.827486421196.issue15922@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 05:49:03 2012 From: report at bugs.python.org (Felipe Cruz) Date: Sat, 15 Sep 2012 03:49:03 +0000 Subject: [issue15897] zipimport.c doesn't check return value of fseek() In-Reply-To: <1347235718.45.0.529510656833.issue15897@psf.upfronthosting.co.za> Message-ID: <1347680943.93.0.779221501173.issue15897@psf.upfronthosting.co.za> Felipe Cruz added the comment: Hello! This is one of my first patches. Tests still OK! Let me know what you think! Thanks! ---------- keywords: +patch nosy: +felipecruz Added file: http://bugs.python.org/file27191/issue15897_v1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 06:44:49 2012 From: report at bugs.python.org (Felipe Cruz) Date: Sat, 15 Sep 2012 04:44:49 +0000 Subject: [issue15897] zipimport.c doesn't check return value of fseek() In-Reply-To: <1347235718.45.0.529510656833.issue15897@psf.upfronthosting.co.za> Message-ID: <1347684289.58.0.959471444855.issue15897@psf.upfronthosting.co.za> Felipe Cruz added the comment: Patch updated - fseek errors messges will be "can't read Zip file' and not "can't Open Zip file" ---------- Added file: http://bugs.python.org/file27192/issue15897_v1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 07:10:12 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 15 Sep 2012 05:10:12 +0000 Subject: [issue15897] zipimport.c doesn't check return value of fseek() In-Reply-To: <1347235718.45.0.529510656833.issue15897@psf.upfronthosting.co.za> Message-ID: <1347685812.59.0.276096036472.issue15897@psf.upfronthosting.co.za> Ezio Melotti added the comment: I suggested to Felipe on IRC to use "read" instead of "seek" because I don't think it's worth making a distinction between the two. Moreover ISTM that in most of the cases, if the fseek fails, the error is detected in a following fread, so the message currently says "can't read", and changing it to "can't seek" is technically backward-incompatible. We also checked if the test suite followed any of these new error paths, but apparently only the "if" added in the first chunk (line 880, in read_directory) is already covered. Going through the following chunks (the ones with the goto fseek_error) is fairly difficult. It should be possibly to trigger the error at line 1071, in get_data, by changing the value of self.archive, but alas self.archive is read-only. The error generated by PyErr_SetFromErrno() doesn't seem too useful. For example, with "PyErr_SetFromErrno(PyExc_IOError);" instead of "PyErr_Format(ZipImportError, "can't open Zip file: %R", archive);", the error becomes "OSError: [Errno 22] Invalid argument". This alone is fairly useless, even though the message might be better in other situations. I think either using PyErr_Format, or a combination of the two (something like "ZipImportError: can't read Zip file: 'ziptestmodule' ([Errno 22] Invalid argument)") would be better. ---------- keywords: -easy nosy: +ezio.melotti, pitrou stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 07:20:02 2012 From: report at bugs.python.org (Chris Rebert) Date: Sat, 15 Sep 2012 05:20:02 +0000 Subject: [issue15789] mention shell-like parts of the std lib in the subprocess docs In-Reply-To: <1346052242.66.0.254880477781.issue15789@psf.upfronthosting.co.za> Message-ID: <1347686402.96.0.75772084078.issue15789@psf.upfronthosting.co.za> Chris Rebert added the comment: Ping. Any further comments? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 07:35:02 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 15 Sep 2012 05:35:02 +0000 Subject: [issue15789] mention shell-like parts of the std lib in the subprocess docs In-Reply-To: <1346052242.66.0.254880477781.issue15789@psf.upfronthosting.co.za> Message-ID: <3XJj3T1Vd2zPJJ@mail.python.org> Roundup Robot added the comment: New changeset 820032281f49 by Ezio Melotti in branch '2.7': #15789: mention shell-like parts of the stdlib in the subprocess docs. Patch by Chris Rebert. http://hg.python.org/cpython/rev/820032281f49 New changeset 9794f69c1d09 by Ezio Melotti in branch '3.2': #15789: mention shell-like parts of the stdlib in the subprocess docs. Patch by Chris Rebert. http://hg.python.org/cpython/rev/9794f69c1d09 New changeset 09011896374d by Ezio Melotti in branch 'default': #15789: merge with 3.2. http://hg.python.org/cpython/rev/09011896374d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 07:36:02 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 15 Sep 2012 05:36:02 +0000 Subject: [issue15789] mention shell-like parts of the std lib in the subprocess docs In-Reply-To: <1346052242.66.0.254880477781.issue15789@psf.upfronthosting.co.za> Message-ID: <1347687362.86.0.834396886357.issue15789@psf.upfronthosting.co.za> Ezio Melotti added the comment: Pong, thanks for the patch! ---------- assignee: docs at python -> ezio.melotti nosy: +ezio.melotti resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 08:02:18 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 15 Sep 2012 06:02:18 +0000 Subject: [issue15880] os.path.split() and long UNC names In-Reply-To: <1347036015.89.0.836232949292.issue15880@psf.upfronthosting.co.za> Message-ID: <1347688938.8.0.464194926941.issue15880@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy nosy: +ezio.melotti stage: -> test needed type: crash -> behavior versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 08:03:05 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 15 Sep 2012 06:03:05 +0000 Subject: [issue15887] urlencode should accept iterables of pairs In-Reply-To: <1347185937.29.0.747427121658.issue15887@psf.upfronthosting.co.za> Message-ID: <1347688985.71.0.815480190957.issue15887@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 08:04:08 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 15 Sep 2012 06:04:08 +0000 Subject: [issue15888] ipaddress doctest examples have some errors In-Reply-To: <1347190349.96.0.156720503481.issue15888@psf.upfronthosting.co.za> Message-ID: <1347689048.96.0.707093060474.issue15888@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 08:05:52 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 15 Sep 2012 06:05:52 +0000 Subject: [issue15920] make howto/regex.rst doctests pass In-Reply-To: <1347365250.51.0.50908200461.issue15920@psf.upfronthosting.co.za> Message-ID: <1347689152.65.0.136573655506.issue15920@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: docs at python -> ezio.melotti nosy: +ezio.melotti type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 08:09:05 2012 From: report at bugs.python.org (Chris Rebert) Date: Sat, 15 Sep 2012 06:09:05 +0000 Subject: [issue14570] Document json "sort_keys" parameter properly In-Reply-To: <1334284947.71.0.88941407788.issue14570@psf.upfronthosting.co.za> Message-ID: <1347689345.25.0.65047784488.issue14570@psf.upfronthosting.co.za> Chris Rebert added the comment: Any reactions? The patch is pretty straightforward... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 08:12:54 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 15 Sep 2012 06:12:54 +0000 Subject: [issue14570] Document json "sort_keys" parameter properly In-Reply-To: <1334284947.71.0.88941407788.issue14570@psf.upfronthosting.co.za> Message-ID: <1347689574.26.0.331813606163.issue14570@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +petri.lehtinen stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 12:27:59 2012 From: report at bugs.python.org (Jean-Paul Calderone) Date: Sat, 15 Sep 2012 10:27:59 +0000 Subject: [issue15945] memoryview + bytes fails Message-ID: <1347704879.16.0.744568990947.issue15945@psf.upfronthosting.co.za> New submission from Jean-Paul Calderone: Python 3.3.0rc2+ (default:9def2209a839, Sep 10 2012, 08:44:51) [GCC 4.6.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> memoryview(b'foo') + b'bar' Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for +: 'memoryview' and 'bytes' >>> b'bar' + memoryview(b'foo') b'barfoo' >>> ---------- messages: 170511 nosy: exarkun priority: normal severity: normal status: open title: memoryview + bytes fails type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 14:24:15 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 15 Sep 2012 12:24:15 +0000 Subject: [issue15945] memoryview + bytes fails In-Reply-To: <1347704879.16.0.744568990947.issue15945@psf.upfronthosting.co.za> Message-ID: <1347711855.47.0.308268375016.issue15945@psf.upfronthosting.co.za> Stefan Krah added the comment: What is the expected outcome? memoryviews can't be resized, so this scenario isn't possible: >>> bytearray([1,2,3]) + b'123' bytearray(b'\x01\x02\x03123') ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 14:37:25 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 15 Sep 2012 12:37:25 +0000 Subject: [issue15945] memoryview + bytes fails In-Reply-To: <1347704879.16.0.744568990947.issue15945@psf.upfronthosting.co.za> Message-ID: <1347712645.61.0.638230140824.issue15945@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Just prepend the empty bytestring if you want to make sure the result is a bytes object: >>> b'' + memoryview(b'foo') + b'bar' b'foobar' I think the following limitation may be more annoying, though: >>> b''.join([memoryview(b'foo'), b'bar']) Traceback (most recent call last): File "", line 1, in TypeError: sequence item 0: expected bytes, memoryview found ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 14:57:40 2012 From: report at bugs.python.org (Christian Mikula) Date: Sat, 15 Sep 2012 12:57:40 +0000 Subject: [issue15946] Windows 8 x64 - IO-Error Message-ID: <1347713860.36.0.872797660614.issue15946@psf.upfronthosting.co.za> New submission from Christian Mikula: OS Windows 8 Enterprise x64 clean installed. Python Version 2.6.6 and 2.7.3 both x64 installed. Problem is to delete one Directory and immediately after create one new with the same Name! !!! Code !!! import sys, platform, os, shutil TEST_PATH = "/test" print "platform:\t", platform.platform() print "sys.platform:\t", sys.platform print "sys.version:\t", sys.version print "directory test:\t'%s'" % TEST_PATH print if os.path.exists(TEST_PATH): shutil.rmtree(TEST_PATH) if not os.path.exists(TEST_PATH): os.makedirs(TEST_PATH) print "success" !!! End of code !!! The error is only present if the Directory was deleted previously. Error: Traceback (most recent call last): File "dir_test.py", line 23, in os.makedirs(BUILD_PATH) File "C:\Program Files\Python27\lib\os.py", line 157, in makedirs mkdir(name, mode) WindowsError: [Error 5] Zugriff verweigert: '/test' ---------- components: IO, Windows files: dir_test.png messages: 170514 nosy: cmikula priority: normal severity: normal status: open title: Windows 8 x64 - IO-Error versions: Python 2.6, Python 2.7 Added file: http://bugs.python.org/file27193/dir_test.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 15:05:15 2012 From: report at bugs.python.org (Christian Mikula) Date: Sat, 15 Sep 2012 13:05:15 +0000 Subject: [issue15946] Windows 8 x64 - IO-Error In-Reply-To: <1347713860.36.0.872797660614.issue15946@psf.upfronthosting.co.za> Message-ID: <1347714315.23.0.135497026177.issue15946@psf.upfronthosting.co.za> Changes by Christian Mikula : ---------- type: -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 15:13:55 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 15 Sep 2012 13:13:55 +0000 Subject: [issue15946] Windows 8 x64 - IO-Error In-Reply-To: <1347713860.36.0.872797660614.issue15946@psf.upfronthosting.co.za> Message-ID: <1347714835.11.0.455302070792.issue15946@psf.upfronthosting.co.za> R. David Murray added the comment: I believe this is a Windows...feature? We have lots of trouble with this ourselves in the test suite, if I understand correctly. ---------- nosy: +brian.curtin, r.david.murray, tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 15:20:40 2012 From: report at bugs.python.org (Felipe Cruz) Date: Sat, 15 Sep 2012 13:20:40 +0000 Subject: [issue15897] zipimport.c doesn't check return value of fseek() In-Reply-To: <1347235718.45.0.529510656833.issue15897@psf.upfronthosting.co.za> Message-ID: <1347715240.89.0.776932896208.issue15897@psf.upfronthosting.co.za> Felipe Cruz added the comment: I've updated the patch changing fseek_error goto block error return from PyErr_SetFromErrno to PyErr_Format(ZipImportError, "can't read Zip file: %R", archive); (returning NULL after). ---------- Added file: http://bugs.python.org/file27194/issue15897_v1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 15:26:06 2012 From: report at bugs.python.org (Christian Mikula) Date: Sat, 15 Sep 2012 13:26:06 +0000 Subject: [issue15946] Windows 8 x64 - IO-Error In-Reply-To: <1347713860.36.0.872797660614.issue15946@psf.upfronthosting.co.za> Message-ID: <1347715566.07.0.562178748195.issue15946@psf.upfronthosting.co.za> Christian Mikula added the comment: I also think that it is a windows feature! who should report this problem with microsoft? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 16:41:47 2012 From: report at bugs.python.org (Facundo Batista) Date: Sat, 15 Sep 2012 14:41:47 +0000 Subject: [issue15947] Assigning new values to instance of pointer types does not check validity Message-ID: <1347720107.38.0.0969129955644.issue15947@psf.upfronthosting.co.za> New submission from Facundo Batista: In the doc it says: """ Assigning a new value to instances of the pointer types c_char_p, c_wchar_p, and c_void_p changes the memory location they point to, not the contents of the memory block [...]. >>> s = "Hello, World" >>> c_s = c_wchar_p(s) >>> print(c_s) c_wchar_p('Hello, World') >>> c_s.value = "Hi, there" >>> print(c_s) c_wchar_p('Hi, there') >>> print(s) # first object is unchanged Hello, World >>> """ However, c_s it's not getting "Hi, there" as "the memory location it points to", otherwise next access will surely segfault. OTOH, if it *does* change the memory location, but the value is cached locally, which is the point of letting it change the memory location? Shouldn't it raise AttributeError or something? Thanks! ---------- components: ctypes messages: 170518 nosy: facundobatista priority: normal severity: normal status: open title: Assigning new values to instance of pointer types does not check validity type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 16:50:34 2012 From: report at bugs.python.org (Christian Heimes) Date: Sat, 15 Sep 2012 14:50:34 +0000 Subject: [issue15897] zipimport.c doesn't check return value of fseek() In-Reply-To: <1347235718.45.0.529510656833.issue15897@psf.upfronthosting.co.za> Message-ID: <1347720634.2.0.596816308884.issue15897@psf.upfronthosting.co.za> Christian Heimes added the comment: You can further compress the changes when you get rid of `rc` and check the return value inline, for example: if (fseek(...) == -1) { errorhandler; } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 17:00:23 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Sat, 15 Sep 2012 15:00:23 +0000 Subject: [issue15526] test_startfile crash on Windows 7 AMD64 In-Reply-To: <1343827804.07.0.425515249327.issue15526@psf.upfronthosting.co.za> Message-ID: <1347721223.26.0.632762200809.issue15526@psf.upfronthosting.co.za> Jeremy Kloth added the comment: This test is still intermittently failing on the AMD64 Windows7 SP1 buildbot: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/630 Any chance the patch could be committed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 17:29:07 2012 From: report at bugs.python.org (Christian Heimes) Date: Sat, 15 Sep 2012 15:29:07 +0000 Subject: [issue15948] Unchecked return value of I/O functions Message-ID: <1347722947.26.0.499070360065.issue15948@psf.upfronthosting.co.za> New submission from Christian Heimes: Python's C code contains more than 30 lines that don't check the return value of I/O functions like fseek(). A missing check can hide issues like a failing NFS connection. I've created an (incomplete) list of missing checks with find and grep. $ find -name '*.c' | sort | xargs egrep '^(\t|\ )*(fopen|fdopen|fread|fseek|fwite|open|read|write|readdir|readlink|lseek|dup|dup2|opendir|fdopendir|closedir|dirfd|readdir|seekdir|scandir|telldir|fcntl|ioctl)\ *\(' ./Modules/_ctypes/libffi/src/dlmalloc.c: read(fd, buf, sizeof(buf)) == sizeof(buf)) { ./Modules/_cursesmodule.c: fseek(fp, 0, 0); ./Modules/_cursesmodule.c: fseek(fp, 0, 0); ./Modules/faulthandler.c: write(thread.fd, thread.header, thread.header_len); ./Modules/getpath.c: fseek(env_file, 0, SEEK_SET); ./Modules/mmapmodule.c: lseek(fileno, 0, SEEK_SET); ./Modules/ossaudiodev.c: ioctl(fd, SNDCTL_DSP_cmd, &arg) ./Modules/posixmodule.c: ioctl(slave_fd, I_PUSH, "ptem"); /* push ptem */ ./Modules/posixmodule.c: ioctl(slave_fd, I_PUSH, "ldterm"); /* push ldterm */ ./Modules/posixmodule.c: ioctl(slave_fd, I_PUSH, "ttcompat"); /* push ttcompat */ ./Modules/_posixsubprocess.c: fcntl(fd_dir_fd, F_SETFD, old | FD_CLOEXEC); ./Modules/_posixsubprocess.c: fcntl(p2cread, F_SETFD, old & ~FD_CLOEXEC); ./Modules/_posixsubprocess.c: fcntl(c2pwrite, F_SETFD, old & ~FD_CLOEXEC); ./Modules/_posixsubprocess.c: fcntl(errwrite, F_SETFD, old & ~FD_CLOEXEC); ./Modules/signalmodule.c: write(wakeup_fd, &byte, 1); ./Modules/socketmodule.c: ioctl(s->sock_fd, FIONBIO, (caddr_t)&block, sizeof(block)); ./Modules/socketmodule.c: ioctl(s->sock_fd, FIONBIO, (unsigned int *)&block); ./Modules/socketmodule.c: fcntl(s->sock_fd, F_SETFL, delay_flag); ./Modules/zipimport.c: fseek(fp, -22, SEEK_END); ./Modules/zipimport.c: fseek(fp, header_offset, 0); /* Start of file header */ ./Modules/zipimport.c: fseek(fp, header_offset + 8, 0); ./Modules/zipimport.c: fseek(fp, header_offset + 42, 0); ./Modules/zipimport.c: fseek(fp, file_offset, 0); ./Modules/zipimport.c: fseek(fp, file_offset + 26, 0); ./Modules/zlib/gzlib.c: open(path, ./PC/getpathp.c: fseek(env_file, 0, SEEK_SET); ./Python/traceback.c: lseek(fd, 0, 0); /* Reset position */ ./Python/traceback.c: write(fd, buffer, len); ./Python/traceback.c: write(fd, buffer, len); ./Python/traceback.c: write(fd, &c, 1); ./Python/traceback.c: write(fd, "\"", 1); ./Python/traceback.c: write(fd, "\"", 1); ./Python/traceback.c: write(fd, "\n", 1); ./Python/traceback.c: write(fd, "\n", 1); The missing checks for zipimport.c are already handles by ticket #15897. ---------- keywords: easy messages: 170521 nosy: christian.heimes priority: normal severity: normal status: open title: Unchecked return value of I/O functions type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 18:35:10 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 15 Sep 2012 16:35:10 +0000 Subject: [issue14570] Document json "sort_keys" parameter properly In-Reply-To: <1334284947.71.0.88941407788.issue14570@psf.upfronthosting.co.za> Message-ID: <1347726910.72.0.866008036834.issue14570@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I would recommend making the added and modified lines not exceed 79 characters in both files. Also, for the .rst file, you can use slashes to break lines as shown in the following example: http://hg.python.org/cpython/file/09011896374d/Doc/library/argparse.rst#l133 ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 18:37:35 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 15 Sep 2012 16:37:35 +0000 Subject: [issue14570] Document json "sort_keys" parameter properly In-Reply-To: <1334284947.71.0.88941407788.issue14570@psf.upfronthosting.co.za> Message-ID: <1347727055.62.0.0149131813087.issue14570@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Also, while not strictly necessary, it is more customary and convenient to provide a single patch file for all files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 18:38:31 2012 From: report at bugs.python.org (Brian Curtin) Date: Sat, 15 Sep 2012 16:38:31 +0000 Subject: [issue15946] Windows 8 x64 - IO-Error In-Reply-To: <1347713860.36.0.872797660614.issue15946@psf.upfronthosting.co.za> Message-ID: <1347727111.72.0.224011071497.issue15946@psf.upfronthosting.co.za> Brian Curtin added the comment: I'm not sure Microsoft is going to change anything about this - it has done this for a long time, if not forever. We recently had #15496 receive changes, and #7443 is in the same area and has more details and some patches, so I'd suggest taking up the discussion over there. ---------- resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> test.support.unlink issue on Windows platform type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 19:00:19 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 15 Sep 2012 17:00:19 +0000 Subject: [issue15949] docs.python.org not getting updated Message-ID: <1347728419.57.0.753818975668.issue15949@psf.upfronthosting.co.za> New submission from Chris Jerdonek: docs.python.org doesn't seem to be getting updated anymore. For example, this revision from Tuesday, Sept 11 is not reflected: http://hg.python.org/cpython/rev/c8d60d0c736b ---------- assignee: docs at python components: Documentation messages: 170525 nosy: cjerdonek, docs at python priority: normal severity: normal status: open title: docs.python.org not getting updated _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 19:18:16 2012 From: report at bugs.python.org (Felipe Cruz) Date: Sat, 15 Sep 2012 17:18:16 +0000 Subject: [issue15897] zipimport.c doesn't check return value of fseek() In-Reply-To: <1347235718.45.0.529510656833.issue15897@psf.upfronthosting.co.za> Message-ID: <1347729496.62.0.933261527416.issue15897@psf.upfronthosting.co.za> Felipe Cruz added the comment: v4 - inline fseek return code check - as Christian suggested ---------- Added file: http://bugs.python.org/file27195/issue15897_v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 20:06:18 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 15 Sep 2012 18:06:18 +0000 Subject: [issue15933] flaky test in test_datetime In-Reply-To: <1347466816.36.0.945599436453.issue15933@psf.upfronthosting.co.za> Message-ID: <1347732378.05.0.202367072981.issue15933@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I also notice that there is an unnecessary call to time.sleep(0.1) whenever the loop exhausts. This adds .1 seconds to the test run for every call to test_today() on, for example, platforms that "never get the same value twice" (according to the code comment). For example, on my system (Mac OS X 10.7.4) this test method is called 8 times when running-- ./python.exe -m test -v test_datetime and in 6 of these calls the loop regularly exhausts. This adds 0.6 seconds to each test run, and this doesn't include the first two loop iterations, which would account for a total of 1.8 seconds added on every test run. ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 21:53:41 2012 From: report at bugs.python.org (Chris Rebert) Date: Sat, 15 Sep 2012 19:53:41 +0000 Subject: [issue14616] subprocess docs should mention pipes.quote/shlex.quote In-Reply-To: <1334769157.78.0.557014485739.issue14616@psf.upfronthosting.co.za> Message-ID: <1347738821.95.0.978447236828.issue14616@psf.upfronthosting.co.za> Changes by Chris Rebert : Added file: http://bugs.python.org/file27196/subprocess.rst-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 21:54:42 2012 From: report at bugs.python.org (Chris Rebert) Date: Sat, 15 Sep 2012 19:54:42 +0000 Subject: [issue14616] subprocess docs should mention pipes.quote/shlex.quote In-Reply-To: <1334769157.78.0.557014485739.issue14616@psf.upfronthosting.co.za> Message-ID: <1347738882.66.0.0496611007112.issue14616@psf.upfronthosting.co.za> Chris Rebert added the comment: Updated patches to mention pipes.quote(). ---------- Added file: http://bugs.python.org/file27197/subprocess.rst-3.3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 21:54:51 2012 From: report at bugs.python.org (Chris Rebert) Date: Sat, 15 Sep 2012 19:54:51 +0000 Subject: [issue14616] subprocess docs should mention pipes.quote/shlex.quote In-Reply-To: <1334769157.78.0.557014485739.issue14616@psf.upfronthosting.co.za> Message-ID: <1347738891.67.0.285968880266.issue14616@psf.upfronthosting.co.za> Changes by Chris Rebert : Removed file: http://bugs.python.org/file25570/subprocess_shlex_quote.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 22:00:16 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 15 Sep 2012 20:00:16 +0000 Subject: [issue1521051] Allow passing DocTestRunner and DocTestCase in doctest Message-ID: <1347739216.21.0.559002884102.issue1521051@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I think this would be useful as well. For example, it would let one more easily get finer-grained test result data (e.g. to the level of doctest examples rather than just the TestCase level). Without this, I needed to monkey patch. The previously attached patch enhances DocTestSuite. I think DocFileSuite should receive the same treatment (the case I was more interested in myself -- cf. http://bugs.python.org/issue15629#msg170447 ). ---------- nosy: +cjerdonek title: Extra configurability for doctest TestCases -> Allow passing DocTestRunner and DocTestCase in doctest versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 23:32:47 2012 From: report at bugs.python.org (Thomas Lee) Date: Sat, 15 Sep 2012 21:32:47 +0000 Subject: [issue15887] urlencode should accept iterables of pairs In-Reply-To: <1347185937.29.0.747427121658.issue15887@psf.upfronthosting.co.za> Message-ID: <1347744767.66.0.684460229658.issue15887@psf.upfronthosting.co.za> Thomas Lee added the comment: Working on a patch for this. Should be ready for review shortly. ---------- nosy: +thomaslee _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 23:40:55 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 15 Sep 2012 21:40:55 +0000 Subject: [issue15933] flaky test in test_datetime In-Reply-To: <1347466816.36.0.945599436453.issue15933@psf.upfronthosting.co.za> Message-ID: <1347745254.57.0.421969564428.issue15933@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Here are the 6 cases where it always exhausts on my system: test_today (test.datetimetester.TestSubclassDateTime_Pure) test_today (test.datetimetester.TestDateTimeTZ_Pure) test_today (test.datetimetester.TestDateTime_Pure) test_today (test.datetimetester.TestSubclassDateTime_Fast) test_today (test.datetimetester.TestDateTimeTZ_Fast) test_today (test.datetimetester.TestDateTime_Fast) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 15 23:48:26 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 15 Sep 2012 21:48:26 +0000 Subject: [issue15419] distutils: build should use a version-specific build directory In-Reply-To: <1342945976.47.0.537572255215.issue15419@psf.upfronthosting.co.za> Message-ID: <1347745706.03.0.255872019681.issue15419@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: Changing of name of subdirectory would break e.g. shell scripts, which set PYTHONPATH=build/lib when calling Python scripts, so this change rather should not be made in micro releases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 00:01:05 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 15 Sep 2012 22:01:05 +0000 Subject: [issue15933] flaky test in test_datetime In-Reply-To: <1347466816.36.0.945599436453.issue15933@psf.upfronthosting.co.za> Message-ID: <1347746465.29.0.897743973584.issue15933@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I think we can avoid unnecessary sleeps if we only loop again if the final assert fails (i.e. by including the "or" condition with the time delta allowance inside the loop and not just outside). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 00:13:45 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 15 Sep 2012 22:13:45 +0000 Subject: [issue15526] test_startfile crash on Windows 7 AMD64 In-Reply-To: <1343827804.07.0.425515249327.issue15526@psf.upfronthosting.co.za> Message-ID: <3XK7Cn2PrSzQVt@mail.python.org> Roundup Robot added the comment: New changeset bc5c5b79b7e1 by Antoine Pitrou in branch '3.2': Issue #15526: try to fix test_startfile's inability to clean up after itself in time. http://hg.python.org/cpython/rev/bc5c5b79b7e1 New changeset 1704deb7e6d7 by Antoine Pitrou in branch 'default': Issue #15526: try to fix test_startfile's inability to clean up after itself in time. http://hg.python.org/cpython/rev/1704deb7e6d7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 00:15:36 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 15 Sep 2012 22:15:36 +0000 Subject: [issue15526] test_startfile crash on Windows 7 AMD64 In-Reply-To: <1343827804.07.0.425515249327.issue15526@psf.upfronthosting.co.za> Message-ID: <1347747336.93.0.645802591528.issue15526@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, hopefully there'll no more be failures now. ---------- resolution: -> fixed stage: -> committed/rejected versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 00:24:12 2012 From: report at bugs.python.org (Thomas Lee) Date: Sat, 15 Sep 2012 22:24:12 +0000 Subject: [issue15887] urlencode should accept iterables of pairs In-Reply-To: <1347185937.29.0.747427121658.issue15887@psf.upfronthosting.co.za> Message-ID: <1347747852.73.0.672954901409.issue15887@psf.upfronthosting.co.za> Thomas Lee added the comment: Patch attached. Terry, you'll notice I wrap the main part of the urlencode function in a big try/except block to catch TypeErrors & ValueErrors. I'm a bit concerned that doing this may misreport the true underlying error in the event we screw up values/types in a way that doesn't relate to the 'query' argument, but I think the code seems to do a pretty good job of ensuring that won't happen -- so that fear may be unfounded. You'll see I reworked the documentation quite a bit. The wording was a bit odd in places, and I called out a few things that may not be obvious at a glance. Hopefully it seems like an improvement. :) ---------- keywords: +patch Added file: http://bugs.python.org/file27198/issue-15887-01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 00:28:07 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 15 Sep 2012 22:28:07 +0000 Subject: [issue15933] flaky test in test_datetime In-Reply-To: <1347466816.36.0.945599436453.issue15933@psf.upfronthosting.co.za> Message-ID: <1347748087.21.0.949690051588.issue15933@psf.upfronthosting.co.za> Ezio Melotti added the comment: The comment before the check states 4 possible reasons for this failure: 1. It recently became midnight, between the today() and the time() calls. 2. The platform time() has such fine resolution that we'll never get the same value twice. 3. The platform time() has poor resolution, and we just happened to call today() right before a resolution quantum boundary. 4. The system clock got fiddled between calls. The test should be able to address 1 and 4 (unless the clock fiddler is really fast). 2 seems common (I couldn't get the same value twice here), but the timedelta is less than half second, so the test still passes. So the failure is caused by either 3 (the platform time() has a resolution of more than half second), or by a really slow buildbot, so that half second passes between the two calls, or possibly by a combination of the two. The attached patch does 3 things: 1) it uses assertLess instead of assertTrue to get a better error message; 2) it imports time() directly instead of using time.time(), in order to reduce the delay between the call to .today() and the one to time(); 3) it removes the sleep altogether, since it's useless for cases 1, 2, and 4, and probably doesn't help for case 3 either; This wouldn't probably fix the sporadic failure, but will give us more information on the next failure and make the tests faster. Checking the time() resolution on the "x86 OpenIndiana 3.2" might also be useful. FTR I tried to reproduce the failure using on my machine: ./python -m test -m TestSubclassDateTime_Fast -F test_datetime but I didn't manage to. ---------- keywords: +patch nosy: +ezio.melotti Added file: http://bugs.python.org/file27199/issue15933.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 00:45:38 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 15 Sep 2012 22:45:38 +0000 Subject: [issue15933] flaky test in test_datetime In-Reply-To: <1347466816.36.0.945599436453.issue15933@psf.upfronthosting.co.za> Message-ID: <1347749138.58.0.216123143052.issue15933@psf.upfronthosting.co.za> Chris Jerdonek added the comment: if today == todayagain: - break + return # test passed Might it make more sense to do the passing time-delta check inside the loop (at the above location), and then raise an exception at the end if the loop exhausts? I think this might be clearer (in addition to preventing unnecessary looping). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 00:52:57 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 15 Sep 2012 22:52:57 +0000 Subject: [issue15933] flaky test in test_datetime In-Reply-To: <1347466816.36.0.945599436453.issue15933@psf.upfronthosting.co.za> Message-ID: <1347749577.76.0.122514203906.issue15933@psf.upfronthosting.co.za> Ezio Melotti added the comment: That won't always work for case 1 (when theclass is e.g. 'date') and for case 4 (even if it's unlikely). Technically 2 loops should be enough, but without the sleep I don't think it matters much if it does 1 or 3 loops. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 01:08:52 2012 From: report at bugs.python.org (Felipe Cruz) Date: Sat, 15 Sep 2012 23:08:52 +0000 Subject: [issue15948] Unchecked return value of I/O functions In-Reply-To: <1347722947.26.0.499070360065.issue15948@psf.upfronthosting.co.za> Message-ID: <1347750532.84.0.147312562105.issue15948@psf.upfronthosting.co.za> Felipe Cruz added the comment: I can submit patches.. Is there any problem to send 1 patch per module? ---------- nosy: +felipecruz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 01:17:14 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 15 Sep 2012 23:17:14 +0000 Subject: [issue15948] Unchecked return value of I/O functions In-Reply-To: <1347722947.26.0.499070360065.issue15948@psf.upfronthosting.co.za> Message-ID: <1347751034.78.0.170659628938.issue15948@psf.upfronthosting.co.za> Ezio Melotti added the comment: I think that's OK. ---------- nosy: +ezio.melotti stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 01:18:01 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 15 Sep 2012 23:18:01 +0000 Subject: [issue12075] python3.2 memory leak when reloading class with attributes In-Reply-To: <1305357392.12.0.709817768407.issue12075@psf.upfronthosting.co.za> Message-ID: <1347751081.3.0.721036574805.issue12075@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 01:25:54 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 15 Sep 2012 23:25:54 +0000 Subject: [issue1052827] filelist.findall should not fail on dangling symlinks Message-ID: <1347751554.44.0.672297391603.issue1052827@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy versions: +Python 3.3, Python 3.4 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 01:29:51 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 15 Sep 2012 23:29:51 +0000 Subject: [issue12321] documentation of ElementTree.find In-Reply-To: <1307958561.6.0.547513151308.issue12321@psf.upfronthosting.co.za> Message-ID: <1347751791.81.0.981526506065.issue12321@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 01:32:10 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 15 Sep 2012 23:32:10 +0000 Subject: [issue15606] re.VERBOSE whitespace behavior not completely documented In-Reply-To: <1344534617.67.0.49137100671.issue15606@psf.upfronthosting.co.za> Message-ID: <1347751930.88.0.695411674706.issue15606@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 02:49:19 2012 From: report at bugs.python.org (Julian Berman) Date: Sun, 16 Sep 2012 00:49:19 +0000 Subject: [issue11664] Add patch method to unittest.TestCase In-Reply-To: <1300999439.71.0.376555102459.issue11664@psf.upfronthosting.co.za> Message-ID: <1347756559.78.0.953739372916.issue11664@psf.upfronthosting.co.za> Julian Berman added the comment: It's kind of unfortunate that `mock.patch` is called `mock.patch`. I was thinking about this a bit more yesterday, and `mock.patch.object` is the one that I think would be most appropriate to put on `TestCase`, and the best name for it is probably `patch`, but doing that would be deathly confusing, so I don't think that's a real choice we can make. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 04:24:35 2012 From: report at bugs.python.org (Felipe Cruz) Date: Sun, 16 Sep 2012 02:24:35 +0000 Subject: [issue15744] missing tests for {RawIO,BufferedIO,TextIO}.writelines In-Reply-To: <1345500357.29.0.226025015503.issue15744@psf.upfronthosting.co.za> Message-ID: <1347762275.59.0.517659430385.issue15744@psf.upfronthosting.co.za> Felipe Cruz added the comment: Add tests for {RawIO,BufferedIO,TextIO}.writelines() ---------- keywords: +patch nosy: +felipecruz Added file: http://bugs.python.org/file27200/issue15744_v1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 04:42:07 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 16 Sep 2012 02:42:07 +0000 Subject: [issue15933] flaky test in test_datetime In-Reply-To: <1347466816.36.0.945599436453.issue15933@psf.upfronthosting.co.za> Message-ID: <1347763327.68.0.82607982807.issue15933@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > That won't always work for case 1 (when theclass is e.g. 'date') and for case 4 (even if it's unlikely). Can you explain what you mean by this? It seems the timedelta allowance would be equally valid and serve the same purpose no matter what case or whether dealing with dates or datetimes (e.g. different date objects because of (1) would also fail the `< timedelta(seconds=0.5)` check). For example-- >>> from datetime import date, timedelta >>> d1 = date(2012, 1, 1) >>> d2 = date(2012, 1, 2) >>> abs(d2 - d1) < timedelta(seconds=0.5) False Basically, the check is to confirm that today and todayagain are within 0.1 seconds of each other -- no matter which case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 06:23:52 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 16 Sep 2012 04:23:52 +0000 Subject: [issue11454] email.message import time In-Reply-To: <1299701237.24.0.992920521308.issue11454@psf.upfronthosting.co.za> Message-ID: <1347769432.06.0.188098961985.issue11454@psf.upfronthosting.co.za> Ezio Melotti added the comment: I tried to remove a few unused regex and inline some of the others (the re module has its own caching anyway and they don't seem to be documented), but it didn't get so much faster (see attached patch). I then put the second list of email imports of the previous message in a file and run it with cprofile and these are the results: === Without patch === $ time ./python -m issue11454_imp2 [69308 refs] real 0m0.337s user 0m0.312s sys 0m0.020s $ ./python -m cProfile -s time issue11454_imp2.py 15130 function calls (14543 primitive calls) in 0.191 seconds Ordered by: internal time ncalls tottime percall cumtime percall filename:lineno(function) 26 0.029 0.001 0.029 0.001 {built-in method loads} 1248 0.015 0.000 0.018 0.000 sre_parse.py:184(__next) 3 0.010 0.003 0.015 0.005 sre_compile.py:301(_optimize_unicode) 48/17 0.009 0.000 0.037 0.002 sre_parse.py:418(_parse) 30/1 0.008 0.000 0.191 0.191 {built-in method exec} 82 0.007 0.000 0.024 0.000 {built-in method __build_class__} 25 0.006 0.000 0.024 0.001 sre_compile.py:207(_optimize_charset) 8 0.005 0.001 0.005 0.001 {built-in method load_dynamic} 1122 0.005 0.000 0.022 0.000 sre_parse.py:209(get) 177 0.005 0.000 0.005 0.000 {built-in method stat} 107 0.005 0.000 0.012 0.000 :1350(find_loader) 2944/2919 0.004 0.000 0.004 0.000 {built-in method len} 69/15 0.003 0.000 0.028 0.002 sre_compile.py:32(_compile) 9 0.003 0.000 0.003 0.000 sre_compile.py:258(_mk_bitmap) 94 0.002 0.000 0.003 0.000 :74(_path_join) === With patch === $ time ./python -m issue11454_imp2 [69117 refs] real 0m0.319s user 0m0.304s sys 0m0.012s $ ./python -m cProfile -s time issue11454_imp2.py 11281 function calls (10762 primitive calls) in 0.162 seconds Ordered by: internal time ncalls tottime percall cumtime percall filename:lineno(function) 21 0.022 0.001 0.022 0.001 {built-in method loads} 3 0.011 0.004 0.015 0.005 sre_compile.py:301(_optimize_unicode) 708 0.008 0.000 0.010 0.000 sre_parse.py:184(__next) 30/1 0.008 0.000 0.238 0.238 {built-in method exec} 82 0.007 0.000 0.023 0.000 {built-in method __build_class__} 187 0.005 0.000 0.005 0.000 {built-in method stat} 8 0.005 0.001 0.005 0.001 {built-in method load_dynamic} 107 0.005 0.000 0.012 0.000 :1350(find_loader) 29/8 0.005 0.000 0.020 0.002 sre_parse.py:418(_parse) 11 0.004 0.000 0.020 0.002 sre_compile.py:207(_optimize_charset) 643 0.003 0.000 0.012 0.000 sre_parse.py:209(get) 5 0.003 0.001 0.003 0.001 {built-in method dumps} 94 0.002 0.000 0.003 0.000 :74(_path_join) 257 0.002 0.000 0.002 0.000 quoprimime.py:56() 26 0.002 0.000 0.116 0.004 :938(get_code) 1689/1676 0.002 0.000 0.002 0.000 {built-in method len} 31 0.002 0.000 0.003 0.000 :1034(get_data) 256 0.002 0.000 0.002 0.000 {method 'setdefault' of 'dict' objects} 119 0.002 0.000 0.003 0.000 :86(_path_split) 35 0.002 0.000 0.019 0.001 :1468(_find_module) 34 0.002 0.000 0.015 0.000 :1278(_get_loader) 39/6 0.002 0.000 0.023 0.004 sre_compile.py:32(_compile) 26/3 0.001 0.000 0.235 0.078 :853(_load_module) The time spent in sre_compile.py:301(_optimize_unicode) most likely comes from email.utils._has_surrogates (there's a further speedup when it's commented away): _has_surrogates = re.compile('([^\ud800-\udbff]|\A)[\udc00-\udfff]([^\udc00-\udfff]|\Z)').search This is used in a number of places, so it can't be inlined. I wanted to optimize it but I'm not sure what it's supposed to do. It matches lone low surrogates, but not lone high ones, and matches some invalid sequences, but not others: >>> _has_surrogates('\ud800') # lone high >>> _has_surrogates('\udc00') # lone low <_sre.SRE_Match object at 0x9ae00e8> >>> _has_surrogates('\ud800\udc00') # valid pair (high+low) >>> _has_surrogates('\ud800\ud800\udc00') # invalid sequence (lone high, valid high+low) >>> _has_surrogates('\udc00\ud800\ud800\udc00') # invalid sequence (lone low, lone high, valid high+low) <_sre.SRE_Match object at 0x9ae0028> FWIW this was introduced in email.message in 1a041f364916 and then moved to email.util in 9388c671d52d. ---------- keywords: +patch nosy: +ezio.melotti Added file: http://bugs.python.org/file27201/issue11454.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 06:29:06 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 16 Sep 2012 04:29:06 +0000 Subject: [issue11454] email.message import time In-Reply-To: <1299701237.24.0.992920521308.issue11454@psf.upfronthosting.co.za> Message-ID: <1347769746.41.0.701575933884.issue11454@psf.upfronthosting.co.za> R. David Murray added the comment: It detects whether a string contains any characters have been surrogate escaped by the surrogate escape handler. I disliked using it, but I didn't know of any better way to do that detection. It's on my long list of things to come back to eventually and try to improve :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 06:42:05 2012 From: report at bugs.python.org (Thomas Lee) Date: Sun, 16 Sep 2012 04:42:05 +0000 Subject: [issue15893] Py_FrozenMain() resource leak and missing malloc checks In-Reply-To: <1347228598.43.0.424519630485.issue15893@psf.upfronthosting.co.za> Message-ID: <1347770525.35.0.860088857082.issue15893@psf.upfronthosting.co.za> Thomas Lee added the comment: Patch against hg tip attached. ---------- keywords: +patch nosy: +thomaslee Added file: http://bugs.python.org/file27202/issue-15893-01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 06:44:47 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 16 Sep 2012 04:44:47 +0000 Subject: [issue15949] docs.python.org not getting updated In-Reply-To: <1347728419.57.0.753818975668.issue15949@psf.upfronthosting.co.za> Message-ID: <1347770687.3.0.165663082003.issue15949@psf.upfronthosting.co.za> Ezio Melotti added the comment: http://docs.python.org/dev/py3k/reference/datamodel.html says "Last updated on Sep 11, 2012". ---------- nosy: +ezio.melotti, georg.brandl type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 07:28:07 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 16 Sep 2012 05:28:07 +0000 Subject: [issue11454] email.message import time In-Reply-To: <1299701237.24.0.992920521308.issue11454@psf.upfronthosting.co.za> Message-ID: <1347773287.07.0.254860780321.issue11454@psf.upfronthosting.co.za> Ezio Melotti added the comment: Given that high surrogates are U+D800..U+DBFF, and low ones are U+DC00..U+DFFF, '([^\ud800-\udbff]|\A)[\udc00-\udfff]([^\udc00-\udfff]|\Z)' means "a low surrogates, preceded by either an high one or line beginning, and followed by another low one or line end". PEP 838 says "With this PEP, non-decodable bytes >= 128 will be represented as lone surrogate codes U+DC80..U+DCFF". If I change the regex to _has_surrogates = re.compile('[\udc80-\udcff]').search, the tests still pass but there's no improvement on startup time (note: the previous regex was matching all the surrogates in this range too, however I'm not sure how well this is tested). If I change the implementation with _pep383_surrogates = set(map(chr, range(0xDC80, 0xDCFF+1))) def _has_surrogates(s): return any(c in _pep383_surrogates for c in s) the tests still pass and the startup is ~15ms faster here: $ time ./python -m issue11454_imp2 [68837 refs] real 0m0.305s user 0m0.288s sys 0m0.012s However using this function instead of the regex is ~10x slower at runtime. Using the shorter regex is about ~7x faster, but there are no improvements on the startup time. Assuming the shorter regex is correct, it can still be called inside a function or used with functools.partial. This will result in a improved startup time and a ~2x improvement on runtime (so it's a win-win). See attached patch for benchmarks. This is a sample result: 17.01 usec/pass <- re.compile(current_regex).search 2.20 usec/pass <- re.compile(short_regex).search 148.18 usec/pass <- return any(c in surrogates for c in s) 106.35 usec/pass <- for c in s: if c in surrogates: return True 8.40 usec/pass <- return re.search(short_regex, s) 8.20 usec/pass <- functools.partial(re.search, short_regex) ---------- Added file: http://bugs.python.org/file27203/issue11454_surr1.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 10:29:46 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 16 Sep 2012 08:29:46 +0000 Subject: [issue13886] readline-related test_builtin failure In-Reply-To: <1327659819.71.0.475160045664.issue13886@psf.upfronthosting.co.za> Message-ID: <1347784186.98.0.145993097828.issue13886@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 10:30:19 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 16 Sep 2012 08:30:19 +0000 Subject: [issue13888] test_builtin failure when run after test_tk In-Reply-To: <1327661656.8.0.445863136974.issue13888@psf.upfronthosting.co.za> Message-ID: <1347784219.02.0.0503403023444.issue13888@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 12:15:16 2012 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Sun, 16 Sep 2012 10:15:16 +0000 Subject: [issue15950] open() should not accept bool argument Message-ID: <1347790516.11.0.86834770042.issue15950@psf.upfronthosting.co.za> New submission from Lars Gust?bel: Today I accidentally did this: open(True).read() Passing True as a file argument to open() does not fail, because a bool value is treated like an integer file descriptor (stdout in this case). Even worse is that the read() call hangs in an endless loop on my linux box. On windows I get an EBADF at least. Wouldn't it be better if open() checked explicitly for a bool argument and raises a TypeError? ---------- components: IO messages: 170550 nosy: lars.gustaebel priority: normal severity: normal status: open title: open() should not accept bool argument type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 13:55:56 2012 From: report at bugs.python.org (Aleksey Sivokon) Date: Sun, 16 Sep 2012 11:55:56 +0000 Subject: [issue15951] string.Formatter returns str for empty unicode template Message-ID: <1347796556.49.0.9624827569.issue15951@psf.upfronthosting.co.za> New submission from Aleksey Sivokon: Expected behavior of string.Formatter() is to return unicode strings for unicode templates, and "byte" strings for str templates. Which is exactly what it does, with one frustrating exception: for empty unicode string it returns byte str. Test follows: import string template = u"" result = string.Formatter().format(template) assert isinstance(result, unicode) # AssertionError ---------- components: Library (Lib) messages: 170551 nosy: Aleksey.Sivokon priority: normal severity: normal status: open title: string.Formatter returns str for empty unicode template type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 15:17:04 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 16 Sep 2012 13:17:04 +0000 Subject: [issue15951] string.Formatter returns str for empty unicode template In-Reply-To: <1347796556.49.0.9624827569.issue15951@psf.upfronthosting.co.za> Message-ID: <1347801424.85.0.800705291365.issue15951@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Adding failing test. Patch coming next. ---------- keywords: +patch nosy: +cjerdonek stage: -> needs patch Added file: http://bugs.python.org/file27204/issue-15951-test-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 15:31:29 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 16 Sep 2012 13:31:29 +0000 Subject: [issue11454] email.message import time In-Reply-To: <1299701237.24.0.992920521308.issue11454@psf.upfronthosting.co.za> Message-ID: <1347802289.05.0.765192819006.issue11454@psf.upfronthosting.co.za> R. David Murray added the comment: Considering how often that test is done, I would consider the compiled version of the short regex the clear winner based on your numbers. I wonder if we could precompile the regex and load it from a pickle. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 15:35:24 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 16 Sep 2012 13:35:24 +0000 Subject: [issue15950] open() should not accept bool argument In-Reply-To: <1347790516.11.0.86834770042.issue15950@psf.upfronthosting.co.za> Message-ID: <1347802524.3.0.9257349946.issue15950@psf.upfronthosting.co.za> R. David Murray added the comment: I don't think so. We don't try to protect people from all their mistakes, and a file descriptor of 1 is valid, and True == 1. ---------- nosy: +r.david.murray resolution: -> wont fix stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 15:55:30 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 16 Sep 2012 13:55:30 +0000 Subject: [issue15951] string.Formatter returns str for empty unicode template In-Reply-To: <1347796556.49.0.9624827569.issue15951@psf.upfronthosting.co.za> Message-ID: <1347803730.9.0.312218895827.issue15951@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Here are some related failing cases that I found: >>> f = string.Formatter() >>> f.format(u"{0}", "") '' >>> f.format(u"{0}", 1) '1' >>> f.format(u"{0}", "a") 'a' >>> f.format(u"{0}{1}", "a", "b") 'ab' >>> f.format("{0}", u"a") u'a' Note that PEP 3101 says the following: "In all cases, the type of the format string dominates - that is, the result of the conversion will always result in an object that contains the same representation of characters as the input format string." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 16:16:10 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 16 Sep 2012 14:16:10 +0000 Subject: [issue15925] email.utils.parsedate(), email.utils.parsedate_tz() and email.utils.parsedate_to_datetime() should return None when date cannot be parsed In-Reply-To: <1347410265.94.0.383870526813.issue15925@psf.upfronthosting.co.za> Message-ID: <1347804970.36.0.714522455595.issue15925@psf.upfronthosting.co.za> R. David Murray added the comment: Here is a patch. Georg, this unfortunately represents a regression from 3.2 and should be fixed. ---------- keywords: +patch stage: -> commit review Added file: http://bugs.python.org/file27205/parsedate_invalid.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 16:18:09 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 16 Sep 2012 14:18:09 +0000 Subject: [issue15925] email.utils.parsedate(), email.utils.parsedate_tz() and email.utils.parsedate_to_datetime() should return None when date cannot be parsed In-Reply-To: <1347410265.94.0.383870526813.issue15925@psf.upfronthosting.co.za> Message-ID: <1347805089.3.0.852681993531.issue15925@psf.upfronthosting.co.za> R. David Murray added the comment: Hmm. Not sure why Georg didn't get auto-added. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 16:20:59 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 16 Sep 2012 14:20:59 +0000 Subject: [issue15925] email.utils.parsedate() and email.utils.parsedate_tz() should return None when date cannot be parsed In-Reply-To: <1347410265.94.0.383870526813.issue15925@psf.upfronthosting.co.za> Message-ID: <1347805259.8.0.659736950012.issue15925@psf.upfronthosting.co.za> R. David Murray added the comment: Oh, and I'm purposely allowing parsedate_to_datetime throw exceptions. I suppose that should be documented, but that's a separate issue. ---------- title: email.utils.parsedate(), email.utils.parsedate_tz() and email.utils.parsedate_to_datetime() should return None when date cannot be parsed -> email.utils.parsedate() and email.utils.parsedate_tz() should return None when date cannot be parsed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 16:32:41 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 16 Sep 2012 14:32:41 +0000 Subject: [issue15951] string.Formatter returns str for empty unicode template In-Reply-To: <1347796556.49.0.9624827569.issue15951@psf.upfronthosting.co.za> Message-ID: <1347805960.99.0.894960379825.issue15951@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Actually, I'm going to defer on creating a patch because this covers more scenarios than I originally thought and so may require more time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 16:55:13 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 16 Sep 2012 14:55:13 +0000 Subject: [issue15951] string.Formatter returns str for empty unicode template In-Reply-To: <1347796556.49.0.9624827569.issue15951@psf.upfronthosting.co.za> Message-ID: <1347807313.88.0.71735185148.issue15951@psf.upfronthosting.co.za> R. David Murray added the comment: Format with unicode is a bit of a mess in 2.7. It would be consistent with the rest of python2 for >>> f.format("{0}", u"a") u'a' to be correct. See also issue 7300 and issue 15276. ---------- nosy: +eric.smith, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 19:14:16 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 16 Sep 2012 17:14:16 +0000 Subject: [issue5057] Unicode-width dependent optimization leads to non-portable pyc file In-Reply-To: <1232900172.29.0.659028766072.issue5057@psf.upfronthosting.co.za> Message-ID: <1347815656.15.0.990885883793.issue5057@psf.upfronthosting.co.za> STINNER Victor added the comment: I prefer option (1), remove the buggy optimization. Python 3.3 does solve correctly this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 20:27:10 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 16 Sep 2012 18:27:10 +0000 Subject: [issue15951] string.Formatter returns str for empty unicode template In-Reply-To: <1347796556.49.0.9624827569.issue15951@psf.upfronthosting.co.za> Message-ID: <1347820030.38.0.215790837971.issue15951@psf.upfronthosting.co.za> Chris Jerdonek added the comment: What about cases like this? >>> f.format(u'{0}', '\xe9') '\xe9' It seems fixing this issue for non-empty strings would cause formerly running cases like this to raise UnicodeDecodeError. >>> unicode('\xe9') ... UnicodeDecodeError: 'ascii' codec can't decode byte 0xe9 in position 0: ordinal not in range(128) Would that be acceptable? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 20:32:32 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 16 Sep 2012 18:32:32 +0000 Subject: [issue15695] Correct __sizeof__ support for StgDict In-Reply-To: <1345144416.71.0.984691068113.issue15695@psf.upfronthosting.co.za> Message-ID: <1347820352.48.0.1539579447.issue15695@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I don't know where StgDict used. Probably need to provide the correct __sizeof__ method for a mapping proxy behind which StgDict hidden. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 20:35:01 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 16 Sep 2012 18:35:01 +0000 Subject: [issue15475] Correct __sizeof__ support for itertools In-Reply-To: <1343418242.58.0.256146467281.issue15475@psf.upfronthosting.co.za> Message-ID: <1347820501.44.0.496383783523.issue15475@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Are there any objections? ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 20:40:01 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 16 Sep 2012 18:40:01 +0000 Subject: [issue15490] Correct __sizeof__ support for StringIO In-Reply-To: <1343591617.54.0.289047671129.issue15490@psf.upfronthosting.co.za> Message-ID: <1347820801.66.0.583986978783.issue15490@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It would be good if someone looked at the patches. I'm not sure that they are good enough. Perhaps they are too complicated and we shouldn't worry about duplicates? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 20:41:24 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 16 Sep 2012 18:41:24 +0000 Subject: [issue15796] Fix readline() docstrings In-Reply-To: <1346107437.01.0.760856446484.issue15796@psf.upfronthosting.co.za> Message-ID: <1347820884.48.0.442809504771.issue15796@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 20:43:26 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 16 Sep 2012 18:43:26 +0000 Subject: [issue15379] Charmap decoding of no-BMP characters In-Reply-To: <1342512958.35.0.341191772548.issue15379@psf.upfronthosting.co.za> Message-ID: <1347821006.72.0.800140420845.issue15379@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 20:47:02 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 16 Sep 2012 18:47:02 +0000 Subject: [issue15144] Possible integer overflow in operations with addresses and sizes. In-Reply-To: <1340395368.97.0.504662983992.issue15144@psf.upfronthosting.co.za> Message-ID: <1347821222.54.0.45224905513.issue15144@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Please, Mark or some other C expert, can you do a code review for the patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 20:52:09 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 16 Sep 2012 18:52:09 +0000 Subject: [issue15490] Correct __sizeof__ support for StringIO In-Reply-To: <1343591617.54.0.289047671129.issue15490@psf.upfronthosting.co.za> Message-ID: <1347821529.0.0.219140270563.issue15490@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, I do think that it's not very important to make __sizeof__ strictly exact according to some specification. I'm also not sure we want to complicate maintenance when the calculation becomes tedious or difficult. To me __sizeof__ is mostly an educational tool which gives a hint at the memory impact of an object, but cannot really convey a precise information except for trivial atomic types. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 21:06:11 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 16 Sep 2012 19:06:11 +0000 Subject: [issue15276] unicode format does not really work in Python 2.x In-Reply-To: <1341668447.61.0.319523039673.issue15276@psf.upfronthosting.co.za> Message-ID: <1347822371.09.0.359032332234.issue15276@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I can't yet reproduce on my system, but after looking at the code, I believe the following are closer to the cause: >>> format(10000, u'n') >>> int.__format__(10000, u'n') Incidentally, on my system, the following note in the docs is wrong: "Note: format(value, format_spec) merely calls value.__format__(format_spec)." (from http://docs.python.org/library/functions.html?#format ) >>> format(10000, u'n') u'10000' >>> 10000.__format__(u'n') File "", line 1 10000.__format__(u'n') ^ SyntaxError: invalid syntax >>> int.__format__(10000, u'n') '10000' Observe also that format() and int.__format__() return different types. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 21:13:09 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 16 Sep 2012 19:13:09 +0000 Subject: [issue15951] string.Formatter returns str for empty unicode template In-Reply-To: <1347796556.49.0.9624827569.issue15951@psf.upfronthosting.co.za> Message-ID: <1347822789.03.0.873764600812.issue15951@psf.upfronthosting.co.za> R. David Murray added the comment: Note that I didn't say it was correct, I just said it was consistent :) And no, breaking stuff that current works is a non-starter for 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 21:19:36 2012 From: report at bugs.python.org (Eric V. Smith) Date: Sun, 16 Sep 2012 19:19:36 +0000 Subject: [issue15276] unicode format does not really work in Python 2.x In-Reply-To: <1341668447.61.0.319523039673.issue15276@psf.upfronthosting.co.za> Message-ID: <1347823176.8.0.893087675186.issue15276@psf.upfronthosting.co.za> Eric V. Smith added the comment: The case with 10000.__format__ is confusing the parser. It sees: __format__ which is indeed a syntax error. Try: >>> 10000 .__format__(u'n') '10000' or: >>> (10000).__format__(u'n') '10000' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 21:26:37 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 16 Sep 2012 19:26:37 +0000 Subject: [issue15276] unicode format does not really work in Python 2.x In-Reply-To: <1341668447.61.0.319523039673.issue15276@psf.upfronthosting.co.za> Message-ID: <1347823597.06.0.161003511191.issue15276@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > The case with 10000.__format__ is confusing the parser. Interesting, good catch! That error did seem unusual. The two modified forms do give the same result as int.__format__() (though the type still differs). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 21:32:13 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 16 Sep 2012 19:32:13 +0000 Subject: [issue5057] Unicode-width dependent optimization leads to non-portable pyc file In-Reply-To: <1232900172.29.0.659028766072.issue5057@psf.upfronthosting.co.za> Message-ID: <1347823933.96.0.176171238262.issue5057@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 21:33:02 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 16 Sep 2012 19:33:02 +0000 Subject: [issue15276] unicode format does not really work in Python 2.x In-Reply-To: <1341668447.61.0.319523039673.issue15276@psf.upfronthosting.co.za> Message-ID: <1347823982.25.0.414550075746.issue15276@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 21:54:43 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 16 Sep 2012 19:54:43 +0000 Subject: [issue15475] Correct __sizeof__ support for itertools In-Reply-To: <1343418242.58.0.256146467281.issue15475@psf.upfronthosting.co.za> Message-ID: <1347825283.88.0.207349465235.issue15475@psf.upfronthosting.co.za> Georg Brandl added the comment: Certainly not for 3.3.0. I'm also not sure this counts as a bugfix in any case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 21:59:51 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 16 Sep 2012 19:59:51 +0000 Subject: [issue15952] format(value) and value.__format__() behave differently with unicode format Message-ID: <1347825591.49.0.625826586182.issue15952@psf.upfronthosting.co.za> New submission from Chris Jerdonek: format(value) and value.__format__() behave differently even though the documentation says otherwise: "Note: format(value, format_spec) merely calls value.__format__(format_spec)." (from http://docs.python.org/library/functions.html?#format ) The difference happens when the format string is unicode. For example: >>> format(10, u'n') u'10' >>> (10).__format__(u'n') # parentheses needed to prevent SyntaxError '10' So either the documentation should be changed, or the behavior should be changed to match. Related to this: neither the "Format Specification Mini-Language" documentation nor the string.Formatter docs seem to say anything about the effect that a unicode format string should have on the return value (in particular, should it cause the return value to be unicode or not): http://docs.python.org/library/string.html#formatspec http://docs.python.org/library/string.html#string-formatting See also issue 15276 (int formatting), issue 15951 (empty format string), and issue 7300 (unicode arguments). ---------- assignee: docs at python components: Documentation messages: 170575 nosy: cjerdonek, docs at python priority: normal severity: normal status: open title: format(value) and value.__format__() behave differently with unicode format type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 22:01:37 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 16 Sep 2012 20:01:37 +0000 Subject: [issue15952] format(value) and value.__format__() behave differently with unicode format In-Reply-To: <1347825591.49.0.625826586182.issue15952@psf.upfronthosting.co.za> Message-ID: <1347825697.36.0.716755323397.issue15952@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 22:09:41 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 16 Sep 2012 20:09:41 +0000 Subject: [issue15951] string.Formatter returns str for empty unicode template In-Reply-To: <1347796556.49.0.9624827569.issue15951@psf.upfronthosting.co.za> Message-ID: <1347826181.88.0.273090454749.issue15951@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I filed issue 15952 for the behavior difference between format(value) and value.__format__() and the related lack of documentation re: unicode format strings. Given that the expected behavior for the current issue doesn't seem to be documented (aside from PEP 3101, which is probably too late to follow), we should probably agree on what the behavior should be (as well as documenting it) before or while addressing this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 22:12:49 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 16 Sep 2012 20:12:49 +0000 Subject: [issue15475] Correct __sizeof__ support for itertools In-Reply-To: <1347825283.88.0.207349465235.issue15475@psf.upfronthosting.co.za> Message-ID: <201209162312.16320.storchaka@gmail.com> Serhiy Storchaka added the comment: Georg, sorry, I don't understood you. You have no objection to the inclusion of this patch in 3.3.0 or you say that this patch should not be in 3.3.0? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 22:15:39 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 16 Sep 2012 20:15:39 +0000 Subject: [issue15475] Correct __sizeof__ support for itertools In-Reply-To: <1343418242.58.0.256146467281.issue15475@psf.upfronthosting.co.za> Message-ID: <1347826539.76.0.754299345971.issue15475@psf.upfronthosting.co.za> Georg Brandl added the comment: Ah, sorry, that was unclear. I meant "this is certainly not going into 3.3.0." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 23:34:33 2012 From: report at bugs.python.org (Aaron Iles) Date: Sun, 16 Sep 2012 21:34:33 +0000 Subject: [issue15629] Add to regrtest the ability to run Lib and Doc doctests In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1347831273.47.0.0593332065288.issue15629@psf.upfronthosting.co.za> Changes by Aaron Iles : ---------- nosy: +aliles _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 16 23:37:51 2012 From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=) Date: Sun, 16 Sep 2012 21:37:51 +0000 Subject: [issue12029] Catching virtual subclasses in except clauses In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za> Message-ID: <1347831471.25.0.792780606298.issue12029@psf.upfronthosting.co.za> Changes by Andreas St?hrk : ---------- nosy: +Trundle _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 01:23:01 2012 From: report at bugs.python.org (Jean-Paul Calderone) Date: Sun, 16 Sep 2012 23:23:01 +0000 Subject: [issue15945] memoryview + bytes fails In-Reply-To: <1347704879.16.0.744568990947.issue15945@psf.upfronthosting.co.za> Message-ID: <1347837781.51.0.608279562368.issue15945@psf.upfronthosting.co.za> Jean-Paul Calderone added the comment: > What is the expected outcome? memoryviews can't be resized, so this scenario isn't possible: The same as `view.tobytes() + bytes`, but without the extra copy implied by `view.tobytes()`. > Just prepend the empty bytestring if you want to make sure the result is a bytes object: Or I could explicitly convert the memoryview to a bytes object. That strikes me as rather preferable. However, this defeats one use of memoryview, which is to avoid unnecessary copying. So it might be suitable workaround for some cases, but not all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 01:36:39 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 16 Sep 2012 23:36:39 +0000 Subject: [issue15945] memoryview + bytes fails In-Reply-To: <1347837781.51.0.608279562368.issue15945@psf.upfronthosting.co.za> Message-ID: <1347838571.3321.0.camel@localhost.localdomain> Antoine Pitrou added the comment: > Or I could explicitly convert the memoryview to a bytes object. That > strikes me as rather preferable. However, this defeats one use of > memoryview, which is to avoid unnecessary copying. So it might be > suitable workaround for some cases, but not all. Indeed, that's why I think it would be good to fix the bytes.join() method (which is precisely meant to minimize copying and resizing). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 04:02:22 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 17 Sep 2012 02:02:22 +0000 Subject: [issue15276] unicode format does not really work in Python 2.x In-Reply-To: <1341668447.61.0.319523039673.issue15276@psf.upfronthosting.co.za> Message-ID: <1347847342.69.0.862599556531.issue15276@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I did some analysis of this issue. For starters, I could not reproduce this on Mac OS X 10.7.4. I iterated through all available locales, and the separator was ASCII in all cases. Instead, I was able to fake the issue by changing "," to "\xa0" in the following line-- http://hg.python.org/cpython/file/820032281f49/Objects/stringlib/formatter.h#l651 and then reproduce with: >>> u'{:,}'.format(10000) .. UnicodeDecodeError: 'ascii' codec can't decode byte 0xa0 in position 2: ordinal not in range(128) >>> format(10000, u',') .. UnicodeDecodeError: 'ascii' codec can't decode byte 0xa0 in position 2: ordinal not in range(128) However, note this difference (see also issue 15952)-- >>> (10000).__format__(u',') '10\xa0000' The issue seems to be that PyObject_Format() in Objects/abstract.c (which, unlike int__format__() in Objects/intobject.c, does respect whether the format string is unicode or not) calls int__format__() to get the formatted string as a byte string. It then passes this to PyObject_Unicode() to convert to unicode. This in turn calls PyUnicode_FromEncodedObject() with a NULL encoding, which causes that code to use PyUnicode_GetDefaultEncoding() for the encoding (i.e. sys.getdefaultencoding()). The right way to fix this seems to be to make int__format__() return unicode as appropriate, which may mean modifying formatter.h's format_int_or_long_internal() to return unicode -- as well as taking into account the locale encoding when accessing the locale's thousands separator. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 04:24:33 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 17 Sep 2012 02:24:33 +0000 Subject: [issue15629] Add to regrtest the ability to run Lib and Doc doctests In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1347848673.08.0.424034377917.issue15629@psf.upfronthosting.co.za> Changes by Ezio Melotti : Added file: http://bugs.python.org/file27206/issue15629-3.2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 04:37:37 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 17 Sep 2012 02:37:37 +0000 Subject: [issue15920] make howto/regex.rst doctests pass In-Reply-To: <1347365250.51.0.50908200461.issue15920@psf.upfronthosting.co.za> Message-ID: <3XKs1q6YX3zQjP@mail.python.org> Roundup Robot added the comment: New changeset f98f46f7f11b by Ezio Melotti in branch '3.2': #15920: fix doctests in Doc/howto/regex.rst. Patch by Chris Jerdonek. http://hg.python.org/cpython/rev/f98f46f7f11b New changeset ef44e1b740cb by Ezio Melotti in branch 'default': #15920: merge with 3.2. http://hg.python.org/cpython/rev/ef44e1b740cb New changeset 19601d451d4c by Ezio Melotti in branch '2.7': #15920: fix doctests in Doc/howto/regex.rst. Patch by Chris Jerdonek. http://hg.python.org/cpython/rev/19601d451d4c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 04:38:16 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 17 Sep 2012 02:38:16 +0000 Subject: [issue15920] make howto/regex.rst doctests pass In-Reply-To: <1347365250.51.0.50908200461.issue15920@psf.upfronthosting.co.za> Message-ID: <1347849496.42.0.534988399203.issue15920@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 08:09:21 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 17 Sep 2012 06:09:21 +0000 Subject: [issue15629] Add to regrtest the ability to run Lib and Doc doctests In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1347862161.91.0.361098434771.issue15629@psf.upfronthosting.co.za> Ezio Melotti added the comment: We discussed about this on IRC, and I'll try to summarize the outcomes. If we want devs to run doctests, the syntax should be as simple as possible, ideally there shouldn't be any extra syntax -- at least for the common case. Note that there are two kind of doctests: * the ones in the *.rst files in the Doc dir; * the ones in the docstrings of the *.py files in the Lib dir; Some of the use cases are: 1) being able to run all the doctests at once; 2) being able to run individual doctests files; 3) being able to discover/run doctests in a specified dir; The use case 1) likely needs an extra flag (e.g. --docall), and could be done by default with -uall. The use case 2) can be already done with `./python -m doctest path/to/doctest.rst`, but, if doctest support is added to regrtest, it would be nice to have this too. The following issues were discussed: * should regrtest accept them with no extra syntax (e.g. `./python -m test path/to/doctest.rst` -- this would be nice but probably tricky/hackish) or should they marked somehow (e.g. `fdoc:path/to/doctest.rst`, or `--doctests path/to/doctest1.rst path/to/doctest2.rst`)? * should we use paths (e.g. Doc/library/textwrap.rst -- easier) or dotted names (e.g. Doc.library.textwrap -- more consistent with unittests)? * should we require the full path/name, or just the filename like we do with regular unittests (e.g. `-m test test_textwrap`)? * should we use the fact that Doc/Lib or rst/py are in the name to distinguish the doctests, or can we search for the name in Lib/test/ first, and fallback on Doc/ and Lib/ if it's not there? The use case 3) is less common, it can be provided with an additional flag but it's not strictly necessary IMHO (might be handy when we want to run all the doctests in a package). Other issues that we haven't discussed are: * it would be nice to have something like run_doctests(['path/to/doctest.rst', 'path/to/module.py']) to be added in the test_module and be called automatically by `-m test test_module`; * which way should be used to mark the files/snippets as doctest-compatible; * how to have a doctest equivalent to setUp/tearDown (this is optional, we can always skip the test if it fails without initialization); (FTR: I was trying the patch on 3.2 and since there were a few conflicts I uploaded the resulting patch in case anyone needs it -- this doesn't mean it should go on 3.2 though.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 08:12:02 2012 From: report at bugs.python.org (Mike Hoy) Date: Mon, 17 Sep 2012 06:12:02 +0000 Subject: [issue11643] Use |version| instead of X.Y in the doc In-Reply-To: <1300838111.66.0.617899175478.issue11643@psf.upfronthosting.co.za> Message-ID: <1347862322.15.0.966035974257.issue11643@psf.upfronthosting.co.za> Changes by Mike Hoy : ---------- nosy: +mikehoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 08:21:40 2012 From: report at bugs.python.org (Mike Hoy) Date: Mon, 17 Sep 2012 06:21:40 +0000 Subject: [issue11643] Use |version| instead of X.Y in the doc In-Reply-To: <1300838111.66.0.617899175478.issue11643@psf.upfronthosting.co.za> Message-ID: <1347862900.35.0.457184497411.issue11643@psf.upfronthosting.co.za> Mike Hoy added the comment: So we could fix this in reverse? Remove the |version| and replace them with X.Y since |version| doesn't expand within :file:? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 08:22:07 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 17 Sep 2012 06:22:07 +0000 Subject: [issue15276] unicode format does not really work in Python 2.x In-Reply-To: <1341668447.61.0.319523039673.issue15276@psf.upfronthosting.co.za> Message-ID: <1347862927.66.0.700416644802.issue15276@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Eric, it looks like you wrote this comment: /* don't define FORMAT_LONG, FORMAT_FLOAT, and FORMAT_COMPLEX, since we can live with only the string versions of those. The builtin format() will convert them to unicode. */ in http://hg.python.org/cpython/file/19601d451d4c/Python/formatter_unicode.c It seems like the current issue may be a valid reason for introducing a unicode FORMAT_INT (i.e. not just for type-purity and PEP 3101 compliance, but to avoid an exception). What do you think? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 08:26:11 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 17 Sep 2012 06:26:11 +0000 Subject: [issue15952] format(value) and value.__format__() behave differently with unicode format In-Reply-To: <1347825591.49.0.625826586182.issue15952@psf.upfronthosting.co.za> Message-ID: <1347863171.14.0.406711320106.issue15952@psf.upfronthosting.co.za> Chris Jerdonek added the comment: See this code comment: /* don't define FORMAT_LONG, FORMAT_FLOAT, and FORMAT_COMPLEX, since we can live with only the string versions of those. The builtin format() will convert them to unicode. */ from http://hg.python.org/cpython/file/19601d451d4c/Python/formatter_unicode.c In other words, it was deliberate not to make value.__format__(format_spec) return unicode when format_spec is unicode. So the docs should be adjusted to say that they are not always the same. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 08:28:15 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 17 Sep 2012 06:28:15 +0000 Subject: [issue15419] distutils: build should use a version-specific build directory In-Reply-To: <1342945976.47.0.537572255215.issue15419@psf.upfronthosting.co.za> Message-ID: <1347863295.42.0.312950352292.issue15419@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I don't think this is a bugfix, but a new feature and as such the behavior should only be changed for 3.4. The easiest workaround for this issue is to use setuptools or distribute when installing, as those tools do set the various build directories to version-specific values. ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 09:01:12 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 17 Sep 2012 07:01:12 +0000 Subject: [issue11643] Use |version| instead of X.Y in the doc In-Reply-To: <1300838111.66.0.617899175478.issue11643@psf.upfronthosting.co.za> Message-ID: <3XKysz4Dc9zNyd@mail.python.org> Roundup Robot added the comment: New changeset de6976fe19aa by Ezio Melotti in branch '2.7': #11643: fix rst markup error in site.rst. http://hg.python.org/cpython/rev/de6976fe19aa New changeset 7aca2781c381 by Ezio Melotti in branch '3.2': #11643: fix rst markup error in site.rst. http://hg.python.org/cpython/rev/7aca2781c381 New changeset c6892ce7e56f by Ezio Melotti in branch 'default': #11643: merge with 3.2. http://hg.python.org/cpython/rev/c6892ce7e56f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 09:03:51 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 17 Sep 2012 07:03:51 +0000 Subject: [issue11643] Use |version| instead of X.Y in the doc In-Reply-To: <1300838111.66.0.617899175478.issue11643@psf.upfronthosting.co.za> Message-ID: <1347865431.64.0.333129285419.issue11643@psf.upfronthosting.co.za> Ezio Melotti added the comment: I fixed the one in site.py. If there's no way to use |version| in :file:`...` I think using {X.Y} is OK, so that can be done where a bare X.Y (without {}) is currently used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 11:13:44 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 17 Sep 2012 09:13:44 +0000 Subject: [issue15953] Incorrect some fields declaration in the PyTypeObject documentation Message-ID: <1347873224.57.0.93636410461.issue15953@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: The declaration of some fields in the PyTypeObject documentation does not match the sources. Here is a patch that fixes the mismatch. ---------- assignee: docs at python components: Documentation files: doc_newtypes.patch keywords: easy, patch messages: 170591 nosy: docs at python, storchaka priority: normal severity: normal status: open title: Incorrect some fields declaration in the PyTypeObject documentation versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file27207/doc_newtypes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 12:14:34 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 17 Sep 2012 10:14:34 +0000 Subject: [issue15954] No error checking after using of the wcsxfrm() Message-ID: <1347876874.21.0.668678433738.issue15954@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: The wcsxfrm() function may fail but there is no error check code. I don't know what exception type should be used here: OSError with an errno EINVAL or some specialized type. I can't prepare tests, because I don't know under what conditions it would be possible error, and whether we can get it on any system at all without broking some internal unicode object invariants. ---------- components: Library (Lib), Windows messages: 170592 nosy: loewis, storchaka priority: low severity: normal status: open title: No error checking after using of the wcsxfrm() type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 12:22:32 2012 From: report at bugs.python.org (Christian Heimes) Date: Mon, 17 Sep 2012 10:22:32 +0000 Subject: [issue15954] No error checking after using of the wcsxfrm() In-Reply-To: <1347876874.21.0.668678433738.issue15954@psf.upfronthosting.co.za> Message-ID: <1347877352.69.0.340731596.issue15954@psf.upfronthosting.co.za> Christian Heimes added the comment: Have you tried code points beyond the BMP? The C function doesn't have a return value that signals an error. An explicit check of errno is required. http://linux.die.net/man/3/wcsxfrm ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 12:23:18 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 17 Sep 2012 10:23:18 +0000 Subject: [issue15921] select module uses uninitialized value "tv.tv_usec" In-Reply-To: <1347367594.05.0.129732037388.issue15921@psf.upfronthosting.co.za> Message-ID: <1347877398.68.0.484894172843.issue15921@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +benj resolution: fixed -> stage: committed/rejected -> patch review status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 12:24:09 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 17 Sep 2012 10:24:09 +0000 Subject: [issue15921] select module uses uninitialized value "tv.tv_usec" In-Reply-To: <1347367594.05.0.129732037388.issue15921@psf.upfronthosting.co.za> Message-ID: <1347877449.48.0.00130891845776.issue15921@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 13:18:29 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 17 Sep 2012 11:18:29 +0000 Subject: [issue15490] Correct __sizeof__ support for StringIO In-Reply-To: <1343591617.54.0.289047671129.issue15490@psf.upfronthosting.co.za> Message-ID: <1347880709.5.0.732473252408.issue15490@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I disagree that sizeof cannot work well for variable-sized types. It works very well for strings, lists, tuple, dicts, and other "regular" containers. I agree that it is not important that it is absolutely correct (in some sense) for every object, but it shouldn't lose "big" chunks of data. A bug where it misses four bytes is much less important than a bug where it misses N bytes (for an object-specific value N that can grow indefinitely). As for the specific patch, I don't think any action should be taken before the 3.3 release. I would personally prefer if the computations where done in Py_ssize_t, not PyObject* (i.e. the result of the recursive call should be unwrapped). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 13:40:34 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 17 Sep 2012 11:40:34 +0000 Subject: [issue15954] No error checking after using of the wcsxfrm() In-Reply-To: <1347876874.21.0.668678433738.issue15954@psf.upfronthosting.co.za> Message-ID: <1347882034.44.0.209845515377.issue15954@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a sample patch (to specify the location of the issue). I don't sure OSError is well here. As far as I understand, this function is Windows-specific, so I can't check how it works with code points beyond the BMP or with surrogates. ---------- keywords: +patch Added file: http://bugs.python.org/file27208/wcsxfrm_error_check.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 13:48:50 2012 From: report at bugs.python.org (Christian Heimes) Date: Mon, 17 Sep 2012 11:48:50 +0000 Subject: [issue15954] No error checking after using of the wcsxfrm() In-Reply-To: <1347876874.21.0.668678433738.issue15954@psf.upfronthosting.co.za> Message-ID: <1347882530.27.0.536504030469.issue15954@psf.upfronthosting.co.za> Christian Heimes added the comment: The patch looks good. `s` and `buf` are cleaned up after the exit label. ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 13:58:07 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 17 Sep 2012 11:58:07 +0000 Subject: [issue15922] make howto/urllib2.rst doctests pass In-Reply-To: <1347370103.61.0.784697754485.issue15922@psf.upfronthosting.co.za> Message-ID: <1347883087.93.0.826021213894.issue15922@psf.upfronthosting.co.za> Ezio Melotti added the comment: + >>> try: + ... urllib.request.urlopen(req) + ... except urllib.error.URLError as e: + ... print("Error opening url.") + ... # E.g. "[Errno 8] nodename nor servname provided, or not known" + ... print("Reason:", e.reason) #doctest: +ELLIPSIS + Error opening url. + Reason: ... I think the previous version was clearer, so maybe this should be a skip. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 14:22:42 2012 From: report at bugs.python.org (Christian Heimes) Date: Mon, 17 Sep 2012 12:22:42 +0000 Subject: [issue15955] gzip, bz2, lzma: add method to get decompressed size Message-ID: <1347884562.79.0.801674791772.issue15955@psf.upfronthosting.co.za> New submission from Christian Heimes: The gzip, bz2 and lzma file reader have no method to get the actual size and compression ratio of a compressed file. In my opinion it's useful to know how much disk space a file will need before it's decompressed. ---------- components: Library (Lib) messages: 170598 nosy: christian.heimes, nadeem.vawda priority: normal severity: normal status: open title: gzip, bz2, lzma: add method to get decompressed size type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 14:26:18 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 17 Sep 2012 12:26:18 +0000 Subject: [issue15490] Correct __sizeof__ support for StringIO In-Reply-To: <1343591617.54.0.289047671129.issue15490@psf.upfronthosting.co.za> Message-ID: <1347884778.13.0.815854108199.issue15490@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It can't work well if we count internal Python objects that can be shared. This is because the "work well" concept is not well defined. And because the implementation of a certain defined calculation algorithm can be completely unmaintainable, that is not well. If we wrote in the StringIO the same 1 MB string twice, should the __sizeof__() return about 1)?2 MB, 2) 1 MB or 3)?size of empty stream if there are external links to this shared string? Patch implements the second strategy, it can be simplified to the first one or complicated even more to a third one. Even more complication will need to take into account the sharing of eol string ('\r' and '\n' always shared, '\r\n' may be). > I would personally prefer if the computations where done in Py_ssize_t, not PyObject* I too. But on platforms with 64-bit pointers and 32-bit sizes we can allocate total more than PY_SIZE_MAX bytes (hey, I remember the DOS memory models with 16-bit size_t and 32-bit pointers). Even faster we get an overflow if allow the repeated counting of shared objects. What to do with overflow? Return PY_SIZE_MAX or ignore the possibility of errors? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 14:30:50 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 17 Sep 2012 12:30:50 +0000 Subject: [issue15629] Add to regrtest the ability to run Lib and Doc doctests In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1347885050.5.0.0338961722505.issue15629@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I think I'm -1 to run doctests as part of regrtest. Documentation examples are meant to be read, not executed: it is fine for them to omit unimportant information or trivial boilerplate (such as imports). Any complication in the way doc examples must be written will deter us from actually writing examples. Furthermore, spreading unit tests in the doc files instead of Lib/test files will make maintenance of tests more tedious as well. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 14:35:18 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 17 Sep 2012 12:35:18 +0000 Subject: [issue15954] No error checking after using of the wcsxfrm() In-Reply-To: <1347876874.21.0.668678433738.issue15954@psf.upfronthosting.co.za> Message-ID: <1347885318.78.0.217739906444.issue15954@psf.upfronthosting.co.za> Martin v. L?wis added the comment: > I don't know what exception type should be used here: > OSError with an errno EINVAL or some specialized type. No, I think the appropriate error is ValueError, at least if errno is EINVAL. > because I don't know under what conditions it would be possible error AFAICT, glibc never sets errno. msvcrt gives EILSEQ or ERANGE, but never EINVAL. EILSEQ is returned if LCMapString failed, and ERANE if the output buffer is too small. In either case, the result is INT_MAX. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 14:43:54 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 17 Sep 2012 12:43:54 +0000 Subject: [issue15629] Add to regrtest the ability to run Lib and Doc doctests In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1347885834.34.0.581638279567.issue15629@psf.upfronthosting.co.za> Ezio Melotti added the comment: > Documentation examples are meant to be read, not executed I agree, but several of them already run, and others run with the addition of doctests directives (that are hidden in the html output). If the code needs to be changed in a way that is less readable, the test can just be skipped. > Furthermore, spreading unit tests in the doc files instead of Lib/test > files will make maintenance of tests more tedious as well. Tests should be kept in Lib/test, this is mostly to make sure that the examples are correct. The examples in the docs should still be written with the goal to be clear for the user -- being valid doctests is a secondary goal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 14:46:46 2012 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 17 Sep 2012 12:46:46 +0000 Subject: [issue15952] format(value) and value.__format__() behave differently with unicode format In-Reply-To: <1347825591.49.0.625826586182.issue15952@psf.upfronthosting.co.za> Message-ID: <1347886006.27.0.52984034566.issue15952@psf.upfronthosting.co.za> Eric V. Smith added the comment: I believe the conversion is happening in Objects/abstract.c in PyObject_Format, around line 864, near this comment: /* Convert to unicode, if needed. Required if spec is unicode and result is str */ I think changing the docs will result in more confusion than clarity, but if you can come up with some good wording, I'd be okay with it. I think changing the code will likely break things with little or no benefit. ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 14:51:15 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 17 Sep 2012 12:51:15 +0000 Subject: [issue15490] Correct __sizeof__ support for StringIO In-Reply-To: <1347884778.13.0.815854108199.issue15490@psf.upfronthosting.co.za> Message-ID: <50571CBF.6070503@v.loewis.de> Martin v. L?wis added the comment: Am 17.09.2012 14:26, schrieb Serhiy Storchaka: >> I would personally prefer if the computations where done in >> Py_ssize_t, not PyObject* > > I too. But on platforms with 64-bit pointers and 32-bit sizes we can > allocate total more than PY_SIZE_MAX bytes (hey, I remember the DOS > memory models with 16-bit size_t and 32-bit pointers). Even faster we > get an overflow if allow the repeated counting of shared objects. > What to do with overflow? Return PY_SIZE_MAX or ignore the > possibility of errors? It can never overflow. We cannot allocate more memory than SIZE_MAX; this is (mostly) guaranteed by the C standard. I don't know whether you deliberately brought up the obscure case of 64-bit pointers and 32-bit sizes. If there are such systems, we don't support them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 15:33:47 2012 From: report at bugs.python.org (Steve Newcomb) Date: Mon, 17 Sep 2012 13:33:47 +0000 Subject: [issue15956] backreference to named group does not work Message-ID: <1347888827.23.0.363134887653.issue15956@psf.upfronthosting.co.za> New submission from Steve Newcomb: The '\\g' in the below does not work: >>> repr( re.compile( '\\<\\!ENTITY[ \\011\\012\\015]+\\%[ \\011\\012\\015]*(?P[A-Za-z][A-Za-z0-9\\.\\-\\_\\:]*)[ \\011\\012\\015]*(?P[\\042\\047])(?P.+?)\\g[ \\011\\012\\015]*\\>', re.IGNORECASE | re.DOTALL).search( '')) 'None' In the following, the '\\g' has been replaced by '\\2'. It works. >>> repr( re.compile( '\\<\\!ENTITY[ \\011\\012\\015]+\\%[ \\011\\012\\015]*(?P[A-Za-z][A-Za-z0-9\\.\\-\\_\\:]*)[ \\011\\012\\015]*(?P[\\042\\047])(?P.+?)\\2[ \\011\\012\\015]*\\>', re.IGNORECASE | re.DOTALL).search( '')) '<_sre.SRE_Match object at 0x7f77503d1918>' Either this feature is broken or the re module documentation is somehow misleading me. (Yes, I know there is an XML error in the above. That's because it's SGML.) ---------- components: Regular Expressions messages: 170605 nosy: ezio.melotti, mrabarnett, steve.newcomb priority: normal severity: normal status: open title: backreference to named group does not work type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 15:48:57 2012 From: report at bugs.python.org (Michael Foord) Date: Mon, 17 Sep 2012 13:48:57 +0000 Subject: [issue11664] Add patch method to unittest.TestCase In-Reply-To: <1300999439.71.0.376555102459.issue11664@psf.upfronthosting.co.za> Message-ID: <1347889737.84.0.630927432331.issue11664@psf.upfronthosting.co.za> Michael Foord added the comment: Why would mock.patch.object be the appropriate one to add to TestCase? patch.object is used orders of magnitude less than patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 15:53:15 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 17 Sep 2012 13:53:15 +0000 Subject: [issue15419] distutils2: build should use a version-specific build directory In-Reply-To: <1342945976.47.0.537572255215.issue15419@psf.upfronthosting.co.za> Message-ID: <1347889995.35.0.449432685058.issue15419@psf.upfronthosting.co.za> ?ric Araujo added the comment: Okay, then it?s distutils2 material. ---------- components: -Distutils title: distutils: build should use a version-specific build directory -> distutils2: build should use a version-specific build directory versions: +3rd party, Python 3.4 -Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 15:54:04 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 17 Sep 2012 13:54:04 +0000 Subject: [issue15419] distutils2: build should use a version-specific build directory In-Reply-To: <1342945976.47.0.537572255215.issue15419@psf.upfronthosting.co.za> Message-ID: <1347890044.08.0.411228123209.issue15419@psf.upfronthosting.co.za> ?ric Araujo added the comment: A doc note for distutils in stable versions could also be added. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 16:06:49 2012 From: report at bugs.python.org (Meador Inge) Date: Mon, 17 Sep 2012 14:06:49 +0000 Subject: [issue15475] Correct __sizeof__ support for itertools In-Reply-To: <1343418242.58.0.256146467281.issue15475@psf.upfronthosting.co.za> Message-ID: <1347890809.54.0.640955329278.issue15475@psf.upfronthosting.co.za> Meador Inge added the comment: Unassigning from myself. I thought I would have more time to review and push this through. ---------- assignee: meador.inge -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 16:13:44 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 17 Sep 2012 14:13:44 +0000 Subject: [issue15956] backreference to named group does not work In-Reply-To: <1347888827.23.0.363134887653.issue15956@psf.upfronthosting.co.za> Message-ID: <1347891224.66.0.115065387605.issue15956@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: \g is meant to be used in re.sub(), in the replacement text (see the docs); in the search pattern, (?P=startquote) can be used to refer to a named group. The docs of "(?P...)" looks clear to me. ---------- nosy: +amaury.forgeotdarc resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 16:20:23 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 17 Sep 2012 14:20:23 +0000 Subject: [issue14616] subprocess docs should mention pipes.quote/shlex.quote In-Reply-To: <1334769157.78.0.557014485739.issue14616@psf.upfronthosting.co.za> Message-ID: <1347891623.15.0.268546894129.issue14616@psf.upfronthosting.co.za> ?ric Araujo added the comment: You thought it was better not to mention that pipes.quote is semi-official and becomes public as shlex.quote in 3.3? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 16:24:50 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 17 Sep 2012 14:24:50 +0000 Subject: [issue15629] Add to regrtest the ability to run Lib and Doc doctests In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1347891890.16.0.117468648987.issue15629@psf.upfronthosting.co.za> R. David Murray added the comment: I've given this some more thought, and I'm leaning toward Antoine's POV here. The point of running the doctests in the docs is not to test python, but to test the docs. Sphinx has a facility to do that: make doctest. So I think it is better to use that doc-specific infrastructure to test the docs. This also allows us to use the full Sphinx facilities to work with those doctests, which includes hiding the not-necessary-for-docs bits. I think we should be moving *away* from having special infrastructure in regrtest. As much stuff as makes sense should be moved to unittest, and we've been slowly doing that. Correspondingly, we should use Sphinx's native test facilities, not add special stuff to regrtest. If Sphinx doesn't have the ability to run individual files, we should add that ability to Sphinx, not regrtest. (Note: I personally do not use the ability recently added to regrtest to select unit tests from the command line, instead I use the unittest CLI directly, and I think that's the better way to do it. IMO regrtest should be focused on running the test *suite*, not on running individual tests.) Once we've refined the docs so that 'make doctest' runs cleanly, we should automate the testing of the docs in some fashion. One way to do that would be to define a test module that handles the interfacing with Sphinx, and is controlled by a resource that is *not* included in -uall, and is then explicitly enabled on certain buildbots. Doctests in module files could be handled the same way: build a test module that does whatever autodiscovery is needed, and control it via a resource not included in -uall. (I am, however, open to the argument that this one should be included in -uall.) Again, there already exists a way to invoke individual files, using the native doctest facilities. So adding hooks to regrtest is not really needed, IMO. Also again, if the doctest CLI is lacking, the improvement should go into doctest. IMO :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 16:38:45 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 17 Sep 2012 14:38:45 +0000 Subject: [issue15629] Add to regrtest the ability to run Lib and Doc doctests In-Reply-To: <1347891890.16.0.117468648987.issue15629@psf.upfronthosting.co.za> Message-ID: <1347892695.3340.7.camel@localhost.localdomain> Antoine Pitrou added the comment: > I think we should be moving *away* from having special infrastructure > in regrtest. As much stuff as makes sense should be moved to > unittest, and we've been slowly doing that. Correspondingly, we > should use Sphinx's native test facilities, not add special stuff to > regrtest. If Sphinx doesn't have the ability to run individual files, > we should add that ability to Sphinx, not regrtest. (Note: I > personally do not use the ability recently added to regrtest to select > unit tests from the command line, instead I use the unittest CLI > directly, and I think that's the better way to do it. IMO regrtest > should be focused on running the test *suite*, not on running > individual tests.) The main reason to add it to regrtest was to allow special test modes with it (such as -R or -F). (and, also, the unittest CLI's poor online help makes it rather unusable for me :-)). But I agree on the principle that unittest should be expanded to better accomodate the needs of regrtest. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 16:42:08 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 17 Sep 2012 14:42:08 +0000 Subject: [issue15629] Add to regrtest the ability to run Lib and Doc doctests In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1347892928.09.0.800311939212.issue15629@psf.upfronthosting.co.za> ?ric Araujo added the comment: RDM?s arguments make a lot of sense. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 16:46:50 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 17 Sep 2012 14:46:50 +0000 Subject: [issue15629] Add to regrtest the ability to run Lib and Doc doctests In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1347893210.76.0.601293219067.issue15629@psf.upfronthosting.co.za> R. David Murray added the comment: We should improve the unittest help, then :) I will also note that the couple of times I tried it I couldn't figure out how to use the regrtest test selection :) What we probably need for regrtest is a way to pass through a "selection string" from the regrtest command line to the unittest test discovery, and then run the selected tests under regrtest control. The same could apply to Sphinx doctests and module doctests. This may require adding APIs to those packages (unittest may already have the necessary API). I think the Sphinx case is the one that will take the most work to accomplish, but I also think it is worth the effort to do that rather than adding CPython-specific stuff to regrtest. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 17:05:58 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Sep 2012 15:05:58 +0000 Subject: [issue15629] Add to regrtest the ability to run Lib and Doc doctests In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za> Message-ID: <1347894358.53.0.729130968149.issue15629@psf.upfronthosting.co.za> Brett Cannon added the comment: I should mention that http://bugs.python.org/issue10967 exists as a meta issue about trying to gut regrtest in favour of using other things in unittest (and doctest in this case) when possible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 17:23:07 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 17 Sep 2012 15:23:07 +0000 Subject: [issue10044] small int optimization In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za> Message-ID: <1347895387.44.0.157668087454.issue10044@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 18:13:21 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 17 Sep 2012 16:13:21 +0000 Subject: [issue10044] small int optimization In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za> Message-ID: <1347898401.28.0.132812748131.issue10044@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Interpreter Core nosy: +storchaka versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 18:59:55 2012 From: report at bugs.python.org (Cliff Dyer) Date: Mon, 17 Sep 2012 16:59:55 +0000 Subject: [issue15957] README.txt points to broken "contributing" url in python wiki Message-ID: <1347901195.54.0.476141478032.issue15957@psf.upfronthosting.co.za> New submission from Cliff Dyer: The README.txt file for distutils2 points to , which raises a 404. The correct URL is . The attached patch fixes this typo. ---------- assignee: docs at python components: Distutils2, Documentation files: broken_link.diff keywords: patch messages: 170617 nosy: alexis, docs at python, jcd, tarek priority: normal severity: normal status: open title: README.txt points to broken "contributing" url in python wiki Added file: http://bugs.python.org/file27209/broken_link.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 20:03:51 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 17 Sep 2012 18:03:51 +0000 Subject: [issue15945] memoryview + bytes fails In-Reply-To: <1347704879.16.0.744568990947.issue15945@psf.upfronthosting.co.za> Message-ID: <1347905031.46.0.0112826903204.issue15945@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Opened issue15958 for the bytes.join enhancement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 20:03:34 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 17 Sep 2012 18:03:34 +0000 Subject: [issue15958] bytes.join() should allow arbitrary buffer objects Message-ID: <1347905010.83.0.632444428638.issue15958@psf.upfronthosting.co.za> New submission from Antoine Pitrou: This should ideally succeed: >>> b''.join([memoryview(b'foo'), b'bar']) Traceback (most recent call last): File "", line 1, in TypeError: sequence item 0: expected bytes, memoryview found (ditto for bytearray.join) ---------- components: Interpreter Core messages: 170618 nosy: pitrou priority: normal severity: normal stage: needs patch status: open title: bytes.join() should allow arbitrary buffer objects type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 20:23:48 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 17 Sep 2012 18:23:48 +0000 Subject: [issue15958] bytes.join() should allow arbitrary buffer objects In-Reply-To: <1347905010.83.0.632444428638.issue15958@psf.upfronthosting.co.za> Message-ID: <1347906228.1.0.190097252889.issue15958@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 21:09:26 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 17 Sep 2012 19:09:26 +0000 Subject: [issue15144] Possible integer overflow in operations with addresses and sizes. In-Reply-To: <1340395368.97.0.504662983992.issue15144@psf.upfronthosting.co.za> Message-ID: <1347908966.88.0.573674861316.issue15144@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Perhaps the three new macros should be made available in a .h file? (in which case they should be private, i.e. start with _). ---------- type: security -> behavior versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 21:52:36 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 17 Sep 2012 19:52:36 +0000 Subject: [issue15959] Declaration mismatch of quick integer allocation counters Message-ID: <1347911556.54.0.0253156044834.issue15959@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: In Objects/longobject.c quick_int_allocs and quick_neg_int_allocs defined as int but in Objects/object.c they are declared and used as Py_ssize_t. Here is a patch that fixes this mismatch. See also issue4850. ---------- components: Interpreter Core files: quick_int_allocs.patch keywords: patch messages: 170621 nosy: loewis, storchaka priority: normal severity: normal status: open title: Declaration mismatch of quick integer allocation counters type: resource usage versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file27210/quick_int_allocs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 22:00:18 2012 From: report at bugs.python.org (Christian Heimes) Date: Mon, 17 Sep 2012 20:00:18 +0000 Subject: [issue15959] Declaration mismatch of quick integer allocation counters In-Reply-To: <1347911556.54.0.0253156044834.issue15959@psf.upfronthosting.co.za> Message-ID: <1347912018.39.0.902944910768.issue15959@psf.upfronthosting.co.za> Christian Heimes added the comment: The patch looks good. IMO it can safely be applied as it fixes a rarely used debug feature. ---------- nosy: +christian.heimes stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 22:09:53 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 17 Sep 2012 20:09:53 +0000 Subject: [issue15144] Possible integer overflow in operations with addresses and sizes. In-Reply-To: <1347908966.88.0.573674861316.issue15144@psf.upfronthosting.co.za> Message-ID: <201209172309.37988.storchaka@gmail.com> Serhiy Storchaka added the comment: > Perhaps the three new macros should be made available in a .h file? > (in which case they should be private, i.e. start with _). Perhaps. There are similar macros in other files (Include/objimpl.h, Objects/obmalloc.c, Python/pyarena.c, Modules/expat/xmlparse.c). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 22:17:09 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 17 Sep 2012 20:17:09 +0000 Subject: [issue15903] Make rawiobase_read() read directly to bytes object In-Reply-To: <1347279783.86.0.217898740398.issue15903@psf.upfronthosting.co.za> Message-ID: <1347913029.92.0.0701048960723.issue15903@psf.upfronthosting.co.za> Richard Oudkerk added the comment: New patch which checks the refcount of the memoryview and bytes object after calling readinto(). If either refcount is larger than the expected value of 1, then the data is copied rather than resized. ---------- Added file: http://bugs.python.org/file27211/iobase_read.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 22:19:55 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 17 Sep 2012 20:19:55 +0000 Subject: [issue15950] open() should not accept bool argument In-Reply-To: <1347790516.11.0.86834770042.issue15950@psf.upfronthosting.co.za> Message-ID: <1347913195.93.0.320874242251.issue15950@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 22:40:07 2012 From: report at bugs.python.org (Daniel Wagner-Hall) Date: Mon, 17 Sep 2012 20:40:07 +0000 Subject: [issue15836] unittest assertRaises should verify excClass is actually a BaseException class In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za> Message-ID: <1347914407.16.0.759915744423.issue15836@psf.upfronthosting.co.za> Daniel Wagner-Hall added the comment: Is anything blocking this patch's submission? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 22:47:16 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 17 Sep 2012 20:47:16 +0000 Subject: [issue15925] email.utils.parsedate() and email.utils.parsedate_tz() should return None when date cannot be parsed In-Reply-To: <1347410265.94.0.383870526813.issue15925@psf.upfronthosting.co.za> Message-ID: <1347914836.0.0.559071640102.issue15925@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: I think that email.utils.parsedate_to_datetime("0") should raise ValueError instead of TypeError. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 17 22:59:07 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 17 Sep 2012 20:59:07 +0000 Subject: [issue15903] Make rawiobase_read() read directly to bytes object In-Reply-To: <1347279783.86.0.217898740398.issue15903@psf.upfronthosting.co.za> Message-ID: <1347915547.35.0.00449863034975.issue15903@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +IO, Library (Lib) type: -> performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 00:30:22 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 17 Sep 2012 22:30:22 +0000 Subject: [issue15903] Make rawiobase_read() read directly to bytes object In-Reply-To: <1347279783.86.0.217898740398.issue15903@psf.upfronthosting.co.za> Message-ID: <1347921022.93.0.243323838795.issue15903@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > If either refcount is larger than the expected value of 1, then the > data is copied rather than resized. I think that's a useless precaution. The bytes object cannot "leak" since you are using PyMemoryView_FromMemory(), which doesn't know about the original object. Out of curiousity, have you done any benchmarks? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 01:05:17 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 17 Sep 2012 23:05:17 +0000 Subject: [issue15903] Make rawiobase_read() read directly to bytes object In-Reply-To: <1347279783.86.0.217898740398.issue15903@psf.upfronthosting.co.za> Message-ID: <1347923117.17.0.575227760931.issue15903@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > I think that's a useless precaution. The bytes object cannot "leak" > since you are using PyMemoryView_FromMemory(), which doesn't know about > the original object. The bytes object cannot "leak" so, as you say, checking that refcount is pointless. But the view might "leak", and since it does not own a reference to the base object we have a problem: we can't deallocate the bytes object for fear of breaking the view. It looks like objects returned by PyMemoryView_FromMemory() must never be allowed to "leak", so I am not sure there are many circumstances in which PyMemoryView_FromMemory() is safe to use. Perhaps using PyBuffer_FillInfo() and PyMemory_FromBuffer() would keep alive the bytes object while the view is alive, without letting the bytes object "leak". > Out of curiousity, have you done any benchmarks? No. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 01:14:47 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 17 Sep 2012 23:14:47 +0000 Subject: [issue15903] Make rawiobase_read() read directly to bytes object In-Reply-To: <1347279783.86.0.217898740398.issue15903@psf.upfronthosting.co.za> Message-ID: <1347923687.67.0.596836727774.issue15903@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > The bytes object cannot "leak" so, as you say, checking that refcount > is pointless. But the view might "leak", and since it does not own a > reference to the base object we have a problem: we can't deallocate the > bytes object for fear of breaking the view. Indeed, that's a problem (but your patch does deallocate the bytes object). It's quite fishy, I'm not sure how to solve the issue cleanly. Stefan, do you have an idea? ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 01:21:40 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 17 Sep 2012 23:21:40 +0000 Subject: [issue8542] Another test issue In-Reply-To: <1272314000.64.0.308936581064.issue8542@psf.upfronthosting.co.za> Message-ID: <1347924100.97.0.721741127519.issue8542@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 01:27:58 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 17 Sep 2012 23:27:58 +0000 Subject: [issue12849] Cannot override 'connection: close' in urllib2 headers In-Reply-To: <1314559168.55.0.630424901631.issue12849@psf.upfronthosting.co.za> Message-ID: <1347924478.52.0.440630428065.issue12849@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 04:01:14 2012 From: report at bugs.python.org (Steve Newcomb) Date: Tue, 18 Sep 2012 02:01:14 +0000 Subject: [issue15956] backreference to named group does not work In-Reply-To: <1347888827.23.0.363134887653.issue15956@psf.upfronthosting.co.za> Message-ID: <1347933674.59.0.148975415853.issue15956@psf.upfronthosting.co.za> Steve Newcomb added the comment: I have re-read the documentation on re.sub(). Even now, now that I understand that the \g syntax applies to the repl argument only, I cannot see how the documentation can be understood that way. The paragraph in which the explanation of the \g syntax appears does not mention the repl argument by name, and neither does the preceding paragraph. The paragraph before the preceding paragraph is about the pattern argument, not the repl argument, and it consists entirely of the words, "The pattern may be a string or an RE object." So I don't see how the explanation of the \g syntax can be understood as applying only to the repl argument, even though you have now informed me that that's the case (which is helpful to know -- thanks!). Indeed, the paragraph that explains the \g syntax *still* appears to me to be discussing the pattern argument. And it even mentions the syntax, which can only appear in a pattern, not in a repl, in the very same sentence as the \g syntax, even though those two syntactic features appear in *different* expression languages, and no single expression language has both of them. So there is no clear indication that it is discussing two different expression languages. Indeed, another syntactic feature, \groupnumber, also discussed in the same paragraph, *is* found in both expression languages, so it's even more confusing to a person who knows that both and \groupnumber appear in the pattern expression language. There is nothing in the documentation that would inform a person (such as myself) that the \g syntax is not also part of the pattern expression language, just as the other two features are. (And why isn't \g part of the pattern language, anyway, or at least some way to refer to a match made in a previous *named* group? It would be very convenient to be able to do that, particularly when using a dynamically-created regexp to parse strings delimited with a choice of delimiters that must match at both ends.) In other words, this documentation could be beneficially improved. ---------- resolution: invalid -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 05:03:47 2012 From: report at bugs.python.org (Trent Nelson) Date: Tue, 18 Sep 2012 03:03:47 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1347937427.76.0.167170751332.issue15745@psf.upfronthosting.co.za> Trent Nelson added the comment: Just noticed that the Solaris 10 slave is failing in the same way: ====================================================================== FAIL: test_utime (test.test_os.StatAttributeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/cpython/buildslave/3.x.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/test/test_os.py", line 332, in test_utime self._test_utime(support.TESTFN, getattr, utime, 10) File "/home/cpython/buildslave/3.x.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/test/test_os.py", line 318, in _test_utime self.assertEqual(attr(st0, "st_mtime"), attr(st1, "st_mtime")) AssertionError: 1347752941.275297 != 1347752941.275296 Note that /home/cpython on this slave is backed by UFS, not ZFS. (It's accessible to committers via sb->s10.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 05:22:52 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 18 Sep 2012 03:22:52 +0000 Subject: [issue15945] memoryview + bytes fails In-Reply-To: <1347704879.16.0.744568990947.issue15945@psf.upfronthosting.co.za> Message-ID: <1347938572.22.0.421645580053.issue15945@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 05:23:22 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 18 Sep 2012 03:23:22 +0000 Subject: [issue15958] bytes.join() should allow arbitrary buffer objects In-Reply-To: <1347905010.83.0.632444428638.issue15958@psf.upfronthosting.co.za> Message-ID: <1347938602.88.0.730404051038.issue15958@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 06:21:51 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 18 Sep 2012 04:21:51 +0000 Subject: [issue15796] Fix readline() docstrings In-Reply-To: <1346107437.01.0.760856446484.issue15796@psf.upfronthosting.co.za> Message-ID: <3XLWHd5dvQzNjr@mail.python.org> Roundup Robot added the comment: New changeset 210a189544c3 by Ezio Melotti in branch '2.7': #15796: Fix \n in readline docstring. http://hg.python.org/cpython/rev/210a189544c3 New changeset 6386e1f4f1fd by Ezio Melotti in branch '3.2': #15796: Fix \n in readline docstring. Patch by Serhiy Storchaka. http://hg.python.org/cpython/rev/6386e1f4f1fd New changeset 3a880d640981 by Ezio Melotti in branch 'default': #15796: merge with 3.2. http://hg.python.org/cpython/rev/3a880d640981 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 06:22:41 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 18 Sep 2012 04:22:41 +0000 Subject: [issue15796] Fix readline() docstrings In-Reply-To: <1346107437.01.0.760856446484.issue15796@psf.upfronthosting.co.za> Message-ID: <1347942161.5.0.624505876605.issue15796@psf.upfronthosting.co.za> Ezio Melotti added the comment: Pong, thanks for the patch! ---------- assignee: docs at python -> ezio.melotti nosy: +ezio.melotti resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 06:49:07 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 18 Sep 2012 04:49:07 +0000 Subject: [issue4711] Wide literals in the table of contents overflow in documentation In-Reply-To: <1229878552.94.0.178929851509.issue4711@psf.upfronthosting.co.za> Message-ID: <1347943747.19.0.91412312389.issue4711@psf.upfronthosting.co.za> Ezio Melotti added the comment: I experimented a bit more with "text-overflow: ellipsis;" but didn't obtain anything good. With "word-wrap: break-word;" I had better luck, and even if breaking long words might not be the most elegant solution, it looks better than the overflowing text and doesn't hide any content (like text-overflow does). Georg, what do you think? ---------- keywords: +patch stage: needs patch -> patch review versions: +Python 3.3 -Python 2.6, Python 3.1 Added file: http://bugs.python.org/file27212/issue4711.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 06:56:49 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 18 Sep 2012 04:56:49 +0000 Subject: [issue4711] Wide literals in the table of contents overflow in documentation In-Reply-To: <1229878552.94.0.178929851509.issue4711@psf.upfronthosting.co.za> Message-ID: <1347944209.33.0.59373353703.issue4711@psf.upfronthosting.co.za> Changes by Ezio Melotti : Added file: http://bugs.python.org/file27213/issue4711.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 08:59:59 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 18 Sep 2012 06:59:59 +0000 Subject: [issue12075] python3.2 memory leak when reloading class with attributes In-Reply-To: <1305357392.12.0.709817768407.issue12075@psf.upfronthosting.co.za> Message-ID: <1347951599.86.0.0246013613812.issue12075@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 09:40:20 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 18 Sep 2012 07:40:20 +0000 Subject: [issue15960] logging.shutdown should cope with IO errors from handler.release methods Message-ID: <1347954020.8.0.36541508073.issue15960@psf.upfronthosting.co.za> New submission from Nick Coghlan: logging.shutdown includes a try/except block to avoid emitting spurious IO errors while the interpreter is shutting down. This fails if a registered handler tries to do IO (such as calling flush()) in its release method. It would be better if the flush-and-close block was written as: try: hr.acquire() try: hr.flush() hr.close() finally: hr.release() except (IOError, ValueError): # Tolerate handlers that try to do IO in release() ---------- messages: 170635 nosy: ncoghlan priority: normal severity: normal status: open title: logging.shutdown should cope with IO errors from handler.release methods versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 09:41:01 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 18 Sep 2012 07:41:01 +0000 Subject: [issue15960] logging.shutdown should cope with IO errors from handler.release methods In-Reply-To: <1347954020.8.0.36541508073.issue15960@psf.upfronthosting.co.za> Message-ID: <1347954061.27.0.851873091125.issue15960@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- nosy: +vinay.sajip type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 09:42:47 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 18 Sep 2012 07:42:47 +0000 Subject: [issue15956] backreference to named group does not work In-Reply-To: <1347888827.23.0.363134887653.issue15956@psf.upfronthosting.co.za> Message-ID: <1347954167.04.0.574429110649.issue15956@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > And why isn't \g part of the pattern language, anyway, or at > least some way to refer to a match made in a previous *named* group? But this way exists: (?P=startquote) is what you want. To me \g is an exception, and frankly I did not know about it before this bug report. I agree that the following sentence could be better structured: """ For example, if the pattern is (?P[a-zA-Z_]\w*), the group can be referenced by its name in arguments to methods of match objects, such as m.group('id') or m.end('id'), and also by name in the regular expression itself (using (?P=id)) and replacement text given to .sub() (using \g). """ It probably needs to be split into several pieces, contributions are welcome. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 09:53:43 2012 From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=) Date: Tue, 18 Sep 2012 07:53:43 +0000 Subject: [issue8786] Add support for IEEE 754 contexts to decimal module. In-Reply-To: <1274524113.24.0.215320207255.issue8786@psf.upfronthosting.co.za> Message-ID: <1347954823.74.0.475378533369.issue8786@psf.upfronthosting.co.za> Michele Orr? added the comment: Something like this? That's a pretty trivial draft for the patch. About "byte sequences", those features should be available using builtins bin(), oct() and hex(), hacking on __index__, or with internal methods? I am lacking imagination, what else there should be to test? ---------- keywords: +patch nosy: +ezio.melotti, maker Added file: http://bugs.python.org/file27214/issue8786.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 10:33:54 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 18 Sep 2012 08:33:54 +0000 Subject: [issue15903] Make rawiobase_read() read directly to bytes object In-Reply-To: <1347279783.86.0.217898740398.issue15903@psf.upfronthosting.co.za> Message-ID: <1347957234.96.0.969752587733.issue15903@psf.upfronthosting.co.za> Stefan Krah added the comment: So the problem is that readinto(view) might result in several references to view? I don't think that can be solved on the memoryview side. One could do: view = PyMemoryView_FromObject(b); // Lie about writability ((PyMemoryViewObject *)view)->view.readonly = 0; [...] Then the view owns a reference to the bytes object. But that does not solve the problem that writable memoryviews based on a readonly object might be hanging around. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 12:47:50 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 18 Sep 2012 10:47:50 +0000 Subject: [issue15903] Make rawiobase_read() read directly to bytes object In-Reply-To: <1347279783.86.0.217898740398.issue15903@psf.upfronthosting.co.za> Message-ID: <1347965270.12.0.195762674033.issue15903@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > Then the view owns a reference to the bytes object. But that does not > solve the problem that writable memoryviews based on a readonly object > might be hanging around. How about doing PyObject_GetBuffer(b, &buf, PyBUF_WRITABLE); view = PyMemoryView_FromBuffer(&buf); // readinto view PyBuffer_Release(&buf); Would attempts to access a "leaked" reference to view now result in ValueError("operation forbidden on released memoryview object")? If so then I think this would be safe. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 13:34:50 2012 From: report at bugs.python.org (Malthe Borch) Date: Tue, 18 Sep 2012 11:34:50 +0000 Subject: [issue15961] Missing return value in ``system_message`` Message-ID: <1347968090.6.0.249587654203.issue15961@psf.upfronthosting.co.za> New submission from Malthe Borch: When ``docutils`` are importable, distutils uses a reporter implementation that incorrectly drops a return value from the ``system_message`` override (see patch). ---------- assignee: eric.araujo components: Distutils files: patch.diff keywords: patch messages: 170640 nosy: eric.araujo, malthe, tarek priority: normal severity: normal status: open title: Missing return value in ``system_message`` type: behavior versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file27215/patch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 14:19:54 2012 From: report at bugs.python.org (=?utf-8?q?Nacsa_Krist=C3=B3f?=) Date: Tue, 18 Sep 2012 12:19:54 +0000 Subject: [issue15962] Windows STDIN/STDOUT Redirection is actually FIXED Message-ID: <1347970794.78.0.910609008076.issue15962@psf.upfronthosting.co.za> New submission from Nacsa Krist?f: The Python docs faq says that due to a bug in Windows NT's cmd.exe, the output redirection and piping won't work when started from file extension. http://docs.python.org/faq/windows.html#how-do-i-make-python-scripts-executable http://docs.python.org/py3k/faq/windows.html#how-do-i-make-python-scripts-executable This is actually fixed in Windows, but the fix is disabled by default, and you need to enable it in regedit, the keyword is "InheritConsoleHandles". Proof & Details: http://support.microsoft.com/default.aspx?kbid=321788 It would be great if the docs could refer to this fix, as the docs is the major source of information for many. ---------- assignee: docs at python components: Documentation, Installation, Windows messages: 170641 nosy: Nacsa.Krist?f, docs at python priority: normal severity: normal status: open title: Windows STDIN/STDOUT Redirection is actually FIXED versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 14:23:33 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 18 Sep 2012 12:23:33 +0000 Subject: [issue15962] Windows STDIN/STDOUT Redirection is actually FIXED In-Reply-To: <1347970794.78.0.910609008076.issue15962@psf.upfronthosting.co.za> Message-ID: <1347971013.95.0.701905718187.issue15962@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy nosy: +brian.curtin, terry.reedy, tim.golden stage: -> needs patch type: -> enhancement versions: -Python 2.6, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 14:30:44 2012 From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=) Date: Tue, 18 Sep 2012 12:30:44 +0000 Subject: [issue8425] a -= b should be fast if a is a small set and b is a large set In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za> Message-ID: <1347971444.62.0.843320502379.issue8425@psf.upfronthosting.co.za> Changes by Michele Orr? : ---------- nosy: +maker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 14:49:30 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 18 Sep 2012 12:49:30 +0000 Subject: [issue15903] Make rawiobase_read() read directly to bytes object In-Reply-To: <1347279783.86.0.217898740398.issue15903@psf.upfronthosting.co.za> Message-ID: <1347972570.3.0.567630914084.issue15903@psf.upfronthosting.co.za> Richard Oudkerk added the comment: The current non-test uses of PyMemoryView_FromBuffer() are in _io.BufferedReader.read(), _io.BufferedWriter.write(), PyUnicode_Decode(). It looks like they can each be made to leak a memoryview that references a deallocated buffer. (Maybe the answer is Don't Do That.) import codecs, sys def decode(buf): global view view = buf return codecs.latin_1_decode(buf) def getregentry(): return codecs.CodecInfo(name='foobar', decode=decode, encode=codecs.latin_1_encode) @codecs.register def search_function(encoding): if encoding == 'foobar': return codecs.CodecInfo(*getregentry()) b = b'hello'.upper() b.decode('foobar') print(view.tobytes()) # => b'HELLO' del b x = b'dump'.upper() print(view.tobytes()) # => b'DUMP\x00' import io, sys class File(io.RawIOBase): def readinto(self, buf): global view view = buf n = len(buf) buf[:] = b'x'*n return n def readable(self): return True f = io.BufferedReader(File()) f.read(1) print(view[:5].tobytes()) # => b'xxxxx' del f print(view[:5].tobytes()) # => b'\xdd\xdd\xdd\xdd\xdd' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 14:58:57 2012 From: report at bugs.python.org (Trent Nelson) Date: Tue, 18 Sep 2012 12:58:57 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS) In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1347973137.83.0.0566174437382.issue15745@psf.upfronthosting.co.za> Changes by Trent Nelson : ---------- title: Numerous utime ns tests fail on FreeBSD w/ ZFS -> Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 15:25:53 2012 From: report at bugs.python.org (Kristof Keppens) Date: Tue, 18 Sep 2012 13:25:53 +0000 Subject: [issue9720] zipfile writes incorrect local file header for large files in zip64 In-Reply-To: <1283216540.17.0.624049939978.issue9720@psf.upfronthosting.co.za> Message-ID: <1347974753.96.0.471373615959.issue9720@psf.upfronthosting.co.za> Changes by Kristof Keppens : ---------- nosy: +Kristof.Keppens _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 15:40:35 2012 From: report at bugs.python.org (Trent Nelson) Date: Tue, 18 Sep 2012 13:40:35 +0000 Subject: [issue15963] Improve ./configure's support for 32/64-bit debug|release|profiled builds w/ vendor (non-gcc) compilers on proprietary UNIX systems (Solaris/HP-UX/AIX et al). Message-ID: <1347975635.66.0.0788814924298.issue15963@psf.upfronthosting.co.za> New submission from Trent Nelson: Gripe: if you want a 64-bit, non-gcc (i.e. vendor's cc) build on a proprietary UNIX system (i.e. Solaris, HP-UX, AIX etc), "you're going to have a bad time". Coercing a 64-bit build from a vendor's cc currently requires explicit CFLAGS/LDFLAGS/configure gymnastics for each platform. It's a pain. Initial goal: use this issue to document the gymnastics. Assumption: once all the different techniques are documented, it'll be easier to assess what changes would be appropriate to configure.in. Side bar design question: on BSD/Linux/OSX w/ gcc/clang, if you're on an amd64 platform, you'll get a 64-bit build. This isn't the case for Solaris, HP-UX and AIX -- the default is always 32-bit. You need aforementioned gymnastics to coerce a 64-bit build. Is this by design? If so, then I guess I'm proposing that ./configure should have a `--with-64`-type argument that'll generate a 64-bit build. If not, then we need to decide whether to change the default behavior such that ./configure always generates a 64-bit build if you're on a 64-bit platform -- if you want a 32-bit build, you need to explicitly tell ./configure (i.e. --with-32). Changing the default is probably only viable for 3.4 onwards. It'd be nice if 2.7->3.3 had generic configure support for 64-bit builds though (via --with-64). XXX TODO for trent: review autoconf's offerings... getting 64-bit builds from vendor cc's can't be that unusual. ---------- assignee: trent components: Build messages: 170643 nosy: trent priority: low severity: normal status: open title: Improve ./configure's support for 32/64-bit debug|release|profiled builds w/ vendor (non-gcc) compilers on proprietary UNIX systems (Solaris/HP-UX/AIX et al). type: enhancement versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 15:43:49 2012 From: report at bugs.python.org (Trent Nelson) Date: Tue, 18 Sep 2012 13:43:49 +0000 Subject: [issue15963] Improve ./configure's support for 32/64-bit debug|release|profiled builds w/ vendor (non-gcc) compilers on proprietary UNIX systems (Solaris/HP-UX/AIX et al). In-Reply-To: <1347975635.66.0.0788814924298.issue15963@psf.upfronthosting.co.za> Message-ID: <1347975829.29.0.750465094305.issue15963@psf.upfronthosting.co.za> Trent Nelson added the comment: On the s10 slave (Solaris 10/nitrogen) for 3.x: (cpython at nitrogen:ttypts/4) (Tue/12:32) .. % ../../src/configure --with-pydebug --without-gcc CFLAGS="-m64 -mt -xcheck=%all -g3 -xarch=native -xchip=native" CPPFLAGS="-IInclude" OPT="" LDFLAGS="-m64 -mt -xcheck=%all -g3 -xarch=native -xchip=native" CC=/opt/solarisstudio12.3/bin/cc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 15:44:30 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 18 Sep 2012 13:44:30 +0000 Subject: [issue9720] zipfile writes incorrect local file header for large files in zip64 In-Reply-To: <1283216540.17.0.624049939978.issue9720@psf.upfronthosting.co.za> Message-ID: <1347975870.76.0.932550727049.issue9720@psf.upfronthosting.co.za> Christian Heimes added the comment: Serhiy: If I understand you correctly it should be easy to fix. The code in close() has to check if any file is beyond the ZIP64 limit and then write all headers with extra args. Is that correct? ---------- keywords: +needs review nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 15:46:58 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Tue, 18 Sep 2012 13:46:58 +0000 Subject: [issue15963] Improve ./configure's support for 32/64-bit debug|release|profiled builds w/ vendor (non-gcc) compilers on proprietary UNIX systems (Solaris/HP-UX/AIX et al). In-Reply-To: <1347975635.66.0.0788814924298.issue15963@psf.upfronthosting.co.za> Message-ID: <1347976018.86.0.990272921915.issue15963@psf.upfronthosting.co.za> Changes by Jeremy Kloth : ---------- nosy: +jkloth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 16:26:19 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 18 Sep 2012 14:26:19 +0000 Subject: [issue15964] SyntaxError in asdl when building 2.7 with system Python 3 Message-ID: <1347978379.29.0.810502621141.issue15964@psf.upfronthosting.co.za> New submission from Chris Jerdonek: Building with-- ./configure --with-pydebug && make -j2 errors out after switching branches from default to 2.7 when the system Python is Python 3 (on Mac OS X 10.7.4 using MacPorts). To reproduce: $ sudo port select python python32 $ python No such file or directory $ python3 -V Python 3.2.3 $ hg update default $ ./configure --with-pydebug && make -j2 $ hg update 2.7 $ cp Modules/Setup.dist Modules/Setup $ ./configure --with-pydebug && make -j2 ... config.status: creating pyconfig.h config.status: pyconfig.h is unchanged creating Modules/Setup creating Modules/Setup.local creating Makefile ./install-sh -c -d Include ./Parser/asdl_c.py -h Include ./Parser/Python.asdl gcc -c -fno-strict-aliasing -g -O2 -g -O0 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o Parser/printgrammar.o Parser/printgrammar.c gcc -c -fno-strict-aliasing -g -O2 -g -O0 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o Parser/pgenmain.o Parser/pgenmain.c File "./Parser/asdl_c.py", line 1 print "Must specify exactly one output file" ^ SyntaxError: invalid syntax make: *** [Include/Python-ast.h] Error 1 make: *** Waiting for unfinished jobs.... Running "make distclean" doesn't fix this. Here is one work-around: $ sudo port select python python27 $ ./configure --with-pydebug && make -j2 Perhaps the right work-around can be documented in the devguide, or maybe this can be addressed another way. ---------- components: Build messages: 170646 nosy: cjerdonek priority: normal severity: normal status: open title: SyntaxError in asdl when building 2.7 with system Python 3 type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 16:49:31 2012 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 18 Sep 2012 14:49:31 +0000 Subject: [issue15960] logging.shutdown should cope with IO errors from handler.release methods In-Reply-To: <1347954020.8.0.36541508073.issue15960@psf.upfronthosting.co.za> Message-ID: <1347979771.49.0.846198686889.issue15960@psf.upfronthosting.co.za> Vinay Sajip added the comment: I'm not against making this change, but I'm curious - why would a handler do clean-up I/O in its release() method (which is just for releasing the I/O lock) where it could just as easily override the close() method to do the same thing? It seems like programmer error to be doing any I/O in a handler after close() is called on it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 17:12:52 2012 From: report at bugs.python.org (Trent Nelson) Date: Tue, 18 Sep 2012 15:12:52 +0000 Subject: [issue15965] AT_FDCWD is 0xffd19553 on Solaris 10, resulting in compiler warnings. Message-ID: <1347981172.74.0.722168531343.issue15965@psf.upfronthosting.co.za> New submission from Trent Nelson: On Solaris (s10/nitrogen): % find /usr/include -type f | xargs fgrep -ni AT_FDCWD /usr/include/sys/fcntl.h:320:#define AT_FDCWD 0xffd19553 (AIX uses -2, FreeBSD uses -100.) Anyway, that results in: (cpython at nitrogen:ttypts/10) (Tue/15:34) .. (~/hg/3.x.trent/build/release) % touch ../../src/Modules/posixmodule.c (cpython at nitrogen:ttypts/10) (Tue/15:34) .. (~/hg/3.x.trent/build/release) % time /usr/ccs/bin/make /opt/solarisstudio12.3/bin/cc -DNDEBUG -v -m64 -mt=yes -xbuiltin -xhwcprof -xF -xarch=native -xchip=native -fast -fma=fused -g -xO4 -library=sunperf -I. -I../../src/Include -IInclude -DPy_BUILD_CORE -c ../../src/Modules/posixmodule.c -o Modules/posixmodule.o "../../src/Modules/posixmodule.c", line 2307: warning: initializer does not fit or is out of range: 0xffd19553 "../../src/Modules/posixmodule.c", line 2337: warning: initializer does not fit or is out of range: 0xffd19553 "../../src/Modules/posixmodule.c", line 2386: warning: initializer does not fit or is out of range: 0xffd19553 "../../src/Modules/posixmodule.c", line 2626: warning: initializer does not fit or is out of range: 0xffd19553 "../../src/Modules/posixmodule.c", line 2966: warning: initializer does not fit or is out of range: 0xffd19553 "../../src/Modules/posixmodule.c", line 3198: warning: initializer does not fit or is out of range: 0xffd19553 "../../src/Modules/posixmodule.c", line 3199: warning: initializer does not fit or is out of range: 0xffd19553 "../../src/Modules/posixmodule.c", line 3845: warning: initializer does not fit or is out of range: 0xffd19553 "../../src/Modules/posixmodule.c", line 3989: warning: initializer does not fit or is out of range: 0xffd19553 "../../src/Modules/posixmodule.c", line 3990: warning: initializer does not fit or is out of range: 0xffd19553 "../../src/Modules/posixmodule.c", line 4111: warning: initializer does not fit or is out of range: 0xffd19553 "../../src/Modules/posixmodule.c", line 4267: warning: initializer does not fit or is out of range: 0xffd19553 "../../src/Modules/posixmodule.c", line 4587: warning: initializer does not fit or is out of range: 0xffd19553 "../../src/Modules/posixmodule.c", line 7007: warning: initializer does not fit or is out of range: 0xffd19553 "../../src/Modules/posixmodule.c", line 7092: warning: initializer does not fit or is out of range: 0xffd19553 "../../src/Modules/posixmodule.c", line 7510: warning: initializer does not fit or is out of range: 0xffd19553 "../../src/Modules/posixmodule.c", line 8260: warning: initializer does not fit or is out of range: 0xffd19553 "../../src/Modules/posixmodule.c", line 8322: warning: initializer does not fit or is out of range: 0xffd19553 ^C *** Modules/posixmodule.o removed. /usr/ccs/bin/make 2.79s user 0.28s system 46% cpu 6.598 total In every case, the affected line is: int dir_fd = DEFAULT_DIR_FD; (DEFAULT_DIR_FD defaults to AT_FDCWD if it's defined.) Note that Solaris 10 64-bit is LP64, ints are still 32-bit. ---------- assignee: trent components: Build messages: 170648 nosy: trent priority: normal severity: normal stage: needs patch status: open title: AT_FDCWD is 0xffd19553 on Solaris 10, resulting in compiler warnings. type: compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 17:16:06 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 18 Sep 2012 15:16:06 +0000 Subject: [issue15965] AT_FDCWD is 0xffd19553 on Solaris 10, resulting in compiler warnings. In-Reply-To: <1347981172.74.0.722168531343.issue15965@psf.upfronthosting.co.za> Message-ID: <1347981366.28.0.371249951736.issue15965@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 17:32:07 2012 From: report at bugs.python.org (Trent Nelson) Date: Tue, 18 Sep 2012 15:32:07 +0000 Subject: [issue15965] AT_FDCWD is 0xffd19553 on Solaris 10, resulting in compiler warnings. In-Reply-To: <1347981172.74.0.722168531343.issue15965@psf.upfronthosting.co.za> Message-ID: <1347982327.53.0.4210648465.issue15965@psf.upfronthosting.co.za> Trent Nelson added the comment: Easy fix, cast AT_FDCWD to (int): % hg diff diff -r 3a880d640981 Modules/posixmodule.c --- a/Modules/posixmodule.c Tue Sep 18 07:21:18 2012 +0300 +++ b/Modules/posixmodule.c Tue Sep 18 16:04:58 2012 +0000 @@ -414,7 +414,14 @@ #ifdef AT_FDCWD -#define DEFAULT_DIR_FD AT_FDCWD +/* + * Why the (int) cast? Solaris 10 defines AT_FDCWD as 0xffd19553 (-3041965); + * without the int cast, the value gets interpreted as uint (4291925331), + * which doesn't play nicely with all the initializer lines in this file that + * look like this: + * int dir_fd = DEFAULT_DIR_FD; + */ +#define DEFAULT_DIR_FD (int)AT_FDCWD #else #define DEFAULT_DIR_FD (-100) #endif The cast is harmless on other platforms that use an actual integer (rather than a hex representation). Any objections? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 17:32:48 2012 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 18 Sep 2012 15:32:48 +0000 Subject: [issue15966] concurrent.futures: Executor.submit keyword arguments may not be called 'fn' (or 'self') Message-ID: <1347982368.75.0.56994107832.issue15966@psf.upfronthosting.co.za> New submission from Mark Dickinson: The submit methods of concurrent.futures.ThreadPoolExecutor and concurrent.futures.ProcessPoolExectutor raise TypeError when submitting a callable with a keyword argument named 'fn' or 'self': Python 3.3.0rc2+ (default:3a880d640981, Sep 18 2012, 16:29:28) [GCC 4.2.1 (Apple Inc. build 5664)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import concurrent.futures >>> def awkward(*, fn): return fn * 1729 ... >>> with concurrent.futures.ThreadPoolExecutor(1) as e: ... e.submit(awkward, fn=3) ... Traceback (most recent call last): File "", line 2, in TypeError: submit() got multiple values for argument 'fn' An obvious solution is to change the declarations of the submit methods from: def submit(self, fn, *args, **kwargs): ... to def submit(*args, **kwargs): self, fn, *args = args I don't think this is quite good enough, since it'll introduce a regression for anyone who was doing executor.submit(fn=...). ---------- messages: 170650 nosy: mark.dickinson priority: normal severity: normal status: open title: concurrent.futures: Executor.submit keyword arguments may not be called 'fn' (or 'self') type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 17:37:49 2012 From: report at bugs.python.org (Trent Nelson) Date: Tue, 18 Sep 2012 15:37:49 +0000 Subject: [issue2286] Stack overflow exception caused by test_marshal on Windows x64 In-Reply-To: <1205499475.78.0.0465561571315.issue2286@psf.upfronthosting.co.za> Message-ID: <1347982669.51.0.061935061791.issue2286@psf.upfronthosting.co.za> Trent Nelson added the comment: Closing issue; this has been fixed. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 17:59:21 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 18 Sep 2012 15:59:21 +0000 Subject: [issue15955] gzip, bz2, lzma: add method to get decompressed size In-Reply-To: <1347884562.79.0.801674791772.issue15955@psf.upfronthosting.co.za> Message-ID: <1347983961.49.0.0511776922446.issue15955@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 17:59:43 2012 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 18 Sep 2012 15:59:43 +0000 Subject: [issue15966] concurrent.futures: Executor.submit keyword arguments may not be called 'fn' (or 'self') In-Reply-To: <1347982368.75.0.56994107832.issue15966@psf.upfronthosting.co.za> Message-ID: <1347983983.27.0.956306025514.issue15966@psf.upfronthosting.co.za> Mark Dickinson added the comment: Here's a patch. The solution is ugly enough that I'm wondering whether this is even worth fixing. ---------- keywords: +patch Added file: http://bugs.python.org/file27216/futures.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 18:03:22 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 18 Sep 2012 16:03:22 +0000 Subject: [issue15957] README.txt points to broken "contributing" url in python wiki In-Reply-To: <1347901195.54.0.476141478032.issue15957@psf.upfronthosting.co.za> Message-ID: <1347984202.6.0.133397038523.issue15957@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks for the report. I think the wiki was modified to redirect /thing to /moin/thing some months ago, so it may be the recent hardware migration that broke that. I?ll follow up with the pydotorg-www mailing list (or feel free to do it). ---------- assignee: docs at python -> eric.araujo nosy: +eric.araujo -docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 18:04:37 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 18 Sep 2012 16:04:37 +0000 Subject: [issue15963] Improve ./configure's support for 32/64-bit debug|release|profiled builds w/ vendor (non-gcc) compilers on proprietary UNIX systems (Solaris/HP-UX/AIX et al). In-Reply-To: <1347975635.66.0.0788814924298.issue15963@psf.upfronthosting.co.za> Message-ID: <1347984277.63.0.892624078525.issue15963@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo, loewis versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 18:07:25 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 18 Sep 2012 16:07:25 +0000 Subject: [issue15961] Missing return value in ``system_message`` In-Reply-To: <1347968090.6.0.249587654203.issue15961@psf.upfronthosting.co.za> Message-ID: <1347984445.85.0.0205486768374.issue15961@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks for the report and patch. I think a similar issue was reported for distutils2 (maybe only orally, not on this tracker, I have to search). How did you find the bug? In other words, can you add a unit test for this? :) ---------- components: +Distutils2 nosy: +alexis stage: -> test needed versions: +3rd party, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 18:07:55 2012 From: report at bugs.python.org (Michael Foord) Date: Tue, 18 Sep 2012 16:07:55 +0000 Subject: [issue15836] unittest assertRaises should verify excClass is actually a BaseException class In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za> Message-ID: <1347984475.05.0.446606664329.issue15836@psf.upfronthosting.co.za> Michael Foord added the comment: The patch is just waiting for me to look over it and commit. I'll get to it ASAP. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 18:08:28 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 18 Sep 2012 16:08:28 +0000 Subject: [issue4711] Wide literals in the table of contents overflow in documentation In-Reply-To: <1229878552.94.0.178929851509.issue4711@psf.upfronthosting.co.za> Message-ID: <1347984508.84.0.632639973733.issue4711@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 18:12:15 2012 From: report at bugs.python.org (Vitaly) Date: Tue, 18 Sep 2012 16:12:15 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za> Message-ID: <1347984735.1.0.940354405617.issue15896@psf.upfronthosting.co.za> Vitaly added the comment: In the work-around, we need to watch out for what 'man 2 read' on Mac OS refers to as "normal file": == Upon successful completion, read(), readv(), and pread() return the number of bytes actually read and placed in the buffer. *The system guarantees to read the number of bytes requested if the descriptor references a normal file that has that many bytes left before the end-of-file*, but in no other case. == I am guessing that fstat() + S_ISREG() can be used to discern "normal files" from other types of file descriptors. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 18:20:47 2012 From: report at bugs.python.org (Ralf Schmitt) Date: Tue, 18 Sep 2012 16:20:47 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za> Message-ID: <1347985247.8.0.47864468183.issue15896@psf.upfronthosting.co.za> Changes by Ralf Schmitt : ---------- nosy: +schmir _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 19:07:58 2012 From: report at bugs.python.org (Matthew Barnett) Date: Tue, 18 Sep 2012 17:07:58 +0000 Subject: [issue15956] backreference to named group does not work In-Reply-To: <1347888827.23.0.363134887653.issue15956@psf.upfronthosting.co.za> Message-ID: <1347988078.48.0.662005406537.issue15956@psf.upfronthosting.co.za> Matthew Barnett added the comment: There needed to be a way of referring to named groups in the replacement template. The existing form \groupnumber clearly wouldn't work. Other regex implementations, such as Perl, do have \g and also \k (for named groups). In my implementation I added support for \g in regex strings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 20:19:43 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 18 Sep 2012 18:19:43 +0000 Subject: [issue15903] Make rawiobase_read() read directly to bytes object In-Reply-To: <1347279783.86.0.217898740398.issue15903@psf.upfronthosting.co.za> Message-ID: <1347992383.6.0.445489615232.issue15903@psf.upfronthosting.co.za> Richard Oudkerk added the comment: I am rather confused about the ownership semantics when one uses PyMemoryView_FromBuffer(). It looks as though PyMemoryView_FromBuffer() "steals" ownership of the buffer since, when the associated _PyManagedBufferObject is garbage collected, PyBuffer_Release() is called on its copy of the buffer info. However, the _PyManagedBufferObject does not own a reference of the base object, so one still needs to decref the base object (at some time when it is safe to do so). So am I right in thinking that PyObject_GetBuffer(obj, &buf, ...); view = PyMemoryView_FromBuffer(&buf); // view->master owns the buffer, but view->master->obj == NULL ... Py_DECREF(view); // releases buffer (assuming no other exports) Py_XDECREF(buf.obj); has balanced refcounting and is more or less equivalent to view = PyMemoryView_FromObject(obj); ... Py_DECREF(view); The documentation is not very helpful. It just says that calls to PyObject_GetBuffer() must be matched with calls to PyBuffer_Release(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 20:20:41 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 18 Sep 2012 18:20:41 +0000 Subject: [issue15903] Make rawiobase_read() read directly to bytes object In-Reply-To: <1347965270.12.0.195762674033.issue15903@psf.upfronthosting.co.za> Message-ID: <20120918182042.GA23778@sleipnir.bytereef.org> Stefan Krah added the comment: Richard Oudkerk wrote: > PyObject_GetBuffer(b, &buf, PyBUF_WRITABLE); > view = PyMemoryView_FromBuffer(&buf); > // readinto view > PyBuffer_Release(&buf); > > Would attempts to access a "leaked" reference to view now result in ValueError("operation forbidden on released memoryview object")? If so then I think this would be safe. You would need to call memory_release(). Perhaps we can just expose it on the C-API level as PyMemoryView_Release(). IMO the use of PyObject_GetBuffer() should be discouraged. The semantics aren't clear (see #15821). I'd suggest using: 1) A buffer provider is involved (the case here): PyMemoryView_From Object() 2) A piece of memory needs to be wrapped temporarily and no references to the memoryview are "leaked" on the Python level: PyMemoryView_FromMemory() 3) A piece of memory needs to be packaged as a memoryview with automatic cleanup in mbuf_dealloc(): PyMemoryView_FromBufferWithCleanup() (proposed in msg169613) So I think the combination of PyMemoryView_FromObject() with a call to PyMemoryView_Release() should indeed work here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 20:22:55 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 18 Sep 2012 18:22:55 +0000 Subject: [issue15903] Make rawiobase_read() read directly to bytes object In-Reply-To: <1347992383.6.0.445489615232.issue15903@psf.upfronthosting.co.za> Message-ID: <20120918182256.GA23919@sleipnir.bytereef.org> Stefan Krah added the comment: Richard Oudkerk wrote: > The documentation is not very helpful. It just says that calls > to PyObject_GetBuffer() must be matched with calls to PyBuffer_Release(). Yes, we need to sort that out, see #15821. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 20:37:28 2012 From: report at bugs.python.org (Trent Nelson) Date: Tue, 18 Sep 2012 18:37:28 +0000 Subject: [issue15963] Improve ./configure's support for 32/64-bit debug|release|profiled builds w/ vendor (non-gcc) compilers on proprietary UNIX systems (Solaris/HP-UX/AIX et al). In-Reply-To: <1347975635.66.0.0788814924298.issue15963@psf.upfronthosting.co.za> Message-ID: <1347993448.46.0.389953521918.issue15963@psf.upfronthosting.co.za> Trent Nelson added the comment: Solaris 10 release (i.e. optimized) build requires the following: ../../src/configure --without-gcc CFLAGS="-v -fsimple=0 -m64 -mt=yes -xbuiltin -xhwcprof -xF -xarch=native -xchip=native -fma=fused -g -xO5 -xlibmil -xlibmopt -xmemalign=8s -xregs=frameptr -xtarget=native -xbuiltin=%all -library=sunperf" CPPFLAGS="-IInclude" OPT="" LDFLAGS="-v -fsimple=0 -m64 -mt=yes -xbuiltin -xhwcprof -xF -xarch=native -xchip=native -fma=fused -g -xO5 -xlibmil -xlibmopt -xmemalign=8s -xbuiltin=%all -xregs=frameptr -xtarget=native -library=sunperf" CC=/opt/solarisstudio12.3/bin/cc (Due to indirect linker invocation via cc, I'm purposely duplicating CFLAGS <-> LDFLAGS for now. I'll refine later.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 20:46:03 2012 From: report at bugs.python.org (Steve Newcomb) Date: Tue, 18 Sep 2012 18:46:03 +0000 Subject: [issue15956] backreference to named group does not work In-Reply-To: <1347888827.23.0.363134887653.issue15956@psf.upfronthosting.co.za> Message-ID: <1347993963.63.0.351348307102.issue15956@psf.upfronthosting.co.za> Steve Newcomb added the comment: > But this way exists: (?P=startquote) is what you want. I know how I missed it: I searched for "backref" in the documentation. I did not find it in the discussion of the pattern language, because that word does not appear where contributions are welcome. See attached brief patch for the documentation. It changes the example, adds a table of the three processing contexts in which named groups can be referenced, and accounts for users who, like me, may search for "backref". (I tested everything. I think it's correct.) Thanks again for the advice, Amaury. ---------- Added file: http://bugs.python.org/file27217/patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 20:57:09 2012 From: report at bugs.python.org (Trent Nelson) Date: Tue, 18 Sep 2012 18:57:09 +0000 Subject: [issue15967] Slaves don't seem to clean up their /tmp mess if a step fails. Message-ID: <1347994629.04.0.316608804637.issue15967@psf.upfronthosting.co.za> New submission from Trent Nelson: All my slaves' /tmp's are polluted with regrtest fluff. I haven't checked yet, but I presume no cleanup is done if a test/run fails. nitrogen% find /tmp -user cpython 2> /dev/null | wc -l 197 netbsd51-x64-1$ find /tmp -user cpython 2> /dev/null | wc -l 142 oxygen% find /tmp -user cpython 2> /dev/null | wc -l 456 Placeholder issue until it annoys me enough to patch. ---------- assignee: trent components: Build messages: 170663 nosy: trent priority: normal severity: normal status: open title: Slaves don't seem to clean up their /tmp mess if a step fails. type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 21:02:08 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 18 Sep 2012 19:02:08 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347985247.92.0.670261802857.issue15896@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > What's wrong with working around this bug by reading a smaller amount? > How much data is there supposed to be? Nothing, except that there are probably other places in the stdlib where we can get bitten by this bug. Note that this should eventually be done for another reason, see http://bugs.python.org/issue15918 > In the work-around, we need to watch out for what 'man 2 read' on Mac OS refers to as > "normal file": There's nothing special actually. This precision concerning normal file is OS-X specific, POSIX makes no such guarantee: you can always get a short read (e.g. because of signal delivery), so one should always call read() in a loop. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 21:08:57 2012 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 18 Sep 2012 19:08:57 +0000 Subject: [issue15039] module/ found before module.py when both are in the CWD In-Reply-To: <1339199943.51.0.731148494988.issue15039@psf.upfronthosting.co.za> Message-ID: <1347995337.71.0.979637907873.issue15039@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 21:18:09 2012 From: report at bugs.python.org (Larry Hastings) Date: Tue, 18 Sep 2012 19:18:09 +0000 Subject: [issue15965] AT_FDCWD is 0xffd19553 on Solaris 10, resulting in compiler warnings. In-Reply-To: <1347981172.74.0.722168531343.issue15965@psf.upfronthosting.co.za> Message-ID: Larry Hastings added the comment: Lgtm. Trent Nelson wrote: > >Trent Nelson added the comment: > >Easy fix, cast AT_FDCWD to (int): > > >% hg diff >diff -r 3a880d640981 Modules/posixmodule.c >--- a/Modules/posixmodule.c Tue Sep 18 07:21:18 2012 +0300 >+++ b/Modules/posixmodule.c Tue Sep 18 16:04:58 2012 +0000 >@@ -414,7 +414,14 @@ > > > #ifdef AT_FDCWD >-#define DEFAULT_DIR_FD AT_FDCWD >+/* >+ * Why the (int) cast? Solaris 10 defines AT_FDCWD as 0xffd19553 (-3041965); >+ * without the int cast, the value gets interpreted as uint (4291925331), >+ * which doesn't play nicely with all the initializer lines in this file that >+ * look like this: >+ * int dir_fd = DEFAULT_DIR_FD; >+ */ >+#define DEFAULT_DIR_FD (int)AT_FDCWD > #else > #define DEFAULT_DIR_FD (-100) > #endif > > >The cast is harmless on other platforms that use an actual integer (rather than a hex representation). > >Any objections? > >---------- > >_______________________________________ >Python tracker > >_______________________________________ ---------- title: AT_FDCWD is 0xffd19553 on Solaris 10, resulting in compiler warnings. -> AT_FDCWD is 0xffd19553 on Solaris 10, resulting in compiler warnings. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 21:21:12 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 18 Sep 2012 19:21:12 +0000 Subject: [issue15956] backreference to named group does not work In-Reply-To: <1347888827.23.0.363134887653.issue15956@psf.upfronthosting.co.za> Message-ID: <1347996072.49.0.299630634663.issue15956@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Thanks for the patch! The new formulation looks much better, but I'll let a native speaker have another check. Some comments: I preferred the previous example "" because it's not obvious what \042\047 is. And a bullet list would be less heavyweight IMO. (Also please use "diff -u"; without context, the patch cannot be applied automatically) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 21:28:52 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 18 Sep 2012 19:28:52 +0000 Subject: [issue15967] Slaves don't seem to clean up their /tmp mess if a step fails. In-Reply-To: <1347994629.04.0.316608804637.issue15967@psf.upfronthosting.co.za> Message-ID: <1347996532.83.0.0601205306557.issue15967@psf.upfronthosting.co.za> R. David Murray added the comment: Cleanup on test failure is supposed to be done. Cleanup on crash or buildbot timeout isn't done as far as I know (and that was a concern I had with the changes made to support.TESTFN and the cwd, but I didn't articulate it very well). If you find tests that do no clean up on error, that's definitely a bug and we should fix them. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 21:36:24 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Tue, 18 Sep 2012 19:36:24 +0000 Subject: [issue15968] Incorporate Tcl/Tk/Tix into the Windows build process Message-ID: <1347996983.92.0.069726969781.issue15968@psf.upfronthosting.co.za> New submission from Jeremy Kloth: This patch incorporates Tcl/Tk/Tix into the MSVC build in the same fashion as OpenSSL has been done. Highlights: - A new project, tcltk, is added that simply calls the Python script build_tkinter.py to build the externals. - New helper module PCbuild/buildlib.py to parse and evaluate the MSBuild property files. - build_tkinter.py is updated to use MSBuild properties for locating the sources. - The tcltk output directory is now inside the PCbuild directory to enable different Tcl/Tk/Tix versions for different Python versions ---------- components: Build hgrepos: 149 messages: 170668 nosy: jkloth priority: normal severity: normal status: open title: Incorporate Tcl/Tk/Tix into the Windows build process versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 21:39:26 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 18 Sep 2012 19:39:26 +0000 Subject: [issue15952] format(value) and value.__format__() behave differently with unicode format In-Reply-To: <1347825591.49.0.625826586182.issue15952@psf.upfronthosting.co.za> Message-ID: <1347997166.28.0.368742707257.issue15952@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Here is a proposed patch. One note on the patch. I feel the second sentence of the note is worth adding because value.__format__() departs from what PEP 3101 says: "Note for Python 2.x: The 'format_spec' argument will be either a string object or a unicode object, depending on the type of the original format string. The __format__ method should test the type of the specifiers parameter to determine whether to return a string or unicode object. It is the responsibility of the __format__ method to return an object of the proper type." The extra sentence will help in heading off and when responding to issues about value.__format__() that are similar to issue 15951. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file27218/issue-15952-1-branch-27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 21:44:16 2012 From: report at bugs.python.org (Steve Newcomb) Date: Tue, 18 Sep 2012 19:44:16 +0000 Subject: [issue15956] backreference to named group does not work In-Reply-To: <1347888827.23.0.363134887653.issue15956@psf.upfronthosting.co.za> Message-ID: <1347997456.31.0.98214879585.issue15956@psf.upfronthosting.co.za> Steve Newcomb added the comment: > I preferred the previous example "" because it's not obvious what \042\047 is. Yeah, but the example I wrote has an in-pattern backreference and a real reason to use one. In the attached patch, I have changed [\042\047] to [\'\"]. That's certainly clearer for everyone who has not memorized the ASCII table in octal! (Oops.) > And a bullet list would be less heavyweight IMO. Well... I rejected that choice because there would be no clarifying columnar distinction between contexts and syntaxes. Personally, I think the table is clearer. It makes it easier for users to find what they need know. >(Also please use "diff -u"; without context, the patch cannot be applied automatically) Oops. Attached. ---------- Added file: http://bugs.python.org/file27219/patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 21:44:29 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 18 Sep 2012 19:44:29 +0000 Subject: [issue15952] format(value) and value.__format__() behave differently with unicode format In-Reply-To: <1347825591.49.0.625826586182.issue15952@psf.upfronthosting.co.za> Message-ID: <1347997469.56.0.955583858095.issue15952@psf.upfronthosting.co.za> Chris Jerdonek added the comment: To clarify, one of the sentences above should have read, "I feel the second sentence of the note *in the patch* was worth adding..." (not the second sentence of the PEP note I quoted). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 21:55:06 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 18 Sep 2012 19:55:06 +0000 Subject: [issue15967] Slaves don't seem to clean up their /tmp mess if a step fails. In-Reply-To: <1347994629.04.0.316608804637.issue15967@psf.upfronthosting.co.za> Message-ID: <1347998106.95.0.403096142985.issue15967@psf.upfronthosting.co.za> Chris Jerdonek added the comment: To follow up on David's comment, the unit tests in the test suite aren't consistent in their treatment of temp directories (e.g. they don't use a common API or code path). So it may be hard to address this globally short of wiping the entire temp directory (though I could be wrong). I have a patch in issue 15415 to add a temp_dir() context manager to test.support (and consolidate with script_helper's) that would do such clean-up. The module already has a temp_cwd(), but that context manager serves two purposes. ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 22:07:27 2012 From: report at bugs.python.org (Vitaly) Date: Tue, 18 Sep 2012 20:07:27 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za> Message-ID: <1347998847.23.0.310601909188.issue15896@psf.upfronthosting.co.za> Vitaly added the comment: > Nothing, except that there are probably other places in the stdlib > where we can get bitten by this bug. Note that this should eventually > be done for another reason, see http://bugs.python.org/issue15918 For greatest benefit, I think that the work-around should be implemented in os.read() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 22:29:31 2012 From: report at bugs.python.org (Felipe Cruz) Date: Tue, 18 Sep 2012 20:29:31 +0000 Subject: [issue15744] missing tests for {RawIO,BufferedIO,TextIO}.writelines In-Reply-To: <1345500357.29.0.226025015503.issue15744@psf.upfronthosting.co.za> Message-ID: <1348000171.42.0.449773867688.issue15744@psf.upfronthosting.co.za> Felipe Cruz added the comment: Updated based on Pitrou comments ---------- Added file: http://bugs.python.org/file27220/issue15744_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 22:47:55 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 18 Sep 2012 20:47:55 +0000 Subject: [issue15903] Make rawiobase_read() read directly to bytes object In-Reply-To: <1347279783.86.0.217898740398.issue15903@psf.upfronthosting.co.za> Message-ID: <1348001275.47.0.26214243454.issue15903@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > You would need to call memory_release(). Perhaps we can just expose it on the > C-API level as PyMemoryView_Release(). Should PyMemoryView_Release() release the _PyManagedBufferObject by doing mbuf_release(view->mbuf) even if view->mbuf->exports > 0? Doing Py_TYPE(view->mbuf)->tp_clear((PyObject *)view->mbuf); seems to have the desired effect of causing ValueError when I try to access any associated memoryview. > 3) A piece of memory needs to be packaged as a memoryview with automatic > cleanup in mbuf_dealloc(): > > PyMemoryView_FromBufferWithCleanup() (proposed in msg169613) Maybe this should also handle decrefing the base object (given a flag PyManagedBuffer_FreeObj). I do worry about creating memoryviews that survive deallocation of the base object. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 22:50:10 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 18 Sep 2012 20:50:10 +0000 Subject: [issue15903] Make rawiobase_read() read directly to bytes object In-Reply-To: <1347279783.86.0.217898740398.issue15903@psf.upfronthosting.co.za> Message-ID: <1348001410.82.0.169155938893.issue15903@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 22:56:44 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 18 Sep 2012 20:56:44 +0000 Subject: [issue15903] Make rawiobase_read() read directly to bytes object In-Reply-To: <1347279783.86.0.217898740398.issue15903@psf.upfronthosting.co.za> Message-ID: <1348001804.11.0.218748560185.issue15903@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > So I think the combination of PyMemoryView_FromObject() with a call to > PyMemoryView_Release() should indeed work here. I don't think we want to expose a mutable bytes object to outside code, so IMO PyMemoryView_FromMemory() is preferrable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 22:57:06 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 18 Sep 2012 20:57:06 +0000 Subject: [issue15969] faulthandler: drop S from dump_tracebacks_later() function name to have consistent names Message-ID: <1348001825.94.0.454810241369.issue15969@psf.upfronthosting.co.za> New submission from STINNER Victor: If it is not too late, I would like to "fix" the name of two functions of the new faulthandler module before the release of Python 3.3 final. Changes: * dump_tracebacks_later() => dump_traceback_later() * cancel_dump_tracebacks_later() => cancel_dump_traceback_later() The module has also a function dump_traceback() without S. In an early version of the module (before it was integrated in Python 3.3), these functions only dumped the current thread. They are now dumping all threads by default, and I don't see the point of having an S anyway. @Georg: Would you accept such change? The module is new in Python 3.3, and it is only a debug module, I don't expect anyone relying on its API right now. ---------- components: Library (Lib) files: faulthandler_without_s.patch keywords: patch messages: 170677 nosy: georg.brandl, haypo priority: release blocker severity: normal status: open title: faulthandler: drop S from dump_tracebacks_later() function name to have consistent names versions: Python 3.3 Added file: http://bugs.python.org/file27221/faulthandler_without_s.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 23:19:27 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 18 Sep 2012 21:19:27 +0000 Subject: [issue15903] Make rawiobase_read() read directly to bytes object In-Reply-To: <1348001275.47.0.26214243454.issue15903@psf.upfronthosting.co.za> Message-ID: <20120918211928.GA25473@sleipnir.bytereef.org> Stefan Krah added the comment: Richard Oudkerk wrote: > Should PyMemoryView_Release() release the _PyManagedBufferObject by doing mbuf_release(view->mbuf) even if view->mbuf->exports > 0? No, I think it should really just be a wrapper: diff --git a/Objects/memoryobject.c b/Objects/memoryobject.c --- a/Objects/memoryobject.c +++ b/Objects/memoryobject.c @@ -1093,6 +1093,12 @@ return memory_release((PyMemoryViewObject *)self, NULL); } +PyObject * +PyMemoryView_Release(PyObject *m) +{ + return memory_release((PyMemoryViewObject *)m, NULL); +} + We decided in #10181 not to allow releasing a view with exports, since the logic is already quite complex. Is there a reasonable expectation that existing code creates memoryviews of the readinto() argument? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 23:25:01 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 18 Sep 2012 21:25:01 +0000 Subject: [issue15969] faulthandler: drop S from dump_tracebacks_later() function name to have consistent names In-Reply-To: <1348001825.94.0.454810241369.issue15969@psf.upfronthosting.co.za> Message-ID: <1348003501.37.0.36333509927.issue15969@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 23:28:18 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 18 Sep 2012 21:28:18 +0000 Subject: [issue15967] Slaves don't seem to clean up their /tmp mess if a step fails. In-Reply-To: <1347994629.04.0.316608804637.issue15967@psf.upfronthosting.co.za> Message-ID: <1348003698.15.0.648288220647.issue15967@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 23:30:20 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 18 Sep 2012 21:30:20 +0000 Subject: [issue15965] AT_FDCWD is 0xffd19553 on Solaris 10, resulting in compiler warnings. In-Reply-To: <1347981172.74.0.722168531343.issue15965@psf.upfronthosting.co.za> Message-ID: <1348003820.83.0.649414286387.issue15965@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- title: AT_FDCWD is 0xffd19553 on Solaris 10, resulting in compiler warnings. -> AT_FDCWD is 0xffd19553 on Solaris 10, resulting in compiler warnings. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 23:35:14 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 18 Sep 2012 21:35:14 +0000 Subject: [issue15956] backreference to named group does not work In-Reply-To: <1347888827.23.0.363134887653.issue15956@psf.upfronthosting.co.za> Message-ID: <1348004114.31.0.566754648666.issue15956@psf.upfronthosting.co.za> Changes by Amaury Forgeot d'Arc : ---------- assignee: -> docs at python nosy: +docs at python stage: committed/rejected -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 23:41:23 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 18 Sep 2012 21:41:23 +0000 Subject: [issue15903] Make rawiobase_read() read directly to bytes object In-Reply-To: <1348001804.11.0.218748560185.issue15903@psf.upfronthosting.co.za> Message-ID: <20120918214124.GA25673@sleipnir.bytereef.org> Stefan Krah added the comment: Antoine Pitrou wrote: > I don't think we want to expose a mutable bytes object to outside code, > so IMO PyMemoryView_FromMemory() is preferrable. I agree, but PyMemoryView_FromMemory(PyBytes_AS_STRING(b), n, PyBUF_WRITE) just hides the fact that a mutable bytes object is exposed. Are we talking about a big speedup here or could we perhaps just keep the existing code? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 23:42:12 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 18 Sep 2012 21:42:12 +0000 Subject: [issue15956] backreference to named group does not work In-Reply-To: <1347888827.23.0.363134887653.issue15956@psf.upfronthosting.co.za> Message-ID: <1348004532.8.0.0550607111889.issue15956@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 23:48:05 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 18 Sep 2012 21:48:05 +0000 Subject: [issue8425] a -= b should be fast if a is a small set and b is a large set In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za> Message-ID: <1348004885.11.0.808968701757.issue8425@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 23:48:49 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 18 Sep 2012 21:48:49 +0000 Subject: [issue15964] SyntaxError in asdl when building 2.7 with system Python 3 In-Reply-To: <1347978379.29.0.810502621141.issue15964@psf.upfronthosting.co.za> Message-ID: <1348004929.78.0.473381224551.issue15964@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 23:50:52 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 18 Sep 2012 21:50:52 +0000 Subject: [issue15954] No error checking after using of the wcsxfrm() In-Reply-To: <1347876874.21.0.668678433738.issue15954@psf.upfronthosting.co.za> Message-ID: <1348005052.3.0.6323506767.issue15954@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 18 23:51:38 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 18 Sep 2012 21:51:38 +0000 Subject: [issue15903] Make rawiobase_read() read directly to bytes object In-Reply-To: <20120918214124.GA25673@sleipnir.bytereef.org> Message-ID: <1348005065.3274.0.camel@localhost.localdomain> Antoine Pitrou added the comment: > Antoine Pitrou wrote: > > I don't think we want to expose a mutable bytes object to outside code, > > so IMO PyMemoryView_FromMemory() is preferrable. > > I agree, but PyMemoryView_FromMemory(PyBytes_AS_STRING(b), n, PyBUF_WRITE) > just hides the fact that a mutable bytes object is exposed. Except that the mutable bytes object is not exposed to any outside code, so that weird behaviour can't be observed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 00:02:18 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 18 Sep 2012 22:02:18 +0000 Subject: [issue15903] Make rawiobase_read() read directly to bytes object In-Reply-To: <1347279783.86.0.217898740398.issue15903@psf.upfronthosting.co.za> Message-ID: <1348005738.57.0.273617074217.issue15903@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > Are we talking about a big speedup here or could we perhaps just keep > the existing code? I doubt it is worth the hassle. But I did want to know if there was a clean way to do what I wanted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 00:07:48 2012 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 18 Sep 2012 22:07:48 +0000 Subject: [issue15966] concurrent.futures: Executor.submit keyword arguments may not be called 'fn' (or 'self') In-Reply-To: <1347982368.75.0.56994107832.issue15966@psf.upfronthosting.co.za> Message-ID: <1348006068.68.0.487452407325.issue15966@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 00:09:56 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 18 Sep 2012 22:09:56 +0000 Subject: [issue15964] SyntaxError in asdl when building 2.7 with system Python 3 In-Reply-To: <1347978379.29.0.810502621141.issue15964@psf.upfronthosting.co.za> Message-ID: <1348006196.16.0.70952907256.issue15964@psf.upfronthosting.co.za> Christian Heimes added the comment: I think this might be related to #15923. It shouldn't be necessary to rebuild the AST definition unless you have modified the grammar and AST files. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 00:16:25 2012 From: report at bugs.python.org (Brian Curtin) Date: Tue, 18 Sep 2012 22:16:25 +0000 Subject: [issue15966] concurrent.futures: Executor.submit keyword arguments may not be called 'fn' (or 'self') In-Reply-To: <1347982368.75.0.56994107832.issue15966@psf.upfronthosting.co.za> Message-ID: <1348006585.11.0.834825442861.issue15966@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- assignee: -> bquinlan nosy: +bquinlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 00:23:20 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 18 Sep 2012 22:23:20 +0000 Subject: [issue13888] test_builtin failure when run after test_tk In-Reply-To: <1327661656.8.0.445863136974.issue13888@psf.upfronthosting.co.za> Message-ID: <1348007000.45.0.0899037648778.issue13888@psf.upfronthosting.co.za> STINNER Victor added the comment: "python: ../../src/xcb_io.c:273: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed." I get a similar XCB assertion error: "xcb_io.c:221: poll_for_event: Assertion `(((long) (event_sequence) - (long) (dpy->request)) <= 0)' failed." The problem is that a Tk thread is still alive while test_builtins is running. XInitThreads() must be the first call to the Xlib for multithreaded applications. Extract of: https://groups.google.com/forum/#!msg/comp.lang.tcl/gFcxwy9TxLc/drmHzhvM9YQJ "3. Tk's thread support for unix/X11 is iffy. There has been work done on making Tk thread safe, but Tk still doesn't call XInitThreads(), and probably won't anytime soon. It seems that the XCB library has a superior implementation for threaded X11 interfaces anyway, so a complete rewrite would make more sense (to me). Tk however can be used with threaded builds, and multiple threads, but only with a single thread using [package require Tk] as I understand it." The correct fix is maybe to stop properly the Tk thread. (Example: Run test_tk in a subprocess? Call tk.quit()?) ---------- components: +XML -Tests nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 00:27:42 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 18 Sep 2012 22:27:42 +0000 Subject: [issue15144] Possible integer overflow in operations with addresses and sizes. In-Reply-To: <1340395368.97.0.504662983992.issue15144@psf.upfronthosting.co.za> Message-ID: <1348007262.15.0.0110413614213.issue15144@psf.upfronthosting.co.za> STINNER Victor added the comment: > Perhaps the three new macros should be made available in a .h file? Good idea. Maybe pymacros.h? These macros need to be documented (with a comment in the .h file) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 00:29:57 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 18 Sep 2012 22:29:57 +0000 Subject: [issue15923] Building from a fresh clone breaks on Parser/asdl_c.py In-Reply-To: <1347398039.31.0.775610002592.issue15923@psf.upfronthosting.co.za> Message-ID: <1348007397.74.0.0253329730027.issue15923@psf.upfronthosting.co.za> STINNER Victor added the comment: See also #15964. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 00:30:13 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 18 Sep 2012 22:30:13 +0000 Subject: [issue13888] test_builtin failure when run after test_tk In-Reply-To: <1327661656.8.0.445863136974.issue13888@psf.upfronthosting.co.za> Message-ID: <1348007413.51.0.82886905216.issue13888@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- components: +Tests, Tkinter -XML _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 00:32:24 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 18 Sep 2012 22:32:24 +0000 Subject: [issue15964] SyntaxError in asdl when building 2.7 with system Python 3 In-Reply-To: <1347978379.29.0.810502621141.issue15964@psf.upfronthosting.co.za> Message-ID: <1348007544.49.0.0569596882086.issue15964@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 00:35:22 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 18 Sep 2012 22:35:22 +0000 Subject: [issue15966] concurrent.futures: Executor.submit keyword arguments may not be called 'fn' (or 'self') In-Reply-To: <1347982368.75.0.56994107832.issue15966@psf.upfronthosting.co.za> Message-ID: <1348007722.61.0.457902717061.issue15966@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The patch looks ok to me. At least passing "fn" as keyword arg should be fixed. Passing "self" as keyword arg admittedly sounds a bit awkward. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 00:36:11 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 18 Sep 2012 22:36:11 +0000 Subject: [issue15967] Slaves don't seem to clean up their /tmp mess if a step fails. In-Reply-To: <1347994629.04.0.316608804637.issue15967@psf.upfronthosting.co.za> Message-ID: <1348007771.18.0.831121114969.issue15967@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > All my slaves' /tmp's are polluted with regrtest fluff. Which "regrtest fluff" exactly? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 02:22:57 2012 From: report at bugs.python.org (Julian Berman) Date: Wed, 19 Sep 2012 00:22:57 +0000 Subject: [issue11664] Add patch method to unittest.TestCase In-Reply-To: <1300999439.71.0.376555102459.issue11664@psf.upfronthosting.co.za> Message-ID: <1348014177.61.0.048064236213.issue11664@psf.upfronthosting.co.za> Julian Berman added the comment: It's slightly less confusing -- "Where do I patch" is the question that will never go away, and the fact that you don't have the `sys` module imported is a small hint that you should be doing patch(mymodule.sys, "path") not patch("sys.path"). Also, the fact that patch is more common doesn't reflect the fact that most of those times, patch.object would have worked as well, but it's longer to type (or people aren't as aware of it), since most of the time you're patching things in a module you've imported already (at least this is true of me, and I've started using patch.object whenever it works and only falling back on patch). Also, Twisted's TestCase (which already has a method to implement patch) is functionally equivalent to patch.object, not patch, in case you wanted a precedent. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 02:24:36 2012 From: report at bugs.python.org (Michael Foord) Date: Wed, 19 Sep 2012 00:24:36 +0000 Subject: [issue11664] Add patch method to unittest.TestCase In-Reply-To: <1300999439.71.0.376555102459.issue11664@psf.upfronthosting.co.za> Message-ID: <1348014276.27.0.256981294291.issue11664@psf.upfronthosting.co.za> Michael Foord added the comment: Well, people vote with their code and find mock.patch vastly more useful than patch.object... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 02:30:26 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 19 Sep 2012 00:30:26 +0000 Subject: [issue7712] Add a context manager to change cwd in test.test_support and run the test suite in a temp dir. In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za> Message-ID: <1348014626.54.0.576137829755.issue7712@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 02:31:16 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 19 Sep 2012 00:31:16 +0000 Subject: [issue15304] Wrong path in test.support.temp_cwd() error message In-Reply-To: <1341833239.95.0.652006223487.issue15304@psf.upfronthosting.co.za> Message-ID: <1348014676.92.0.98543487204.issue15304@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: -> ezio.melotti nosy: +ezio.melotti type: -> behavior versions: +Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 02:31:49 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 19 Sep 2012 00:31:49 +0000 Subject: [issue15415] Add temp_dir() and change_cwd() to test.support In-Reply-To: <1342905198.6.0.0438176504742.issue15415@psf.upfronthosting.co.za> Message-ID: <1348014709.54.0.0581264776852.issue15415@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti, flox type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 02:33:12 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 19 Sep 2012 00:33:12 +0000 Subject: [issue11664] Add patch method to unittest.TestCase In-Reply-To: <1300999439.71.0.376555102459.issue11664@psf.upfronthosting.co.za> Message-ID: <1348014792.26.0.817044157633.issue11664@psf.upfronthosting.co.za> R. David Murray added the comment: I actually agree with Julian here. I much prefer patch.object and do my best to avoid mock.patch. support.patch is also equivalent to patch.object and not patch. That doesn't change the fact that other people prefer mock.patch, of course. I think mock.patch is too "magical" for my taste. There is something I don't like about the dynamic import, even though I can't really tell you what it is :) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 02:35:40 2012 From: report at bugs.python.org (Julian Berman) Date: Wed, 19 Sep 2012 00:35:40 +0000 Subject: [issue11664] Add patch method to unittest.TestCase In-Reply-To: <1300999439.71.0.376555102459.issue11664@psf.upfronthosting.co.za> Message-ID: <1348014940.68.0.230517275758.issue11664@psf.upfronthosting.co.za> Julian Berman added the comment: With all due respect, your response pretty much ignored mine completely. That's OK, I've agreed with you that patch seems more common. I'll point you additionally though to the fact that ?ric's original post also used patch.object's semantics, as does test.test_support.swap_attr and patch. I don't know how hard I can push here though, since again, this would be really confusing to have it have the same name. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 02:36:44 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 19 Sep 2012 00:36:44 +0000 Subject: [issue11664] Add patch method to unittest.TestCase In-Reply-To: <1300999439.71.0.376555102459.issue11664@psf.upfronthosting.co.za> Message-ID: <1348015004.28.0.0215038917025.issue11664@psf.upfronthosting.co.za> Chris Jerdonek added the comment: What about patch_object()? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 02:38:54 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 19 Sep 2012 00:38:54 +0000 Subject: [issue15951] string.Formatter returns str for empty unicode template In-Reply-To: <1347796556.49.0.9624827569.issue15951@psf.upfronthosting.co.za> Message-ID: <1348015134.92.0.914227288563.issue15951@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attached is a proposed patch. Some explanation behind the patch that stems from the above comments: The following is an example of Formatter.format() returning str in the current implementation that would break if we made Formatter.format() return unicode whenever format_string is unicode: >>> f.format(u"{0}", "\xc3\xa9") # UTF-8 encoded "e-acute". '\xc3\xa9' (It would break with a UnicodeDecodeError because 'ascii' is the default encoding.) Since we can't change Formatter.format(format_string) to return unicode whenever format_string is unicode without breaking existing code, I believe the best we can do is to document the departure from PEP 3101. Since the caller has to handle return values of type str anyways, I don't think it helps to ensure that more return values are unicode. ---------- Added file: http://bugs.python.org/file27222/issue-15951-2-branch27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 03:33:17 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 19 Sep 2012 01:33:17 +0000 Subject: [issue11664] Add patch method to unittest.TestCase In-Reply-To: <1300999439.71.0.376555102459.issue11664@psf.upfronthosting.co.za> Message-ID: <1348018397.21.0.830884733914.issue11664@psf.upfronthosting.co.za> Ezio Melotti added the comment: IMHO a setattr-like API seems the obvious choice here, so that's what I would expect. I haven't used mock, so I wasn't familiar with mock.patch, but after skimming through the mock docs a bit I think I have to agree with Julian and RDM. In addition, I'm not sure we need TestCase.patch now that we have already have mock.patch(.object) in the stdlib. If we still add it, it would probably make more sense as a "vanilla" patch that doesn't depend on mock. > a helper TestCase.patch should delegate to unittest.mock.patch Does it mean it will return MagicMocks? > patch.object would have worked as well, but it's longer to type If mock.patch requires a FQN to work the call might even be longer: patch('package.subpackage.module.function') vs patch.object(module, 'function', newfunc) (assuming "from package.subpackage import module", which is not uncommon if we are testing that specific module) > What about patch_object()? patchobj()? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 03:49:19 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 19 Sep 2012 01:49:19 +0000 Subject: [issue8996] Add a default role to allow writing bare `len` instead of :func:`len` In-Reply-To: <1276528152.92.0.60611534239.issue8996@psf.upfronthosting.co.za> Message-ID: <1348019359.39.0.196860534718.issue8996@psf.upfronthosting.co.za> Ezio Melotti added the comment: I think I'm -1 on this, for the following reasons: * it's less explicit; * it gives you less control (I'm thinking e.g. at the () added by :func:/:meth: but not :class:, so that :func:`int` and :class:`int` are rendered in different ways); * even though this might have been OK if we used it from the beginning, now we are using specific roles everywhere, and changing them will either result in a mass update or in a mixed style -- none of which are desirable; * if the mass update is done and later on we change our mind, it's difficult to switch back from `...` to :role:`...`. Disabling `...` sounds OK to me (I don't think we have many left, if any). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 03:50:27 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 19 Sep 2012 01:50:27 +0000 Subject: [issue15965] AT_FDCWD is 0xffd19553 on Solaris 10, resulting in compiler warnings. In-Reply-To: <1347981172.74.0.722168531343.issue15965@psf.upfronthosting.co.za> Message-ID: <3XM3tV3XmQzP1K@mail.python.org> Roundup Robot added the comment: New changeset 974a4cae6094 by Trent Nelson in branch 'default': #15965: Explicitly cast AT_FDCWD as (int). http://hg.python.org/cpython/rev/974a4cae6094 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 04:09:27 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 19 Sep 2012 02:09:27 +0000 Subject: [issue7665] test_urllib2 and test_ntpath fail if path contains "\" In-Reply-To: <1263142226.0.0.91918347375.issue7665@psf.upfronthosting.co.za> Message-ID: <1348020567.28.0.285484301378.issue7665@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +haypo stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 04:20:40 2012 From: report at bugs.python.org (Trent Nelson) Date: Wed, 19 Sep 2012 02:20:40 +0000 Subject: [issue15965] AT_FDCWD is 0xffd19553 on Solaris 10, resulting in compiler warnings. In-Reply-To: <1347981172.74.0.722168531343.issue15965@psf.upfronthosting.co.za> Message-ID: <1348021240.77.0.141773673312.issue15965@psf.upfronthosting.co.za> Changes by Trent Nelson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 04:46:49 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 19 Sep 2012 02:46:49 +0000 Subject: [issue11454] email.message import time In-Reply-To: <1299701237.24.0.992920521308.issue11454@psf.upfronthosting.co.za> Message-ID: <1348022809.82.0.409326282992.issue11454@psf.upfronthosting.co.za> Ezio Melotti added the comment: re.compile seems twice as fast as pickle.loads: import re import pickle import timeit N = 100000 s = "r = re.compile('[\\udc80-\\udcff]')" t = timeit.Timer(s, 'import re') print("%6.2f <- re.compile" % t.timeit(number=N)) s = "r = pickle.loads(p)" p = pickle.dumps(re.compile('[\udc80-\udcff]')) t = timeit.Timer(s, 'import pickle; from __main__ import p') print("%6.2f <- pickle.loads" % t.timeit(number=N)) Result: 5.59 <- re.compile 11.04 <- pickle.loads See also #2679. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 05:45:15 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 19 Sep 2012 03:45:15 +0000 Subject: [issue15960] logging.shutdown should cope with IO errors from handler.release methods In-Reply-To: <1347954020.8.0.36541508073.issue15960@psf.upfronthosting.co.za> Message-ID: <1348026315.23.0.981268013448.issue15960@psf.upfronthosting.co.za> Nick Coghlan added the comment: The particular app that is getting affected is clearing out and rebuilding the logging configuration without restarting in response to a notification that the application config has changed. This was working OK on 2.6, but started misbehaving when ported to 2.7. It's http://pypi.python.org/pypi/ConcurrentLogHandler that's calling self.stream.flush() inside release(), and I suspect that *is* a bug on that side as well. It's also possible that we should just be skipping the use of ConcurrentLogHandler entirely on 2.7, but I haven't looked into the feasibility of that as yet. This specific bug report is just because I noticed that the stdlib is *trying* to be tolerant of handler misbehaviour, but not quite succeeding in this particular case. Perhaps we should be writing something out to stderr when ignoring one of these errors? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 05:46:20 2012 From: report at bugs.python.org (Joshua Biagio) Date: Wed, 19 Sep 2012 03:46:20 +0000 Subject: [issue15970] ElementTree HTML serialization incorrect for , Message-ID: <1348026380.02.0.662051799593.issue15970@psf.upfronthosting.co.za> New submission from Joshua Biagio: There seems to be a very minor bug in the ElementTree.py file, for the so-called 'empty' elements that are serialized without a closing tag. The HTML_EMPTY tuple/set is used to lookup these tags. In the Lib/xml/etree/ElementTree.py file, the HTML_EMPTY tuple is created like: HTML_EMPTY = ("area", "base", "basefont", "br", "col", "frame", "hr", "img", "input", "isindex", "link", "meta" "param") There is a missing comma between "meta" and "param". I'm not sure if this is intended behavior. The line should be replaced with: HTML_EMPTY = ("area", "base", "basefont", "br", "col", "frame", "hr", "img", "input", "isindex", "link", "meta", "param") ---------- components: Library (Lib), XML messages: 170699 nosy: Joshua.Biagio priority: normal severity: normal status: open title: ElementTree HTML serialization incorrect for , versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 05:47:45 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 19 Sep 2012 03:47:45 +0000 Subject: [issue15971] Sporadic failure in test_dump_tracebacks_later_file (test_faulthandler) Message-ID: <1348026465.86.0.879721154604.issue15971@psf.upfronthosting.co.za> New submission from Ezio Melotti: Seen on http://buildbot.python.org/all/builders/AMD64%20Lion%203.x/builds/428/steps/test/logs/stdio ====================================================================== FAIL: test_dump_tracebacks_later_file (test.test_faulthandler.FaultHandlerTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/ambv/Buildbot/3.x.langa-lion/build/Lib/test/test_faulthandler.py", line 490, in test_dump_tracebacks_later_file self.check_dump_tracebacks_later(file=True) File "/Users/ambv/Buildbot/3.x.langa-lion/build/Lib/test/test_faulthandler.py", line 476, in check_dump_tracebacks_later filename, loops) File "/Users/ambv/Buildbot/3.x.langa-lion/build/Lib/test/test_faulthandler.py", line 460, in _check_dump_tracebacks_later self.assertRegex(trace, regex) AssertionError: Regex didn't match: '^Timeout \\(0:00:00.500000\\)!\\nThread 0x[0-9a-f]+:\\n File "", line 9 in func\n File "", line 20 in $' not found in 'Timeout (0:00:00.500000)!\nThread 0x00007fff77d85960:\n File "", line 10 in func\n File "", line 20 in ' ---------------------------------------------------------------------- Ran 30 tests in 126.504s The regex expects the failure to be at "line 9 in func", but the failure happens at "line 10". ---------- assignee: haypo components: Tests messages: 170700 nosy: ezio.melotti, haypo, lukasz.langa priority: normal severity: normal stage: needs patch status: open title: Sporadic failure in test_dump_tracebacks_later_file (test_faulthandler) type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 06:31:06 2012 From: report at bugs.python.org (Julian Berman) Date: Wed, 19 Sep 2012 04:31:06 +0000 Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za> Message-ID: <1348029066.58.0.384357484146.issue7559@psf.upfronthosting.co.za> Changes by Julian Berman : ---------- nosy: +Julian _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 07:26:20 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 19 Sep 2012 05:26:20 +0000 Subject: [issue15970] ElementTree HTML serialization incorrect for , In-Reply-To: <1348026380.02.0.662051799593.issue15970@psf.upfronthosting.co.za> Message-ID: <3XM8gK50GRzQMx@mail.python.org> Roundup Robot added the comment: New changeset 3498ffd3cdee by Ezio Melotti in branch '2.7': #15970: xml.etree.ElementTree now serializes correctly the empty HTML elements "meta" and "param". http://hg.python.org/cpython/rev/3498ffd3cdee New changeset 17c528cff63f by Ezio Melotti in branch '3.2': #15970: xml.etree.ElementTree now serializes correctly the empty HTML elements "meta" and "param". http://hg.python.org/cpython/rev/17c528cff63f New changeset 19c74cadea95 by Ezio Melotti in branch 'default': #15970: merge with 3.2. http://hg.python.org/cpython/rev/19c74cadea95 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 07:29:09 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 19 Sep 2012 05:29:09 +0000 Subject: [issue15970] ElementTree HTML serialization incorrect for , In-Reply-To: <1348026380.02.0.662051799593.issue15970@psf.upfronthosting.co.za> Message-ID: <1348032548.99.0.71835626104.issue15970@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the report! ---------- assignee: -> ezio.melotti nosy: +ezio.melotti resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> behavior versions: -Python 2.6, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 07:42:49 2012 From: report at bugs.python.org (Trent Nelson) Date: Wed, 19 Sep 2012 05:42:49 +0000 Subject: [issue15967] Slaves don't seem to clean up their /tmp mess if a step fails. In-Reply-To: <1347994629.04.0.316608804637.issue15967@psf.upfronthosting.co.za> Message-ID: <1348033369.73.0.905231128821.issue15967@psf.upfronthosting.co.za> Trent Nelson added the comment: > > All my slaves' /tmp's are polluted with regrtest fluff. > Which "regrtest fluff" exactly? I was being lazy when I wrote that. By "regrtest fluff" I was referring to lingering files/directories in /tmp, owned by cpython, starting with tmp*. Few examples below. openbsd51-x64-1% ls -l /tmp total 32 drwxr-xr-x 2 root wheel 512 Aug 18 05:40 aucat drwx------ 4 cpython wheel 512 Sep 19 02:26 tmp03dyjv -rw------- 1 cpython wheel 3 Sep 19 02:03 tmp4t3_bk -rw------- 1 cpython wheel 3 Sep 18 05:02 tmp5ljha3 -rw------- 1 cpython wheel 3 Sep 18 05:02 tmp7p3sht -rw------- 1 cpython wheel 0 Sep 19 05:34 tmpCFMYVJ -rw------- 1 cpython wheel 3 Sep 19 02:34 tmpcnwqcn -rw------- 1 cpython wheel 3 Sep 19 02:34 tmpk0gthu -rw------- 1 cpython wheel 3 Sep 19 02:03 tmpmf973r -rw------- 1 cpython wheel 0 Sep 19 05:34 tmpqO20FC dragonfly30-x86-1% ls -l /tmp | grep cpython drwx------ 1 cpython wheel 0 Aug 22 03:46 ssh-v3WDeO7FhO -rw------- 1 cpython wheel 3 Sep 14 16:05 tmp31idrc -rw------- 1 cpython wheel 3 Sep 11 15:58 tmp34z8iv -rw------- 1 cpython wheel 3 Sep 18 05:06 tmp43uhjt -rw------- 1 cpython wheel 3 Sep 19 02:03 tmp4jypkx -rw------- 1 cpython wheel 3 Sep 12 04:31 tmp4odqso -rw------- 1 cpython wheel 3 Sep 12 20:36 tmp6acej6 -rw------- 1 cpython wheel 3 Sep 12 16:22 tmp9m5vie -rw------- 1 cpython wheel 3 Sep 11 16:15 tmp9oj443 -rw------- 1 cpython wheel 3 Sep 12 20:10 tmpb086ow -rw------- 1 cpython wheel 3 Sep 12 14:02 tmpcm0s2g -rw------- 1 cpython wheel 3 Sep 11 16:15 tmpd81jie -rw------- 1 cpython wheel 3 Sep 12 17:05 tmpdm8vv9 -rw------- 1 cpython wheel 3 Sep 15 23:01 tmpef4d2m -rw------- 1 cpython wheel 3 Sep 18 05:06 tmpel_xi_ -rw------- 1 cpython wheel 3 Sep 12 04:31 tmpf41fj3 -rw------- 1 cpython wheel 3 Sep 11 12:08 tmpi94ajz -rw------- 1 cpython wheel 3 Sep 19 02:25 tmpilpy7y -rw------- 1 cpython wheel 3 Sep 15 22:27 tmpiq1yo9 -rw------- 1 cpython wheel 3 Sep 13 16:36 tmpkq6d8i -rw------- 1 cpython wheel 3 Sep 11 12:28 tmpkxqa4a -rw------- 1 cpython wheel 3 Sep 19 02:25 tmpl35290 -rw------- 1 cpython wheel 3 Sep 11 12:08 tmpn1dq2c -rw------- 1 cpython wheel 3 Sep 12 17:05 tmpnxrnxp -rw------- 1 cpython wheel 3 Sep 19 02:03 tmpocz5ux -rw------- 1 cpython wheel 3 Sep 14 16:05 tmppsebwf -rw------- 1 cpython wheel 3 Sep 11 13:50 tmpptpcep -rw------- 1 cpython wheel 3 Sep 15 22:27 tmpqk1s3k -rw------- 1 cpython wheel 3 Sep 12 14:02 tmprk8uxy -rw------- 1 cpython wheel 3 Sep 11 13:50 tmprqmmfw -rw------- 1 cpython wheel 3 Sep 13 16:36 tmps99aky -rw------- 1 cpython wheel 3 Sep 11 15:58 tmpsfsmoc -rw------- 1 cpython wheel 3 Sep 12 20:36 tmpt8_0vu -rw------- 1 cpython wheel 3 Sep 15 23:01 tmpthosfe -rw------- 1 cpython wheel 3 Sep 11 12:28 tmpwhsp9p -rw------- 1 cpython wheel 3 Sep 12 20:10 tmpy5774k -rw------- 1 cpython wheel 3 Sep 12 16:22 tmpzgafbz oxygen% ls -l /tmp | grep cpython drwxr-xr-x 3 root cpython 96 Aug 31 15:41 screens -rw------- 1 cpython cpython 0 Sep 19 05:30 tmp249ZUA drwx------ 2 cpython cpython 96 Sep 19 05:31 tmpAvStO1 drwx------ 2 cpython cpython 96 Sep 19 05:31 tmpFLfr2x drwx------ 2 cpython cpython 96 Sep 19 05:31 tmpOYB_X6 drwx------ 2 cpython cpython 96 Sep 19 05:31 tmpP1Hsdf -rw------- 1 cpython cpython 0 Sep 19 05:30 tmpTqctqQ drwx------ 2 cpython cpython 96 Sep 19 05:31 tmpUW1Gov drwx------ 2 cpython cpython 96 Sep 19 05:31 tmpYU0lzE drwx------ 2 cpython cpython 96 Sep 19 05:31 tmpazia2w drwx------ 2 cpython cpython 96 Sep 19 05:31 tmpgemyJY drwx------ 2 cpython cpython 96 Sep 19 05:31 tmpkfg0aZ drwx------ 2 cpython cpython 96 Sep 19 05:31 tmpt1e0Jc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 07:49:37 2012 From: report at bugs.python.org (Trent Nelson) Date: Wed, 19 Sep 2012 05:49:37 +0000 Subject: [issue15967] Slaves don't seem to clean up their /tmp mess if a step fails. In-Reply-To: <1347994629.04.0.316608804637.issue15967@psf.upfronthosting.co.za> Message-ID: <1348033777.73.0.474055115856.issue15967@psf.upfronthosting.co.za> Trent Nelson added the comment: > Cleanup on test failure is supposed to be done. Cleanup on crash or > buildbot timeout isn't done as far as I know (and that was a concern I > had with the changes made to support.TESTFN and the cwd, but I didn't > articulate it very well). Ah, yeah, this is almost certainly to do with crash/timeout. I remember running into this way back in 2008 when I was running a few slaves. Personally I think the best solution is to have the test framework allocate a single test directory, inform the parent* as to what it is, then make sure all temp files are rooted in it. The parent* should then rm -rf the tempdir at the end of the run as a final 'catch all'. parent*: this will mean different things in different contexts... could be the Tools/run_tests.py wrapper, buildbot slave wrapper, etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 08:27:02 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 19 Sep 2012 06:27:02 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za> Message-ID: <1348036022.43.0.163067395219.issue15896@psf.upfronthosting.co.za> Ronald Oussoren added the comment: The workaround should not be implemented in os.read because it is a very thin wrapper around the system call and should stay that way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 08:55:45 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 19 Sep 2012 06:55:45 +0000 Subject: [issue15967] Slaves don't seem to clean up their /tmp mess if a step fails. In-Reply-To: <1347994629.04.0.316608804637.issue15967@psf.upfronthosting.co.za> Message-ID: <1348037745.31.0.951655702005.issue15967@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > Personally I think the best solution is to have the test framework allocate a single test directory This is partially done. See here: http://hg.python.org/cpython/file/19c74cadea95/Lib/test/regrtest.py#l1810 # Run the tests in a context manager that temporary changes the CWD to a # temporary and writable directory. regrtest sets things up such that the current working directory is supposed to be this temp directory (constructed from _make_temp_dir_for_build()). But the tests adhere to this only weakly. Many or most tests create their own temp directory rather than relying on the caller having set the current working directory to a temp directory. If the tests used a common API, we could control this behavior globally. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 08:55:56 2012 From: report at bugs.python.org (Vitaly) Date: Wed, 19 Sep 2012 06:55:56 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za> Message-ID: <1348037756.11.0.83305283696.issue15896@psf.upfronthosting.co.za> Vitaly added the comment: > The workaround should not be implemented in os.read because it is a very thin wrapper around the system call and should stay that way. Although this issue was initially filed as "Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS", the subsequent investigation revealed that this has nothing to do with a forked child failing. Rather, it's a bug in the read() syscall on Mac OS X. What would be a more appropriate place to work around this read() syscall bug than os.read? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 09:24:06 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 19 Sep 2012 07:24:06 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za> Message-ID: <1348039446.55.0.389105682633.issue15896@psf.upfronthosting.co.za> Ronald Oussoren added the comment: How can you work around it in os.read, without knowing anything about what the file descriptor represents? Just triggering on getting on EINVAL error when calling read might trigger other problems and might even be a valid result for some file descriptors (for example for custom file systems or device files). And what kind of workaround do you propose? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 09:47:26 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 19 Sep 2012 07:47:26 +0000 Subject: [issue14783] Make int() and str() docstrings correct In-Reply-To: <1336751413.58.0.519130225761.issue14783@psf.upfronthosting.co.za> Message-ID: <1348040846.54.0.657732126674.issue14783@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > +.. function:: int(number=0) First argument is named "x". >>> int(number=42) Traceback (most recent call last): File "", line 1, in TypeError: 'number' is an invalid keyword argument for this function >>> int(x=42) 42 + int(string, base=10) Here can be not only string, but bytes or bytearray. >>> int('42', 6) 26 >>> int(b'42', 6) 26 >>> int(bytearray(b'42'), 6) 26 ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 09:51:05 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 19 Sep 2012 07:51:05 +0000 Subject: [issue6471] errno and strerror attributes incorrectly set on socket errors wrapped by urllib In-Reply-To: <1247432074.99.0.825435411389.issue6471@psf.upfronthosting.co.za> Message-ID: <1348041065.85.0.49438838444.issue6471@psf.upfronthosting.co.za> Ezio Melotti added the comment: > I seem to remember writing code that fished the wrapped error > out using one of those attributrs... That would be err.reason: from urllib.request import urlopen try: urlopen('http://www.pythonfoobarbaz.org') except Exception as exc: print('err:', err) print('repr(err):', repr(err)) print('err.reason:', err.reason) print('repr(err.reason):', repr(err.reason)) prints: err: repr(err): URLError(gaierror(-2, 'Name or service not known'),) err.reason: [Errno -2] Name or service not known repr(err.reason): gaierror(-2, 'Name or service not known') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 09:51:48 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 19 Sep 2012 07:51:48 +0000 Subject: [issue6471] errno and strerror attributes incorrectly set on socket errors wrapped by urllib In-Reply-To: <1247432074.99.0.825435411389.issue6471@psf.upfronthosting.co.za> Message-ID: <1348041108.4.0.566713635073.issue6471@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 09:58:09 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 19 Sep 2012 07:58:09 +0000 Subject: [issue14783] Make int() and str() docstrings correct In-Reply-To: <1336751413.58.0.519130225761.issue14783@psf.upfronthosting.co.za> Message-ID: <1348041489.19.0.418718928189.issue14783@psf.upfronthosting.co.za> Ezio Melotti added the comment: > First argument is named "x". Sometimes the doc uses "better" names to improve clarity when the argument is not supposed to be called as keyword arg. > Here can be not only string, but bytes or bytearray. The same applies here. "string" is also used in the error message (int() can't convert non-string with explicit base). If bytes/bytearrays are accepted too it could be mentioned later in the prose. Otherwise we could use x for both, but the distinction would be less clear. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 10:33:04 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 19 Sep 2012 08:33:04 +0000 Subject: [issue11454] email.message import time In-Reply-To: <1299701237.24.0.992920521308.issue11454@psf.upfronthosting.co.za> Message-ID: <1348043584.24.0.869560792961.issue11454@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > If I change the regex to _has_surrogates = re.compile('[\udc80-\udcff]').search, the tests still pass but there's no improvement on startup time (note: the previous regex was matching all the surrogates in this range too, however I'm not sure how well this is tested). What about _has_surrogates = re.compile('[^\udc80-\udcff]*\Z').match ? ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 10:49:57 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 19 Sep 2012 08:49:57 +0000 Subject: [issue11454] email.message import time In-Reply-To: <1299701237.24.0.992920521308.issue11454@psf.upfronthosting.co.za> Message-ID: <1348044597.65.0.0671540879274.issue11454@psf.upfronthosting.co.za> Ezio Melotti added the comment: > What about _has_surrogates = re.compile('[^\udc80-\udcff]*\Z').match ? The runtime is a bit slower than re.compile('[\udc80-\udcff]').search, but otherwise it's faster than all the other alternatives. I haven't checked the startup-time, but I suspect it won't be better -- maybe even worse. ---------- Added file: http://bugs.python.org/file27223/issue11454_surr1.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 11:03:21 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 19 Sep 2012 09:03:21 +0000 Subject: [issue11454] email.message import time In-Reply-To: <1348044597.65.0.0671540879274.issue11454@psf.upfronthosting.co.za> Message-ID: <201209191203.02205.storchaka@gmail.com> Serhiy Storchaka added the comment: > I haven't checked the startup-time, but I suspect it won't be better -- maybe even worse. I suppose it will be much better. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 11:29:39 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 19 Sep 2012 09:29:39 +0000 Subject: [issue11454] email.message import time In-Reply-To: <1299701237.24.0.992920521308.issue11454@psf.upfronthosting.co.za> Message-ID: <1348046979.1.0.979049570522.issue11454@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Startup-time: $ ./python -m timeit -s 'import re' 're.compile("([^\ud800-\udbff]|\A)[\udc00-\udfff]([^\udc00-\udfff]|\Z)").search; re.purge()' 100 loops, best of 3: 4.16 msec per loop $ ./python -m timeit -s 'import re' 're.purge()' 're.compile("[\udc80-\udcff]").search' 100 loops, best of 3: 5.72 msec per loop $ ./python -m timeit 'h=lambda s, p=set(map(chr, range(0xDC80, 0xDCFF+1))): any(c in p for c in s)' 10000 loops, best of 3: 60.5 usec per loop $ ./python -m timeit -s 'import re' 're.purge()' 're.compile("(?![^\udc80-\udcff])").search' 1000 loops, best of 3: 401 usec per loop $ ./python -m timeit -s 'import re' 're.purge()' 're.compile("[^\udc80-\udcff]*\Z").match' 1000 loops, best of 3: 427 usec per loop Runtime: $ ./python -m timeit -s 'import re; h=re.compile("([^\ud800-\udbff]|\A)[\udc00-\udfff]([^\udc00-\udfff]|\Z)").search; s = "A"*1000' 'h(s)' 1000 loops, best of 3: 245 usec per loop $ ./python -m timeit -s 'import re; h=re.compile("[\udc80-\udcff]").search; s = "A"*1000' 'h(s)' 10000 loops, best of 3: 30.1 usec per loop $ ./python -m timeit -s 'h=lambda s, p=set(map(chr, range(0xDC80, 0xDCFF+1))): any(c in p for c in s); s = "A"*1000' 'h(s)' 10000 loops, best of 3: 164 usec per loop $ ./python -m timeit -s 'import re; h=re.compile("(?![^\udc80-\udcff])").search; s = "A"*1000' 'h(s)' 10000 loops, best of 3: 98.3 usec per loop $ ./python -m timeit -s 'import re; h=re.compile("[^\udc80-\udcff]*\Z").match; s = "A"*1000' 'h(s)' 10000 loops, best of 3: 34.6 usec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 11:32:06 2012 From: report at bugs.python.org (Michael Foord) Date: Wed, 19 Sep 2012 09:32:06 +0000 Subject: [issue11664] Add patch method to unittest.TestCase In-Reply-To: <1300999439.71.0.376555102459.issue11664@psf.upfronthosting.co.za> Message-ID: <1348047126.6.0.854690363841.issue11664@psf.upfronthosting.co.za> Michael Foord added the comment: It maybe that patch.object is a more natural interface to the small sample of people commenting here, in which case great - that's what it's there for. However in common usage patch is used around two orders of magnitude more. I've seen large codebases with hundreds of uses of patch and only a handful of uses of patch.object. To support the *minor* use case and not the major use case in TestCase would be an inanity. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 11:32:23 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 19 Sep 2012 09:32:23 +0000 Subject: [issue15946] Windows 8 x64 - IO-Error In-Reply-To: <1347713860.36.0.872797660614.issue15946@psf.upfronthosting.co.za> Message-ID: <1348047143.75.0.862929512433.issue15946@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I think it should be possible to add a wait=False parameter to rmtree which makes it block until the directory is gone away. This could be similar to the test.support feature added in #15496. For compatibility, such a flag should default to False, and users need to be aware that this may block "indefinitely". I'd be opposed to specifying a timeout - users who need that can use the non-blocking version, and then loop themselves (or we expose a separate wait function with a timeout). Of course, such a feature could not be added to 2.7. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 11:40:46 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 19 Sep 2012 09:40:46 +0000 Subject: [issue11454] email.message import time In-Reply-To: <1299701237.24.0.992920521308.issue11454@psf.upfronthosting.co.za> Message-ID: <1348047646.17.0.608648133117.issue11454@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Faster set-version: $ ./python -m timeit -s 'h=lambda s, hn=set(map(chr, range(0xDC80, 0xDD00))).isdisjoint: not hn(s); s = "A"*1000' 'h(s)' 10000 loops, best of 3: 43.8 usec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 11:45:42 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 19 Sep 2012 09:45:42 +0000 Subject: [issue15276] unicode format does not really work in Python 2.x In-Reply-To: <1347862927.66.0.700416644802.issue15276@psf.upfronthosting.co.za> Message-ID: <50599444.8060006@v.loewis.de> Martin v. L?wis added the comment: > What do you think? [Even though I wasn't asked] I think we may need to close the issue as "won't fix". Depending on the exact change propsosed, it may be that the return type for existing operations might change, which shouldn't be done in a bug fix release. People running into this issue should port to Python 3 (IMO). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 12:34:44 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 19 Sep 2012 10:34:44 +0000 Subject: [issue15964] SyntaxError in asdl when building 2.7 with system Python 3 In-Reply-To: <1347978379.29.0.810502621141.issue15964@psf.upfronthosting.co.za> Message-ID: <1348050884.11.0.941135197667.issue15964@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The case that "python" is a Python 3 binary is not a supported installation (see PEP 394). asdl_c.py works on both 2.x and 3.x unmodified in the 3.x branch, however, backporting this to 2.7 would be a new feature (support for building on systems where "python" is Python 3). The proper work-around is to "make touch" after a hg update to bring the files in the right order. #15923 is really a separate issue since it complains about an actual bug in asdl_c.py. So I propose to close this as "won't fix". ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 12:40:46 2012 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 19 Sep 2012 10:40:46 +0000 Subject: [issue15966] concurrent.futures: Executor.submit keyword arguments may not be called 'fn' (or 'self') In-Reply-To: <1347982368.75.0.56994107832.issue15966@psf.upfronthosting.co.za> Message-ID: <1348051246.28.0.437963946727.issue15966@psf.upfronthosting.co.za> Mark Dickinson added the comment: Ah, I added the wrong Brian to the nosy. Sorry, Brian C. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 14:08:30 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 19 Sep 2012 12:08:30 +0000 Subject: [issue15971] Sporadic failure in test_dump_tracebacks_later_file (test_faulthandler) In-Reply-To: <1348026465.86.0.879721154604.issue15971@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Code of the failing test: ---- import faulthandler import time def func(timeout, repeat, cancel, file, loops): for loop in range(loops): faulthandler.dump_tracebacks_later(timeout, repeat=repeat, file=file) if cancel: faulthandler.cancel_dump_tracebacks_later() time.sleep(timeout * 5) # line 9 faulthandler.cancel_dump_tracebacks_later() # line 10 timeout = {timeout} repeat = {repeat} cancel = {cancel} loops = {loops} if {has_filename}: file = open({filename}, "wb") else: file = None func(timeout, repeat, cancel, file, loops) if file is not None: file.close() ---- If the test fails at line 10: it means that it failed to dump the traceback in 2.5 seconds, whereas the traceback must be dumped after a timeout of 0.5 second. Do you know if the system load of this particular buildbot is high? It would be nice to have the system load in the output of the buildbot. We might change the timeout, but it is already long. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 15:56:39 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 19 Sep 2012 13:56:39 +0000 Subject: [issue6471] errno and strerror attributes incorrectly set on socket errors wrapped by urllib In-Reply-To: <1247432074.99.0.825435411389.issue6471@psf.upfronthosting.co.za> Message-ID: <1348062999.61.0.145473392261.issue6471@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, of course. I should have reread the whole issue :) The backward compatibility is the big concern here. Regardless of what we do about that, we should at least fix this in 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 16:24:51 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 19 Sep 2012 14:24:51 +0000 Subject: [issue15415] Add temp_dir() and change_cwd() to test.support In-Reply-To: <1342905198.6.0.0438176504742.issue15415@psf.upfronthosting.co.za> Message-ID: <1348064691.95.0.13254000643.issue15415@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 16:46:55 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 19 Sep 2012 14:46:55 +0000 Subject: [issue11664] Add patch method to unittest.TestCase In-Reply-To: <1300999439.71.0.376555102459.issue11664@psf.upfronthosting.co.za> Message-ID: <1348066015.36.0.806258868632.issue11664@psf.upfronthosting.co.za> ?ric Araujo added the comment: A data point: at work I follow Pyramid testing guidelines which tell you not to import code under test at module level, but in your test functions, so that if you have an error your tests do start and you see the error under the test method. This means that I use mock.patch and not mock.patch.object, as my modules are not imported. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 16:49:01 2012 From: report at bugs.python.org (Michael Foord) Date: Wed, 19 Sep 2012 14:49:01 +0000 Subject: [issue11664] Add patch method to unittest.TestCase In-Reply-To: <1300999439.71.0.376555102459.issue11664@psf.upfronthosting.co.za> Message-ID: <1348066141.32.0.0312746051513.issue11664@psf.upfronthosting.co.za> Michael Foord added the comment: I think those guidelines are horrible and I've told the pyramid folks that. There is a related issue for unittest that failing to import a test module (due to a failed import in the test module for example) should not kill the test run but should create a "failing test" that shows the problem. This is all wandering off topic however... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 18:12:02 2012 From: report at bugs.python.org (John Taylor) Date: Wed, 19 Sep 2012 16:12:02 +0000 Subject: [issue15972] wrong error message for os.path.getsize Message-ID: <1348071122.36.0.302681706423.issue15972@psf.upfronthosting.co.za> New submission from John Taylor: import os.path a = [ r'c:\Windows\notepad.exe' ] print( os.path.getsize(a) ) Under Python 3.2.3, this error message is returned: File "c:\python32\lib\genericpath.py", line 49, in getsize return os.stat(filename).st_size TypeError: Can't convert 'list' object to str implicitly Under Python 3.3.0rc2, this error message is returned: File "c:\Python33\lib\genericpath.py", line 49, in getsize return os.stat(filename).st_size TypeError: an integer is required I feel like the 3.2.3 behavior is more accurate and would like to propose that the 3.3 error message says something about a list instead of an integer. ---------- components: Extension Modules messages: 170726 nosy: jftuga priority: normal severity: normal status: open title: wrong error message for os.path.getsize type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 18:27:13 2012 From: report at bugs.python.org (Christian Heimes) Date: Wed, 19 Sep 2012 16:27:13 +0000 Subject: [issue15972] wrong error message for os.path.getsize In-Reply-To: <1348071122.36.0.302681706423.issue15972@psf.upfronthosting.co.za> Message-ID: <1348072033.33.0.14081040529.issue15972@psf.upfronthosting.co.za> Christian Heimes added the comment: Linux: >>> os.stat([]) Traceback (most recent call last): File "", line 1, in FileNotFoundError: [Errno 2] No such file or directory: '' [60996 refs] >>> os.stat([None]) Traceback (most recent call last): File "", line 1, in TypeError: an integer is required [60993 refs] ---------- keywords: +3.3regression nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 18:29:44 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 19 Sep 2012 16:29:44 +0000 Subject: [issue15964] SyntaxError in asdl when building 2.7 with system Python 3 In-Reply-To: <1347978379.29.0.810502621141.issue15964@psf.upfronthosting.co.za> Message-ID: <1348072184.73.0.50522658646.issue15964@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > The case that "python" is a Python 3 binary is not a supported installation Just to clarify, in the original scenario, "python" did not refer to anything. From the original comment: $ python No such file or directory ("python2" and "python3" did refer to the respective versions.) > The proper work-around is to "make touch" after a hg update to bring the files in the right order. I had tried this in the 2.7 branch and got: $ make touch make: *** No rule to make target `touch'. Stop. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 18:40:31 2012 From: report at bugs.python.org (Christian Heimes) Date: Wed, 19 Sep 2012 16:40:31 +0000 Subject: [issue15964] SyntaxError in asdl when building 2.7 with system Python 3 In-Reply-To: <1347978379.29.0.810502621141.issue15964@psf.upfronthosting.co.za> Message-ID: <1348072831.62.0.701022266042.issue15964@psf.upfronthosting.co.za> Christian Heimes added the comment: > $ make touch > make: *** No rule to make target `touch'. Stop. Martin meant: touch Include/Python-ast.h Python/Python-ast.c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 18:54:37 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 19 Sep 2012 16:54:37 +0000 Subject: [issue15964] SyntaxError in asdl when building 2.7 with system Python 3 In-Reply-To: <1347978379.29.0.810502621141.issue15964@psf.upfronthosting.co.za> Message-ID: <1348073677.59.0.260189003148.issue15964@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Yes, that works. Rather than closing this as "won't fix," however, I would suggest that we document the workaround in the devguide. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 19:13:47 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 19 Sep 2012 17:13:47 +0000 Subject: [issue11454] email.message import time In-Reply-To: <1299701237.24.0.992920521308.issue11454@psf.upfronthosting.co.za> Message-ID: <1348074827.86.0.764951026998.issue11454@psf.upfronthosting.co.za> Changes by Ezio Melotti : Removed file: http://bugs.python.org/file27203/issue11454_surr1.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 19:13:53 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 19 Sep 2012 17:13:53 +0000 Subject: [issue11454] email.message import time In-Reply-To: <1299701237.24.0.992920521308.issue11454@psf.upfronthosting.co.za> Message-ID: <1348074833.19.0.0180266034111.issue11454@psf.upfronthosting.co.za> Changes by Ezio Melotti : Removed file: http://bugs.python.org/file27223/issue11454_surr1.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 19:54:42 2012 From: report at bugs.python.org (Vitaly) Date: Wed, 19 Sep 2012 17:54:42 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za> Message-ID: <1348077282.82.0.0829988915146.issue15896@psf.upfronthosting.co.za> Vitaly added the comment: > And what kind of workaround do you propose? [os.read(fd, buffersize)] I am thinking about these options: Option 1: Fix breakages as they are discovered at higher level (above os.read) as needed in places where usage semantics are known, and address the issue via errata documentation (i.e., "On Mac OS X, don't make individual pipe read requests that would result in os.read() buffersize arg being above 127KB on non-blocking pipes."); should also check if the same issue occurs with sockets (e.g., socket.socketpair() instead of os.pipe()) to make the errata more complete. This may be perfectly acceptable and how things have worked for a long time. Option 2: Implement a work-around in the lowest common denominator wrapper function, so that anything in Python that needs to call read() and could benefit from this work-around, would call that wrapper instead of read(). The read() work-around might go something like this in *pseudocode*: if running_on_darwin and buffersize > 127KB: # fix up buffer size to work around a Mac OS x bug... if stat.S_ISFIFO(os.fstat(fd).st_mode): buffersize = 127KB Then do whatever else the read function is supposed to do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 20:03:18 2012 From: report at bugs.python.org (Lance Helsten) Date: Wed, 19 Sep 2012 18:03:18 +0000 Subject: [issue15973] Segmentation fault on timezone comparison Message-ID: <1348077797.35.0.854267629086.issue15973@psf.upfronthosting.co.za> New submission from Lance Helsten: In the 3.2.3 interpreter execute the following line: `None == datetime.timezone(datetime.timedelta())` The interpreter will crash with a `Segmentation fault: 11`. ---------- assignee: ronaldoussoren components: Macintosh files: CoreDump.txt messages: 170732 nosy: lanhel, ronaldoussoren priority: normal severity: normal status: open title: Segmentation fault on timezone comparison type: crash versions: Python 3.2 Added file: http://bugs.python.org/file27224/CoreDump.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 20:05:38 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 19 Sep 2012 18:05:38 +0000 Subject: [issue15974] Optional compact and colored output for regrest Message-ID: <1348077938.27.0.260547344914.issue15974@psf.upfronthosting.co.za> New submission from Brett Cannon: It would be nice to have something like sphinx's build output where the output is all kept on a single line except for failures. The color would help when scrolling through current output looking for failures. Currently I just look until the failure count switches, but I can spot color more quickly and easily. The reason for the compact output is that I simply don't typically care about passed tests, so why keep it visible? It also helps with noticing tests failures if those are the only tests that are kept in the terminal while the suite is running (obviously the output summary is still there). This also suggests having an option to write out to a file the test results to make it easier to see the exact test execution order (and if passed tests are commented out then it's easier to pass the file to --fromfile to re-run the fail tests). ---------- components: Tests messages: 170733 nosy: brett.cannon priority: low severity: normal stage: needs patch status: open title: Optional compact and colored output for regrest type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 20:15:44 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 19 Sep 2012 18:15:44 +0000 Subject: [issue15973] Segmentation fault on timezone comparison In-Reply-To: <1348077797.35.0.854267629086.issue15973@psf.upfronthosting.co.za> Message-ID: <1348078544.02.0.401946785428.issue15973@psf.upfronthosting.co.za> Stefan Krah added the comment: Reproducible also on Linux with Python 3.3. ---------- components: +Extension Modules -Macintosh nosy: +belopolsky, skrah stage: -> needs patch versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 20:18:49 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 19 Sep 2012 18:18:49 +0000 Subject: [issue15974] Optional compact and colored output for regrest In-Reply-To: <1348077938.27.0.260547344914.issue15974@psf.upfronthosting.co.za> Message-ID: <1348078729.47.0.118575911772.issue15974@psf.upfronthosting.co.za> Ezio Melotti added the comment: > It would be nice to have something like sphinx's build output where > the output is all kept on a single line except for failures. +1 I wanted the exact same thing for a long time but never had time to look at it. OTOH the more features are added to regrtest, the more complex it gets, and it's already fairly complex as it is. A better option might be to create a new unittest test runner, and then start switching regrtest to use more unittest bits (see #10967). That should allow us to select the runner we prefer, and that can also be available for regular unittests (there might even be something already). ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 20:20:21 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 19 Sep 2012 18:20:21 +0000 Subject: [issue15973] Segmentation fault on timezone comparison In-Reply-To: <1348077797.35.0.854267629086.issue15973@psf.upfronthosting.co.za> Message-ID: <1348078821.02.0.32041660838.issue15973@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- assignee: ronaldoussoren -> belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 20:23:18 2012 From: report at bugs.python.org (John Taylor) Date: Wed, 19 Sep 2012 18:23:18 +0000 Subject: [issue15973] Segmentation fault on timezone comparison In-Reply-To: <1348077797.35.0.854267629086.issue15973@psf.upfronthosting.co.za> Message-ID: <1348078998.88.0.667472462671.issue15973@psf.upfronthosting.co.za> John Taylor added the comment: Crashes Python 3.2.3 and Python 3.3.0rc2 on Windows 7 as well. ---------- nosy: +jftuga _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 20:23:27 2012 From: report at bugs.python.org (Ram Rachum) Date: Wed, 19 Sep 2012 18:23:27 +0000 Subject: [issue15975] Allow multiplying timedelta by Decimal Message-ID: <1348079007.17.0.324309830936.issue15975@psf.upfronthosting.co.za> New submission from Ram Rachum: Please allow multiplying timedelta by a Decimal: Python 3.3.0a1 (default, Mar 4 2012, 17:27:59) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import datetime >>> import decimal >>> decimal.Decimal('0.1')*datetime.timedelta(seconds=3) Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for *: 'Decimal' and 'datetime.timedelta' >>> ---------- components: Library (Lib) messages: 170737 nosy: cool-RR priority: normal severity: normal status: open title: Allow multiplying timedelta by Decimal type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 20:23:49 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 19 Sep 2012 18:23:49 +0000 Subject: [issue15974] Optional compact and colored output for regrest In-Reply-To: <1348077938.27.0.260547344914.issue15974@psf.upfronthosting.co.za> Message-ID: <1348079029.96.0.659311282172.issue15974@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I also think it would be better to refactor regrtest before adding this kind of complication. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 20:35:59 2012 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 19 Sep 2012 18:35:59 +0000 Subject: [issue15975] Allow multiplying timedelta by Decimal In-Reply-To: <1348079007.17.0.324309830936.issue15975@psf.upfronthosting.co.za> Message-ID: <1348079759.01.0.399812275403.issue15975@psf.upfronthosting.co.za> Mark Dickinson added the comment: Do you have a particular use-case in mind? Is there a reason that td * 0.1 or td / 10.0 aren't good enough? ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 20:41:17 2012 From: report at bugs.python.org (Ram Rachum) Date: Wed, 19 Sep 2012 18:41:17 +0000 Subject: [issue15975] Allow multiplying timedelta by Decimal In-Reply-To: <1348079007.17.0.324309830936.issue15975@psf.upfronthosting.co.za> Message-ID: <1348080077.69.0.441959127313.issue15975@psf.upfronthosting.co.za> Ram Rachum added the comment: This is for cases where I already have the number as a Decimal. Asking me to convert it to `float` myself is annoying. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 20:45:34 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 19 Sep 2012 18:45:34 +0000 Subject: [issue15973] Segmentation fault on timezone comparison In-Reply-To: <1348077797.35.0.854267629086.issue15973@psf.upfronthosting.co.za> Message-ID: <1348080334.82.0.170977769799.issue15973@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I cannot reproduce on a Mac with py3k tip. Python 3.3.0rc2+ (default:19c74cadea95, Sep 19 2012, 14:39:07) [GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.61)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import datetime >>> None == datetime.timezone(datetime.timedelta()) False Can anyone reproduce in a debug build and post a stack trace? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 20:47:04 2012 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 19 Sep 2012 18:47:04 +0000 Subject: [issue15975] Allow multiplying timedelta by Decimal In-Reply-To: <1348079007.17.0.324309830936.issue15975@psf.upfronthosting.co.za> Message-ID: <1348080424.16.0.119139294236.issue15975@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 20:50:17 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 19 Sep 2012 18:50:17 +0000 Subject: [issue15975] Allow multiplying timedelta by Decimal In-Reply-To: <1348079007.17.0.324309830936.issue15975@psf.upfronthosting.co.za> Message-ID: <1348080617.06.0.167254504048.issue15975@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: This is similar to issue 14262. If we decide that timedelta should play nice with Decimal, I would like to consider all related features. ---------- versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 20:52:47 2012 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 19 Sep 2012 18:52:47 +0000 Subject: [issue15975] Allow multiplying timedelta by Decimal In-Reply-To: <1348079007.17.0.324309830936.issue15975@psf.upfronthosting.co.za> Message-ID: <1348080767.92.0.314659135298.issue15975@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Asking me to convert it to `float` myself is annoying. Well, it's just a call to 'float', right? On the other side, we're looking at significant extra code to implement Decimal * timedelta, so there needs to be a good reason to add it. (And there's feature-creep involved, too; once we've got Decimal * timedelta, there will probably also be requests for timedelta / Decimal, and possibly timedelta / timedelta -> Decimal too). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 20:54:13 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 19 Sep 2012 18:54:13 +0000 Subject: [issue15975] Allow multiplying timedelta by Decimal In-Reply-To: <1348079007.17.0.324309830936.issue15975@psf.upfronthosting.co.za> Message-ID: <1348080853.66.0.292336002614.issue15975@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: In fact, this is a near-duplicate of #14262 becaus instead of >>> decimal.Decimal('0.1')*datetime.timedelta(seconds=3) one can always write >>> datetime.timedelta(seconds=decimal.Decimal('0.1')*3) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 20:55:00 2012 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 19 Sep 2012 18:55:00 +0000 Subject: [issue15975] Allow multiplying timedelta by Decimal In-Reply-To: <1348079007.17.0.324309830936.issue15975@psf.upfronthosting.co.za> Message-ID: <1348080900.15.0.417281232333.issue15975@psf.upfronthosting.co.za> Mark Dickinson added the comment: Agreed; +1 on folding this into issue 14262. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 20:55:28 2012 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 19 Sep 2012 18:55:28 +0000 Subject: [issue14262] Allow using decimals as arguments to `timedelta` In-Reply-To: <1331557988.1.0.944940856764.issue14262@psf.upfronthosting.co.za> Message-ID: <1348080928.58.0.243066178297.issue14262@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 20:56:54 2012 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 19 Sep 2012 18:56:54 +0000 Subject: [issue14262] Allow using decimals as arguments to `timedelta` In-Reply-To: <1331557988.1.0.944940856764.issue14262@psf.upfronthosting.co.za> Message-ID: <1348081014.11.0.585832697182.issue14262@psf.upfronthosting.co.za> Mark Dickinson added the comment: > (1) timedelta() does no loose precision over the entire range > of timedelta and rounding is documented; Agreed that this should be a requirement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 20:57:09 2012 From: report at bugs.python.org (Ram Rachum) Date: Wed, 19 Sep 2012 18:57:09 +0000 Subject: [issue15975] Allow multiplying timedelta by Decimal In-Reply-To: <1348079007.17.0.324309830936.issue15975@psf.upfronthosting.co.za> Message-ID: <1348081029.38.0.481928043746.issue15975@psf.upfronthosting.co.za> Ram Rachum added the comment: +1 on folding this into issue 14262. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 20:58:00 2012 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 19 Sep 2012 18:58:00 +0000 Subject: [issue15975] Allow multiplying timedelta by Decimal In-Reply-To: <1348079007.17.0.324309830936.issue15975@psf.upfronthosting.co.za> Message-ID: <1348081080.82.0.245239669724.issue15975@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- resolution: -> duplicate status: open -> closed superseder: -> Allow using decimals as arguments to `timedelta` _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 21:04:37 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 19 Sep 2012 19:04:37 +0000 Subject: [issue14262] Allow using decimals as arguments to `timedelta` In-Reply-To: <1331557988.1.0.944940856764.issue14262@psf.upfronthosting.co.za> Message-ID: <1348081477.0.0.696120550994.issue14262@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Mark wrote in his comment on issue 15975: > we're looking at significant extra code to implement > Decimal * timedelta Not necessarily. I will only support adding this feature if it can be done without making datetime know about Decimal. If we can agree on a lossless protocol to communicate floating pointing numbers of different base (or even more generally rational numbers), datetime module can support this protocol and allow all kinds of numbers in its constructors without much extra code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 21:05:21 2012 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 19 Sep 2012 19:05:21 +0000 Subject: [issue14262] Allow using decimals as arguments to `timedelta` In-Reply-To: <1331557988.1.0.944940856764.issue14262@psf.upfronthosting.co.za> Message-ID: <1348081521.8.0.469883636426.issue14262@psf.upfronthosting.co.za> Mark Dickinson added the comment: @Ram Rachum: out of curiosity, where are your Decimal objects coming from in the first place? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 21:07:38 2012 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 19 Sep 2012 19:07:38 +0000 Subject: [issue14262] Allow using decimals as arguments to `timedelta` In-Reply-To: <1331557988.1.0.944940856764.issue14262@psf.upfronthosting.co.za> Message-ID: <1348081658.84.0.682191934799.issue14262@psf.upfronthosting.co.za> Mark Dickinson added the comment: > If we can agree on a lossless protocol to communicate floating pointing > numbers of different base What sort of thing did you have in mind? This is sounding like a PEP-level proposal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 21:09:44 2012 From: report at bugs.python.org (Ram Rachum) Date: Wed, 19 Sep 2012 19:09:44 +0000 Subject: [issue14262] Allow using decimals as arguments to `timedelta` In-Reply-To: <1331557988.1.0.944940856764.issue14262@psf.upfronthosting.co.za> Message-ID: <1348081784.04.0.933126854599.issue14262@psf.upfronthosting.co.za> Ram Rachum added the comment: @mark.dickinson: Many different sources. One example is decimal fields on Django, used for dollar amounts. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 21:15:56 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 19 Sep 2012 19:15:56 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za> Message-ID: <1348082156.34.0.870889473361.issue15896@psf.upfronthosting.co.za> Ned Deily added the comment: Out of curiosity, has anyone checked whether this is also an issue with any of the supported BSD's? There have been other issues which were detected first on OS X but turned out to be more general BSD vs Linux differences, rather than OS X "bugs". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 21:20:18 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 19 Sep 2012 19:20:18 +0000 Subject: [issue14262] Allow using decimals as arguments to `timedelta` In-Reply-To: <1348081784.04.0.933126854599.issue14262@psf.upfronthosting.co.za> Message-ID: Alexander Belopolsky added the comment: On Wed, Sep 19, 2012 at 3:09 PM, Ram Rachum wrote: > One example is decimal fields on Django, used for dollar amounts. .. and since time is money and money is time we should support easy conversion between the two. :-) ---------- nosy: +Alexander.Belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 21:24:43 2012 From: report at bugs.python.org (Ram Rachum) Date: Wed, 19 Sep 2012 19:24:43 +0000 Subject: [issue14262] Allow using decimals as arguments to `timedelta` In-Reply-To: <1331557988.1.0.944940856764.issue14262@psf.upfronthosting.co.za> Message-ID: <1348082683.55.0.520329795644.issue14262@psf.upfronthosting.co.za> Ram Rachum added the comment: I hope this was intended as a joke. If this was an actual criticism, let me know so I could explain why it makes sense. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 21:25:25 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 19 Sep 2012 19:25:25 +0000 Subject: [issue15974] Optional compact and colored output for regrest In-Reply-To: <1348077938.27.0.260547344914.issue15974@psf.upfronthosting.co.za> Message-ID: <1348082725.37.0.371486889585.issue15974@psf.upfronthosting.co.za> Brett Cannon added the comment: I totally agree, I just wanted this in the tracker as a long-term goal to have. I have made this a dependency on issue #10967 which is tracking moving regrtest over unittest as much as possible. ---------- dependencies: +move regrtest over to using more unittest infrastructure _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 21:26:45 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 19 Sep 2012 19:26:45 +0000 Subject: [issue15973] Segmentation fault on timezone comparison In-Reply-To: <1348077797.35.0.854267629086.issue15973@psf.upfronthosting.co.za> Message-ID: <1348082805.78.0.918085737086.issue15973@psf.upfronthosting.co.za> Stefan Krah added the comment: The segfault does not occur in a debug build. The stack trace suggests that timezone_richcompare() accesses other->offset of the None object: (gdb) f 2 #2 0x000000000041d4e9 in do_richcompare (v=None, w=, op=) at Objects/object.c:563 563 res = (*f)(w, v, _Py_SwappedOp[op]); (gdb) f 1 #1 timezone_richcompare (self=0x7ffff6688ab0, other=, op=2) at /home/stefan/pydev/cpython-commit/Modules/_datetimemodule.c:3218 3218 return delta_richcompare(self->offset, other->offset, op); (gdb) l 3213 timezone_richcompare(PyDateTime_TimeZone *self, 3214 PyDateTime_TimeZone *other, int op) 3215 { 3216 if (op != Py_EQ && op != Py_NE) 3217 Py_RETURN_NOTIMPLEMENTED; 3218 return delta_richcompare(self->offset, other->offset, op); 3219 } 3220 3221 static Py_hash_t 3222 timezone_hash(PyDateTime_TimeZone *self) (gdb) f 0 #0 0x00007ffff5d850cf in delta_richcompare (self=0x7ffff6688ab0, other=, op=2) at /home/stefan/pydev/cpython-commit/Modules/_datetimemodule.c:1823 1823 if (PyDelta_Check(other)) { ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 21:30:25 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 19 Sep 2012 19:30:25 +0000 Subject: [issue15973] Segmentation fault on timezone comparison In-Reply-To: <1348077797.35.0.854267629086.issue15973@psf.upfronthosting.co.za> Message-ID: <1348083025.33.0.395662309599.issue15973@psf.upfronthosting.co.za> R. David Murray added the comment: On linux it segfaults for me in the debug interpreter. On default tip. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 21:34:11 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 19 Sep 2012 19:34:11 +0000 Subject: [issue14262] Allow using decimals as arguments to `timedelta` In-Reply-To: <1348082683.55.0.520329795644.issue14262@psf.upfronthosting.co.za> Message-ID: Alexander Belopolsky added the comment: On Wed, Sep 19, 2012 at 3:24 PM, Ram Rachum wrote: > I hope this was intended as a joke. If this was an actual criticism, let me know so > I could explain why it makes sense. It was both. Yes, any use cases will be helpful. Timedelta is already a decimal with six fractional digits, so it is natural to desire having direct Decimal to timedelta conversion, but without important use-case this feature will be hard to sell. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 21:52:01 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 19 Sep 2012 19:52:01 +0000 Subject: [issue15949] docs.python.org not getting updated In-Reply-To: <1347728419.57.0.753818975668.issue15949@psf.upfronthosting.co.za> Message-ID: <1348084321.81.0.197871435819.issue15949@psf.upfronthosting.co.za> Chris Jerdonek added the comment: It has been 8 days since the last update. ---------- priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 21:57:41 2012 From: report at bugs.python.org (Evangelos Foutras) Date: Wed, 19 Sep 2012 19:57:41 +0000 Subject: [issue15976] Inconsistent behavior of search_for_exec_prefix() results in startup failure in certain cases Message-ID: <1348084661.36.0.682682476046.issue15976@psf.upfronthosting.co.za> New submission from Evangelos Foutras: On Arch Linux /lib is a symbolic link to /usr/lib. When the Python interpreter is provided with an argv[0] of e.g. '/python2.7' and the current working directory is /, it'll fail to start with the following error: IOError: invalid Python installation: unable to open //include/python2.7/pyconfig.h (No such file or directory) >From what I understand, what is happening inside Modules/getpath.c is: 1) search_for_exec_prefix() is given an empty `argv0_path` 2) PYTHONHOME is not set, and we're not in a build directory, so step three is executed: * Step 3. Try to find prefix and exec_prefix relative to argv0_path, * backtracking up the path until it is exhausted. This is the most common * step to succeed. Note that if prefix and exec_prefix are different, * exec_prefix is more likely to be found; however if exec_prefix is a * subdirectory of prefix, both will be found. 3) copy_absolute() sets `exec_prefix` to '/' 4) 'lib/python2.7' gets appended to `exec_prefix` using joinpath() 5) 'lib-dynload' gets appended to `exec_prefix` using joinpath() 6) '/lib/python2.7/lib-dynload' exists and the function returns 1 (success) 7) control is returned to calculate_path() which later reduces `exec_prefix` to '/' During further initialization, sysconfig.py tries to open pyconfig.h, whose path is calculated as {exec_prefix}/include/python2.7/pyconfig.h; thus ending up with the nonexistent path //include/python2.7/pyconfig.h. The correct exec_prefix would be /usr. Moreover, if argv[0] and/or the current working directory are one level deeper (or more), `exec_prefix` will not be reduced to '/' and search_for_exec_prefix() will proceed to step four: * Step 4. Search the directories pointed to by the preprocessor variables * PREFIX and EXEC_PREFIX. These are supplied by the Makefile but can be * passed in as options to the configure script. i.e.: If search_for_exec_prefix() is passed an `argv0_path` with the value '/mnt', step three will only check '/mnt' but not '/', because '/mnt' will be reduced to '' and the `while (exec_prefix[0])` condition will be false. I see two problems with the behavior I describe above: 1) Step three will skip checking the root directory (/) if argv[0] or the current working directory are one or more levels below / (in other words, not directly under /). Its behavior in this regard is inconsistent. 2) When argv[0] is e.g. '/python2.7' and the current working directory is /, it'll use '/' as the exec_prefix and fail to start. The /lib -> /usr/lib symbolic link should get dereferenced and not used as is. I'm not sure how this should be fixed, so I only tried to present the issue with as many details as I could. If something is unclear, let me know. Lastly, search_for_prefix() has very similar code, so any fix will have to be applied there too. (There is also a downstream bug report @ https://bugs.archlinux.org/task/30812.) ---------- components: Interpreter Core messages: 170760 nosy: foutrelis priority: normal severity: normal status: open title: Inconsistent behavior of search_for_exec_prefix() results in startup failure in certain cases type: crash versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 21:58:02 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 19 Sep 2012 19:58:02 +0000 Subject: [issue11454] email.message import time In-Reply-To: <1299701237.24.0.992920521308.issue11454@psf.upfronthosting.co.za> Message-ID: <1348084682.42.0.628109551862.issue11454@psf.upfronthosting.co.za> Ezio Melotti added the comment: Attached new benchmark file. Results: Testing runtime of the _has_surrogates functions Generating chars... Generating samples... 1.61 <- re.compile(current_regex).search 0.24 <- re.compile(short_regex).search 15.13 <- return any(c in surrogates for c in s) 10.21 <- for c in s: if c in surrogates: return True 0.85 <- return re.search(short_regex, s) 0.83 <- functools.partial(re.search, short_regex) 20.86 <- for c in map(ord, s): if c in range(0xDC80, 0xDCFF+1): return True 19.68 <- for c in map(ord, s): if 0xDC80 <= c <= 0xDCFF: return True 0.28 <- re.compile('[^\udc80-\udcff]*\Z').match 7.00 <- return not set(map(chr, range(0xDC80, 0xDCFF+1))).isdisjoint(s) Testing startup time 0.57 <- r = re.compile('[\udc80-\udcff]').search 0.59 <- r = re.compile('[^\udc80-\udcff]*\Z').match 199.79 <- r = re.compile('[\udc80-\udcff]').search; purge() 22.62 <- r = re.compile('[^\udc80-\udcff]*\Z').match; purge() 1.12 <- r = pickle.loads(p) ---------- Added file: http://bugs.python.org/file27225/issue11454_benchmarks.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 22:01:38 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 19 Sep 2012 20:01:38 +0000 Subject: [issue11454] email.message import time In-Reply-To: <1299701237.24.0.992920521308.issue11454@psf.upfronthosting.co.za> Message-ID: <1348084898.44.0.749766437877.issue11454@psf.upfronthosting.co.za> R. David Murray added the comment: So by your measurements the short search is the clear winner? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 22:09:50 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 19 Sep 2012 20:09:50 +0000 Subject: [issue11454] email.message import time In-Reply-To: <1299701237.24.0.992920521308.issue11454@psf.upfronthosting.co.za> Message-ID: <1348085390.37.0.616956670035.issue11454@psf.upfronthosting.co.za> Ezio Melotti added the comment: Yes, however it has a startup cost that the function that returns re.search(short_regex, s) and the one with functool.partial don't have, because with these the compilation happens at the first call. If we use one of these two, the startup time will be reduced a lot, and the runtime will be ~2x faster. If we use re.compile(short_regex).search the startup time won't be reduced as much, but the runtime will be ~8x faster. Given that here we are trying to reduce the startup time and not the runtime, I think using one of those two functions is better. Another possible solution to improve the startup time is trying to optimize _optimize_unicode -- not sure how much can be done there though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 22:12:41 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 19 Sep 2012 20:12:41 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1348077282.82.0.0829988915146.issue15896@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Option 1: > Fix breakages as they are discovered at higher level (above os.read) as needed in places where usage semantics are known, and address the issue via errata documentation (i.e., "On Mac OS X, don't make individual pipe read requests that would result in os.read() buffersize arg being above 127KB on non-blocking pipes."); should also check if the same issue occurs with sockets (e.g., socket.socketpair() instead of os.pipe()) to make the errata more complete. This may be perfectly acceptable and how things have worked for a long time. > Implement a work-around in the lowest common denominator wrapper function, so that anything in Python that needs to call read() and could benefit from this work-around, would call that wrapper instead of read(). The read() work-around might go something like this in *pseudocode*: It's not Python's job to workaround stupid platform bugs, or document them: that would lead to unmanagable code or unmaintanable documentation. This particular issue will get fixed as part of http://bugs.python.org/issue15918, and I'm -10 against adding an hack to posix.read(). So I'd suggest closing this, and urge people to complain to the OS-X folks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 22:19:37 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 19 Sep 2012 20:19:37 +0000 Subject: [issue11454] email.message import time In-Reply-To: <1299701237.24.0.992920521308.issue11454@psf.upfronthosting.co.za> Message-ID: <1348085977.63.0.299625841549.issue11454@psf.upfronthosting.co.za> R. David Murray added the comment: This issue may be about reducing the startup time, but this function is a hot spot in the email package so I would prefer to sacrifice startup time optimization for an increase in speed. However, given the improvements to import locking in 3.3, what about a self replacing function? def _has_surrogates(s): import email.utils f = re.compile('[\udc80-\udcff]').search email.utils._has_surrogates = f return f(s) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 22:25:25 2012 From: report at bugs.python.org (Vitaly) Date: Wed, 19 Sep 2012 20:25:25 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za> Message-ID: <1348086325.59.0.840396146303.issue15896@psf.upfronthosting.co.za> Vitaly added the comment: > It's not Python's job to workaround stupid platform bugs... > So I'd suggest closing this, and urge people to complain to the OS-X folks After digesting the postings, I've come around to this point of view as well, so closing as "rejected". And, as mentioned earlier, I filed the issue on https://bugreport.apple.com as Problem ID: 12274650. ---------- resolution: -> rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 22:25:35 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 19 Sep 2012 20:25:35 +0000 Subject: [issue11454] email.message import time In-Reply-To: <1299701237.24.0.992920521308.issue11454@psf.upfronthosting.co.za> Message-ID: <1348086335.45.0.638704605617.issue11454@psf.upfronthosting.co.za> Ezio Melotti added the comment: That might work. To avoid the overhead of the cache lookup I was thinking about something like regex = None def _has_surrogates(s): global regex if regex is None: regex = re.compile(short_regex) return regex.search(s) but I have discarded it because it's not very pretty and still has the overhead of the function and an additional if. Your version solves both the problems in a more elegant way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 22:26:07 2012 From: report at bugs.python.org (Vitaly) Date: Wed, 19 Sep 2012 20:26:07 +0000 Subject: [issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS In-Reply-To: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za> Message-ID: <1348086367.6.0.279119720338.issue15896@psf.upfronthosting.co.za> Changes by Vitaly : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 22:28:30 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 19 Sep 2012 20:28:30 +0000 Subject: [issue11454] email.message import time In-Reply-To: <1299701237.24.0.992920521308.issue11454@psf.upfronthosting.co.za> Message-ID: <1348086510.0.0.918883176412.issue11454@psf.upfronthosting.co.za> R. David Murray added the comment: It passed the email test suite. Patch attached. ---------- Added file: http://bugs.python.org/file27226/email_import_speedup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 22:32:07 2012 From: report at bugs.python.org (Ram Rachum) Date: Wed, 19 Sep 2012 20:32:07 +0000 Subject: [issue14262] Allow using decimals as arguments to `timedelta` In-Reply-To: <1331557988.1.0.944940856764.issue14262@psf.upfronthosting.co.za> Message-ID: <1348086727.38.0.15645123586.issue14262@psf.upfronthosting.co.za> Ram Rachum added the comment: I can think of millions of use cases. Here's a random one out of those millions: A client is entitled to X hours of service a month. We grant him a promotion where he is allowed 15% more than x, i.e. 1.15*x. But that number, 1.15, is stored in a Django decimal field. We try to multiply 1.15 by the timedelta X and it fails. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 22:33:56 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 19 Sep 2012 20:33:56 +0000 Subject: [issue11454] email.message import time In-Reply-To: <1299701237.24.0.992920521308.issue11454@psf.upfronthosting.co.za> Message-ID: <1348086836.73.0.240922400102.issue11454@psf.upfronthosting.co.za> Ezio Melotti added the comment: It would be better to add/improve the _has_surrogates tests before committing. The patch I attached is also still valid if you want a further speed up improvement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 22:57:20 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 19 Sep 2012 20:57:20 +0000 Subject: [issue14262] Allow using decimals as arguments to `timedelta` In-Reply-To: <1348086727.38.0.15645123586.issue14262@psf.upfronthosting.co.za> Message-ID: Alexander Belopolsky added the comment: On Wed, Sep 19, 2012 at 4:32 PM, Ram Rachum wrote: > But that number, 1.15, is stored in a Django decimal field. My criticism was towards the idea that one may need to multiply timedelta by a dollar amount or convert a dollar amount to a timedelta. Storing dollar amounts is an important use case for Decimal and there are several reasons why Decimal is a better choice than float for this. On the other hand, I don't see why use of Decimal would be required in your example. Do you have any real world use cases where Decimal is clearly preferred over float and there is a need to multiply Decimals by time deltas? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 23:26:28 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 19 Sep 2012 21:26:28 +0000 Subject: [issue11454] email.message import time In-Reply-To: <1299701237.24.0.992920521308.issue11454@psf.upfronthosting.co.za> Message-ID: <1348089988.73.0.431632808707.issue11454@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: def _has_surrogates(s): try: s.encode() return False except UnicodeEncodeError: return True Results: 0.26 <- re.compile(short_regex).search 0.06 <- try encode ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 19 23:36:57 2012 From: report at bugs.python.org (Ram Rachum) Date: Wed, 19 Sep 2012 21:36:57 +0000 Subject: [issue14262] Allow using decimals as arguments to `timedelta` In-Reply-To: <1331557988.1.0.944940856764.issue14262@psf.upfronthosting.co.za> Message-ID: <1348090617.44.0.695582293496.issue14262@psf.upfronthosting.co.za> Ram Rachum added the comment: In the example I gave, Decimal is clearly preferred over float. Why would we use float to represent the ratio of the bonus to the client? Why would we risk imprecision there when Decimal provides us with perfect precision? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 00:02:00 2012 From: report at bugs.python.org (Daniel Sommermann) Date: Wed, 19 Sep 2012 22:02:00 +0000 Subject: [issue15977] Memory leak in _ssl.c Message-ID: <1348092120.32.0.751173728211.issue15977@psf.upfronthosting.co.za> New submission from Daniel Sommermann: I noticed that the function _set_npn_protocols() has the following line: self->npn_protocols = PyMem_Malloc(protos.len); There is no check to see if self->npn_protocols is already allocated. Thus, multiple calls to _set_npn_protocols() will leak memory. There should be a check to see if it is non-null and free the memory pointed to by self->npn_protocols before the malloc unless I am missing something. ---------- components: IO messages: 170774 nosy: Daniel.Sommermann, pitrou priority: normal severity: normal status: open title: Memory leak in _ssl.c versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 00:09:06 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 19 Sep 2012 22:09:06 +0000 Subject: [issue10967] move regrtest over to using more unittest infrastructure In-Reply-To: <1295567145.8.0.568957178125.issue10967@psf.upfronthosting.co.za> Message-ID: <1348092546.01.0.259915604254.issue10967@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 00:31:24 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 19 Sep 2012 22:31:24 +0000 Subject: [issue10967] move regrtest over to using more unittest infrastructure In-Reply-To: <1295567145.8.0.568957178125.issue10967@psf.upfronthosting.co.za> Message-ID: <1348093884.98.0.888176029872.issue10967@psf.upfronthosting.co.za> Chris Jerdonek added the comment: One important piece is that regrtest currently has no tests (e.g. there is no test_regrtest.py), so changing it must be done more carefully. How do people feel about new (or newly modified) regrtest classes and functions going into a different fully-tested module with its own test_* file. Currently, regrtest is a mixture of definitions and "running code," so I would be leery of adding test_regrtest. This could also be done by making regrtest a package, so that regrtest-related modules would be in a single directory. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 00:38:02 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 19 Sep 2012 22:38:02 +0000 Subject: [issue14262] Allow using decimals as arguments to `timedelta` In-Reply-To: <1348090617.44.0.695582293496.issue14262@psf.upfronthosting.co.za> Message-ID: Alexander Belopolsky added the comment: On Sep 19, 2012, at 5:36 PM, Ram Rachum wrote: > Why would we use float to represent the ratio of the bonus to the client? Because float is the builtin type that Python provides to represent such quantities. > Why would we risk imprecision there when Decimal provides us with perfect precision? Python float is a much simpler and more efficient type than Decimal. One should have a really good reason to introduce Decimal in the program. In case of money, Decimal provides a *lower* precision alternative to float together with the control over rounding direction. This is important in applications where fractions of a penny have to be dealt with in very precise manner. In your application, float is a perfectly good type to represent 15% bonus. Even if your customers insist on microsecond precision, float is good enough and timedelta resolution will prevent you from supporting higher precision anyways. As I mentioned before, I would be happy to see greater interoperability between numerical types in Python and interoperability between timedelta and Decimal may come as a side benefit of that effort. However, I don't find your use case to be compelling enough to either justify special case code or to motivate a more general effort. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 01:48:27 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 19 Sep 2012 23:48:27 +0000 Subject: [issue15888] ipaddress doctest examples have some errors In-Reply-To: <1347190349.96.0.156720503481.issue15888@psf.upfronthosting.co.za> Message-ID: <1348098507.72.0.141722796412.issue15888@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attaching an updated patch that does not render the import statements in the final HTML, so that it renders the same as before. ---------- Added file: http://bugs.python.org/file27227/issue-15888-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 02:23:06 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 20 Sep 2012 00:23:06 +0000 Subject: [issue15276] unicode format does not really work in Python 2.x In-Reply-To: <1341668447.61.0.319523039673.issue15276@psf.upfronthosting.co.za> Message-ID: <1348100586.23.0.873987181705.issue15276@psf.upfronthosting.co.za> Chris Jerdonek added the comment: If we don't fix this (I'm leaning that way myself), I think we should somehow document the limitation. There are ways to acknowledge the limitation without getting into the specifics of this particular issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 03:02:34 2012 From: report at bugs.python.org (Christian Heimes) Date: Thu, 20 Sep 2012 01:02:34 +0000 Subject: [issue15977] Memory leak in _ssl.c In-Reply-To: <1348092120.32.0.751173728211.issue15977@psf.upfronthosting.co.za> Message-ID: <1348102954.55.0.955240719045.issue15977@psf.upfronthosting.co.za> Christian Heimes added the comment: You are right. I did some testing and the function indeed leaks memory. The attached patch fixes the issue for me. ---------- keywords: +patch nosy: +christian.heimes stage: -> patch review type: -> resource usage Added file: http://bugs.python.org/file27228/npn_memfix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 03:48:09 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 20 Sep 2012 01:48:09 +0000 Subject: [issue15973] Segmentation fault on timezone comparison In-Reply-To: <1348077797.35.0.854267629086.issue15973@psf.upfronthosting.co.za> Message-ID: <1348105689.21.0.178304655738.issue15973@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I think the following simple patch should do the trick. I'll add some tests and commit. Should this get in 3.3.0? diff -r 19c74cadea95 Modules/_datetimemodule.c --- a/Modules/_datetimemodule.c Wed Sep 19 08:25:01 2012 +0300 +++ b/Modules/_datetimemodule.c Wed Sep 19 21:42:51 2012 -0400 @@ -3215,6 +3215,11 @@ { if (op != Py_EQ && op != Py_NE) Py_RETURN_NOTIMPLEMENTED; + if (Py_TYPE(other) != &PyDateTime_TimeZoneType) + if (op == Py_EQ) + Py_RETURN_FALSE; + else + Py_RETURN_TRUE; return delta_richcompare(self->offset, other->offset, op); } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 03:49:07 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 20 Sep 2012 01:49:07 +0000 Subject: [issue15973] Segmentation fault on timezone comparison In-Reply-To: <1348077797.35.0.854267629086.issue15973@psf.upfronthosting.co.za> Message-ID: <1348105747.12.0.682312481149.issue15973@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Hopefully, there will be some more braces, though. :) ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 04:59:44 2012 From: report at bugs.python.org (chrysn) Date: Thu, 20 Sep 2012 02:59:44 +0000 Subject: [issue15978] asyncore: included batteries don't fit Message-ID: <1348109984.23.0.963898980799.issue15978@psf.upfronthosting.co.za> New submission from chrysn: the asyncore module would be much more useful if it were well integrated in the standard library. in particular, it should be supported by: * subprocess * BaseHTTPServer / http.server (and thus, socketserver) * urllib2 / urllib, http.client * probably many other network libraries except smtpd, which already uses asyncore without widespread asyncore support, it is not possible to easily integrate different servers and services with each other; with asyncore support, it's just a matter of creating the objects and entering the main loop. (eg, a http server for controlling a serial device, with a telnet-like debugging interface). the socketserver even documents that it would like to have such a framework ("Future work: [...] Standard framework for select-based multiplexing"). it would be rather difficult to port in the generic case (as socketserver based code in general relies on blocking `read`s or `readline`s), but can be done in particular cases (i've ported SimpleHTTPServer, but it's a mess of monkey-patching). for subprocess, there's a bunch of recipies at [1]; pyserial (not standard library, but might as well become) can be ported quite easily [2]. [1] http://code.activestate.com/recipes/576957-asynchronous-subprocess-using-asyncore/ [2] http://sourceforge.net/tracker/?func=detail&aid=3559321&group_id=46487&atid=446305 this issue touches several modules, so for practical implementation, it might be split up for the different individual fixes to come and track them. some of them will bring incompatible changes -- it's easy to get SimpleHTTPServer to a state where it can run unmodified inside asyncore, and emulate its external interfaces (serve_forever just being a wrapper to asyncore.loop), but hard to say if it will work with what people built atop of it. how can we find a roadmap for that? python already has batteries for nonblocking operation included -- let's just make sure they fit in the other gadgets! ---------- messages: 170782 nosy: chrysn priority: normal severity: normal status: open title: asyncore: included batteries don't fit _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 05:00:24 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 20 Sep 2012 03:00:24 +0000 Subject: [issue15973] Segmentation fault on timezone comparison In-Reply-To: <1348077797.35.0.854267629086.issue15973@psf.upfronthosting.co.za> Message-ID: <1348110024.47.0.73394945979.issue15973@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 05:01:25 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 20 Sep 2012 03:01:25 +0000 Subject: [issue15977] Memory leak in _ssl.c In-Reply-To: <1348092120.32.0.751173728211.issue15977@psf.upfronthosting.co.za> Message-ID: <1348110085.68.0.150785301667.issue15977@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea stage: patch review -> type: resource usage -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 05:01:50 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 20 Sep 2012 03:01:50 +0000 Subject: [issue15977] Memory leak in _ssl.c In-Reply-To: <1348092120.32.0.751173728211.issue15977@psf.upfronthosting.co.za> Message-ID: <1348110110.5.0.518370115643.issue15977@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- stage: -> patch review type: -> resource usage _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 05:07:49 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 20 Sep 2012 03:07:49 +0000 Subject: [issue15973] Segmentation fault on timezone comparison In-Reply-To: <1348077797.35.0.854267629086.issue15973@psf.upfronthosting.co.za> Message-ID: <1348110469.09.0.570311898403.issue15973@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: What about datetime subclasses? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 05:16:38 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 20 Sep 2012 03:16:38 +0000 Subject: [issue15978] asyncore: included batteries don't fit In-Reply-To: <1348109984.23.0.963898980799.issue15978@psf.upfronthosting.co.za> Message-ID: <1348110998.53.0.0864088509089.issue15978@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- components: +Library (Lib) nosy: +giampaolo.rodola, josiahcarlson, stutzbach type: -> enhancement versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 05:21:59 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 20 Sep 2012 03:21:59 +0000 Subject: [issue15973] Segmentation fault on timezone comparison In-Reply-To: <1348077797.35.0.854267629086.issue15973@psf.upfronthosting.co.za> Message-ID: <1348111319.41.0.628148556159.issue15973@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > What about datetime subclasses? Do you mean timezone subclasses? Timezone type is not subclassable, but we should probably support comparison with any tzinfo subclass. I'll add this logic, but arguably that would be a new feature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 05:26:47 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 20 Sep 2012 03:26:47 +0000 Subject: [issue15979] Improve timeit documentation Message-ID: <1348111607.58.0.268885940785.issue15979@psf.upfronthosting.co.za> New submission from Ezio Melotti: The documentation of timeit can be improved in several ways: * it should start with a couple of short and comprehensible examples that show the basic usage from the command-line and from the code; * the 3 convenience functions should be moved before the class documentation (and their order inverted); * the methods in the class should be reordered to show the important one first; * more comprehensive (but still comprehensible) examples should be added at the end; * sh syntax highlight should be used for the command-line usage examples; * the note about Python 2.3 can be removed from 3.x docs; http://docs.python.org/dev/library/timeit.html ---------- assignee: docs at python components: Documentation messages: 170785 nosy: docs at python, ezio.melotti priority: normal severity: normal stage: needs patch status: open title: Improve timeit documentation type: enhancement versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 06:40:42 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 20 Sep 2012 04:40:42 +0000 Subject: [issue15979] Improve timeit documentation In-Reply-To: <1348111607.58.0.268885940785.issue15979@psf.upfronthosting.co.za> Message-ID: <1348116042.11.0.784135719284.issue15979@psf.upfronthosting.co.za> Raymond Hettinger added the comment: +1 ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 06:43:16 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 20 Sep 2012 04:43:16 +0000 Subject: [issue14873] Windows devguide: clarification for build errors due to missing optional dependencies In-Reply-To: <1337635934.97.0.00774228484409.issue14873@psf.upfronthosting.co.za> Message-ID: <3XMlgQ47PnzQms@mail.python.org> Roundup Robot added the comment: New changeset a9f8a205fa9a by Ezio Melotti in branch 'default': #14873: add paragraph about building errors caused by missing dependencies on Windows. Patch by Chris Jerdonek, initial patch by Merlijn van Deen. http://hg.python.org/devguide/rev/a9f8a205fa9a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 06:47:06 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 20 Sep 2012 04:47:06 +0000 Subject: [issue14873] Windows devguide: clarification for build errors due to missing optional dependencies In-Reply-To: <1337635934.97.0.00774228484409.issue14873@psf.upfronthosting.co.za> Message-ID: <1348116426.2.0.220521559463.issue14873@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patches! ---------- assignee: -> ezio.melotti resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 06:50:00 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 20 Sep 2012 04:50:00 +0000 Subject: [issue14873] Windows devguide: clarification for build errors due to missing optional dependencies In-Reply-To: <1337635934.97.0.00774228484409.issue14873@psf.upfronthosting.co.za> Message-ID: <1348116600.29.0.368985163405.issue14873@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks, Ezio! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 06:52:21 2012 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 20 Sep 2012 04:52:21 +0000 Subject: [issue15978] asyncore: included batteries don't fit In-Reply-To: <1348109984.23.0.963898980799.issue15978@psf.upfronthosting.co.za> Message-ID: <1348116741.28.0.919017562195.issue15978@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: The proposal looks way too ambitious and vaguely defined to me to say the least. Integrating any async framework into another one which uses a blocking concurrency model is hard. If that async framework is asyncore is usually also a bad idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 06:52:27 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 20 Sep 2012 04:52:27 +0000 Subject: [issue15939] make *.rst files in Doc/ parseable by doctest In-Reply-To: <1347543698.43.0.179468389771.issue15939@psf.upfronthosting.co.za> Message-ID: <1348116747.51.0.349536321503.issue15939@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 06:58:18 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 20 Sep 2012 04:58:18 +0000 Subject: [issue15939] make *.rst files in Doc/ parseable by doctest In-Reply-To: <1347543698.43.0.179468389771.issue15939@psf.upfronthosting.co.za> Message-ID: <1348117098.16.0.287139826726.issue15939@psf.upfronthosting.co.za> Chris Jerdonek added the comment: My opinion on the "+LINUX" and "+WINDOWS" doctest directives in Doc/library/ctypes.rst is simply to leave them alone for now. We can make those errors go away in code when running doctest by adding no-op calls to doctest.register_optionflag() as below: +doctest.register_optionflag('WINDOWS') +doctest.register_optionflag('LINUX') prior to constructing the doctest TestSuites. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 07:23:31 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 20 Sep 2012 05:23:31 +0000 Subject: [issue15949] docs.python.org not getting updated In-Reply-To: <1347728419.57.0.753818975668.issue15949@psf.upfronthosting.co.za> Message-ID: <1348118611.87.0.43862930943.issue15949@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +loewis, ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 08:41:23 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 20 Sep 2012 06:41:23 +0000 Subject: [issue15979] Improve timeit documentation In-Reply-To: <1348111607.58.0.268885940785.issue15979@psf.upfronthosting.co.za> Message-ID: <1348123283.03.0.2761720816.issue15979@psf.upfronthosting.co.za> Ezio Melotti added the comment: The sh syntax highlight can be enabled with: .. code-block:: sh $ ... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 09:01:14 2012 From: report at bugs.python.org (Daniel Sommermann) Date: Thu, 20 Sep 2012 07:01:14 +0000 Subject: [issue15977] Memory leak in _ssl.c In-Reply-To: <1348092120.32.0.751173728211.issue15977@psf.upfronthosting.co.za> Message-ID: <1348124474.72.0.937255899841.issue15977@psf.upfronthosting.co.za> Daniel Sommermann added the comment: This patch looks good to me (it's exactly how I fixed it in my local build), although I'm not sure how to approve your patch so you can push it to the upstream. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 10:26:32 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 20 Sep 2012 08:26:32 +0000 Subject: [issue15980] Non-escaped '\n' in docstrings Message-ID: <1348129592.37.0.740321783262.issue15980@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Here are patches that escapes '\n' in docstrings of LWPCookieJar and (for 2.7 only) of email. ---------- assignee: docs at python components: Documentation files: escape_nl2.patch keywords: patch messages: 170794 nosy: docs at python, ezio.melotti, storchaka priority: normal severity: normal status: open title: Non-escaped '\n' in docstrings type: enhancement versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file27229/escape_nl2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 10:27:02 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 20 Sep 2012 08:27:02 +0000 Subject: [issue15980] Non-escaped '\n' in docstrings In-Reply-To: <1348129592.37.0.740321783262.issue15980@psf.upfronthosting.co.za> Message-ID: <1348129622.69.0.0651295464456.issue15980@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file27230/escape_nl2-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 11:23:19 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 20 Sep 2012 09:23:19 +0000 Subject: [issue15944] memoryviews and ctypes In-Reply-To: <1347635130.32.0.649142152247.issue15944@psf.upfronthosting.co.za> Message-ID: <1348132999.54.0.214822140544.issue15944@psf.upfronthosting.co.za> Stefan Krah added the comment: As I understand it, you prefer memoryviews where the format is purely informational, whereas we now have typed memoryviews. Typed memoryviews are certainly useful, in fact they are present in Cython, see here for examples: http://docs.cython.org/src/userguide/memoryviews.html I can see only one obvious benefit of ignoring the format: All possible formats are accepted. What I don't understand is why this ... m[0] = b'\x00\x00\x00\x01' ... should be preferable to: m[0] = 1 If you think that typed memoryviews are a mistake, I suggest raising the issue on python-dev as soon as possible (3.3 is due soon). All memoryview operations are now based on values instead of bit patterns, see for example #15573. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 12:43:56 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 20 Sep 2012 10:43:56 +0000 Subject: [issue15977] Memory leak in _ssl.c In-Reply-To: <1348092120.32.0.751173728211.issue15977@psf.upfronthosting.co.za> Message-ID: <3XMvgb3LPSzNQw@mail.python.org> Roundup Robot added the comment: New changeset 2bdc8c8ea42e by Christian Heimes in branch 'default': Issue #15977: Fix memory leak in Modules/_ssl.c when the function _set_npn_protocols() is called multiple times http://hg.python.org/cpython/rev/2bdc8c8ea42e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 12:49:38 2012 From: report at bugs.python.org (Christian Heimes) Date: Thu, 20 Sep 2012 10:49:38 +0000 Subject: [issue15977] Memory leak in _ssl.c In-Reply-To: <1348092120.32.0.751173728211.issue15977@psf.upfronthosting.co.za> Message-ID: <1348138178.69.0.103947067745.issue15977@psf.upfronthosting.co.za> Christian Heimes added the comment: Georg, here is another candidate for the new release candidate. Daniel, two equal patches are good enough as a patch review. The fix is simple and straight forward, too. Thanks for your report! ---------- assignee: -> georg.brandl nosy: +georg.brandl resolution: -> fixed stage: patch review -> committed/rejected status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 13:00:24 2012 From: report at bugs.python.org (Max) Date: Thu, 20 Sep 2012 11:00:24 +0000 Subject: [issue15981] improve documentation of __hash__ Message-ID: <1348138824.37.0.3310744827.issue15981@psf.upfronthosting.co.za> New submission from Max: In dev/reference/datamodel#object.__hash__, there are two paragraphs that seem inconsistent. The first paragraph seems to say that a class that overrides __eq__() *should* explicitly flag itself as unhashable. The next paragraph says that a class that overrides __eq__() *will be* flagged unhashable by default. Which one is it? Here are the two paragraphs: Classes which inherit a __hash__() method from a parent class but change the meaning of __eq__() such that the hash value returned is no longer appropriate (e.g. by switching to a value-based concept of equality instead of the default identity based equality) can explicitly flag themselves as being unhashable by setting __hash__ = None in the class definition. Doing so means that not only will instances of the class raise an appropriate TypeError when a program attempts to retrieve their hash value, but they will also be correctly identified as unhashable when checking isinstance(obj, collections.Hashable) (unlike classes which define their own __hash__() to explicitly raise TypeError). If a class that overrides __eq__() needs to retain the implementation of __hash__() from a parent class, the interpreter must be told this explicitly by setting __hash__ = .__hash__. Otherwise the inheritance of __hash__() will be blocked, just as if __hash__ had been explicitly set to None. ---------- assignee: docs at python components: Documentation messages: 170798 nosy: docs at python, max priority: normal severity: normal status: open title: improve documentation of __hash__ type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 13:12:50 2012 From: report at bugs.python.org (Nicolai Ehemann) Date: Thu, 20 Sep 2012 11:12:50 +0000 Subject: [issue15982] asyncore.dispatcher does not handle windows socket error code correctly (namely WSAEWOULDBLOCK 10035) Message-ID: <1348139570.15.0.496741951323.issue15982@psf.upfronthosting.co.za> New submission from Nicolai Ehemann: There are some differences between win32 and other os socket implementations. One specific I found is that in windows, non-blocking socket apis will return WSAEWOULDBLOCK or 10035 instead of EWOULDBLOCK. This causes recv() in asyncore.dispatcher to raise an unhandled exception instead of continuing gracefully. The fix could maybe be as simple as replacing line 384 in asyncore.py: data = self.socket.recv(buffer_size) with try: data = self.socket.recv(buffer_size) except socket.error as e: if 10035 == e.errno: pass else: raise e The differences between windows and unix non-blocking sockets are summarized quite nice here: http://itamarst.org/writings/win32sockets.html The original documentation from microsoft can be found here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms740668(v=vs.85).aspx ---------- components: Library (Lib) messages: 170799 nosy: McNetic priority: normal severity: normal status: open title: asyncore.dispatcher does not handle windows socket error code correctly (namely WSAEWOULDBLOCK 10035) type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 13:31:06 2012 From: report at bugs.python.org (chrysn) Date: Thu, 20 Sep 2012 11:31:06 +0000 Subject: [issue15978] asyncore: included batteries don't fit In-Reply-To: <1348109984.23.0.963898980799.issue15978@psf.upfronthosting.co.za> Message-ID: <1348140666.86.0.948985366577.issue15978@psf.upfronthosting.co.za> chrysn added the comment: i'm aware this is ambitious, and hope that at least the individual sub-agendas will be manageable. as for vague, i can enhance it (i'd start refining the individual sub-agendas -- or do you think the "big picture" needs more details too?). integration of frameworks is hard, i know. for some libraries, it might not even be feasible, or it could be that it'd be easier to write a new server than integrating into the existing one. (eg it might be easier to refactor http servers into a generic and a blocking part first, and then offer a http.server.AsyncServer in parallel to the existing implementation). that's why i'd like to try to get a rough roadmap instead of hacking ahead :-) nevertheless, the current situation is not satisfying -- we have a versatile http client module, and yet who wants to fetch asynchronously is left with a stub implementation in the asyncore docs. that's not what one would expect from the "batteries included" catchphrase. we don't need all of that implemented *right now*, but maybe we can do better than implementing it never. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 13:40:16 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 20 Sep 2012 11:40:16 +0000 Subject: [issue15276] unicode format does not really work in Python 2.x In-Reply-To: <1341668447.61.0.319523039673.issue15276@psf.upfronthosting.co.za> Message-ID: <1348141216.24.0.15622994824.issue15276@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 13:45:20 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 20 Sep 2012 11:45:20 +0000 Subject: [issue15276] unicode format does not really work in Python 2.x In-Reply-To: <1341668447.61.0.319523039673.issue15276@psf.upfronthosting.co.za> Message-ID: <1348141520.67.0.537604536279.issue15276@psf.upfronthosting.co.za> STINNER Victor added the comment: I fixed a similar bug in Python 3.3: issue #13706. changeset: 75231:f89e2f4cda88 user: Victor Stinner date: Fri Feb 24 00:37:51 2012 +0100 files: Include/unicodeobject.h Lib/test/test_format.py Objects/stringlib/asciilib.h Objects/stringlib/localeutil.h Objects/stringlib/stringdefs.h Objects/stringlib/ucs1lib.h description: Issue #13706: Fix format(int, "n") for locale with non-ASCII thousands separator * Decode thousands separator and decimal point using PyUnicode_DecodeLocale() (from the locale encoding), instead of decoding them implicitly from latin1 * Remove _PyUnicode_InsertThousandsGroupingLocale(), it was not used * Change _PyUnicode_InsertThousandsGrouping() API to return the maximum character if unicode is NULL * Replace MIN/MAX macros by Py_MIN/Py_MAX * stringlib/undef.h undefines STRINGLIB_IS_UNICODE * stringlib/localeutil.h only supports Unicode ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 14:03:49 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 20 Sep 2012 12:03:49 +0000 Subject: [issue15276] unicode format does not really work in Python 2.x In-Reply-To: <1341668447.61.0.319523039673.issue15276@psf.upfronthosting.co.za> Message-ID: <1348142629.01.0.828345024438.issue15276@psf.upfronthosting.co.za> STINNER Victor added the comment: > I can't reproduce this with Python 2.7.3. > >>> locale.setlocale(locale.LC_NUMERIC, 'fr_FR') > 'fr_FR' > >>> u'{:n}'.format(10000) > u'10 000' I don't understand why, but the all french locales are the same. Some "french locale" uses the standard ASCII space (U+0020) as thousand seperator, others use the non-breaking space (U+00A0). I suppose that some systems prefer to avoid non-ASCII characters to avoid "Unicode issues". On Ubuntu 12.04, locale.localeconv()['thousands_sep'] is chr(32) for the locale fr_FR.utf8. You may need to install other locales to test this issue. For example, the ps_AF locale uses U+066b as the decimal point and the thousands separator. I chose to not fix the issue in Python 3.2 because it needs to change too much code (and I don't want to introduce a regression and 3.2 code is very different than 3.3). You should upgrade to Python 3.3, or reimplement the Unicode format() function for numbers using locale.localeconv() ('thousands_sep', 'decimal_point' and 'grouping') :-/ Or find a more motivated developer. Or I can do the job if you pay me ;-) (Read also the issue #13706 for more information.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 14:07:56 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 20 Sep 2012 12:07:56 +0000 Subject: [issue15973] Segmentation fault on timezone comparison In-Reply-To: <1348077797.35.0.854267629086.issue15973@psf.upfronthosting.co.za> Message-ID: <1348142876.32.0.959571491598.issue15973@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Alexander, did you send a contributor agreement?. I don't see it in the tracker :-?? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 14:08:18 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 20 Sep 2012 12:08:18 +0000 Subject: [issue15972] wrong error message for os.path.getsize In-Reply-To: <1348071122.36.0.302681706423.issue15972@psf.upfronthosting.co.za> Message-ID: <1348142898.16.0.337903904038.issue15972@psf.upfronthosting.co.za> STINNER Victor added the comment: It looks like os.stat() and os.path.getsize() converts the list into a byte string. It does something like: >>> x=[]; y=bytes(x); print(y.decode("ascii")) >>> x=[65, 66, 67]; y=bytes(x); print(y.decode("ascii")) ABC >>> x=[None]; y=bytes(x); print(y.decode("ascii")) Traceback (most recent call last): File "", line 1, in TypeError: 'NoneType' object cannot be interpreted as an integer ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 14:12:37 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 20 Sep 2012 12:12:37 +0000 Subject: [issue15972] wrong error message for os.path.getsize In-Reply-To: <1348071122.36.0.302681706423.issue15972@psf.upfronthosting.co.za> Message-ID: <1348143157.49.0.737787908322.issue15972@psf.upfronthosting.co.za> STINNER Victor added the comment: Functions of the os module uses PyUnicode_FSConverter() function (which uses PyBytes_Check() on bytes) in Python 3.2, whereas PyBytes_FromObject() is used in Python 3.3. Related change: changeset: 77597:27f9c26fdd8b user: Larry Hastings date: Fri Jun 22 16:30:09 2012 -0700 files: Doc/library/os.rst Lib/os.py Lib/shutil.py Lib/test/support.py Lib/test/test_os.py Lib/test/test_posix.py Lib/test/test_shutil.py Misc/NEWS Modules/posixmodule.c description: Issue #14626: Large refactoring of functions / parameters in the os module. Many functions now support "dir_fd" and "follow_symlinks" parameters; some also support accepting an open file descriptor in place of of a path string. Added os.support_* collections as LBYL helpers. Removed many functions only previously seen in 3.3 alpha releases (often starting with "f" or "l", or ending with "at"). Originally suggested by Serhiy Storchaka; implemented by Larry Hastings. ---------- nosy: +larry, storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 14:13:20 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 20 Sep 2012 12:13:20 +0000 Subject: [issue15972] wrong error message for os.path.getsize In-Reply-To: <1348071122.36.0.302681706423.issue15972@psf.upfronthosting.co.za> Message-ID: <1348143200.6.0.373946814087.issue15972@psf.upfronthosting.co.za> STINNER Victor added the comment: Set the priority to release blocker until it is decided if this issue is a regression, or a new feature :-) ---------- priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 14:16:32 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 20 Sep 2012 12:16:32 +0000 Subject: [issue15960] logging.shutdown should cope with IO errors from handler.release methods In-Reply-To: <1347954020.8.0.36541508073.issue15960@psf.upfronthosting.co.za> Message-ID: <1348143392.61.0.406567216738.issue15960@psf.upfronthosting.co.za> Nick Coghlan added the comment: Dan and Amit worked out a patch for ConcurrentLogHandler (https://bugzilla.redhat.com/show_bug.cgi?id=858912) so I'm OK with rejecting this one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 14:23:51 2012 From: report at bugs.python.org (=?utf-8?b?TcO8bWluIMOWenTDvHJr?=) Date: Thu, 20 Sep 2012 12:23:51 +0000 Subject: [issue12750] datetime.strftime('%s') should respect tzinfo In-Reply-To: <1313375473.21.0.352014190788.issue12750@psf.upfronthosting.co.za> Message-ID: <1348143831.72.0.596088909091.issue12750@psf.upfronthosting.co.za> M?min ?zt?rk added the comment: I made a patch for datetime.strftime('%s'). it takes tzinfo into consideration. >>> datetime.datetime(1970,1,1).strftime("%s") '-7200' >>> datetime.datetime(1970,1,1, tzinfo=datetime.timezone.utc).strftime("%s") '0' datetime.date still behave as naive datetime.datetime >>> datetime.date(1970,1,1).strftime("%s") '-7200' ---------- keywords: +patch nosy: +mumino Added file: http://bugs.python.org/file27231/strftime.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 14:35:15 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 20 Sep 2012 12:35:15 +0000 Subject: [issue15144] Possible integer overflow in operations with addresses and sizes. In-Reply-To: <1340395368.97.0.504662983992.issue15144@psf.upfronthosting.co.za> Message-ID: <1348144515.83.0.277537935748.issue15144@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Well, here is a new patch. The five new macros moved to pymacros.h and used in more files. ---------- Added file: http://bugs.python.org/file27232/align_operations2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 14:38:19 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 20 Sep 2012 12:38:19 +0000 Subject: [issue14783] Make int() and str() docstrings correct In-Reply-To: <1336751413.58.0.519130225761.issue14783@psf.upfronthosting.co.za> Message-ID: <1348144699.51.0.109188717562.issue14783@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It may be worth rewrite int() and str() so that the first argument was positional-only argument? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 14:52:12 2012 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 20 Sep 2012 12:52:12 +0000 Subject: [issue15144] Possible integer overflow in operations with addresses and sizes. In-Reply-To: <1340395368.97.0.504662983992.issue15144@psf.upfronthosting.co.za> Message-ID: <1348145532.87.0.657520920114.issue15144@psf.upfronthosting.co.za> Mark Dickinson added the comment: Apologies; I got distracted from the main point of this issue with the strict aliasing stuff, and then it fell off the to-do list. Unassigning; Antoine or Victor, do you want to take this? ---------- assignee: mark.dickinson -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 15:29:52 2012 From: report at bugs.python.org (Karl Bicker) Date: Thu, 20 Sep 2012 13:29:52 +0000 Subject: [issue15983] multiprocessing JoinableQueue's join function with timeout Message-ID: <1348147792.78.0.126354805475.issue15983@psf.upfronthosting.co.za> New submission from Karl Bicker: The multiprocessing.JoinableQueue's function join() should have a timeout argument so that one can check on other things while waiting for a queue to finish. As join() uses a condition to wait anyway, a timeout is easily implemented and passed to the Condidition.wait(). Patch is attached. ---------- components: Library (Lib) files: JoinableQueue_with_timeout.patch keywords: patch messages: 170812 nosy: legordian priority: normal severity: normal status: open title: multiprocessing JoinableQueue's join function with timeout type: enhancement versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file27233/JoinableQueue_with_timeout.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 15:40:32 2012 From: report at bugs.python.org (Berker Peksag) Date: Thu, 20 Sep 2012 13:40:32 +0000 Subject: [issue15983] multiprocessing JoinableQueue's join function with timeout In-Reply-To: <1348147792.78.0.126354805475.issue15983@psf.upfronthosting.co.za> Message-ID: <1348148432.47.0.514267217986.issue15983@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- versions: -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 16:35:32 2012 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 20 Sep 2012 14:35:32 +0000 Subject: [issue15960] logging.shutdown should cope with IO errors from handler.release methods In-Reply-To: <1347954020.8.0.36541508073.issue15960@psf.upfronthosting.co.za> Message-ID: <1348151732.94.0.362730145982.issue15960@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- assignee: -> vinay.sajip resolution: -> wont fix stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 16:36:18 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 20 Sep 2012 14:36:18 +0000 Subject: [issue14783] Make int() and str() docstrings correct In-Reply-To: <1336751413.58.0.519130225761.issue14783@psf.upfronthosting.co.za> Message-ID: <1348151778.11.0.593169922887.issue14783@psf.upfronthosting.co.za> Ezio Melotti added the comment: That would be backward incompatible, and there might be some valid (corner) cases to pass it as a keyword. Since people are usually not supposed to use it as a keyword arg, it doesn't matter much if the name is different if that makes the docs more understandable. If someone tries to do int(number=10) and gets an error it would likely switch to the simpler int(10). If he really needs keyword args he can always check the code. That said, I don't have a strong opinion about this, so if people think that x should be used, it's fine with me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 16:53:09 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 20 Sep 2012 14:53:09 +0000 Subject: [issue15954] No error checking after using of the wcsxfrm() In-Reply-To: <1347876874.21.0.668678433738.issue15954@psf.upfronthosting.co.za> Message-ID: <1348152789.11.0.127738345027.issue15954@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > No, I think the appropriate error is ValueError, at least if errno is EINVAL. With what message? > msvcrt gives EILSEQ or ERANGE, but never EINVAL. EILSEQ is returned if LCMapString failed, and ERANE if the output buffer is too small. I don't see where ERANE can be returned. If the output buffer is too small then the required buffer size (not including terminating null-char) should be returned. I?see the same issue with wcscoll() in locale.strcoll(). An alternative solution is in case of an error to return the original string (in locale.strxfrm) and to compare strings without regard locale (in locale.strcoll). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 16:53:44 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 20 Sep 2012 14:53:44 +0000 Subject: [issue15973] Segmentation fault on timezone comparison In-Reply-To: <1348077797.35.0.854267629086.issue15973@psf.upfronthosting.co.za> Message-ID: <1348152824.26.0.590459654947.issue15973@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > Alexander, did you send a contributor agreement? At least twice. :-) ---------- keywords: +patch priority: normal -> high stage: needs patch -> commit review Added file: http://bugs.python.org/file27234/issue15973.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 16:59:40 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 20 Sep 2012 14:59:40 +0000 Subject: [issue15981] improve documentation of __hash__ In-Reply-To: <1348138824.37.0.3310744827.issue15981@psf.upfronthosting.co.za> Message-ID: <1348153180.26.0.125960217698.issue15981@psf.upfronthosting.co.za> R. David Murray added the comment: This has already been fixed, and the change is visible in the online documentation. ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> confusing docs with regard to __hash__ _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 17:06:35 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 20 Sep 2012 15:06:35 +0000 Subject: [issue15983] multiprocessing JoinableQueue's join function with timeout In-Reply-To: <1348147792.78.0.126354805475.issue15983@psf.upfronthosting.co.za> Message-ID: <1348153595.25.0.281108515555.issue15983@psf.upfronthosting.co.za> Changes by Richard Oudkerk : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 17:14:32 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 20 Sep 2012 15:14:32 +0000 Subject: [issue15144] Possible integer overflow in operations with addresses and sizes. In-Reply-To: <1348145532.87.0.657520920114.issue15144@psf.upfronthosting.co.za> Message-ID: <201209201814.15170.storchaka@gmail.com> Serhiy Storchaka added the comment: Mark, please open a new discussion, so we don't lose it and that was the place for discussion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 17:42:43 2012 From: report at bugs.python.org (David Beazley) Date: Thu, 20 Sep 2012 15:42:43 +0000 Subject: [issue15944] memoryviews and ctypes In-Reply-To: <1347635130.32.0.649142152247.issue15944@psf.upfronthosting.co.za> Message-ID: <1348155763.15.0.251237423811.issue15944@psf.upfronthosting.co.za> David Beazley added the comment: There's probably a bigger discussion about memoryviews for a rainy day. However, the number one thing that would save all of this in my book would be to make sure cast('B') is universally supported regardless of format including endianness--especially in the standard library. For example, being able to do this: >>> a = array.array('d',[1.0, 2.0, 3.0, 4.0]) >>> m = memoryview(a).cast('B') >>> m[0:4] = b'\x00\x01\x02\x03' >>> a array('d', [1.0000000112050316, 2.0, 3.0, 4.0]) >>> Right now, it doesn't work for ctypes. For example: >>> import ctypes >>> a = (ctypes.c_double * 4)(1,2,3,4) >>> a <__main__.c_double_Array_4 object at 0x1006a7cb0> >>> m = memoryview(a).cast('B') Traceback (most recent call last): File "", line 1, in ValueError: memoryview: source format must be a native single character format prefixed with an optional '@' >>> As some background, being able to work with a "byte" view of memory is important for a lot of problems involving I/O, data interchange, and related problems where being able to accurately construct/deconstruct the underlying memory buffers is more useful than actually interpreting their contents. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 17:50:00 2012 From: report at bugs.python.org (David Beazley) Date: Thu, 20 Sep 2012 15:50:00 +0000 Subject: [issue15944] memoryviews and ctypes In-Reply-To: <1347635130.32.0.649142152247.issue15944@psf.upfronthosting.co.za> Message-ID: <1348156200.1.0.188144945943.issue15944@psf.upfronthosting.co.za> David Beazley added the comment: One followup note---I think it's fine to punt on cast('B') if the memoryview is non-contiguous. That's a rare case that's probably not as common. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 17:56:02 2012 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 20 Sep 2012 15:56:02 +0000 Subject: [issue15421] Calendar.itermonthdates OverflowError In-Reply-To: <1342967144.9.0.843108675207.issue15421@psf.upfronthosting.co.za> Message-ID: <1348156562.21.0.189049842384.issue15421@psf.upfronthosting.co.za> Skip Montanaro added the comment: LGTM ---------- nosy: +skip.montanaro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 18:18:27 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 20 Sep 2012 16:18:27 +0000 Subject: [issue15984] Wrong documentation for PyUnicode_FromObject() Message-ID: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: In the documentation it is written that PyUnicode_FromObject() is a shortcut for PyUnicode_FromEncodedObject(). But PyUnicode_FromObject() is not call PyUnicode_FromEncodedObject() direct nor indirect. PyUnicode_FromObject() works only with unicode and unicode subclass objects, PyUnicode_FromEncodedObject() is not works with unicode objects. ---------- assignee: docs at python components: Documentation messages: 170821 nosy: docs at python, storchaka priority: normal severity: normal status: open title: Wrong documentation for PyUnicode_FromObject() versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 18:19:32 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 20 Sep 2012 16:19:32 +0000 Subject: [issue15421] Calendar.itermonthdates OverflowError In-Reply-To: <1342967144.9.0.843108675207.issue15421@psf.upfronthosting.co.za> Message-ID: <1348157972.54.0.670315709414.issue15421@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 18:47:53 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 20 Sep 2012 16:47:53 +0000 Subject: [issue15985] round() has wrong argument names Message-ID: <1348159673.68.0.790286767208.issue15985@psf.upfronthosting.co.za> New submission from Chris Jerdonek: The documentation for round() says: round(x[, n]) Return the floating point value x rounded to n digits after the decimal point. If n is omitted, it defaults to zero. Delegates to x.__round__(n). (from http://docs.python.org/dev/library/functions.html#round ) However, we have the following: Python 3.3.0rc2+ (default:1704deb7e6d7+, Sep 16 2012, 04:49:45) >>> round(x=4.7) Traceback (most recent call last): File "", line 1, in TypeError: Required argument 'number' (pos 1) not found >>> round(number=4.7) 5 The second argument is also affected: >>> round(5.1234, n=3) Traceback (most recent call last): File "", line 1, in TypeError: 'n' is an invalid keyword argument for this function >>> round(5.1234, ndigits=3) 5.123 ---------- assignee: docs at python components: Documentation keywords: easy messages: 170822 nosy: cjerdonek, docs at python priority: normal severity: normal stage: needs patch status: open title: round() has wrong argument names type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 18:48:44 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 20 Sep 2012 16:48:44 +0000 Subject: [issue15985] round() has wrong argument names In-Reply-To: <1348159673.68.0.790286767208.issue15985@psf.upfronthosting.co.za> Message-ID: <1348159724.23.0.414150160421.issue15985@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 18:50:33 2012 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 20 Sep 2012 16:50:33 +0000 Subject: [issue15985] round() has wrong argument names In-Reply-To: <1348159673.68.0.790286767208.issue15985@psf.upfronthosting.co.za> Message-ID: <1348159833.48.0.217474795634.issue15985@psf.upfronthosting.co.za> Mark Dickinson added the comment: A case where fixing the names improves both accuracy *and* readability! ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 19:16:06 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 20 Sep 2012 17:16:06 +0000 Subject: [issue15421] Calendar.itermonthdates OverflowError In-Reply-To: <1342967144.9.0.843108675207.issue15421@psf.upfronthosting.co.za> Message-ID: <1348161366.5.0.88293810774.issue15421@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Context: http://issues.roundup-tracker.org/issue2550765 ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 19:18:08 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 20 Sep 2012 17:18:08 +0000 Subject: [issue15421] Calendar.itermonthdates OverflowError In-Reply-To: <1342967144.9.0.843108675207.issue15421@psf.upfronthosting.co.za> Message-ID: <1348161488.46.0.602291293947.issue15421@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: -> ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 19:54:58 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 20 Sep 2012 17:54:58 +0000 Subject: [issue15972] wrong error message for os.path.getsize In-Reply-To: <1348143157.49.0.737787908322.issue15972@psf.upfronthosting.co.za> Message-ID: <201209202054.40689.storchaka@gmail.com> Serhiy Storchaka added the comment: Here is a patch. Are there any tests for string and bytes arguments as filenames? I will add float and list there. ---------- keywords: +patch Added file: http://bugs.python.org/file27235/posix_path_converter.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r ddec854843f1 Modules/posixmodule.c --- a/Modules/posixmodule.c Thu Sep 20 09:47:41 2012 +0300 +++ b/Modules/posixmodule.c Thu Sep 20 20:50:29 2012 +0300 @@ -427,26 +427,24 @@ #endif static int -_fd_converter(PyObject *o, int *p, int default_value) { - long long_value; - if (o == Py_None) { - *p = default_value; - return 1; - } - if (PyFloat_Check(o)) { - PyErr_SetString(PyExc_TypeError, - "integer argument expected, got float" ); +_fd_converter(PyObject *o, int *p, const char *allowed) +{ + int overflow; + long long_value = PyLong_AsLongAndOverflow(o, &overflow); + if (PyFloat_Check(o) || + (long_value == -1 && !overflow && PyErr_Occurred())) { + PyErr_Clear(); + PyErr_Format(PyExc_TypeError, + "argument must be %s, not %.200s", + allowed, Py_TYPE(o)->tp_name); return 0; } - long_value = PyLong_AsLong(o); - if (long_value == -1 && PyErr_Occurred()) - return 0; - if (long_value > INT_MAX) { + if (overflow > 0 || long_value > INT_MAX) { PyErr_SetString(PyExc_OverflowError, "signed integer is greater than maximum"); return 0; } - if (long_value < INT_MIN) { + if (overflow < 0 || long_value < INT_MIN) { PyErr_SetString(PyExc_OverflowError, "signed integer is less than minimum"); return 0; @@ -456,8 +454,13 @@ } static int -dir_fd_converter(PyObject *o, void *p) { - return _fd_converter(o, (int *)p, DEFAULT_DIR_FD); +dir_fd_converter(PyObject *o, void *p) +{ + if (o == Py_None) { + *(int *)p = DEFAULT_DIR_FD; + return 1; + } + return _fd_converter(o, (int *)p, "integer"); } @@ -634,17 +637,16 @@ } else { PyErr_Clear(); - bytes = PyBytes_FromObject(o); + if (PyObject_CheckBuffer(o)) + bytes = PyBytes_FromObject(o); + else + bytes = NULL; if (!bytes) { PyErr_Clear(); if (path->allow_fd) { int fd; - /* - * note: _fd_converter always permits None. - * but we've already done our None check. - * so o cannot be None at this point. - */ - int result = _fd_converter(o, &fd, -1); + int result = _fd_converter(o, &fd, + "string, bytes or integer"); if (result) { path->wide = NULL; path->narrow = NULL; @@ -705,15 +707,17 @@ } static int -dir_fd_unavailable(PyObject *o, void *p) { - int *dir_fd = (int *)p; - int return_value = _fd_converter(o, dir_fd, DEFAULT_DIR_FD); - if (!return_value) +dir_fd_unavailable(PyObject *o, void *p) +{ + int dir_fd; + if (!dir_fd_converter(o, &dir_fd)) return 0; - if (*dir_fd == DEFAULT_DIR_FD) - return 1; - argument_unavailable_error(NULL, "dir_fd"); - return 0; + if (dir_fd != DEFAULT_DIR_FD) { + argument_unavailable_error(NULL, "dir_fd"); + return 0; + } + *(int *)p = dir_fd; + return 1; } static int From report at bugs.python.org Thu Sep 20 19:57:18 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 20 Sep 2012 17:57:18 +0000 Subject: [issue15986] memoryview: expose 'buf' attribute Message-ID: <1348163838.24.0.972937834938.issue15986@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- components: Interpreter Core nosy: dabeaz, skrah priority: normal severity: normal stage: needs patch status: open title: memoryview: expose 'buf' attribute type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 20:43:57 2012 From: report at bugs.python.org (Julian Berman) Date: Thu, 20 Sep 2012 18:43:57 +0000 Subject: [issue15987] Provide a way to compare AST nodes for equality recursively Message-ID: <1348166637.22.0.281544835659.issue15987@psf.upfronthosting.co.za> New submission from Julian Berman: As is, as far as I can tell, there's no way to easily compare two AST nodes to see if they have the same children and same fields (recursively). I'm writing some unit tests for a NodeTransformers, so I've settled for comparing `ast.dump()`s of each, which is kind of dirty, but 1) works and 2) produces reasonable failure messages. (As a side note of what else I've tried, comparing, say, a list of the `iter_child_nodes` is not a good alternative, since the tests I'm writing are making assertions that a given node was not modified, which means they deepcopy the node and then want to assert that the "transformed" node is unchanged.) I don't know the global implications of changing ast.AST.__eq__ to know if that's feasible (hopefully someone will comment on that), but if it isn't, another provided way would be nice. ---------- components: Library (Lib) messages: 170826 nosy: Julian priority: normal severity: normal status: open title: Provide a way to compare AST nodes for equality recursively type: enhancement versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 20:51:10 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 20 Sep 2012 18:51:10 +0000 Subject: [issue15988] Inconsistency in overflow error messages of integer argument Message-ID: <1348167070.37.0.305629822418.issue15988@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: PyArg_ParseTuple raises inconsistent overflow error messages for small integer formats. For example: >>> import _testcapi >>> _testcapi.getargs_b(100) 100 >>> _testcapi.getargs_b(1000) Traceback (most recent call last): File "", line 1, in OverflowError: unsigned byte integer is greater than maximum >>> _testcapi.getargs_b(-1000) Traceback (most recent call last): File "", line 1, in OverflowError: unsigned byte integer is less than minimum >>> _testcapi.getargs_b(100000000000000000000) Traceback (most recent call last): File "", line 1, in OverflowError: Python int too large to convert to C long >>> _testcapi.getargs_b(-100000000000000000000) Traceback (most recent call last): File "", line 1, in OverflowError: Python int too large to convert to C long On platforms with 32-bit int and 64-bit long there will be more such cases. ---------- components: Interpreter Core messages: 170827 nosy: storchaka priority: low severity: normal status: open title: Inconsistency in overflow error messages of integer argument type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 20:51:51 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 20 Sep 2012 18:51:51 +0000 Subject: [issue15144] Possible integer overflow in operations with addresses and sizes. In-Reply-To: <1340395368.97.0.504662983992.issue15144@psf.upfronthosting.co.za> Message-ID: <1348167111.47.0.264811910966.issue15144@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the patch! These macros will be useful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 20:57:02 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 20 Sep 2012 18:57:02 +0000 Subject: [issue15985] round() has wrong argument names In-Reply-To: <1348159673.68.0.790286767208.issue15985@psf.upfronthosting.co.za> Message-ID: <1348167422.93.0.32564318421.issue15985@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Here is a patch. Also, I checked, and there is already a test for the keyword arguments: http://hg.python.org/cpython/file/dcced3bd22fe/Lib/test/test_builtin.py#l1239 ---------- keywords: +needs review, patch stage: needs patch -> patch review Added file: http://bugs.python.org/file27236/issue-15985-1-branch-default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 20:57:45 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 20 Sep 2012 18:57:45 +0000 Subject: [issue15144] Possible integer overflow in operations with addresses and sizes. In-Reply-To: <1340395368.97.0.504662983992.issue15144@psf.upfronthosting.co.za> Message-ID: <3XN6dN1CV3zPPL@mail.python.org> Roundup Robot added the comment: New changeset 99112b851b25 by Antoine Pitrou in branch 'default': Issue #15144: Fix possible integer overflow when handling pointers as integer values, by using Py_uintptr_t instead of size_t. http://hg.python.org/cpython/rev/99112b851b25 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 20:58:50 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 20 Sep 2012 18:58:50 +0000 Subject: [issue15144] Possible integer overflow in operations with addresses and sizes. In-Reply-To: <1340395368.97.0.504662983992.issue15144@psf.upfronthosting.co.za> Message-ID: <1348167530.79.0.189266805116.issue15144@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Committed in 3.3(.1). ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: +Python 3.3 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 21:01:45 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 20 Sep 2012 19:01:45 +0000 Subject: [issue15989] Possible integer overflow of PyLong_AsLong() results Message-ID: <1348167705.87.0.588220983695.issue15989@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: There are several places where the result of PyLong_AsLong() assigned to variable of type int. It can cause unknown issues on platforms with sizeof(int) != sizeof(long). All 140 cases of PyLong_AsLong() usage should be checked. ---------- assignee: storchaka components: Interpreter Core messages: 170832 nosy: storchaka priority: normal severity: normal status: open title: Possible integer overflow of PyLong_AsLong() results type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 21:05:08 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 20 Sep 2012 19:05:08 +0000 Subject: [issue15973] Segmentation fault on timezone comparison In-Reply-To: <1348077797.35.0.854267629086.issue15973@psf.upfronthosting.co.za> Message-ID: <1348167908.5.0.0984648896032.issue15973@psf.upfronthosting.co.za> Stefan Krah added the comment: Looks good. It would be nice to have this in 3.3.0. There are a couple of blockers open, so perhaps this could go in, too. Georg, are we going to have an rc3 anyway? ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 21:24:17 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 20 Sep 2012 19:24:17 +0000 Subject: [issue15990] solidify argument/parameter terminology Message-ID: <1348169057.62.0.370171802379.issue15990@psf.upfronthosting.co.za> New submission from Chris Jerdonek: There is currently some ambiguity in our documentation around positional and keyword arguments (e.g. whether positional means "position-only" or "non-keyword" (roughly) and whether various terms and definitions should be for the calling syntax or the function definition syntax or both). For example, see the python-dev thread starting here: http://mail.python.org/pipermail/python-dev/2012-September/121760.html It would be good to nail down the preferred terminology in a central place. I would suggest that the glossary is a good place to start. For example, when there is a question about what phrase an error message should use or how an error message should be interpreted, it would be good if (at least going forward) the glossary could be used as a definitive resource. This issue may involve making a distinction in our terminology "between arguments (what you pass, call syntax) and parameters (what the function receives, function definition syntax)" (see http://mail.python.org/pipermail/python-dev/2012-September/121771.html ). ---------- assignee: docs at python components: Documentation messages: 170834 nosy: cjerdonek, docs at python priority: normal severity: normal status: open title: solidify argument/parameter terminology _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 21:36:07 2012 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 20 Sep 2012 19:36:07 +0000 Subject: [issue15985] round() has wrong argument names In-Reply-To: <1348159673.68.0.790286767208.issue15985@psf.upfronthosting.co.za> Message-ID: <1348169767.43.0.74258113533.issue15985@psf.upfronthosting.co.za> Mark Dickinson added the comment: Looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 21:52:20 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 20 Sep 2012 19:52:20 +0000 Subject: [issue15985] round() has wrong argument names In-Reply-To: <1348159673.68.0.790286767208.issue15985@psf.upfronthosting.co.za> Message-ID: <3XN7rM50TVzQm0@mail.python.org> Roundup Robot added the comment: New changeset eccd94d4ee77 by Mark Dickinson in branch '3.2': Issue 15985: fix round argument names in documentation. Thanks Chris Jerdonek. http://hg.python.org/cpython/rev/eccd94d4ee77 New changeset ad04dd6c07f7 by Mark Dickinson in branch 'default': Issue 15985: merge from 3.2. http://hg.python.org/cpython/rev/ad04dd6c07f7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 21:58:04 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 20 Sep 2012 19:58:04 +0000 Subject: [issue15985] round() has wrong argument names In-Reply-To: <1348159673.68.0.790286767208.issue15985@psf.upfronthosting.co.za> Message-ID: <3XN7yz5BlKzQlt@mail.python.org> Roundup Robot added the comment: New changeset e4037dd73877 by Mark Dickinson in branch '2.7': Issue 15985: fix round argument names in documentation. Thanks Chris Jerdonek. http://hg.python.org/cpython/rev/e4037dd73877 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 21:59:15 2012 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 20 Sep 2012 19:59:15 +0000 Subject: [issue15985] round() has wrong argument names In-Reply-To: <1348159673.68.0.790286767208.issue15985@psf.upfronthosting.co.za> Message-ID: <1348171155.28.0.927582206475.issue15985@psf.upfronthosting.co.za> Mark Dickinson added the comment: Fixed. Thanks for the patch! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 22:01:24 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 20 Sep 2012 20:01:24 +0000 Subject: [issue15985] round() has wrong argument names In-Reply-To: <1348159673.68.0.790286767208.issue15985@psf.upfronthosting.co.za> Message-ID: <1348171284.83.0.391846539139.issue15985@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks for the quick commit, Mark. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 22:03:01 2012 From: report at bugs.python.org (Mikhail Afanasyev) Date: Thu, 20 Sep 2012 20:03:01 +0000 Subject: [issue15991] BaseHTTPServer with ThreadingMixIn serving wrong data sometimes Message-ID: <1348171381.08.0.748825821227.issue15991@psf.upfronthosting.co.za> New submission from Mikhail Afanasyev: When using BaseHTTPServer with ThreadingMixIn, sometimes the wrong data is served. The attached script requests normal URL and URLs which are not found in multiple threads using wget (which only saves pages if it gets 200 OK status). Every once in a while responses are incorrect. - sometimes normal URL gets a '404 not found' content with '200 OK' status. - sometimes, a '404 not found' page gets '200 OK' status code The problems become much, much less frequent if ThreadingMixIn is removed. Python 2.7.3 on ubuntu 12.04 x86_64. ---------- components: Library (Lib) files: http_server_bug.py messages: 170840 nosy: theamk priority: normal severity: normal status: open title: BaseHTTPServer with ThreadingMixIn serving wrong data sometimes versions: Python 2.7 Added file: http://bugs.python.org/file27237/http_server_bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 22:03:04 2012 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 20 Sep 2012 20:03:04 +0000 Subject: [issue15990] solidify argument/parameter terminology In-Reply-To: <1348169057.62.0.370171802379.issue15990@psf.upfronthosting.co.za> Message-ID: <1348171384.59.0.234118650721.issue15990@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 22:07:47 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 20 Sep 2012 20:07:47 +0000 Subject: [issue15990] solidify argument/parameter terminology In-Reply-To: <1348169057.62.0.370171802379.issue15990@psf.upfronthosting.co.za> Message-ID: <1348171667.65.0.130733854049.issue15990@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 22:16:59 2012 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 20 Sep 2012 20:16:59 +0000 Subject: [issue15992] Strict aliasing violations in Objects/unicodeobject.c Message-ID: <1348172219.51.0.84674051024.issue15992@psf.upfronthosting.co.za> New submission from Mark Dickinson: [Broken out of the discussion in issue 15144] Some of the newly-optimized code in Objects/unicodeobject.c contains strict aliasing violations; under the C standards, this is undefined behaviour (C99 6.5p7). An example occurs in ascii_decode: unsigned long value = *(const unsigned long *) _p; Here the pointer dereference violates the strict aliasing rule. I think these portions of Objects/unicodeobject.c should be rewritten to avoid the undefined behaviour. This is not a purely theoretical problem: compilers are known to make optimizations based on the assumption that strict aliasing is not violated. Early versions of David Gay's dtoa.c gave incorrect results as a result of strict aliasing violations, for example; see [1]. [2] gives a stackoverflow reference explaining strict aliasing. [1] http://patrakov.blogspot.co.uk/2009/03/dont-use-old-dtoac.html [2] http://stackoverflow.com/questions/98650/what-is-the-strict-aliasing-rule ---------- components: Interpreter Core messages: 170841 nosy: mark.dickinson, storchaka priority: normal severity: normal status: open title: Strict aliasing violations in Objects/unicodeobject.c type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 22:17:26 2012 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 20 Sep 2012 20:17:26 +0000 Subject: [issue15144] Possible integer overflow in operations with addresses and sizes. In-Reply-To: <1340395368.97.0.504662983992.issue15144@psf.upfronthosting.co.za> Message-ID: <1348172246.56.0.0526951754474.issue15144@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Mark, please open a new discussion. Done: issue 15992. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 22:24:11 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 20 Sep 2012 20:24:11 +0000 Subject: [issue15990] solidify argument/parameter terminology In-Reply-To: <1348169057.62.0.370171802379.issue15990@psf.upfronthosting.co.za> Message-ID: <1348172651.74.0.847441694063.issue15990@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 22:31:09 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 20 Sep 2012 20:31:09 +0000 Subject: [issue15959] Declaration mismatch of quick integer allocation counters In-Reply-To: <1347911556.54.0.0253156044834.issue15959@psf.upfronthosting.co.za> Message-ID: <3XN8j15lPzzQ0k@mail.python.org> Roundup Robot added the comment: New changeset 5ed83105731d by Mark Dickinson in branch '3.2': Issue 15959: Fix type mismatch for quick{_neg}_int_allocs. Thanks Serhiy Storchaka. http://hg.python.org/cpython/rev/5ed83105731d New changeset 3504cbb3e1d8 by Mark Dickinson in branch 'default': Issue 15959: Merge from 3.2. http://hg.python.org/cpython/rev/3504cbb3e1d8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 22:31:50 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 20 Sep 2012 20:31:50 +0000 Subject: [issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails Message-ID: <1348173110.08.0.356112095586.issue15993@psf.upfronthosting.co.za> New submission from Stefan Krah: I've installed 3.3.0-rc2 on Windows-7 64-bit using the msi installer. I'm getting these failures in test_buffer, but I can *not* reproduce them when I build Win-32/pgo/python.exe from source: ====================================================================== FAIL: test_memoryview_assign (test.test_buffer.TestBufferProtocol) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Program Files (x86)\Python33\lib\test\test_buffer.py", line 2863, self.assertEqual(m[i], 8) AssertionError: 34359738368 != 8 ====================================================================== FAIL: test_memoryview_struct_module (test.test_buffer.TestBufferProtocol) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Program Files (x86)\Python33\lib\test\test_buffer.py", line 2476, self.assertEqual(m[0], nd[0]) AssertionError: 15080797365275624638 != 6838299039298601293 ---------- components: Interpreter Core messages: 170844 nosy: brian.curtin, loewis, skrah priority: critical severity: normal status: open title: Windows: 3.3.0-rc2.msi: test_buffer fails versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 22:36:04 2012 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 20 Sep 2012 20:36:04 +0000 Subject: [issue15959] Declaration mismatch of quick integer allocation counters In-Reply-To: <1347911556.54.0.0253156044834.issue15959@psf.upfronthosting.co.za> Message-ID: <1348173364.86.0.985762162358.issue15959@psf.upfronthosting.co.za> Mark Dickinson added the comment: Fixed; thanks for the patch! (It seems this was fixed in Python 2 some time ago: see issue #4850.) ---------- nosy: +mark.dickinson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 22:37:22 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 20 Sep 2012 20:37:22 +0000 Subject: [issue15994] memoryview to freed memory can cause segfault Message-ID: <1348173441.91.0.841080415833.issue15994@psf.upfronthosting.co.za> New submission from Richard Oudkerk: A memoryview which does not own a reference to its base object can point to freed or reallocated memory. For instance the following segfaults for me on Windows and Linux. import io class File(io.RawIOBase): def readinto(self, buf): global view view = buf def readable(self): return True f = io.BufferedReader(File()) f.read(1) # get view of buffer used by BufferedReader del f # deallocate buffer view = view.cast('P') L = [None] * len(view) # create list whose array has same size # (this will probably coincide with view) view[0] = 0 # overwrite first item with NULL print(L[0]) # segfault: dereferencing NULL I realize there are easier ways to make Python segfault, so maybe this should not be considered a serious issue. But I think there should be some way of guaranteeing that a memoryview will not try to access memory which has already been freed. In #15903 skrah proposed exposing memory_release() as PyBuffer_Release(). However, I don't think that would necessarily invalidate all exports of the buffer. Alternatively, one could incref the buffered reader object and set mview->mbuf->obj to it. Maybe we could have PyMemoryView_FromMemoryEx(char *mem, Py_ssize_t size, int flags, PyObject *obj) which guarantees that if obj is non-NULL then it will not be garbage collected before the memoryview. This should *not* expose obj as an attribute of the memoryview. ---------- messages: 170846 nosy: sbt, skrah priority: normal severity: normal status: open title: memoryview to freed memory can cause segfault type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 22:49:20 2012 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 20 Sep 2012 20:49:20 +0000 Subject: [issue15989] Possible integer overflow of PyLong_AsLong() results In-Reply-To: <1348167705.87.0.588220983695.issue15989@psf.upfronthosting.co.za> Message-ID: <1348174160.31.0.541120761381.issue15989@psf.upfronthosting.co.za> Mark Dickinson added the comment: Getting a C int out of a Python int is currently a bit awkward. What do you think about adding a PyLong_AsInt counterpart to PyLong_AsLong? (The alternative is to use PyLong_AsLong and repeat the same overflow detection code in many places.) ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 22:50:20 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 20 Sep 2012 20:50:20 +0000 Subject: [issue15973] Segmentation fault on timezone comparison In-Reply-To: <1348077797.35.0.854267629086.issue15973@psf.upfronthosting.co.za> Message-ID: <3XN97H36kczMdw@mail.python.org> Roundup Robot added the comment: New changeset 9fba12ceb2fd by Alexander Belopolsky in branch '3.2': Issue #15973: Fixed segmentation fault on timezone comparison to other types. http://hg.python.org/cpython/rev/9fba12ceb2fd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 22:53:21 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 20 Sep 2012 20:53:21 +0000 Subject: [issue15973] Segmentation fault on timezone comparison In-Reply-To: <1348077797.35.0.854267629086.issue15973@psf.upfronthosting.co.za> Message-ID: <1348174401.32.0.282150264304.issue15973@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Leeaving the issue open in case it will go to 3.3.0. Reassigning to the RM. ---------- assignee: belopolsky -> georg.brandl resolution: -> fixed stage: commit review -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 23:02:02 2012 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 20 Sep 2012 21:02:02 +0000 Subject: [issue15989] Possible integer overflow of PyLong_AsLong() results In-Reply-To: <1348167705.87.0.588220983695.issue15989@psf.upfronthosting.co.za> Message-ID: <1348174922.56.0.595049097612.issue15989@psf.upfronthosting.co.za> Mark Dickinson added the comment: In the Objects subdirectory (which is all I've looked at so far), I see issues in: - fileobject.c (PyObject_AsFileDescriptor) - structseq.c (PyLong_AsLong return value used as a Py_ssize_t; probably safe, but it would be better to use PyLong_AsSsize_t). - unicodeobject.c (one place where result assigned to something of type ssize_t, one where result assigned to something of type int). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 23:10:40 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 20 Sep 2012 21:10:40 +0000 Subject: [issue15990] solidify argument/parameter terminology In-Reply-To: <1348169057.62.0.370171802379.issue15990@psf.upfronthosting.co.za> Message-ID: <1348175440.31.0.86155644911.issue15990@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 23:16:07 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 20 Sep 2012 21:16:07 +0000 Subject: [issue15973] Segmentation fault on timezone comparison In-Reply-To: <1348077797.35.0.854267629086.issue15973@psf.upfronthosting.co.za> Message-ID: <1348175767.67.0.0666040397957.issue15973@psf.upfronthosting.co.za> STINNER Victor added the comment: Your change does not compile on Windows: _datetimemodule.c ..\Modules\_datetimemodule.c(3247) : error C2065: 'Py_RETURN_NOTIMPLEMENTED' : undeclared identifier http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.2/builds/194/steps/compile/logs/stdio ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 23:25:38 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 20 Sep 2012 21:25:38 +0000 Subject: [issue15973] Segmentation fault on timezone comparison In-Reply-To: <1348077797.35.0.854267629086.issue15973@psf.upfronthosting.co.za> Message-ID: <3XN9w13K5HzQSF@mail.python.org> Roundup Robot added the comment: New changeset f17f67f0ec4b by Alexander Belopolsky in branch '3.2': Issue #15973: fixed 3.2 backport. http://hg.python.org/cpython/rev/f17f67f0ec4b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 23:30:11 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 20 Sep 2012 21:30:11 +0000 Subject: [issue15987] Provide a way to compare AST nodes for equality recursively In-Reply-To: <1348166637.22.0.281544835659.issue15987@psf.upfronthosting.co.za> Message-ID: <1348176611.97.0.606127442782.issue15987@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 23:31:21 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 20 Sep 2012 21:31:21 +0000 Subject: [issue11454] email.message import time In-Reply-To: <1299701237.24.0.992920521308.issue11454@psf.upfronthosting.co.za> Message-ID: <1348176681.08.0.345740669312.issue11454@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 23:34:41 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 20 Sep 2012 21:34:41 +0000 Subject: [issue15995] Windows: 3.3.0-rc2.msi: test_lzma fails Message-ID: <1348176881.28.0.847630849965.issue15995@psf.upfronthosting.co.za> New submission from Stefan Krah: This is similar to #15993: With the installed Python from the rc2-msi test_lzma fails. I cannot reproduce the failure with python.exe (PGO) compiled from source: ====================================================================== ERROR: test__decode_filter_properties (test.test_lzma.MiscellaneousTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python33\lib\test\test_lzma.py", line 1105, in test__decode_filter_properties lzma.FILTER_LZMA1, b"]\x00\x00\x80\x00") ValueError: Invalid filter ID: 4611686018427387905 ====================================================================== ERROR: test_filter_properties_roundtrip (test.test_lzma.MiscellaneousTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python33\lib\test\test_lzma.py", line 1114, in test_filter_properties_roundtrip lzma.FILTER_LZMA1, b"]\x00\x00\x80\x00") ValueError: Invalid filter ID: 4611686018427387905 ---------------------------------------------------------------------- ---------- components: Interpreter Core messages: 170853 nosy: brian.curtin, loewis, skrah priority: critical severity: normal status: open title: Windows: 3.3.0-rc2.msi: test_lzma fails type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 23:35:30 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 20 Sep 2012 21:35:30 +0000 Subject: [issue15995] Windows: 3.3.0-rc2.msi: test_lzma fails In-Reply-To: <1348176881.28.0.847630849965.issue15995@psf.upfronthosting.co.za> Message-ID: <1348176930.86.0.383536240217.issue15995@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +nadeem.vawda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 23:43:10 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 20 Sep 2012 21:43:10 +0000 Subject: [issue15421] Calendar.itermonthdates OverflowError In-Reply-To: <1342967144.9.0.843108675207.issue15421@psf.upfronthosting.co.za> Message-ID: <1348177390.66.0.222125606041.issue15421@psf.upfronthosting.co.za> STINNER Victor added the comment: Hi C?dric! while True: yield date - date += oneday + try: + date += oneday + except OverflowError: + break You might add a comment explaining why we may get an OverflowError here. I don't know the cost of adding a try/except in a loop. But the loop has 31 iterations or less, so it's maybe better to keep the explicit try/except around date += oneday. + def test_itermonthdates(self): + # ensure itermonthdates works for all months + list(calendar.Calendar().itermonthdates(9999, 12)) Please use datetime.MAXYEAR instead of this hardcoded constant. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 23:43:35 2012 From: report at bugs.python.org (Larry Hastings) Date: Thu, 20 Sep 2012 21:43:35 +0000 Subject: [issue15972] wrong error message for os.path.getsize In-Reply-To: <1348071122.36.0.302681706423.issue15972@psf.upfronthosting.co.za> Message-ID: <1348177415.05.0.535891661599.issue15972@psf.upfronthosting.co.za> Larry Hastings added the comment: Patch looks like it'll work fine. But please add regression tests checking that the error message is what we want. Are the new error messages okay with the OP? It looks like now it'll throw TypeError("argument must be string, bytes or integer, not list"). v I'd personally prefer the Oxford Comma there ("string, bytes, or integer"). But I don't know if there is a style preference one way or the other in Python error messages. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 23:53:34 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 20 Sep 2012 21:53:34 +0000 Subject: [issue15995] Windows: 3.3.0-rc2.msi: test_lzma fails In-Reply-To: <1348176881.28.0.847630849965.issue15995@psf.upfronthosting.co.za> Message-ID: <1348178014.32.0.287619193298.issue15995@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 20 23:53:37 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 20 Sep 2012 21:53:37 +0000 Subject: [issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails In-Reply-To: <1348173110.08.0.356112095586.issue15993@psf.upfronthosting.co.za> Message-ID: <1348178017.81.0.0647543406987.issue15993@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 00:00:28 2012 From: report at bugs.python.org (mattip) Date: Thu, 20 Sep 2012 22:00:28 +0000 Subject: [issue15996] pow() for complex numbers is rough around the edges Message-ID: <1348178428.15.0.517718755216.issue15996@psf.upfronthosting.co.za> New submission from mattip: complex(1., 0.) ** complex(float('inf'), 0.) raises a ZeroDivisionError. In general, complex_power() needs to handle more corner cases. Barring a clear standard for pow() in C99, the documentation for pow 3 in glibc http://www.kernel.org/doc/man-pages/online/pages/man3/pow.3.html seems solid for a start, however it only describes behaviour for float/double values. Where would be an appropriate place to add tests? I propose adding a test-case file similar to cmath_testcases.txt (attached) and a test runner similar to test_cmath.py ---------- components: Interpreter Core files: rcomplex_testcases2.txt messages: 170856 nosy: mark.dickinson, mattip priority: normal severity: normal status: open title: pow() for complex numbers is rough around the edges type: behavior Added file: http://bugs.python.org/file27238/rcomplex_testcases2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 00:02:18 2012 From: report at bugs.python.org (Alex Gaynor) Date: Thu, 20 Sep 2012 22:02:18 +0000 Subject: [issue15996] pow() for complex numbers is rough around the edges In-Reply-To: <1348178428.15.0.517718755216.issue15996@psf.upfronthosting.co.za> Message-ID: <1348178538.84.0.460854796062.issue15996@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 00:02:22 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 20 Sep 2012 22:02:22 +0000 Subject: [issue15548] Mention all new os functions in What's New in Python 3.3 In-Reply-To: <1343996760.47.0.232563077305.issue15548@psf.upfronthosting.co.za> Message-ID: <1348178542.24.0.108382652593.issue15548@psf.upfronthosting.co.za> STINNER Victor added the comment: The doc is now complete. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 00:05:45 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 20 Sep 2012 22:05:45 +0000 Subject: [issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails In-Reply-To: <1348173110.08.0.356112095586.issue15993@psf.upfronthosting.co.za> Message-ID: <1348178745.93.0.180513629304.issue15993@psf.upfronthosting.co.za> Stefan Krah added the comment: Both lzma and memoryview use PyLong_AsUnsignedLongLong() in the affected code paths. I get this with the msi installed python.exe: >>> import array >>> a = array.array('Q', [1,2,3,4]) >>> m = memoryview(a) >>> m[0] = 4 >>> m[0] 17179869184 >>> And the correct result with the self-compiled (PGO) python.exe: >>> import array >>> a = array.array('Q', [1,2,3,4]) >>> m = memoryview(a) >>> m[0] = 4 >>> m[0] 4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 00:15:44 2012 From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=) Date: Thu, 20 Sep 2012 22:15:44 +0000 Subject: [issue15421] Calendar.itermonthdates OverflowError In-Reply-To: <1342967144.9.0.843108675207.issue15421@psf.upfronthosting.co.za> Message-ID: <1348179344.83.0.968895610063.issue15421@psf.upfronthosting.co.za> C?dric Krier added the comment: Fix haypo comments ---------- Added file: http://bugs.python.org/file27239/calendar.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 07:50:37 2012 From: report at bugs.python.org (Max) Date: Fri, 21 Sep 2012 05:50:37 +0000 Subject: [issue15997] NotImplemented needs to be documented Message-ID: <1348206637.53.0.485410334327.issue15997@psf.upfronthosting.co.za> New submission from Max: Quoting from http://docs.python.org/reference/datamodel.html#the-standard-type-hierarchy: NotImplemented This type has a single value. There is a single object with this value. This object is accessed through the built-in name NotImplemented. Numeric methods and rich comparison methods may return this value if they do not implement the operation for the operands provided. (The interpreter will then try the reflected operation, or some other fallback, depending on the operator.) Its truth value is true. This is not a sufficient description of NotImplemented behavior. What does it mean "reflected operation" (I assume it is other.__eq__(self), but it needs to be clarified), and what does it mean "or some other fallback" (wouldn't developers need to know?). It also doesn't state what happens if the reflected operation or the fallback again return NotImplemented. The rest of the documentation doesn't seem to talk about this either, despite several mentions of NotImplemented, with references to other sections. This is particularly serious problem because Python's behavior changed in this respect not that long ago. ---------- assignee: docs at python components: Documentation messages: 170860 nosy: docs at python, max priority: normal severity: normal status: open title: NotImplemented needs to be documented type: enhancement versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 07:57:34 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 21 Sep 2012 05:57:34 +0000 Subject: [issue15997] NotImplemented needs to be documented In-Reply-To: <1348206637.53.0.485410334327.issue15997@psf.upfronthosting.co.za> Message-ID: <1348207054.19.0.747755200335.issue15997@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This must not be documented for NotImplemented, but for the operations itself. On the same page, it says "There are no swapped-argument versions of these methods (to be used when the left argument does not support the operation but the right argument does); rather, __lt__() and __gt__() are each other?s reflection, __le__() and __ge__() are each other?s reflection, and __eq__() and __ne__() are their own reflection." So I'd say it's there already. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 08:38:35 2012 From: report at bugs.python.org (Max) Date: Fri, 21 Sep 2012 06:38:35 +0000 Subject: [issue15997] NotImplemented needs to be documented In-Reply-To: <1348206637.53.0.485410334327.issue15997@psf.upfronthosting.co.za> Message-ID: <1348209515.47.0.397254464827.issue15997@psf.upfronthosting.co.za> Max added the comment: I agree about reflected operation, although the wording could be clearer ("will try reflected operation" is better worded as "will return the result of the reflected operation called on the swapped arguments".) But what does it mean "or some other fallback"? And what if the reflected operation or the fallback again return NotImplemented or is actually not implemented. Is it somewhere else in the docs? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 08:51:18 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 21 Sep 2012 06:51:18 +0000 Subject: [issue15490] Correct __sizeof__ support for StringIO In-Reply-To: <1343591617.54.0.289047671129.issue15490@psf.upfronthosting.co.za> Message-ID: <1348210278.5.0.928772047086.issue15490@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Patches updated. Now the computations done in size_t. Note that the patches for the different versions differ. ---------- Added file: http://bugs.python.org/file27240/stringio_sizeof-3.3_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 08:51:51 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 21 Sep 2012 06:51:51 +0000 Subject: [issue15490] Correct __sizeof__ support for StringIO In-Reply-To: <1343591617.54.0.289047671129.issue15490@psf.upfronthosting.co.za> Message-ID: <1348210311.35.0.574063255525.issue15490@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file27241/stringio_sizeof-3.2_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 08:52:22 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 21 Sep 2012 06:52:22 +0000 Subject: [issue15490] Correct __sizeof__ support for StringIO In-Reply-To: <1343591617.54.0.289047671129.issue15490@psf.upfronthosting.co.za> Message-ID: <1348210342.61.0.0725785901704.issue15490@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file27242/stringio_sizeof-2.7_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 08:53:33 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 21 Sep 2012 06:53:33 +0000 Subject: [issue15997] NotImplemented needs to be documented In-Reply-To: <1348206637.53.0.485410334327.issue15997@psf.upfronthosting.co.za> Message-ID: <1348210413.32.0.360028374752.issue15997@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 09:07:42 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 21 Sep 2012 07:07:42 +0000 Subject: [issue15972] wrong error message for os.path.getsize In-Reply-To: <1348177415.05.0.535891661599.issue15972@psf.upfronthosting.co.za> Message-ID: <201209211007.28201.storchaka@gmail.com> Serhiy Storchaka added the comment: > But please add regression tests checking > that the error message is what we want. Immediately as soon as I find a suitable place for this test. Should be somewhere tests for bytes/unicode filenames. > I'd personally prefer the Oxford Comma there ("string, bytes, or integer"). > But I don't know if there is a style preference one way or the other in > Python error messages. "Invalid whence (%i, should be 0, 1 or 2)" "expect bytes or str of length 1, or int, " "argument should be bytes, buffer or ASCII string, " "coercing to str: need bytes, bytearray or buffer-like object, %.80s found" "character mapping must return integer, bytes or None, not %.400s" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 09:10:17 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 21 Sep 2012 07:10:17 +0000 Subject: [issue15972] wrong error message for os.path.getsize In-Reply-To: <1348071122.36.0.302681706423.issue15972@psf.upfronthosting.co.za> Message-ID: <1348211417.77.0.800496305778.issue15972@psf.upfronthosting.co.za> Larry Hastings added the comment: Ah! It seems Python is anti-Oxford Comma. Carry on! ;-) Wouldn't test_os be the natural place? I don't understand why you're having difficulty finding a suitable place. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 09:26:39 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 21 Sep 2012 07:26:39 +0000 Subject: [issue15996] pow() for complex numbers is rough around the edges In-Reply-To: <1348178428.15.0.517718755216.issue15996@psf.upfronthosting.co.za> Message-ID: <1348212399.12.0.596471353823.issue15996@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 09:57:40 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 21 Sep 2012 07:57:40 +0000 Subject: [issue15996] pow() for complex numbers is rough around the edges In-Reply-To: <1348178428.15.0.517718755216.issue15996@psf.upfronthosting.co.za> Message-ID: <1348214260.92.0.717304190766.issue15996@psf.upfronthosting.co.za> Mark Dickinson added the comment: Well, C99 covers pow for *real* numbers just fine; it's complex numbers where no-one wants to pin down what the behaviour should be. So I don't think we need the man page reference. If we're writing tests for complex pow, we might also want to consider adding tests for multiplication and division; those aren't entirely trivial either for special cases. I do agree that (for the most part), complex pow applied to arguments with zero imaginary part should behave like regular float pow. There are some cases where it's clear what the behaviour should be, and others that are murkier. E.g., for a positive real z and arbitrary complex w, the special cases for z**w should behave in the same way as for exp for z > 0, and with some reflection of that behaviour for 0 < z < 1; 1**w should always be 1. For nonzero finite values it's straightforward: we just want to compute the best approximation to exp(w * log(z)), with the branch cut for the log along the negative real axis as usual. But there are a *lot* of special cases to think about. Consider that each real or imaginary part of the input is either: (1) -infinity, (2) -finite, (3) -0.0 (4) +0.0 (5) +finite (6) +infinity (7) nan and that we've got 2 complex inputs, or in effect 4 real inputs. This divides our argument space into 7**4 = 2401 pieces. With luck we can find rules that cover lots of those pieces at once, but it's still going to be a long job. It doesn't help that it isn't particularly clear what the underlying mathematical model should be. For floats, we can think about the two-point compactification of the real line (okay, with a doubled zero, which messes things up a little bit), which is a fairly sane space to work in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 10:37:17 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 21 Sep 2012 08:37:17 +0000 Subject: [issue11715] Building Python on multiarch Debian and Ubuntu In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za> Message-ID: <1348216637.55.0.574471058283.issue11715@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- Removed message: http://bugs.python.org/msg169954 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 10:37:21 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 21 Sep 2012 08:37:21 +0000 Subject: [issue11715] Building Python on multiarch Debian and Ubuntu In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za> Message-ID: <1348216641.5.0.902684351492.issue11715@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- Removed message: http://bugs.python.org/msg169959 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 10:37:24 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 21 Sep 2012 08:37:24 +0000 Subject: [issue11715] Building Python on multiarch Debian and Ubuntu In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za> Message-ID: <1348216644.44.0.591433985288.issue11715@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- Removed message: http://bugs.python.org/msg169961 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 10:40:39 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 21 Sep 2012 08:40:39 +0000 Subject: [issue12067] Doc: remove errors about mixed-type comparisons. In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za> Message-ID: <1348216839.9.0.677562196966.issue12067@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 10:50:55 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 21 Sep 2012 08:50:55 +0000 Subject: [issue15972] wrong error message for os.path.getsize In-Reply-To: <1348211417.77.0.800496305778.issue15972@psf.upfronthosting.co.za> Message-ID: <201209211150.30277.storchaka@gmail.com> Serhiy Storchaka added the comment: Patch updated. Added tests. ---------- Added file: http://bugs.python.org/file27243/posix_path_converter_2.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 24136a775943 Lib/test/test_posix.py --- a/Lib/test/test_posix.py Thu Sep 20 23:49:33 2012 -0400 +++ b/Lib/test/test_posix.py Fri Sep 21 11:47:25 2012 +0300 @@ -358,12 +358,24 @@ try: self.assertTrue(posix.fstat(fp.fileno())) self.assertTrue(posix.stat(fp.fileno())) + + self.assertRaisesRegex(TypeError, 'should be string, bytes or integer, not', + posix.stat, float(fp.fileno())) finally: fp.close() def test_stat(self): if hasattr(posix, 'stat'): self.assertTrue(posix.stat(support.TESTFN)) + self.assertTrue(posix.stat(os.fsencode(support.TESTFN))) + self.assertTrue(posix.stat(bytearray(os.fsencode(support.TESTFN)))) + + self.assertRaisesRegex(TypeError, 'can\'t specify None for path argument', + posix.stat, None) + self.assertRaisesRegex(TypeError, 'should be string, bytes or integer, not', + posix.stat, list(support.TESTFN)) + self.assertRaisesRegex(TypeError, 'should be string, bytes or integer, not', + posix.stat, list(os.fsencode(support.TESTFN))) @unittest.skipUnless(hasattr(posix, 'mkfifo'), "don't have mkfifo()") def test_mkfifo(self): @@ -721,6 +733,13 @@ s1 = posix.stat(support.TESTFN) s2 = posix.stat(support.TESTFN, dir_fd=f) self.assertEqual(s1, s2) + s2 = posix.stat(support.TESTFN, dir_fd=None) + self.assertEqual(s1, s2) + self.assertRaisesRegex(TypeError, 'should be integer, not', + posix.stat, support.TESTFN, dir_fd=posix.getcwd()) + self.assertRaisesRegex(TypeError, 'should be integer, not', + posix.stat, support.TESTFN, dir_fd=float(f)) + self.assertRaises(OverflowError, posix.stat, support.TESTFN, dir_fd=10**20) finally: posix.close(f) diff -r 24136a775943 Modules/posixmodule.c --- a/Modules/posixmodule.c Thu Sep 20 23:49:33 2012 -0400 +++ b/Modules/posixmodule.c Fri Sep 21 11:47:25 2012 +0300 @@ -427,26 +427,24 @@ #endif static int -_fd_converter(PyObject *o, int *p, int default_value) { - long long_value; - if (o == Py_None) { - *p = default_value; - return 1; - } - if (PyFloat_Check(o)) { - PyErr_SetString(PyExc_TypeError, - "integer argument expected, got float" ); +_fd_converter(PyObject *o, int *p, const char *allowed) +{ + int overflow; + long long_value = PyLong_AsLongAndOverflow(o, &overflow); + if (PyFloat_Check(o) || + (long_value == -1 && !overflow && PyErr_Occurred())) { + PyErr_Clear(); + PyErr_Format(PyExc_TypeError, + "argument should be %s, not %.200s", + allowed, Py_TYPE(o)->tp_name); return 0; } - long_value = PyLong_AsLong(o); - if (long_value == -1 && PyErr_Occurred()) - return 0; - if (long_value > INT_MAX) { + if (overflow > 0 || long_value > INT_MAX) { PyErr_SetString(PyExc_OverflowError, "signed integer is greater than maximum"); return 0; } - if (long_value < INT_MIN) { + if (overflow < 0 || long_value < INT_MIN) { PyErr_SetString(PyExc_OverflowError, "signed integer is less than minimum"); return 0; @@ -456,8 +454,13 @@ } static int -dir_fd_converter(PyObject *o, void *p) { - return _fd_converter(o, (int *)p, DEFAULT_DIR_FD); +dir_fd_converter(PyObject *o, void *p) +{ + if (o == Py_None) { + *(int *)p = DEFAULT_DIR_FD; + return 1; + } + return _fd_converter(o, (int *)p, "integer"); } @@ -634,17 +637,16 @@ } else { PyErr_Clear(); - bytes = PyBytes_FromObject(o); + if (PyObject_CheckBuffer(o)) + bytes = PyBytes_FromObject(o); + else + bytes = NULL; if (!bytes) { PyErr_Clear(); if (path->allow_fd) { int fd; - /* - * note: _fd_converter always permits None. - * but we've already done our None check. - * so o cannot be None at this point. - */ - int result = _fd_converter(o, &fd, -1); + int result = _fd_converter(o, &fd, + "string, bytes or integer"); if (result) { path->wide = NULL; path->narrow = NULL; @@ -705,15 +707,17 @@ } static int -dir_fd_unavailable(PyObject *o, void *p) { - int *dir_fd = (int *)p; - int return_value = _fd_converter(o, dir_fd, DEFAULT_DIR_FD); - if (!return_value) +dir_fd_unavailable(PyObject *o, void *p) +{ + int dir_fd; + if (!dir_fd_converter(o, &dir_fd)) return 0; - if (*dir_fd == DEFAULT_DIR_FD) - return 1; - argument_unavailable_error(NULL, "dir_fd"); - return 0; + if (dir_fd != DEFAULT_DIR_FD) { + argument_unavailable_error(NULL, "dir_fd"); + return 0; + } + *(int *)p = dir_fd; + return 1; } static int From report at bugs.python.org Fri Sep 21 11:06:22 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 21 Sep 2012 09:06:22 +0000 Subject: [issue15845] Fixing some byte-to-string conversion warnings In-Reply-To: <1346552396.88.0.397419581961.issue15845@psf.upfronthosting.co.za> Message-ID: <1348218382.49.0.243261405456.issue15845@psf.upfronthosting.co.za> Ezio Melotti added the comment: - if basename == '': + if len(basename) == 0: This should be "if not basename:" - if tail == curdir: + cdir = curdir + if isinstance(tail, bytes): + cdir = bytes(curdir, 'ASCII') + if tail == cdir: This will raise an error if curdir is a non-ascii str, so, unless the same error was already raised later in the code, this is backward incompatible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 11:07:22 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 21 Sep 2012 09:07:22 +0000 Subject: [issue15826] Increased test coverage of test_glob.py In-Reply-To: <1346381534.69.0.636623200483.issue15826@psf.upfronthosting.co.za> Message-ID: <1348218442.71.0.321687566452.issue15826@psf.upfronthosting.co.za> Ezio Melotti added the comment: FTR this is addressed in #15845. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 11:07:56 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 21 Sep 2012 09:07:56 +0000 Subject: [issue15996] pow() for complex numbers is rough around the edges In-Reply-To: <1348214260.92.0.717304190766.issue15996@psf.upfronthosting.co.za> Message-ID: <201209211207.35531.storchaka@gmail.com> Serhiy Storchaka added the comment: > Well, C99 covers pow for *real* numbers just fine; it's complex numbers > where no-one wants to pin down what the behaviour should be. C99 contains cpow. Perhaps we should use conditional compilation? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 11:10:11 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 21 Sep 2012 09:10:11 +0000 Subject: [issue15852] typos in curses argument error messages In-Reply-To: <1346622102.83.0.795568790125.issue15852@psf.upfronthosting.co.za> Message-ID: <1348218611.02.0.0729769752518.issue15852@psf.upfronthosting.co.za> Ezio Melotti added the comment: Can't you use assertRaisesRegex? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 11:13:02 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 21 Sep 2012 09:13:02 +0000 Subject: [issue15844] weird import errors In-Reply-To: <1346547205.78.0.590339633235.issue15844@psf.upfronthosting.co.za> Message-ID: <1348218782.86.0.0501866580372.issue15844@psf.upfronthosting.co.za> Ezio Melotti added the comment: Closing for lack of reproducible test case. ---------- resolution: -> invalid stage: -> committed/rejected status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 11:27:29 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 21 Sep 2012 09:27:29 +0000 Subject: [issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails In-Reply-To: <1348173110.08.0.356112095586.issue15993@psf.upfronthosting.co.za> Message-ID: <1348219649.82.0.150692458128.issue15993@psf.upfronthosting.co.za> Stefan Krah added the comment: The high and low words of the 64-bit value are switched: >>> a = array.array('Q', [1]) >>> m = memoryview(a) >>> m[0]= 2**32+5 >>> m[0] 21474836481 >>> struct.unpack_from('8s', m, 0) (b'\x01\x00\x00\x00\x05\x00\x00\x00',) Can anyone reproduce this in a source build? I think this should be a blocker. ---------- priority: critical -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 11:30:10 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 21 Sep 2012 09:30:10 +0000 Subject: [issue15995] Windows: 3.3.0-rc2.msi: test_lzma fails In-Reply-To: <1348176881.28.0.847630849965.issue15995@psf.upfronthosting.co.za> Message-ID: <1348219810.37.0.425239934276.issue15995@psf.upfronthosting.co.za> Stefan Krah added the comment: This should be the same as #15993. Closing. ---------- resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> Windows: 3.3.0-rc2.msi: test_buffer fails _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 11:30:53 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 21 Sep 2012 09:30:53 +0000 Subject: [issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails In-Reply-To: <1348173110.08.0.356112095586.issue15993@psf.upfronthosting.co.za> Message-ID: <1348219853.77.0.375971356833.issue15993@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: +nadeem.vawda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 11:52:47 2012 From: report at bugs.python.org (Pierre Le Marre) Date: Fri, 21 Sep 2012 09:52:47 +0000 Subject: [issue15545] sqlite3.Connection.iterdump() does not work with row_factory = sqlite3.Row In-Reply-To: <1343981372.87.0.323193257201.issue15545@psf.upfronthosting.co.za> Message-ID: <1348221167.33.0.354374745722.issue15545@psf.upfronthosting.co.za> Pierre Le Marre added the comment: Thanks for the patch. In which version will be your patch integrated? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 12:08:51 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 21 Sep 2012 10:08:51 +0000 Subject: [issue15990] solidify argument/parameter terminology In-Reply-To: <1348169057.62.0.370171802379.issue15990@psf.upfronthosting.co.za> Message-ID: <1348222131.29.0.0592316798505.issue15990@psf.upfronthosting.co.za> Ezio Melotti added the comment: > "between arguments (what you pass, call syntax) and parameters > (what the function receives, function definition syntax)" Note that there's a subtle difference to make here. IMHO as soon as you use terms like "receives" or "accepts", you are still talking about arguments. What you pass from one side is received by the other, and it's called an argument. Given "def f(x, y): pass" you can say that x and y are parameter of the f function, or that the function accepts 2 arguments -- x and y. The latter is far more common IME, and I rarely talk about parameters myself. In "f() missing 1 required positional argument: 'x'", the usage of "argument" is correct, because what's missing is the argument in the function call, not the parameter in the function definition. However the error points to the corresponding parameter 'x' -- because clearly it can't point to the argument you forgot to pass -- and this fact might led to some confusion. IMHO though, the error is clear as is (at least regarding argument/parameter), so I wouldn't change it. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 12:30:30 2012 From: report at bugs.python.org (Sreenivas) Date: Fri, 21 Sep 2012 10:30:30 +0000 Subject: [issue15998] Python GUI idle not working Message-ID: <1348223430.53.0.95377552699.issue15998@psf.upfronthosting.co.za> New submission from Sreenivas: Hi Everybody, I have a problem where Python GUI IDLE is not working.I did go through the issues 15658,9925,4625.I did follow the steps given in these issues.I did unset the tcl and tk_library.I was able to open the python idle temporarily.But once i closed it I had to follow the same commands to open it again.instead of just clicking the application.I also tried this command --------- c:\>Python32\Lib\idlelib\idle.py This command gave the following error message "This probably means Tcl wasn#t properly installed" I tried to uninstall and reinstall and Python32 but still unsuccessful.I have installed few libs such as cx_Freeze and serial.I do not want to lose them as serial lib was itself painstaking process for installation.Can you tell me stepwise as to what should I do to get the IDLE working. regards, Sreeni ---------- components: IDLE messages: 170877 nosy: sreeni priority: normal severity: normal status: open title: Python GUI idle not working type: crash versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 12:46:32 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 21 Sep 2012 10:46:32 +0000 Subject: [issue15990] solidify argument/parameter terminology In-Reply-To: <1348169057.62.0.370171802379.issue15990@psf.upfronthosting.co.za> Message-ID: <1348224392.7.0.409975512166.issue15990@psf.upfronthosting.co.za> Mark Dickinson added the comment: Nick Coghlan pointed out that a lot of this discussion has already happened for the function signature object PEP [1]. That PEP defines constants Parameter.POSITIONAL_ONLY Parameter.POSITIONAL_OR_KEYWORD Parameter.KEYWORD_ONLY Parameter.VAR_POSITIONAL Parameter.VAR_KEYWORD So the 'positional' in the TypeError messages corresponds to POSITIONAL_OR_KEYWORD. [1] http://www.python.org/dev/peps/pep-0362/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 13:02:37 2012 From: report at bugs.python.org (Arne Babenhauserheide) Date: Fri, 21 Sep 2012 11:02:37 +0000 Subject: [issue14900] cProfile does not take its result headers as sort arguments In-Reply-To: <1337869163.57.0.920578910684.issue14900@psf.upfronthosting.co.za> Message-ID: <1348225357.23.0.361616874875.issue14900@psf.upfronthosting.co.za> Arne Babenhauserheide added the comment: Did you get to taking a look? Is there anything I should change? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 13:37:38 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 21 Sep 2012 11:37:38 +0000 Subject: [issue15997] NotImplemented needs to be documented In-Reply-To: <1348206637.53.0.485410334327.issue15997@psf.upfronthosting.co.za> Message-ID: <1348227458.62.0.400186725889.issue15997@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The main point is: it depends on the operation. NotImplemented is a way to signal that an operation is not implemented. It can be used for whatever you want to use it for. You can design to call an operation "foo", and, if NotImplemented is returned, call "bar" instead. If you want to know how a specific operation performs its fallback, you have to look in the documentation of the specific operation. As an example for a method where some other fallback is used, see http://docs.python.org/py3k/library/abc.html#abc.ABCMeta.__subclasshook__ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 14:04:56 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 21 Sep 2012 12:04:56 +0000 Subject: [issue11715] Building Python on multiarch Debian and Ubuntu In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za> Message-ID: <3XNYQZ1xYDzQph@mail.python.org> Roundup Robot added the comment: New changeset 53fa224b95f4 by doko in branch '2.7': - Issue #11715: Fix multiarch detection without having Debian development http://hg.python.org/cpython/rev/53fa224b95f4 New changeset 78aba41a8105 by doko in branch '3.2': - Issue #11715: Fix multiarch detection without having Debian development http://hg.python.org/cpython/rev/78aba41a8105 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 14:05:55 2012 From: report at bugs.python.org (Matthias Klose) Date: Fri, 21 Sep 2012 12:05:55 +0000 Subject: [issue11715] Building Python on multiarch Debian and Ubuntu In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za> Message-ID: <1348229155.15.0.456425717891.issue11715@psf.upfronthosting.co.za> Matthias Klose added the comment: fixed for 2.7 and 3.2 as well. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 14:42:10 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 21 Sep 2012 12:42:10 +0000 Subject: [issue15987] Provide a way to compare AST nodes for equality recursively In-Reply-To: <1348166637.22.0.281544835659.issue15987@psf.upfronthosting.co.za> Message-ID: <1348231330.22.0.751352225118.issue15987@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 14:56:18 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 21 Sep 2012 12:56:18 +0000 Subject: [issue15997] NotImplemented needs to be documented In-Reply-To: <1348206637.53.0.485410334327.issue15997@psf.upfronthosting.co.za> Message-ID: <1348232178.92.0.73919038017.issue15997@psf.upfronthosting.co.za> R. David Murray added the comment: The mention of NotImplemented in library/stdtypes cross references to the 'comparisions' section of the reference guide chapter on expressions. That might be a useful cross link in the datamodel section as well. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 15:26:18 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 21 Sep 2012 13:26:18 +0000 Subject: [issue15882] _decimal.Decimal constructed from tuple In-Reply-To: <1347058075.63.0.395926246222.issue15882@psf.upfronthosting.co.za> Message-ID: <1348233978.03.0.547102272773.issue15882@psf.upfronthosting.co.za> Stefan Krah added the comment: Georg, *if* there is an rc3, could you add 97e53273f423 to it? The commit is a backwards compatibility fix for constructing infinities from tuples with arbitrary coefficients. If there's no rc3, the issue can just be closed as fixed. ---------- assignee: skrah -> georg.brandl nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 15:31:48 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 21 Sep 2012 13:31:48 +0000 Subject: [issue15980] Non-escaped '\n' in docstrings In-Reply-To: <1348129592.37.0.740321783262.issue15980@psf.upfronthosting.co.za> Message-ID: <3XNbLp2yWSzQpy@mail.python.org> Roundup Robot added the comment: New changeset 7a125913a375 by Ezio Melotti in branch '2.7': #15980: properly escape newlines in docstrings. Patch by Serhiy Storchaka. http://hg.python.org/cpython/rev/7a125913a375 New changeset e582ad1aee62 by Ezio Melotti in branch '3.2': #15980: properly escape newlines in docstrings. Patch by Serhiy Storchaka. http://hg.python.org/cpython/rev/e582ad1aee62 New changeset 1830426da082 by Ezio Melotti in branch 'default': #15980: merge with 3.2. http://hg.python.org/cpython/rev/1830426da082 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 15:32:28 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 21 Sep 2012 13:32:28 +0000 Subject: [issue15980] Non-escaped '\n' in docstrings In-Reply-To: <1348129592.37.0.740321783262.issue15980@psf.upfronthosting.co.za> Message-ID: <1348234348.78.0.779334346544.issue15980@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! ---------- assignee: docs at python -> ezio.melotti resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 15:43:41 2012 From: report at bugs.python.org (Mike Hoy) Date: Fri, 21 Sep 2012 13:43:41 +0000 Subject: [issue12067] Doc: remove errors about mixed-type comparisons. In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za> Message-ID: <1348235021.68.0.490389889454.issue12067@psf.upfronthosting.co.za> Mike Hoy added the comment: http://bugs.python.org/issue15997 is this issue related to what Terry has mentioned: Does 'not supported' mean 'raises TypeError', 'returns NotImplemented', or both? If the last, I don't really understand the reason for NotImplemented versus TypeError. That point should be clarified in 3.3 also. And 3.3 should be referenced in the comparisons section. I am working on this patch and need confirmation as to whether or not this has to be included in my patch. I'm not clear on it so I may just pass on making a patch if it is required for this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 15:53:30 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 21 Sep 2012 13:53:30 +0000 Subject: [issue15304] Wrong path in test.support.temp_cwd() error message In-Reply-To: <1341833239.95.0.652006223487.issue15304@psf.upfronthosting.co.za> Message-ID: <3XNbqs47KXzRQB@mail.python.org> Roundup Robot added the comment: New changeset 0b60dcabf7e6 by Ezio Melotti in branch '3.2': #15304: fix wrong warning message in test.support.temp_cwd(). http://hg.python.org/cpython/rev/0b60dcabf7e6 New changeset b1d6daface10 by Ezio Melotti in branch 'default': #15304: merge with 3.2. http://hg.python.org/cpython/rev/b1d6daface10 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 15:54:12 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 21 Sep 2012 13:54:12 +0000 Subject: [issue15304] Wrong path in test.support.temp_cwd() error message In-Reply-To: <1341833239.95.0.652006223487.issue15304@psf.upfronthosting.co.za> Message-ID: <1348235652.14.0.239885168515.issue15304@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 16:03:47 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 21 Sep 2012 14:03:47 +0000 Subject: [issue15998] Python GUI idle not working In-Reply-To: <1348223430.53.0.95377552699.issue15998@psf.upfronthosting.co.za> Message-ID: <1348236227.21.0.346988495171.issue15998@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ned.deily, serwy, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 16:08:13 2012 From: report at bugs.python.org (John Taylor) Date: Fri, 21 Sep 2012 14:08:13 +0000 Subject: [issue15972] wrong error message for os.path.getsize In-Reply-To: <1348071122.36.0.302681706423.issue15972@psf.upfronthosting.co.za> Message-ID: <1348236493.28.0.285464690762.issue15972@psf.upfronthosting.co.za> John Taylor added the comment: OP here. These error messages are much better. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 16:09:00 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 21 Sep 2012 14:09:00 +0000 Subject: [issue15996] pow() for complex numbers is rough around the edges In-Reply-To: <1348178428.15.0.517718755216.issue15996@psf.upfronthosting.co.za> Message-ID: <1348236540.37.0.217186258932.issue15996@psf.upfronthosting.co.za> Mark Dickinson added the comment: > C99 contains cpow. Perhaps we should use conditional compilation? I dread to think what horrors lurk in OS math library implementations of cpow; I suspect we'd soon find out, if we had used cpow and have any tests at all for special cases. OS math libraries are bad enough at *float* math, let alone complex; I'd rather not depend on them unless we have to. And given that at least on Windows we need our own complex pow implementation anyway, I'd prefer to use the same code on all platforms, so that we have at least some degree of consistency from platform to platform. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 16:29:40 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 21 Sep 2012 14:29:40 +0000 Subject: [issue15421] Calendar.itermonthdates OverflowError In-Reply-To: <1342967144.9.0.843108675207.issue15421@psf.upfronthosting.co.za> Message-ID: <3XNcdb61jvzQmw@mail.python.org> Roundup Robot added the comment: New changeset bfdf366a779a by Ezio Melotti in branch '2.7': #15421: fix an OverflowError in Calendar.itermonthdates() after datetime.MAXYEAR. Patch by C?dric Krier. http://hg.python.org/cpython/rev/bfdf366a779a New changeset aa73e60f65e9 by Ezio Melotti in branch '3.2': #15421: fix an OverflowError in Calendar.itermonthdates() after datetime.MAXYEAR. Patch by C?dric Krier. http://hg.python.org/cpython/rev/aa73e60f65e9 New changeset 59a2807872d5 by Ezio Melotti in branch 'default': #15421: merge with 3.2. http://hg.python.org/cpython/rev/59a2807872d5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 16:30:56 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 21 Sep 2012 14:30:56 +0000 Subject: [issue15421] Calendar.itermonthdates OverflowError In-Reply-To: <1342967144.9.0.843108675207.issue15421@psf.upfronthosting.co.za> Message-ID: <1348237856.75.0.374382541544.issue15421@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch and the report! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 16:39:32 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 21 Sep 2012 14:39:32 +0000 Subject: [issue15983] multiprocessing JoinableQueue's join function with timeout In-Reply-To: <1348147792.78.0.126354805475.issue15983@psf.upfronthosting.co.za> Message-ID: <1348238372.4.0.472683551571.issue15983@psf.upfronthosting.co.za> Richard Oudkerk added the comment: I notice that queue.Queue.join() does not have a timeout parameter either. Have you hit a particular problem that would be substantially easier with the patch? ---------- versions: -Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 17:11:15 2012 From: report at bugs.python.org (Karl Bicker) Date: Fri, 21 Sep 2012 15:11:15 +0000 Subject: [issue15983] multiprocessing JoinableQueue's join function with timeout In-Reply-To: <1348147792.78.0.126354805475.issue15983@psf.upfronthosting.co.za> Message-ID: <1348240275.41.0.63549741896.issue15983@psf.upfronthosting.co.za> Karl Bicker added the comment: Actually, I would like to check if the threads working on the queue are still alive. However, it occurs to me now that I would need a facility to distinguish between a timeout and an actual join. Unfortunately, my original patch does not provide this, one would have to implement an additional check and think about the correct way to signal a timeout. Also, there seem to be other people looking for this feature: http://stackoverflow.com/questions/1564501/add-timeout-argument-to-pythons-queue-join ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 17:16:35 2012 From: report at bugs.python.org (Roger Serwy) Date: Fri, 21 Sep 2012 15:16:35 +0000 Subject: [issue15998] Python GUI idle not working In-Reply-To: <1348223430.53.0.95377552699.issue15998@psf.upfronthosting.co.za> Message-ID: <1348240595.4.0.396316939287.issue15998@psf.upfronthosting.co.za> Roger Serwy added the comment: Hi Sreeni, Can you launch a Python interpreter from C:\python32\python.exe and report the output to "import tkinter" ? ---------- status: open -> pending type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 17:47:10 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 21 Sep 2012 15:47:10 +0000 Subject: [issue15999] Using new 'bool' format character Message-ID: <1348242429.94.0.662282558141.issue15999@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Issue14705 added 'bool' format character to PyArg_ParseTuple for using it for parsing multiple boolean arguments in os module. The proposed patch uses this format character for other boolean arguments. This makes the sources simpler, clearer and more reliable, improves error messages, gets rid of a few rare errors. ---------- components: Extension Modules, Interpreter Core files: use_bool_parsing.diff keywords: patch messages: 170897 nosy: larry, storchaka priority: normal severity: normal status: open title: Using new 'bool' format character type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file27244/use_bool_parsing.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 17:59:36 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 21 Sep 2012 15:59:36 +0000 Subject: [issue15999] Using new 'bool' format character In-Reply-To: <1348242429.94.0.662282558141.issue15999@psf.upfronthosting.co.za> Message-ID: <1348243176.36.0.449300151224.issue15999@psf.upfronthosting.co.za> Larry Hastings added the comment: Patch looks fine in principle, though I'd want someone to go over the individual cases to make sure they make sense. Also, I have something up my sleeve regarding argument parsing for 3.4, and if it gets accepted we might be touching all this code anyway. I mention this just to say--you may want to hold off on more patches like this for now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 18:20:09 2012 From: report at bugs.python.org (Drekin) Date: Fri, 21 Sep 2012 16:20:09 +0000 Subject: [issue1602] windows console doesn't print or input Unicode In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za> Message-ID: <1348244409.32.0.55063490164.issue1602@psf.upfronthosting.co.za> Drekin added the comment: Hello, I'm trying to handle Unicode input and output in Windows console and found this issue. Will this be solved in 3.3 final? I tried to write a solution (file attached) based on solution here ? rewriting sys.stdin and sys.stdout so it uses ReadConsoleW and WriteConsoleW. Output works well, but there are few problems with input. First, the Python interactive interpreter actually doesn't use sys.stdin but standard C stdin. It's implemented over file pointer (PyRun_InteractiveLoopFlags, PyRun_InteractiveOneFlags in pythonrun). But still the interpreter uses sys.stdin.encoding (assigning sys.stdin something, that doesn't have encoding==None freezes the interpreter). Wouldn't it make more sense if it used sys.__stdin__.encoding? However, input() (which uses stdin.readline) works as expected. There's a small problem with KeyboardInterrupt. Since signals are processed asynchronously, it's raised at random place and it behaves wierdly. time.sleep(0.01) after the C call works well, but it's an ugly solution. When code.interact() is used instead of standard interpreter, it works as expected. Is there a way of changing the intepreter loop? Some hook which calls code.interact() at the right place? The patch can be applied in site or sitecustomized, but calling code.iteract() there obviously doesn't work. Some other remarks: - When sys.stdin or sys.stdout doesn't define encoding and errors, input() raises TypeError: bad argument type for built-in operation. - input() raises KeyboardInterrupt on Ctrl-C in Python 3.2 but not in Python 3.3rc2. ---------- nosy: +Drekin Added file: http://bugs.python.org/file27245/win_unicode_console.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 18:32:59 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 21 Sep 2012 16:32:59 +0000 Subject: [issue15852] typos in curses argument error messages In-Reply-To: <1346622102.83.0.795568790125.issue15852@psf.upfronthosting.co.za> Message-ID: <1348245179.87.0.40138508088.issue15852@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks for taking a look at this, and good question. Without restructuring how the tests are done, I believe the short answer is no. The funny thing about this test module is that it does not actually have any unittest test cases. It just calls some functions. Failure happens if an exception is raised in any one of those functions. See here, for example: http://hg.python.org/cpython/file/59a2807872d5/Lib/test/test_curses.py#l35 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 18:38:29 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 21 Sep 2012 16:38:29 +0000 Subject: [issue15304] Wrong path in test.support.temp_cwd() error message In-Reply-To: <1341833239.95.0.652006223487.issue15304@psf.upfronthosting.co.za> Message-ID: <1348245509.8.0.190230159587.issue15304@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks, Ezio! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 18:38:45 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 21 Sep 2012 16:38:45 +0000 Subject: [issue15972] wrong error message for os.path.getsize In-Reply-To: <1348071122.36.0.302681706423.issue15972@psf.upfronthosting.co.za> Message-ID: <1348245525.91.0.531417652928.issue15972@psf.upfronthosting.co.za> Larry Hastings added the comment: Patch looks fine, except please fix 80 columns. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 18:53:45 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 21 Sep 2012 16:53:45 +0000 Subject: [issue15989] Possible integer overflow of PyLong_AsLong() results In-Reply-To: <1348174160.31.0.541120761381.issue15989@psf.upfronthosting.co.za> Message-ID: <201209211953.16838.storchaka@gmail.com> Serhiy Storchaka added the comment: Here is a patch (for 3.3). I added private _PyLong_AsInt and where possible I have tried to use the appropriate function. ---------- keywords: +patch Added file: http://bugs.python.org/file27246/long_aslong_overflow.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 59a2807872d5 Include/longobject.h --- a/Include/longobject.h Fri Sep 21 17:29:20 2012 +0300 +++ b/Include/longobject.h Fri Sep 21 19:21:25 2012 +0300 @@ -26,6 +26,9 @@ PyAPI_FUNC(size_t) PyLong_AsSize_t(PyObject *); PyAPI_FUNC(unsigned long) PyLong_AsUnsignedLong(PyObject *); PyAPI_FUNC(unsigned long) PyLong_AsUnsignedLongMask(PyObject *); +#ifndef Py_LIMITED_API +PyAPI_FUNC(int) _PyLong_AsInt(PyObject *); +#endif PyAPI_FUNC(PyObject *) PyLong_GetInfo(void); /* It may be useful in the future. I've added it in the PyInt -> PyLong diff -r 59a2807872d5 Modules/_ctypes/stgdict.c --- a/Modules/_ctypes/stgdict.c Fri Sep 21 17:29:20 2012 +0300 +++ b/Modules/_ctypes/stgdict.c Fri Sep 21 19:21:25 2012 +0300 @@ -335,7 +335,7 @@ isPacked = PyObject_GetAttrString(type, "_pack_"); if (isPacked) { - pack = PyLong_AsLong(isPacked); + pack = _PyLong_AsInt(isPacked); if (pack < 0 || PyErr_Occurred()) { Py_XDECREF(isPacked); PyErr_SetString(PyExc_ValueError, diff -r 59a2807872d5 Modules/_datetimemodule.c --- a/Modules/_datetimemodule.c Fri Sep 21 17:29:20 2012 +0300 +++ b/Modules/_datetimemodule.c Fri Sep 21 19:21:25 2012 +0300 @@ -4717,7 +4717,7 @@ if (seconds == NULL) goto error; Py_DECREF(delta); - timestamp = PyLong_AsLong(seconds); + timestamp = _PyLong_AsTime_t(seconds); Py_DECREF(seconds); if (timestamp == -1 && PyErr_Occurred()) return NULL; diff -r 59a2807872d5 Modules/_io/_iomodule.c --- a/Modules/_io/_iomodule.c Fri Sep 21 17:29:20 2012 +0300 +++ b/Modules/_io/_iomodule.c Fri Sep 21 19:21:25 2012 +0300 @@ -358,9 +358,9 @@ PyObject *res = _PyObject_CallMethodId(raw, &PyId_isatty, NULL); if (res == NULL) goto error; - isatty = PyLong_AsLong(res); + isatty = PyObject_IsTrue(res); Py_DECREF(res); - if (isatty == -1 && PyErr_Occurred()) + if (isatty < 0) goto error; } @@ -376,12 +376,12 @@ #ifdef HAVE_STRUCT_STAT_ST_BLKSIZE { struct stat st; - long fileno; + int fileno; PyObject *res = _PyObject_CallMethodId(raw, &PyId_fileno, NULL); if (res == NULL) goto error; - fileno = PyLong_AsLong(res); + fileno = _PyLong_AsInt(res); Py_DECREF(res); if (fileno == -1 && PyErr_Occurred()) goto error; diff -r 59a2807872d5 Modules/_io/fileio.c --- a/Modules/_io/fileio.c Fri Sep 21 17:29:20 2012 +0300 +++ b/Modules/_io/fileio.c Fri Sep 21 19:21:25 2012 +0300 @@ -244,7 +244,7 @@ return -1; } - fd = PyLong_AsLong(nameobj); + fd = _PyLong_AsInt(nameobj); if (fd < 0) { if (!PyErr_Occurred()) { PyErr_SetString(PyExc_ValueError, @@ -382,7 +382,7 @@ goto error; } - self->fd = PyLong_AsLong(fdobj); + self->fd = _PyLong_AsInt(fdobj); Py_DECREF(fdobj); if (self->fd == -1) { goto error; diff -r 59a2807872d5 Modules/_io/textio.c --- a/Modules/_io/textio.c Fri Sep 21 17:29:20 2012 +0300 +++ b/Modules/_io/textio.c Fri Sep 21 19:21:25 2012 +0300 @@ -881,7 +881,7 @@ } } else { - int fd = (int) PyLong_AsLong(fileno); + int fd = _PyLong_AsInt(fileno); Py_DECREF(fileno); if (fd == -1 && PyErr_Occurred()) { goto error; diff -r 59a2807872d5 Modules/_sqlite/connection.c --- a/Modules/_sqlite/connection.c Fri Sep 21 17:29:20 2012 +0300 +++ b/Modules/_sqlite/connection.c Fri Sep 21 19:21:25 2012 +0300 @@ -859,7 +859,7 @@ rc = SQLITE_DENY; } else { if (PyLong_Check(ret)) { - rc = (int)PyLong_AsLong(ret); + rc = _PyLong_AsInt(ret); } else { rc = SQLITE_DENY; } @@ -1350,7 +1350,7 @@ goto finally; } - result = PyLong_AsLong(retval); + result = _PyLong_AsInt(retval); if (PyErr_Occurred()) { result = 0; } diff -r 59a2807872d5 Modules/grpmodule.c --- a/Modules/grpmodule.c Fri Sep 21 17:29:20 2012 +0300 +++ b/Modules/grpmodule.c Fri Sep 21 19:21:25 2012 +0300 @@ -85,16 +85,23 @@ grp_getgrgid(PyObject *self, PyObject *pyo_id) { PyObject *py_int_id; - unsigned int gid; + unsigned long gid; struct group *p; py_int_id = PyNumber_Long(pyo_id); if (!py_int_id) return NULL; - gid = PyLong_AS_LONG(py_int_id); + gid = PyLong_AsUnsignedLong(py_int_id); Py_DECREF(py_int_id); + if (gid == (unsigned long)-1 && PyErr_Occurred()) + return NULL; + if ((unsigned long)(gid_t)gid != gid) { + PyErr_SetString(PyExc_OverflowError, + "Python int too large to convert to gid_t"); + return NULL; + } - if ((p = getgrgid(gid)) == NULL) { + if ((p = getgrgid((gid_t)gid)) == NULL) { PyErr_Format(PyExc_KeyError, "getgrgid(): gid not found: %d", gid); return NULL; } diff -r 59a2807872d5 Modules/parsermodule.c --- a/Modules/parsermodule.c Fri Sep 21 17:29:20 2012 +0300 +++ b/Modules/parsermodule.c Fri Sep 21 19:21:25 2012 +0300 @@ -725,7 +725,7 @@ /* elem must always be a sequence, however simple */ PyObject* elem = PySequence_GetItem(tuple, i); int ok = elem != NULL; - long type = 0; + int type = 0; char *strn = 0; if (ok) @@ -736,8 +736,14 @@ ok = 0; else { ok = PyLong_Check(temp); - if (ok) - type = PyLong_AS_LONG(temp); + if (ok) { + type = _PyLong_AsInt(temp); + if (type == -1 && PyErr_Occurred()) { + Py_DECREF(temp); + Py_DECREF(elem); + return 0; + } + } Py_DECREF(temp); } } @@ -773,8 +779,16 @@ if (len == 3) { PyObject *o = PySequence_GetItem(elem, 2); if (o != NULL) { - if (PyLong_Check(o)) - *line_num = PyLong_AS_LONG(o); + if (PyLong_Check(o)) { + int num = _PyLong_AsInt(o); + if (num == -1 && PyErr_Occurred()) { + Py_DECREF(o); + Py_DECREF(temp); + Py_DECREF(elem); + return 0; + } + *line_num = num; + } else { PyErr_Format(parser_error, "third item in terminal node must be an" diff -r 59a2807872d5 Modules/posixmodule.c --- a/Modules/posixmodule.c Fri Sep 21 17:29:20 2012 +0300 +++ b/Modules/posixmodule.c Fri Sep 21 19:21:25 2012 +0300 @@ -8170,7 +8170,7 @@ int fds[2]; int res; - flags = PyLong_AsLong(arg); + flags = _PyLong_AsInt(arg); if (flags == -1 && PyErr_Occurred()) return NULL; @@ -9016,7 +9016,7 @@ */ struct constdef { char *name; - long value; + int value; }; static int @@ -9024,7 +9024,10 @@ size_t tablesize) { if (PyLong_Check(arg)) { - *valuep = PyLong_AS_LONG(arg); + int value = _PyLong_AsInt(arg); + if (value == -1 && PyErr_Occurred()) + return 0; + *valuep = value; return 1; } else { diff -r 59a2807872d5 Modules/pyexpat.c --- a/Modules/pyexpat.c Fri Sep 21 17:29:20 2012 +0300 +++ b/Modules/pyexpat.c Fri Sep 21 19:21:25 2012 +0300 @@ -1447,13 +1447,13 @@ } if (PyUnicode_CompareWithASCIIString(name, "buffer_size") == 0) { - long new_buffer_size; + int new_buffer_size; if (!PyLong_Check(v)) { PyErr_SetString(PyExc_TypeError, "buffer_size must be an integer"); return -1; } - new_buffer_size=PyLong_AS_LONG(v); + new_buffer_size = _PyLong_AsInt(v); /* trivial case -- no change */ if (new_buffer_size == self->buffer_size) { return 0; @@ -1464,14 +1464,6 @@ return -1; } - /* check maximum */ - if (new_buffer_size > INT_MAX) { - char errmsg[100]; - sprintf(errmsg, "buffer_size must not be greater than %i", INT_MAX); - PyErr_SetString(PyExc_ValueError, errmsg); - return -1; - } - if (self->buffer != NULL) { /* there is already a buffer */ if (self->buffer_used != 0) { diff -r 59a2807872d5 Modules/readline.c --- a/Modules/readline.c Fri Sep 21 17:29:20 2012 +0300 +++ b/Modules/readline.c Fri Sep 21 19:21:25 2012 +0300 @@ -741,7 +741,7 @@ if (r == Py_None) result = 0; else { - result = PyLong_AsLong(r); + result = _PyLong_AsInt(r); if (result == -1 && PyErr_Occurred()) goto error; } diff -r 59a2807872d5 Modules/selectmodule.c --- a/Modules/selectmodule.c Fri Sep 21 17:29:20 2012 +0300 +++ b/Modules/selectmodule.c Fri Sep 21 19:21:25 2012 +0300 @@ -359,10 +359,13 @@ i = pos = 0; while (PyDict_Next(self->dict, &pos, &key, &value)) { - self->ufds[i].fd = PyLong_AsLong(key); + assert(i < self->ufd_len); + /* Never overflow */ + self->ufds[i].fd = (int)PyLong_AsLong(key); self->ufds[i].events = (short)PyLong_AsLong(value); i++; } + assert(i == self->ufd_len); self->ufd_uptodate = 1; return 1; } @@ -378,10 +381,11 @@ poll_register(pollObject *self, PyObject *args) { PyObject *o, *key, *value; - int fd, events = POLLIN | POLLPRI | POLLOUT; + int fd; + short events = POLLIN | POLLPRI | POLLOUT; int err; - if (!PyArg_ParseTuple(args, "O|i:register", &o, &events)) { + if (!PyArg_ParseTuple(args, "O|h:register", &o, &events)) { return NULL; } @@ -520,7 +524,7 @@ tout = PyNumber_Long(tout); if (!tout) return NULL; - timeout = PyLong_AsLong(tout); + timeout = _PyLong_AsInt(tout); Py_DECREF(tout); if (timeout == -1 && PyErr_Occurred()) return NULL; @@ -804,7 +808,7 @@ struct dvpoll dvp; PyObject *result_list = NULL, *tout = NULL; int poll_result, i; - long timeout; + int timeout; PyObject *value, *num1, *num2; if (!PyArg_UnpackTuple(args, "poll", 0, 1, &tout)) { @@ -823,16 +827,15 @@ tout = PyNumber_Long(tout); if (!tout) return NULL; - timeout = PyLong_AsLong(tout); + timeout = _PyLong_AsInt(tout); Py_DECREF(tout); if (timeout == -1 && PyErr_Occurred()) return NULL; - } - - if ((timeout < -1) || (timeout > INT_MAX)) { - PyErr_SetString(PyExc_OverflowError, + if (timeout < -1) { + PyErr_SetString(PyExc_OverflowError, "timeout is out of range"); - return NULL; + return NULL; + } } if (devpoll_flush(self)) diff -r 59a2807872d5 Modules/socketmodule.c --- a/Modules/socketmodule.c Fri Sep 21 17:29:20 2012 +0300 +++ b/Modules/socketmodule.c Fri Sep 21 19:21:25 2012 +0300 @@ -2075,8 +2075,8 @@ { int block; - block = PyLong_AsLong(arg); - if (block == -1 && PyErr_Occurred()) + block = PyObject_IsTrue(arg); + if (block < 0) return NULL; s->sock_timeout = block ? -1.0 : 0.0; @@ -2555,7 +2555,7 @@ int backlog; int res; - backlog = PyLong_AsLong(arg); + backlog = _PyLong_AsInt(arg); if (backlog == -1 && PyErr_Occurred()) return NULL; Py_BEGIN_ALLOW_THREADS @@ -3712,7 +3712,7 @@ int how; int res; - how = PyLong_AsLong(arg); + how = _PyLong_AsInt(arg); if (how == -1 && PyErr_Occurred()) return NULL; Py_BEGIN_ALLOW_THREADS diff -r 59a2807872d5 Objects/fileobject.c --- a/Objects/fileobject.c Fri Sep 21 17:29:20 2012 +0300 +++ b/Objects/fileobject.c Fri Sep 21 19:21:25 2012 +0300 @@ -200,7 +200,7 @@ _Py_IDENTIFIER(fileno); if (PyLong_Check(o)) { - fd = PyLong_AsLong(o); + fd = _PyLong_AsInt(o); } else if ((meth = _PyObject_GetAttrId(o, &PyId_fileno)) != NULL) { @@ -210,7 +210,7 @@ return -1; if (PyLong_Check(fno)) { - fd = PyLong_AsLong(fno); + fd = _PyLong_AsInt(fno); Py_DECREF(fno); } else { diff -r 59a2807872d5 Objects/longobject.c --- a/Objects/longobject.c Fri Sep 21 17:29:20 2012 +0300 +++ b/Objects/longobject.c Fri Sep 21 19:21:25 2012 +0300 @@ -434,6 +434,23 @@ return result; } +/* Get a C int from a long int object or any object that has an __int__ + method. Return -1 and set an error if overflow occurs. */ + +int +_PyLong_AsInt(PyObject *obj) +{ + int overflow; + long result = PyLong_AsLongAndOverflow(obj, &overflow); + if (overflow || result > INT_MAX || result < INT_MIN) { + /* XXX: could be cute and give a different + message for overflow == -1 */ + PyErr_SetString(PyExc_OverflowError, + "Python int too large to convert to C int"); + } + return (int)result; +} + /* Get a Py_ssize_t from a long int object. Returns -1 and sets an error condition if overflow occurs. */ diff -r 59a2807872d5 Objects/structseq.c --- a/Objects/structseq.c Fri Sep 21 17:29:20 2012 +0300 +++ b/Objects/structseq.c Fri Sep 21 19:21:25 2012 +0300 @@ -13,14 +13,14 @@ char *PyStructSequence_UnnamedField = "unnamed field"; #define VISIBLE_SIZE(op) Py_SIZE(op) -#define VISIBLE_SIZE_TP(tp) PyLong_AsLong( \ +#define VISIBLE_SIZE_TP(tp) PyLong_AsSsize_t( \ PyDict_GetItemString((tp)->tp_dict, visible_length_key)) -#define REAL_SIZE_TP(tp) PyLong_AsLong( \ +#define REAL_SIZE_TP(tp) PyLong_AsSsize_t( \ PyDict_GetItemString((tp)->tp_dict, real_length_key)) #define REAL_SIZE(op) REAL_SIZE_TP(Py_TYPE(op)) -#define UNNAMED_FIELDS_TP(tp) PyLong_AsLong( \ +#define UNNAMED_FIELDS_TP(tp) PyLong_AsSsize_t( \ PyDict_GetItemString((tp)->tp_dict, unnamed_fields_key)) #define UNNAMED_FIELDS(op) UNNAMED_FIELDS_TP(Py_TYPE(op)) @@ -161,7 +161,8 @@ #define TYPE_MAXSIZE 100 PyTypeObject *typ = Py_TYPE(obj); - int i, removelast = 0; + Py_ssize_t i; + int removelast = 0; Py_ssize_t len; char buf[REPR_BUFFER_SIZE]; char *endofbuf, *pbuf = buf; @@ -233,8 +234,7 @@ PyObject* tup; PyObject* dict; PyObject* result; - Py_ssize_t n_fields, n_visible_fields, n_unnamed_fields; - int i; + Py_ssize_t n_fields, n_visible_fields, n_unnamed_fields, i; n_fields = REAL_SIZE(self); n_visible_fields = VISIBLE_SIZE(self); @@ -320,7 +320,7 @@ { PyObject *dict; PyMemberDef* members; - int n_members, n_unnamed_members, i, k; + Py_ssize_t n_members, n_unnamed_members, i, k; #ifdef Py_TRACE_REFS /* if the type object was chained, unchain it first @@ -365,18 +365,18 @@ Py_INCREF(type); dict = type->tp_dict; -#define SET_DICT_FROM_INT(key, value) \ +#define SET_DICT_FROM_SIZE(key, value) \ do { \ - PyObject *v = PyLong_FromLong((long) value); \ + PyObject *v = PyLong_FromSsize_t(value); \ if (v != NULL) { \ PyDict_SetItemString(dict, key, v); \ Py_DECREF(v); \ } \ } while (0) - SET_DICT_FROM_INT(visible_length_key, desc->n_in_sequence); - SET_DICT_FROM_INT(real_length_key, n_members); - SET_DICT_FROM_INT(unnamed_fields_key, n_unnamed_members); + SET_DICT_FROM_SIZE(visible_length_key, desc->n_in_sequence); + SET_DICT_FROM_SIZE(real_length_key, n_members); + SET_DICT_FROM_SIZE(unnamed_fields_key, n_unnamed_members); } PyTypeObject* diff -r 59a2807872d5 Objects/unicodeobject.c --- a/Objects/unicodeobject.c Fri Sep 21 17:29:20 2012 +0300 +++ b/Objects/unicodeobject.c Fri Sep 21 19:21:25 2012 +0300 @@ -13567,7 +13567,7 @@ "* wants int"); goto onError; } - width = PyLong_AsLong(v); + width = PyLong_AsSsize_t(v); if (width == -1 && PyErr_Occurred()) goto onError; if (width < 0) { @@ -13607,7 +13607,7 @@ "* wants int"); goto onError; } - prec = PyLong_AsLong(v); + prec = _PyLong_AsInt(v); if (prec == -1 && PyErr_Occurred()) goto onError; if (prec < 0) diff -r 59a2807872d5 Python/Python-ast.c --- a/Python/Python-ast.c Fri Sep 21 17:29:20 2012 +0300 +++ b/Python/Python-ast.c Fri Sep 21 19:21:25 2012 +0300 @@ -730,7 +730,7 @@ return 1; } - i = (int)PyLong_AsLong(obj); + i = _PyLong_AsInt(obj); if (i == -1 && PyErr_Occurred()) return 1; *out = i; diff -r 59a2807872d5 Python/compile.c --- a/Python/compile.c Fri Sep 21 17:29:20 2012 +0300 +++ b/Python/compile.c Fri Sep 21 19:21:25 2012 +0300 @@ -426,6 +426,7 @@ v = PyDict_GetItem(src, k); assert(PyLong_Check(v)); vi = PyLong_AS_LONG(v); + assert(!PyErr_Occurred()); scope = (vi >> SCOPE_OFFSET) & SCOPE_MASK; if (scope == scope_type || vi & flag) { @@ -1065,7 +1066,7 @@ Py_DECREF(v); } else - arg = PyLong_AsLong(v); + arg = PyLong_AsSsize_t(v); Py_DECREF(t); return arg; } diff -r 59a2807872d5 Python/pythonrun.c --- a/Python/pythonrun.c Fri Sep 21 17:29:20 2012 +0300 +++ b/Python/pythonrun.c Fri Sep 21 19:21:25 2012 +0300 @@ -1478,7 +1478,7 @@ parse_syntax_error(PyObject *err, PyObject **message, const char **filename, int *lineno, int *offset, const char **text) { - long hold; + int hold; PyObject *v; _Py_IDENTIFIER(msg); _Py_IDENTIFIER(filename); @@ -1510,11 +1510,11 @@ v = _PyObject_GetAttrId(err, &PyId_lineno); if (!v) goto finally; - hold = PyLong_AsLong(v); + hold = _PyLong_AsInt(v); Py_DECREF(v); if (hold < 0 && PyErr_Occurred()) goto finally; - *lineno = (int)hold; + *lineno = hold; v = _PyObject_GetAttrId(err, &PyId_offset); if (!v) @@ -1523,11 +1523,11 @@ *offset = -1; Py_DECREF(v); } else { - hold = PyLong_AsLong(v); + hold = _PyLong_AsInt(v); Py_DECREF(v); if (hold < 0 && PyErr_Occurred()) goto finally; - *offset = (int)hold; + *offset = hold; } v = _PyObject_GetAttrId(err, &PyId_text); @@ -1616,7 +1616,7 @@ just let the else clause below print the error. */ } if (PyLong_Check(value)) - exitcode = (int)PyLong_AsLong(value); + exitcode = _PyLong_AsInt(value); else { PyObject *sys_stderr = PySys_GetObject("stderr"); if (sys_stderr != NULL && sys_stderr != Py_None) { From report at bugs.python.org Fri Sep 21 18:59:26 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 21 Sep 2012 16:59:26 +0000 Subject: [issue15989] Possible integer overflow of PyLong_AsLong() results In-Reply-To: <1348167705.87.0.588220983695.issue15989@psf.upfronthosting.co.za> Message-ID: <1348246766.56.0.302381129513.issue15989@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I was assigned this to itself to show that I working on the issue. Now I free up place for someone with committing privileges. ---------- assignee: storchaka -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 19:08:41 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 21 Sep 2012 17:08:41 +0000 Subject: [issue15972] wrong error message for os.path.getsize In-Reply-To: <1348245525.91.0.531417652928.issue15972@psf.upfronthosting.co.za> Message-ID: <201209212008.21437.storchaka@gmail.com> Serhiy Storchaka added the comment: > Patch looks fine, except please fix 80 columns. Patch updated. Long lines in tests fixed. ---------- Added file: http://bugs.python.org/file27247/posix_path_converter_3.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 59a2807872d5 Lib/test/test_posix.py --- a/Lib/test/test_posix.py Fri Sep 21 17:29:20 2012 +0300 +++ b/Lib/test/test_posix.py Fri Sep 21 20:07:09 2012 +0300 @@ -358,12 +358,28 @@ try: self.assertTrue(posix.fstat(fp.fileno())) self.assertTrue(posix.stat(fp.fileno())) + + self.assertRaisesRegex(TypeError, + 'should be string, bytes or integer, not', + posix.stat, float(fp.fileno())) finally: fp.close() def test_stat(self): if hasattr(posix, 'stat'): self.assertTrue(posix.stat(support.TESTFN)) + self.assertTrue(posix.stat(os.fsencode(support.TESTFN))) + self.assertTrue(posix.stat(bytearray(os.fsencode(support.TESTFN)))) + + self.assertRaisesRegex(TypeError, + 'can\'t specify None for path argument', + posix.stat, None) + self.assertRaisesRegex(TypeError, + 'should be string, bytes or integer, not', + posix.stat, list(support.TESTFN)) + self.assertRaisesRegex(TypeError, + 'should be string, bytes or integer, not', + posix.stat, list(os.fsencode(support.TESTFN))) @unittest.skipUnless(hasattr(posix, 'mkfifo'), "don't have mkfifo()") def test_mkfifo(self): @@ -721,6 +737,14 @@ s1 = posix.stat(support.TESTFN) s2 = posix.stat(support.TESTFN, dir_fd=f) self.assertEqual(s1, s2) + s2 = posix.stat(support.TESTFN, dir_fd=None) + self.assertEqual(s1, s2) + self.assertRaisesRegex(TypeError, 'should be integer, not', + posix.stat, support.TESTFN, dir_fd=posix.getcwd()) + self.assertRaisesRegex(TypeError, 'should be integer, not', + posix.stat, support.TESTFN, dir_fd=float(f)) + self.assertRaises(OverflowError, + posix.stat, support.TESTFN, dir_fd=10**20) finally: posix.close(f) diff -r 59a2807872d5 Modules/posixmodule.c --- a/Modules/posixmodule.c Fri Sep 21 17:29:20 2012 +0300 +++ b/Modules/posixmodule.c Fri Sep 21 20:07:09 2012 +0300 @@ -427,26 +427,24 @@ #endif static int -_fd_converter(PyObject *o, int *p, int default_value) { - long long_value; - if (o == Py_None) { - *p = default_value; - return 1; - } - if (PyFloat_Check(o)) { - PyErr_SetString(PyExc_TypeError, - "integer argument expected, got float" ); +_fd_converter(PyObject *o, int *p, const char *allowed) +{ + int overflow; + long long_value = PyLong_AsLongAndOverflow(o, &overflow); + if (PyFloat_Check(o) || + (long_value == -1 && !overflow && PyErr_Occurred())) { + PyErr_Clear(); + PyErr_Format(PyExc_TypeError, + "argument should be %s, not %.200s", + allowed, Py_TYPE(o)->tp_name); return 0; } - long_value = PyLong_AsLong(o); - if (long_value == -1 && PyErr_Occurred()) - return 0; - if (long_value > INT_MAX) { + if (overflow > 0 || long_value > INT_MAX) { PyErr_SetString(PyExc_OverflowError, "signed integer is greater than maximum"); return 0; } - if (long_value < INT_MIN) { + if (overflow < 0 || long_value < INT_MIN) { PyErr_SetString(PyExc_OverflowError, "signed integer is less than minimum"); return 0; @@ -456,8 +454,13 @@ } static int -dir_fd_converter(PyObject *o, void *p) { - return _fd_converter(o, (int *)p, DEFAULT_DIR_FD); +dir_fd_converter(PyObject *o, void *p) +{ + if (o == Py_None) { + *(int *)p = DEFAULT_DIR_FD; + return 1; + } + return _fd_converter(o, (int *)p, "integer"); } @@ -634,17 +637,16 @@ } else { PyErr_Clear(); - bytes = PyBytes_FromObject(o); + if (PyObject_CheckBuffer(o)) + bytes = PyBytes_FromObject(o); + else + bytes = NULL; if (!bytes) { PyErr_Clear(); if (path->allow_fd) { int fd; - /* - * note: _fd_converter always permits None. - * but we've already done our None check. - * so o cannot be None at this point. - */ - int result = _fd_converter(o, &fd, -1); + int result = _fd_converter(o, &fd, + "string, bytes or integer"); if (result) { path->wide = NULL; path->narrow = NULL; @@ -705,15 +707,17 @@ } static int -dir_fd_unavailable(PyObject *o, void *p) { - int *dir_fd = (int *)p; - int return_value = _fd_converter(o, dir_fd, DEFAULT_DIR_FD); - if (!return_value) +dir_fd_unavailable(PyObject *o, void *p) +{ + int dir_fd; + if (!dir_fd_converter(o, &dir_fd)) return 0; - if (*dir_fd == DEFAULT_DIR_FD) - return 1; - argument_unavailable_error(NULL, "dir_fd"); - return 0; + if (dir_fd != DEFAULT_DIR_FD) { + argument_unavailable_error(NULL, "dir_fd"); + return 0; + } + *(int *)p = dir_fd; + return 1; } static int From report at bugs.python.org Fri Sep 21 19:08:59 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 21 Sep 2012 17:08:59 +0000 Subject: [issue15972] wrong error message for os.path.getsize In-Reply-To: <1348071122.36.0.302681706423.issue15972@psf.upfronthosting.co.za> Message-ID: <1348247339.95.0.754778091032.issue15972@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file27235/posix_path_converter.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 19:09:02 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 21 Sep 2012 17:09:02 +0000 Subject: [issue15972] wrong error message for os.path.getsize In-Reply-To: <1348071122.36.0.302681706423.issue15972@psf.upfronthosting.co.za> Message-ID: <1348247342.42.0.228055279369.issue15972@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file27243/posix_path_converter_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 19:17:01 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 21 Sep 2012 17:17:01 +0000 Subject: [issue15972] wrong error message for os.path.getsize In-Reply-To: <1348071122.36.0.302681706423.issue15972@psf.upfronthosting.co.za> Message-ID: <1348247821.34.0.973573181175.issue15972@psf.upfronthosting.co.za> Larry Hastings added the comment: LGTM. Serhiy, you have the commit bit? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 19:42:13 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 21 Sep 2012 17:42:13 +0000 Subject: [issue15987] Provide a way to compare AST nodes for equality recursively In-Reply-To: <1348166637.22.0.281544835659.issue15987@psf.upfronthosting.co.za> Message-ID: <1348249333.25.0.180517105281.issue15987@psf.upfronthosting.co.za> Benjamin Peterson added the comment: This is a reasonable request. Should comparison include lineno/col_offset or not? If you implement, __eq__, you should also implement __hash__. Maybe, it would be best to start with a helper comparison function in the ast module. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 19:53:55 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 21 Sep 2012 17:53:55 +0000 Subject: [issue15972] wrong error message for os.path.getsize In-Reply-To: <1348247821.34.0.973573181175.issue15972@psf.upfronthosting.co.za> Message-ID: <201209212053.40772.storchaka@gmail.com> Serhiy Storchaka added the comment: > Serhiy, you have the commit bit? It is zero. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 20:12:14 2012 From: report at bugs.python.org (Julian Berman) Date: Fri, 21 Sep 2012 18:12:14 +0000 Subject: [issue15987] Provide a way to compare AST nodes for equality recursively In-Reply-To: <1348166637.22.0.281544835659.issue15987@psf.upfronthosting.co.za> Message-ID: <1348251134.25.0.334113349049.issue15987@psf.upfronthosting.co.za> Julian Berman added the comment: I'd say yes (to both lineno/col_offset). And yeah that sounds like what I had in mind (a helper function). If I'm specific for a moment about implementation, perhaps something like `ast.diff`, which yielded tuples of differing nodes (in say, breadth first order down the tree) from two given nodes, and took args for configuration, compare_lineno and compare_col_offset (both defaulted to True), and then __eq__ was just `next(ast.diff(self, other, compare_lineno=True, compare_col_offset=True), None) is None`. Sound good to you? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 20:49:49 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 21 Sep 2012 18:49:49 +0000 Subject: [issue15759] "make suspicious" doesn't display instructions in case of failure In-Reply-To: <1345613663.78.0.519613331574.issue15759@psf.upfronthosting.co.za> Message-ID: <1348253389.68.0.459172416907.issue15759@psf.upfronthosting.co.za> Ezio Melotti added the comment: Apparently a '-' at the beginning of the command means "run this thing and if it fails ignore the failure and keep going". I tried to add an if/else in the build target to use the '-' with the selected builder was "suspicious" but I couldn't make it work, so I ended up adding a new build-and-continue that uses the '-'. make linkcheck and make doctest had the same problem, so I fixed them too. The output now looks like this: $ make suspicious mkdir -p build/suspicious build/doctrees python tools/sphinx-build.py -b suspicious -d build/doctrees -D latex_paper_size= . build/suspicious Running Sphinx v1.0.7 loading pickled environment... done loading ignore rules... done, 359 rules loaded building [suspicious]: targets for 428 source files that are out of date updating environment: 0 added, 0 changed, 0 removed looking for now-outdated files... none found preparing documents... done writing output... [ 81%] library/unittest WARNING: [library/unittest:19] ":port" found in "host:port" writing output... [100%] whatsnew/index build finished with problems, 1 warning. make: [build-and-continue] Error 1 (ignored) Suspicious check complete; look for any errors in the above output or in build/suspicious/suspicious.csv. If all issues are false positives, append that file to tools/sphinxext/susp-ignored.csv. ---------- stage: patch review -> commit review versions: +Python 2.7, Python 3.2 Added file: http://bugs.python.org/file27248/issue15759-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 22:05:40 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 21 Sep 2012 20:05:40 +0000 Subject: [issue15990] solidify argument/parameter terminology In-Reply-To: <1348169057.62.0.370171802379.issue15990@psf.upfronthosting.co.za> Message-ID: <1348257940.77.0.318040734849.issue15990@psf.upfronthosting.co.za> Chris Jerdonek added the comment: We could start by establishing the argument/parameter distinction in the glossary. Currently, the word "parameter" does not appear in the glossary, and the definition of "argument" blurs the distinction between the two: For example, in the following definition of "argument"-- "argument: A value passed to a function or method, assigned to a named local variable in the function body. A function or method may have both positional arguments and keyword arguments in its definition..." (from http://docs.python.org/dev/glossary.html#term-argument ) the second sentence is actually talking about parameters. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 22:06:58 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 21 Sep 2012 20:06:58 +0000 Subject: [issue15990] solidify argument/parameter terminology In-Reply-To: <1348169057.62.0.370171802379.issue15990@psf.upfronthosting.co.za> Message-ID: <1348258018.54.0.809091820766.issue15990@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > IMHO as soon as you use terms like "receives" or "accepts", you are still talking about arguments. Even PEP 362 is loose with its language in this regard. For example, at the beginning of the "Signature Object" section: "For each parameter accepted by the function it stores a Parameter object in its parameters collection." And at the beginning of the "Parameter Object" section: "Python's expressive syntax means functions can accept many different kinds of parameters with many subtle semantic differences." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 22:14:10 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 21 Sep 2012 20:14:10 +0000 Subject: [issue15379] Charmap decoding of no-BMP characters In-Reply-To: <1342512958.35.0.341191772548.issue15379@psf.upfronthosting.co.za> Message-ID: <201209212313.47557.storchaka@gmail.com> Serhiy Storchaka added the comment: Patches updated. Added a few new tests, used MAX_UNICODE, a little changed extrachars grow step. ---------- Added file: http://bugs.python.org/file27249/decode_charmap_maxchar-3.3_2.patch Added file: http://bugs.python.org/file27250/decode_charmap_maxchar-3.2_2.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 3e677956eef4 Lib/test/test_codecs.py --- a/Lib/test/test_codecs.py Fri Sep 21 10:12:14 2012 -0700 +++ b/Lib/test/test_codecs.py Fri Sep 21 23:08:31 2012 +0300 @@ -1693,6 +1693,15 @@ ) self.assertEqual( + codecs.charmap_decode(b"\x00\x01\x02", "strict", "\U0010FFFFbc"), + ("\U0010FFFFbc", 3) + ) + + self.assertRaises(UnicodeDecodeError, + codecs.charmap_decode, b"\x00\x01\x02", "strict", "ab" + ) + + self.assertEqual( codecs.charmap_decode(b"\x00\x01\x02", "replace", "ab"), ("ab\ufffd", 3) ) @@ -1718,6 +1727,113 @@ ("", len(allbytes)) ) + def test_decode_with_int2str_map(self): + self.assertEqual( + codecs.charmap_decode(b"\x00\x01\x02", "strict", + {0: 'a', 1: 'b', 2: 'c'}), + ("abc", 3) + ) + + self.assertEqual( + codecs.charmap_decode(b"\x00\x01\x02", "strict", + {0: 'Aa', 1: 'Bb', 2: 'Cc'}), + ("AaBbCc", 3) + ) + + self.assertEqual( + codecs.charmap_decode(b"\x00\x01\x02", "strict", + {0: '\U0010FFFF', 1: 'b', 2: 'c'}), + ("\U0010FFFFbc", 3) + ) + + self.assertEqual( + codecs.charmap_decode(b"\x00\x01\x02", "strict", + {0: 'a', 1: 'b', 2: ''}), + ("ab", 3) + ) + + self.assertRaises(UnicodeDecodeError, + codecs.charmap_decode, b"\x00\x01\x02", "strict", + {0: 'a', 1: 'b'} + ) + + self.assertEqual( + codecs.charmap_decode(b"\x00\x01\x02", "replace", + {0: 'a', 1: 'b'}), + ("ab\ufffd", 3) + ) + + self.assertEqual( + codecs.charmap_decode(b"\x00\x01\x02", "replace", + {0: 'a', 1: 'b', 2: None}), + ("ab\ufffd", 3) + ) + + self.assertEqual( + codecs.charmap_decode(b"\x00\x01\x02", "ignore", + {0: 'a', 1: 'b'}), + ("ab", 3) + ) + + self.assertEqual( + codecs.charmap_decode(b"\x00\x01\x02", "ignore", + {0: 'a', 1: 'b', 2: None}), + ("ab", 3) + ) + + allbytes = bytes(range(256)) + self.assertEqual( + codecs.charmap_decode(allbytes, "ignore", {}), + ("", len(allbytes)) + ) + + def test_decode_with_int2int_map(self): + a = ord('a') + b = ord('b') + c = ord('c') + + self.assertEqual( + codecs.charmap_decode(b"\x00\x01\x02", "strict", + {0: a, 1: b, 2: c}), + ("abc", 3) + ) + + # Issue #15379 + self.assertEqual( + codecs.charmap_decode(b"\x00\x01\x02", "strict", + {0: 0x10FFFF, 1: b, 2: c}), + ("\U0010FFFFbc", 3) + ) + + self.assertEqual( + codecs.charmap_decode(b"\x00\x01\x02", "strict", + {0: sys.maxunicode, 1: b, 2: c}), + (chr(sys.maxunicode) + "bc", 3) + ) + + self.assertRaises(TypeError, + codecs.charmap_decode, b"\x00\x01\x02", "strict", + {0: sys.maxunicode + 1, 1: b, 2: c} + ) + + self.assertRaises(UnicodeDecodeError, + codecs.charmap_decode, b"\x00\x01\x02", "strict", + {0: a, 1: b}, + ) + + self.assertEqual( + codecs.charmap_decode(b"\x00\x01\x02", "replace", + {0: a, 1: b}), + ("ab\ufffd", 3) + ) + + self.assertEqual( + codecs.charmap_decode(b"\x00\x01\x02", "ignore", + {0: a, 1: b}), + ("ab", 3) + ) + + class WithStmtTest(unittest.TestCase): def test_encodedfile(self): f = io.BytesIO(b"\xc3\xbc") diff -r 3e677956eef4 Objects/unicodeobject.c --- a/Objects/unicodeobject.c Fri Sep 21 10:12:14 2012 -0700 +++ b/Objects/unicodeobject.c Fri Sep 21 23:08:31 2012 +0300 @@ -7525,9 +7525,10 @@ /* Apply mapping */ if (PyLong_Check(x)) { long value = PyLong_AS_LONG(x); - if (value < 0 || value > 65535) { - PyErr_SetString(PyExc_TypeError, - "character mapping must be in range(65536)"); + if (value < 0 || value > MAX_UNICODE) { + PyErr_Format(PyExc_TypeError, + "character mapping must be in range(0x%lx)", + (unsigned long)MAX_UNICODE + 1); Py_DECREF(x); goto onError; } -------------- next part -------------- diff -r aa73e60f65e9 Lib/test/test_codecs.py --- a/Lib/test/test_codecs.py Fri Sep 21 17:26:35 2012 +0300 +++ b/Lib/test/test_codecs.py Fri Sep 21 23:08:15 2012 +0300 @@ -1546,6 +1546,10 @@ ("abc", 3) ) + self.assertRaises(UnicodeDecodeError, + codecs.charmap_decode, b"\x00\x01\x02", "strict", "ab" + ) + self.assertEqual( codecs.charmap_decode(b"\x00\x01\x02", "replace", "ab"), ("ab\ufffd", 3) @@ -1572,6 +1576,107 @@ ("", len(allbytes)) ) + def test_decode_with_int2str_map(self): + self.assertEqual( + codecs.charmap_decode(b"\x00\x01\x02", "strict", + {0: 'a', 1: 'b', 2: 'c'}), + ("abc", 3) + ) + + self.assertEqual( + codecs.charmap_decode(b"\x00\x01\x02", "strict", + {0: 'Aa', 1: 'Bb', 2: 'Cc'}), + ("AaBbCc", 3) + ) + + self.assertEqual( + codecs.charmap_decode(b"\x00\x01\x02", "strict", + {0: '\U0010FFFF', 1: 'b', 2: 'c'}), + ("\U0010FFFFbc", 3) + ) + + self.assertEqual( + codecs.charmap_decode(b"\x00\x01\x02", "strict", + {0: 'a', 1: 'b', 2: ''}), + ("ab", 3) + ) + + self.assertRaises(UnicodeDecodeError, + codecs.charmap_decode, b"\x00\x01\x02", "strict", + {0: 'a', 1: 'b'} + ) + + self.assertEqual( + codecs.charmap_decode(b"\x00\x01\x02", "replace", + {0: 'a', 1: 'b'}), + ("ab\ufffd", 3) + ) + + self.assertEqual( + codecs.charmap_decode(b"\x00\x01\x02", "replace", + {0: 'a', 1: 'b', 2: None}), + ("ab\ufffd", 3) + ) + + self.assertEqual( + codecs.charmap_decode(b"\x00\x01\x02", "ignore", + {0: 'a', 1: 'b'}), + ("ab", 3) + ) + + self.assertEqual( + codecs.charmap_decode(b"\x00\x01\x02", "ignore", + {0: 'a', 1: 'b', 2: None}), + ("ab", 3) + ) + + allbytes = bytes(range(256)) + self.assertEqual( + codecs.charmap_decode(allbytes, "ignore", {}), + ("", len(allbytes)) + ) + + def test_decode_with_int2int_map(self): + a = ord('a') + b = ord('b') + c = ord('c') + + self.assertEqual( + codecs.charmap_decode(b"\x00\x01\x02", "strict", + {0: a, 1: b, 2: c}), + ("abc", 3) + ) + + # Issue #15379 + self.assertEqual( + codecs.charmap_decode(b"\x00\x01\x02", "strict", + {0: 0x10FFFF, 1: b, 2: c}), + ("\U0010FFFFbc", 3) + ) + + self.assertRaises(TypeError, + codecs.charmap_decode, b"\x00\x01\x02", "strict", + {0: 0x110000, 1: b, 2: c} + ) + + self.assertRaises(UnicodeDecodeError, + codecs.charmap_decode, b"\x00\x01\x02", "strict", + {0: a, 1: b}, + ) + + self.assertEqual( + codecs.charmap_decode(b"\x00\x01\x02", "replace", + {0: a, 1: b}), + ("ab\ufffd", 3) + ) + + self.assertEqual( + codecs.charmap_decode(b"\x00\x01\x02", "ignore", + {0: a, 1: b}), + ("ab", 3) + ) + + class WithStmtTest(unittest.TestCase): def test_encodedfile(self): f = io.BytesIO(b"\xc3\xbc") diff -r aa73e60f65e9 Objects/unicodeobject.c --- a/Objects/unicodeobject.c Fri Sep 21 17:26:35 2012 +0300 +++ b/Objects/unicodeobject.c Fri Sep 21 23:08:15 2012 +0300 @@ -5250,12 +5250,36 @@ /* Apply mapping */ if (PyLong_Check(x)) { long value = PyLong_AS_LONG(x); - if (value < 0 || value > 65535) { + if (value < 0 || value > 0x10FFFF) { PyErr_SetString(PyExc_TypeError, - "character mapping must be in range(65536)"); + "character mapping must be in range(0x110000)"); Py_DECREF(x); goto onError; } + +#ifndef Py_UNICODE_WIDE + if (value > 0xFFFF) { + /* see the code for 1-n mapping below */ + if (extrachars < 2) { + /* resize first */ + Py_ssize_t oldpos = p - PyUnicode_AS_UNICODE(v); + Py_ssize_t needed = 10 - extrachars; + extrachars += needed; + /* XXX overflow detection missing */ + if (_PyUnicode_Resize(&v, + PyUnicode_GET_SIZE(v) + needed) < 0) { + Py_DECREF(x); + goto onError; + } + p = PyUnicode_AS_UNICODE(v) + oldpos; + } + value -= 0x10000; + *p++ = 0xD800 | (value >> 10); + *p++ = 0xDC00 | (value & 0x3FF); + extrachars -= 2; + } + else +#endif *p++ = (Py_UNICODE)value; } else if (x == Py_None) { From report at bugs.python.org Fri Sep 21 22:16:09 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 21 Sep 2012 20:16:09 +0000 Subject: [issue15379] Charmap decoding of no-BMP characters In-Reply-To: <1342512958.35.0.341191772548.issue15379@psf.upfronthosting.co.za> Message-ID: <1348258569.82.0.985502559231.issue15379@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file26412/decode_charmap_maxchar.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 22:16:16 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 21 Sep 2012 20:16:16 +0000 Subject: [issue15379] Charmap decoding of no-BMP characters In-Reply-To: <1342512958.35.0.341191772548.issue15379@psf.upfronthosting.co.za> Message-ID: <1348258576.53.0.577254521732.issue15379@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file26416/decode_charmap_tests.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 22:16:26 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 21 Sep 2012 20:16:26 +0000 Subject: [issue15379] Charmap decoding of no-BMP characters In-Reply-To: <1342512958.35.0.341191772548.issue15379@psf.upfronthosting.co.za> Message-ID: <1348258586.57.0.716212351255.issue15379@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file26428/decode_charmap_maxchar-3.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 22:42:30 2012 From: report at bugs.python.org (Catalin Iacob) Date: Fri, 21 Sep 2012 20:42:30 +0000 Subject: [issue15991] BaseHTTPServer with ThreadingMixIn serving wrong data sometimes In-Reply-To: <1348171381.08.0.748825821227.issue15991@psf.upfronthosting.co.za> Message-ID: <1348260149.24.0.929269633222.issue15991@psf.upfronthosting.co.za> Catalin Iacob added the comment: Can't reproduce this on openSUSE Factory (development version, what will become 12.3). I tried with openSUSE's Python 2 which is 2.7.3 and with self compiled up to date 2.7 branch from hg. For each of these I bumped the number of files to 3000 instead of 300 and ran the script around 10 times, always got 3000 good 0 bad. ---------- nosy: +catalin.iacob _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 22:51:33 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 21 Sep 2012 20:51:33 +0000 Subject: [issue1602] windows console doesn't print or input Unicode In-Reply-To: <1348244409.32.0.55063490164.issue1602@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > Will this [issue] be solved in 3.3 final? No. It would be an huge change and the RC2 was already released. No new feature are accepted after the version 3.3.0 beta 1: http://www.python.org/dev/peps/pep-0398/ I'm not really motivated to work on this issue, because it is really hard to get something working in all cases. Using ReadConsoleW/WriteConsoleW helps, but it doesn't solve all issues as you said. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 22:54:20 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 21 Sep 2012 20:54:20 +0000 Subject: [issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails In-Reply-To: <1348173110.08.0.356112095586.issue15993@psf.upfronthosting.co.za> Message-ID: <1348260860.21.0.179063128855.issue15993@psf.upfronthosting.co.za> STINNER Victor added the comment: Issue #15995 was marked as a duplicate of this issue. Copy of its initial message (msg170853): This is similar to #15993: With the installed Python from the rc2-msi test_lzma fails. I cannot reproduce the failure with python.exe (PGO) compiled from source: ====================================================================== ERROR: test__decode_filter_properties (test.test_lzma.MiscellaneousTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python33\lib\test\test_lzma.py", line 1105, in test__decode_filter_properties lzma.FILTER_LZMA1, b"]\x00\x00\x80\x00") ValueError: Invalid filter ID: 4611686018427387905 ====================================================================== ERROR: test_filter_properties_roundtrip (test.test_lzma.MiscellaneousTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python33\lib\test\test_lzma.py", line 1114, in test_filter_properties_roundtrip lzma.FILTER_LZMA1, b"]\x00\x00\x80\x00") ValueError: Invalid filter ID: 4611686018427387905 ---------------------------------------------------------------------- ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 23:02:24 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 21 Sep 2012 21:02:24 +0000 Subject: [issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails In-Reply-To: <1348173110.08.0.356112095586.issue15993@psf.upfronthosting.co.za> Message-ID: <1348261344.9.0.687433709249.issue15993@psf.upfronthosting.co.za> STINNER Victor added the comment: I fail to reproduce the issue on Windows 7 (Version 6.0.1, number 7601, Service Pack 1): --- Microsoft Windows [version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. Tous droits r?serv?s. C:\Users\haypo>cd \python33 C:\Python33>python.exe Python 3.3.0rc2 (v3.3.0rc2:88a0792e8ba3, Sep 9 2012, 10:13:38) [MSC v.1600 64 b it (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> exit() C:\Python33>python.exe -m test test_buffer test_lzma [1/2] test_buffer [2/2] test_lzma All 2 tests OK. --- I'm running Windows 7 in KVM, my host CPU is a Intel i7-2600. > I'm getting these failures in test_buffer, > but I can *not* reproduce them when I build > Win-32/pgo/python.exe from source: The issue looks to be specific to 64 bits binaries. You need the professional version of Visual Studio 10. The express version doesn't support 64 bits. I only have the Express version. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 23:04:09 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 21 Sep 2012 21:04:09 +0000 Subject: [issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails In-Reply-To: <1348173110.08.0.356112095586.issue15993@psf.upfronthosting.co.za> Message-ID: <1348261449.44.0.324929878368.issue15993@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Declaring this a release blocker is technically difficult. If it is a release blocker, further releases cannot be done until it is resolved. Since it is an issue with the binary only, the only possible way to resolve this is with a release. So declaring this a release blocker essentially deadlocks the release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 23:07:13 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 21 Sep 2012 21:07:13 +0000 Subject: [issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails In-Reply-To: <1348173110.08.0.356112095586.issue15993@psf.upfronthosting.co.za> Message-ID: <1348261633.44.0.984761124191.issue15993@psf.upfronthosting.co.za> Martin v. L?wis added the comment: For the record, the released binary is not just a PGO build, but has been trained with the attached training script. ---------- Added file: http://bugs.python.org/file27251/profile.bat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 23:07:21 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 21 Sep 2012 21:07:21 +0000 Subject: [issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails In-Reply-To: <1348173110.08.0.356112095586.issue15993@psf.upfronthosting.co.za> Message-ID: <1348261641.93.0.556340853539.issue15993@psf.upfronthosting.co.za> Changes by Martin v. L?wis : Added file: http://bugs.python.org/file27252/profiletests.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 23:14:39 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 21 Sep 2012 21:14:39 +0000 Subject: [issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails In-Reply-To: <1348173110.08.0.356112095586.issue15993@psf.upfronthosting.co.za> Message-ID: <1348262079.85.0.29262932542.issue15993@psf.upfronthosting.co.za> STINNER Victor added the comment: > You need the professional version of Visual Studio 10. > The express version doesn't support 64 bits. I only have the > Express version. Ah yes, I now remember my issue with VS10 Express: when I set the project to 64 bits, I get such error popup: http://www.haypocalc.com/tmp/visual_studio_64bits.png Which version should I try? Ultimate? Premium? Professional? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 23:24:02 2012 From: report at bugs.python.org (Idan Kamara) Date: Fri, 21 Sep 2012 21:24:02 +0000 Subject: [issue14174] argparse.REMAINDER fails to parse remainder correctly In-Reply-To: <1330690090.15.0.511487898244.issue14174@psf.upfronthosting.co.za> Message-ID: <1348262642.84.0.710934643644.issue14174@psf.upfronthosting.co.za> Idan Kamara added the comment: I just ran into this issue myself and worked around it by using parse_known_args*. * http://docs.python.org/library/argparse.html#partial-parsing ---------- nosy: +idank _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 23:29:21 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 21 Sep 2012 21:29:21 +0000 Subject: [issue15949] docs.python.org not getting updated In-Reply-To: <1347728419.57.0.753818975668.issue15949@psf.upfronthosting.co.za> Message-ID: <1348262961.71.0.79970250535.issue15949@psf.upfronthosting.co.za> Chris Jerdonek added the comment: The 2.7 docs seem not to be affected by this issue (they are current) -- just the docs for 3.2 and the default branch. ---------- versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 23:29:39 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 21 Sep 2012 21:29:39 +0000 Subject: [issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails In-Reply-To: <1348262079.85.0.29262932542.issue15993@psf.upfronthosting.co.za> Message-ID: <20120921212937.GA31120@sleipnir.bytereef.org> Stefan Krah added the comment: STINNER Victor wrote: > Which version should I try? Ultimate? Premium? Professional? Try Ultimate, it's AFAIK the only version these days that supports PGO. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 23:30:59 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 21 Sep 2012 21:30:59 +0000 Subject: [issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails In-Reply-To: <1348261633.44.0.984761124191.issue15993@psf.upfronthosting.co.za> Message-ID: <20120921213057.GB31120@sleipnir.bytereef.org> Stefan Krah added the comment: Martin v. L?wis wrote: > For the record, the released binary is not just a PGO build, but has > been trained with the attached training script. Thanks. Now I can reproduce the issue with a source build. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 23:31:27 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 21 Sep 2012 21:31:27 +0000 Subject: [issue16000] test_curses should use unittest Message-ID: <1348263086.74.0.172285441847.issue16000@psf.upfronthosting.co.za> New submission from Chris Jerdonek: This issue is to switch test_curses to using unittest.TestCase classes. Currently, test_curses does not use unittest.TestCase. It just calls a series of functions that exercise curses functionality and aborts if an exception occurs: http://hg.python.org/cpython/file/3e677956eef4/Lib/test/test_curses.py#l314 Some consequences of this are that a single failure will cause remaining tests not to execute, there is no fine-grained reporting, and TestCase assertion methods are not available (e.g. assertRaisesRegexp()). ---------- components: Library (Lib) messages: 170925 nosy: cjerdonek priority: normal severity: normal status: open title: test_curses should use unittest type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 23:33:02 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 21 Sep 2012 21:33:02 +0000 Subject: [issue16000] test_curses should use unittest In-Reply-To: <1348263086.74.0.172285441847.issue16000@psf.upfronthosting.co.za> Message-ID: <1348263182.41.0.0763019014953.issue16000@psf.upfronthosting.co.za> STINNER Victor added the comment: Would like to work on such patch? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 23:33:06 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 21 Sep 2012 21:33:06 +0000 Subject: [issue15852] typos in curses argument error messages In-Reply-To: <1346622102.83.0.795568790125.issue15852@psf.upfronthosting.co.za> Message-ID: <1348263186.32.0.10213078033.issue15852@psf.upfronthosting.co.za> Chris Jerdonek added the comment: FYI, I created issue 16000 :) to switch test_curses to using unittest.TestCase. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 23:39:41 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 21 Sep 2012 21:39:41 +0000 Subject: [issue15964] SyntaxError in asdl when building 2.7 with system Python 3 In-Reply-To: <1347978379.29.0.810502621141.issue15964@psf.upfronthosting.co.za> Message-ID: <1348263581.16.0.58495711018.issue15964@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Switching this to a devguide issue so the work-around can be documented, for example in this section: http://docs.python.org/devguide/faq.html#how-do-i-switch-between-branches-inside-my-working-copy ---------- assignee: -> docs at python components: +Devguide, Documentation -Build keywords: +easy nosy: +docs at python, ezio.melotti stage: -> needs patch type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 23:40:14 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 21 Sep 2012 21:40:14 +0000 Subject: [issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails In-Reply-To: <1348173110.08.0.356112095586.issue15993@psf.upfronthosting.co.za> Message-ID: <1348263614.74.0.984028663322.issue15993@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'm using Ultimate, but I think Professional should provide you with all required tools. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 23:46:08 2012 From: report at bugs.python.org (Ned Deily) Date: Fri, 21 Sep 2012 21:46:08 +0000 Subject: [issue15949] docs.python.org not getting updated In-Reply-To: <1347728419.57.0.753818975668.issue15949@psf.upfronthosting.co.za> Message-ID: <1348263968.42.0.759175085193.issue15949@psf.upfronthosting.co.za> Ned Deily added the comment: I believe Georg maintains cronjobs for updating the docs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 23:49:17 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 21 Sep 2012 21:49:17 +0000 Subject: [issue16000] test_curses should use unittest In-Reply-To: <1348263086.74.0.172285441847.issue16000@psf.upfronthosting.co.za> Message-ID: <1348264157.81.0.367160993406.issue16000@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Sure, I could start work on such a patch. I may start by switching just a couple of the functions to TestCase though (to establish a model and to make sure everything is wired up correctly), rather than attempting to switch the entire module all at once. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 23:52:45 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 21 Sep 2012 21:52:45 +0000 Subject: [issue15895] PyRun_SimpleFileExFlags() can leak a FILE pointer In-Reply-To: <1347231050.54.0.0211027720618.issue15895@psf.upfronthosting.co.za> Message-ID: <1348264365.65.0.395522771827.issue15895@psf.upfronthosting.co.za> STINNER Victor added the comment: This issue is not a regression, I think that the fix can wait for Python 3.3.1. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 21 23:56:10 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 21 Sep 2012 21:56:10 +0000 Subject: [issue15895] PyRun_SimpleFileExFlags() can leak a FILE pointer In-Reply-To: <1347231050.54.0.0211027720618.issue15895@psf.upfronthosting.co.za> Message-ID: <1348264570.51.0.720229095204.issue15895@psf.upfronthosting.co.za> STINNER Victor added the comment: > This issue is not a regression My bad, Crys explained me on IRC that the leak does not exist in Python 3.2, it was introduced by the importlib. So it is a regression. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 00:13:28 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 21 Sep 2012 22:13:28 +0000 Subject: [issue15972] wrong error message for os.path.getsize In-Reply-To: <1348071122.36.0.302681706423.issue15972@psf.upfronthosting.co.za> Message-ID: <1348265608.5.0.836006627276.issue15972@psf.upfronthosting.co.za> Larry Hastings added the comment: Georg: this okay to check in? It passes the regression test. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 00:54:14 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 21 Sep 2012 22:54:14 +0000 Subject: [issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails In-Reply-To: <1348173110.08.0.356112095586.issue15993@psf.upfronthosting.co.za> Message-ID: <1348268054.84.0.211446605462.issue15993@psf.upfronthosting.co.za> Stefan Krah added the comment: It's a bit late here already, but unless I'm missing something I think this is an optimizer bug. I'm attaching a workaround for memoryview.c and _lzmamodule.c. ---------- keywords: +patch Added file: http://bugs.python.org/file27253/issue15993.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 02:05:23 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 22 Sep 2012 00:05:23 +0000 Subject: [issue12067] Doc: remove errors about mixed-type comparisons. In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za> Message-ID: <1348272323.83.0.295622691418.issue12067@psf.upfronthosting.co.za> Terry J. Reedy added the comment: After further thought: This section is about the syntax operators, not the special methods. The syntax operators never evaluate to NotImplemented as they (apparently) interpret its return from a special method the same as a raising of TypeError, and always raise TypeError when neither the op or its reflection is supported. So there should be no mention of NotImplemented here. Just a reference to 3.3. #15997 is related to my 'wonder' but not directly relevant to a patch for this. Please submit a draft patch when you have one. I determined that 'raise TypeError' and 'return NotImplemented' both result in the call of the reflected method, at least for a couple of cases. (And same seems true for arithmetic ops too.) class C(): def __ge__(self, other): # print("in C.__ge__", end='') return True def __add__(self, other): return 44 __radd__ = __add__ class O(): def __le__(self, other): # print ("in O.__le__") return NotImplemented def __add__(self, other): return NotImplemented c = C() o = O() ob = object() print(c >= o, o <= c, ob <= c) # True True True # print(ob <= ob) # raises TypeError print(c + o, o + c, ob + c) # 44 44 44 # print(ob + ob) # raises TypeError # print(ob >= o) # with O.__le__ print uncommented # in O.__le__ # so non-implemented reflected o <= ob *is* called # TypeError: unorderable types: object() >= O() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 02:10:49 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 22 Sep 2012 00:10:49 +0000 Subject: [issue15997] NotImplemented needs to be documented In-Reply-To: <1348206637.53.0.485410334327.issue15997@psf.upfronthosting.co.za> Message-ID: <1348272649.53.0.228031950738.issue15997@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The first three sentences are fine. The problem I have is with the 4th: 'may return' is rather vague. Such methods may raise TypeError instead (the old way), seemingly to the same effect. (See msg170936 in issue #12067, which is about clarifying the comparisons section of the expression chapter.). So the 5th sentence could be misinterpreted wrongly to mean that NotImplemented is needed to get the alternate method try. (Since it is not, I wonder why it was added, since it complicates the internal logic of arithmetic and comparison ops.) Perhaps a better place for any clarification on this point would be in 3.3 in the entry for __le__, etc. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 02:11:20 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 22 Sep 2012 00:11:20 +0000 Subject: [issue16001] small ints: cache string representation Message-ID: <1348272680.09.0.237238464287.issue16001@psf.upfronthosting.co.za> New submission from STINNER Victor: Integers in range [-5; 256] are singleton. It is possible to cache their string representation (in base 10) to make str(int) faster, but also to reduce memory consumption (and memory fragmentation, Unicode strings don't use free list). Attached patch implements this micro-optimization. It reuses singleton for latin1 characters (so digits 0..9): str(0) is chr(48). - /* Special-case boolean: we want 0/1 */ - if (PyBool_Check(val)) - result = PyNumber_ToBase(val, 10); - else - result = Py_TYPE(val)->tp_str(val); + result = PyNumber_ToBase(val, 10); This change is required because Py_TYPE(val)->tp_str(val); may return a singleton, whereas formatlong() requires a "mutable" string (string not used yet). See also issue #10044. ---------- components: Unicode files: small_ints_cache_str.patch keywords: patch messages: 170938 nosy: ezio.melotti, haypo, pitrou priority: normal severity: normal status: open title: small ints: cache string representation type: performance versions: Python 3.4 Added file: http://bugs.python.org/file27254/small_ints_cache_str.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 02:11:49 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 22 Sep 2012 00:11:49 +0000 Subject: [issue16001] small ints: cache string representation In-Reply-To: <1348272680.09.0.237238464287.issue16001@psf.upfronthosting.co.za> Message-ID: <1348272709.56.0.169411150872.issue16001@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 02:12:01 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 22 Sep 2012 00:12:01 +0000 Subject: [issue16001] small ints: cache string representation In-Reply-To: <1348272680.09.0.237238464287.issue16001@psf.upfronthosting.co.za> Message-ID: <1348272721.8.0.394604527516.issue16001@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: -ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 02:22:06 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 22 Sep 2012 00:22:06 +0000 Subject: [issue15998] Python GUI idle not working In-Reply-To: <1348223430.53.0.95377552699.issue15998@psf.upfronthosting.co.za> Message-ID: <1348273326.94.0.690201172825.issue15998@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The following might also be helpful: which version of Windows? 32 or 64 bit? is python the 32 or 64 bit build? Or just copy the header line from the interactive interpreter. For me: Python 3.3.0rc2 (v3.3.0rc2:88a0792e8ba3, Sep 9 2012, 10:13:38) [MSC v.1600 64 bit (AMD64)] on win32 (although the win32 part seems wrong as this is 64 bit windows and amd64 build would not run on 32 bit windows) Another suggestion: get 3.3.0, install in /python33, and try that (you should be able to select an option to have it not be the default install). This should not affect your 3.2 installation, and it will install its own copy of tcl/tk. In fact, if you do not have 3.2.3, you should be able to install that without disturbing your installed libraries. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 02:41:59 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 22 Sep 2012 00:41:59 +0000 Subject: [issue10044] small int optimization In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za> Message-ID: <1348274519.79.0.306436521145.issue10044@psf.upfronthosting.co.za> STINNER Victor added the comment: If I understood correctly, the optimization proposed by Antoine was somehow rejected because _PyLong_IS_SMALL_INT() may be optimized "incorrectly". If a compiler "miscompiles" this macro, can't we disable this optimization on this specific compiler, instead of missing an interesting optimization on all compilers? I bet that no compiler will do insane optimization on such test. Where in CPython source code do we use directly references to small_ints? The common case is to write PyLong_FromLong(0). Can compiler call PyLong_FromLong() to detect that the result is part of the small_ints array? Or that it is not part of small_ints? The corner case is very unlikely to me. -- I tested Antoine's patch with GCC 4.6 and CFLAGS="-O3 -flto" (-flto: standard link-time optimizer): the test suite pass. I don't see any magic optimization here, sorry. -- "fwiw I've always found this helpful for undefined behavior: http://blog.regehr.org/archives/213 and, just as it says "x+1 > x" will be optimized to a nop, by the same logic "v >= &array[0] && v < &array[array_len]" will also be optimized to a nop." "x+1 > x" and "v >= &array[0]" are not the same checks. In the first test, x is used in both parts. I don't understand. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 02:42:09 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 22 Sep 2012 00:42:09 +0000 Subject: [issue10044] small int optimization In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za> Message-ID: <1348274529.72.0.677842407922.issue10044@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 02:45:14 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 22 Sep 2012 00:45:14 +0000 Subject: [issue16000] test_curses should use unittest In-Reply-To: <1348263086.74.0.172285441847.issue16000@psf.upfronthosting.co.za> Message-ID: <1348274714.87.0.492844231147.issue16000@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Here is an initial patch for discussion. As I started to say in my previous comment, I think it would be worth settling on the wiring (e.g. setUp/tearDown/etc) before trying to do more. Some comments on the current patch: (1) Of the following methods, it's not clear to me which should go in setUpModule(), setUpClass(), and setUp(): curses.setupterm(), curses.initscr(), and curses.savetty(). (2) When running the tests using "__main__" or from regrtest in verbose mode, there is a slight rendering glitch in that the "ok" prints over the beginning of the output line instead of appending to the end: $ ./python.exe Lib/test/test_curses.py okst_issue10570 (__main__.CursesTestCase) ... okst_issue6243 (__main__.CursesTestCase) ... ---------------------------------------------------------------------- Ran 2 tests in 0.005s OK I'm not sure how important it is to make that work perfectly. Using regrtest in normal mode, there are no rendering defects that I see. ---------- keywords: +needs review, patch stage: -> patch review Added file: http://bugs.python.org/file27255/issue-16000-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 02:46:15 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 22 Sep 2012 00:46:15 +0000 Subject: [issue2281] Enhanced cPython profiler with high-resolution timer In-Reply-To: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za> Message-ID: <1348274775.89.0.99339807787.issue2281@psf.upfronthosting.co.za> STINNER Victor added the comment: Python 3.3 has a new time.perf_counter() function. It may be possible to expose this function in C and then use it in _lsprof. See the PEP for the list of (OS/hardware) clocks used by this function: http://www.python.org/dev/peps/pep-0418/#time-perf-counter http://www.python.org/dev/peps/pep-0418/#time-monotonic ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 02:46:41 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 22 Sep 2012 00:46:41 +0000 Subject: [issue16001] small ints: cache string representation In-Reply-To: <1348272680.09.0.237238464287.issue16001@psf.upfronthosting.co.za> Message-ID: <1348274801.68.0.659492292779.issue16001@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Honestly, I'm not sure I understand the point of this optimization. Have you identified a workload where this would help? ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 02:54:30 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 22 Sep 2012 00:54:30 +0000 Subject: [issue2281] Enhanced cPython profiler with high-resolution timer In-Reply-To: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za> Message-ID: <1348275270.21.0.271320807913.issue2281@psf.upfronthosting.co.za> STINNER Victor added the comment: Reading directly the CPU timestamp counter is not a good idea. > One issue with using timestamp counters is that their resolution varies > with CPU speed, which is not necessarily constant during a whole run > (because of power management). On the other hand I'm not sure it's > really a problem. There is another major issue: you have to synchronize the counter of all CPU cores. Windows XP didn't synchronize the counters, and it was a major issue on QueryPerformanceCounter. http://support.microsoft.com/?id=896256 It is really better to rely on the OS rather than querying directly the hardward. The OS (well, most OS except Windows) handles all these minor "nits" and provide the best possible resolution. -- > Python 3.3 has a new time.perf_counter() function. > It may be possible to expose this function in C ... Oh, I now remember why I didn't do this before: when clock_gettime() function is used in perf_counter(), the program or library must be linked to librt on most Linux distro. It was easier to only handle this correctly for the time module. We can do something similar on the _lsprof module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 03:10:52 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 22 Sep 2012 01:10:52 +0000 Subject: [issue15956] backreference to named group does not work In-Reply-To: <1347888827.23.0.363134887653.issue15956@psf.upfronthosting.co.za> Message-ID: <1348276252.43.0.852860016792.issue15956@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I read it as a 'native speaker' and it looks fine to me. Table is clear, but I will let doc stylist decide. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 03:12:05 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 22 Sep 2012 01:12:05 +0000 Subject: [issue15997] NotImplemented needs to be documented In-Reply-To: <1348206637.53.0.485410334327.issue15997@psf.upfronthosting.co.za> Message-ID: <1348276325.37.0.0215154698817.issue15997@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Terry: can you propose an alternative wording? I don't think that the discussion of TypeError belongs into the description of NotImplemented, though. IIUC, NotImplemented was added for performance reasons; returning a value is much faster than raising an exception. The return only requires an INCREF/DECREF pair, and a pointer identity test. The exception requires to create a new object, possibly a traceback, and a subclass check on exception matching. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 03:13:45 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 22 Sep 2012 01:13:45 +0000 Subject: [issue16001] small ints: cache string representation In-Reply-To: <1348272680.09.0.237238464287.issue16001@psf.upfronthosting.co.za> Message-ID: <1348276425.32.0.842354103581.issue16001@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Also, can you report benchmark results? ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 03:19:28 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 22 Sep 2012 01:19:28 +0000 Subject: [issue15974] Optional compact and colored output for regrest In-Reply-To: <1348077938.27.0.260547344914.issue15974@psf.upfronthosting.co.za> Message-ID: <1348276768.71.0.973918265489.issue15974@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Great idea. By default, the windows console keeps fewer lines of output than regrtest generates, which means that earlier errors are gone before it finishes. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 03:28:14 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 22 Sep 2012 01:28:14 +0000 Subject: [issue15978] asyncore: included batteries don't fit In-Reply-To: <1348109984.23.0.963898980799.issue15978@psf.upfronthosting.co.za> Message-ID: <1348277294.38.0.570226113968.issue15978@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I think discussion of this idea on python-ideas list would be better. There might be some controversy and alternatives presented. With a positive response, a PEP should probably follow with details on a module by module basis. As this stands, this is not really an actionable issue. So yes, I am suggesting closing for the present. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 03:30:40 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 22 Sep 2012 01:30:40 +0000 Subject: [issue15987] Provide a way to compare AST nodes for equality recursively In-Reply-To: <1348166637.22.0.281544835659.issue15987@psf.upfronthosting.co.za> Message-ID: <1348277440.88.0.232688214158.issue15987@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: -> test needed versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 03:40:54 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 22 Sep 2012 01:40:54 +0000 Subject: [issue15988] Inconsistency in overflow error messages of integer argument In-Reply-To: <1348167070.37.0.305629822418.issue15988@psf.upfronthosting.co.za> Message-ID: <1348278054.38.0.10454442738.issue15988@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The reason for the different messages is clear -- there are different internal tests (I presume in different functions), each of which raises its own error. What do you propose to change? The only thing I can imagine is that when the bytes converter calls the Python int to c long function, it somehow intercepts the error return and rewrites the message for consistency. Is this your proposal? ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 04:14:07 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 22 Sep 2012 02:14:07 +0000 Subject: [issue15996] pow() for complex numbers is rough around the edges In-Reply-To: <1348178428.15.0.517718755216.issue15996@psf.upfronthosting.co.za> Message-ID: <1348280047.46.0.136556768723.issue15996@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Given that >>> 1.0**float('inf'), 1.0**float('-inf') (1.0, 1.0) works, >>> (1.0+0j)**(float('inf') + 0j) Traceback ... ZeroDivisionError: 0.0 to a negative or complex power (and same for ('-inf') seems like a clear bug in raising an exception, let alone a clearly wrong exception. Clarification of murky cases, if it changes behavior, might be an enhancement. ---------- nosy: +terry.reedy stage: -> test needed versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 07:42:03 2012 From: report at bugs.python.org (Mike Hoy) Date: Sat, 22 Sep 2012 05:42:03 +0000 Subject: [issue12067] Doc: remove errors about mixed-type comparisons. In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za> Message-ID: <1348292523.33.0.542830274745.issue12067@psf.upfronthosting.co.za> Mike Hoy added the comment: I've attempted to incorporate both Terry's and Ezio's suggestions. Here is a patch to get started with. There is a section that has been deleted. Patch uploaded. ---------- keywords: +patch Added file: http://bugs.python.org/file27256/issue12067-expressions.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 08:10:57 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 22 Sep 2012 06:10:57 +0000 Subject: [issue12067] Doc: remove errors about mixed-type comparisons. In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za> Message-ID: <1348294257.65.0.353267839706.issue12067@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Some minor comments: -The operators ``<``, ``>``, ``==``, ``>=``, ``<=``, and ``!=`` compare the +``<``, ``>``, ``==``, ``>=``, ``<=``, and ``!=`` compare the values of two I think it reads better to start a sentence (and in this case a paragraph) with a word rather than a symbol. -values of two objects. The objects need not have the same type. If both are +objects. The two objects don't necessarily have to be of the same type. With The replacement sentence seems wordier to me. +(:meth:`__ge__()` reflects :meth:`__lt__()`, etcetera). Builtin numbers compare +as expected, even when of different types. Builtin sequences compare "Built-in" is hyphenated in the docs. See, for example, here: http://docs.python.org/dev/library/functions.html ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 08:44:19 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 22 Sep 2012 06:44:19 +0000 Subject: [issue15972] wrong error message for os.path.getsize In-Reply-To: <1348071122.36.0.302681706423.issue15972@psf.upfronthosting.co.za> Message-ID: <1348296259.01.0.624754715501.issue15972@psf.upfronthosting.co.za> Georg Brandl added the comment: This certainly isn't a release blocker. Check it into default, and it will go into 3.3.1. ---------- priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 08:49:26 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 22 Sep 2012 06:49:26 +0000 Subject: [issue15949] docs.python.org not getting updated In-Reply-To: <1347728419.57.0.753818975668.issue15949@psf.upfronthosting.co.za> Message-ID: <1348296566.13.0.0638859872837.issue15949@psf.upfronthosting.co.za> Georg Brandl added the comment: When the docs don't update, there's usually an error in running Sphinx. In this case, the recently committed patch for #78982 (in the Unicode howto) prevents the LaTeX build (or more exact, the pdflatex run) from completing. Please revert that part of it. (Aside: That is exactly the reason why I don't like these "make doctests run at all costs" patches.) ---------- priority: high -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 08:51:41 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 22 Sep 2012 06:51:41 +0000 Subject: [issue15759] "make suspicious" doesn't display instructions in case of failure In-Reply-To: <1345613663.78.0.519613331574.issue15759@psf.upfronthosting.co.za> Message-ID: <1348296701.51.0.186272374354.issue15759@psf.upfronthosting.co.za> Georg Brandl added the comment: The error exit code should be preserved though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 08:53:21 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 22 Sep 2012 06:53:21 +0000 Subject: [issue15882] _decimal.Decimal constructed from tuple In-Reply-To: <1347058075.63.0.395926246222.issue15882@psf.upfronthosting.co.za> Message-ID: <1348296801.74.0.42315288221.issue15882@psf.upfronthosting.co.za> Georg Brandl added the comment: Done. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 08:53:35 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 22 Sep 2012 06:53:35 +0000 Subject: [issue15895] PyRun_SimpleFileExFlags() can leak a FILE pointer In-Reply-To: <1347231050.54.0.0211027720618.issue15895@psf.upfronthosting.co.za> Message-ID: <1348296815.72.0.0404910429764.issue15895@psf.upfronthosting.co.za> Georg Brandl added the comment: Now transplanted to release clone. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 08:54:24 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 22 Sep 2012 06:54:24 +0000 Subject: [issue15973] Segmentation fault on timezone comparison In-Reply-To: <1348077797.35.0.854267629086.issue15973@psf.upfronthosting.co.za> Message-ID: <1348296864.73.0.888238537478.issue15973@psf.upfronthosting.co.za> Georg Brandl added the comment: Which commit(s) do I have to pick? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 08:56:20 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 22 Sep 2012 06:56:20 +0000 Subject: [issue15977] Memory leak in _ssl.c In-Reply-To: <1348092120.32.0.751173728211.issue15977@psf.upfronthosting.co.za> Message-ID: <1348296980.72.0.969228305306.issue15977@psf.upfronthosting.co.za> Georg Brandl added the comment: Picked. ---------- status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 09:05:40 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 22 Sep 2012 07:05:40 +0000 Subject: [issue15926] Segmentation fault after multiple reinitializations In-Reply-To: <1347419581.97.0.0354883385349.issue15926@psf.upfronthosting.co.za> Message-ID: <1348297540.38.0.00402317720002.issue15926@psf.upfronthosting.co.za> Georg Brandl added the comment: Picked as 6708224f8bee. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 09:07:01 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 22 Sep 2012 07:07:01 +0000 Subject: [issue15973] Segmentation fault on timezone comparison In-Reply-To: <1348077797.35.0.854267629086.issue15973@psf.upfronthosting.co.za> Message-ID: <1348297621.5.0.226872048589.issue15973@psf.upfronthosting.co.za> Stefan Krah added the comment: This one: 63cb0a642c84 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 09:23:21 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 22 Sep 2012 07:23:21 +0000 Subject: [issue15973] Segmentation fault on timezone comparison In-Reply-To: <1348077797.35.0.854267629086.issue15973@psf.upfronthosting.co.za> Message-ID: <1348298601.48.0.0922270806707.issue15973@psf.upfronthosting.co.za> Georg Brandl added the comment: Done as ec77f8fb9958. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 09:24:46 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 22 Sep 2012 07:24:46 +0000 Subject: [issue15900] Memory leak in PyUnicode_TranslateCharmap() In-Reply-To: <1347271102.51.0.468950657705.issue15900@psf.upfronthosting.co.za> Message-ID: <1348298686.05.0.444192360338.issue15900@psf.upfronthosting.co.za> Georg Brandl added the comment: Done as 89f62f143920. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 10:00:25 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 22 Sep 2012 08:00:25 +0000 Subject: [issue15958] bytes.join() should allow arbitrary buffer objects In-Reply-To: <1347905010.83.0.632444428638.issue15958@psf.upfronthosting.co.za> Message-ID: <1348300825.22.0.104973677648.issue15958@psf.upfronthosting.co.za> Ezio Melotti added the comment: Attached patch adds support for memoryviews to bytes.join: >>> b''.join([memoryview(b'foo'), b'bar']) b'foobar' The implementation currently has some duplication, because it does a first pass to calculate the total size to allocate, and another pass to create the result that calculates the individual sizes again. Py_SIZE(item) can't be used here for memoryviews, so during the first pass it's now necessary to check for memoryviews and extract the len from the memoryview buffer, and then do it again during the second pass. If necessary this could be optimized/improved. I also tried to check for multi-dimensional and non-contiguous buffers, but I didn't manage to obtain a failure so I removed the check for now. More tests should probably be added to cover these cases, and possibly the patch should be adjusted accordingly. If/when the patch is OK I'll do the same for bytearrays. ---------- keywords: +patch nosy: +ezio.melotti stage: needs patch -> patch review Added file: http://bugs.python.org/file27257/issue15958.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 10:17:00 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 22 Sep 2012 08:17:00 +0000 Subject: [issue12067] Doc: remove errors about mixed-type comparisons. In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za> Message-ID: <1348301820.13.0.460725268872.issue12067@psf.upfronthosting.co.za> Mark Dickinson added the comment: > I determined that 'raise TypeError' and 'return NotImplemented' both > result in the call of the reflected method Are you sure? raise TypeError *should* result in the operation being abandoned, with the reflected operation not tried. Python 3.3.0rc2+ (default:3504cbb3e1d8, Sep 20 2012, 22:08:44) [GCC 4.2.1 (Apple Inc. build 5664)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> class A: ... def __add__(self, other): ... raise TypeError("Don't know how to add") ... def __le__(self, other): ... raise TypeError("Can't compare") ... [65945 refs] >>> class B: ... def __radd__(self, other): ... return 42 ... def __ge__(self, other): ... return False ... [66016 refs] >>> A() <= B() Traceback (most recent call last): File "", line 1, in File "", line 5, in __le__ TypeError: Can't compare [66064 refs] >>> A() + B() Traceback (most recent call last): File "", line 1, in File "", line 3, in __add__ TypeError: Don't know how to add [66065 refs] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 10:19:26 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 22 Sep 2012 08:19:26 +0000 Subject: [issue15949] docs.python.org not getting updated In-Reply-To: <1347728419.57.0.753818975668.issue15949@psf.upfronthosting.co.za> Message-ID: <1348301966.93.0.781063757166.issue15949@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I think the issue was #15899, and the change 8a40bc71c072. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 10:20:02 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 22 Sep 2012 08:20:02 +0000 Subject: [issue15949] docs.python.org not getting updated In-Reply-To: <1347728419.57.0.753818975668.issue15949@psf.upfronthosting.co.za> Message-ID: <1348302002.47.0.479989912578.issue15949@psf.upfronthosting.co.za> Ezio Melotti added the comment: I'm working on it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 10:25:41 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 22 Sep 2012 08:25:41 +0000 Subject: [issue15949] docs.python.org not getting updated In-Reply-To: <1347728419.57.0.753818975668.issue15949@psf.upfronthosting.co.za> Message-ID: <3XP4W835DmzQmF@mail.python.org> Roundup Robot added the comment: New changeset 0799fd1f8887 by Ezio Melotti in branch '3.2': #15949, 15899: avoid using non-latin1 chars in the doc (they break `make all-pdf`). http://hg.python.org/cpython/rev/0799fd1f8887 New changeset 832999a97e59 by Ezio Melotti in branch 'default': #15949, 15899: merge with 3.2. http://hg.python.org/cpython/rev/832999a97e59 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 10:28:48 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 22 Sep 2012 08:28:48 +0000 Subject: [issue15949] docs.python.org not getting updated In-Reply-To: <1347728419.57.0.753818975668.issue15949@psf.upfronthosting.co.za> Message-ID: <1348302528.89.0.996991216853.issue15949@psf.upfronthosting.co.za> Ezio Melotti added the comment: This should be fixed now. It would be nice if Sphinx could send a notification mail in case of failure, so that the next time we will notice and fix the problem earlier. ---------- assignee: docs at python -> ezio.melotti resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 10:32:17 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 22 Sep 2012 08:32:17 +0000 Subject: [issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails In-Reply-To: <1348173110.08.0.356112095586.issue15993@psf.upfronthosting.co.za> Message-ID: <1348302737.57.0.729142629575.issue15993@psf.upfronthosting.co.za> Stefan Krah added the comment: System: Windows 7 64-bit Build (unpatched): PCBuild\Win32-pgo\python.exe, trained with profile.bat In the unpatched version, I stepped through this test case in the debugger: import array a = array.array('Q', [1]) m = memoryview(a) m[0] = 1 At Objects/memoryobject.c:1572: llu == 1 At Objects/memoryobject.c:1782: pylong_as_llu returned value 4294967296 So I think it's pretty safe to say that this is indeed an optimizer bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 10:34:13 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 22 Sep 2012 08:34:13 +0000 Subject: [issue10044] small int optimization In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za> Message-ID: <1348302853.19.0.0492573137518.issue10044@psf.upfronthosting.co.za> Mark Dickinson added the comment: Victor: so you want to *deliberately* introduce undefined behaviour for the sake of a minor optimization, while crossing your fingers and *hoping* that that doesn't cause issues with any existing or future compilers? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 10:38:32 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 22 Sep 2012 08:38:32 +0000 Subject: [issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails In-Reply-To: <1348302737.57.0.729142629575.issue15993@psf.upfronthosting.co.za> Message-ID: <20120922083832.GA2611@sleipnir.bytereef.org> Stefan Krah added the comment: Sorry, the line numbers are messed up. They should be: Objects/memoryobject.c:1569 Objects/memoryobject.c:1776 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 10:51:46 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 22 Sep 2012 08:51:46 +0000 Subject: [issue15958] bytes.join() should allow arbitrary buffer objects In-Reply-To: <1347905010.83.0.632444428638.issue15958@psf.upfronthosting.co.za> Message-ID: <1348303906.44.0.52149280514.issue15958@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think memoryview here is example only, and Antoine had in mind arbitrary buffer objects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 11:05:16 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sat, 22 Sep 2012 09:05:16 +0000 Subject: [issue2281] Enhanced cPython profiler with high-resolution timer In-Reply-To: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za> Message-ID: <1348304716.11.0.557467279133.issue2281@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: >There is another major issue: you have to synchronize the counter of all >CPU cores. Windows XP didn't synchronize the counters, and it was a major >issue on QueryPerformanceCounter. >http://support.microsoft.com/?id=896256 I don't understand why you keep bashing Windows for this. It was actually a problem with CPU drivers. We encountered this problem for a number of our players and the fix was to get the latest intel/amd drivers. The issue you quote is a separate one. This appears to be the correct one: http://support.microsoft.com/kb/895980 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 11:13:56 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 22 Sep 2012 09:13:56 +0000 Subject: [issue15958] bytes.join() should allow arbitrary buffer objects In-Reply-To: <1347905010.83.0.632444428638.issue15958@psf.upfronthosting.co.za> Message-ID: <1348305236.58.0.624117786936.issue15958@psf.upfronthosting.co.za> Ezio Melotti added the comment: Indeed. Attached new patch. Tests still need to be improved; bytearrays are still not changed. ---------- Added file: http://bugs.python.org/file27258/issue15958-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 11:16:43 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 22 Sep 2012 09:16:43 +0000 Subject: [issue10044] small int optimization In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za> Message-ID: <1348305402.99.0.273207589774.issue10044@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Victor, the danger of this approach is that we can't verify that a particular compiler with certain options on a specific platform compiles the source code with undefined behavior in a certain way. If such a test were possible, if this aspect was guaranteed by the compiler manufacturer, or could be checked in the ./configure script, then such an approach would have some meaning. Regardless of _PyLong_IS_SMALL_INT, the rest of patch looks a little cumbersome. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 11:35:33 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 22 Sep 2012 09:35:33 +0000 Subject: [issue15958] bytes.join() should allow arbitrary buffer objects In-Reply-To: <1347905010.83.0.632444428638.issue15958@psf.upfronthosting.co.za> Message-ID: <1348306533.58.0.225470216912.issue15958@psf.upfronthosting.co.za> Stefan Krah added the comment: We would need to release the buffers and also check for format 'B'. With issue15958-2.diff this is possible: >>> import array >>> a = array.array('d', [1.2345]) >>> b''.join([b'ABC', a]) b'ABC\x8d\x97n\x12\x83\xc0\xf3?' It is unfortunate that a PyBUF_SIMPLE request does not guarantee 'B'. I think that's probably a mistake, but it's certainly existing practice. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 11:42:59 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 22 Sep 2012 09:42:59 +0000 Subject: [issue15988] Inconsistency in overflow error messages of integer argument In-Reply-To: <1348167070.37.0.305629822418.issue15988@psf.upfronthosting.co.za> Message-ID: <1348306979.28.0.422731687213.issue15988@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: 1) Use PyLong_AsLongAndOverflow instead PyLong_AsLong in PyArg_ParseTuple and in some other functions. 2) Unify an integer overflow error messages in different functions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 11:43:04 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 22 Sep 2012 09:43:04 +0000 Subject: [issue15958] bytes.join() should allow arbitrary buffer objects In-Reply-To: <1347905010.83.0.632444428638.issue15958@psf.upfronthosting.co.za> Message-ID: <1348306984.44.0.87601660609.issue15958@psf.upfronthosting.co.za> Stefan Krah added the comment: Also, perhaps we can keep a fast path for bytes and bytearray, but I didn't time the difference. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 12:01:00 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 22 Sep 2012 10:01:00 +0000 Subject: [issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails In-Reply-To: <1348173110.08.0.356112095586.issue15993@psf.upfronthosting.co.za> Message-ID: <1348308060.08.0.227371530291.issue15993@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Unfortunately (?) I now cannot produce this myself, anymore, either. Given all the problems, I'll stop using PGO on all branches and targets, as the compiler apparently generates bad code. Anybody curious to investigate the issue further who is able to reproduce it might want to look at the generated machine code, to find out where exactly the incorrect processing happens. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 12:01:07 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 22 Sep 2012 10:01:07 +0000 Subject: [issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails In-Reply-To: <1348173110.08.0.356112095586.issue15993@psf.upfronthosting.co.za> Message-ID: <1348308067.33.0.778137456296.issue15993@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 12:21:42 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 22 Sep 2012 10:21:42 +0000 Subject: [issue15958] bytes.join() should allow arbitrary buffer objects In-Reply-To: <1347905010.83.0.632444428638.issue15958@psf.upfronthosting.co.za> Message-ID: <1348309302.84.0.142602486395.issue15958@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, given the following works: >>> import array >>> a = array.array('d', [1.2345]) >>> b'' + a b'\x8d\x97n\x12\x83\xc0\xf3?' It should also work for bytes.join(). I guess that means I'm against the strict-typedness of memoryviews. As the name suggests, it provides access to some memory area, not some structured array of data. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 12:25:20 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 22 Sep 2012 10:25:20 +0000 Subject: [issue15958] bytes.join() should allow arbitrary buffer objects In-Reply-To: <1347905010.83.0.632444428638.issue15958@psf.upfronthosting.co.za> Message-ID: <1348309520.61.0.174939526797.issue15958@psf.upfronthosting.co.za> Ezio Melotti added the comment: Attached new refleakless patch. ---------- Added file: http://bugs.python.org/file27259/issue15958-3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 12:31:10 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 22 Sep 2012 10:31:10 +0000 Subject: [issue15958] bytes.join() should allow arbitrary buffer objects In-Reply-To: <1348309520.61.0.174939526797.issue15958@psf.upfronthosting.co.za> Message-ID: <1348309826.3392.1.camel@localhost.localdomain> Antoine Pitrou added the comment: > Attached new refleakless patch. Your approach is dangerous, because the buffers may change size between two calls to PyObject_GetBuffer(). I think you should keep the Py_buffers alive in an array, and only release them at the end (it may also be slightly faster to do so). A nit: you are adding a lot of newlines in test_bytes.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 13:09:29 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 22 Sep 2012 11:09:29 +0000 Subject: [issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails In-Reply-To: <1348173110.08.0.356112095586.issue15993@psf.upfronthosting.co.za> Message-ID: <1348312169.14.0.11436421539.issue15993@psf.upfronthosting.co.za> Stefan Krah added the comment: > Given all the problems, I'll stop using PGO on all branches and > as the compiler apparently generates bad code. That is probably the best solution. The problem in memoryview.c:pack_single() is that Visual Studio optimizes the memcpy() to mov instructions, but exchanges the low and high dwords: unsigned __int64 llu = 1; do { unsigned __int64 x; x = (unsigned __int64)llu; // At this point x=llu is in edx=1 and ecx=0. // The memcpy() is optimized to: // mov dword ptr [esi], ecx // mov dword ptr [esi+4], edx memcpy(ptr, (char *)&x, sizeof x); } while (0); ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 13:14:12 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 22 Sep 2012 11:14:12 +0000 Subject: [issue15949] docs.python.org not getting updated In-Reply-To: <1347728419.57.0.753818975668.issue15949@psf.upfronthosting.co.za> Message-ID: <1348312452.76.0.0722270103331.issue15949@psf.upfronthosting.co.za> Georg Brandl added the comment: I usually get the result of the cronjob via email if there's a failure; for a few weeks now this went to my spam folder, so I didn't immediately see something was wrong. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 13:11:12 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 22 Sep 2012 11:11:12 +0000 Subject: [issue10044] small int optimization In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za> Message-ID: <1348312272.02.0.520132325248.issue10044@psf.upfronthosting.co.za> Martin v. L?wis added the comment: > "x+1 > x" and "v >= &array[0]" are not the same checks. > In the first test, x is used in both parts. I don't understand. The consequences of "undefined behavior" are really difficult to understand, it seems. A compiler which evaluates both relational expressions unconditionally to true would be conforming to the C language definition. The reason for that has been said several times before, but let me repeat them. Mathematically, x+1 > x for any real number, so it seems natural to assume that this can be determined to be "true" statically. However, what if x+1 overflows? Shouldn't then it evaluate to "false"? Not necessarily if x is signed. Then the behavior of overflow is undefined, and *any* result of the comparison would be conforming to the standard: the overflow may trap, the expression may evaluate to "false", or the expression may evaluate to "true", or your hard disk may get erased - all of these would be conforming to the C language definition. For v >= &array[0], this is the same issue. If v points into the array, the expression is true. If v doesn't point into the array, the behavior is undefined, so the compiler may chose to give false, or to give true, or to actually compare the pointers as integers, or to erase your hard disk. Of these possible behaviors, only two are plausible. For x+1>x, it may be that the compiler actually generates code to perform the addition and the comparison, or it may statically decide that the expression is always true. For v > &array[0], the compiler may either generate code to perform the comparison, or statically decide that the expression is true. Either implementation would be correct - it's not that the compiler is optimizing "incorrectly". In the specific case, a compiler might infer that _PyLong_IS_SMALL_INT is always true, which would give incorrect results in Python. However, it is the patch which is incorrect, not the compiler. I recommend to close the issue as rejected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 13:48:54 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 22 Sep 2012 11:48:54 +0000 Subject: [issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails In-Reply-To: <1348173110.08.0.356112095586.issue15993@psf.upfronthosting.co.za> Message-ID: <1348314534.25.0.672079874216.issue15993@psf.upfronthosting.co.za> Martin v. L?wis added the comment: It's interesting that the compiler uses ecx:edx to represent a __int64 quantity when 64-bit registers are available... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 14:00:07 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 22 Sep 2012 12:00:07 +0000 Subject: [issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails In-Reply-To: <1348314534.25.0.672079874216.issue15993@psf.upfronthosting.co.za> Message-ID: <20120922120007.GA4721@sleipnir.bytereef.org> Stefan Krah added the comment: Hmm, the bug is in the 32-bit build. The 64-bit build is fine. Or do you mean MMX registers? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 14:54:24 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 22 Sep 2012 12:54:24 +0000 Subject: [issue15949] docs.python.org not getting updated In-Reply-To: <1347728419.57.0.753818975668.issue15949@psf.upfronthosting.co.za> Message-ID: <1348318464.79.0.384519736744.issue15949@psf.upfronthosting.co.za> Chris Jerdonek added the comment: In the future, now that a few more people know, we could always look to see what doc changes were made since the last "publication" of the docs (or run the other `make` commands locally, or ideally, beforehand in cases that warrant it). The fact that 2.7 published and not the others should have been a tip off for me. I wonder if `make patchcheck` could be enhanced to check for unsupported characters. Lastly, is there a work-around for the inability to include ? in the docs? That particular difference between u.encode('replace') and bytes.decode('replace') (? vs. ?) seems like an important one to me not to conflate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 15:09:06 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 22 Sep 2012 13:09:06 +0000 Subject: [issue15964] SyntaxError in asdl when building 2.7 with system Python 3 In-Reply-To: <1347978379.29.0.810502621141.issue15964@psf.upfronthosting.co.za> Message-ID: <1348319346.09.0.0279194666743.issue15964@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attaching patch. I started a new section in the FAQ called "Build Troubleshooting" which is something Nick suggested in the context of addressing this issue. I'm sure we could add a couple more questions to this section right now if we wanted to. ---------- keywords: +patch Added file: http://bugs.python.org/file27260/issue-15964-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 15:12:27 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 22 Sep 2012 13:12:27 +0000 Subject: [issue15964] SyntaxError in asdl when building 2.7 with system Python 3 In-Reply-To: <1347978379.29.0.810502621141.issue15964@psf.upfronthosting.co.za> Message-ID: <1348319547.49.0.576458812874.issue15964@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Adding Nick because he is the one that suggested adding a "Build Troubleshooting" section to the devguide FAQ (meant to add him above). ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 15:18:10 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 22 Sep 2012 13:18:10 +0000 Subject: [issue15949] docs.python.org not getting updated In-Reply-To: <1347728419.57.0.753818975668.issue15949@psf.upfronthosting.co.za> Message-ID: <1348319890.32.0.768750922323.issue15949@psf.upfronthosting.co.za> Ezio Melotti added the comment: > I usually get the result of the cronjob via email if there's a failure; Maybe it should go to python-committers or some other public ML, so that other devs can see and possibly fix the issue. > I wonder if `make patchcheck` could be enhanced to check > for unsupported characters. That sounds like a good idea to me. > Lastly, is there a work-around for the inability to include ? > in the docs? '\ufffdabc' is acceptable, and it is what non-utf-8 terminals print. > That particular difference between u.encode('replace') and > bytes.decode('replace') (? vs. ?) seems like an important > one to me not to conflate. Indeed I was confusing the two. I'm not actually even sure that the Unicode standard mandates these specific replacement characters (IIRC there's even a way to configure them), and I was under the impression that '?' was sometimes used during the decoding, but after a few tests it seems I was wrong. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 15:25:03 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 22 Sep 2012 13:25:03 +0000 Subject: [issue15949] docs.python.org not getting updated In-Reply-To: <1347728419.57.0.753818975668.issue15949@psf.upfronthosting.co.za> Message-ID: <1348320303.2.0.58095555554.issue15949@psf.upfronthosting.co.za> Chris Jerdonek added the comment: The distinction between ? vs. ? for encode() and decode() is in the Python docs, but it's not prominent. It's mentioned in codecs's "Codec Base Classes" but not in the encode() and decode() docs themselves: http://docs.python.org/dev/library/codecs.html#codec-base-classes ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 15:35:18 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 22 Sep 2012 13:35:18 +0000 Subject: [issue15949] docs.python.org not getting updated In-Reply-To: <1347728419.57.0.753818975668.issue15949@psf.upfronthosting.co.za> Message-ID: <1348320918.83.0.29772122442.issue15949@psf.upfronthosting.co.za> Ezio Melotti added the comment: > The distinction between ? vs. ? for encode() and decode() > is in the Python docs, but it's not prominent. The point is that I'm not even sure we make any guarantees about the replacement characters that we use. I should check again what the Unicode standard says -- IIRC ? was suggested, but it wasn't mandatory. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 15:39:20 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 22 Sep 2012 13:39:20 +0000 Subject: [issue16000] test_curses should use unittest In-Reply-To: <1348263086.74.0.172285441847.issue16000@psf.upfronthosting.co.za> Message-ID: <1348321160.26.0.628233075943.issue16000@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 15:57:29 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 22 Sep 2012 13:57:29 +0000 Subject: [issue15978] asyncore: included batteries don't fit In-Reply-To: <1348109984.23.0.963898980799.issue15978@psf.upfronthosting.co.za> Message-ID: <1348322249.56.0.441958280537.issue15978@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 16:02:28 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 22 Sep 2012 14:02:28 +0000 Subject: [issue15925] email.utils.parsedate() and email.utils.parsedate_tz() should return None when date cannot be parsed In-Reply-To: <1347410265.94.0.383870526813.issue15925@psf.upfronthosting.co.za> Message-ID: <3XPCxs143VzQkc@mail.python.org> Roundup Robot added the comment: New changeset 3b03d31f6a79 by R David Murray in branch 'default': #15925: fix regression: return None for null and non-date strings. http://hg.python.org/cpython/rev/3b03d31f6a79 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 16:04:59 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 22 Sep 2012 14:04:59 +0000 Subject: [issue15925] email.utils.parsedate() and email.utils.parsedate_tz() should return None when date cannot be parsed In-Reply-To: <1347410265.94.0.383870526813.issue15925@psf.upfronthosting.co.za> Message-ID: <1348322699.16.0.853441796129.issue15925@psf.upfronthosting.co.za> R. David Murray added the comment: I don't think it is worth the extra code to convert the TypeError into a ValueError. We aren't very strict about the distinction between those two. Leaving this open for Georg to transplant it to 3.3.0. ---------- assignee: -> georg.brandl resolution: -> fixed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 16:06:17 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 22 Sep 2012 14:06:17 +0000 Subject: [issue15952] format(value) and value.__format__() behave differently with unicode format In-Reply-To: <1347825591.49.0.625826586182.issue15952@psf.upfronthosting.co.za> Message-ID: <1348322777.12.0.254046687565.issue15952@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 16:07:58 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 22 Sep 2012 14:07:58 +0000 Subject: [issue15951] string.Formatter returns str for empty unicode template In-Reply-To: <1347796556.49.0.9624827569.issue15951@psf.upfronthosting.co.za> Message-ID: <1348322878.93.0.459763046651.issue15951@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 16:09:37 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 22 Sep 2012 14:09:37 +0000 Subject: [issue15935] clarify argparse docs re: add_argument() type and default arguments In-Reply-To: <1347485175.79.0.860808168134.issue15935@psf.upfronthosting.co.za> Message-ID: <1348322976.99.0.126208718423.issue15935@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 16:11:25 2012 From: report at bugs.python.org (Larry Hastings) Date: Sat, 22 Sep 2012 14:11:25 +0000 Subject: [issue10044] small int optimization In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za> Message-ID: <1348323085.71.0.969906710557.issue10044@psf.upfronthosting.co.za> Larry Hastings added the comment: I must be missing something--because I thought Python *already* depended on this apparently-undefined behavior. The small-block object allocator in Objects/obmalloc.c determines whether a pointer belongs to a particular arena using exactly this trick. I quote from the gigantic comment at the top of that file: Let B be the arena base address associated with the pool, B = arenas[(POOL)->arenaindex].address. Then P belongs to the arena if and only if B <= P < B + ARENA_SIZE Subtracting B throughout, this is true iff 0 <= P-B < ARENA_SIZE This test is implemented as the following macro: #define Py_ADDRESS_IN_RANGE(P, POOL) \ ((arenaindex_temp = (POOL)->arenaindex) < maxarenas && \ (uptr)(P) - arenas[arenaindex_temp].address < (uptr)ARENA_SIZE && \ arenas[arenaindex_temp].address != 0) Why is that permissible but _PyLong_IS_SMALL_INT is not? ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 16:27:22 2012 From: report at bugs.python.org (Drekin) Date: Sat, 22 Sep 2012 14:27:22 +0000 Subject: [issue1602] windows console doesn't print or input Unicode In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za> Message-ID: <1348324042.0.0.228490922136.issue1602@psf.upfronthosting.co.za> Drekin added the comment: I have finished a solution working for me. It bypasses standard Python interactive interpreter and uses its own repl based on code.interact(). This repl is activated by an ugly hack since PYTHONSTARTUP doesn't apply when some file is run (python -i somefile.py). Why it works like that? Startup script could find out if a file is run or not. If anybody knows how to get rid of time.sleep() used for wait for KeyboardInterrupt or how to get rid of PromptHack, please let me know. The "patch" can be activated by win_unicode_console_2.enable(change_console=True, use_hack=True) in site or sitecustomize or usercustomize. ---------- Added file: http://bugs.python.org/file27261/win_unicode_console_2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 16:46:03 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 22 Sep 2012 14:46:03 +0000 Subject: [issue15987] Provide a way to compare AST nodes for equality recursively In-Reply-To: <1348166637.22.0.281544835659.issue15987@psf.upfronthosting.co.za> Message-ID: <1348325163.63.0.306494843284.issue15987@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Yes, though some things like what to return if one has an entire subtree that the other doesn't have will have to be worked out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 17:20:26 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 22 Sep 2012 15:20:26 +0000 Subject: [issue15964] SyntaxError in asdl when building 2.7 with system Python 3 In-Reply-To: <1347978379.29.0.810502621141.issue15964@psf.upfronthosting.co.za> Message-ID: <1348327226.39.0.989913155839.issue15964@psf.upfronthosting.co.za> Nick Coghlan added the comment: We should be able to add the "make touch" target to the 2.7 Makefile without running afoul of the "no new features" rule. However, agreed this is mostly a docs problem. We're seeing a couple of common traps that people run into when first getting started, so it will be good to get answers up somewhere where people are likely to look (and where search engines will be able to see the error messages). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 17:35:39 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 22 Sep 2012 15:35:39 +0000 Subject: [issue15925] email.utils.parsedate() and email.utils.parsedate_tz() should return None when date cannot be parsed In-Reply-To: <1347410265.94.0.383870526813.issue15925@psf.upfronthosting.co.za> Message-ID: <1348328139.3.0.907158829858.issue15925@psf.upfronthosting.co.za> Georg Brandl added the comment: This was committed to the release clone as c1e9a1fc6931. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 17:35:54 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 22 Sep 2012 15:35:54 +0000 Subject: [issue15925] email.utils.parsedate() and email.utils.parsedate_tz() should return None when date cannot be parsed In-Reply-To: <1347410265.94.0.383870526813.issue15925@psf.upfronthosting.co.za> Message-ID: <1348328154.36.0.170483920742.issue15925@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 17:36:34 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 22 Sep 2012 15:36:34 +0000 Subject: [issue15969] faulthandler: drop S from dump_tracebacks_later() function name to have consistent names In-Reply-To: <1348001825.94.0.454810241369.issue15969@psf.upfronthosting.co.za> Message-ID: <1348328194.21.0.0645933678666.issue15969@psf.upfronthosting.co.za> Georg Brandl added the comment: Added to release clone as eede0bf3ceac. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 18:00:28 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 22 Sep 2012 16:00:28 +0000 Subject: [issue10044] small int optimization In-Reply-To: <1348323085.71.0.969906710557.issue10044@psf.upfronthosting.co.za> Message-ID: <201209221858.10922.storchaka@gmail.com> Serhiy Storchaka added the comment: > Why is that permissible but _PyLong_IS_SMALL_INT is not? Touch?r! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 18:30:33 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 22 Sep 2012 16:30:33 +0000 Subject: [issue10044] small int optimization In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za> Message-ID: <1348331433.38.0.56822496791.issue10044@psf.upfronthosting.co.za> Mark Dickinson added the comment: Ah: nice catch, Larry. I would say that the obmalloc case *shouldn't* be permissible; however, it's already there, and changing that would be an involved task that would also likely risk introducing new bugs. So I guess practicality beats purity on that one. I don't see that as an excuse for introducing *new* undefined behaviour though, especially for a small optimization. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 18:47:56 2012 From: report at bugs.python.org (chrysn) Date: Sat, 22 Sep 2012 16:47:56 +0000 Subject: [issue15978] asyncore: included batteries don't fit In-Reply-To: <1348109984.23.0.963898980799.issue15978@psf.upfronthosting.co.za> Message-ID: <1348332476.13.0.882716949542.issue15978@psf.upfronthosting.co.za> chrysn added the comment: i've redirected my request to python-ideas as suggested. for future reference, my email can be found at http://mail.python.org/pipermail/python-ideas/2012-September/016185.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 18:51:10 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 22 Sep 2012 16:51:10 +0000 Subject: [issue10044] small int optimization In-Reply-To: <1348312272.02.0.520132325248.issue10044@psf.upfronthosting.co.za> Message-ID: <201209221950.56855.storchaka@gmail.com> Serhiy Storchaka added the comment: > I recommend to close the issue as rejected. I think _PyLong_IS_SMALL_INT can be rewritten in a safe style. For example, using a checking of several fields ((sdigit)(x)->ob_digit[0] < _MAX_SMALL_INT && PySIZE(x) <= 1) or a special flag. It is possible however that shuch checking will fully destroy the effect of optimization. We need further research. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 19:08:59 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 22 Sep 2012 17:08:59 +0000 Subject: [issue15958] bytes.join() should allow arbitrary buffer objects In-Reply-To: <1348309826.3392.1.camel@localhost.localdomain> Message-ID: <201209222008.45883.storchaka@gmail.com> Serhiy Storchaka added the comment: > I think you should keep the > Py_buffers alive in an array, and only release them at the end (it may > also be slightly faster to do so). However allocation of this array may considerably slow down the function. We may need the special-case for bytes and bytearray. Stop, and the bytearray (or bytearray subclass) can change size between two calls to Py_SIZE()? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 19:09:01 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 22 Sep 2012 17:09:01 +0000 Subject: [issue15996] pow() for complex numbers is rough around the edges In-Reply-To: <1348178428.15.0.517718755216.issue15996@psf.upfronthosting.co.za> Message-ID: <1348333741.13.0.583109041948.issue15996@psf.upfronthosting.co.za> Mark Dickinson added the comment: > (1.0+0j)**(float('inf') + 0j) Oddly enough, this is nan+nanj on OS X. I haven't investigated what the difference is due to---probably something to do with the errno results. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 19:56:23 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 22 Sep 2012 17:56:23 +0000 Subject: [issue9720] zipfile writes incorrect local file header for large files in zip64 In-Reply-To: <1347975870.76.0.932550727049.issue9720@psf.upfronthosting.co.za> Message-ID: <201209222056.07175.storchaka@gmail.com> Serhiy Storchaka added the comment: No, on the contrary, it is not such easy to fix, and the patch is incorrect. Sorry that it is not clear either. The size of the header with extra args depends on the size of the file. The file size can be changed in the process of compressing, and compressed size may be larger than uncompressed size, exceeding 32-bit boundary. Rewriting the header with extra args, we can overwrite compressed data. I was put off the issue for further more careful research. Thanks for the reminder. One solution is always (even for smallest files) to write 64-bit sizes when allowZip64 is true. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 20:32:05 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 22 Sep 2012 18:32:05 +0000 Subject: [issue15276] unicode format does not really work in Python 2.x In-Reply-To: <1341668447.61.0.319523039673.issue15276@psf.upfronthosting.co.za> Message-ID: <1348338725.2.0.469059919896.issue15276@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I have a brief documentation patch in mind for this, but it relies on documentation issue 15952 being addressed first (e.g. to say that format(value) returns Unicode when format_spec is Unicode and that value.__format__() can return a string of type str). So I'm marking issue 15952 as a dependency. ---------- dependencies: +format(value) and value.__format__() behave differently with unicode format _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 22 23:01:57 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 22 Sep 2012 21:01:57 +0000 Subject: [issue12067] Doc: remove errors about mixed-type comparisons. In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za> Message-ID: <1348347717.78.0.377914197908.issue12067@psf.upfronthosting.co.za> Terry J. Reedy added the comment: You are right, I did not look deep enough. I was fooled by the conversion of NotImplemented, returned from object.__le__, etc, to TypeError. Sorry for that noise. For comparison and arithmetic, the actual alternative to defining a function that returns NotImplemented seems to be to not define it at all. class C(): def __ge__(self, other): return True def __add__(self, other): return 44 __radd__ = __add__ class O(): pass # removed NotImplemented defs c = C() o = O() print(c >= o, o <= c) # True True print(c + o, o + c) # 44 44 (I looked at the codes for binary_op1 in abstract.c and do_richcompare in object.c and do not yet see any effective difference between not defined and a NotImplemented return.) I'll take a look at the patch later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 00:16:57 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 22 Sep 2012 22:16:57 +0000 Subject: [issue16002] AIX buildbot compile errors Message-ID: <1348352217.78.0.0013472169184.issue16002@psf.upfronthosting.co.za> New submission from Stefan Krah: According to issue #9799 configuring --without-computed-gotos might solve the AIX compile error. ---------- components: Build keywords: buildbot messages: 171013 nosy: skrah, trent priority: normal severity: normal status: open title: AIX buildbot compile errors type: compile error versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 00:42:56 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 22 Sep 2012 22:42:56 +0000 Subject: [issue10044] small int optimization In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za> Message-ID: <1348353776.09.0.392344328236.issue10044@psf.upfronthosting.co.za> Martin v. L?wis added the comment: > Why is that permissible but _PyLong_IS_SMALL_INT is not? It's *permissable* primarily because it is there. There are many places in Python which invoke undefined behavior already (most notably wrt. signed integers); we should strive to eliminate them. OTOH, obmalloc clearly makes a lot of assumptions on the hardware architecture (including the assumption that there is page-based virtual memory, etc). It's a memory allocator, that gives permission to make such assumptions. If it turns out that they break on some system, obmalloc cannot be used there - hence usage of obmalloc is still a compile-time option. In addition, for the specific macros: it's easy to see that a compiler may optimize _PyLong_IS_SMALL_INT as true by simple static analysis. For Py_ADDRESS_IN_RANGE, the same static analysis is not possible, since the memory doesn't come from a declared array. It would require whole-program analysis to determine that .address always points to a memory block with ARENA_SIZE bytes. If a compiler manages to figure it out, obmalloc cannot be used on that system (and if that happens, I'll recommend to drop or revise obmalloc altogether, perhaps in favor of a system pool allocator). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 00:44:41 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 22 Sep 2012 22:44:41 +0000 Subject: [issue15997] NotImplemented needs to be documented In-Reply-To: <1348206637.53.0.485410334327.issue15997@psf.upfronthosting.co.za> Message-ID: <1348353881.43.0.242902847995.issue15997@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I was wrong about TypeError; forget that. The seeming equivalent to 'return NotImplement' is not defining the method. My confusion stemed from the fact that NotImplemented returned from special methods gets intercepted and converted to TypeError exceptions by the operator functions that call them -- unless there is an alternate path *and* the alternate does not also return NotImplemented. Changing "will try reflected operation" to "will return the result of the reflected operation called on the swapped arguments" is wrong as the latter is not completely correct. If the fallback also returns NotImplemented, it is ignored and TypeError is raised the same as if the fallback did not exist. But as Martin said, the details belong in operator documentation. I would like to more closely parallel the None entry, which has "It is used to signify the absence of a value in many situations, e.g. it is returned from functions that don?t explicitly return anything." by replacing "Numeric methods and rich comparison methods may return this value if they do not implement the operation for the operands provided. (The interpreter will then try the reflected operation, or some other fallback, depending on the operator.)" with "It is used to signify that a method does not implement the operation requested for the operands provided. For example, the special methods for arithmetic and and rich comparison may return NotImplemented, and when they do, the interpreter will try the reversed or reflected operation." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 00:44:45 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 22 Sep 2012 22:44:45 +0000 Subject: [issue10044] small int optimization In-Reply-To: <201209221950.56855.storchaka@gmail.com> Message-ID: <20120923004444.Horde.NxBbTcL8999QXj9cHmuCiqA@webmail.df.eu> Martin v. L?wis added the comment: Zitat von Serhiy Storchaka : >> I recommend to close the issue as rejected. > > I think _PyLong_IS_SMALL_INT can be rewritten in a safe style. For > example, using a checking of several fields > ((sdigit)(x)->ob_digit[0] < _MAX_SMALL_INT && PySIZE(x) <= 1) or a > special flag. It is possible however that shuch checking will fully > destroy the effect of optimization. We need further research. Do we need to keep this issue open while this research is being carried out? This issue is already cluttered with the undefined-behavior discussion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 10:34:06 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sun, 23 Sep 2012 08:34:06 +0000 Subject: [issue16003] thread_PyThread_start_new_thread fails with a generic error Message-ID: <1348389246.53.0.0663792895343.issue16003@psf.upfronthosting.co.za> New submission from Kristj?n Valur J?nsson: If thread creation fails, for any reason, a ThreadError is returned with the error "can't start new thread". No attempt is made to diagnose the issue. In fact, for example, if we are out of resources, pthread_new() would have returned EAGAIN. This should perhaps rather be classified as an OSError so that users can catch this and diagnose it. ThreadError seems to be used otherwise exclusively to indicate problems with locking. Can this be turned into an informative OSError, or is it to platform dependant for any sensible structured error handlng to be implemented? ---------- messages: 171017 nosy: kristjan.jonsson priority: normal severity: normal status: open title: thread_PyThread_start_new_thread fails with a generic error type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 10:55:14 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 23 Sep 2012 08:55:14 +0000 Subject: [issue15964] SyntaxError in asdl when building 2.7 with system Python 3 In-Reply-To: <1347978379.29.0.810502621141.issue15964@psf.upfronthosting.co.za> Message-ID: <1348390514.76.0.659653092314.issue15964@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > We should be able to add the "make touch" target to the 2.7 Makefile without running afoul of the "no new features" rule. To keep things simpler, I'm going to create a separate issue for this so that it can be discussed and committed independently of this doc-only issue. If necessary, we can always modify the answers to existing FAQ's in that issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 11:04:35 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 23 Sep 2012 09:04:35 +0000 Subject: [issue16004] Add `make touch` to 2.7 Makefile Message-ID: <1348391075.72.0.200262721096.issue16004@psf.upfronthosting.co.za> New submission from Chris Jerdonek: This issue is to add "make touch" to the 2.7 Makefile as suggested by Nick Coghlan in the following comment to issue 15964: "We should be able to add the "make touch" target to the 2.7 Makefile without running afoul of the "no new features" rule." (from http://bugs.python.org/issue15964#msg171001 ) This will make it easier to help people address certain build errors encountered when switching between 2.7 and 3.x branches. ---------- components: Build messages: 171019 nosy: cjerdonek, ncoghlan priority: normal severity: normal status: open title: Add `make touch` to 2.7 Makefile versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 11:05:58 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 23 Sep 2012 09:05:58 +0000 Subject: [issue15964] SyntaxError in asdl when building 2.7 with system Python 3 In-Reply-To: <1347978379.29.0.810502621141.issue15964@psf.upfronthosting.co.za> Message-ID: <1348391158.21.0.885420261352.issue15964@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > We should be able to add the "make touch" target to the 2.7 Makefile without running afoul of the "no new features" rule. I created issue 16004 for this: http://bugs.python.org/issue16004 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 11:12:45 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 23 Sep 2012 09:12:45 +0000 Subject: [issue16004] Add `make touch` to 2.7 Makefile In-Reply-To: <1348391075.72.0.200262721096.issue16004@psf.upfronthosting.co.za> Message-ID: <1348391565.01.0.607248367612.issue16004@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: -> needs patch type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 11:13:21 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 23 Sep 2012 09:13:21 +0000 Subject: [issue5969] setup build with Platform SDK, finding vcvarsall.bat In-Reply-To: <1241791427.1.0.931613951559.issue5969@psf.upfronthosting.co.za> Message-ID: <3XPjWh0BGYzQwc@mail.python.org> Roundup Robot added the comment: New changeset abf23c22231e by Victor Stinner in branch 'default': Issue #5969: faulthandler module: rename dump_tracebacks_later() to http://hg.python.org/cpython/rev/abf23c22231e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 11:15:22 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 23 Sep 2012 09:15:22 +0000 Subject: [issue15969] faulthandler: drop S from dump_tracebacks_later() function name to have consistent names In-Reply-To: <1348001825.94.0.454810241369.issue15969@psf.upfronthosting.co.za> Message-ID: <3XPjZ14tKhzQwc@mail.python.org> Roundup Robot added the comment: New changeset 178f9042af81 by Victor Stinner in branch 'default': Issue #15969: Fix the issue number in Misc/NEWS http://hg.python.org/cpython/rev/178f9042af81 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 11:16:21 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 23 Sep 2012 09:16:21 +0000 Subject: [issue15969] faulthandler: drop S from dump_tracebacks_later() function name to have consistent names In-Reply-To: <1348001825.94.0.454810241369.issue15969@psf.upfronthosting.co.za> Message-ID: <1348391781.82.0.0482426692751.issue15969@psf.upfronthosting.co.za> STINNER Victor added the comment: @georg.brandl: You wrote the wrong issue number in the Misc/NEWS file of the 3.3 repository (5969 -> 15969). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 11:17:12 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 23 Sep 2012 09:17:12 +0000 Subject: [issue15969] faulthandler: drop S from dump_tracebacks_later() function name to have consistent names In-Reply-To: <1348001825.94.0.454810241369.issue15969@psf.upfronthosting.co.za> Message-ID: <1348391832.53.0.369812174215.issue15969@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, fixed in b8b5ef366bdc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 11:22:08 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 23 Sep 2012 09:22:08 +0000 Subject: [issue15964] SyntaxError in asdl when building 2.7 with system Python 3 In-Reply-To: <1347978379.29.0.810502621141.issue15964@psf.upfronthosting.co.za> Message-ID: <1348392128.54.0.316527648759.issue15964@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- keywords: +needs review stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 11:54:19 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 23 Sep 2012 09:54:19 +0000 Subject: [issue9720] zipfile writes incorrect local file header for large files in zip64 In-Reply-To: <1283216540.17.0.624049939978.issue9720@psf.upfronthosting.co.za> Message-ID: <1348394059.68.0.540424292243.issue9720@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I see two rational solutions of the issue (all written below is applicable only for allowZip64=True): 1) Always write Zip64 extended information extra field. This approach always successful, but the zipfile size will increase by 20 bytes for each file. The first patch (zipfile_zip64_always.patch) uses this approach. 2) Write Zip64 extended information extra field only if assumed file size is more than a certain limit. In very rare cases this leads to the impossibility of compression of the file which can be compressed the first way. However it produces the same file as before patch in most cases. The second patch (zipfile_zip64_try.patch) is based on Alan's patch and uses the second approach. The probability of errors is reduced and they are now detected and does not lead to a silent data damage. Both patches are for Python 3.3. If any patch is good, I'll backport it for the older versions. ---------- nosy: +gregory.p.smith, loewis, ronaldoussoren Added file: http://bugs.python.org/file27262/zipfile_zip64_always.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 11:55:46 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 23 Sep 2012 09:55:46 +0000 Subject: [issue9720] zipfile writes incorrect local file header for large files in zip64 In-Reply-To: <1283216540.17.0.624049939978.issue9720@psf.upfronthosting.co.za> Message-ID: <1348394146.84.0.471579765589.issue9720@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: needs patch -> patch review Added file: http://bugs.python.org/file27263/zipfile_zip64_try.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 13:15:11 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 23 Sep 2012 11:15:11 +0000 Subject: [issue15952] format(value) and value.__format__() behave differently with unicode format In-Reply-To: <1347825591.49.0.625826586182.issue15952@psf.upfronthosting.co.za> Message-ID: <1348398911.27.0.679749148325.issue15952@psf.upfronthosting.co.za> Ezio Melotti added the comment: ``format(value, format_spec)`` merely calls - ``value.__format__(format_spec)``. + ``value.__format__(format_spec)`` and, if *format_spec* is Unicode, + converts the value to Unicode if it is not already Unicode. This is correct, but should be rephrased (and "value" should be "return value"). + The method ``value.__format__(format_spec)`` may return 8-bit strings + for some built-in types when *format_spec* is Unicode. This is not limited to built-in types. __format__() might return either str or unicode, and format() returns the same -- except for the aforementioned case. This is a summary of the possible cases. __format__ can return unicode or str: >>> class Uni(object): ... def __format__(*args): return u'uni' ... >>> class Str(object): ... def __format__(*args): return 'str' ... format() and __format__ return the same value, except when the format_spec is unicode and __format__ returns str: >>> format(Uni(), 'd'), Uni().__format__( 'd') # same (u'uni', u'uni') >>> format(Uni(), u'd'), Uni().__format__(u'd') # same (u'uni', u'uni') >>> format(Str(), 'd'), Str().__format__( 'd') # same ('str', 'str') >>> format(Str(), u'd'), Str().__format__(u'd') # different (u'str', 'str') It is also not true that the type of return value is the same of the format_spec, because in the first case the returned type is unicode even if the format_spec is str. Therefore this part of the patch should be changed: + Per :pep:`3101`, the function returns a Unicode object if *format_spec* is + Unicode. Otherwise, it returns an 8-bit string. The behavior might be against PEP 3101 (see quotation in msg170669), even thought the wording of the PEP is somewhat lenient IMHO ("proper type" doesn't necessary mean "same type"). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 13:21:10 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 23 Sep 2012 11:21:10 +0000 Subject: [issue16004] Add `make touch` to 2.7 Makefile In-Reply-To: <1348391075.72.0.200262721096.issue16004@psf.upfronthosting.co.za> Message-ID: <1348399270.58.0.140348235215.issue16004@psf.upfronthosting.co.za> Ezio Melotti added the comment: I'm not so sure it's worth adding it. ISTM that this would be useful only to people that already encountered the problem described in #15964 and now that `make touch` is the solution. All the others will have to google for a solution anyway, and there's no much difference in finding `make touch` or `touch Include/Python-ast.h Python/Python-ast.c` ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 13:58:00 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 23 Sep 2012 11:58:00 +0000 Subject: [issue16004] Add `make touch` to 2.7 Makefile In-Reply-To: <1348391075.72.0.200262721096.issue16004@psf.upfronthosting.co.za> Message-ID: <1348401480.92.0.965890854514.issue16004@psf.upfronthosting.co.za> Nick Coghlan added the comment: The idea is to make the solution consistent, regardless of which branch you have checked out (in 3.x, the list of files to touch is longer and "make touch" already exists) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 14:21:25 2012 From: report at bugs.python.org (DDarko) Date: Sun, 23 Sep 2012 12:21:25 +0000 Subject: [issue16005] smtplib.SMTP().sendmail() and rset() Message-ID: <1348402885.58.0.691449233826.issue16005@psf.upfronthosting.co.za> New submission from DDarko: I'm trying to send an email as follows: smtp = smtplib.SMTP(host, port=25) smtp.ehlo() smtp.sendmail(from_mail, to_mail, data) The last line / command calls the raise. I would like to know the reason why SMTP did not accept my email? In theory, enough to capture the exception. However, the exception of the last line returns: "smtplib.SMTPServerDisconnected: Connection unexpectedly closed" This is because the smtplib get replies in: http://hg.python.org/cpython/file/default/Lib/smtplib.py 767 (code, resp) = self.data(msg) Then performs: 769 self.rset() As a result, the SMTP server disconnects the client. And instead receive info with reason I have information about sudden disconnection. I do not think it should be reset, and if it is wrapped in a try. Working snippet: (code, resp) = self.data(msg) if code != 250: #self.rset() raise SMTPDataError(code, resp) #if we got here then somebody got our mail return senderrs This happens on servers mx.google.com ---------- components: Library (Lib) messages: 171029 nosy: DDarko priority: normal severity: normal status: open title: smtplib.SMTP().sendmail() and rset() type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 14:22:39 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 23 Sep 2012 12:22:39 +0000 Subject: [issue16004] Add `make touch` to 2.7 Makefile In-Reply-To: <1348391075.72.0.200262721096.issue16004@psf.upfronthosting.co.za> Message-ID: <1348402959.0.0.755609442041.issue16004@psf.upfronthosting.co.za> Ezio Melotti added the comment: > in 3.x, the list of files to touch is longer You mean that the attached patch is enough for 2.7? In that case I guess it might be OK. ---------- keywords: +patch Added file: http://bugs.python.org/file27264/issue16004.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 14:50:25 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 23 Sep 2012 12:50:25 +0000 Subject: [issue16005] smtplib.SMTP().sendmail() and rset() In-Reply-To: <1348402885.58.0.691449233826.issue16005@psf.upfronthosting.co.za> Message-ID: <1348404625.19.0.862498487056.issue16005@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- components: +email -Library (Lib) nosy: +barry, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 15:00:57 2012 From: report at bugs.python.org (Christian Heimes) Date: Sun, 23 Sep 2012 13:00:57 +0000 Subject: [issue16005] smtplib.SMTP().sendmail() and rset() In-Reply-To: <1348402885.58.0.691449233826.issue16005@psf.upfronthosting.co.za> Message-ID: <1348405257.33.0.516768790027.issue16005@psf.upfronthosting.co.za> Christian Heimes added the comment: According to RFC 821 a smtp server must always apply with OK when it receives a RSET command. RESET (RSET) This command specifies that the current mail transaction is to be aborted. Any stored sender, recipients, and mail data must be discarded, and all buffers and state tables cleared. The receiver must send an OK reply. It seems like your mail server violates the standards. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 15:03:43 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 23 Sep 2012 13:03:43 +0000 Subject: [issue15899] howto/unicode.rst doctest corrections In-Reply-To: <1347267716.91.0.310284408834.issue15899@psf.upfronthosting.co.za> Message-ID: <3XPpdV1WpXzQwk@mail.python.org> Roundup Robot added the comment: New changeset 9c666683e309 by Ezio Melotti in branch '3.2': #15949, #15899: use \ufffd instead of ?. http://hg.python.org/cpython/rev/9c666683e309 New changeset 1aebae2f68da by Ezio Melotti in branch 'default': #15949, #15899: merge with 3.2. http://hg.python.org/cpython/rev/1aebae2f68da ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 15:03:44 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 23 Sep 2012 13:03:44 +0000 Subject: [issue15949] docs.python.org not getting updated In-Reply-To: <1347728419.57.0.753818975668.issue15949@psf.upfronthosting.co.za> Message-ID: <3XPpdW006yzQwk@mail.python.org> Roundup Robot added the comment: New changeset 9c666683e309 by Ezio Melotti in branch '3.2': #15949, #15899: use \ufffd instead of ?. http://hg.python.org/cpython/rev/9c666683e309 New changeset 1aebae2f68da by Ezio Melotti in branch 'default': #15949, #15899: merge with 3.2. http://hg.python.org/cpython/rev/1aebae2f68da ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 15:13:59 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 23 Sep 2012 13:13:59 +0000 Subject: [issue12907] Update test coverage devguide page In-Reply-To: <1315284413.51.0.757189280849.issue12907@psf.upfronthosting.co.za> Message-ID: <1348406039.33.0.381084033682.issue12907@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 15:16:11 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 23 Sep 2012 13:16:11 +0000 Subject: [issue11869] Include information about the bug tracker Rietveld code review tool In-Reply-To: <1303156808.41.0.477083927136.issue11869@psf.upfronthosting.co.za> Message-ID: <1348406171.24.0.679003202989.issue11869@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: -> ezio.melotti type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 15:16:51 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 23 Sep 2012 13:16:51 +0000 Subject: [issue13440] Explain the "status quo wins a stalemate" principle in the devguide In-Reply-To: <1321833284.75.0.438515825131.issue13440@psf.upfronthosting.co.za> Message-ID: <1348406211.02.0.89007003568.issue13440@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 15:17:29 2012 From: report at bugs.python.org (DDarko) Date: Sun, 23 Sep 2012 13:17:29 +0000 Subject: [issue16005] smtplib.SMTP().sendmail() and rset() In-Reply-To: <1348402885.58.0.691449233826.issue16005@psf.upfronthosting.co.za> Message-ID: <1348406249.11.0.0734997089276.issue16005@psf.upfronthosting.co.za> DDarko added the comment: The problem is that this is not my SMTP server. I want to connect as a client with smtplib. For this, as I said earlier it is mx.google.com send: 'ehlo [127.0.1.1]\r\n' reply: b'250-mx.google.com at your service, [MYIP]\r\n' reply: b'250-SIZE 35882577\r\n' reply: b'250-8BITMIME\r\n' reply: b'250-STARTTLS\r\n' reply: b'250 ENHANCEDSTATUSCODES\r\n' reply: retcode (250); Msg: b'mx.google.com at your service, [MYIP]\nSIZE 35882577\n8BITMIME\nSTARTTLS\nENHANCEDSTATUSCODES' send: 'mail FROM: size=448\r\n' reply: b'250 2.1.0 OK o7si11249316wiz.31\r\n' reply: retcode (250); Msg: b'2.1.0 OK o7si11249316wiz.31' send: 'rcpt TO:\r\n' reply: b'250 2.1.5 OK o7si11249316wiz.31\r\n' reply: retcode (250); Msg: b'2.1.5 OK o7si11249316wiz.31' send: 'data\r\n' reply: b'354 Go ahead o7si11249316wiz.31\r\n' reply: retcode (354); Msg: b'Go ahead o7si11249316wiz.31' data: (354, b'Go ahead o7si11249316wiz.31') send: b'Content-Type: multipart/related; boundary="===============0969887089=="\r\nMIME-Version: 1.0\r\nFrom: ....\r\n\r\n--===============0969887089==--\r\n.\r\n' reply: b'550-5.7.1 [MYIP 7] Our system has detected that this message is\r\n' reply: b'550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail,\r\n' reply: b'550-5.7.1 this message has been blocked. Please visit\r\n' reply: b'550-5.7.1 http://support.google.com/mail/bin/answer.py?hl=en&answer=188131 for\r\n' reply: b'550 5.7.1 more information. o7si11249316wiz.31\r\n' reply: retcode (550); Msg: b'5.7.1 [MYIP 7] Our system has detected that this message is\n5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail,\n5.7.1 this message has been blocked. Please visit\n5.7.1 http://support.google.com/mail/bin/answer.py?hl=en&answer=188131 for\n5.7.1 more information. o7si11249316wiz.31' data: (550, b'5.7.1 [MYIP 7] Our system has detected that this message is\n5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail,\n5.7.1 this message has been blocked. Please visit\n5.7.1 http://support.google.com/mail/bin/answer.py?hl=en&answer=188131 for\n5.7.1 more information. o7si11249316wiz.31') send: 'rset\r\n' --- Connection unexpectedly closed ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 15:17:29 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 23 Sep 2012 13:17:29 +0000 Subject: [issue12296] Minor clarification in devguide In-Reply-To: <1307634327.28.0.988674687108.issue12296@psf.upfronthosting.co.za> Message-ID: <1348406249.29.0.62378495008.issue12296@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 15:26:26 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 23 Sep 2012 13:26:26 +0000 Subject: [issue14218] include rendered output in addition to markup In-Reply-To: <1331111194.08.0.943407781198.issue14218@psf.upfronthosting.co.za> Message-ID: <1348406786.65.0.142011962639.issue14218@psf.upfronthosting.co.za> Ezio Melotti added the comment: Another issue with this is that the devguide and the docs use different themes, so there's no guarantee that the output will look the same. Some output examples (and the table I mentioned earlier) could still be added for a few cases though. ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 15:29:51 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 23 Sep 2012 13:29:51 +0000 Subject: [issue13963] dev guide has no mention of mechanics of patch review In-Reply-To: <1328631878.8.0.85188160352.issue13963@psf.upfronthosting.co.za> Message-ID: <1348406991.15.0.617153829923.issue13963@psf.upfronthosting.co.za> Ezio Melotti added the comment: See also #11869. ---------- assignee: -> ezio.melotti stage: -> needs patch type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 15:30:20 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 23 Sep 2012 13:30:20 +0000 Subject: [issue11869] Include information about the bug tracker Rietveld code review tool In-Reply-To: <1303156808.41.0.477083927136.issue11869@psf.upfronthosting.co.za> Message-ID: <1348407020.48.0.150986176807.issue11869@psf.upfronthosting.co.za> Ezio Melotti added the comment: See also #13963. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 15:46:01 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 23 Sep 2012 13:46:01 +0000 Subject: [issue15121] devguide doesn't document all bug tracker components In-Reply-To: <1340275042.61.0.991678411408.issue15121@psf.upfronthosting.co.za> Message-ID: <1348407961.04.0.964449265233.issue15121@psf.upfronthosting.co.za> Ezio Melotti added the comment: 'None' is not available from the UI, and I suspect it's automatically set for issues reported via email. This might be a bug in Roundup, but I haven't verified it yet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 16:03:06 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 23 Sep 2012 14:03:06 +0000 Subject: [issue15034] Devguide should document best practices for stdlib exceptions In-Reply-To: <1339118524.85.0.923317590244.issue15034@psf.upfronthosting.co.za> Message-ID: <1348408986.8.0.496673948378.issue15034@psf.upfronthosting.co.za> Ezio Melotti added the comment: I'm not sure this belongs to the devguide. Ideally the best way to do it should be documented in the docs. This doesn't necessary mean it should be in the tutorial, but if the way documented in the tutorial is "wrong", I'd rather tell users "this is the right way, do like this and don't worry about the details right now (but follow this link if you want to know more)" than "use this wrongish way that is simple but will break as soon as you start doing something more complex". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 16:08:59 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 23 Sep 2012 14:08:59 +0000 Subject: [issue16002] AIX buildbot compile errors In-Reply-To: <1348352217.78.0.0013472169184.issue16002@psf.upfronthosting.co.za> Message-ID: <1348409339.75.0.951983051143.issue16002@psf.upfronthosting.co.za> Stefan Krah added the comment: I tested --without-computed-gotos on the AIX machine and that solves the problem. Antoine, I understood that ./configure parameters can only be changed on the build master. Could you add --without-computed-gotos? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 16:16:14 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 23 Sep 2012 14:16:14 +0000 Subject: [issue15270] "Economy of Expression" section outdated In-Reply-To: <1341641029.42.0.551889407429.issue15270@psf.upfronthosting.co.za> Message-ID: <1348409774.42.0.919444784671.issue15270@psf.upfronthosting.co.za> Ezio Melotti added the comment: IMHO the paragraph about super() can be dropped altogether. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 16:47:05 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 23 Sep 2012 14:47:05 +0000 Subject: [issue15989] Possible integer overflow of PyLong_AsLong() results In-Reply-To: <1348167705.87.0.588220983695.issue15989@psf.upfronthosting.co.za> Message-ID: <1348411625.84.0.589869047146.issue15989@psf.upfronthosting.co.za> Mark Dickinson added the comment: Looks good, in general. _PyLong_AsInt should return -1 on overflow in all cases; at the moment, it looks like it doesn't do that for values that overflow an int but not a long. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 17:23:17 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 23 Sep 2012 15:23:17 +0000 Subject: [issue16002] AIX buildbot compile errors In-Reply-To: <1348352217.78.0.0013472169184.issue16002@psf.upfronthosting.co.za> Message-ID: <1348413797.76.0.567224460523.issue16002@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Antoine, I understood that ./configure parameters can only be changed > on the build master. Could you add --without-computed-gotos? Done. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 17:33:59 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 23 Sep 2012 15:33:59 +0000 Subject: [issue13440] Explain the "status quo wins a stalemate" principle in the devguide In-Reply-To: <1321833284.75.0.438515825131.issue13440@psf.upfronthosting.co.za> Message-ID: <1348414439.82.0.465770376091.issue13440@psf.upfronthosting.co.za> Antoine Pitrou added the comment: What would be the benefit of adding this to the devguide? I'll say it again, the devguide should be short enough to be practical for someone learning to contribute. It is quite wordy already. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 17:35:49 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 23 Sep 2012 15:35:49 +0000 Subject: [issue16003] thread_PyThread_start_new_thread fails with a generic error In-Reply-To: <1348389246.53.0.0663792895343.issue16003@psf.upfronthosting.co.za> Message-ID: <1348414549.27.0.547873651006.issue16003@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm personally ok with using a more informative error than ThreadError. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 17:38:38 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 23 Sep 2012 15:38:38 +0000 Subject: [issue15989] Possible integer overflow of PyLong_AsLong() results In-Reply-To: <1348167705.87.0.588220983695.issue15989@psf.upfronthosting.co.za> Message-ID: <1348414718.09.0.535918420549.issue15989@psf.upfronthosting.co.za> Mark Dickinson added the comment: I added some comments on Rietveld. Apart from the bug in _PyLong_AsInt mentioned above, the patch mostly looks good. But there are many changes, some of which will have user-visible effects, and I think it's somewhat risky to make all these changes in bugfix releases (which now includes Python 3.3). Perhaps there could be a smaller patch aimed at the bugfix releases? Ideally, each fix there should be backed by a regression test. ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 17:38:38 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 23 Sep 2012 15:38:38 +0000 Subject: [issue16002] AIX buildbot compile errors In-Reply-To: <1348413797.76.0.567224460523.issue16002@psf.upfronthosting.co.za> Message-ID: <20120923153839.GA19006@sleipnir.bytereef.org> Stefan Krah added the comment: Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 17:59:11 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 23 Sep 2012 15:59:11 +0000 Subject: [issue15996] pow() for complex numbers is rough around the edges In-Reply-To: <1348178428.15.0.517718755216.issue15996@psf.upfronthosting.co.za> Message-ID: <1348415951.48.0.992545939041.issue15996@psf.upfronthosting.co.za> Mark Dickinson added the comment: Reclassifying this as an enhancement; I don't think it's appropriate to rewrite complex_pow for the bugfix releases. ---------- type: behavior -> enhancement versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 17:59:37 2012 From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=) Date: Sun, 23 Sep 2012 15:59:37 +0000 Subject: [issue8425] a -= b should be fast if a is a small set and b is a large set In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za> Message-ID: <1348415977.27.0.194835817099.issue8425@psf.upfronthosting.co.za> Michele Orr? added the comment: Something like this would also need unit tests? $ ./python.exe -m timeit -s "s= set(range(2000)); l = set(range(20000000)); s=s-l" 10000000 loops, best of 3: 0.0622 usec per loop [48787 refs] $ ./python.exe -m timeit -s "s= set(range(2000)); l = set(range(20000000)); s-=l" 10000000 loops, best of 3: 0.0591 usec per loop [48787 refs] ---------- Added file: http://bugs.python.org/file27265/issue8425.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 18:03:54 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Sun, 23 Sep 2012 16:03:54 +0000 Subject: [issue16006] Spelling mistake in PEP 213 Message-ID: <1348416234.5.0.925899069315.issue16006@psf.upfronthosting.co.za> New submission from Ramchandra Apte: In the first line of the "Justification" paragraph in PEP 213 "cenario" is used. It should be "Scenario". ---------- components: None messages: 171050 nosy: ramchandra.apte priority: normal severity: normal status: open title: Spelling mistake in PEP 213 type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 18:14:29 2012 From: report at bugs.python.org (Ling Li) Date: Sun, 23 Sep 2012 16:14:29 +0000 Subject: [issue16007] Improved Error message for failing re expressions Message-ID: <1348416868.74.0.37879499143.issue16007@psf.upfronthosting.co.za> New submission from Ling Li: Hi, I would like to make a small improvement to the exception raised when _compile() function fails with exception on line 245. Please see attached amended file. The line of code is amended from: raise error, v # invalid expression to: raise error, r'%s with pattern: %s' % (v, pattern) # invalid expression As this is my first contribution, please let me know if this is the correct procedure to submit changes. Kind regards, Ling ---------- components: Regular Expressions files: re.py messages: 171051 nosy: ezio.melotti, lingster, mrabarnett priority: normal severity: normal status: open title: Improved Error message for failing re expressions type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file27266/re.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 18:17:27 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 23 Sep 2012 16:17:27 +0000 Subject: [issue16008] [OS bug] DragonFly buildbot locale failures Message-ID: <1348417046.98.0.868158442098.issue16008@psf.upfronthosting.co.za> New submission from Stefan Krah: The locale failures on the DragonFly buildbot are caused by an OS bug: bugs.dragonflybsd.org/issues/2415 I'm opening an issue so that this is recorded and other people hopefully won't waste time debugging the failures. I intend to close the issue as invalid in a couple of days. ====================================================================== FAIL: test_wide_char_separator_decimal_point (test.test_decimal.CFormatTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/cpython/buildslave/3.x.snakebite-dragonfly30-amd64-1/build/Lib/test/test_decimal.py", line 1149, in test_wide_char_separator_decimal_point '100\u066c000\u066c000\u066b123') AssertionError: '100000000.123' != '100\u066c000\u066c000\u066b123' - 100000000.123 ? ^ + 100\u066c000\u066c000\u066b123 ? + + ^ ====================================================================== ERROR: test_basic (test.test_strptime.getlang_Tests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/cpython/buildslave/3.x.snakebite-dragonfly30-amd64-1/build/Lib/test/test_strptime.py", line 16, in test_basic self.assertEqual(_strptime._getlang(), locale.getlocale(locale.LC_TIME)) File "/home/cpython/buildslave/3.x.snakebite-dragonfly30-amd64-1/build/Lib/_strptime.py", line 31, in _getlang return locale.getlocale(locale.LC_TIME) File "/home/cpython/buildslave/3.x.snakebite-dragonfly30-amd64-1/build/Lib/locale.py", line 524, in getlocale return _parse_localename(localename) File "/home/cpython/buildslave/3.x.snakebite-dragonfly30-amd64-1/build/Lib/locale.py", line 433, in _parse_localename raise ValueError('unknown locale: %s' % localename) ValueError: unknown locale: ps_AF ---------- keywords: buildbot messages: 171052 nosy: skrah, trent priority: low severity: normal status: open title: [OS bug] DragonFly buildbot locale failures type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 18:21:09 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 23 Sep 2012 16:21:09 +0000 Subject: [issue16006] Spelling mistake in PEP 213 In-Reply-To: <1348416234.5.0.925899069315.issue16006@psf.upfronthosting.co.za> Message-ID: <1348417269.6.0.108783447503.issue16006@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed in 94dbf7d100f3, thanks for the report! ---------- assignee: -> ezio.melotti components: -None nosy: +ezio.melotti resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 18:22:00 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 23 Sep 2012 16:22:00 +0000 Subject: [issue16007] Improved Error message for failing re expressions In-Reply-To: <1348416868.74.0.37879499143.issue16007@psf.upfronthosting.co.za> Message-ID: <1348417320.21.0.366344934149.issue16007@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Please provide a patch in unified diff format. ---------- nosy: +benjamin.peterson versions: +Python 3.4 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 18:23:34 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Sun, 23 Sep 2012 16:23:34 +0000 Subject: [issue16007] Improved Error message for failing re expressions In-Reply-To: <1348416868.74.0.37879499143.issue16007@psf.upfronthosting.co.za> Message-ID: <1348417414.97.0.90506419305.issue16007@psf.upfronthosting.co.za> Ramchandra Apte added the comment: > As this is my first contribution, please let me know if this is the correct procedure to submit changes. This is the correct procedure. http://docs.python.org/devguide/ (the Python Devlopment Guide) is a guide on how to contribute to Python. Hope you enjoy your Python development experience! ---------- nosy: +ramchandra.apte _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 18:25:02 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Sun, 23 Sep 2012 16:25:02 +0000 Subject: [issue16006] Spelling mistake in PEP 213 In-Reply-To: <1348416234.5.0.925899069315.issue16006@psf.upfronthosting.co.za> Message-ID: <1348417502.4.0.620974313026.issue16006@psf.upfronthosting.co.za> Ramchandra Apte added the comment: That's hyper-fast. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 18:38:20 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 23 Sep 2012 16:38:20 +0000 Subject: [issue15270] "Economy of Expression" section outdated In-Reply-To: <1341641029.42.0.551889407429.issue15270@psf.upfronthosting.co.za> Message-ID: <3XPvP65XcvzQtS@mail.python.org> Roundup Robot added the comment: New changeset 100909b4def0 by Raymond Hettinger in branch 'default': Issue #15270. Appease critics by removing a reference to the docs for super(). http://hg.python.org/devguide/rev/100909b4def0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 18:39:41 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 23 Sep 2012 16:39:41 +0000 Subject: [issue15270] "Economy of Expression" section outdated In-Reply-To: <1341641029.42.0.551889407429.issue15270@psf.upfronthosting.co.za> Message-ID: <1348418381.8.0.663814660919.issue15270@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This whole discussion was inane. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 18:46:35 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Sun, 23 Sep 2012 16:46:35 +0000 Subject: [issue15955] gzip, bz2, lzma: add method to get decompressed size In-Reply-To: <1347884562.79.0.801674791772.issue15955@psf.upfronthosting.co.za> Message-ID: <1348418795.08.0.401605495281.issue15955@psf.upfronthosting.co.za> Nadeem Vawda added the comment: As far as I can tell, there is no way to find this out reliably without decompressing the entire file. With gzip, the file trailer contains the uncompressed size modulo 2^32, but this seems less than useful. It appears that the other two formats do not store the total uncompressed data size in any form. For bz2 and lzma, one can get the uncompressed size by doing f.seek(0, 2) followed by f.tell(). However this approach is ugly and potentially very slow, so I would be reluctant to add a method based on it to the (BZ2|LZMA)File classes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 18:48:41 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 23 Sep 2012 16:48:41 +0000 Subject: [issue16005] smtplib.SMTP().sendmail() and rset() In-Reply-To: <1348402885.58.0.691449233826.issue16005@psf.upfronthosting.co.za> Message-ID: <1348418921.85.0.174519752325.issue16005@psf.upfronthosting.co.za> R. David Murray added the comment: I believe that Google is technically out of compliance with the SMTP spec here. What they are doing is not unreasonable, since they don't have any reason to want to waste resources on talking to a server they think is spamming them. Making this work in a more useful fashion may be considered an enhancement rather than a bug fix, since arguably it is Google, not smtplib, that appears to be violating the RFC. On the other hand, the fix is simple enough, is unlikely to be harmful, and it can be argued that handling this error is the proper action for a robust smtp client in any case, so I think we can justify making it a bug fix. The rset is correct in the general case, so the fix would be to wrap it in a try/except and treat SMTPServerDisconnected as not-an-error. DDarko, would you have any interest in proposing a patch with tests? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 19:08:46 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 23 Sep 2012 17:08:46 +0000 Subject: [issue16002] AIX buildbot compile errors In-Reply-To: <1348352217.78.0.0013472169184.issue16002@psf.upfronthosting.co.za> Message-ID: <1348420126.23.0.146476125065.issue16002@psf.upfronthosting.co.za> Stefan Krah added the comment: The compile errors are fixed, let's open separate issues for the test failures. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 19:14:25 2012 From: report at bugs.python.org (Luka Rahne) Date: Sun, 23 Sep 2012 17:14:25 +0000 Subject: [issue16009] Json not handling errors correctly Message-ID: <1348420465.53.0.405036591258.issue16009@psf.upfronthosting.co.za> New submission from Luka Rahne: Example: import json j = json.loads( """ { "phoneNumber": [ { "type": "home", "number": "212 555-1234" }, } """) print(j) Output>> Traceback (most recent call last): File "", line 13, in File "/usr/lib/python2.7/json/__init__.py", line 326, in loads return _default_decoder.decode(s) File "/usr/lib/python2.7/json/decoder.py", line 366, in decode obj, end = self.raw_decode(s, idx=_w(s, 0).end()) File "/usr/lib/python2.7/json/decoder.py", line 384, in raw_decode raise ValueError("No JSON object could be decoded") ValueError: No JSON object could be decoded My comment: It is annoying in case of manual json editing where you can't know where jeson typeing error is. ---------- components: Library (Lib) messages: 171062 nosy: Luka.Rahne priority: normal severity: normal status: open title: Json not handling errors correctly versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 19:21:32 2012 From: report at bugs.python.org (DDarko) Date: Sun, 23 Sep 2012 17:21:32 +0000 Subject: [issue16005] smtplib.SMTP().sendmail() and rset() In-Reply-To: <1348402885.58.0.691449233826.issue16005@psf.upfronthosting.co.za> Message-ID: <1348420892.26.0.163848485454.issue16005@psf.upfronthosting.co.za> DDarko added the comment: I do not understand why at all reset is performed ? If moments later raise is done. If someone despite error SMTPSenderRefused, SMTPRecipientsRefused or SMTPDataError will still want to maintain a connection and use other data with session is likely he will call SMTP().rset() manually. In my opinion, the most frequent use of the library are: smtp = smtplib.SMTP(host, port=25) smtp.ehlo() try: smtp.sendmail(from_mail, to_mail, data) except Exception as e: print(e) smtp.quit() If you wish to use session despite the error: smtp = smtplib.SMTP(host, port=25) smtp.ehlo() for to_mail in mail_list: try: smtp.sendmail(from_mail, to_mail, data) except smtplib.SMTPRecipientsRefused as e: smtp.rset() print(e) smtp.quit() If we do not handle exception, reset does not matter. IMHO patch should look like this: http://hg.python.org/cpython/file/default/Lib/smtplib.py 745d744 < self.rset() 756d754 < self.rset() 760d757 < self.rset() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 19:21:49 2012 From: report at bugs.python.org (Luka Rahne) Date: Sun, 23 Sep 2012 17:21:49 +0000 Subject: [issue16009] Json not handling errors correctly In-Reply-To: <1348420465.53.0.405036591258.issue16009@psf.upfronthosting.co.za> Message-ID: <1348420909.91.0.172805619251.issue16009@psf.upfronthosting.co.za> Luka Rahne added the comment: For example i foun out, that just extra comma crate such error j = json.loads("""{ "" :[{},]}""") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 19:23:13 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 23 Sep 2012 17:23:13 +0000 Subject: [issue15034] Devguide should document best practices for stdlib exceptions In-Reply-To: <1339118524.85.0.923317590244.issue15034@psf.upfronthosting.co.za> Message-ID: <1348420993.97.0.777322946399.issue15034@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I think the Library Manual's chapter 5 on exceptions, currently called Built-in Exceptions, would be a good place for a section on subclassing exceptions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 19:25:52 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 23 Sep 2012 17:25:52 +0000 Subject: [issue13440] Explain the "status quo wins a stalemate" principle in the devguide In-Reply-To: <1321833284.75.0.438515825131.issue13440@psf.upfronthosting.co.za> Message-ID: <1348421152.64.0.969655079955.issue13440@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Maybe just add links to the two essays. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 19:26:53 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 23 Sep 2012 17:26:53 +0000 Subject: [issue15034] Devguide should document best practices for stdlib exceptions In-Reply-To: <1339118524.85.0.923317590244.issue15034@psf.upfronthosting.co.za> Message-ID: <1348421213.65.0.66728213355.issue15034@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 19:27:47 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 23 Sep 2012 17:27:47 +0000 Subject: [issue13440] Explain the "status quo wins a stalemate" principle in the devguide In-Reply-To: <1321833284.75.0.438515825131.issue13440@psf.upfronthosting.co.za> Message-ID: <1348421267.1.0.769725556681.issue13440@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 19:44:45 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 23 Sep 2012 17:44:45 +0000 Subject: [issue13963] dev guide has no mention of mechanics of patch review In-Reply-To: <1328631878.8.0.85188160352.issue13963@psf.upfronthosting.co.za> Message-ID: <1348422285.1.0.391811927792.issue13963@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > If this is true, we could simply add a way to specify the branch (either a dropdown in the roundup UI or an X.Y in the filename). It would be cool if this could happen even without any user action (e.g. if Rietveld tried default, 3.2, and 2.7 in sequence until one succeeded). ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 19:58:07 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 23 Sep 2012 17:58:07 +0000 Subject: [issue15835] HP-UX build needs to be tweaked to pick up PATH_MAX In-Reply-To: <1346457153.04.0.0294174797728.issue15835@psf.upfronthosting.co.za> Message-ID: <1348423087.38.0.161033177346.issue15835@psf.upfronthosting.co.za> Stefan Krah added the comment: PATH_MAX seems to be a mess on HP-UX: It's only defined in limits.h if _INCLUDE_XOPEN_SOURCE_PRE_500 is defined. But MAXPATHLEN is always defined in sys/param.h, so I suggest to use that (patch attached). Other projects take a similar approach by just defining PATH_MAX as 1024: http://lists.gnu.org/archive/html/bug-gnulib/2011-06/msg00242.html ---------- keywords: +buildbot, patch nosy: +skrah Added file: http://bugs.python.org/file27267/issue15835.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 20:01:13 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 23 Sep 2012 18:01:13 +0000 Subject: [issue15379] Charmap decoding of no-BMP characters In-Reply-To: <1342512958.35.0.341191772548.issue15379@psf.upfronthosting.co.za> Message-ID: <3XPxDl4DNhzQyr@mail.python.org> Roundup Robot added the comment: New changeset 620d23f7ad41 by Antoine Pitrou in branch '3.2': Issue #15379: Fix passing of non-BMP characters as integers for the charmap decoder (already working as unicode strings). http://hg.python.org/cpython/rev/620d23f7ad41 New changeset c64dec45d46f by Antoine Pitrou in branch 'default': Issue #15379: Fix passing of non-BMP characters as integers for the charmap decoder (already working as unicode strings). http://hg.python.org/cpython/rev/c64dec45d46f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 20:02:06 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 23 Sep 2012 18:02:06 +0000 Subject: [issue15379] Charmap decoding of no-BMP characters In-Reply-To: <1342512958.35.0.341191772548.issue15379@psf.upfronthosting.co.za> Message-ID: <1348423326.25.0.0196725561614.issue15379@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thank you, I've committed the patches. There was a test failure in test_codeccallbacks in 3.2, which I fixed simply by replacing sys.maxunicode with a hardcoded 0x110000. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 20:02:19 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 23 Sep 2012 18:02:19 +0000 Subject: [issue15379] Charmap decoding of no-BMP characters In-Reply-To: <1342512958.35.0.341191772548.issue15379@psf.upfronthosting.co.za> Message-ID: <1348423339.81.0.118368446199.issue15379@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: patch review -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 20:04:14 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 23 Sep 2012 18:04:14 +0000 Subject: [issue16005] smtplib.SMTP().sendmail() and rset() In-Reply-To: <1348402885.58.0.691449233826.issue16005@psf.upfronthosting.co.za> Message-ID: <1348423454.98.0.697600134463.issue16005@psf.upfronthosting.co.za> R. David Murray added the comment: The rset just returns the connection to the "base" state, allowing a new message sending transaction to start from a known state. In any case, since the library has done this in the past, it must continue to do this in the future, or it will break currently working code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 20:10:08 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 23 Sep 2012 18:10:08 +0000 Subject: [issue16009] Json error messages could provide more information about the error In-Reply-To: <1348420465.53.0.405036591258.issue16009@psf.upfronthosting.co.za> Message-ID: <1348423808.35.0.11018469972.issue16009@psf.upfronthosting.co.za> R. David Murray added the comment: The errors are being handled correctly, but it would indeed be nice for them to provide more information about the specific error. That's an enhancement, though. ---------- nosy: +r.david.murray stage: -> needs patch title: Json not handling errors correctly -> Json error messages could provide more information about the error type: -> enhancement versions: +Python 3.4 -Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 20:22:09 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 23 Sep 2012 18:22:09 +0000 Subject: [issue11454] email.message import time In-Reply-To: <1299701237.24.0.992920521308.issue11454@psf.upfronthosting.co.za> Message-ID: <1348424529.94.0.53426442654.issue11454@psf.upfronthosting.co.za> R. David Murray added the comment: I'm really not willing to inline any of those pre-compiled regular expressions. They are precompiled because for a program processing lots of email, they are hot spots. We could use the same "compile on demand" dodge on them, though. Can you explain your changes to the ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 20:23:01 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 23 Sep 2012 18:23:01 +0000 Subject: [issue11454] email.message import time In-Reply-To: <1299701237.24.0.992920521308.issue11454@psf.upfronthosting.co.za> Message-ID: <1348424581.41.0.752366809688.issue11454@psf.upfronthosting.co.za> R. David Murray added the comment: Woops. Can you explain your changes to the ecre regex (keeping in mind that I don't know much about regex syntax). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 20:24:56 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 23 Sep 2012 18:24:56 +0000 Subject: [issue11454] email.message import time In-Reply-To: <1299701237.24.0.992920521308.issue11454@psf.upfronthosting.co.za> Message-ID: <1348424696.96.0.324222630573.issue11454@psf.upfronthosting.co.za> R. David Murray added the comment: Oh, yeah, and the encode benchmark is very instructive, thanks Serhiy :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 20:44:49 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 23 Sep 2012 18:44:49 +0000 Subject: [issue16004] Add `make touch` to 2.7 Makefile In-Reply-To: <1348391075.72.0.200262721096.issue16004@psf.upfronthosting.co.za> Message-ID: <1348425889.99.0.0459626144536.issue16004@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 20:53:19 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 23 Sep 2012 18:53:19 +0000 Subject: [issue11454] email.message import time In-Reply-To: <1299701237.24.0.992920521308.issue11454@psf.upfronthosting.co.za> Message-ID: <1348426399.19.0.771620737701.issue11454@psf.upfronthosting.co.za> Ezio Melotti added the comment: > They are precompiled because for a program processing lots of email, > they are hot spots. OK, I didn't know they were hot spots. Note that the regex are not recompiled everytime: they are compiled the first time and then taken from the cache (assuming they don't fall out from the bottom of the cache). This still has a small overhead though. > Can you explain your changes to the ecre regex (keeping in mind > that I don't know much about regex syntax). - (?P[^?]*?) # non-greedy up to the next ? is the charset + (?P[^?]*) # up to the next ? is the charset \? # literal ? (?P[qb]) # either a "q" or a "b", case insensitive \? # literal ? - (?P.*?) # non-greedy up to the next ?= is the encoded string + (?P[^?]*) # up to the next ?= is the encoded string \?= # literal ?= At the beginning, the non-greedy *? is unnecessary because [^?]* already stops at the first ? found. The second change might actually be wrong if is allowed to contain lone '?'s. The original regex used '.*?\?=', which means "match everything (including lone '?'s) until the first '?=')", mine means "match everything until the first '?'" which works fine as long as lone '?'s are not allowed. Serhiy's suggestion is semantically different, but it might be still suitable if having _has_surrogate return True even for surrogates not in range \udc80-\udcff is OK. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 21:06:14 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 23 Sep 2012 19:06:14 +0000 Subject: [issue11454] email.message import time In-Reply-To: <1299701237.24.0.992920521308.issue11454@psf.upfronthosting.co.za> Message-ID: <1348427174.77.0.656591616199.issue11454@psf.upfronthosting.co.za> R. David Murray added the comment: Well, "other" surrogates will cause a different error later than with the current _has_surrogates logic, but it won't be any more mysterious than what would happen now, I think. Normally, if I understand correctly, other surrogates should never occur, so I don't think it is a real issue. Yes, lone '?'s should not stop the pattern match in an encoded string. Even though I don't think they are normally supposed to occur, they do occur when encoded words are encoded incorrectly, and we get a better error recovery result if we look for ?= as the end. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 21:15:41 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 23 Sep 2012 19:15:41 +0000 Subject: [issue15989] Possible integer overflow of PyLong_AsLong() results In-Reply-To: <1348414718.09.0.535918420549.issue15989@psf.upfronthosting.co.za> Message-ID: <201209232215.15567.storchaka@gmail.com> Serhiy Storchaka added the comment: Thank you for review and for found bugs. I again checked the patch, corrected the errors and dubious places. Also I corrected the error in Modules/grpmodule.c (in other places gid_t parsed as signed long) and the possible behaviour change in Modules/_io/_iomodule.c, reversed the changes in Modules/pyexpat.c. If some changes cause you have doubts, you can cherry-pick only the most obvious fixes. > Ideally, each fix there should be backed by a regression test. Unfortunately I have only platforms where sizeof(int) == sizeof(long) == sizeof(size_t). ---------- Added file: http://bugs.python.org/file27268/long_aslong_overflow-3.3_2.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r c64dec45d46f Include/longobject.h --- a/Include/longobject.h Sun Sep 23 20:00:04 2012 +0200 +++ b/Include/longobject.h Sun Sep 23 21:46:54 2012 +0300 @@ -26,6 +26,9 @@ PyAPI_FUNC(size_t) PyLong_AsSize_t(PyObject *); PyAPI_FUNC(unsigned long) PyLong_AsUnsignedLong(PyObject *); PyAPI_FUNC(unsigned long) PyLong_AsUnsignedLongMask(PyObject *); +#ifndef Py_LIMITED_API +PyAPI_FUNC(int) _PyLong_AsInt(PyObject *); +#endif PyAPI_FUNC(PyObject *) PyLong_GetInfo(void); /* It may be useful in the future. I've added it in the PyInt -> PyLong diff -r c64dec45d46f Modules/_ctypes/stgdict.c --- a/Modules/_ctypes/stgdict.c Sun Sep 23 20:00:04 2012 +0200 +++ b/Modules/_ctypes/stgdict.c Sun Sep 23 21:46:54 2012 +0300 @@ -335,7 +335,7 @@ isPacked = PyObject_GetAttrString(type, "_pack_"); if (isPacked) { - pack = PyLong_AsLong(isPacked); + pack = _PyLong_AsInt(isPacked); if (pack < 0 || PyErr_Occurred()) { Py_XDECREF(isPacked); PyErr_SetString(PyExc_ValueError, diff -r c64dec45d46f Modules/_datetimemodule.c --- a/Modules/_datetimemodule.c Sun Sep 23 20:00:04 2012 +0200 +++ b/Modules/_datetimemodule.c Sun Sep 23 21:46:54 2012 +0300 @@ -4717,7 +4717,7 @@ if (seconds == NULL) goto error; Py_DECREF(delta); - timestamp = PyLong_AsLong(seconds); + timestamp = _PyLong_AsTime_t(seconds); Py_DECREF(seconds); if (timestamp == -1 && PyErr_Occurred()) return NULL; diff -r c64dec45d46f Modules/_io/_iomodule.c --- a/Modules/_io/_iomodule.c Sun Sep 23 20:00:04 2012 +0200 +++ b/Modules/_io/_iomodule.c Sun Sep 23 21:46:54 2012 +0300 @@ -230,7 +230,8 @@ int text = 0, binary = 0, universal = 0; char rawmode[6], *m; - int line_buffering, isatty; + int line_buffering; + long isatty; PyObject *raw, *modeobj = NULL, *buffer = NULL, *wrapper = NULL; @@ -376,12 +377,12 @@ #ifdef HAVE_STRUCT_STAT_ST_BLKSIZE { struct stat st; - long fileno; + int fileno; PyObject *res = _PyObject_CallMethodId(raw, &PyId_fileno, NULL); if (res == NULL) goto error; - fileno = PyLong_AsLong(res); + fileno = _PyLong_AsInt(res); Py_DECREF(res); if (fileno == -1 && PyErr_Occurred()) goto error; diff -r c64dec45d46f Modules/_io/fileio.c --- a/Modules/_io/fileio.c Sun Sep 23 20:00:04 2012 +0200 +++ b/Modules/_io/fileio.c Sun Sep 23 21:46:54 2012 +0300 @@ -244,7 +244,7 @@ return -1; } - fd = PyLong_AsLong(nameobj); + fd = _PyLong_AsInt(nameobj); if (fd < 0) { if (!PyErr_Occurred()) { PyErr_SetString(PyExc_ValueError, @@ -382,7 +382,7 @@ goto error; } - self->fd = PyLong_AsLong(fdobj); + self->fd = _PyLong_AsInt(fdobj); Py_DECREF(fdobj); if (self->fd == -1) { goto error; diff -r c64dec45d46f Modules/_io/textio.c --- a/Modules/_io/textio.c Sun Sep 23 20:00:04 2012 +0200 +++ b/Modules/_io/textio.c Sun Sep 23 21:46:54 2012 +0300 @@ -881,7 +881,7 @@ } } else { - int fd = (int) PyLong_AsLong(fileno); + int fd = _PyLong_AsInt(fileno); Py_DECREF(fileno); if (fd == -1 && PyErr_Occurred()) { goto error; diff -r c64dec45d46f Modules/_sqlite/connection.c --- a/Modules/_sqlite/connection.c Sun Sep 23 20:00:04 2012 +0200 +++ b/Modules/_sqlite/connection.c Sun Sep 23 21:46:54 2012 +0300 @@ -859,7 +859,7 @@ rc = SQLITE_DENY; } else { if (PyLong_Check(ret)) { - rc = (int)PyLong_AsLong(ret); + rc = _PyLong_AsInt(ret); } else { rc = SQLITE_DENY; } @@ -1350,7 +1350,7 @@ goto finally; } - result = PyLong_AsLong(retval); + result = _PyLong_AsInt(retval); if (PyErr_Occurred()) { result = 0; } diff -r c64dec45d46f Modules/grpmodule.c --- a/Modules/grpmodule.c Sun Sep 23 20:00:04 2012 +0200 +++ b/Modules/grpmodule.c Sun Sep 23 21:46:54 2012 +0300 @@ -85,7 +85,7 @@ grp_getgrgid(PyObject *self, PyObject *pyo_id) { PyObject *py_int_id; - unsigned int gid; + long gid; struct group *p; py_int_id = PyNumber_Long(pyo_id); @@ -93,8 +93,15 @@ return NULL; gid = PyLong_AS_LONG(py_int_id); Py_DECREF(py_int_id); + if (gid == -1 && PyErr_Occurred()) + return NULL; + if ((long)(gid_t)gid != gid) { + PyErr_SetString(PyExc_OverflowError, + "Python int too large to convert to gid_t"); + return NULL; + } - if ((p = getgrgid(gid)) == NULL) { + if ((p = getgrgid((gid_t)gid)) == NULL) { PyErr_Format(PyExc_KeyError, "getgrgid(): gid not found: %d", gid); return NULL; } diff -r c64dec45d46f Modules/parsermodule.c --- a/Modules/parsermodule.c Sun Sep 23 20:00:04 2012 +0200 +++ b/Modules/parsermodule.c Sun Sep 23 21:46:54 2012 +0300 @@ -725,7 +725,7 @@ /* elem must always be a sequence, however simple */ PyObject* elem = PySequence_GetItem(tuple, i); int ok = elem != NULL; - long type = 0; + int type = 0; char *strn = 0; if (ok) @@ -736,8 +736,14 @@ ok = 0; else { ok = PyLong_Check(temp); - if (ok) - type = PyLong_AS_LONG(temp); + if (ok) { + type = _PyLong_AsInt(temp); + if (type == -1 && PyErr_Occurred()) { + Py_DECREF(temp); + Py_DECREF(elem); + return 0; + } + } Py_DECREF(temp); } } @@ -773,8 +779,16 @@ if (len == 3) { PyObject *o = PySequence_GetItem(elem, 2); if (o != NULL) { - if (PyLong_Check(o)) - *line_num = PyLong_AS_LONG(o); + if (PyLong_Check(o)) { + int num = _PyLong_AsInt(o); + if (num == -1 && PyErr_Occurred()) { + Py_DECREF(o); + Py_DECREF(temp); + Py_DECREF(elem); + return 0; + } + *line_num = num; + } else { PyErr_Format(parser_error, "third item in terminal node must be an" diff -r c64dec45d46f Modules/posixmodule.c --- a/Modules/posixmodule.c Sun Sep 23 20:00:04 2012 +0200 +++ b/Modules/posixmodule.c Sun Sep 23 21:46:54 2012 +0300 @@ -8170,7 +8170,7 @@ int fds[2]; int res; - flags = PyLong_AsLong(arg); + flags = _PyLong_AsInt(arg); if (flags == -1 && PyErr_Occurred()) return NULL; @@ -9016,7 +9016,7 @@ */ struct constdef { char *name; - long value; + int value; }; static int @@ -9024,7 +9024,10 @@ size_t tablesize) { if (PyLong_Check(arg)) { - *valuep = PyLong_AS_LONG(arg); + int value = _PyLong_AsInt(arg); + if (value == -1 && PyErr_Occurred()) + return 0; + *valuep = value; return 1; } else { diff -r c64dec45d46f Modules/readline.c --- a/Modules/readline.c Sun Sep 23 20:00:04 2012 +0200 +++ b/Modules/readline.c Sun Sep 23 21:46:54 2012 +0300 @@ -741,7 +741,7 @@ if (r == Py_None) result = 0; else { - result = PyLong_AsLong(r); + result = _PyLong_AsInt(r); if (result == -1 && PyErr_Occurred()) goto error; } diff -r c64dec45d46f Modules/selectmodule.c --- a/Modules/selectmodule.c Sun Sep 23 20:00:04 2012 +0200 +++ b/Modules/selectmodule.c Sun Sep 23 21:46:54 2012 +0300 @@ -359,10 +359,13 @@ i = pos = 0; while (PyDict_Next(self->dict, &pos, &key, &value)) { - self->ufds[i].fd = PyLong_AsLong(key); + assert(i < self->ufd_len); + /* Never overflow */ + self->ufds[i].fd = (int)PyLong_AsLong(key); self->ufds[i].events = (short)PyLong_AsLong(value); i++; } + assert(i == self->ufd_len); self->ufd_uptodate = 1; return 1; } @@ -378,10 +381,11 @@ poll_register(pollObject *self, PyObject *args) { PyObject *o, *key, *value; - int fd, events = POLLIN | POLLPRI | POLLOUT; + int fd; + short events = POLLIN | POLLPRI | POLLOUT; int err; - if (!PyArg_ParseTuple(args, "O|i:register", &o, &events)) { + if (!PyArg_ParseTuple(args, "O|h:register", &o, &events)) { return NULL; } @@ -520,7 +524,7 @@ tout = PyNumber_Long(tout); if (!tout) return NULL; - timeout = PyLong_AsLong(tout); + timeout = _PyLong_AsInt(tout); Py_DECREF(tout); if (timeout == -1 && PyErr_Occurred()) return NULL; @@ -804,7 +808,7 @@ struct dvpoll dvp; PyObject *result_list = NULL, *tout = NULL; int poll_result, i; - long timeout; + int timeout; PyObject *value, *num1, *num2; if (!PyArg_UnpackTuple(args, "poll", 0, 1, &tout)) { @@ -823,16 +827,15 @@ tout = PyNumber_Long(tout); if (!tout) return NULL; - timeout = PyLong_AsLong(tout); + timeout = _PyLong_AsInt(tout); Py_DECREF(tout); if (timeout == -1 && PyErr_Occurred()) return NULL; - } - - if ((timeout < -1) || (timeout > INT_MAX)) { - PyErr_SetString(PyExc_OverflowError, + if (timeout < -1) { + PyErr_SetString(PyExc_OverflowError, "timeout is out of range"); - return NULL; + return NULL; + } } if (devpoll_flush(self)) diff -r c64dec45d46f Modules/socketmodule.c --- a/Modules/socketmodule.c Sun Sep 23 20:00:04 2012 +0200 +++ b/Modules/socketmodule.c Sun Sep 23 21:46:54 2012 +0300 @@ -2073,7 +2073,7 @@ static PyObject * sock_setblocking(PySocketSockObject *s, PyObject *arg) { - int block; + long block; block = PyLong_AsLong(arg); if (block == -1 && PyErr_Occurred()) @@ -2555,7 +2555,7 @@ int backlog; int res; - backlog = PyLong_AsLong(arg); + backlog = _PyLong_AsInt(arg); if (backlog == -1 && PyErr_Occurred()) return NULL; Py_BEGIN_ALLOW_THREADS @@ -3712,7 +3712,7 @@ int how; int res; - how = PyLong_AsLong(arg); + how = _PyLong_AsInt(arg); if (how == -1 && PyErr_Occurred()) return NULL; Py_BEGIN_ALLOW_THREADS diff -r c64dec45d46f Objects/fileobject.c --- a/Objects/fileobject.c Sun Sep 23 20:00:04 2012 +0200 +++ b/Objects/fileobject.c Sun Sep 23 21:46:54 2012 +0300 @@ -200,7 +200,7 @@ _Py_IDENTIFIER(fileno); if (PyLong_Check(o)) { - fd = PyLong_AsLong(o); + fd = _PyLong_AsInt(o); } else if ((meth = _PyObject_GetAttrId(o, &PyId_fileno)) != NULL) { @@ -210,7 +210,7 @@ return -1; if (PyLong_Check(fno)) { - fd = PyLong_AsLong(fno); + fd = _PyLong_AsInt(fno); Py_DECREF(fno); } else { diff -r c64dec45d46f Objects/longobject.c --- a/Objects/longobject.c Sun Sep 23 20:00:04 2012 +0200 +++ b/Objects/longobject.c Sun Sep 23 21:46:54 2012 +0300 @@ -434,6 +434,24 @@ return result; } +/* Get a C int from a long int object or any object that has an __int__ + method. Return -1 and set an error if overflow occurs. */ + +int +_PyLong_AsInt(PyObject *obj) +{ + int overflow; + long result = PyLong_AsLongAndOverflow(obj, &overflow); + if (overflow || result > INT_MAX || result < INT_MIN) { + /* XXX: could be cute and give a different + message for overflow == -1 */ + PyErr_SetString(PyExc_OverflowError, + "Python int too large to convert to C int"); + return -1; + } + return (int)result; +} + /* Get a Py_ssize_t from a long int object. Returns -1 and sets an error condition if overflow occurs. */ diff -r c64dec45d46f Objects/structseq.c --- a/Objects/structseq.c Sun Sep 23 20:00:04 2012 +0200 +++ b/Objects/structseq.c Sun Sep 23 21:46:54 2012 +0300 @@ -13,14 +13,14 @@ char *PyStructSequence_UnnamedField = "unnamed field"; #define VISIBLE_SIZE(op) Py_SIZE(op) -#define VISIBLE_SIZE_TP(tp) PyLong_AsLong( \ +#define VISIBLE_SIZE_TP(tp) PyLong_AsSsize_t( \ PyDict_GetItemString((tp)->tp_dict, visible_length_key)) -#define REAL_SIZE_TP(tp) PyLong_AsLong( \ +#define REAL_SIZE_TP(tp) PyLong_AsSsize_t( \ PyDict_GetItemString((tp)->tp_dict, real_length_key)) #define REAL_SIZE(op) REAL_SIZE_TP(Py_TYPE(op)) -#define UNNAMED_FIELDS_TP(tp) PyLong_AsLong( \ +#define UNNAMED_FIELDS_TP(tp) PyLong_AsSsize_t( \ PyDict_GetItemString((tp)->tp_dict, unnamed_fields_key)) #define UNNAMED_FIELDS(op) UNNAMED_FIELDS_TP(Py_TYPE(op)) @@ -161,7 +161,8 @@ #define TYPE_MAXSIZE 100 PyTypeObject *typ = Py_TYPE(obj); - int i, removelast = 0; + Py_ssize_t i; + int removelast = 0; Py_ssize_t len; char buf[REPR_BUFFER_SIZE]; char *endofbuf, *pbuf = buf; @@ -233,8 +234,7 @@ PyObject* tup; PyObject* dict; PyObject* result; - Py_ssize_t n_fields, n_visible_fields, n_unnamed_fields; - int i; + Py_ssize_t n_fields, n_visible_fields, n_unnamed_fields, i; n_fields = REAL_SIZE(self); n_visible_fields = VISIBLE_SIZE(self); @@ -320,7 +320,7 @@ { PyObject *dict; PyMemberDef* members; - int n_members, n_unnamed_members, i, k; + Py_ssize_t n_members, n_unnamed_members, i, k; #ifdef Py_TRACE_REFS /* if the type object was chained, unchain it first @@ -365,18 +365,18 @@ Py_INCREF(type); dict = type->tp_dict; -#define SET_DICT_FROM_INT(key, value) \ +#define SET_DICT_FROM_SIZE(key, value) \ do { \ - PyObject *v = PyLong_FromLong((long) value); \ + PyObject *v = PyLong_FromSsize_t(value); \ if (v != NULL) { \ PyDict_SetItemString(dict, key, v); \ Py_DECREF(v); \ } \ } while (0) - SET_DICT_FROM_INT(visible_length_key, desc->n_in_sequence); - SET_DICT_FROM_INT(real_length_key, n_members); - SET_DICT_FROM_INT(unnamed_fields_key, n_unnamed_members); + SET_DICT_FROM_SIZE(visible_length_key, desc->n_in_sequence); + SET_DICT_FROM_SIZE(real_length_key, n_members); + SET_DICT_FROM_SIZE(unnamed_fields_key, n_unnamed_members); } PyTypeObject* diff -r c64dec45d46f Objects/unicodeobject.c --- a/Objects/unicodeobject.c Sun Sep 23 20:00:04 2012 +0200 +++ b/Objects/unicodeobject.c Sun Sep 23 21:46:54 2012 +0300 @@ -13568,7 +13568,7 @@ "* wants int"); goto onError; } - width = PyLong_AsLong(v); + width = PyLong_AsSsize_t(v); if (width == -1 && PyErr_Occurred()) goto onError; if (width < 0) { @@ -13608,7 +13608,7 @@ "* wants int"); goto onError; } - prec = PyLong_AsLong(v); + prec = _PyLong_AsInt(v); if (prec == -1 && PyErr_Occurred()) goto onError; if (prec < 0) diff -r c64dec45d46f Python/Python-ast.c --- a/Python/Python-ast.c Sun Sep 23 20:00:04 2012 +0200 +++ b/Python/Python-ast.c Sun Sep 23 21:46:54 2012 +0300 @@ -730,7 +730,7 @@ return 1; } - i = (int)PyLong_AsLong(obj); + i = _PyLong_AsInt(obj); if (i == -1 && PyErr_Occurred()) return 1; *out = i; diff -r c64dec45d46f Python/compile.c --- a/Python/compile.c Sun Sep 23 20:00:04 2012 +0200 +++ b/Python/compile.c Sun Sep 23 21:46:54 2012 +0300 @@ -426,6 +426,7 @@ v = PyDict_GetItem(src, k); assert(PyLong_Check(v)); vi = PyLong_AS_LONG(v); + assert(!PyErr_Occurred()); scope = (vi >> SCOPE_OFFSET) & SCOPE_MASK; if (scope == scope_type || vi & flag) { @@ -1057,6 +1058,12 @@ Py_DECREF(t); return -1; } + arg = _PyLong_AsInt(v); + if (arg == -1 && PyErr_Occurred()) { + Py_DECREF(t); + Py_DECREF(v); + return -1; + } if (PyDict_SetItem(dict, t, v) < 0) { Py_DECREF(t); Py_DECREF(v); @@ -1065,7 +1072,7 @@ Py_DECREF(v); } else - arg = PyLong_AsLong(v); + arg = _PyLong_AsInt(v); Py_DECREF(t); return arg; } diff -r c64dec45d46f Python/pythonrun.c --- a/Python/pythonrun.c Sun Sep 23 20:00:04 2012 +0200 +++ b/Python/pythonrun.c Sun Sep 23 21:46:54 2012 +0300 @@ -1478,7 +1478,7 @@ parse_syntax_error(PyObject *err, PyObject **message, const char **filename, int *lineno, int *offset, const char **text) { - long hold; + int hold; PyObject *v; _Py_IDENTIFIER(msg); _Py_IDENTIFIER(filename); @@ -1510,11 +1510,11 @@ v = _PyObject_GetAttrId(err, &PyId_lineno); if (!v) goto finally; - hold = PyLong_AsLong(v); + hold = _PyLong_AsInt(v); Py_DECREF(v); if (hold < 0 && PyErr_Occurred()) goto finally; - *lineno = (int)hold; + *lineno = hold; v = _PyObject_GetAttrId(err, &PyId_offset); if (!v) @@ -1523,11 +1523,11 @@ *offset = -1; Py_DECREF(v); } else { - hold = PyLong_AsLong(v); + hold = _PyLong_AsInt(v); Py_DECREF(v); if (hold < 0 && PyErr_Occurred()) goto finally; - *offset = (int)hold; + *offset = hold; } v = _PyObject_GetAttrId(err, &PyId_text); From report at bugs.python.org Sun Sep 23 22:07:31 2012 From: report at bugs.python.org (Thomas Lee) Date: Sun, 23 Sep 2012 20:07:31 +0000 Subject: [issue15991] BaseHTTPServer with ThreadingMixIn serving wrong data sometimes In-Reply-To: <1348171381.08.0.748825821227.issue15991@psf.upfronthosting.co.za> Message-ID: <1348430851.03.0.732001191226.issue15991@psf.upfronthosting.co.za> Thomas Lee added the comment: I can reproduce this on Debian Wheezy. Both with the system Python (2.7.3rc2) and the 2.7 branch built from source. ---------- nosy: +thomaslee _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 22:51:51 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Sun, 23 Sep 2012 20:51:51 +0000 Subject: [issue15996] pow() for complex numbers is rough around the edges In-Reply-To: <1348178428.15.0.517718755216.issue15996@psf.upfronthosting.co.za> Message-ID: <1348433511.13.0.555748529525.issue15996@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea stage: test needed -> type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 23 22:52:39 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Sun, 23 Sep 2012 20:52:39 +0000 Subject: [issue15996] pow() for complex numbers is rough around the edges In-Reply-To: <1348178428.15.0.517718755216.issue15996@psf.upfronthosting.co.za> Message-ID: <1348433559.67.0.346551435544.issue15996@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- stage: -> test needed type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 00:01:24 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 23 Sep 2012 22:01:24 +0000 Subject: [issue15964] SyntaxError in asdl when building 2.7 with system Python 3 In-Reply-To: <1347978379.29.0.810502621141.issue15964@psf.upfronthosting.co.za> Message-ID: <1348437684.13.0.672535300275.issue15964@psf.upfronthosting.co.za> Martin v. L?wis added the comment: > Martin meant: > touch Include/Python-ast.h Python/Python-ast.c No, I *actually* meant 'make touch'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 00:05:32 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 23 Sep 2012 22:05:32 +0000 Subject: [issue15964] SyntaxError in asdl when building 2.7 with system Python 3 In-Reply-To: <1347978379.29.0.810502621141.issue15964@psf.upfronthosting.co.za> Message-ID: <1348437932.19.0.653067903063.issue15964@psf.upfronthosting.co.za> Martin v. L?wis added the comment: > Just to clarify, in the original scenario, "python" did not refer to > anything. From the original comment: > $ python > No such file or directory So can you find out why asdl_c.py actually printed this error? With no python executable in PATH, it shouldn't even run. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 01:45:22 2012 From: report at bugs.python.org (Joshua Landau) Date: Sun, 23 Sep 2012 23:45:22 +0000 Subject: [issue16010] Some Unicode in identifiers improperly rejected Message-ID: <1348443922.86.0.645371844145.issue16010@psf.upfronthosting.co.za> New submission from Joshua Landau: "a? = None" is not valid, even though unicodedata.normalize("NFKC", "?") == "1". One would expect "a? = None" and "a1 = None" to be equivalent in this case, as with "a? = None" and "ai = None". I am not sure how many other characters exhibit the same problem. References: http://docs.python.org/py3k/reference/lexical_analysis.html#identifiers http://mail.python.org/pipermail/python-list/2012-September/631420.html "?" === "\u00b9" "?" === "\u2071" ---------- components: Interpreter Core messages: 171082 nosy: Joshua.Landau priority: normal severity: normal status: open title: Some Unicode in identifiers improperly rejected versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 02:06:25 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 24 Sep 2012 00:06:25 +0000 Subject: [issue15991] BaseHTTPServer with ThreadingMixIn serving wrong data sometimes In-Reply-To: <1348171381.08.0.748825821227.issue15991@psf.upfronthosting.co.za> Message-ID: <1348445185.77.0.739721617695.issue15991@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I can reproduce under Debian testing, but not Debian stable nor Mageia 1. I think this is really a bug in recent Debian/Ubuntu wget. By instrumenting SocketServer, I see that less requests are received than expected (e.g. ~350 instead of 400). It seems wget is trying to send further requests on the same client socket, even though the server responded with a HTTP/1.0 status line and without a "connection: keep-alive" header, indicating it doesn't want keep-alive. Even explicitly sending a "connection: close" header doesn't seem to change wget's behaviour. If you pass "--no-keep-alive" to wget, though, it solves the issue. Running Wireshark would probably help confirm this. ---------- nosy: +neologix, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 02:13:42 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 24 Sep 2012 00:13:42 +0000 Subject: [issue15991] BaseHTTPServer with ThreadingMixIn serving wrong data sometimes In-Reply-To: <1348171381.08.0.748825821227.issue15991@psf.upfronthosting.co.za> Message-ID: <1348445622.84.0.483449825934.issue15991@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Note that forcing a content length on error responses also seems to make wget happy: diff --git a/Lib/BaseHTTPServer.py b/Lib/BaseHTTPServer.py --- a/Lib/BaseHTTPServer.py +++ b/Lib/BaseHTTPServer.py @@ -362,14 +362,19 @@ message = short explain = long self.log_error("code %d, message %s", code, message) - # using _quote_html to prevent Cross Site Scripting attacks (see bug #1100201) - content = (self.error_message_format % - {'code': code, 'message': _quote_html(message), 'explain': explain}) + if self.command != 'HEAD' and code >= 200 and code not in (204, 304): + # using _quote_html to prevent Cross Site Scripting attacks (see bug #1100201) + content = (self.error_message_format % + {'code': code, 'message': _quote_html(message), 'explain': explain}) + else: + content = None self.send_response(code, message) self.send_header("Content-Type", self.error_content_type) + if content is not None: + self.send_header("Content-Length", str(len(content))) self.send_header('Connection', 'close') self.end_headers() - if self.command != 'HEAD' and code >= 200 and code not in (204, 304): + if content is not None: self.wfile.write(content) error_message_format = DEFAULT_ERROR_MESSAGE ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 02:13:51 2012 From: report at bugs.python.org (Neal Parikh) Date: Mon, 24 Sep 2012 00:13:51 +0000 Subject: [issue16011] "in" should be consistent with return value of __contains__ Message-ID: <1348445631.47.0.961273834435.issue16011@psf.upfronthosting.co.za> New submission from Neal Parikh: The Python 2.7.3 documentation says the following about defining __contains__: "Called to implement membership test operators. Should return true if item is in self, false otherwise. For mapping objects, this should consider the keys of the mapping rather than the values or the key-item pairs." This suggests that while you should return True/False, you don't need to. Also, the documentation doesn't say that if you return a value other than True or False, it will silently coerce other values to be True or False when you use "in". For example: >>> class Foo(object): ... def __contains__(self, item): return 42 ... >>> foo = Foo() >>> 3 in foo True >>> foo.__contains__(3) 42 When __contains__ is defined, "in" should return whatever __contains__ returns, even if this value is neither True nor False. That would be consistent with, for example, the comparison operators: You can return anything from __lt__ and "x < 4" will correctly pass along that value regardless of what it is. ---------- assignee: docs at python components: Documentation, Interpreter Core messages: 171085 nosy: docs at python, nparikh priority: normal severity: normal status: open title: "in" should be consistent with return value of __contains__ type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 02:26:10 2012 From: report at bugs.python.org (Christian Heimes) Date: Mon, 24 Sep 2012 00:26:10 +0000 Subject: [issue16011] "in" should be consistent with return value of __contains__ In-Reply-To: <1348445631.47.0.961273834435.issue16011@psf.upfronthosting.co.za> Message-ID: <1348446370.53.0.430687883052.issue16011@psf.upfronthosting.co.za> Christian Heimes added the comment: The internal API is limited to flags as the sq_contains slot and the API function can only return an int: PyAPI_FUNC(int) PySequence_In(PyObject *o, PyObject *value) In order to return the Python object we'd have to alter the API which we can't do as the type slot and the function is part of the stable API and ABI. A doc update should explain why the code doesn't behave as you expect it. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 03:21:32 2012 From: report at bugs.python.org (Michael Domingues) Date: Mon, 24 Sep 2012 01:21:32 +0000 Subject: [issue1927] raw_input behavior incorrect if readline not enabled In-Reply-To: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za> Message-ID: <1348449692.1.0.123936775197.issue1927@psf.upfronthosting.co.za> Michael Domingues added the comment: The code that dictates this behavior is in /Parser/myreadline.c and has not been rectified yet in either Python 2.7 (http://hg.python.org/cpython/file/bfdf366a779a/Parser/myreadline.c#l107) or the default branch (http://hg.python.org/cpython/file/c64dec45d46f/Parser/myreadline.c#l111). Specifically, within these functions, references to standard error should actually be references to standard out. The attached file is a proposed patch for this bug on the 2.7 branch, bringing interpreter behavior into accordance with the Python documentation (http://docs.python.org/library/functions.html#raw_input), which states that the prompt is written to standard out, as opposed to standard error. ---------- keywords: +patch nosy: +mdomingues Added file: http://bugs.python.org/file27269/promptOutputFix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 03:26:29 2012 From: report at bugs.python.org (Michael Domingues) Date: Mon, 24 Sep 2012 01:26:29 +0000 Subject: [issue1927] raw_input behavior incorrect if readline not enabled In-Reply-To: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za> Message-ID: <1348449989.21.0.565575217253.issue1927@psf.upfronthosting.co.za> Michael Domingues added the comment: Also uploading a patch for the Python3.2 branch. ---------- Added file: http://bugs.python.org/file27270/promptOutputFix3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 03:40:37 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 24 Sep 2012 01:40:37 +0000 Subject: [issue16010] Some Unicode in identifiers improperly rejected In-Reply-To: <1348443922.86.0.645371844145.issue16010@psf.upfronthosting.co.za> Message-ID: <1348450837.51.0.215132231111.issue16010@psf.upfronthosting.co.za> R. David Murray added the comment: I find it unexpected that a? and ai name the same variable, but I suppose that is a consequence of the unicode normalization rules (meaning what I really find surprising is the normalization). As for the '?', its category is No, which does not appear in the list in the identifiers section you link to, while '?' is Lm, which does. So there is no bug here. ---------- nosy: +r.david.murray stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 03:53:53 2012 From: report at bugs.python.org (Guy Rozendorn) Date: Mon, 24 Sep 2012 01:53:53 +0000 Subject: [issue10760] tarfile doesn't handle sysfs well In-Reply-To: <1293037554.87.0.808780630488.issue10760@psf.upfronthosting.co.za> Message-ID: <1348451633.78.0.894636371943.issue10760@psf.upfronthosting.co.za> Guy Rozendorn added the comment: Here's a test case that re-creates this issue. I chose to use mocks instead of sample files from sysfs so it would be simpler to run, it can be easily changed to use a file from sysfs. The following code runs on Python2.7, requires the mock library {code} from unittest import TestCase from tempfile import mkstemp from mock import patch, Mock from os import close, remove, write, stat from posix import stat_result from tarfile import TarFile def fake_st_size_side_effect(*args, **kwargs): src, = args stats = stat(src) return stat_result((stats.st_mode, stats.st_ino, stats.st_dev, stats.st_nlink, stats.st_uid, stats.st_gid, stats.st_size + 10, stats.st_atime, stats.st_mtime, stats.st_ctime)) class Issue10760TestCase(TestCase): def setUp(self): fd, self.src = mkstemp() write(fd, '\x00' * 4) close(fd) fd, self.dst = mkstemp() close(fd) def test(self): with patch("os.lstat") as lstat: lstat.side_effect = fake_st_size_side_effect tar_file = TarFile.open(self.dst, 'w:gz') tar_file.add(self.src) {code} ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 05:37:47 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 24 Sep 2012 03:37:47 +0000 Subject: [issue15964] SyntaxError in asdl when building 2.7 with system Python 3 In-Reply-To: <1347978379.29.0.810502621141.issue15964@psf.upfronthosting.co.za> Message-ID: <1348457867.8.0.44835254467.issue15964@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > So can you find out why asdl_c.py actually printed this error? I collected some additional information. Here is the beginning of Parser/asdl_c.py: #! /usr/bin/env python """Generate C code from an ASDL description.""" And in the scenario of this issue I have-- $ python -bash: /opt/local/Library/Frameworks/Python.framework/Versions/Current/bin/python: No such file or directory But-- $ /usr/bin/env python -V Python 3.2.3 Some more data: $ /usr/bin/env python -c "import sys; print(sys.executable)" /opt/local/Library/Frameworks/Python.framework/Versions/3.2/Resources/Python.app/Contents/MacOS/Python $ echo $PATH /opt/local/Library/Frameworks/Python.framework/Versions/Current/bin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/git/bin:/usr/texbin $ which python /opt/local/bin/python $ /opt/local/bin/python -c "import sys; print(sys.executable)" /opt/local/Library/Frameworks/Python.framework/Versions/3.2/Resources/Python.app/Contents/MacOS/Python It's not immediately clear to me why running `python` doesn't find python in the second $PATH entry even though `which python` does. Also, creating a new terminal doesn't seem to exhibit the same problem, so the error state may not be fully reproducible after all (at least on my machine). In any case, Christian's work-around does resolve the issue for this particular error state while other solutions don't. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 05:55:03 2012 From: report at bugs.python.org (Ned Deily) Date: Mon, 24 Sep 2012 03:55:03 +0000 Subject: [issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0 In-Reply-To: <1344473974.14.0.584788696764.issue15599@psf.upfronthosting.co.za> Message-ID: <1348458903.77.0.238989222112.issue15599@psf.upfronthosting.co.za> Ned Deily added the comment: OS X 10.4 (and presumably earlier versions) also does not handle the low switchinterval gracefully. Monitoring system activity and running with -v, test_threaded_import does seem to progress but *very* slowly (I quit after 45 minutes with the test only partially complete) at 100% CPU (mainly sys time). 10.5 and later systems are fine. Here's a patch that extends the FreeBSD solution to OS X 10.4 systems. ---------- nosy: +ned.deily Added file: http://bugs.python.org/file27271/issue15599_osx_10_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 07:42:21 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 24 Sep 2012 05:42:21 +0000 Subject: [issue16011] "in" should be consistent with return value of __contains__ In-Reply-To: <1348445631.47.0.961273834435.issue16011@psf.upfronthosting.co.za> Message-ID: <1348465341.4.0.0180420280326.issue16011@psf.upfronthosting.co.za> Ezio Melotti added the comment: http://docs.python.org/py3k/reference/datamodel.html#object.__contains__ says that __contain__ "Should return true if item is in self, false otherwise.". Here the lowercase true and false mean any true or false value, not just True and False and it's indeed possible to return any value. The fact that 'in' only returns True/False, possibly converting the return value of __contains__, should be documented in the 'in' documentation. http://docs.python.org/py3k/reference/expressions.html#membership-test-details says "For user-defined classes which define the __contains__() method, x in y is true if and only if y.__contains__(x) is true.". This could be changed to say that the return value is converted to True/False. ---------- keywords: +easy nosy: +ezio.melotti stage: -> needs patch versions: +Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 07:46:45 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 24 Sep 2012 05:46:45 +0000 Subject: [issue15895] PyRun_SimpleFileExFlags() can leak a FILE pointer In-Reply-To: <1347231050.54.0.0211027720618.issue15895@psf.upfronthosting.co.za> Message-ID: <3XQDtr28vszMgl@mail.python.org> Roundup Robot added the comment: New changeset fe4e6e0d6b0f by Christian Heimes in branch 'default': Issue #15895: Fix FILE pointer leak in PyRun_SimpleFileExFlags() when filename points to a pyc/pyo file and closeit is false. http://hg.python.org/cpython/rev/fe4e6e0d6b0f New changeset 9251fb0440a0 by Christian Heimes in branch 'default': Issue #15895: my analysis was slightly off. The FILE pointer is only leaked when set_main_loader() fails for a pyc file with closeit=0. In the success case run_pyc_file() does its own cleanup of the fp. I've changed the code to use another FILE ptr for pyc files and moved the fclose() to PyRun_SimpleFileExFlags() to make it more obvious what's happening. http://hg.python.org/cpython/rev/9251fb0440a0 New changeset 61b1c25d55f2 by Christian Heimes in branch 'default': Updates NEWS for issue #15895 http://hg.python.org/cpython/rev/61b1c25d55f2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 07:46:46 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 24 Sep 2012 05:46:46 +0000 Subject: [issue15900] Memory leak in PyUnicode_TranslateCharmap() In-Reply-To: <1347271102.51.0.468950657705.issue15900@psf.upfronthosting.co.za> Message-ID: <3XQDts0mF7zMgl@mail.python.org> Roundup Robot added the comment: New changeset 89f62f143920 by Christian Heimes in branch 'default': Issue #15900: Fixed reference leak in PyUnicode_TranslateCharmap() http://hg.python.org/cpython/rev/89f62f143920 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 07:46:47 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 24 Sep 2012 05:46:47 +0000 Subject: [issue15925] email.utils.parsedate() and email.utils.parsedate_tz() should return None when date cannot be parsed In-Reply-To: <1347410265.94.0.383870526813.issue15925@psf.upfronthosting.co.za> Message-ID: <3XQDts6M6qzMgl@mail.python.org> Roundup Robot added the comment: New changeset c1e9a1fc6931 by Georg Brandl in branch 'default': Closes #15925: fix regression in parsedate() and parsedate_tz() that should return None if unable to parse the argument. http://hg.python.org/cpython/rev/c1e9a1fc6931 ---------- stage: commit review -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 07:46:48 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 24 Sep 2012 05:46:48 +0000 Subject: [issue15926] Segmentation fault after multiple reinitializations In-Reply-To: <1347419581.97.0.0354883385349.issue15926@psf.upfronthosting.co.za> Message-ID: <3XQDtt4tmkzMgl@mail.python.org> Roundup Robot added the comment: New changeset 6708224f8bee by Antoine Pitrou in branch 'default': Issue #15926: Fix crash after multiple reinitializations of the interpreter. http://hg.python.org/cpython/rev/6708224f8bee ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 07:46:48 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 24 Sep 2012 05:46:48 +0000 Subject: [issue15977] Memory leak in _ssl.c In-Reply-To: <1348092120.32.0.751173728211.issue15977@psf.upfronthosting.co.za> Message-ID: <3XQDtv3LvGzMlF@mail.python.org> Roundup Robot added the comment: New changeset 4cf53684e14e by Christian Heimes in branch 'default': Issue #15977: Fix memory leak in Modules/_ssl.c when the function _set_npn_protocols() is called multiple times http://hg.python.org/cpython/rev/4cf53684e14e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 07:46:50 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 24 Sep 2012 05:46:50 +0000 Subject: [issue15973] Segmentation fault on timezone comparison In-Reply-To: <1348077797.35.0.854267629086.issue15973@psf.upfronthosting.co.za> Message-ID: <3XQDtw1y53zN8C@mail.python.org> Roundup Robot added the comment: New changeset ec77f8fb9958 by Georg Brandl in branch 'default': Closes #15973: fix a segmentation fault when comparing timezone objects. http://hg.python.org/cpython/rev/ec77f8fb9958 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 07:46:50 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 24 Sep 2012 05:46:50 +0000 Subject: [issue15969] faulthandler: drop S from dump_tracebacks_later() function name to have consistent names In-Reply-To: <1348001825.94.0.454810241369.issue15969@psf.upfronthosting.co.za> Message-ID: <3XQDtx0rp2zNXr@mail.python.org> Roundup Robot added the comment: New changeset eede0bf3ceac by Georg Brandl in branch 'default': Closes #15969: rename new API to have consistent names in the faulthandler module. http://hg.python.org/cpython/rev/eede0bf3ceac ---------- stage: -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 07:46:51 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 24 Sep 2012 05:46:51 +0000 Subject: [issue15882] _decimal.Decimal constructed from tuple In-Reply-To: <1347058075.63.0.395926246222.issue15882@psf.upfronthosting.co.za> Message-ID: <3XQDty2jLLzNWB@mail.python.org> Roundup Robot added the comment: New changeset d22ea2aa1057 by Stefan Krah in branch 'default': Issue #15882: Change _decimal to accept any coefficient tuple when http://hg.python.org/cpython/rev/d22ea2aa1057 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 08:32:43 2012 From: report at bugs.python.org (DDarko) Date: Mon, 24 Sep 2012 06:32:43 +0000 Subject: [issue16005] smtplib.SMTP().sendmail() and rset() In-Reply-To: <1348402885.58.0.691449233826.issue16005@psf.upfronthosting.co.za> Message-ID: <1348468363.48.0.732343986693.issue16005@psf.upfronthosting.co.za> DDarko added the comment: I understand, in that case: /cpython/file/default/Lib/smtplib.py 760c760,761 < self.rset() --- > try: self.rset() > except: pass Solves the problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 08:56:21 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 24 Sep 2012 06:56:21 +0000 Subject: [issue15121] devguide doesn't document all bug tracker components In-Reply-To: <1340275042.61.0.991678411408.issue15121@psf.upfronthosting.co.za> Message-ID: <1348469781.19.0.999469529963.issue15121@psf.upfronthosting.co.za> Ezio Melotti added the comment: > I suspect it's automatically set for issues reported via email Apparently it's set automatically on new issues if no other component is specified, even if the issue is created from the web interface. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 10:56:25 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 24 Sep 2012 08:56:25 +0000 Subject: [issue16011] "in" should be consistent with return value of __contains__ In-Reply-To: <1348445631.47.0.961273834435.issue16011@psf.upfronthosting.co.za> Message-ID: <1348476985.29.0.412500443782.issue16011@psf.upfronthosting.co.za> Mark Dickinson added the comment: There was a related discussion on python-ideas a while back: http://mail.python.org/pipermail/python-ideas/2010-July/007733.html ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 11:22:36 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 24 Sep 2012 09:22:36 +0000 Subject: [issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0 In-Reply-To: <1344473974.14.0.584788696764.issue15599@psf.upfronthosting.co.za> Message-ID: <1348478556.9.0.0750616287927.issue15599@psf.upfronthosting.co.za> Stefan Krah added the comment: test_threaded_import also takes around 5 min on Windows. I think we should go for 0.00001 on all platforms. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 11:24:22 2012 From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=) Date: Mon, 24 Sep 2012 09:24:22 +0000 Subject: [issue8425] a -= b should be fast if a is a small set and b is a large set In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za> Message-ID: <1348478662.95.0.500450526444.issue8425@psf.upfronthosting.co.za> Michele Orr? added the comment: Reviewed with Ezio. ---------- Added file: http://bugs.python.org/file27272/issue8425.1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 11:36:03 2012 From: report at bugs.python.org (Sreenivas) Date: Mon, 24 Sep 2012 09:36:03 +0000 Subject: [issue15998] Python GUI idle not working In-Reply-To: <1348223430.53.0.95377552699.issue15998@psf.upfronthosting.co.za> Message-ID: <1348479363.97.0.554751184443.issue15998@psf.upfronthosting.co.za> Sreenivas added the comment: Hi All, I was able to solve the problem.I reinstalled the python overwriting the lib packages of the previously installed Python.I was not overwriting it before because I was afraid that I would lose my pyserial and cx_Freeze lib files.But it was still there and was not deleted :).Thanks guys for your help and answers.I wish I get some other issue and get back to the forum asap. cheers, Sreeni ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 12:10:05 2012 From: report at bugs.python.org (Erich Seifert) Date: Mon, 24 Sep 2012 10:10:05 +0000 Subject: [issue16012] pyexpat: Argument for UseForeignDTD should be optional Message-ID: <1348481405.23.0.796569447482.issue16012@psf.upfronthosting.co.za> New submission from Erich Seifert: It seems the recent changes to Modules/pyexpat.c made the boolean 'flag' for UseForeignDTD mandatory although it was optional in previous Python releases. According to the docs the usage is UseForeignDTD([flag]), but calling UseForeignDTD without arguments leads to an error:: >>> from xml.parsers import expat >>> parser = expat.ParserCreate('utf8') >>> parser.UseForeignDTD() Traceback (most recent call last): File "", line 1, in TypeError: UseForeignDTD() takes exactly 1 argument (0 given) This was tested with version bfdf366a779a from hg repository. ---------- components: Extension Modules messages: 171108 nosy: eseifert priority: normal severity: normal status: open title: pyexpat: Argument for UseForeignDTD should be optional type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 12:31:07 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 24 Sep 2012 10:31:07 +0000 Subject: [issue15979] Improve timeit documentation In-Reply-To: <1348111607.58.0.268885940785.issue15979@psf.upfronthosting.co.za> Message-ID: <1348482667.82.0.465721180901.issue15979@psf.upfronthosting.co.za> Ezio Melotti added the comment: Here's a patch. ---------- assignee: docs at python -> ezio.melotti keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file27273/issue15979.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 12:36:39 2012 From: report at bugs.python.org (Christian Heimes) Date: Mon, 24 Sep 2012 10:36:39 +0000 Subject: [issue16012] pyexpat: Argument for UseForeignDTD should be optional In-Reply-To: <1348481405.23.0.796569447482.issue16012@psf.upfronthosting.co.za> Message-ID: <1348482999.59.0.766430457315.issue16012@psf.upfronthosting.co.za> Christian Heimes added the comment: Confirmed! In Ubuntu's Python 2.7.3 and 3.2.3 UseForeignDTD() can be called without an argument. The hg versions of 2.7, 3.2 and 3.3 require one argument. The change smells like a regression for all affected Python versions. Antoine, it looks like you committed the modification. ---------- keywords: +3.2regression, 3.3regression nosy: +benjamin.peterson, christian.heimes, georg.brandl, pitrou priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 12:42:16 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 24 Sep 2012 10:42:16 +0000 Subject: [issue16012] pyexpat: Argument for UseForeignDTD should be optional In-Reply-To: <1348481405.23.0.796569447482.issue16012@psf.upfronthosting.co.za> Message-ID: <1348483336.96.0.142895086166.issue16012@psf.upfronthosting.co.za> Ezio Melotti added the comment: This seems to be the changeset that introduced the regression b878df1d23b1. ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 12:46:04 2012 From: report at bugs.python.org (Christian Heimes) Date: Mon, 24 Sep 2012 10:46:04 +0000 Subject: [issue16012] pyexpat: Argument for UseForeignDTD should be optional In-Reply-To: <1348481405.23.0.796569447482.issue16012@psf.upfronthosting.co.za> Message-ID: <1348483564.19.0.708891478024.issue16012@psf.upfronthosting.co.za> Christian Heimes added the comment: I've created a patch with a simple test case. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file27274/issue16012.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 12:49:44 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 24 Sep 2012 10:49:44 +0000 Subject: [issue16012] pyexpat: Argument for UseForeignDTD should be optional In-Reply-To: <1348481405.23.0.796569447482.issue16012@psf.upfronthosting.co.za> Message-ID: <1348483784.8.0.78396930672.issue16012@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ah, that's true. Too bad it wasn't tested for :( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 12:52:14 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 24 Sep 2012 10:52:14 +0000 Subject: [issue15979] Improve timeit documentation In-Reply-To: <1348111607.58.0.268885940785.issue15979@psf.upfronthosting.co.za> Message-ID: <1348483934.34.0.607912426718.issue15979@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't think there's a need for two separate examples sections (one "basic examples" and one "examples"). Also, you say a couple of times "The equivalent can be achieved from the :ref:`python-interface`", but that's not true since the command-line interface auto-calibrates, which the Python API (unfortunately) doesn't. Besides, the results use different units and can't be directly compared. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 12:54:47 2012 From: report at bugs.python.org (Christian Heimes) Date: Mon, 24 Sep 2012 10:54:47 +0000 Subject: [issue16012] pyexpat: Argument for UseForeignDTD should be optional In-Reply-To: <1348481405.23.0.796569447482.issue16012@psf.upfronthosting.co.za> Message-ID: <1348484087.11.0.969489092529.issue16012@psf.upfronthosting.co.za> Christian Heimes added the comment: Don't feel bad. The final hasn't been released yet. :) Here is a slightly different patch for 3.2 and 2.7. ---------- Added file: http://bugs.python.org/file27275/issue16012_py32.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 12:57:45 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 24 Sep 2012 10:57:45 +0000 Subject: [issue15979] Improve timeit documentation In-Reply-To: <1348111607.58.0.268885940785.issue15979@psf.upfronthosting.co.za> Message-ID: <1348484265.12.0.220519760287.issue15979@psf.upfronthosting.co.za> Ezio Melotti added the comment: The first example shows the basic usage and it's right at the beginning, all the other "advanced" examples are at the bottom. About the autocalibration you are right, I'll rephrase the sentence (see also #6422). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 13:28:15 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 24 Sep 2012 11:28:15 +0000 Subject: [issue8425] a -= b should be fast if a is a small set and b is a large set In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za> Message-ID: <1348486095.33.0.30535583821.issue8425@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > $ ./python.exe -m timeit -s "s= set(range(2000)); l = set(range(20000000)); s=s-l" You are measure empty loop. ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 13:28:20 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 24 Sep 2012 11:28:20 +0000 Subject: [issue16012] pyexpat: Argument for UseForeignDTD should be optional In-Reply-To: <1348481405.23.0.796569447482.issue16012@psf.upfronthosting.co.za> Message-ID: <3XQNSz0756zNPb@mail.python.org> Roundup Robot added the comment: New changeset 22ddf77e0497 by Christian Heimes in branch '3.2': Issue #16012: Fix a regression in pyexpat. The parser's UseForeignDTD() http://hg.python.org/cpython/rev/22ddf77e0497 New changeset 3e0d632ce910 by Christian Heimes in branch '2.7': Issue #16012: Fix a regression in pyexpat. The parser's UseForeignDTD() http://hg.python.org/cpython/rev/3e0d632ce910 New changeset 0f55ad9b07c8 by Christian Heimes in branch 'default': Issue #16012: Fix a regression in pyexpat. The parser's UseForeignDTD() http://hg.python.org/cpython/rev/0f55ad9b07c8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 13:32:42 2012 From: report at bugs.python.org (Christian Heimes) Date: Mon, 24 Sep 2012 11:32:42 +0000 Subject: [issue16012] pyexpat: Argument for UseForeignDTD should be optional In-Reply-To: <1348481405.23.0.796569447482.issue16012@psf.upfronthosting.co.za> Message-ID: <1348486362.28.0.764834039473.issue16012@psf.upfronthosting.co.za> Christian Heimes added the comment: Erich, thank you very much for your bug report. Your report made it right in time for the upcoming 3.3.0 final release. Here you are, Georg. ---------- assignee: -> georg.brandl resolution: -> fixed stage: patch review -> committed/rejected status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 13:42:18 2012 From: report at bugs.python.org (Georg Brandl) Date: Mon, 24 Sep 2012 11:42:18 +0000 Subject: [issue16012] pyexpat: Argument for UseForeignDTD should be optional In-Reply-To: <1348481405.23.0.796569447482.issue16012@psf.upfronthosting.co.za> Message-ID: <1348486938.38.0.779952485904.issue16012@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in release clone as b907f99272c5. ---------- status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 14:50:32 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 24 Sep 2012 12:50:32 +0000 Subject: [issue15963] Improve ./configure's support for 32/64-bit debug|release|profiled builds w/ vendor (non-gcc) compilers on proprietary UNIX systems (Solaris/HP-UX/AIX et al). In-Reply-To: <1347975635.66.0.0788814924298.issue15963@psf.upfronthosting.co.za> Message-ID: <1348491032.52.0.320482850529.issue15963@psf.upfronthosting.co.za> Stefan Krah added the comment: I'm glad I found this. Without the long incantation _decimal is seriously miscompiled on SPARC/Solaris 10/Sun Studio 12.3. I was using just ... ./configure --without-gcc CFLAGS=-m64 LDFLAGS=-m64 ..., and that seems to trigger an optimizer bug that produces different output for _mpd_div_words_r() when called with exactly the same input at different locations. The line that Trent gave appears to work. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 15:03:12 2012 From: report at bugs.python.org (Armin Rigo) Date: Mon, 24 Sep 2012 13:03:12 +0000 Subject: [issue16013] small csv reader bug Message-ID: <1348491792.39.0.00618601585478.issue16013@psf.upfronthosting.co.za> New submission from Armin Rigo: A small bug of cvs.reader(): >>> list(csv.reader(['foo:"'], delimiter=':', quotechar='"')) [] Adding strict=True doesn't change anything. This is caused by the opening quote not followed by anything, which causes the error to be silently ignored and the last line to be dropped. ---------- components: Library (Lib) messages: 171122 nosy: arigo priority: normal severity: normal status: open title: small csv reader bug versions: Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 15:29:42 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 24 Sep 2012 13:29:42 +0000 Subject: [issue16005] smtplib.SMTP().sendmail() and rset() In-Reply-To: <1348402885.58.0.691449233826.issue16005@psf.upfronthosting.co.za> Message-ID: <1348493382.03.0.631613924979.issue16005@psf.upfronthosting.co.za> R. David Murray added the comment: Well, a bare except is almost always a bad idea, and certainly is in this case. I'll create a patch for this if no one beats me to it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 15:33:06 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 24 Sep 2012 13:33:06 +0000 Subject: [issue16008] [OS bug] DragonFly buildbot locale failures In-Reply-To: <1348417046.98.0.868158442098.issue16008@psf.upfronthosting.co.za> Message-ID: <1348493586.03.0.402311917591.issue16008@psf.upfronthosting.co.za> Stefan Krah added the comment: Closing since this an OS bug. ---------- resolution: -> wont fix stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 15:48:33 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 24 Sep 2012 13:48:33 +0000 Subject: [issue16014] Incomplete link in docs Message-ID: <1348494513.71.0.115486808135.issue16014@psf.upfronthosting.co.za> New submission from Ramchandra Apte: In http://docs.python.org/py3k/license.html#mersenne-twister, the link http://www.math.keio.ac.jp/ matumoto/MT2002/emt19937ar.html is not complete because there is a space in it. ---------- assignee: docs at python components: Documentation messages: 171125 nosy: docs at python, ramchandra.apte priority: normal severity: normal status: open title: Incomplete link in docs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 15:53:02 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 24 Sep 2012 13:53:02 +0000 Subject: [issue16015] Incorrect startup header in tutorial Message-ID: <1348494782.32.0.720891839928.issue16015@psf.upfronthosting.co.za> New submission from Ramchandra Apte: In http://docs.python.org/py3k/tutorial/interpreter.html#interactive-mode , the header shown is "Python 3.2 (py3k, Sep 12 2007, 12:21:02)". Python 3.2 was no made in Sep 12 2007, so it could not be compiled at that time. It should be a correct date or the date of today. ---------- assignee: docs at python components: Documentation messages: 171126 nosy: docs at python, ramchandra.apte priority: normal severity: normal status: open title: Incorrect startup header in tutorial _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 15:58:35 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 24 Sep 2012 13:58:35 +0000 Subject: [issue16014] Incomplete link in docs In-Reply-To: <1348494513.71.0.115486808135.issue16014@psf.upfronthosting.co.za> Message-ID: <3XQRpL2mwyzN1x@mail.python.org> Roundup Robot added the comment: New changeset 5f19c505ecea by Ezio Melotti in branch '2.7': #16014: fix broken link. http://hg.python.org/cpython/rev/5f19c505ecea New changeset 74b4c8c2894f by Ezio Melotti in branch '3.2': #16014: fix broken link. http://hg.python.org/cpython/rev/74b4c8c2894f New changeset 6db739d611fd by Ezio Melotti in branch 'default': #16014: merge with 3.2. http://hg.python.org/cpython/rev/6db739d611fd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 15:59:05 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 24 Sep 2012 13:59:05 +0000 Subject: [issue16014] Incomplete link in docs In-Reply-To: <1348494513.71.0.115486808135.issue16014@psf.upfronthosting.co.za> Message-ID: <1348495145.2.0.282774236847.issue16014@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the report! ---------- assignee: docs at python -> ezio.melotti nosy: +ezio.melotti resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 15:59:11 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 24 Sep 2012 13:59:11 +0000 Subject: [issue16016] Maybe make one author in ipaddress HOWTO Message-ID: <1348495151.31.0.0905378753903.issue16016@psf.upfronthosting.co.za> New submission from Ramchandra Apte: In http://docs.python.org/dev/howto/ipaddress.html, I think there should be one author field with "Peter Moody and Nick Coghlan" on the right side. ---------- assignee: docs at python components: Documentation messages: 171129 nosy: docs at python, ramchandra.apte priority: normal severity: normal status: open title: Maybe make one author in ipaddress HOWTO versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 16:03:19 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 24 Sep 2012 14:03:19 +0000 Subject: [issue16017] "urls" should be capital in tutorial Message-ID: <1348495399.07.0.504496501292.issue16017@psf.upfronthosting.co.za> New submission from Ramchandra Apte: In http://docs.python.org/py3k/tutorial/stdlib.html#internet-access , "from urls" should be "from URLs". ---------- assignee: docs at python components: Documentation messages: 171130 nosy: docs at python, ramchandra.apte priority: normal severity: normal status: open title: "urls" should be capital in tutorial versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 16:08:26 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 24 Sep 2012 14:08:26 +0000 Subject: [issue16017] "urls" should be capital in tutorial In-Reply-To: <1348495399.07.0.504496501292.issue16017@psf.upfronthosting.co.za> Message-ID: <3XQS1j0x21zNZ1@mail.python.org> Roundup Robot added the comment: New changeset 063a052af878 by Ezio Melotti in branch '2.7': #16017: capitalize URLs. http://hg.python.org/cpython/rev/063a052af878 New changeset d7455cceb917 by Ezio Melotti in branch '3.2': #16017: capitalize URLs. http://hg.python.org/cpython/rev/d7455cceb917 New changeset d6e4080960a3 by Ezio Melotti in branch 'default': #16017: merge with 3.2. http://hg.python.org/cpython/rev/d6e4080960a3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 16:09:07 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 24 Sep 2012 14:09:07 +0000 Subject: [issue16017] "urls" should be capital in tutorial In-Reply-To: <1348495399.07.0.504496501292.issue16017@psf.upfronthosting.co.za> Message-ID: <1348495747.78.0.654328994969.issue16017@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the report. ---------- assignee: docs at python -> ezio.melotti nosy: +ezio.melotti resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> enhancement versions: +Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 16:10:04 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 24 Sep 2012 14:10:04 +0000 Subject: [issue16016] Maybe make one author in ipaddress HOWTO In-Reply-To: <1348495151.31.0.0905378753903.issue16016@psf.upfronthosting.co.za> Message-ID: <1348495804.9.0.562796617691.issue16016@psf.upfronthosting.co.za> Ezio Melotti added the comment: I think it's OK to have two. ---------- nosy: +ezio.melotti resolution: -> rejected stage: -> committed/rejected status: open -> closed type: -> enhancement versions: +Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 16:12:18 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 24 Sep 2012 14:12:18 +0000 Subject: [issue16015] Incorrect startup header in tutorial In-Reply-To: <1348494782.32.0.720891839928.issue16015@psf.upfronthosting.co.za> Message-ID: <1348495938.72.0.0504207787054.issue16015@psf.upfronthosting.co.za> Ezio Melotti added the comment: Looks like the version got updated but not the rest, even the 3.3 doc has the same date. ---------- nosy: +ezio.melotti stage: -> needs patch type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 16:14:31 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 24 Sep 2012 14:14:31 +0000 Subject: [issue16015] Incorrect startup header in tutorial In-Reply-To: <1348494782.32.0.720891839928.issue16015@psf.upfronthosting.co.za> Message-ID: <1348496071.53.0.0134974299459.issue16015@psf.upfronthosting.co.za> Ramchandra Apte added the comment: The later lines also needs to be updated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 16:17:29 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 24 Sep 2012 14:17:29 +0000 Subject: [issue16015] impossible ... line in tutorial In-Reply-To: <1348494782.32.0.720891839928.issue16015@psf.upfronthosting.co.za> Message-ID: <1348496249.11.0.396298834681.issue16015@psf.upfronthosting.co.za> Ramchandra Apte added the comment: In http://docs.python.org/dev/tutorial/introduction.html, there is an ... line which is impossible in that case: Variables must be ?defined? (assigned a value) before they can be used, or an error will occur: >>> >>> # try to access an undefined variable ... n Traceback (most recent call last): File "", line 1, in NameError: name 'n' is not defined It should be: >>> n # try to access an undefined variable Traceback (most recent call last): File "", line 1, in NameError: name 'n' is not defined ---------- title: Incorrect startup header in tutorial -> impossible ... line in tutorial _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 16:18:17 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 24 Sep 2012 14:18:17 +0000 Subject: [issue16015] impossible ... line in tutorial In-Reply-To: <1348494782.32.0.720891839928.issue16015@psf.upfronthosting.co.za> Message-ID: <1348496297.53.0.491016923755.issue16015@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Oops! The last message should be in a new issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 16:18:47 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 24 Sep 2012 14:18:47 +0000 Subject: [issue16015] Incorrect startup header in tutorial In-Reply-To: <1348494782.32.0.720891839928.issue16015@psf.upfronthosting.co.za> Message-ID: <1348496327.91.0.735010926858.issue16015@psf.upfronthosting.co.za> Changes by Ramchandra Apte : ---------- title: impossible ... line in tutorial -> Incorrect startup header in tutorial _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 16:19:30 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 24 Sep 2012 14:19:30 +0000 Subject: [issue16018] Impossible ... line in tutorial Message-ID: <1348496370.31.0.7411232442.issue16018@psf.upfronthosting.co.za> New submission from Ramchandra Apte: In http://docs.python.org/dev/tutorial/introduction.html, there is an ... line which is impossible in that case: Variables must be ?defined? (assigned a value) before they can be used, or an error will occur: >>> >>> # try to access an undefined variable ... n Traceback (most recent call last): File "", line 1, in NameError: name 'n' is not defined It should be: >>> n # try to access an undefined variable Traceback (most recent call last): File "", line 1, in NameError: name 'n' is not defined ---------- messages: 171138 nosy: ramchandra.apte priority: normal severity: normal status: open title: Impossible ... line in tutorial _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 16:19:53 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 24 Sep 2012 14:19:53 +0000 Subject: [issue16018] Impossible ... line in tutorial In-Reply-To: <1348496370.31.0.7411232442.issue16018@psf.upfronthosting.co.za> Message-ID: <1348496393.53.0.0485951419373.issue16018@psf.upfronthosting.co.za> Changes by Ramchandra Apte : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 16:20:04 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 24 Sep 2012 14:20:04 +0000 Subject: [issue16015] Incorrect startup header in tutorial In-Reply-To: <1348494782.32.0.720891839928.issue16015@psf.upfronthosting.co.za> Message-ID: <1348496404.45.0.858619095864.issue16015@psf.upfronthosting.co.za> Ezio Melotti added the comment: I'm not sure it's worth updating it, it will probably get outdated again when new versions are released. Also this is just an example, the actual header and dates might be different depending on the version/.OS/compiler. ---------- versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 16:22:16 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 24 Sep 2012 14:22:16 +0000 Subject: [issue16018] Impossible ... line in tutorial In-Reply-To: <1348496370.31.0.7411232442.issue16018@psf.upfronthosting.co.za> Message-ID: <1348496536.73.0.820722274855.issue16018@psf.upfronthosting.co.za> Ezio Melotti added the comment: Is it? Python 3.2.3 (default, May 3 2012, 15:54:42) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> # try to access an undefined variable ... n Traceback (most recent call last): File "", line 2, in NameError: name 'n' is not defined >>> ---------- nosy: +ezio.melotti resolution: -> invalid stage: -> committed/rejected status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 16:23:45 2012 From: report at bugs.python.org (Roger Serwy) Date: Mon, 24 Sep 2012 14:23:45 +0000 Subject: [issue15998] Python GUI idle not working In-Reply-To: <1348223430.53.0.95377552699.issue15998@psf.upfronthosting.co.za> Message-ID: <1348496625.01.0.96083429439.issue15998@psf.upfronthosting.co.za> Roger Serwy added the comment: A re-install fixed the issue for OP caused by what appeared to be a corrupt /Lib directory. I'm closing this issue. ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 16:23:57 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 24 Sep 2012 14:23:57 +0000 Subject: [issue16019] Python highlighting in tutorial; should be text highlighting Message-ID: <1348496637.1.0.121151069885.issue16019@psf.upfronthosting.co.za> New submission from Ramchandra Apte: In http://docs.python.org/py3k/tutorial/stdlib2.html#logging , a text output has Python highlighting; it should be text highlighting This is incorrectly highlighted text: WARNING:root:Warning:config file server.conf not found ERROR:root:Error occurred CRITICAL:root:Critical error -- shutting down ---------- assignee: docs at python components: Documentation messages: 171142 nosy: docs at python, ramchandra.apte priority: normal severity: normal status: open title: Python highlighting in tutorial;should be text highlighting _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 16:27:11 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 24 Sep 2012 14:27:11 +0000 Subject: [issue16020] Missing >>> in Python code example Message-ID: <1348496831.82.0.497019065466.issue16020@psf.upfronthosting.co.za> New submission from Ramchandra Apte: In http://docs.python.org/py3k/tutorial/stdlib2.html#logging , some code in a code sample is missing ">>>". The code is: unsearched = deque([starting_node]) def breadth_first_search(unsearched): node = unsearched.popleft() for m in gen_moves(node): if is_goal(m): return m unsearched.append(m) should be: >>> unsearched = deque([starting_node]) >>> def breadth_first_search(unsearched): >>> node = unsearched.popleft() >>> for m in gen_moves(node): >>> if is_goal(m): >>> return m >>> unsearched.append(m) ---------- assignee: docs at python components: Documentation messages: 171143 nosy: docs at python, ramchandra.apte priority: normal severity: normal status: open title: Missing >>> in Python code example _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 16:32:03 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 24 Sep 2012 14:32:03 +0000 Subject: [issue16019] Python highlighting in tutorial; should be text highlighting In-Reply-To: <1348496637.1.0.121151069885.issue16019@psf.upfronthosting.co.za> Message-ID: <3XQSXy07z0zNND@mail.python.org> Roundup Robot added the comment: New changeset ce943bce76c9 by Ezio Melotti in branch '2.7': #16019, #16020: fix syntax highlight. http://hg.python.org/cpython/rev/ce943bce76c9 New changeset 101354f95a07 by Ezio Melotti in branch '3.2': #16019, #16020: fix syntax highlight. http://hg.python.org/cpython/rev/101354f95a07 New changeset 62ddf16eea24 by Ezio Melotti in branch 'default': #16019, #16020: merge with 3.2. http://hg.python.org/cpython/rev/62ddf16eea24 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 16:32:04 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 24 Sep 2012 14:32:04 +0000 Subject: [issue16020] Missing >>> in Python code example In-Reply-To: <1348496831.82.0.497019065466.issue16020@psf.upfronthosting.co.za> Message-ID: <3XQSXy6VTlzNND@mail.python.org> Roundup Robot added the comment: New changeset ce943bce76c9 by Ezio Melotti in branch '2.7': #16019, #16020: fix syntax highlight. http://hg.python.org/cpython/rev/ce943bce76c9 New changeset 101354f95a07 by Ezio Melotti in branch '3.2': #16019, #16020: fix syntax highlight. http://hg.python.org/cpython/rev/101354f95a07 New changeset 62ddf16eea24 by Ezio Melotti in branch 'default': #16019, #16020: merge with 3.2. http://hg.python.org/cpython/rev/62ddf16eea24 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 16:32:43 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 24 Sep 2012 14:32:43 +0000 Subject: [issue16020] Missing >>> in Python code example In-Reply-To: <1348496831.82.0.497019065466.issue16020@psf.upfronthosting.co.za> Message-ID: <1348497163.42.0.961157680349.issue16020@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the report! ---------- assignee: docs at python -> ezio.melotti nosy: +ezio.melotti resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> enhancement versions: +Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 16:33:16 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 24 Sep 2012 14:33:16 +0000 Subject: [issue16019] Python highlighting in tutorial; should be text highlighting In-Reply-To: <1348496637.1.0.121151069885.issue16019@psf.upfronthosting.co.za> Message-ID: <1348497196.74.0.220674069781.issue16019@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the report! ---------- assignee: docs at python -> ezio.melotti nosy: +ezio.melotti resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> enhancement versions: +Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 16:34:13 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 24 Sep 2012 14:34:13 +0000 Subject: [issue16021] In a table in PEP 235, brrrrrrrr should be N/A Message-ID: <1348497253.81.0.361762009812.issue16021@psf.upfronthosting.co.za> New submission from Ramchandra Apte: In the table: case-preserving case-destroying +-------------------+------------------+ case-sensitive | most Unix flavors | brrrrrrrrrr | +-------------------+------------------+ case-insensitive | Windows | some unfortunate | | MacOSX HFS+ | network schemes | | Cygwin | | | | OpenVMS | +-------------------+------------------+ brrrrrrrrrrr (pardon me for not putting the correct amount of "r"s) should be replaced with N/A ---------- messages: 171148 nosy: ramchandra.apte priority: normal severity: normal status: open title: In a table in PEP 235, brrrrrrrr should be N/A _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 16:34:15 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 24 Sep 2012 14:34:15 +0000 Subject: [issue16020] Missing >>> in Python code example In-Reply-To: <1348496831.82.0.497019065466.issue16020@psf.upfronthosting.co.za> Message-ID: <1348497255.49.0.774432141744.issue16020@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks for the report. Minor clarification for future reference. Subsequent lines should begin with "..." (when doctest-style is used): >>> def breadth_first_search(unsearched): ... node = unsearched.popleft() etc. ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 16:39:23 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 24 Sep 2012 14:39:23 +0000 Subject: [issue16021] In a table in PEP 235, brrrrrrrr should be N/A In-Reply-To: <1348497253.81.0.361762009812.issue16021@psf.upfronthosting.co.za> Message-ID: <1348497563.45.0.925439956483.issue16021@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +tim_one type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 16:46:55 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 24 Sep 2012 14:46:55 +0000 Subject: [issue16022] Mistake in "What's New in Python 3.3" Message-ID: <1348498015.65.0.0485764115741.issue16022@psf.upfronthosting.co.za> New submission from Ramchandra Apte: In "What's New in Python 3.3", there is a note: Note: Beta users should be aware that this document is currently in draft form. It will be updated substantially as Python 3.3 moves towards release, so it?s worth checking back even after reading earlier versions. If it is still in a draft form, replace "Beta users" with "Pre-release users" or something similar. Else, obviously remove the note. ---------- assignee: docs at python components: Documentation messages: 171150 nosy: docs at python, ramchandra.apte priority: normal severity: normal status: open title: Mistake in "What's New in Python 3.3" _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 16:52:50 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 24 Sep 2012 14:52:50 +0000 Subject: [issue16020] Missing >>> in Python code example In-Reply-To: <1348496831.82.0.497019065466.issue16020@psf.upfronthosting.co.za> Message-ID: <1348498369.99.0.127425073668.issue16020@psf.upfronthosting.co.za> Ramchandra Apte added the comment: This issue still does not appear to be fixed - looking at http://hg.python.org/cpython/file/101354f95a07/Doc/tutorial/stdlib2.rst . And sorry, the URL should be http://docs.python.org/py3k/tutorial/stdlib2.html#tools-for-working-with-lists. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 16:54:35 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 24 Sep 2012 14:54:35 +0000 Subject: [issue16020] Missing >>> in Python code example In-Reply-To: <1348496831.82.0.497019065466.issue16020@psf.upfronthosting.co.za> Message-ID: <1348498475.1.0.333611651494.issue16020@psf.upfronthosting.co.za> Ezio Melotti added the comment: The code didn't have any output, so I created a separate code block with regular Python highlight -- no need to add >>>/... there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 17:06:34 2012 From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=) Date: Mon, 24 Sep 2012 15:06:34 +0000 Subject: [issue8425] a -= b should be fast if a is a small set and b is a large set In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za> Message-ID: <1348499194.62.0.751394172483.issue8425@psf.upfronthosting.co.za> Michele Orr? added the comment: woops, sry. Re-posting the benchmark, with three tests: the first one proposed (@abacabadabacaba) with very large sets; another one with smaller sets. $ ./python.exe -m timeit -n 100 -s "s= set(range(2000)); l = set(range(20000000))" "s-=l" 100 loops, best of 3: 9.71 usec per loop [48787 refs] $ ./python.exe -m timeit -n 100 -s "s= set(range(1)); l = set(range(20))" "s-=l" 100 loops, best of 3: 0.366 usec per loop $ hg co -C $ make -j3 ----[!PATCHED]-------------------------------------------------- $ ./python.exe -m timeit -n 100 -s "s= set(range(2000)); l = set(range(20000000))" "s-=l" 100 loops, best of 3: 665 msec per loop [48787 refs] $ ./python.exe -m timeit -n 100 -s "s= set(range(1)); l = set(range(20))" "s-=l" 100 loops, best of 3: 0.849 usec per loop [48787 refs] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 17:21:55 2012 From: report at bugs.python.org (Zellmeyer) Date: Mon, 24 Sep 2012 15:21:55 +0000 Subject: [issue16023] IDLE froze when typing ctrl-shift-5 Message-ID: <1348500115.21.0.649772246938.issue16023@psf.upfronthosting.co.za> New submission from Zellmeyer: IDLE do not response and you have to force to quit when you type the bad combination ctrl-shift-5. I find it on my macbook when i try do type a [ character and type the bad combination by mistake because the keyboard are not exactly the same as the iMac. ---------- assignee: ronaldoussoren components: IDLE, Macintosh messages: 171154 nosy: ronaldoussoren, szellmeyer priority: normal severity: normal status: open title: IDLE froze when typing ctrl-shift-5 type: crash versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 17:30:00 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 24 Sep 2012 15:30:00 +0000 Subject: [issue16024] Doc cleanup regarding path=fd, dir_fd, follow_symlinks, etc Message-ID: <1348500599.22.0.118178834994.issue16024@psf.upfronthosting.co.za> New submission from Larry Hastings: You know how you start pulling on a thread and before you notice you've unraveled the whole sweater? I meant to do a simple *one line* fix on the docs and wound up with a nearly-300-line diff. I claim it's all an improvement, though I'm willing to change it if there's something you don't like. Definite improvements: * supports_fd et al are :class:`set` objects, not :class:`~collections.Set`. Those are different. * Linked to the "specifying a file descriptor" section in os from the relevant discussion in what's new. * "Availability: Unix" goes above :versionadded. Avowed improvements: * supports_* now explicitly mention what values are permitted for their parameters. * Lots of rewriting/munging in an effort to improve readability and precision. * A couple places where "it's" read better than "it is". LGTU? ---------- assignee: larry components: Documentation files: lch.supports_set.doc.cleanup.1.diff keywords: patch messages: 171155 nosy: georg.brandl, larry priority: normal severity: normal stage: patch review status: open title: Doc cleanup regarding path=fd, dir_fd, follow_symlinks, etc type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file27276/lch.supports_set.doc.cleanup.1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 17:30:09 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 24 Sep 2012 15:30:09 +0000 Subject: [issue16023] IDLE froze when typing ctrl-shift-5 In-Reply-To: <1348500115.21.0.649772246938.issue16023@psf.upfronthosting.co.za> Message-ID: <1348500609.78.0.725525881699.issue16023@psf.upfronthosting.co.za> Ronald Oussoren added the comment: What version of OSX do you use? Do you have ActiveState TCL installed, and if so, which version? Does 'Ctrl+Shift+5' insert a special character in the keyboard layout you use? BTW. I cannot reproduce this on my machine (OSX 10.8.2) with a recent snapshot of the 3.2 branch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 18:08:03 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 24 Sep 2012 16:08:03 +0000 Subject: [issue16025] Minor corrections to the zipfile documentation Message-ID: <1348502882.43.0.635160318129.issue16025@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: The proposed patch corrects a few markup errors in the zipfile documentation and adds a few relevant hyperlinks. ---------- assignee: docs at python components: Documentation files: doc_zipfile-3.3.patch keywords: patch messages: 171157 nosy: docs at python, storchaka priority: normal severity: normal status: open title: Minor corrections to the zipfile documentation versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file27277/doc_zipfile-3.3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 18:09:46 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 24 Sep 2012 16:09:46 +0000 Subject: [issue16025] Minor corrections to the zipfile documentation In-Reply-To: <1348502882.43.0.635160318129.issue16025@psf.upfronthosting.co.za> Message-ID: <1348502986.76.0.235271197882.issue16025@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file27278/doc_zipfile-3.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 18:10:15 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 24 Sep 2012 16:10:15 +0000 Subject: [issue16025] Minor corrections to the zipfile documentation In-Reply-To: <1348502882.43.0.635160318129.issue16025@psf.upfronthosting.co.za> Message-ID: <1348503015.4.0.895246382981.issue16025@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file27279/doc_zipfile-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 18:13:08 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 24 Sep 2012 16:13:08 +0000 Subject: [issue16025] Minor corrections to the zipfile documentation In-Reply-To: <1348502882.43.0.635160318129.issue16025@psf.upfronthosting.co.za> Message-ID: <1348503188.43.0.560333998937.issue16025@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: -> patch review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 18:21:33 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 24 Sep 2012 16:21:33 +0000 Subject: [issue16021] In a table in PEP 235, brrrrrrrr should be N/A In-Reply-To: <1348497253.81.0.361762009812.issue16021@psf.upfronthosting.co.za> Message-ID: <1348503693.65.0.473598711741.issue16021@psf.upfronthosting.co.za> Mark Dickinson added the comment: Is this really necessary? I suggest closing this as 'wont fix'. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 18:23:39 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 24 Sep 2012 16:23:39 +0000 Subject: [issue8425] a -= b should be fast if a is a small set and b is a large set In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za> Message-ID: <1348503819.79.0.0868860186283.issue8425@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > $ ./python.exe -m timeit -n 100 -s "s= set(range(2000)); l = set(range(20000000))" "s-=l" s is empty set after first loop. Try this: $ ./python.exe -m timeit -n 100 -s "s= set(range(2000)); l = set(range(2000,2000+20000000))" "s-=l" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 18:30:56 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 24 Sep 2012 16:30:56 +0000 Subject: [issue15963] Improve ./configure's support for 32/64-bit debug|release|profiled builds w/ vendor (non-gcc) compilers on proprietary UNIX systems (Solaris/HP-UX/AIX et al). In-Reply-To: <1347975635.66.0.0788814924298.issue15963@psf.upfronthosting.co.za> Message-ID: <1348504256.58.0.861243504993.issue15963@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 18:32:44 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 24 Sep 2012 16:32:44 +0000 Subject: [issue16024] Doc cleanup regarding path=fd, dir_fd, follow_symlinks, etc In-Reply-To: <1348500599.22.0.118178834994.issue16024@psf.upfronthosting.co.za> Message-ID: <1348504364.6.0.364864205923.issue16024@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 18:38:37 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 24 Sep 2012 16:38:37 +0000 Subject: [issue8425] a -= b should be fast if a is a small set and b is a large set In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za> Message-ID: <1348504717.63.0.198794235261.issue8425@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Michele, in any case you patch is not preserve set identity. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 18:39:03 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 24 Sep 2012 16:39:03 +0000 Subject: [issue8425] a -= b should be fast if a is a small set and b is a large set In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za> Message-ID: <1348504743.24.0.547075833992.issue8425@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: -easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 18:53:03 2012 From: report at bugs.python.org (Peter Eisentraut) Date: Mon, 24 Sep 2012 16:53:03 +0000 Subject: [issue16026] csv.DictReader argument names documented incorrectly Message-ID: <1348505583.77.0.632308357055.issue16026@psf.upfronthosting.co.za> New submission from Peter Eisentraut: The documentation for the csv.DictReader constructor is .. class:: DictReader(csvfile, fieldnames=None, restkey=None, restval=None, dialect='excel', *args, **kwds) but the implementation is def __init__(self, f, fieldnames=None, restkey=None, restval=None, dialect="excel", *args, **kwds): The name of the first argument is documented incorrectly, leading to surprise errors when attempting to use key word arguments. ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 171161 nosy: docs at python, petere priority: normal severity: normal status: open title: csv.DictReader argument names documented incorrectly type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 19:02:39 2012 From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=) Date: Mon, 24 Sep 2012 17:02:39 +0000 Subject: [issue8425] a -= b should be fast if a is a small set and b is a large set In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za> Message-ID: <1348506159.01.0.984834469804.issue8425@psf.upfronthosting.co.za> Michele Orr? added the comment: What do you mean by "does not preserve set identity"? Because I see: $ ./python.exe Python 3.3.0rc2+ (default:178f9042af81+, Sep 24 2012, 18:54:31) [GCC 4.2.1 Compatible Apple Clang 2.1 (tags/Apple/clang-163.7.1)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> a = set(range(1)) [65967 refs] >>> b = set(range(20)) [65989 refs] >>> id(a) 4540421032 [65992 refs] >>> a -= b [65991 refs] >>> id(a) 4540421032 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 19:02:41 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 24 Sep 2012 17:02:41 +0000 Subject: [issue16027] pkgutil doesn't support frozen modules Message-ID: <1348506161.12.0.954547119673.issue16027@psf.upfronthosting.co.za> New submission from Marc-Andre Lemburg: pkgutil is used by runpy to run Python modules that are loaded via the -m command line switch. Unfortunately, this doesn't work for frozen modules, since pkgutil doesn't know how to load their code object (this can be had via imp.get_code_object() for frozen modules). We found the problem while working on eGenix PyRun (see http://www.egenix.com/products/python/PyRun/) which uses frozen modules extensively. We currently only target Python 2.x, so will have work around the problem with a patch, but Python 3.x still has the same problem. ---------- components: Library (Lib) messages: 171163 nosy: lemburg priority: normal severity: normal status: open title: pkgutil doesn't support frozen modules versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 19:33:11 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 24 Sep 2012 17:33:11 +0000 Subject: [issue8425] a -= b should be fast if a is a small set and b is a large set In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za> Message-ID: <1348507991.22.0.698458777715.issue8425@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sorry, I was wrong. I think that the proposed changes should be applied in set_difference_update_internal() directly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 19:33:54 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 24 Sep 2012 17:33:54 +0000 Subject: [issue16027] pkgutil doesn't support frozen modules In-Reply-To: <1348506161.12.0.954547119673.issue16027@psf.upfronthosting.co.za> Message-ID: <1348508034.08.0.384108149195.issue16027@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Correction: the helper function is called imp.get_frozen_object(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 19:54:12 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 24 Sep 2012 17:54:12 +0000 Subject: [issue16021] In a table in PEP 235, brrrrrrrr should be N/A In-Reply-To: <1348497253.81.0.361762009812.issue16021@psf.upfronthosting.co.za> Message-ID: <1348509252.22.0.641342387716.issue16021@psf.upfronthosting.co.za> Mark Dickinson added the comment: Closing. This doesn't appear to have caused any confusion in the 11 years since the PEP was written. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 20:01:56 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 24 Sep 2012 18:01:56 +0000 Subject: [issue16027] pkgutil doesn't support frozen modules In-Reply-To: <1348506161.12.0.954547119673.issue16027@psf.upfronthosting.co.za> Message-ID: <1348509716.84.0.0748458367133.issue16027@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 20:18:19 2012 From: report at bugs.python.org (Neal Parikh) Date: Mon, 24 Sep 2012 18:18:19 +0000 Subject: [issue16011] "in" should be consistent with return value of __contains__ In-Reply-To: <1348445631.47.0.961273834435.issue16011@psf.upfronthosting.co.za> Message-ID: <1348510699.55.0.00341422831466.issue16011@psf.upfronthosting.co.za> Neal Parikh added the comment: Thanks for passing along the thread, it was interesting. Oddly, it seemed to die off with no real resolution. I realize it is now too late to change __contains__ to return a non-boolean value, but for reference, the reason I wanted to return something different from __contains__ was also to implement a DSL, though not a SQL-related one. Basically, I have some kind of abstract mathematical set S, and I wanted "x in S" to return a constraint that the variable x must lie in the set S for use in a larger problem description. (In fact, one could implement __contains__ so it returned True/False with a constant numeric argument and a constraint object with a variable argument.) This would have mirrored the way one would write all this mathematically. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 20:27:59 2012 From: report at bugs.python.org (Erik Allik) Date: Mon, 24 Sep 2012 18:27:59 +0000 Subject: [issue16028] break in finally discards exception Message-ID: <1348511279.94.0.440526778313.issue16028@psf.upfronthosting.co.za> New submission from Erik Allik: This is either a bug, or a very weird but undocumented feature/caveat. def fn1(): while True: try: raise Exception() finally: pass def fn2(): while True: try: raise Exception() finally: break # <----- fn1() # exception, as expected fn2() # silence! ---------- messages: 171168 nosy: eallik priority: normal severity: normal status: open title: break in finally discards exception type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 20:42:48 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 24 Sep 2012 18:42:48 +0000 Subject: [issue16028] break in finally discards exception In-Reply-To: <1348511279.94.0.440526778313.issue16028@psf.upfronthosting.co.za> Message-ID: <1348512168.45.0.580844388453.issue16028@psf.upfronthosting.co.za> Mark Dickinson added the comment: This *was* a documented feature until very recently; it looks as though a recent doc change inadvertently removed it from the documentation. See http://hg.python.org/cpython/rev/bef098bd3fa5 and the associated issue, issue 14167. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 20:45:23 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 24 Sep 2012 18:45:23 +0000 Subject: [issue14167] document return statement in finally blocks In-Reply-To: <1330614429.57.0.59180427723.issue14167@psf.upfronthosting.co.za> Message-ID: <1348512323.02.0.95826218182.issue14167@psf.upfronthosting.co.za> Mark Dickinson added the comment: I think something went wrong with this doc change. The docs used to say: """ If the :keyword:`finally` clause raises another exception or executes a :keyword:`return` or :keyword:`break` statement, the saved exception is lost. """ Now we have: """ If there is a saved exception or :keyword:`break` statement, it is re-raised at the end of the :keyword:`finally` clause. """ which doesn't make much sense (what does 'it' refer to in the case of a 'break' statement), and we seem to have lost the explicit statement that a 'break' in a finally cause swallows exceptions. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 20:45:52 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 24 Sep 2012 18:45:52 +0000 Subject: [issue14167] document return statement in finally blocks In-Reply-To: <1330614429.57.0.59180427723.issue14167@psf.upfronthosting.co.za> Message-ID: <1348512352.97.0.760544609311.issue14167@psf.upfronthosting.co.za> Mark Dickinson added the comment: See also issue 16021. Re-opening this issue for reconsideration. ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 20:46:17 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 24 Sep 2012 18:46:17 +0000 Subject: [issue14167] document return statement in finally blocks In-Reply-To: <1330614429.57.0.59180427723.issue14167@psf.upfronthosting.co.za> Message-ID: <1348512377.68.0.493478227385.issue14167@psf.upfronthosting.co.za> Mark Dickinson added the comment: Bah. Issue 16028; sorry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 20:47:53 2012 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 24 Sep 2012 18:47:53 +0000 Subject: [issue14167] document return statement in finally blocks In-Reply-To: <1330614429.57.0.59180427723.issue14167@psf.upfronthosting.co.za> Message-ID: <1348512473.78.0.73943940449.issue14167@psf.upfronthosting.co.za> Yury Selivanov added the comment: Can you close this one? It's already merged. ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 20:50:59 2012 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 24 Sep 2012 18:50:59 +0000 Subject: [issue14167] document return statement in finally blocks In-Reply-To: <1330614429.57.0.59180427723.issue14167@psf.upfronthosting.co.za> Message-ID: <1348512659.64.0.241699450746.issue14167@psf.upfronthosting.co.za> Yury Selivanov added the comment: I'll open another issue and will attach a patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 20:53:01 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 24 Sep 2012 18:53:01 +0000 Subject: [issue14167] document return statement in finally blocks In-Reply-To: <1330614429.57.0.59180427723.issue14167@psf.upfronthosting.co.za> Message-ID: <1348512781.31.0.505344895086.issue14167@psf.upfronthosting.co.za> Mark Dickinson added the comment: Yury: I don't think there's any need for yet another issue; this one will do (or if you prefer, attach the patch to issue 16028.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 20:55:29 2012 From: report at bugs.python.org (Erik Allik) Date: Mon, 24 Sep 2012 18:55:29 +0000 Subject: [issue16028] break in finally discards exception In-Reply-To: <1348511279.94.0.440526778313.issue16028@psf.upfronthosting.co.za> Message-ID: <1348512928.99.0.512085793394.issue16028@psf.upfronthosting.co.za> Erik Allik added the comment: It looks to me that it was not removed from the doc but explicitly changed to say that 'break' does not cause the exception to be discarded, unless I'm misunderstanding it: 1.20 +:keyword:`finally` clause is executed. If there is a saved exception 1.21 +or :keyword:`break` statement, it is re-raised at the end of the 1.22 +:keyword:`finally` clause. If the :keyword:`finally` clause raises ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 21:01:34 2012 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 24 Sep 2012 19:01:34 +0000 Subject: [issue14167] document return statement in finally blocks In-Reply-To: <1330614429.57.0.59180427723.issue14167@psf.upfronthosting.co.za> Message-ID: <1348513294.9.0.164783508203.issue14167@psf.upfronthosting.co.za> Yury Selivanov added the comment: OK. Attaching the patch. Please review. ---------- Added file: http://bugs.python.org/file27280/finally_doc_patch.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 21:02:00 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 24 Sep 2012 19:02:00 +0000 Subject: [issue16028] break in finally discards exception In-Reply-To: <1348511279.94.0.440526778313.issue16028@psf.upfronthosting.co.za> Message-ID: <1348513320.7.0.142937753512.issue16028@psf.upfronthosting.co.za> Mark Dickinson added the comment: Hmm. Yes, true. Either way, it's the docs that need to be fixed rather than the behaviour. Thanks for catching this! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 21:02:43 2012 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 24 Sep 2012 19:02:43 +0000 Subject: [issue16028] break in finally discards exception In-Reply-To: <1348511279.94.0.440526778313.issue16028@psf.upfronthosting.co.za> Message-ID: <1348513363.78.0.267319179782.issue16028@psf.upfronthosting.co.za> Yury Selivanov added the comment: see the issue 14167 ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 21:17:33 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 24 Sep 2012 19:17:33 +0000 Subject: [issue14167] document return statement in finally blocks In-Reply-To: <1330614429.57.0.59180427723.issue14167@psf.upfronthosting.co.za> Message-ID: <3XQZtN0VXgzQSF@mail.python.org> Roundup Robot added the comment: New changeset 485902ecf0ee by Mark Dickinson in branch '3.2': Issue #14167: restore statement about breaks in finally clauses. http://hg.python.org/cpython/rev/485902ecf0ee New changeset f5ed3a5440b2 by Mark Dickinson in branch 'default': Issue #14167: merge fix from 3.2 branch. http://hg.python.org/cpython/rev/f5ed3a5440b2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 21:19:17 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 24 Sep 2012 19:19:17 +0000 Subject: [issue14167] document return statement in finally blocks In-Reply-To: <1330614429.57.0.59180427723.issue14167@psf.upfronthosting.co.za> Message-ID: <1348514357.74.0.661627442723.issue14167@psf.upfronthosting.co.za> Mark Dickinson added the comment: Thanks for the quick fix! Patch applied to 3.2 and 3.3 The 2.7 commit also introduced an incorrect statement about exception chaining; I'll look at fixing that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 21:19:48 2012 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 24 Sep 2012 19:19:48 +0000 Subject: [issue14167] document return statement in finally blocks In-Reply-To: <1330614429.57.0.59180427723.issue14167@psf.upfronthosting.co.za> Message-ID: <1348514388.93.0.851982513213.issue14167@psf.upfronthosting.co.za> Yury Selivanov added the comment: thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 21:25:46 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 24 Sep 2012 19:25:46 +0000 Subject: [issue14167] document return statement in finally blocks In-Reply-To: <1330614429.57.0.59180427723.issue14167@psf.upfronthosting.co.za> Message-ID: <3XQb3r6yPkzNbr@mail.python.org> Roundup Robot added the comment: New changeset f51d11405f1d by Mark Dickinson in branch '2.7': Issue #14167: restore statement about breaks in finally clauses; remove statement about exception chaining. http://hg.python.org/cpython/rev/f51d11405f1d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 21:26:52 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 24 Sep 2012 19:26:52 +0000 Subject: [issue14167] document return statement in finally blocks In-Reply-To: <1330614429.57.0.59180427723.issue14167@psf.upfronthosting.co.za> Message-ID: <1348514812.08.0.962533539052.issue14167@psf.upfronthosting.co.za> Mark Dickinson added the comment: Reclosing. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 21:27:48 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 24 Sep 2012 19:27:48 +0000 Subject: [issue16028] break in finally discards exception In-Reply-To: <1348511279.94.0.440526778313.issue16028@psf.upfronthosting.co.za> Message-ID: <1348514868.81.0.946436190109.issue16028@psf.upfronthosting.co.za> Mark Dickinson added the comment: That portion of the documentation has been restored. Closing this issue. ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python resolution: -> fixed status: open -> closed versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 22:27:13 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 24 Sep 2012 20:27:13 +0000 Subject: [issue16013] small csv reader bug In-Reply-To: <1348491792.39.0.00618601585478.issue16013@psf.upfronthosting.co.za> Message-ID: <1348518433.67.0.910264236948.issue16013@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: A shorter example: >>> import csv >>> list(csv.reader(['foo,"'])) [] ---------- nosy: +storchaka type: -> behavior versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 22:29:00 2012 From: report at bugs.python.org (akira) Date: Mon, 24 Sep 2012 20:29:00 +0000 Subject: [issue16029] pickle.dumps(xrange(sys.maxsize)) produces xrange(0) Message-ID: <1348518540.13.0.547483002596.issue16029@psf.upfronthosting.co.za> New submission from akira: >>> import sys >>> from pickle import dumps, loads >>> r = xrange(sys.maxsize) >>> len(r) == sys.maxsize True >>> pr = loads(dumps(r)) >>> len(pr) == len(r) False >>> pr xrange(0) >>> r xrange(9223372036854775807) It breaks multiprocessing module: http://stackoverflow.com/questions/12569977/python-large-iterations-number-fail It fails on 2.6.6, 2.7.3. It works correctly on 3.1-3.3, pypy 1.7-1.9 x86_64 Linux. ---------- components: Library (Lib) files: test_pickle_dumps_xrange.py messages: 171187 nosy: akira priority: normal severity: normal status: open title: pickle.dumps(xrange(sys.maxsize)) produces xrange(0) type: behavior versions: Python 2.6, Python 2.7 Added file: http://bugs.python.org/file27281/test_pickle_dumps_xrange.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 22:59:10 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 24 Sep 2012 20:59:10 +0000 Subject: [issue16029] pickle.dumps(xrange(sys.maxsize)) produces xrange(0) In-Reply-To: <1348518540.13.0.547483002596.issue16029@psf.upfronthosting.co.za> Message-ID: <1348520350.45.0.0515803495391.issue16029@psf.upfronthosting.co.za> Mark Dickinson added the comment: The bug is (not surprisingly) in range_reduce in Objects/rangeobject.c, where return Py_BuildValue("(O(iii))", Py_TYPE(r), should be return Py_BuildValue("(O(lll))", Py_TYPE(r), But in writing tests for this bug, I fell over another one: >>> import sys >>> xrange(0, sys.maxint, sys.maxint-1) xrange(0, -4, 2147483646) ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 23:04:08 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 24 Sep 2012 21:04:08 +0000 Subject: [issue16029] pickle.dumps(xrange(sys.maxsize)) produces xrange(0) In-Reply-To: <1348518540.13.0.547483002596.issue16029@psf.upfronthosting.co.za> Message-ID: <1348520648.62.0.366097585165.issue16029@psf.upfronthosting.co.za> Mark Dickinson added the comment: Here's the fix. There's a commented out test, which fails because of the second xrange bug (or something closely related to it). ---------- keywords: +patch Added file: http://bugs.python.org/file27282/issue16029.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 23:04:44 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 24 Sep 2012 21:04:44 +0000 Subject: [issue16029] pickle.dumps(xrange(sys.maxsize)) produces xrange(0) In-Reply-To: <1348518540.13.0.547483002596.issue16029@psf.upfronthosting.co.za> Message-ID: <1348520684.35.0.294028076386.issue16029@psf.upfronthosting.co.za> Mark Dickinson added the comment: Removing 2.6: this isn't a security issue. ---------- stage: -> patch review versions: -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 23:11:17 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 24 Sep 2012 21:11:17 +0000 Subject: [issue16011] "in" should be consistent with return value of __contains__ In-Reply-To: <1348445631.47.0.961273834435.issue16011@psf.upfronthosting.co.za> Message-ID: <1348521077.54.0.111112543379.issue16011@psf.upfronthosting.co.za> STINNER Victor added the comment: Do you need this PEP? http://www.python.org/dev/peps/pep-0335/ ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 23:14:58 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 24 Sep 2012 21:14:58 +0000 Subject: [issue16029] pickle.dumps(xrange(sys.maxsize)) produces xrange(0) In-Reply-To: <1348518540.13.0.547483002596.issue16029@psf.upfronthosting.co.za> Message-ID: <1348521298.3.0.355136331848.issue16029@psf.upfronthosting.co.za> Mark Dickinson added the comment: Okay, the xrange stop for both its pickle and its repr is computed as: r->start + r->len * r->step If this overflows, it gives a bad value. It would suffice to replace it with sys.maxint or -sys.maxint - 1 on overflow. I'll look at this shortly. ---------- assignee: -> mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 23:16:03 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 24 Sep 2012 21:16:03 +0000 Subject: [issue16029] pickle.dumps(xrange(sys.maxsize)) produces xrange(0) In-Reply-To: <1348518540.13.0.547483002596.issue16029@psf.upfronthosting.co.za> Message-ID: <1348521363.43.0.0592738277663.issue16029@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 23:23:17 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 24 Sep 2012 21:23:17 +0000 Subject: [issue16030] xrange repr broken for large arguments Message-ID: <1348521797.77.0.407946912471.issue16030@psf.upfronthosting.co.za> New submission from Mark Dickinson: Python 2.7.3+ (2.7:f51d11405f1d+, Sep 24 2012, 21:39:19) [GCC 4.2.1 (Apple Inc. build 5664)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> xrange(0, sys.maxint, sys.maxint-1) xrange(0, -4, 9223372036854775806) See also issue #16029. There should be a common solution to both these issues. Suggestion is to write a 'range_safe_stop' utility function that returns r->start + r->len * r->step clipped to the range [LONG_MIN, LONG_MAX], and use that for the stop value in both the repr and the pickle. ---------- assignee: mark.dickinson components: Library (Lib) messages: 171193 nosy: mark.dickinson priority: normal severity: normal stage: needs patch status: open title: xrange repr broken for large arguments type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 23:23:38 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 24 Sep 2012 21:23:38 +0000 Subject: [issue16022] Mistake in "What's New in Python 3.3" In-Reply-To: <1348498015.65.0.0485764115741.issue16022@psf.upfronthosting.co.za> Message-ID: <3XQdgr6PsdzQhc@mail.python.org> Roundup Robot added the comment: New changeset 35289291a2e6 by Victor Stinner in branch 'default': Close #16022: What's New in Python 3.3 document is no more at beta stage http://hg.python.org/cpython/rev/35289291a2e6 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 23:24:47 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 24 Sep 2012 21:24:47 +0000 Subject: [issue16029] pickle.dumps(xrange(sys.maxsize)) produces xrange(0) In-Reply-To: <1348518540.13.0.547483002596.issue16029@psf.upfronthosting.co.za> Message-ID: <1348521887.01.0.846908936315.issue16029@psf.upfronthosting.co.za> Mark Dickinson added the comment: Opened issue #16030 for the repr issue. The patch for this issue still lacks a fix for the stop value. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 23:25:58 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 24 Sep 2012 21:25:58 +0000 Subject: [issue16022] Mistake in "What's New in Python 3.3" In-Reply-To: <1348498015.65.0.0485764115741.issue16022@psf.upfronthosting.co.za> Message-ID: <1348521958.77.0.720411491212.issue16022@psf.upfronthosting.co.za> STINNER Victor added the comment: @Georg: You should include this fix in Python 3.3 final. @Raymond: FYI, I removed your warning :) ---------- nosy: +georg.brandl, haypo, rhettinger resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 23:28:01 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 24 Sep 2012 21:28:01 +0000 Subject: [issue7897] Support parametrized tests in unittest In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za> Message-ID: <1348522081.89.0.664982315456.issue7897@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 23:30:09 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 24 Sep 2012 21:30:09 +0000 Subject: [issue16022] Mistake in "What's New in Python 3.3" In-Reply-To: <1348498015.65.0.0485764115741.issue16022@psf.upfronthosting.co.za> Message-ID: <1348522209.52.0.713920987446.issue16022@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 23:41:12 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 24 Sep 2012 21:41:12 +0000 Subject: [issue15954] No error checking after using of the wcsxfrm() In-Reply-To: <1347876874.21.0.668678433738.issue15954@psf.upfronthosting.co.za> Message-ID: <1348522872.17.0.386026291075.issue15954@psf.upfronthosting.co.za> STINNER Victor added the comment: Dummy question: can you provide an example of strings that make wcsxfrm() failing? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 24 23:59:07 2012 From: report at bugs.python.org (Georg Brandl) Date: Mon, 24 Sep 2012 21:59:07 +0000 Subject: [issue16022] Mistake in "What's New in Python 3.3" In-Reply-To: <1348498015.65.0.0485764115741.issue16022@psf.upfronthosting.co.za> Message-ID: <1348523947.38.0.503882304952.issue16022@psf.upfronthosting.co.za> Georg Brandl added the comment: Done. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 00:04:55 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 24 Sep 2012 22:04:55 +0000 Subject: [issue16013] small csv reader bug In-Reply-To: <1348491792.39.0.00618601585478.issue16013@psf.upfronthosting.co.za> Message-ID: <1348524295.87.0.280161666799.issue16013@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch. >>> list(csv.reader(['foo,"'])) [['foo', '']] >>> list(csv.reader(['foo,"'], strict=1)) Traceback (most recent call last): File "", line 1, in _csv.Error: unexpected end of data >>> list(csv.reader(['foo,^'], escapechar='^')) [['foo', '\n']] >>> list(csv.reader(['foo,^'], escapechar='^', strict=1)) Traceback (most recent call last): File "", line 1, in _csv.Error: unexpected end of data Is it good? ---------- keywords: +patch Added file: http://bugs.python.org/file27283/csv_eof-3.3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 00:05:47 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 24 Sep 2012 22:05:47 +0000 Subject: [issue16013] small csv reader bug In-Reply-To: <1348491792.39.0.00618601585478.issue16013@psf.upfronthosting.co.za> Message-ID: <1348524347.2.0.845028756412.issue16013@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file27284/csv_eof-3.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 00:10:30 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 24 Sep 2012 22:10:30 +0000 Subject: [issue15954] No error checking after using of the wcsxfrm() In-Reply-To: <1348522872.17.0.386026291075.issue15954@psf.upfronthosting.co.za> Message-ID: <201209250110.15595.storchaka@gmail.com> Serhiy Storchaka added the comment: > Dummy question: can you provide an example of strings that make wcsxfrm() failing? No, I can not (on Linux). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 00:18:54 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 24 Sep 2012 22:18:54 +0000 Subject: [issue15954] No error checking after using of the wcsxfrm() In-Reply-To: <1347876874.21.0.668678433738.issue15954@psf.upfronthosting.co.za> Message-ID: <1348525134.63.0.222833106643.issue15954@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What error message is most appropriate here? Can we return the original string instead of exception? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 00:58:35 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 24 Sep 2012 22:58:35 +0000 Subject: [issue16009] Json error messages could provide more information about the error In-Reply-To: <1348420465.53.0.405036591258.issue16009@psf.upfronthosting.co.za> Message-ID: <1348527515.92.0.59678466531.issue16009@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 01:25:21 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 24 Sep 2012 23:25:21 +0000 Subject: [issue16001] small ints: cache string representation In-Reply-To: <1348272680.09.0.237238464287.issue16001@psf.upfronthosting.co.za> Message-ID: <1348529121.01.0.658434105163.issue16001@psf.upfronthosting.co.za> STINNER Victor added the comment: Here is a micro benchmark: --- # run it using: # benchmark.py script bench_int_str.py [--file=output] # https://bitbucket.org/haypo/misc/src/tip/python/benchmark.py def run_benchmark(bench): bench.timeit('S(123)', setup='S=str') bench.timeit('S(1) == S(2)', setup='S=str') bench.timeit('S(12345)', setup='S=str') bench.timeit('{S(x): x for x in data}', setup='data=tuple(range(100)); S=str') bench.timeit('"x=%s" % x', setup='x=123') bench.timeit('"x=%s" % x', setup='x=12345') --- Output: -------------------------------------------------------+-------------+--------------- Tests | unpatched | patched -------------------------------------------------------+-------------+--------------- S=str; S(123) | 158 ns (*) | 112 ns (-29%) S=str; S(1) == S(2) | 329 ns (*) | 248 ns (-25%) S=str; S(12345) | 161 ns (*) | 161 ns data=tuple(range(100)); S=str; {S(x): x for x in data} | 23 us (*) | 16.5 us (-28%) x=123; "x=%s" % x | 145 ns (*) | 133 ns (-8%) x=12345; "x=%s" % x | 149 ns (*) | 145 ns -------------------------------------------------------+-------------+--------------- Total | 23.9 us (*) | 17.3 us (-27%) -------------------------------------------------------+-------------+--------------- I expected more important speedup. ---------- Added file: http://bugs.python.org/file27285/bench_int_str.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 01:25:56 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 24 Sep 2012 23:25:56 +0000 Subject: [issue16001] small ints: cache string representation In-Reply-To: <1348272680.09.0.237238464287.issue16001@psf.upfronthosting.co.za> Message-ID: <1348529156.5.0.086622266846.issue16001@psf.upfronthosting.co.za> STINNER Victor added the comment: My initial idea was to cache str(int) for any integer, but it may waste memory for huge numbers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 01:28:31 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 24 Sep 2012 23:28:31 +0000 Subject: [issue16001] small ints: cache string representation In-Reply-To: <1348272680.09.0.237238464287.issue16001@psf.upfronthosting.co.za> Message-ID: <1348529311.71.0.396822525375.issue16001@psf.upfronthosting.co.za> STINNER Victor added the comment: Oops, I forgot to attach the new patch: small_ints_cache_str-2.patch optimizes also str % args (copy the string when needed if the reference count is not 1). ---------- Added file: http://bugs.python.org/file27286/small_ints_cache_str-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 01:50:42 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 24 Sep 2012 23:50:42 +0000 Subject: [issue15381] Optimize BytesIO to so less reallocations when written, similarly to StringIO In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za> Message-ID: <1348530642.77.0.530741437777.issue15381@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 01:53:43 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 24 Sep 2012 23:53:43 +0000 Subject: [issue15381] Optimize BytesIO to so less reallocations when written, similarly to StringIO In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za> Message-ID: <1348530823.34.0.16773350713.issue15381@psf.upfronthosting.co.za> STINNER Victor added the comment: See also issue #15612 for a possible optimization on StringIO (use _PyUnicodeWriter). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 01:53:59 2012 From: report at bugs.python.org (Neal Parikh) Date: Mon, 24 Sep 2012 23:53:59 +0000 Subject: [issue16011] "in" should be consistent with return value of __contains__ In-Reply-To: <1348445631.47.0.961273834435.issue16011@psf.upfronthosting.co.za> Message-ID: <1348530839.85.0.342021069164.issue16011@psf.upfronthosting.co.za> Neal Parikh added the comment: I don't, but thanks for passing that along. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 02:05:15 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 25 Sep 2012 00:05:15 +0000 Subject: [issue16027] pkgutil doesn't support frozen modules In-Reply-To: <1348506161.12.0.954547119673.issue16027@psf.upfronthosting.co.za> Message-ID: <1348531515.85.0.482221925432.issue16027@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 02:08:02 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 25 Sep 2012 00:08:02 +0000 Subject: [issue16024] Doc cleanup regarding path=fd, dir_fd, follow_symlinks, etc In-Reply-To: <1348500599.22.0.118178834994.issue16024@psf.upfronthosting.co.za> Message-ID: <1348531682.28.0.925974953112.issue16024@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 02:08:16 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 25 Sep 2012 00:08:16 +0000 Subject: [issue16030] xrange repr broken for large arguments In-Reply-To: <1348521797.77.0.407946912471.issue16030@psf.upfronthosting.co.za> Message-ID: <1348531696.72.0.121830212206.issue16030@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 02:18:34 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 25 Sep 2012 00:18:34 +0000 Subject: [issue15612] Rewrite StringIO to use the _PyUnicodeWriter API In-Reply-To: <1344565830.56.0.384034899089.issue15612@psf.upfronthosting.co.za> Message-ID: <1348532314.83.0.0890148297986.issue15612@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 03:03:03 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 25 Sep 2012 01:03:03 +0000 Subject: [issue16015] Incorrect startup header in tutorial In-Reply-To: <1348494782.32.0.720891839928.issue16015@psf.upfronthosting.co.za> Message-ID: <1348534983.73.0.219755371436.issue16015@psf.upfronthosting.co.za> ?ric Araujo added the comment: Suggest closing: I think this causes no issue and changing it would have no benefit. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 03:03:33 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 25 Sep 2012 01:03:33 +0000 Subject: [issue16026] csv.DictReader argument names documented incorrectly In-Reply-To: <1348505583.77.0.632308357055.issue16026@psf.upfronthosting.co.za> Message-ID: <1348535013.05.0.192293250064.issue16026@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- keywords: +easy stage: -> needs patch versions: -Python 2.6, Python 3.1, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 03:04:18 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 25 Sep 2012 01:04:18 +0000 Subject: [issue16013] small csv reader bug In-Reply-To: <1348491792.39.0.00618601585478.issue16013@psf.upfronthosting.co.za> Message-ID: <1348535058.74.0.512060657081.issue16013@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- keywords: +needs review stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 03:07:48 2012 From: report at bugs.python.org (James Hutchison) Date: Tue, 25 Sep 2012 01:07:48 +0000 Subject: [issue16031] relative import headaches Message-ID: <1348535267.9.0.55515174451.issue16031@psf.upfronthosting.co.za> New submission from James Hutchison: This might even be a bug I've stumbled upon but I'm listing it as an enhancement for now. I really feel that relative imports in Python should just work. Regardless of the __name__, I should be able to import below me. Likewise, it should work even if I've already done an import into the symbol table. It adds additional work to us as a developer to have to do some pythonpath or code gymnastics to get something rather trivial working. Additionally, the import errors from circular imports add another challenge to work around. In C/C++ you can force it to import a file once and only once, why can't Python work the same way? Take the following example set-up: startPoint.py subModule1 /__init__.py /a.py /b.py /tests /__init__.py /test_a.py a's code: print("in a"); from subModule1 import b b's code: print("in b"); from subModule1 import a test_a.py's code: print("myname:",__name__); from .. import a startPoint.py is empty, and the __init__.py files are also empty. If I run a PyDev unit test on test_a.py this is what I get: Finding files... done. Importing test modules ... myname: subModule1.tests.test_a in a in b myname: test_a Traceback (most recent call last): File "C:\eclipse\plugins\org.python.pydev_2.6.0.2012062818\pysrc\pydev_runfiles.py", line 432, in __get_module_from_str mod = __import__(modname) File "C:\myfolder/relativeImportTest/subModule1/tests\test_a.py", line 6, in from .. import a ValueError: Attempted relative import in non-package Clearly in this case, the exception given doesn't make any sense. I have __init__.py, the error says the relative import line is failing, and the error says it's because I'm in a non-package. Except, I'm in a package. It seems to go through the a_test.py file twice, even though I never explicitly import it. The first time through, I'm clearly in a package. The second time through, my name is NOT __main__ but yet I'm apparently no longer a package, which is where it fails. Now if I change: "from subModule1 import b" to "import subModule1.b" and "from subModule1 import a" to "import subModule1.a" then everything works. But then that means I have to reference everything by the full name in my submodules. In this example, there's clearly a circular reference between a and b that wouldn't work anyways. So lets change some things. Now: a.py: import subModule1.b b.py: from subModule1 import a Now the circular reference is gone between a and b. I really don't like having to do this as a means to work around a circular reference because it forces me to vary the import style of one file to another. If we try the test code again however, it gets the same problem. If I swap which file does the relative import, then it works. So lets make one last change: test_a.py: import subModule1.b # added from .. import a This will work, seemingly magically. It only runs the code in test_a.py once. Recall that the code in a.py is "import subModule1.b" So basically this brings up several issues: 1. "import a.b" isn't the same as "from a import b" by more than how you reference it in the code 2. submodules are re-imported as non-module without ever importing them if you import their parent module relatively. If this is documented I don't know where. 3. import order can matter drastically to if a code runs or not for seemingly magical reasons. And back when I was a beginner Python user, the naming convention of the full path really threw a monkey wrench in my code when I would try to move a select number of files from one project to another, or would try relative imports. If relative imports cause such headaches with circular references then I should generally stick to the full module path when referencing things. But if the full module path isn't portable then I should use relative imports. Likewise, if I run as a PyDev unitTest, my module name is NOT __main__, so special path checks for __main__ won't work I think the bottom line is that the import system gave me headaches as a beginner user and as an advanced user it still does every now and then so it really should be changed to something more intuitive or forgiving. I really shouldn't have to sit and think "how do I reference a function in the file just one directory level below mine?" If there is already some magic bullet for this then it should probably be more visible. ---------- components: Interpreter Core messages: 171208 nosy: Jimbofbx priority: normal severity: normal status: open title: relative import headaches type: enhancement versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 04:38:26 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 25 Sep 2012 02:38:26 +0000 Subject: [issue16015] Incorrect startup header in tutorial In-Reply-To: <1348494782.32.0.720891839928.issue16015@psf.upfronthosting.co.za> Message-ID: <3XQmg448SDzQpP@mail.python.org> Roundup Robot added the comment: New changeset 5f4841977bee by Chris Jerdonek in branch '3.2': Issue #16015: Fix NameError doctest example in tutorial introduction. http://hg.python.org/cpython/rev/5f4841977bee New changeset dae33c2e916b by Chris Jerdonek in branch 'default': Issue #16015: Merge fix from 3.2. http://hg.python.org/cpython/rev/dae33c2e916b New changeset 878c33d2f301 by Chris Jerdonek in branch '2.7': Issue #16015: Fix NameError doctest example in tutorial introduction. http://hg.python.org/cpython/rev/878c33d2f301 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 05:07:25 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 25 Sep 2012 03:07:25 +0000 Subject: [issue16015] Incorrect startup header in tutorial In-Reply-To: <1348494782.32.0.720891839928.issue16015@psf.upfronthosting.co.za> Message-ID: <1348542445.24.0.769842756115.issue16015@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I don't mind fixing the year suggestion (in the interest of "realism" and for practice). ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 05:12:12 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 25 Sep 2012 03:12:12 +0000 Subject: [issue16001] small ints: cache string representation In-Reply-To: <1348272680.09.0.237238464287.issue16001@psf.upfronthosting.co.za> Message-ID: <1348542732.57.0.723082421521.issue16001@psf.upfronthosting.co.za> Martin v. L?wis added the comment: -1 for this entire effort. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 05:44:58 2012 From: report at bugs.python.org (Omanand Jha Vatsa) Date: Tue, 25 Sep 2012 03:44:58 +0000 Subject: [issue16032] IDLE 3.2 is crashing multiple times Message-ID: <1348544697.27.0.843034170589.issue16032@psf.upfronthosting.co.za> New submission from Omanand Jha Vatsa: Crashed multiple times on clicking Preferences in IDLE menu. It is crashing while trying to copying things from the IDLE shell. ---------- assignee: ronaldoussoren components: Macintosh files: Python_2012-09-24-234004_BLMACPRO3137C.crash messages: 171212 nosy: Omanand.Jha.Vatsa, ronaldoussoren priority: normal severity: normal status: open title: IDLE 3.2 is crashing multiple times type: crash versions: Python 3.2 Added file: http://bugs.python.org/file27287/Python_2012-09-24-234004_BLMACPRO3137C.crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 06:08:12 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 25 Sep 2012 04:08:12 +0000 Subject: [issue16032] IDLE 3.2 is crashing multiple times In-Reply-To: <1348544697.27.0.843034170589.issue16032@psf.upfronthosting.co.za> Message-ID: <1348546092.07.0.154233657978.issue16032@psf.upfronthosting.co.za> Ned Deily added the comment: This is due to a bug in the current Cocoa Tk as released in ActiveTcl 8.5.12.1 (and 8.5.12). Try installing the previous ActiveTcl version, 8.5.11.1, which I just discovered is still available here: http://downloads.activestate.com/ActiveTcl/releases/8.5.11.1/ ---------- assignee: ronaldoussoren -> ned.deily nosy: +ned.deily resolution: -> duplicate status: open -> pending superseder: -> IDLE crashes selecting Preferences menu with OS X ActiveState Tcl/Tk 8.5.12.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 06:15:14 2012 From: report at bugs.python.org (jimbo1qaz) Date: Tue, 25 Sep 2012 04:15:14 +0000 Subject: [issue16033] IDLE crashes when debugging and saving Message-ID: <1348546514.17.0.0573110140957.issue16033@psf.upfronthosting.co.za> New submission from jimbo1qaz: Have the debugger open, stopped on a breakpoint, and save the open file. The whole thing will bomb after the save finishes. Changes are not lost, but I have to reopen IDLE and lose history and breakpoints. ---------- components: IDLE messages: 171214 nosy: jimbo1qaz priority: normal severity: normal status: open title: IDLE crashes when debugging and saving versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 06:29:08 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 25 Sep 2012 04:29:08 +0000 Subject: [issue16033] IDLE crashes when debugging and saving In-Reply-To: <1348546514.17.0.0573110140957.issue16033@psf.upfronthosting.co.za> Message-ID: <1348547348.87.0.165296168263.issue16033@psf.upfronthosting.co.za> Ned Deily added the comment: What operating system are you using? Which python 3.2 are you using (i.e. a particular installer downloaded from python.org, built from source, etc)? If known, which version of Tcl/Tk are you using? ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 06:39:33 2012 From: report at bugs.python.org (Victor Hooi) Date: Tue, 25 Sep 2012 04:39:33 +0000 Subject: [issue16034] bz2 module appears slower in Python 3.x versus Python 2.x Message-ID: <1348547973.67.0.489000428853.issue16034@psf.upfronthosting.co.za> New submission from Victor Hooi: Hi, I was writing a script to parse BZ2 blogfiles under Python 2.6, and I noticed that bz2file (http://pypi.python.org/pypi/bz2file) seemed to perform much slower than with bz2 (native): http://stackoverflow.com/questions/12575930/is-python-bz2file-slower-than-bz2 I wrote a dummy script that basically just reads through the file, one for bz2 and one for bz2file (attached): [vichoo at dev_desktop_vm Desktop]$ time /opt/python3.3/bin/python3.3 testbz2.py > /dev/null real 0m5.170s user 0m5.009s sys 0m0.030s [vichoo at dev_desktop_vm Desktop]$ time /opt/python3.3/bin/python3.3 testbz2file.py > /dev/null real 0m5.245s user 0m4.979s sys 0m0.060s [vichoo at dev_desktop_vm Desktop]$ time /opt/python2.7/bin/python2.7 testbz2.py > /dev/null real 0m0.500s user 0m0.410s sys 0m0.030s [vichoo at dev_desktop_vm Desktop]$ time /opt/python2.7/bin/python2.7 testbz2file.py > /dev/null real 0m5.801s user 0m5.529s sys 0m0.050s I also executed "echo 3 > /proc/sys/vm/drop_cache" between each run. >From this, it appears that Python 2.x's bz2 is fast, but bz2file is slow - and that Python 3.x's bz2 is slow. Obviously, there could be an issue with the methdology above - however, if not, do you know if there are any performance regressions in bz2 from Python 2.x to 3.x? Thanks, Victor ---------- components: None files: testbz2file.py messages: 171216 nosy: victorhooi priority: normal severity: normal status: open title: bz2 module appears slower in Python 3.x versus Python 2.x type: performance versions: Python 3.3 Added file: http://bugs.python.org/file27288/testbz2file.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 06:48:54 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 25 Sep 2012 04:48:54 +0000 Subject: [issue16033] IDLE crashes when debugging and saving In-Reply-To: <1348546514.17.0.0573110140957.issue16033@psf.upfronthosting.co.za> Message-ID: <1348548534.88.0.614764206005.issue16033@psf.upfronthosting.co.za> Ned Deily added the comment: With 3.2.3 (on OS X), if I open a new edit window, enter a few files, save the file, set a breakpoint on a line, then save the file again (with or without having debug on), the following exception occurs but IDLE keeps running: Exception in Tkinter callback Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/tkinter/__init__.py", line 1399, in __call__ return self.func(*args) File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/MultiCall.py", line 166, in handler r = l[i](event) File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/IOBinding.py", line 336, in save self.editwin.store_file_breaks() File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/PyShell.py", line 214, in store_file_breaks self.update_breakpoints() File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/PyShell.py", line 244, in update_breakpoints linenumber_list = self.ranges_to_linenumbers(ranges) File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/PyShell.py", line 250, in ranges_to_linenumbers lineno = int(float(ranges[index])) TypeError: float() argument must be a string or a number In a quick attempt, I was not able to produce the same exception with 3.3.0rc3. ---------- nosy: +serwy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 06:57:30 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 25 Sep 2012 04:57:30 +0000 Subject: [issue16034] bz2 module appears slower in Python 3.x versus Python 2.x In-Reply-To: <1348547973.67.0.489000428853.issue16034@psf.upfronthosting.co.za> Message-ID: <1348549050.43.0.0887668935374.issue16034@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +nadeem.vawda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 07:05:35 2012 From: report at bugs.python.org (Roger Serwy) Date: Tue, 25 Sep 2012 05:05:35 +0000 Subject: [issue16033] IDLE crashes when debugging and saving In-Reply-To: <1348546514.17.0.0573110140957.issue16033@psf.upfronthosting.co.za> Message-ID: <1348549535.17.0.533165807475.issue16033@psf.upfronthosting.co.za> Roger Serwy added the comment: This was fixed in issue9803, but after the 3.2.3 release. I'm closing this issue as a duplicate. ---------- resolution: -> duplicate status: open -> closed superseder: -> IDLE closes with save while breakpoint open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 07:34:53 2012 From: report at bugs.python.org (Roger Serwy) Date: Tue, 25 Sep 2012 05:34:53 +0000 Subject: [issue11103] Python 3.2 installer doesn't register file extensions on Windows 7 In-Reply-To: <1296682766.55.0.843230930362.issue11103@psf.upfronthosting.co.za> Message-ID: <1348551293.22.0.125966969675.issue11103@psf.upfronthosting.co.za> Roger Serwy added the comment: The latest 3.2.3 release for Win7-64 registers the .py extensions properly, with "Open" and "Edit with IDLE". I'm closing this issue as out of date. ---------- nosy: +serwy resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 07:47:34 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 25 Sep 2012 05:47:34 +0000 Subject: [issue16031] relative import headaches In-Reply-To: <1348535267.9.0.55515174451.issue16031@psf.upfronthosting.co.za> Message-ID: <1348552054.16.0.238914959847.issue16031@psf.upfronthosting.co.za> Nick Coghlan added the comment: There is no magic bullet, but there are a whole mess of backwards compatibility constraints. Closing this as a duplicate, because there's no clear resolvable RFE here beyond the known issues with circular imports and the differences between lazy and eager imports (already well documented in #992389, although potentially easier to resolve in 3.4 now that we have migrated to importlib). Much of the rest of the complaint looks like a bug in pydev, as it appears to be running from a string *without creating an appropriate entry in sys.modules* first. Thus it *is* running through test_a twice due to the self import. Many of these apparent import problems stem from poor reimplementations of import mechanics in tools like pydev and nose violating import system invariants. With importlib being used as the reference import implementation and the language reference finally including formally documented import semantics in 3.3+, this problem should hopefully reduce over time, as these ad hoc reimplementations are replaced by appropriate usage of importlib and runpy. (Of course, the import system initialisation process is not without problems of its own, as PEP 395 describes) ---------- nosy: +ncoghlan resolution: -> duplicate status: open -> closed superseder: -> attribute error due to circular import versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 07:47:51 2012 From: report at bugs.python.org (Roger Serwy) Date: Tue, 25 Sep 2012 05:47:51 +0000 Subject: [issue15869] IDLE: Include .desktop file and icon In-Reply-To: <1346929874.07.0.220677915984.issue15869@psf.upfronthosting.co.za> Message-ID: <1348552071.11.0.448423810657.issue15869@psf.upfronthosting.co.za> Roger Serwy added the comment: I tried the provided .desktop files and they work with Gnome 3.4. ---------- keywords: +easy nosy: +serwy title: Include .desktop file and icon -> IDLE: Include .desktop file and icon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 07:53:41 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 25 Sep 2012 05:53:41 +0000 Subject: [issue16034] bz2 module appears slower in Python 3.x versus Python 2.x In-Reply-To: <1348547973.67.0.489000428853.issue16034@psf.upfronthosting.co.za> Message-ID: <1348552421.52.0.376529635387.issue16034@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It looks as bz2 in Python 3.3 has bad buffering. Reading by larger chunks shows the same speed in 2.7 and 3.3. ---------- components: +Library (Lib) -None nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 08:18:53 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 25 Sep 2012 06:18:53 +0000 Subject: [issue16034] bz2 module appears slower in Python 3.x versus Python 2.x In-Reply-To: <1348547973.67.0.489000428853.issue16034@psf.upfronthosting.co.za> Message-ID: <1348553933.42.0.544370779821.issue16034@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Well, I was able to restore performance (using same code as in zipfile). The patch will be later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 08:19:42 2012 From: report at bugs.python.org (Victor Hooi) Date: Tue, 25 Sep 2012 06:19:42 +0000 Subject: [issue16034] bz2 module appears slower in Python 3.x versus Python 2.x In-Reply-To: <1348547973.67.0.489000428853.issue16034@psf.upfronthosting.co.za> Message-ID: <1348553982.03.0.280208644879.issue16034@psf.upfronthosting.co.za> Victor Hooi added the comment: Hi, I didn't have any buffering size set before, so I believe it defaults to 0 (no buffering), right? Wouldn't this be the behaviour on both 2.x and 3.x? I'm using a 1.5 Mb bzip2 file - I just tried setting buffering to 1000 and 1000000, and it didn't seem to make any noticeable difference to the speed of reading in the file. E.g.: f = bz2.BZ2File(filename, 'rb', buffering=1000000) What sort of values did you use in relation to your compressed file size to get the improvements? Cheers, Victor ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 08:23:31 2012 From: report at bugs.python.org (Victor Hooi) Date: Tue, 25 Sep 2012 06:23:31 +0000 Subject: [issue16034] bz2 module appears slower in Python 3.x versus Python 2.x In-Reply-To: <1348547973.67.0.489000428853.issue16034@psf.upfronthosting.co.za> Message-ID: <1348554211.72.0.33204724136.issue16034@psf.upfronthosting.co.za> Victor Hooi added the comment: Hi, Aha, whoops, sorry Serhiy, didn't see your second message - I think you and I posted our last messages at nearly the same time... Cool, looking forward to your patch =). Also, is there any chance you could provide a more detailed explanation of what's going on? This is just me being curious about how it all works under the hood... Cheers, Victor ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 08:41:29 2012 From: report at bugs.python.org (Omanand Jha Vatsa) Date: Tue, 25 Sep 2012 06:41:29 +0000 Subject: [issue16032] IDLE 3.2 is crashing multiple times In-Reply-To: <1348544697.27.0.843034170589.issue16032@psf.upfronthosting.co.za> Message-ID: <1348555289.08.0.656217734984.issue16032@psf.upfronthosting.co.za> Omanand Jha Vatsa added the comment: I have tried re-installing to 8.5.11.1. Still same issue. I am on Mac OSX 10.7.4 version. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 08:57:12 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 25 Sep 2012 06:57:12 +0000 Subject: [issue16032] IDLE 3.2 is crashing multiple times In-Reply-To: <1348544697.27.0.843034170589.issue16032@psf.upfronthosting.co.za> Message-ID: <1348556232.4.0.0272680501005.issue16032@psf.upfronthosting.co.za> Ned Deily added the comment: Odd, it works for me. Check to make sure it really got installed: $ cd /Library/Frameworks/Tk.framework/ $ grep PATCH tkConfig.sh TK_PATCH_LEVEL='.11' You could manually delete the frameworks and try installing again: $ cd /Library/Frameworks $ sudo rm -r ./Tcl.framework $ sudo rm -r ./Tk.framework ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 09:16:40 2012 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 25 Sep 2012 07:16:40 +0000 Subject: [issue16029] pickle.dumps(xrange(sys.maxsize)) produces xrange(0) In-Reply-To: <1348518540.13.0.547483002596.issue16029@psf.upfronthosting.co.za> Message-ID: <1348557400.72.0.711546074746.issue16029@psf.upfronthosting.co.za> Mark Dickinson added the comment: Updated patch, which also fixes issue 16030. It needs more tests. ---------- Added file: http://bugs.python.org/file27289/xrange_reduce_repr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 09:17:16 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 25 Sep 2012 07:17:16 +0000 Subject: [issue16013] small csv reader bug In-Reply-To: <1348491792.39.0.00618601585478.issue16013@psf.upfronthosting.co.za> Message-ID: <1348557436.82.0.817525067951.issue16013@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a test. ---------- Added file: http://bugs.python.org/file27290/csv_eof_test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 09:26:04 2012 From: report at bugs.python.org (Zellmeyer) Date: Tue, 25 Sep 2012 07:26:04 +0000 Subject: [issue16023] IDLE froze when typing ctrl-shift-5 In-Reply-To: <1348500115.21.0.649772246938.issue16023@psf.upfronthosting.co.za> Message-ID: <1348557964.71.0.823199951019.issue16023@psf.upfronthosting.co.za> Zellmeyer added the comment: I used OSX 10.8.2 build 12C54 on both Macbookair and iMac I have ActiveState TCL installed 8.5 Ctrl-shift-5 does not correspond to a special character on my keyboard layout. But i discovered that this combination open a window called "tab width" in the IDLE shell and the crash appears then the combination is done in a script window of IDLE ---------- Added file: http://bugs.python.org/file27291/Capture d??cran 2012-09-25 ? 09.24.35.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 09:37:53 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 25 Sep 2012 07:37:53 +0000 Subject: [issue16034] bz2 module appears slower in Python 3.x versus Python 2.x In-Reply-To: <1348554211.72.0.33204724136.issue16034@psf.upfronthosting.co.za> Message-ID: <201209251037.40494.storchaka@gmail.com> Serhiy Storchaka added the comment: > Cool, looking forward to your patch =). It will take some time to make a completed patch. I don't have much time *right* now. Wait for a few hours. > Also, is there any chance you could provide a more detailed explanation of > what's going on? This is just me being curious about how it all works > under the hood... When reading from the buffer bz2 does: result = buffer[:size] buffer = buffer[size:] # copy a thousands bytes zipfile does: result = buffer[offset:offset+size] offset += size # buffer untouched ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 10:22:39 2012 From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=) Date: Tue, 25 Sep 2012 08:22:39 +0000 Subject: [issue8425] a -= b should be fast if a is a small set and b is a large set In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za> Message-ID: <1348561359.44.0.769425323107.issue8425@psf.upfronthosting.co.za> Michele Orr? added the comment: Updated. tumbolandia:cpython maker$ hg import --no-commit -f issue8425.2.patch && make -j3 >/dev/null 2>/dev/null sto applicando issue8425.2.patch tumbolandia:cpython maker$ ./python.exe bench.py starting... setting up tests... testing... big_timer_no_intersection 0.0005461599998852762 big_timer_subtraction 382.0618862710003 small_timer 0.0034195990001535392 big_timer 603.5105132449999 std_timer_subtraction 0.0006865100003778934 big_timer_reversed 292.44042680999974 std_timer 8.092500047496287e-05 [44705 refs] tumbolandia:cpython maker$ hg co -C && make -j3 >/dev/null 2>/dev/null1 files updated, 0 files merged, 0 files removed, 0 files unresolved tumbolandia:cpython maker$ ./python.exe bench.py starting... setting up tests... testing... big_timer_subtraction 611.292889542 big_timer 465.68463925800006 small_timer 0.002618359999360109 big_timer_reversed 256.5112134430001 std_timer 0.00011092699969594833 big_timer_no_intersection 0.0005648139995173551 std_timer_subtraction 2.8619999284273945e-05 [44705 refs] ---------- Added file: http://bugs.python.org/file27292/issue8425.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 10:23:09 2012 From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=) Date: Tue, 25 Sep 2012 08:23:09 +0000 Subject: [issue8425] a -= b should be fast if a is a small set and b is a large set In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za> Message-ID: <1348561389.24.0.148164677754.issue8425@psf.upfronthosting.co.za> Changes by Michele Orr? : Added file: http://bugs.python.org/file27293/bench.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 11:21:42 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 25 Sep 2012 09:21:42 +0000 Subject: [issue16013] small csv reader bug In-Reply-To: <1348491792.39.0.00618601585478.issue16013@psf.upfronthosting.co.za> Message-ID: <1348564902.83.0.839335345396.issue16013@psf.upfronthosting.co.za> Senthil Kumaran added the comment: The patch looks good and is doing the right thing, that is, when the, strict mode is passed, it fails and without strict mode, it is printing the parsed list. ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 11:32:46 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 25 Sep 2012 09:32:46 +0000 Subject: [issue16015] Incorrect startup header in tutorial In-Reply-To: <1348494782.32.0.720891839928.issue16015@psf.upfronthosting.co.za> Message-ID: <1348565566.94.0.413550013524.issue16015@psf.upfronthosting.co.za> Ezio Melotti added the comment: OK. If you change the date also change s/py3k/default/, py3k was used on the SVN days. Here is what my header looks like: $ python3 Python 3.2.3 (default, May 3 2012, 15:54:42) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. While you are at it, you could also add .. code-block:: sh. ---------- stage: needs patch -> type: enhancement -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 11:37:30 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 25 Sep 2012 09:37:30 +0000 Subject: [issue16013] small csv reader bug In-Reply-To: <1348491792.39.0.00618601585478.issue16013@psf.upfronthosting.co.za> Message-ID: <3XQxyc6HytzQcS@mail.python.org> Roundup Robot added the comment: New changeset e9c005676d6e by Senthil Kumaran in branch '3.2': Issue #16013: Fix CSV Reader parsing issue with ending quote characters. Patch by Serhiy Storchaka. http://hg.python.org/cpython/rev/e9c005676d6e New changeset 25f0756deeae by Senthil Kumaran in branch 'default': merge 3.2: Issue #16013: Fix CSV Reader parsing issue with ending quote characters. Patch by Serhiy Storchaka. http://hg.python.org/cpython/rev/25f0756deeae ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 11:40:44 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 25 Sep 2012 09:40:44 +0000 Subject: [issue16035] Segmentation fault in test suite of apsw Message-ID: <1348566044.22.0.909419846865.issue16035@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis: The fix for issue #13992 introduced segmentation fault in test suite of apsw (http://code.google.com/p/apsw/) (with Python 2.7, 3.2 and 3.3). $ python2.7 setup.py build running build running build_ext SQLite: Using system sqlite include/libraries building 'apsw' extension creating build creating build/temp.linux-x86_64-2.7 creating build/temp.linux-x86_64-2.7/src x86_64-pc-linux-gnu-gcc -pthread -DNDEBUG -O2 -fPIC -DEXPERIMENTAL=1 -DNDEBUG=1 -DAPSW_FORK_CHECKER=1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -Isrc -I/usr/include/python2.7 -c src/apsw.c -o build/temp.linux-x86_64-2.7/src/apsw.o In file included from /usr/include/python2.7/Python.h:8:0, from src/apsw.c:73: /usr/include/python2.7/pyconfig.h:1161:0: warning: "_POSIX_C_SOURCE" redefined [enabled by default] /usr/include/features.h:215:0: note: this is the location of the previous definition creating build/lib.linux-x86_64-2.7 x86_64-pc-linux-gnu-gcc -pthread -shared -O2 build/temp.linux-x86_64-2.7/src/apsw.o -L/usr/lib64 -lsqlite3 -lpython2.7 -o build/lib.linux-x86_64-2.7/apsw.so $ PYTHONPATH="build/lib.linux-x86_64-2.7" python2.7 tests.py -v Python /usr/bin/python2.7 sys.version_info(major=2, minor=7, micro=4, releaselevel='alpha', serial=0) Testing with APSW file /tmp/apsw-3.7.14-r1/build/lib.linux-x86_64-2.7/apsw.so APSW version 3.7.14-r1 SQLite lib version 3.7.14 SQLite headers version 3007014 Using amalgamation False testAggregateFunctions (__main__.APSW) Verify aggregate functions ... Segmentation fault ---------- messages: 171236 nosy: Arfrever, benjamin.peterson, georg.brandl, pitrou priority: release blocker severity: normal status: open title: Segmentation fault in test suite of apsw versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 11:48:43 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 25 Sep 2012 09:48:43 +0000 Subject: [issue16013] small csv reader bug In-Reply-To: <1348491792.39.0.00618601585478.issue16013@psf.upfronthosting.co.za> Message-ID: <3XQyCZ2Hr3zQZl@mail.python.org> Roundup Robot added the comment: New changeset 5f0465d0e91e by Senthil Kumaran in branch '2.7': 2.7 : Issue #16013: Fix CSV Reader parsing issue with ending quote characters. Patch by Serhiy Storchaka. http://hg.python.org/cpython/rev/5f0465d0e91e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 12:18:30 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 25 Sep 2012 10:18:30 +0000 Subject: [issue16036] simplify int() signature docs Message-ID: <1348568310.1.0.968219969881.issue16036@psf.upfronthosting.co.za> New submission from Chris Jerdonek: This issue is to simplify the documentation of the built-in function int()'s signature: int([number | string[, base]]) and to make any needed changes to the text of the docs as a consequence. Discussion around this issue began in the comments to issue 14783 about int() and str()'s docstrings. [I copied the nosy list from that issue.] ---------- assignee: docs at python components: Documentation keywords: easy messages: 171238 nosy: chris.jerdonek, cvrebert, docs at python, eric.araujo, ezio.melotti, georg.brandl, rhettinger, storchaka, terry.reedy, tshepang priority: normal severity: normal status: open title: simplify int() signature docs type: enhancement versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 12:19:15 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 25 Sep 2012 10:19:15 +0000 Subject: [issue14783] Make int() and str() docstrings correct In-Reply-To: <1336751413.58.0.519130225761.issue14783@psf.upfronthosting.co.za> Message-ID: <1348568355.66.0.148768279039.issue14783@psf.upfronthosting.co.za> Chris Jerdonek added the comment: To make it easier to make progress on this docstring issue, I created issue 16036 to focus on int()'s reST documentation. (I have a comment on that aspect.) This will allow the current issue to focus on the docstring aspect. ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 12:25:22 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Sep 2012 10:25:22 +0000 Subject: [issue16037] httplib: header parsing is not delimited Message-ID: <1348568722.91.0.654032066819.issue16037@psf.upfronthosting.co.za> New submission from Christian Heimes: The httplib module / package can read arbitrary amounts of data from its socket when it's parsing the HTTP header. This may lead to issues when a user connects to a broken HTTP server or something that isn't a HTTP at all. The issue can be broken up into two parts: parsing the HTTP status line parsing and parsing the remaining HTTP headers. Reading and parsing of the HTTP status line is already limited in Python 3.x. Python 2.7 and lower may read arbitrary amounts of bytes from the socket until it finds a newline char. The small patch below is a backport of the Python 3.x behavior to 2.7: --- a/Lib/httplib.py +++ b/Lib/httplib.py @@ -362,7 +362,9 @@ def _read_status(self): # Initialize with Simple-Response defaults - line = self.fp.readline() + line = self.fp.readline(_MAXLINE + 1) + if len(line) > _MAXLINE: + raise LineTooLong("header line") if self.debuglevel > 0: print "reply:", repr(line) if not line: Both Python 2 and Python 3 accept an unlimited count of HTTP headers with a maximum length of 64k each. As headers are accumulated in an list it may consume lots of memory. I suggest that we limit the maximum amount of HTTP header lines to a sane value. How does 100 sound to you? ---------- components: Library (Lib) messages: 171240 nosy: christian.heimes priority: normal severity: normal status: open title: httplib: header parsing is not delimited type: resource usage versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 12:32:55 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Sep 2012 10:32:55 +0000 Subject: [issue16038] ftplib: unlimited readline() from connection Message-ID: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za> New submission from Christian Heimes: This bug is similar to #16037. The ftplib module doesn't limit the amount of read data in its call to readline(). An erroneous or malicious FTP server can trick the ftplib module to consume large amounts of memory. Suggestion: The ftplib module should be modified to use limited readline() with _MAXLINE like the httplib module. ---------- components: Library (Lib) messages: 171241 nosy: christian.heimes priority: normal severity: normal status: open title: ftplib: unlimited readline() from connection type: resource usage versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 12:36:10 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Sep 2012 10:36:10 +0000 Subject: [issue16039] imaplib: unlimited readline() from connection Message-ID: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za> New submission from Christian Heimes: This bug is similar to #16037 and a modified copy of #16038. The imaplib module doesn't limit the amount of read data in its call to readline(). An erroneous or malicious IMAP server can trick the imaplib module to consume large amounts of memory. Suggestion: The imaplib module should be modified to use limited readline() with _MAXLINE like the httplib module. ---------- components: Library (Lib) messages: 171242 nosy: christian.heimes priority: normal severity: normal status: open title: imaplib: unlimited readline() from connection type: resource usage _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 12:38:45 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Sep 2012 10:38:45 +0000 Subject: [issue16040] nntplib: unlimited readline() from connection Message-ID: <1348569525.38.0.219080768405.issue16040@psf.upfronthosting.co.za> New submission from Christian Heimes: This bug is similar to #16037 and a modified copy of #16038. The nntplib module doesn't limit the amount of read data in its call to readline(). An erroneous or malicious news server can trick the nntplib module to consume large amounts of memory. Suggestion: The nntplib module should be modified to use limited readline() with _MAXLINE like the httplib module. ---------- components: Library (Lib) messages: 171243 nosy: christian.heimes priority: normal severity: normal status: open title: nntplib: unlimited readline() from connection type: resource usage versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 12:39:23 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Sep 2012 10:39:23 +0000 Subject: [issue16041] poplib: unlimited readline() from connection Message-ID: <1348569563.2.0.69634867698.issue16041@psf.upfronthosting.co.za> New submission from Christian Heimes: This bug is similar to #16037 and a modified copy of #16038. The poplib module doesn't limit the amount of read data in its call to readline(). An erroneous or malicious POP3 server can trick the poplib module to consume large amounts of memory. Suggestion: The poplib module should be modified to use limited readline() with _MAXLINE like the httplib module. ---------- components: Library (Lib) messages: 171244 nosy: christian.heimes priority: normal severity: normal status: open title: poplib: unlimited readline() from connection type: resource usage versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 12:40:09 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Sep 2012 10:40:09 +0000 Subject: [issue16042] smtplib: unlimited readline() from connection Message-ID: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za> New submission from Christian Heimes: This bug is similar to #16037 and a modified copy of #16038. The smtplib module doesn't limit the amount of read data in its call to readline(). An erroneous or malicious SMTP server can trick the smtplib module to consume large amounts of memory. Suggestion: The smtplib module should be modified to use limited readline() with _MAXLINE like the httplib module. ---------- components: Library (Lib) messages: 171245 nosy: christian.heimes priority: normal severity: normal status: open title: smtplib: unlimited readline() from connection type: resource usage versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 12:52:06 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Sep 2012 10:52:06 +0000 Subject: [issue16043] xmlrpc: gzip_decode has unlimited read() Message-ID: <1348570326.9.0.587983624118.issue16043@psf.upfronthosting.co.za> New submission from Christian Heimes: The xmlrpc client library is the only stdlib module that has a gzip decompression handler for compressed HTTP streams. The gzip_decode() function decompresses HTTP bodies that are compressed and sent with Accept-Encoding: x-gzip. A malicious server can send a specially prepared HTTP request that can consume lots of memory. For example 1 GB of \0 bytes is less than 1 MB of gzip data. Suggestion: The gzip_decode() should only decode a sane amount of bytes (for example 50 MB) and raise an exception when more data is to be read. ---------- components: Library (Lib) messages: 171246 nosy: christian.heimes priority: normal severity: normal status: open title: xmlrpc: gzip_decode has unlimited read() type: resource usage versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 12:53:05 2012 From: report at bugs.python.org (Ralf Schmitt) Date: Tue, 25 Sep 2012 10:53:05 +0000 Subject: [issue16043] xmlrpc: gzip_decode has unlimited read() In-Reply-To: <1348570326.9.0.587983624118.issue16043@psf.upfronthosting.co.za> Message-ID: <1348570385.0.0.545245725934.issue16043@psf.upfronthosting.co.za> Changes by Ralf Schmitt : ---------- nosy: +schmir _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 12:58:41 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Sep 2012 10:58:41 +0000 Subject: [issue16043] xmlrpc: gzip_decode has unlimited read() In-Reply-To: <1348570326.9.0.587983624118.issue16043@psf.upfronthosting.co.za> Message-ID: <1348570721.92.0.587662844566.issue16043@psf.upfronthosting.co.za> Christian Heimes added the comment: Also see #15955 According to Nadeem it's not (easily) possible to detect how large the output is going to be. ---------- dependencies: +gzip, bz2, lzma: add method to get decompressed size _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 13:03:15 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Sep 2012 11:03:15 +0000 Subject: [issue15955] gzip, bz2, lzma: add method to get decompressed size In-Reply-To: <1347884562.79.0.801674791772.issue15955@psf.upfronthosting.co.za> Message-ID: <1348570995.63.0.611208521302.issue15955@psf.upfronthosting.co.za> Christian Heimes added the comment: I've checked the implementation of the gzip command. It uses some tricks to get the result size of a compressed file. The bzip2 command doesn't have the ability. lzmainfo can print the actual size of the file but it says "Unknown" for my test file. Also see #16043 why this would be a useful feature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 13:17:05 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 25 Sep 2012 11:17:05 +0000 Subject: [issue16035] Segmentation fault in test suite of apsw In-Reply-To: <1348566044.22.0.909419846865.issue16035@psf.upfronthosting.co.za> Message-ID: <1348571825.07.0.409998699639.issue16035@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- assignee: -> pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 13:17:30 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 25 Sep 2012 11:17:30 +0000 Subject: [issue16035] Segmentation fault in test suite of apsw In-Reply-To: <1348566044.22.0.909419846865.issue16035@psf.upfronthosting.co.za> Message-ID: <1348571850.25.0.205015548134.issue16035@psf.upfronthosting.co.za> Georg Brandl added the comment: Can you provide a stacktrace? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 13:29:54 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 25 Sep 2012 11:29:54 +0000 Subject: [issue16037] httplib: header parsing is not delimited In-Reply-To: <1348568722.91.0.654032066819.issue16037@psf.upfronthosting.co.za> Message-ID: <3XR0SK2k66zQff@mail.python.org> Roundup Robot added the comment: New changeset 8a22a2804a66 by Christian Heimes in branch '2.7': Issue #16037: Limit httplib's _read_status() function to work around broken http://hg.python.org/cpython/rev/8a22a2804a66 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 13:31:24 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Sep 2012 11:31:24 +0000 Subject: [issue16037] httplib: header parsing is not delimited In-Reply-To: <1348568722.91.0.654032066819.issue16037@psf.upfronthosting.co.za> Message-ID: <1348572684.33.0.435760988756.issue16037@psf.upfronthosting.co.za> Christian Heimes added the comment: The readline() limitation in _read_status() was added at some point in the 3.2 line. Python 3.1 has an unlimited readline(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 13:35:22 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 25 Sep 2012 11:35:22 +0000 Subject: [issue16015] Incorrect startup header in tutorial In-Reply-To: <1348494782.32.0.720891839928.issue16015@psf.upfronthosting.co.za> Message-ID: <3XR0Zc54sszQpY@mail.python.org> Roundup Robot added the comment: New changeset d2df5bc89fc9 by Chris Jerdonek in branch '3.2': Issue #16015: Make welcome message more realistic in tutorial example. http://hg.python.org/cpython/rev/d2df5bc89fc9 New changeset fcb5bc824e3e by Chris Jerdonek in branch 'default': Issue #16015: Merge and update from 3.2. http://hg.python.org/cpython/rev/fcb5bc824e3e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 13:39:43 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 25 Sep 2012 11:39:43 +0000 Subject: [issue16015] Incorrect startup header in tutorial In-Reply-To: <1348494782.32.0.720891839928.issue16015@psf.upfronthosting.co.za> Message-ID: <1348573182.99.0.186563787439.issue16015@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Fixed, and thanks for the report! (Ezio, I didn't add "code-block:: sh" because it resulted in some undesired highlighting in the interpreter portion when I tried it.) ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 13:56:10 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 25 Sep 2012 11:56:10 +0000 Subject: [issue16035] Segmentation fault in test suite of apsw In-Reply-To: <1348566044.22.0.909419846865.issue16035@psf.upfronthosting.co.za> Message-ID: <1348574170.62.0.505313106078.issue16035@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I can't build apsw here: gcc -pthread -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -DEXPERIMENTAL=1 -DNDEBUG=1 -DAPSW_FORK_CHECKER=1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -Isrc -I/home/antoine/opt/include/python3.3m -c src/apsw.c -o build/temp.linux-x86_64-3.3/src/apsw.o src/apsw.c:62:2: erreur: #error Your SQLite version is too old. It must be at least 3.7.13 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 14:06:05 2012 From: report at bugs.python.org (kirpit) Date: Tue, 25 Sep 2012 12:06:05 +0000 Subject: [issue16044] xml.etree.ElementTree.Element: append method iterator param is broken Message-ID: <1348574765.38.0.275058753456.issue16044@psf.upfronthosting.co.za> New submission from kirpit: xml.etree.ElementTree.Element's append method doesn't support iterator/sequence parameters as it's supposed to, for the version 1.3.0. Python 2.7.3 (default, Sep 14 2012, 09:52:31) [GCC 4.2.1 Compatible Apple Clang 4.0 ((tags/Apple/clang-421.0.60))] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import xml.etree.ElementTree as et >>> et.VERSION '1.3.0' >>> root = et.Element('root') >>> sublist = [et.Element('sub'), et.Element('sub')] >>> root.append(sublist) >>> et.tostring(root) Traceback (most recent call last): File "", line 1, in File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py", line 1127, in tostring ElementTree(element).write(file, encoding, method=method) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py", line 818, in write self._root, encoding, default_namespace File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py", line 878, in _namespaces for elem in iterate(): File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py", line 477, in iter for e in e.iter(tag): AttributeError: 'list' object has no attribute 'iter' >>> root = et.Element('root') >>> root.append(iter(sublist)) >>> et.tostring(root) Traceback (most recent call last): File "", line 1, in File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py", line 1127, in tostring ElementTree(element).write(file, encoding, method=method) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py", line 818, in write self._root, encoding, default_namespace File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py", line 878, in _namespaces for elem in iterate(): File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py", line 477, in iter for e in e.iter(tag): AttributeError: 'listiterator' object has no attribute 'iter' ---------- assignee: ronaldoussoren components: Macintosh, XML messages: 171255 nosy: kirpit, ronaldoussoren priority: normal severity: normal status: open title: xml.etree.ElementTree.Element: append method iterator param is broken type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 14:13:17 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 25 Sep 2012 12:13:17 +0000 Subject: [issue16044] xml.etree.ElementTree.Element: append method iterator param is broken In-Reply-To: <1348574765.38.0.275058753456.issue16044@psf.upfronthosting.co.za> Message-ID: <1348575197.65.0.0311799620844.issue16044@psf.upfronthosting.co.za> Ronald Oussoren added the comment: (unassigning as this is not a mac-specific issue) BTW. Is this really a bug, the documentation says that append appends a single element : append(subelement) Adds the element subelement to the end of this elements internal list of subelements. ---------- assignee: ronaldoussoren -> nobody nosy: +nobody _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 14:26:58 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 25 Sep 2012 12:26:58 +0000 Subject: [issue15955] gzip, bz2, lzma: add option to limit output size In-Reply-To: <1347884562.79.0.801674791772.issue15955@psf.upfronthosting.co.za> Message-ID: <1348576018.5.0.484135278928.issue15955@psf.upfronthosting.co.za> Antoine Pitrou added the comment: You don't need to know the final size. You just need to be able to pass an output size limit. This would be an easy feature to add to functions like zlib.decompress(), since they already handle sizing of the output buffer. ---------- nosy: +pitrou title: gzip, bz2, lzma: add method to get decompressed size -> gzip, bz2, lzma: add option to limit output size _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 14:30:38 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 25 Sep 2012 12:30:38 +0000 Subject: [issue16037] httplib: header parsing is not delimited In-Reply-To: <1348568722.91.0.654032066819.issue16037@psf.upfronthosting.co.za> Message-ID: <1348576238.03.0.970257873749.issue16037@psf.upfronthosting.co.za> Antoine Pitrou added the comment: 100 headers sounds more than enough for everybody. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 14:33:13 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 25 Sep 2012 12:33:13 +0000 Subject: [issue16036] simplify int() signature docs In-Reply-To: <1348568310.1.0.968219969881.issue16036@psf.upfronthosting.co.za> Message-ID: <1348576393.53.0.172208737666.issue16036@psf.upfronthosting.co.za> Chris Jerdonek added the comment: [Continuing the issue 14783 discussion] > That said, I don't have a strong opinion about this, so if people think that x should be used, it's fine with me. I also feel that *x* should be used, since that is what the code enforces. I'm attaching a revised patch. This patch also makes related adjustments to the corresponding text. ---------- keywords: +needs review, patch stage: -> patch review Added file: http://bugs.python.org/file27294/issue-16036-1-default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 14:44:08 2012 From: report at bugs.python.org (kirpit) Date: Tue, 25 Sep 2012 12:44:08 +0000 Subject: [issue16044] xml.etree.ElementTree.Element: append method iterator param is broken In-Reply-To: <1348574765.38.0.275058753456.issue16044@psf.upfronthosting.co.za> Message-ID: <1348577048.64.0.214885207185.issue16044@psf.upfronthosting.co.za> kirpit added the comment: well, i've just followed the source code regardless to documentation so you may be right about appending a single element. (kind of newbie around here.) but then, append method is misbehaving about asserting the parameter, isn't it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 14:45:02 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 25 Sep 2012 12:45:02 +0000 Subject: [issue10980] http.server Header Unicode Bug In-Reply-To: <1295700354.03.0.333269896981.issue10980@psf.upfronthosting.co.za> Message-ID: <1348577102.25.0.930887850974.issue10980@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: accepted -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 14:51:06 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 25 Sep 2012 12:51:06 +0000 Subject: [issue16044] xml.etree.ElementTree.Element: append method iterator param is broken In-Reply-To: <1348574765.38.0.275058753456.issue16044@psf.upfronthosting.co.za> Message-ID: <1348577466.55.0.634666531321.issue16044@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Use the extend method to add multiple elements. Both the source and documentation indicate that 'append' is used for appending a single item and 'extend' for appending multiple items (just like with list). IMHO this is not a bug. As an aside: when you import xml.etree.cElementTree you get a faster implementation of the same interface, and this (C-based) implementation does validate arguments. ---------- resolution: -> invalid _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 14:54:35 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 25 Sep 2012 12:54:35 +0000 Subject: [issue2126] BaseHTTPServer.py fails long POST from IE In-Reply-To: <1203167938.11.0.556138107236.issue2126@psf.upfronthosting.co.za> Message-ID: <1348577675.49.0.501471536292.issue2126@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Reading the original issue: "it appears that IE is sending 2 extra bytes ('\r\n') after the request data. and if you don't read those two extra bytes off, the window's socket handling gets messed up. the result is that a partial response is returned and the socket closed. IE tries to recover by re-POST'ing (which is behavior specified in the HTTP/1.1 RFC)... only they seem to add an embedded NULL the second time through, and the original socket problem happens again anyway." ... I have a hard time believing IE is still broken today. I'd rather close this issue, please re-open if you can reproduce with a recent IE. ---------- nosy: +pitrou resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 15:00:20 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 25 Sep 2012 13:00:20 +0000 Subject: [issue14414] xmlrpclib leaves connection in broken state if server returns error without content-length In-Reply-To: <1332778465.08.0.819519448389.issue14414@psf.upfronthosting.co.za> Message-ID: <1348578020.28.0.474249906607.issue14414@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +flox, loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 15:02:01 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 25 Sep 2012 13:02:01 +0000 Subject: [issue14044] IncompleteRead error with urllib2 or urllib.request -- fine with urllib, wget, or curl In-Reply-To: <1329500177.48.0.42118882394.issue14044@psf.upfronthosting.co.za> Message-ID: <1348578121.19.0.284357976923.issue14044@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The example URL doesn't seem to work anymore. Do you have another example to test with? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 15:06:37 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 25 Sep 2012 13:06:37 +0000 Subject: [issue13403] Option for XMLPRC Server to support HTTPS In-Reply-To: <1321291767.37.0.486686259371.issue13403@psf.upfronthosting.co.za> Message-ID: <1348578397.92.0.604319006993.issue13403@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Note there's already a couple of HTTPS servers in Lib/test/ssl_servers.py. I'm not sure there's anything special to do for XMLRPC except to take the core instantiation code and put it in xmlrpclib. ---------- nosy: +flox, loewis, pitrou stage: -> needs patch versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 15:12:13 2012 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 25 Sep 2012 13:12:13 +0000 Subject: [issue16029] pickle.dumps(xrange(sys.maxsize)) produces xrange(0) In-Reply-To: <1348518540.13.0.547483002596.issue16029@psf.upfronthosting.co.za> Message-ID: <1348578733.49.0.946828662731.issue16029@psf.upfronthosting.co.za> Mark Dickinson added the comment: Patch with tests. ---------- components: +Interpreter Core -Library (Lib) stage: needs patch -> commit review Added file: http://bugs.python.org/file27295/xrange_reduce_repr_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 15:13:11 2012 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 25 Sep 2012 13:13:11 +0000 Subject: [issue16030] xrange repr broken for large arguments In-Reply-To: <1348521797.77.0.407946912471.issue16030@psf.upfronthosting.co.za> Message-ID: <1348578791.81.0.962323054896.issue16030@psf.upfronthosting.co.za> Mark Dickinson added the comment: The patch for issue #16029 fixes this issue, too. ---------- components: +Interpreter Core -Library (Lib) dependencies: +pickle.dumps(xrange(sys.maxsize)) produces xrange(0) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 15:14:19 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 25 Sep 2012 13:14:19 +0000 Subject: [issue16025] Minor corrections to the zipfile documentation In-Reply-To: <1348502882.43.0.635160318129.issue16025@psf.upfronthosting.co.za> Message-ID: <1348578859.08.0.309024102236.issue16025@psf.upfronthosting.co.za> Chris Jerdonek added the comment: - :meth:`close`\ d without adding any files to the archive, the appropriate + :meth:`close `\ d without adding any files to the archive, the appropriate This formatting looks odd to me when rendered (both cases). I would perhaps suggest something like, "... and then close() is called without ...." ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 15:14:48 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 25 Sep 2012 13:14:48 +0000 Subject: [issue12319] [http.client] HTTPConnection.putrequest not support "chunked" Transfer-Encodings to send data In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za> Message-ID: <1348578888.59.0.984855166345.issue12319@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > We had support for chunked transfer encoding for POST method recently, > which is exposed via urllib2 wrapper function. I couldn't find what you're talking about. If I look at AbstractHTTPHandler.do_request_, it actually mandates a Content-Length header for POST data (hence no chunked encoding). ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 15:20:30 2012 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 25 Sep 2012 13:20:30 +0000 Subject: [issue16029] pickle.dumps(xrange(sys.maxsize)) produces xrange(0) In-Reply-To: <1348518540.13.0.547483002596.issue16029@psf.upfronthosting.co.za> Message-ID: <1348579230.92.0.06733902634.issue16029@psf.upfronthosting.co.za> Mark Dickinson added the comment: Whoops; there's no need to iterate over pickle protocols in test_repr. New patch. ---------- Added file: http://bugs.python.org/file27296/xrange_reduce_repr_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 15:28:42 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 25 Sep 2012 13:28:42 +0000 Subject: [issue16045] create some unit tests for built-in int() Message-ID: <1348579722.08.0.96812684384.issue16045@psf.upfronthosting.co.za> New submission from Chris Jerdonek: The built-in function int() does not seem to have any basic unit tests (e.g. in test_builtin). It would be good to add some. Some cases (including edge cases) for possible inclusion: int() int(base='foo') # no exception; returns 0 int(x=5) int(x=5, base=10) # raises TypeError int(5.8) # test truncation towards zero int(-5.8) # ditto int('5.8') # raises ValueError Both positional and keyword argument combinations should be tested. ---------- components: Library (Lib) keywords: easy messages: 171270 nosy: chris.jerdonek, ezio.melotti priority: normal severity: normal status: open title: create some unit tests for built-in int() type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 15:29:10 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 25 Sep 2012 13:29:10 +0000 Subject: [issue2600] BindingHTTPConnectionWithTimeout and BindingHTTPHandlerWithTimeout In-Reply-To: <1207688700.18.0.242817334294.issue2600@psf.upfronthosting.co.za> Message-ID: <1348579750.09.0.148067743437.issue2600@psf.upfronthosting.co.za> Antoine Pitrou added the comment: HTTPConnection now supports timeout and source_address parameters, so this is really out of date. Thanks for reporting, though! (see http://docs.python.org/dev/library/http.client.html#http.client.HTTPConnection) ---------- nosy: +pitrou resolution: -> out of date stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 15:34:25 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 25 Sep 2012 13:34:25 +0000 Subject: [issue16027] pkgutil doesn't support frozen modules In-Reply-To: <1348506161.12.0.954547119673.issue16027@psf.upfronthosting.co.za> Message-ID: <1348580065.27.0.148064602182.issue16027@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- versions: +Python 3.4 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 15:36:18 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 25 Sep 2012 13:36:18 +0000 Subject: [issue16045] create some unit tests for built-in int() In-Reply-To: <1348579722.08.0.96812684384.issue16045@psf.upfronthosting.co.za> Message-ID: <1348580178.25.0.463572568226.issue16045@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, have you looked at test_int? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 15:37:21 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 25 Sep 2012 13:37:21 +0000 Subject: [issue16027] pkgutil doesn't support frozen modules In-Reply-To: <1348506161.12.0.954547119673.issue16027@psf.upfronthosting.co.za> Message-ID: <1348580241.03.0.400389390037.issue16027@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 15:42:57 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 25 Sep 2012 13:42:57 +0000 Subject: [issue16045] create some unit tests for built-in int() In-Reply-To: <1348579722.08.0.96812684384.issue16045@psf.upfronthosting.co.za> Message-ID: <1348580577.52.0.357321075854.issue16045@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks for the pointer. That should do it. :) Searching for "test_int(" completely missed test_int.py. ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 15:48:07 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 25 Sep 2012 13:48:07 +0000 Subject: [issue16045] add more unit tests for built-in int() In-Reply-To: <1348579722.08.0.96812684384.issue16045@psf.upfronthosting.co.za> Message-ID: <1348580887.34.0.763474536249.issue16045@psf.upfronthosting.co.za> Chris Jerdonek added the comment: [Reopening] Actually, there may still be value in this. Not all of the edge cases I mentioned are covered (e.g. calling using keyword arguments). ---------- resolution: invalid -> stage: committed/rejected -> test needed status: closed -> open title: create some unit tests for built-in int() -> add more unit tests for built-in int() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 15:54:47 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 25 Sep 2012 13:54:47 +0000 Subject: [issue16045] add more unit tests for built-in int() In-Reply-To: <1348579722.08.0.96812684384.issue16045@psf.upfronthosting.co.za> Message-ID: <1348581287.69.0.961499944779.issue16045@psf.upfronthosting.co.za> Chris Jerdonek added the comment: We should also add a code-comment pointer in test_builtin to test_int (where test_int() would be located). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 16:02:06 2012 From: report at bugs.python.org (Marco Buttu) Date: Tue, 25 Sep 2012 14:02:06 +0000 Subject: [issue16046] python -O does not find *.pyo files Message-ID: <1348581725.98.0.841014002753.issue16046@psf.upfronthosting.co.za> New submission from Marco Buttu: $ echo "print(__file__)" > foo.py $ python3.3 -O -m foo /home/marco/temp/foo.py $ ls foo.py __pycache__ $ rm foo.py $ mv __pycache__/foo.cpython-33.pyo foo.pyo $ rm __pycache__ -r $ ls foo.pyo # The following works in Python3.2, but not in Python 3.3.0rc3 $ python3.3 -O -m foo /usr/local/bin/python3.3: No module named foo ---------- components: Interpreter Core messages: 171276 nosy: mbuttu priority: normal severity: normal status: open title: python -O does not find *.pyo files versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 16:04:21 2012 From: report at bugs.python.org (Marco Buttu) Date: Tue, 25 Sep 2012 14:04:21 +0000 Subject: [issue16046] python -O does not find *.pyo files In-Reply-To: <1348581725.98.0.841014002753.issue16046@psf.upfronthosting.co.za> Message-ID: <1348581861.45.0.0498531337248.issue16046@psf.upfronthosting.co.za> Changes by Marco Buttu : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 16:06:20 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 25 Sep 2012 14:06:20 +0000 Subject: [issue16027] pkgutil doesn't support frozen modules In-Reply-To: <1348506161.12.0.954547119673.issue16027@psf.upfronthosting.co.za> Message-ID: <1348581980.89.0.327782767133.issue16027@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Here's the fix we're applying in pyrun to make -m imports work at least for top-level modules: --- /home/lemburg/orig/Python-2.7.3/Lib/pkgutil.py 2012-04-10 01:07:30.000000000 +0200 +++ pkgutil.py 2012-09-24 22:53:30.982526065 +0200 @@ -273,10 +273,21 @@ class ImpLoader: def is_package(self, fullname): fullname = self._fix_name(fullname) return self.etc[2]==imp.PKG_DIRECTORY def get_code(self, fullname=None): + if self.code is not None: + return self.code + fullname = self._fix_name(fullname) + mod_type = self.etc[2] + if mod_type == imp.PY_FROZEN: + self.code = imp.get_frozen_object(fullname) + return self.code + else: + return self._get_code(fullname) + + def _get_code(self, fullname=None): fullname = self._fix_name(fullname) if self.code is None: mod_type = self.etc[2] if mod_type==imp.PY_SOURCE: source = self.get_source(fullname) This makes runpy work for top-level frozen modules, but it's really only partial solution, since pkgutil would need to get such support in more places. We also found that for some reason, runpy/pkgutil does not work for frozen package imports, e.g. wsgiref.util. The reasons for this appear to be deeper than just in the pkgutil module. We don't have a solution for this yet. It is also not clear whether the problem still exists in Python 3.x. The __path__ attribute of frozen modules was changed in 3.0 to be a list like for all other modules, however, applying that change to 2.x lets runpy/pkgutil fail altogether (not even the above fix works anymore). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 16:08:52 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 25 Sep 2012 14:08:52 +0000 Subject: [issue16046] python -O does not find *.pyo files In-Reply-To: <1348581725.98.0.841014002753.issue16046@psf.upfronthosting.co.za> Message-ID: <1348582132.45.0.621359227038.issue16046@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- keywords: +3.3regression nosy: +brett.cannon, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 16:08:58 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 25 Sep 2012 14:08:58 +0000 Subject: [issue16025] Minor corrections to the zipfile documentation In-Reply-To: <1348502882.43.0.635160318129.issue16025@psf.upfronthosting.co.za> Message-ID: <1348582138.49.0.127152409025.issue16025@psf.upfronthosting.co.za> Ezio Melotti added the comment: :meth:`closed ` works too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 16:13:29 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 25 Sep 2012 14:13:29 +0000 Subject: [issue16035] Segmentation fault in test suite of apsw In-Reply-To: <1348566044.22.0.909419846865.issue16035@psf.upfronthosting.co.za> Message-ID: <1348582409.81.0.379686276598.issue16035@psf.upfronthosting.co.za> Stefan Krah added the comment: I don't get a segfault, but a fatal error. Here's the back trace (unfortunately I've no time to debug this further today; sqlite is the latest version compiled from source): #0 0x00007ffff71e6a75 in *__GI_raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007ffff71ea5c0 in *__GI_abort () at abort.c:92 #2 0x00000000005076a0 in Py_FatalError (msg=0x652a88 "PyThreadState_Get: no current thread") at Python/pythonrun.c:2360 #3 0x0000000000500a67 in PyThreadState_Get () at Python/pystate.c:423 #4 0x000000000043211f in tupledealloc (op=0x7ffff62ce4c0) at Objects/tupleobject.c:236 #5 0x000000000041fb5a in _Py_Dealloc (op=0x7ffff62ce4c0) at Objects/object.c:1764 #6 0x00000000005d6867 in func_dealloc (op=0x7ffff6b8eea0) at Objects/funcobject.c:564 #7 0x000000000041fb5a in _Py_Dealloc (op=0x7ffff6b8eea0) at Objects/object.c:1764 #8 0x00007ffff68754e2 in FunctionCBInfo_dealloc (self=0x7ffff6317bf0) at src/connection.c:119 #9 0x000000000041fb5a in _Py_Dealloc (op=0x7ffff6317bf0) at Objects/object.c:1764 #10 0x00007ffff687b4f4 in apsw_free_func (funcinfo=0x7ffff6317bf0) at src/connection.c:2221 #11 0x00007ffff65d03f7 in functionDestroy (db=0xd0cb08, p=0x26f4) at sqlite3.c:112342 #12 0x00007ffff65eb7e0 in sqlite3CreateFunc (db=0x8, zFunctionName=, nArg=-1, enc=1, pUserData=, xFunc=0, xStep=0x7ffff687ae90 , xFinal=0x7ffff687b0a4 , pDestructor=0xd05448) at sqlite3.c:112858 #13 0x00007ffff65ebb9c in sqlite3_create_function_v2 (db=0xd0cb08, zFunc=, nArg=-1, enc=1, p=0x7ffff6ba3988, xFunc=, xStep=0x7ffff687ae90 , xFinal=0x7ffff687b0a4 , xDestroy=0x7ffff687b47d ) at sqlite3.c:112913 #14 0x00007ffff687ba30 in Connection_createaggregatefunction (self=0x7ffff6b2cdd8, args=0x7ffff62f29c0) at src/connection.c:2395 #15 0x00000000005ffee7 in PyCFunction_Call (func=0x7ffff6bab768, arg=0x7ffff62f29c0, kw=0x0) at Objects/methodobject.c:81 #16 0x00000000004d0ea1 in call_function (pp_stack=0x7fffffff3b78, oparg=2) at Python/ceval.c:4062 #17 0x00000000004cab06 in PyEval_EvalFrameEx (f=0xd0d720, throwflag=0) at Python/ceval.c:2679 #18 0x00000000004cea43 in PyEval_EvalCodeEx (_co=0x7ffff6078940, globals=0x7ffff7eae330, locals=0x0, args=0xd0c598, argcount=1, kws=0xd0c5a0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3433 #19 0x00000000004d14cb in fast_function (func=0x7ffff63597e0, pp_stack=0x7fffffff47e8, n=1, na=1, nk=0) at Python/ceval.c:4160 #20 0x00000000004d1074 in call_function (pp_stack=0x7fffffff47e8, oparg=0) at Python/ceval.c:4083 #21 0x00000000004cab06 in PyEval_EvalFrameEx (f=0xd0c3e0, throwflag=0) at Python/ceval.c:2679 #22 0x00000000004cea43 in PyEval_EvalCodeEx (_co=0x7ffff6ae3580, globals=0x7ffff6bf1ba0, locals=0x0, args=0xd0c2e0, argcount=3, kws=0xd0c2f8, kwcount=1, defs=0x7ffff6ad6168, defcount=1, kwdefs=0x0, closure=0x0) at Python/ceval.c:3433 #23 0x00000000004d14cb in fast_function (func=0x7ffff6c0d420, pp_stack=0x7fffffff5458, n=5, na=3, nk=1) at Python/ceval.c:4160 #24 0x00000000004d1074 in call_function (pp_stack=0x7fffffff5458, oparg=258) at Python/ceval.c:4083 #25 0x00000000004cab06 in PyEval_EvalFrameEx (f=0xd0c100, throwflag=0) at Python/ceval.c:2679 #26 0x00000000004cea43 in PyEval_EvalCodeEx (_co=0x7ffff6ae3700, globals=0x7ffff6bf1ba0, locals=0x0, ---Type to continue, or q to quit--- args=0x7ffff6368628, argcount=2, kws=0x7ffff7fa9088, kwcount=0, defs=0x7ffff6c14da8, defcount=1, kwdefs=0x0, closure=0x0) at Python/ceval.c:3433 #27 0x00000000005d6e1f in function_call (func=0x7ffff6c0d4e0, arg=0x7ffff6368600, kw=0x7ffff62b8c18) at Objects/funcobject.c:633 #28 0x000000000059969b in PyObject_Call (func=0x7ffff6c0d4e0, arg=0x7ffff6368600, kw=0x7ffff62b8c18) at Objects/abstract.c:2083 #29 0x00000000004d239b in ext_do_call (func=0x7ffff6c0d4e0, pp_stack=0x7fffffff60f8, flags=3, na=1, nk=0) at Python/ceval.c:4377 #30 0x00000000004caf3c in PyEval_EvalFrameEx (f=0x7ffff62ef460, throwflag=0) at Python/ceval.c:2720 #31 0x00000000004cea43 in PyEval_EvalCodeEx (_co=0x7ffff6ae3a00, globals=0x7ffff6bf1ba0, locals=0x0, args=0x7ffff5acb1f0, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3433 #32 0x00000000005d6e1f in function_call (func=0x7ffff6c0d660, arg=0x7ffff5acb1c8, kw=0x0) at Objects/funcobject.c:633 #33 0x000000000059969b in PyObject_Call (func=0x7ffff6c0d660, arg=0x7ffff5acb1c8, kw=0x0) at Objects/abstract.c:2083 #34 0x00000000005b7cc4 in method_call (func=0x7ffff6c0d660, arg=0x7ffff5acb1c8, kw=0x0) at Objects/classobject.c:323 #35 0x000000000059969b in PyObject_Call (func=0x7ffff635c7e0, arg=0x7ffff63257d0, kw=0x0) at Objects/abstract.c:2083 #36 0x00000000004462c2 in slot_tp_call (self=0x7ffff62ce840, args=0x7ffff63257d0, kwds=0x0) at Objects/typeobject.c:5349 #37 0x000000000059969b in PyObject_Call (func=0x7ffff62ce840, arg=0x7ffff63257d0, kw=0x0) at Objects/abstract.c:2083 #38 0x00000000004d1d18 in do_call (func=0x7ffff62ce840, pp_stack=0x7fffffff6f48, na=1, nk=0) at Python/ceval.c:4282 #39 0x00000000004d1093 in call_function (pp_stack=0x7fffffff6f48, oparg=1) at Python/ceval.c:4085 #40 0x00000000004cab06 in PyEval_EvalFrameEx (f=0xd0ae60, throwflag=0) at Python/ceval.c:2679 #41 0x00000000004cea43 in PyEval_EvalCodeEx (_co=0x7ffff6c05700, globals=0x7ffff6bbe588, locals=0x0, args=0x7ffff62ed178, argcount=2, kws=0x7ffff7fa9088, kwcount=0, defs=0x7ffff6c306a8, defcount=1, kwdefs=0x0, closure=0x0) at Python/ceval.c:3433 #42 0x00000000005d6e1f in function_call (func=0x7ffff6c291e0, arg=0x7ffff62ed150, kw=0x7ffff635c678) at Objects/funcobject.c:633 [...] ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 16:28:20 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 25 Sep 2012 14:28:20 +0000 Subject: [issue16035] Segmentation fault in test suite of apsw In-Reply-To: <1348566044.22.0.909419846865.issue16035@psf.upfronthosting.co.za> Message-ID: <1348583300.67.0.745686260988.issue16035@psf.upfronthosting.co.za> Benjamin Peterson added the comment: My guess is an extension problem (failing to aqcuire locks?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 16:29:34 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 25 Sep 2012 14:29:34 +0000 Subject: [issue15935] clarify argparse docs re: add_argument() type and default arguments In-Reply-To: <1347485175.79.0.860808168134.issue15935@psf.upfronthosting.co.za> Message-ID: <1348583374.66.0.483875465581.issue15935@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Looks good to me too! Thanks; I'll apply the patch. ---------- assignee: docs at python -> barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 16:29:36 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 25 Sep 2012 14:29:36 +0000 Subject: [issue16027] pkgutil doesn't support frozen modules In-Reply-To: <1348506161.12.0.954547119673.issue16027@psf.upfronthosting.co.za> Message-ID: <1348583376.35.0.44662603492.issue16027@psf.upfronthosting.co.za> Nick Coghlan added the comment: Can you confirm this problem still exists on 3.3? The pkgutil emulation isn't used by runpy any more - with the migration to importlib, the interface that runpy invokes fails outright if no loader is found rather than falling back to the emulation (we only retained the emulation for backwards compatibility - it's a public API, so others may be using it directly). I have a feeling that there may still be a couple of checks which are restricted to PY_SOURCE and PY_COMPILED that really should be allowing PY_FROZEN as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 16:31:53 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 25 Sep 2012 14:31:53 +0000 Subject: [issue16035] Segmentation fault in test suite of apsw In-Reply-To: <1348566044.22.0.909419846865.issue16035@psf.upfronthosting.co.za> Message-ID: <1348583513.52.0.299873075413.issue16035@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The cause for Stefan's traceback looks quite clear: Connection_createaggregatefunction() release the GIL (through the PYSQLITE_CON_CALL macro) before calling into sqlite3_create_function_v2, which itself calls the destructor for the old aggregate function, aka. apsw_free_func(), which calls Py_DECREF without re-acquiring the GIL. So apsw needs to sanitize its callbacks implementation here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 16:48:34 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 25 Sep 2012 14:48:34 +0000 Subject: [issue15935] clarify argparse docs re: add_argument() type and default arguments In-Reply-To: <1347485175.79.0.860808168134.issue15935@psf.upfronthosting.co.za> Message-ID: <3XR4sX3b2SzNnR@mail.python.org> Roundup Robot added the comment: New changeset b624059a8dac by Barry Warsaw in branch '2.7': - Issue #15935: Clarification of argparse docs, re: add_argument() type and http://hg.python.org/cpython/rev/b624059a8dac New changeset b738e42e664a by Barry Warsaw in branch '3.2': - Issue #15935: Clarification of argparse docs, re: add_argument() type and http://hg.python.org/cpython/rev/b738e42e664a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 16:48:55 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 25 Sep 2012 14:48:55 +0000 Subject: [issue15935] clarify argparse docs re: add_argument() type and default arguments In-Reply-To: <1347485175.79.0.860808168134.issue15935@psf.upfronthosting.co.za> Message-ID: <1348584535.48.0.776602658664.issue15935@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 17:10:03 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 25 Sep 2012 15:10:03 +0000 Subject: [issue15935] clarify argparse docs re: add_argument() type and default arguments In-Reply-To: <1347485175.79.0.860808168134.issue15935@psf.upfronthosting.co.za> Message-ID: <1348585803.24.0.112363752593.issue15935@psf.upfronthosting.co.za> R. David Murray added the comment: FTR, the 3.3 commit is cce2bfe03dc5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 17:23:12 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 25 Sep 2012 15:23:12 +0000 Subject: [issue16035] Segmentation fault in test suite of apsw In-Reply-To: <1348566044.22.0.909419846865.issue16035@psf.upfronthosting.co.za> Message-ID: <1348586592.58.0.188906803548.issue16035@psf.upfronthosting.co.za> Georg Brandl added the comment: Not a blocker then. ---------- priority: release blocker -> normal resolution: -> invalid status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 17:23:16 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 25 Sep 2012 15:23:16 +0000 Subject: [issue16046] python -O does not find *.pyo files In-Reply-To: <1348581725.98.0.841014002753.issue16046@psf.upfronthosting.co.za> Message-ID: <3XR5db2NkWzQpc@mail.python.org> Roundup Robot added the comment: New changeset 4de5e4ec3cff by Benjamin Peterson in branch 'default': don't depend on __debug__ because it's baked in at freeze time (issue #16046) http://hg.python.org/cpython/rev/4de5e4ec3cff ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 17:23:30 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 25 Sep 2012 15:23:30 +0000 Subject: [issue16046] python -O does not find *.pyo files In-Reply-To: <1348581725.98.0.841014002753.issue16046@psf.upfronthosting.co.za> Message-ID: <1348586610.79.0.525846844417.issue16046@psf.upfronthosting.co.za> Benjamin Peterson added the comment: This "tested" in the sense if you run test_import with -O, it fails. We ought to have a buildbot running with -O. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 17:24:00 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 25 Sep 2012 15:24:00 +0000 Subject: [issue16046] python -O does not find *.pyo files In-Reply-To: <1348581725.98.0.841014002753.issue16046@psf.upfronthosting.co.za> Message-ID: <1348586640.26.0.382148242479.issue16046@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Georg, do you want to take this for 3.3, final? ---------- assignee: -> georg.brandl nosy: +georg.brandl priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 17:25:21 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 25 Sep 2012 15:25:21 +0000 Subject: [issue16046] python -O does not find *.pyo files In-Reply-To: <1348581725.98.0.841014002753.issue16046@psf.upfronthosting.co.za> Message-ID: <1348586721.96.0.50669609966.issue16046@psf.upfronthosting.co.za> Georg Brandl added the comment: Looks serious enough, yes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 17:40:20 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 25 Sep 2012 15:40:20 +0000 Subject: [issue16046] python -O does not find *.pyo files In-Reply-To: <1348581725.98.0.841014002753.issue16046@psf.upfronthosting.co.za> Message-ID: <1348587620.57.0.677758516592.issue16046@psf.upfronthosting.co.za> Georg Brandl added the comment: Transplanted to ff50579241cd. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 17:41:13 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 25 Sep 2012 15:41:13 +0000 Subject: [issue16027] pkgutil doesn't support frozen modules In-Reply-To: <1348583376.35.0.44662603492.issue16027@psf.upfronthosting.co.za> Message-ID: <5061D093.2030109@egenix.com> Marc-Andre Lemburg added the comment: Nick Coghlan wrote: > > Nick Coghlan added the comment: > > Can you confirm this problem still exists on 3.3? The pkgutil emulation isn't used by runpy any more - with the migration to importlib, the interface that runpy invokes fails outright if no loader is found rather than falling back to the emulation (we only retained the emulation for backwards compatibility - it's a public API, so others may be using it directly). That's difficult to test, since the Tools/freeze/ tool no longer works in Python 3.3. I'll open a separate issue for that. > I have a feeling that there may still be a couple of checks which are restricted to PY_SOURCE and PY_COMPILED that really should be allowing PY_FROZEN as well. Same here. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 25 2012) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2012-10-29: PyCon DE 2012, Leipzig, Germany ... 34 days to go 2012-10-23: Python Meeting Duesseldorf ... 28 days to go 2012-09-25: Released mxODBC 3.2.1 ... http://egenix.com/go31 2012-09-18: Released mxODBC Zope DA 2.1.0 ... http://egenix.com/go32 eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 17:46:20 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 25 Sep 2012 15:46:20 +0000 Subject: [issue16045] add more unit tests for built-in int() In-Reply-To: <1348579722.08.0.96812684384.issue16045@psf.upfronthosting.co.za> Message-ID: <1348587980.8.0.982525388732.issue16045@psf.upfronthosting.co.za> Ezio Melotti added the comment: Before adding tests (and possibly documentation) for edge cases like > int(base='foo') # no exception; returns 0 I'd take a look at what other implementations do. If they do something different we might still decide to keep the tests and mark them as cpython-specific, but I would refrain to document them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 17:47:11 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Sep 2012 15:47:11 +0000 Subject: [issue16042] smtplib: unlimited readline() from connection In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za> Message-ID: <1348588031.23.0.102095786296.issue16042@psf.upfronthosting.co.za> Christian Heimes added the comment: RFC 821 [1] specifies rather short line lengths between 512 and 1001 chars including the trailing CRLF. A line limit of a couple of kilobyte should definitely work with all standard conform SMTP clients and servers. [1] http://www.freesoft.org/CIE/RFC/821/24.htm ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 17:48:40 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Sep 2012 15:48:40 +0000 Subject: [issue16042] smtplib: unlimited readline() from connection In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za> Message-ID: <1348588120.13.0.288447682709.issue16042@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +barry, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 18:28:00 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 25 Sep 2012 16:28:00 +0000 Subject: [issue16047] Tools/freeze no longer works in Python 3 Message-ID: <1348590480.55.0.440432620482.issue16047@psf.upfronthosting.co.za> New submission from Marc-Andre Lemburg: The freeze tool used for compiling Python binaries with frozen modules no longer works with Python 3.x. It looks like it was never updated to the various path and symbols changes introduced with PEP 3149 (ABI tags) in Python 3.2. Even with lots of symlinks to restore the non-ABI flagged names, freezing fails with a linker error in Python 3.3: Tools/freeze> python3 freeze.py hello.py Tools/freeze> make config.o:(.data+0x38): undefined reference to `PyInit__imp' collect2: ld returned 1 exit status make: *** [hello] Error 1 ---------- components: Demos and Tools messages: 171295 nosy: lemburg priority: normal severity: normal status: open title: Tools/freeze no longer works in Python 3 versions: Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 18:36:31 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Sep 2012 16:36:31 +0000 Subject: [issue16042] smtplib: unlimited readline() from connection In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za> Message-ID: <1348590991.54.0.588759418178.issue16042@psf.upfronthosting.co.za> Christian Heimes added the comment: First patch I haven't written tests yet nor implemented the size limit on the mock_socket class. ---------- keywords: +patch Added file: http://bugs.python.org/file27297/smtp_readline.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 18:50:17 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 25 Sep 2012 16:50:17 +0000 Subject: [issue16042] smtplib: unlimited readline() from connection In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za> Message-ID: <1348591817.49.0.928295263947.issue16042@psf.upfronthosting.co.za> R. David Murray added the comment: I've only taken a quick glance at this so far. Why size=-1 instead of size=None? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 18:56:01 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Sep 2012 16:56:01 +0000 Subject: [issue16042] smtplib: unlimited readline() from connection In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za> Message-ID: <1348592161.94.0.33295697932.issue16042@psf.upfronthosting.co.za> Christian Heimes added the comment: size=-1 mimics the code of the io module. The C implementation of readline() maps all negative values to "unlimited" and values >= 0 as limit. >>> sys.stdin.readline(None) Traceback (most recent call last): File "", line 1, in TypeError: 'NoneType' object cannot be interpreted as an integer ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 19:01:51 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 25 Sep 2012 17:01:51 +0000 Subject: [issue16045] add more unit tests for built-in int() In-Reply-To: <1348579722.08.0.96812684384.issue16045@psf.upfronthosting.co.za> Message-ID: <1348592511.1.0.408086872965.issue16045@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Good thought. Here is one data point: $ pypy Python 2.7.2 (341e1e3821fff77db3bb5cdb7a4851626298c44e, Jun 09 2012, 14:24:11) [PyPy 1.9.0] on darwin Type "help", "copyright", "credits" or "license" for more information. >>>> int() 0 >>>> int(x='10', base=8) 8 >>>> int(x=5, base=10) Traceback (most recent call last): File "", line 1, in TypeError: int() can't convert non-string with explicit base >>>> int(base=6) Traceback (most recent call last): File "", line 1, in TypeError: int() can't convert non-string with explicit base >>>> int(base='foo') Traceback (most recent call last): File "", line 1, in TypeError: expected integer, got str object So it looks like "no x with given base" is where behavior differs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 19:06:13 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Tue, 25 Sep 2012 17:06:13 +0000 Subject: [issue16047] Tools/freeze no longer works in Python 3 In-Reply-To: <1348590480.55.0.440432620482.issue16047@psf.upfronthosting.co.za> Message-ID: <1348592773.16.0.715590304097.issue16047@psf.upfronthosting.co.za> Changes by Jeremy Kloth : ---------- nosy: +jkloth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 19:10:13 2012 From: report at bugs.python.org (Trent Nelson) Date: Tue, 25 Sep 2012 17:10:13 +0000 Subject: [issue16002] AIX buildbot compile errors In-Reply-To: <1348352217.78.0.0013472169184.issue16002@psf.upfronthosting.co.za> Message-ID: <1348593013.28.0.465486140234.issue16002@psf.upfronthosting.co.za> Trent Nelson added the comment: Hi Stefan, quick question: how did you invoke ./configure on the AIX box? The reason for asking is that a7/arsenic is a little quirky, you need to run a zsh subroutine via `_xlc 12` to set up the right CC env (see ~/buildslave/start.zsh). Once you've done that, you need ./configure --without-gcc --with-pydebug to get the same environment as the build slave. (I haven't set up a buildslave for gcc on that box.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 19:55:11 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 25 Sep 2012 17:55:11 +0000 Subject: [issue16042] smtplib: unlimited readline() from connection In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za> Message-ID: <1348595711.0.0.226019048578.issue16042@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Both io.IOBase.readline() and io.TextIOBase.readline() have parameter named "limit". I doubt that such a change can be done in 2.7 and 3.2. ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 20:03:36 2012 From: report at bugs.python.org (Erik Johansson) Date: Tue, 25 Sep 2012 18:03:36 +0000 Subject: [issue14201] Documented caching for shared library's __getattr__ and __getitem__ is incorrect In-Reply-To: <1330957421.08.0.5889949548.issue14201@psf.upfronthosting.co.za> Message-ID: <1348596216.06.0.491660745198.issue14201@psf.upfronthosting.co.za> Erik Johansson added the comment: The issue14201-v2.patch patch looks good to me at least. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 20:09:29 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 25 Sep 2012 18:09:29 +0000 Subject: [issue16042] smtplib: unlimited readline() from connection In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za> Message-ID: <1348596568.99.0.798576384226.issue16042@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Please submit patches in standard Mercurial format to them understood Rietveld. I wanted to make a code review, but I don't see the definition of readline() method in the file Lib/smtplib.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 20:13:09 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 25 Sep 2012 18:13:09 +0000 Subject: [issue15955] gzip, bz2, lzma: add option to limit output size In-Reply-To: <1347884562.79.0.801674791772.issue15955@psf.upfronthosting.co.za> Message-ID: <1348596789.31.0.869633663361.issue15955@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Agree with Antoine. This would be a desirable feature. ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 20:21:18 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 25 Sep 2012 18:21:18 +0000 Subject: [issue16025] Minor corrections to the zipfile documentation In-Reply-To: <1348502882.43.0.635160318129.issue16025@psf.upfronthosting.co.za> Message-ID: <1348597278.02.0.43191484816.issue16025@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file27277/doc_zipfile-3.3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 20:21:32 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 25 Sep 2012 18:21:32 +0000 Subject: [issue16025] Minor corrections to the zipfile documentation In-Reply-To: <1348502882.43.0.635160318129.issue16025@psf.upfronthosting.co.za> Message-ID: <1348597292.94.0.858583780736.issue16025@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file27278/doc_zipfile-3.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 20:21:46 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 25 Sep 2012 18:21:46 +0000 Subject: [issue16025] Minor corrections to the zipfile documentation In-Reply-To: <1348502882.43.0.635160318129.issue16025@psf.upfronthosting.co.za> Message-ID: <1348597306.49.0.785417499576.issue16025@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file27279/doc_zipfile-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 20:23:20 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 25 Sep 2012 18:23:20 +0000 Subject: [issue16025] Minor corrections to the zipfile documentation In-Reply-To: <1348582138.49.0.127152409025.issue16025@psf.upfronthosting.co.za> Message-ID: <201209252122.38167.storchaka@gmail.com> Serhiy Storchaka added the comment: > :meth:`closed ` works too. Patches updated. ---------- Added file: http://bugs.python.org/file27298/doc_zipfile-3.3.patch Added file: http://bugs.python.org/file27299/doc_zipfile-3.2.patch Added file: http://bugs.python.org/file27300/doc_zipfile-2.7.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 3d9c323711d0 Doc/library/zipfile.rst --- a/Doc/library/zipfile.rst Mon Sep 24 07:46:35 2012 +0200 +++ b/Doc/library/zipfile.rst Mon Sep 24 18:56:25 2012 +0300 @@ -61,7 +61,7 @@ .. class:: ZipInfo(filename='NoName', date_time=(1980,1,1,0,0,0)) Class used to represent information about a member of an archive. Instances - of this class are returned by the :meth:`getinfo` and :meth:`infolist` + of this class are returned by the :meth:`.getinfo` and :meth:`.infolist` methods of :class:`ZipFile` objects. Most users of the :mod:`zipfile` module will not need to create these, but only use those created by this module. *filename* should be the full name of the archive member, and @@ -87,20 +87,20 @@ .. data:: ZIP_DEFLATED The numeric constant for the usual ZIP compression method. This requires the - zlib module. + :mod:`zlib` module. .. data:: ZIP_BZIP2 The numeric constant for the BZIP2 compression method. This requires the - bz2 module. + :mod:`bz2` module. .. versionadded:: 3.3 .. data:: ZIP_LZMA The numeric constant for the LZMA compression method. This requires the - lzma module. + :mod:`lzma` module. .. versionadded:: 3.3 @@ -155,7 +155,7 @@ these extensions. If the file is created with mode ``'a'`` or ``'w'`` and then - :meth:`close`\ d without adding any files to the archive, the appropriate + :meth:`closed ` without adding any files to the archive, the appropriate ZIP structures for an empty archive will be written to the file. ZipFile is also a context manager and therefore supports the @@ -169,7 +169,7 @@ Added the ability to use :class:`ZipFile` as a context manager. .. versionchanged:: 3.3 - Added support for :mod:`bzip2` and :mod:`lzma` compression. + Added support for :mod:`bzip2 ` and :mod:`lzma` compression. .. method:: ZipFile.close() @@ -207,7 +207,7 @@ *mode* parameter, if included, must be one of the following: ``'r'`` (the default), ``'U'``, or ``'rU'``. Choosing ``'U'`` or ``'rU'`` will enable :term:`universal newlines` support in the read-only object. *pwd* is the - password used for encrypted files. Calling :meth:`open` on a closed + password used for encrypted files. Calling :meth:`.open` on a closed ZipFile will raise a :exc:`RuntimeError`. .. note:: @@ -229,7 +229,7 @@ .. note:: - The :meth:`open`, :meth:`read` and :meth:`extract` methods can take a filename + The :meth:`.open`, :meth:`read` and :meth:`extract` methods can take a filename or a :class:`ZipInfo` object. You will appreciate this when trying to read a ZIP file that contains members with duplicate names. @@ -335,7 +335,7 @@ :class:`ZipInfo` constructor sets this member to :const:`ZIP_STORED`. .. versionchanged:: 3.2 - The *compression_type* argument. + The *compress_type* argument. The following data attributes are also available: @@ -351,7 +351,7 @@ The comment text associated with the ZIP file. If assigning a comment to a :class:`ZipFile` instance created with mode 'a' or 'w', this should be a string no longer than 65535 bytes. Comments longer than this will be - truncated in the written archive when :meth:`ZipFile.close` is called. + truncated in the written archive when :meth:`close` is called. .. _pyzipfile-objects: @@ -407,8 +407,8 @@ ZipInfo Objects --------------- -Instances of the :class:`ZipInfo` class are returned by the :meth:`getinfo` and -:meth:`infolist` methods of :class:`ZipFile` objects. Each object stores +Instances of the :class:`ZipInfo` class are returned by the :meth:`.getinfo` and +:meth:`.infolist` methods of :class:`ZipFile` objects. Each object stores information about a single member of the ZIP archive. Instances have the following attributes: -------------- next part -------------- diff -r aa73e60f65e9 Doc/library/zipfile.rst --- a/Doc/library/zipfile.rst Fri Sep 21 17:26:35 2012 +0300 +++ b/Doc/library/zipfile.rst Mon Sep 24 19:01:40 2012 +0300 @@ -61,7 +61,7 @@ .. class:: ZipInfo(filename='NoName', date_time=(1980,1,1,0,0,0)) Class used to represent information about a member of an archive. Instances - of this class are returned by the :meth:`getinfo` and :meth:`infolist` + of this class are returned by the :meth:`.getinfo` and :meth:`.infolist` methods of :class:`ZipFile` objects. Most users of the :mod:`zipfile` module will not need to create these, but only use those created by this module. *filename* should be the full name of the archive member, and @@ -87,7 +87,7 @@ .. data:: ZIP_DEFLATED The numeric constant for the usual ZIP compression method. This requires the - zlib module. No other compression methods are currently supported. + :mod:`zlib` module. No other compression methods are currently supported. .. seealso:: @@ -130,7 +130,7 @@ these extensions. If the file is created with mode ``'a'`` or ``'w'`` and then - :meth:`close`\ d without adding any files to the archive, the appropriate + :meth:`closed ` without adding any files to the archive, the appropriate ZIP structures for an empty archive will be written to the file. ZipFile is also a context manager and therefore supports the @@ -179,7 +179,7 @@ *mode* parameter, if included, must be one of the following: ``'r'`` (the default), ``'U'``, or ``'rU'``. Choosing ``'U'`` or ``'rU'`` will enable :term:`universal newlines` support in the read-only object. *pwd* is the - password used for encrypted files. Calling :meth:`open` on a closed + password used for encrypted files. Calling :meth:`.open` on a closed ZipFile will raise a :exc:`RuntimeError`. .. note:: @@ -201,7 +201,7 @@ .. note:: - The :meth:`open`, :meth:`read` and :meth:`extract` methods can take a filename + The :meth:`.open`, :meth:`read` and :meth:`extract` methods can take a filename or a :class:`ZipInfo` object. You will appreciate this when trying to read a ZIP file that contains members with duplicate names. @@ -307,7 +307,7 @@ :class:`ZipInfo` constructor sets this member to :const:`ZIP_STORED`. .. versionchanged:: 3.2 - The *compression_type* argument. + The *compress_type* argument. The following data attributes are also available: @@ -323,7 +323,7 @@ The comment text associated with the ZIP file. If assigning a comment to a :class:`ZipFile` instance created with mode 'a' or 'w', this should be a string no longer than 65535 bytes. Comments longer than this will be - truncated in the written archive when :meth:`ZipFile.close` is called. + truncated in the written archive when :meth:`close` is called. .. _pyzipfile-objects: @@ -379,8 +379,8 @@ ZipInfo Objects --------------- -Instances of the :class:`ZipInfo` class are returned by the :meth:`getinfo` and -:meth:`infolist` methods of :class:`ZipFile` objects. Each object stores +Instances of the :class:`ZipInfo` class are returned by the :meth:`.getinfo` and +:meth:`.infolist` methods of :class:`ZipFile` objects. Each object stores information about a single member of the ZIP archive. Instances have the following attributes: -------------- next part -------------- diff -r dc080e19f7aa Doc/library/zipfile.rst --- a/Doc/library/zipfile.rst Tue Aug 28 12:33:46 2012 +0200 +++ b/Doc/library/zipfile.rst Mon Sep 24 19:05:30 2012 +0300 @@ -53,7 +53,7 @@ .. class:: ZipInfo([filename[, date_time]]) Class used to represent information about a member of an archive. Instances - of this class are returned by the :meth:`getinfo` and :meth:`infolist` + of this class are returned by the :meth:`.getinfo` and :meth:`.infolist` methods of :class:`ZipFile` objects. Most users of the :mod:`zipfile` module will not need to create these, but only use those created by this module. *filename* should be the full name of the archive member, and @@ -78,7 +78,7 @@ .. data:: ZIP_DEFLATED The numeric constant for the usual ZIP compression method. This requires the - zlib module. No other compression methods are currently supported. + :mod:`zlib` module. No other compression methods are currently supported. .. seealso:: @@ -125,7 +125,7 @@ .. versionchanged:: 2.7.1 If the file is created with mode ``'a'`` or ``'w'`` and then - :meth:`close`\ d without adding any files to the archive, the appropriate + :meth:`closed ` without adding any files to the archive, the appropriate ZIP structures for an empty archive will be written to the file. ZipFile is also a context manager and therefore supports the @@ -175,7 +175,7 @@ ``'U'``, or ``'rU'``. Choosing ``'U'`` or ``'rU'`` will enable :term:`universal newline ` support in the read-only object. *pwd* is the password used for encrypted files. - Calling :meth:`open` on a closed ZipFile will raise a :exc:`RuntimeError`. + Calling :meth:`.open` on a closed ZipFile will raise a :exc:`RuntimeError`. .. note:: @@ -196,7 +196,7 @@ .. note:: - The :meth:`open`, :meth:`read` and :meth:`extract` methods can take a filename + The :meth:`.open`, :meth:`read` and :meth:`extract` methods can take a filename or a :class:`ZipInfo` object. You will appreciate this when trying to read a ZIP file that contains members with duplicate names. @@ -313,7 +313,7 @@ :class:`ZipInfo` constructor sets this member to :const:`ZIP_STORED`. .. versionchanged:: 2.7 - The *compression_type* argument. + The *compress_type* argument. The following data attributes are also available: @@ -329,7 +329,7 @@ The comment text associated with the ZIP file. If assigning a comment to a :class:`ZipFile` instance created with mode 'a' or 'w', this should be a string no longer than 65535 bytes. Comments longer than this will be - truncated in the written archive when :meth:`ZipFile.close` is called. + truncated in the written archive when :meth:`.close` is called. .. _pyzipfile-objects: @@ -369,8 +369,8 @@ ZipInfo Objects --------------- -Instances of the :class:`ZipInfo` class are returned by the :meth:`getinfo` and -:meth:`infolist` methods of :class:`ZipFile` objects. Each object stores +Instances of the :class:`ZipInfo` class are returned by the :meth:`.getinfo` and +:meth:`.infolist` methods of :class:`ZipFile` objects. Each object stores information about a single member of the ZIP archive. Instances have the following attributes: From report at bugs.python.org Tue Sep 25 20:37:29 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 25 Sep 2012 18:37:29 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1348598249.3.0.649314950994.issue2771@psf.upfronthosting.co.za> Changes by Ezio Melotti : Added file: http://bugs.python.org/file27301/entities.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 21:03:28 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 25 Sep 2012 19:03:28 +0000 Subject: [issue8425] a -= b should be fast if a is a small set and b is a large set In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za> Message-ID: <1348599808.42.0.925957156492.issue8425@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I added a few comments in Rietveld. Did you run benchmarks in debug mode? In order for results to be convenient to compare please sort it by name. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 21:05:16 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 25 Sep 2012 19:05:16 +0000 Subject: [issue8425] a -= b should be fast if a is a small set and b is a large set In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za> Message-ID: <1348599916.58.0.232264583803.issue8425@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: s/it/them/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 21:08:27 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 25 Sep 2012 19:08:27 +0000 Subject: [issue15222] mailbox.mbox writes without empty line after each message In-Reply-To: <1340948825.65.0.977158180544.issue15222@psf.upfronthosting.co.za> Message-ID: <3XRBd1358HzQn2@mail.python.org> Roundup Robot added the comment: New changeset 6451be0e374a by Petri Lehtinen in branch '2.7': #15222: test_mailbox: End message template in a newline http://hg.python.org/cpython/rev/6451be0e374a New changeset d903d4981e33 by Petri Lehtinen in branch '2.7': #15222: Insert blank line after each message in mbox mailboxes http://hg.python.org/cpython/rev/d903d4981e33 New changeset 8adac3f03372 by Petri Lehtinen in branch '3.2': #15222: test_mailbox: End message template in a newline http://hg.python.org/cpython/rev/8adac3f03372 New changeset f7615ee43318 by Petri Lehtinen in branch '3.2': #15222: Insert blank line after each message in mbox mailboxes http://hg.python.org/cpython/rev/f7615ee43318 New changeset 4b626ccace1a by Petri Lehtinen in branch 'default': #15222: Merge 3.2 http://hg.python.org/cpython/rev/4b626ccace1a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 21:10:07 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Tue, 25 Sep 2012 19:10:07 +0000 Subject: [issue15222] mailbox.mbox writes without empty line after each message In-Reply-To: <1340948825.65.0.977158180544.issue15222@psf.upfronthosting.co.za> Message-ID: <1348600207.01.0.663396950249.issue15222@psf.upfronthosting.co.za> Petri Lehtinen added the comment: Fixed, thanks! ---------- keywords: -needs review resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 21:12:52 2012 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 25 Sep 2012 19:12:52 +0000 Subject: [issue16029] pickle.dumps(xrange(sys.maxsize)) produces xrange(0) In-Reply-To: <1348518540.13.0.547483002596.issue16029@psf.upfronthosting.co.za> Message-ID: <1348600372.28.0.598821919254.issue16029@psf.upfronthosting.co.za> Mark Dickinson added the comment: Updated patch: rename range_stop, as suggested in Rietveld review. ---------- Added file: http://bugs.python.org/file27302/xrange_reduce_repr_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 21:27:33 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 25 Sep 2012 19:27:33 +0000 Subject: [issue16002] AIX buildbot compile errors In-Reply-To: <1348593013.28.0.465486140234.issue16002@psf.upfronthosting.co.za> Message-ID: <20120925192713.GA12528@sleipnir.bytereef.org> Stefan Krah added the comment: Hi Trent, nice setup BTW! Trent Nelson wrote: > Hi Stefan, quick question: how did you invoke ./configure on the AIX box? > The reason for asking is that a7/arsenic is a little quirky, you need to > run a zsh subroutine via `_xlc 12` to set up the right CC env (see > ~/buildslave/start.zsh). That's good to know. I did the whole thing manually and pasted the ./configure environment from http://buildbot.python.org/all/builders/RS6000%20AIX%207.1%20%5BSB%5D%203.x/builds/85/steps/configure/logs/stdio to a file "build_env" in the home directory. Perhaps we can put that subroutine in the file instead. > (I haven't set up a buildslave for gcc on that box.) I think that's not so important right now. It's good to have more diversity w.r.t compilers. For the commercial compilers it might be good to switch to optimized builds in order to see if there are either optimizer bugs or Python bugs that don't show up with gcc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 21:27:37 2012 From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=) Date: Tue, 25 Sep 2012 19:27:37 +0000 Subject: [issue8425] a -= b should be fast if a is a small set and b is a large set In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za> Message-ID: <1348601257.75.0.399651616097.issue8425@psf.upfronthosting.co.za> Michele Orr? added the comment: > I'm not sure of the usefulness of this comment. removing, then. > "else" redundant here. > Instead of using a local variable "intersected", you can simply add "else > Py_INCREF(other)" here and then decref "other" unconditionally. It will be > shorter and perhaps a little clearer, but a bit slower. I find my first patch more readable and efficient, but if these comments are conformant to pep7.. Attaching updated patch (issue8425.3.patch) > Did you run benchmarks in debug mode? Yes, but bench.py is available, fell free to run it with whatever configuration; my example was done with a --with-pydebug and clang compiler. > In order for results to be convenient to compare please sort it by name. Done. ---------- Added file: http://bugs.python.org/file27303/issue8425.3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 21:28:20 2012 From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=) Date: Tue, 25 Sep 2012 19:28:20 +0000 Subject: [issue8425] a -= b should be fast if a is a small set and b is a large set In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za> Message-ID: <1348601300.97.0.741657786048.issue8425@psf.upfronthosting.co.za> Michele Orr? added the comment: > I'm not sure of the usefulness of this comment. removing, then. > "else" redundant here. > Instead of using a local variable "intersected", you can simply add "else > Py_INCREF(other)" here and then decref "other" unconditionally. It will be > shorter and perhaps a little clearer, but a bit slower. I find my first patch more readable and efficient, but if these comments are conformant to pep7.. Attaching updated patch (issue8425.3.patch) > Did you run benchmarks in debug mode? Yes, but bench.py is available, fell free to run it with whatever configuration; my example was done with a --with-pydebug and clang compiler. > In order for results to be convenient to compare please sort it by name. Done. ---------- Added file: http://bugs.python.org/file27305/issue8425.3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 21:29:04 2012 From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=) Date: Tue, 25 Sep 2012 19:29:04 +0000 Subject: [issue8425] a -= b should be fast if a is a small set and b is a large set In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za> Message-ID: <1348601344.06.0.820407775823.issue8425@psf.upfronthosting.co.za> Changes by Michele Orr? : Removed file: http://bugs.python.org/file27293/bench.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 21:29:24 2012 From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=) Date: Tue, 25 Sep 2012 19:29:24 +0000 Subject: [issue8425] a -= b should be fast if a is a small set and b is a large set In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za> Message-ID: <1348601364.12.0.410015842787.issue8425@psf.upfronthosting.co.za> Changes by Michele Orr? : Added file: http://bugs.python.org/file27306/bench.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 22:04:57 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 25 Sep 2012 20:04:57 +0000 Subject: [issue16035] Segmentation fault in test suite of apsw In-Reply-To: <1348566044.22.0.909419846865.issue16035@psf.upfronthosting.co.za> Message-ID: <1348603497.62.0.614131462102.issue16035@psf.upfronthosting.co.za> Stefan Krah added the comment: [Adding the apsw author to the cc.] Antoine is right, no Python bug here. I think we can close this. ---------- nosy: +rogerbinns stage: -> committed/rejected status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 22:06:02 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 25 Sep 2012 20:06:02 +0000 Subject: [issue16048] Tutorial-classes-remarks: replace paragragh Message-ID: <1348603562.92.0.789475109772.issue16048@psf.upfronthosting.co.za> New submission from Terry J. Reedy: (from python-list thread "data attributes override method attributes?") "9.4. Random Remarks Data attributes override method attributes with the same name; to avoid accidental name conflicts, which may cause hard-to-find bugs in large programs, it is wise to use some kind of convention that minimizes the chance of conflicts. Possible conventions include capitalizing method names, prefixing data attribute names with a small unique string (perhaps just an underscore), or using verbs for methods and nouns for data attributes." The first semi-sentence is wrong. Within a class or instance attribute space, later assignments replace earlier ones. Between them, instance attributes (usually) override class attributes. The exceptions are (some? all?) special methods. One suggestion on the thread is to replace the clause with 'Instance attributes override class attributes', as that is the apparent intent, but the exception needs to be noted. The suggested Method and _data conventions are wrong in that they contradict PEP8 style. Peter Otten suggested that the convention suggestion be shortened to "To avoid name conflicts consider using verbs for methods and nouns for data attributes". ---------- assignee: docs at python components: Documentation messages: 171316 nosy: docs at python, terry.reedy priority: normal severity: normal status: open title: Tutorial-classes-remarks: replace paragragh versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 22:16:04 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 25 Sep 2012 20:16:04 +0000 Subject: [issue16048] Tutorial-classes-remarks: replace paragragh In-Reply-To: <1348603562.92.0.789475109772.issue16048@psf.upfronthosting.co.za> Message-ID: <1348604164.18.0.077035721572.issue16048@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Peter Otten thought the first clause should instead be ""Data attributes and method attributes share the same namespace.", which is also true for a given object. This is a different intepretation of what the original author was getting at. The convention remark applies both within the class namespace and between class and instance namespaces. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 22:33:48 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 25 Sep 2012 20:33:48 +0000 Subject: [issue16048] Tutorial-classes-remarks: replace paragragh In-Reply-To: <1348603562.92.0.789475109772.issue16048@psf.upfronthosting.co.za> Message-ID: <1348605228.14.0.0484831417371.issue16048@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Ian Kelly reminds me that instance.__xxx__ is only skipped by the internal machinery and not by direct accesses in user code. In the other hand, docs, official or otherwise, are filled with things like 'len(a) calls a.__len__', so I think something should be said that giving instances special method attributes does not have the effect one might expect. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 23:08:15 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 25 Sep 2012 21:08:15 +0000 Subject: [issue16010] Some Unicode in identifiers improperly rejected In-Reply-To: <1348443922.86.0.645371844145.issue16010@psf.upfronthosting.co.za> Message-ID: <1348607295.27.0.741047683047.issue16010@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> invalid _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 23:25:27 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 25 Sep 2012 21:25:27 +0000 Subject: [issue16036] simplify int() signature docs In-Reply-To: <1348568310.1.0.968219969881.issue16036@psf.upfronthosting.co.za> Message-ID: <1348608327.5.0.208783249147.issue16036@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I'm attaching an updated patch that does not cover certain edge cases that may differ for other Python implementations (and in fact does differ for PyPY). See issue 16045 for more information. ---------- Added file: http://bugs.python.org/file27307/issue-16036-2-default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 23:51:02 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 25 Sep 2012 21:51:02 +0000 Subject: [issue16023] IDLE freezes on ^5 or ^6 (Un-)Tabify Region with OS X Cocoa Tk 8.5 In-Reply-To: <1348500115.21.0.649772246938.issue16023@psf.upfronthosting.co.za> Message-ID: <1348609862.3.0.561327727039.issue16023@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the additional information! I can now reproduce a hang using just Ctrl-5 on a US keyboard input method. Ctrl-5 is the default IDLE keyboard accelerator for the "Tabify Region" menu item under the "Format" menu cascade for an edit window. With any current Python (2.7.3, 3.2.3, or 3.3.0rc3) linked with Cocoa Tk 8.5, using the Ctrl-5 accelerator key causes the hang, requiring a force quit. Selecting the menu item with a mouse causes the "Tab Width" window to appear as expected. Ctrl-5 seems to work properly with Pythons linked with either Carbon Tk 8.4 or with X11 8.5. There is a similar hang behavior with Ctrl-6 "Untabify Region" using Cocoa Tk 8.5 as well. Attached is an excerpt from a hang dump when running with a debug framework build of 3.3 tip. ---------- nosy: +ned.deily title: IDLE froze when typing ctrl-shift-5 -> IDLE freezes on ^5 or ^6 (Un-)Tabify Region with OS X Cocoa Tk 8.5 versions: +Python 2.7, Python 3.3 Added file: http://bugs.python.org/file27308/3.3.0_tip_10_8_2012-09-25.hang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 25 23:59:02 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 25 Sep 2012 21:59:02 +0000 Subject: [issue16001] small ints: cache string representation In-Reply-To: <1348272680.09.0.237238464287.issue16001@psf.upfronthosting.co.za> Message-ID: <1348610342.79.0.468663329813.issue16001@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Small int caching saves both time and space. On a nearly fresh IDLE session: >>> sys.getrefcount(0) 772 >>> sys.getrefcount(1) 854 >>> sum(sys.getrefcount(i) for i in range(-5, 257)) 4878 While an interesting idea, I do not see the same gain here, and agree with Martin. Array lookup *is* faster than string conversion: >>> ti.repeat(setup = "ar = [str(i) for i in range(101)]", stmt = "ar[100]") [0.058166605132757995, 0.03438449234832762, 0.034402937150259674] >>> ti.repeat(setup = "S = str", stmt = 'S(100)') [0.21833603908330446, 0.19469564386039195, 0.1947128590088596] but 1: converting ints to decimal digits is nearly always done for output, and conversion is blazingly fast compared to output, so output time will dominate. >>> ti.repeat(setup = "S = str", stmt = 'S(100)', number = 20) [1.0144641009901534e-05, 8.914987631669646e-06, 8.914987574826228e-06] >>> ti.repeat(setup = "p = print", stmt = 'p(100)', number = 20) ... [0.11873041968999587, 0.039060557051357137, 0.03859697769621562] 2. I presume the conversion of 0 - 9 to '0' - '9' within the conversion routines is already optimized. I don't see that 10 - 259 should be more common that 257 - 999, let alone more common than all higher ints. So the limited optimization can have only limited effect. 3. Much production numerical output is float or decimal rather than int. The 3.3 optimization of ascii-only strings to bytes helped here. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 01:07:08 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 25 Sep 2012 23:07:08 +0000 Subject: [issue8425] a -= b should be fast if a is a small set and b is a large set In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za> Message-ID: <1348614428.48.0.245139743597.issue8425@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Please don't apply this until I've signed-off on it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 01:20:31 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 25 Sep 2012 23:20:31 +0000 Subject: [issue16049] Create abstract base classes by inheritance rather than a direct invocation of __metaclass__ Message-ID: <1348615231.16.0.514985949274.issue16049@psf.upfronthosting.co.za> New submission from Raymond Hettinger: Since inheritance is more commonplace and more easily understood than __metaclass__, the abc module would benefit from a simple helper class: class ABC(metaclass=ABCMeta): pass >From a user's point-of-view, writing an abstract base call becomes simpler and clearer: from abc import ABC, abstractmethod class Vector(ABC): @abstractmethod def __iter__(self): pass def dot(self, other): 'Compute a dot product' return sum(map(operator.mul, self, other)) Notice that this class seems less mysterious because it inherits from ABC rather than using __metaclass__=ABCMeta. Also note, it has become a reasonably common practice for metaclass writers to put the __metaclass__ assignment in a class and have it get inherited rather than requiring users do the metaclass assignment themselves. ---------- components: Library (Lib) messages: 171323 nosy: rhettinger priority: normal severity: normal status: open title: Create abstract base classes by inheritance rather than a direct invocation of __metaclass__ versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 01:48:32 2012 From: report at bugs.python.org (Andrew Swan) Date: Tue, 25 Sep 2012 23:48:32 +0000 Subject: [issue7427] BadStatusLine is hell to debug In-Reply-To: <1259855564.36.0.140869506599.issue7427@psf.upfronthosting.co.za> Message-ID: <1348616912.61.0.974759857919.issue7427@psf.upfronthosting.co.za> Andrew Swan added the comment: I just got tripped up by this change, I wanted to catch the specific case of an http server closing a connection and assumed that the following would work: try: resp = conn.getresponse() except httplib.BadStatusLine, e: if len(e.line) == 0: # server closed... else: raise That doesn't work since e.line holds the representation of the empty string instead of just holding the empty string. I think the fragment above would be a much better way to write this test, the current alterntative of: if e.line == "''": is hopelessly obscure. Seems like the original fix should have been to add __repr__ to BadStatusLine rather than changing its contents. Can this be revisited? ---------- nosy: +aswan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 02:07:04 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 26 Sep 2012 00:07:04 +0000 Subject: [issue16034] bz2 module appears slower in Python 3.x versus Python 2.x In-Reply-To: <1348547973.67.0.489000428853.issue16034@psf.upfronthosting.co.za> Message-ID: <1348618024.68.0.360559068276.issue16034@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 02:12:58 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Wed, 26 Sep 2012 00:12:58 +0000 Subject: [issue16049] Create abstract base classes by inheritance rather than a direct invocation of __metaclass__ In-Reply-To: <1348615231.16.0.514985949274.issue16049@psf.upfronthosting.co.za> Message-ID: <1348618378.46.0.138342343808.issue16049@psf.upfronthosting.co.za> Changes by Jeremy Kloth : ---------- nosy: +jkloth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 02:22:35 2012 From: report at bugs.python.org (Pavel Maltsev) Date: Wed, 26 Sep 2012 00:22:35 +0000 Subject: [issue16050] ctypes: callback from C++ to Python fails with Illegal Instruction call Message-ID: <1348618955.55.0.49066087682.issue16050@psf.upfronthosting.co.za> New submission from Pavel Maltsev: ppc_405, Linux 2.4, GCC 3.3.1 Python crashes on attempt to pass python callback function to custom C++ library under PowerPC 405. This happens because some versions of GCC (I guess below 4.1) doesn't raise __NO_FPRS__ flag if hard-floats is not supported, instead they use _SOFT_FLOAT. So we need to change #ifndef __NO_FPRS__ to #if (!defined(__NO_FPRS__) && !defined(_SOFT_FLOAT)) ---------- components: ctypes files: soft_float.patch keywords: patch messages: 171325 nosy: Opilki_Inside priority: normal severity: normal status: open title: ctypes: callback from C++ to Python fails with Illegal Instruction call type: crash versions: Python 2.7 Added file: http://bugs.python.org/file27309/soft_float.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 02:30:23 2012 From: report at bugs.python.org (Santoso Wijaya) Date: Wed, 26 Sep 2012 00:30:23 +0000 Subject: [issue7897] Support parametrized tests in unittest In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za> Message-ID: <1348619423.95.0.242959098833.issue7897@psf.upfronthosting.co.za> Changes by Santoso Wijaya : ---------- nosy: +santa4nt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 02:39:27 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 26 Sep 2012 00:39:27 +0000 Subject: [issue16047] Tools/freeze no longer works in Python 3 In-Reply-To: <1348590480.55.0.440432620482.issue16047@psf.upfronthosting.co.za> Message-ID: <1348619967.44.0.354482080767.issue16047@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 03:09:47 2012 From: report at bugs.python.org (Barry Morrison) Date: Wed, 26 Sep 2012 01:09:47 +0000 Subject: [issue16051] Documentation missing pipes.quote() Message-ID: <1348621787.28.0.392137899077.issue16051@psf.upfronthosting.co.za> New submission from Barry Morrison: Documentation here: http://docs.python.org/library/pipes.html makes no mention of quote() But the link to Source code: Lib/pipes.py http://hg.python.org/cpython/file/2.7/Lib/pipes.py has: 267 def quote(file): 268 """Return a shell-escaped version of the file string.""" 269 for c in file: 270 if c not in _safechars: 271 break 272 else: 273 if not file: 274 return "''" 275 return file 276 # use single quotes, and put single quotes into double quotes 277 # the string $'b is then quoted as '$'"'"'b' 278 return "'" + file.replace("'", "'\"'\"'") + "'" First _ever_ bug report, apologies if this is incorrect. ---------- assignee: docs at python components: Documentation messages: 171326 nosy: Barry.Morrison, docs at python priority: normal severity: normal status: open title: Documentation missing pipes.quote() type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 05:11:38 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 26 Sep 2012 03:11:38 +0000 Subject: [issue16049] Create abstract base classes by inheritance rather than a direct invocation of __metaclass__ In-Reply-To: <1348615231.16.0.514985949274.issue16049@psf.upfronthosting.co.za> Message-ID: <1348629098.56.0.0547545768955.issue16049@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- keywords: +easy type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 06:18:26 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 26 Sep 2012 04:18:26 +0000 Subject: [issue15805] Add stdout redirection tool to contextlib In-Reply-To: <1346214384.31.0.130580797931.issue15805@psf.upfronthosting.co.za> Message-ID: <1348633106.85.0.0517841558477.issue15805@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I like Nick's proposed variant and think it should go in contextlib, not the mocking library. Redirection has a lot of use cases that has nothing to do with mocking-up test suites. Contextlib is about general purpose context-managers that apply in many situations (the closing() context manager is a good example). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 06:27:41 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Wed, 26 Sep 2012 04:27:41 +0000 Subject: [issue16040] nntplib: unlimited readline() from connection In-Reply-To: <1348569525.38.0.219080768405.issue16040@psf.upfronthosting.co.za> Message-ID: <1348633661.56.0.871368429906.issue16040@psf.upfronthosting.co.za> Changes by Hynek Schlawack : ---------- nosy: +hynek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 06:44:29 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 26 Sep 2012 04:44:29 +0000 Subject: [issue15222] mailbox.mbox writes without empty line after each message In-Reply-To: <1340948825.65.0.977158180544.issue15222@psf.upfronthosting.co.za> Message-ID: <3XRRQ14XclzQcS@mail.python.org> Roundup Robot added the comment: New changeset a87ab9b0c9e5 by Petri Lehtinen in branch '2.7': #15222: Fix a test failure on Windows http://hg.python.org/cpython/rev/a87ab9b0c9e5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 08:19:18 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 26 Sep 2012 06:19:18 +0000 Subject: [issue15805] Add stdout redirection tool to contextlib In-Reply-To: <1346214384.31.0.130580797931.issue15805@psf.upfronthosting.co.za> Message-ID: <1348640358.57.0.303664678326.issue15805@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'd actually be inclined to make it the full trio: redirect_stdin, redirect_stdout, redirect_stderr. Mostly because I don't see an especially compelling reason to privilege redirecting stdout over the other two standard streams, and the "pass in the stream name" approach is just ugly (e.g. we don't have "sys.stdstream['stdin']", we have sys.stdin). There are plenty of command line apps that have both -i and -o options (to select input and output files), and "2>1" is a pretty common shell redirection. Agreed that the general purpose nature of standard stream redirection makes it a good fit for contextlib, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 09:47:50 2012 From: report at bugs.python.org (Roger Binns) Date: Wed, 26 Sep 2012 07:47:50 +0000 Subject: [issue16035] Segmentation fault in test suite of apsw In-Reply-To: <1348566044.22.0.909419846865.issue16035@psf.upfronthosting.co.za> Message-ID: <1348645670.99.0.765026566852.issue16035@psf.upfronthosting.co.za> Roger Binns added the comment: Thanks for finding this problem. I can repeat it with the patch and am in the process of fixing it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 09:52:24 2012 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 26 Sep 2012 07:52:24 +0000 Subject: [issue16049] Create abstract base classes by inheritance rather than a direct invocation of __metaclass__ In-Reply-To: <1348615231.16.0.514985949274.issue16049@psf.upfronthosting.co.za> Message-ID: <1348645944.07.0.462193903688.issue16049@psf.upfronthosting.co.za> Mark Dickinson added the comment: +1 ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 12:06:50 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 26 Sep 2012 10:06:50 +0000 Subject: [issue16034] bz2 module appears slower in Python 3.x versus Python 2.x In-Reply-To: <201209251037.40494.storchaka@gmail.com> Message-ID: <201209261306.31173.storchaka@gmail.com> Serhiy Storchaka added the comment: Here is a patch and benchmark script. This required more time than I thought. Benchmark results: Unpatched: 5.3 read(1) 0.5 read(10) 0.049 read(100) 0.013 read(1000) 0.009 read(10000) 0.0085 read(100000) 0.0082 read() 5 read1(1) 0.47 read1(10) 0.046 read1(100) 0.012 read1(1000) 0.0089 read1(10000) 0.0084 read1(100000) 0.0082 read1() 0.15 readline() Patched: 0.73 read(1) 0.082 read(10) 0.015 read(100) 0.0089 read(1000) 0.0082 read(10000) 0.0084 read(100000) 0.0083 read() 0.78 read1(1) 0.087 read1(10) 0.016 read1(100) 0.0089 read1(1000) 0.0082 read1(10000) 0.0082 read1(100000) 0.008 read1() 0.14 readline() ---------- keywords: +patch Added file: http://bugs.python.org/file27310/bz2_faster_read.patch Added file: http://bugs.python.org/file27311/bz2bench.py _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 82f25e941be2 Lib/bz2.py --- a/Lib/bz2.py Tue Sep 25 12:34:54 2012 -0700 +++ b/Lib/bz2.py Wed Sep 26 12:34:43 2012 +0300 @@ -79,7 +79,8 @@ mode = "rb" mode_code = _MODE_READ self._decompressor = BZ2Decompressor() - self._buffer = None + self._buffer = b'' + self._offset = 0 elif mode in ("w", "wb"): mode = "wb" mode_code = _MODE_WRITE @@ -124,7 +125,8 @@ self._fp = None self._closefp = False self._mode = _MODE_CLOSED - self._buffer = None + self._buffer = b'' + self._offset = 0 @property def closed(self): @@ -172,14 +174,14 @@ raise io.UnsupportedOperation("The underlying file object " "does not support seeking") - # Fill the readahead buffer if it is empty. Returns False on EOF. - def _fill_buffer(self): + # Non-buffered read and decompress next chunk of data. + # Always returns at least one byte of data, unless at EOF. + def _read1(self): # Depending on the input data, our call to the decompressor may not # return any data. In this case, try again after reading another block. + if self._mode == _MODE_READ_EOF: + return b'' while True: - if self._buffer: - return True - if self._decompressor.unused_data: rawblock = self._decompressor.unused_data else: @@ -189,48 +191,70 @@ if self._decompressor.eof: self._mode = _MODE_READ_EOF self._size = self._pos - return False + return b'' else: raise EOFError("Compressed file ended before the " - "end-of-stream marker was reached") + "end-of-stream marker was reached") # Continue to next stream. if self._decompressor.eof: self._decompressor = BZ2Decompressor() - self._buffer = self._decompressor.decompress(rawblock) + data = self._decompressor.decompress(rawblock) + if data: + return data # Read data until EOF. # If return_data is false, consume the data without returning it. def _read_all(self, return_data=True): + data = self._buffer[self._offset:] blocks = [] - while self._fill_buffer(): + self._buffer = b'' + self._offset = 0 + while True: if return_data: - blocks.append(self._buffer) - self._pos += len(self._buffer) - self._buffer = None + blocks.append(data) + self._pos += len(data) + data = self._read1() + if not data: + break if return_data: return b"".join(blocks) # Read a block of up to n bytes. # If return_data is false, consume the data without returning it. def _read_block(self, n, return_data=True): + if n <= 0: + return b'' + end = n + self._offset + data = self._buffer[self._offset:end] + if data: + self._offset = end + self._pos += len(data) + return data + blocks = [] - while n > 0 and self._fill_buffer(): - if n < len(self._buffer): - data = self._buffer[:n] - self._buffer = self._buffer[n:] - else: - data = self._buffer - self._buffer = None + self._buffer = b'' + self._offset = 0 + while True: if return_data: blocks.append(data) self._pos += len(data) n -= len(data) + if not n: + break + data = self._read1() + if not data: + break + if n < len(data): + self._buffer = data + self._offset = n + data = data[:n] + if return_data: return b"".join(blocks) - def peek(self, n=0): + def peek(self, n=1): """Return buffered data without advancing the file position. Always returns at least one byte of data, unless at EOF. @@ -238,9 +262,11 @@ """ with self._lock: self._check_can_read() - if self._mode == _MODE_READ_EOF or not self._fill_buffer(): - return b"" - return self._buffer + data = self._buffer[self._offset:] + if not data: + self._buffer = data = self._read1() + self._offset = 0 + return data def read(self, size=-1): """Read up to size uncompressed bytes from the file. @@ -250,9 +276,7 @@ """ with self._lock: self._check_can_read() - if self._mode == _MODE_READ_EOF or size == 0: - return b"" - elif size < 0: + if size < 0: return self._read_all() else: return self._read_block(size) @@ -268,15 +292,18 @@ # In this case we make multiple reads, to avoid returning b"". with self._lock: self._check_can_read() - if (size == 0 or self._mode == _MODE_READ_EOF or - not self._fill_buffer()): + if size == 0: return b"" - if 0 < size < len(self._buffer): - data = self._buffer[:size] - self._buffer = self._buffer[size:] + if self._offset == len(self._buffer): + self._buffer = self._read1() + self._offset = 0 + if size > 0: + data = self._buffer[self._offset:self._offset + size] + self._offset += len(data) else: - data = self._buffer - self._buffer = None + data = self._buffer[self._offset:] + self._buffer = b'' + self._offset = 0 self._pos += len(data) return data @@ -345,7 +372,8 @@ self._mode = _MODE_READ self._pos = 0 self._decompressor = BZ2Decompressor() - self._buffer = None + self._buffer = b'' + self._offset = 0 def seek(self, offset, whence=0): """Change the file position. -------------- next part -------------- # -*- coding: utf-8 -*- import sys, bz2, timeit fn = sys.argv[1] min_t = 2 if len(sys.argv) <= 2 else float(sys.argv[2]) benchs = [] for i in (1, 10, 100, 1000, 10000, 100000): benchs.append('read(%d)' % i) benchs.append('read()') for i in (1, 10, 100, 1000, 10000, 100000): benchs.append('read1(%d)' % i) benchs.append('read1()') benchs.append('readline()') for s in benchs: stmt = 'with bz2.BZ2File(%r) as f:\n while f.%s: pass' % (fn, s) n = 1 while True: t = timeit.timeit(stmt, 'import bz2', number=n) if t >= min_t: break n = min(int(n * min_t / t * 1.1) + 1, 10 * n) print('%.2g\t%s' % (t / n, s)) sys.stdout.flush() From report at bugs.python.org Wed Sep 26 12:30:52 2012 From: report at bugs.python.org (Lars Buitinck) Date: Wed, 26 Sep 2012 10:30:52 +0000 Subject: [issue16052] Typo in "What's new in 3.3" Message-ID: <1348655452.61.0.28429874777.issue16052@psf.upfronthosting.co.za> New submission from Lars Buitinck: I spotted a minor typo in the "What's new" for Py 3.3, introduced yesterday. See attached patch. ---------- assignee: docs at python components: Documentation files: typo.hg messages: 171333 nosy: docs at python, larsmans priority: normal severity: normal status: open title: Typo in "What's new in 3.3" versions: Python 3.3 Added file: http://bugs.python.org/file27312/typo.hg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 12:35:57 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 26 Sep 2012 10:35:57 +0000 Subject: [issue16053] "strict" parameter is not documented in csv module Message-ID: <1348655757.15.0.984566805089.issue16053@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: csv.Dialect.strict is not documented. However it is used in tests. ---------- messages: 171334 nosy: storchaka priority: normal severity: normal status: open title: "strict" parameter is not documented in csv module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 12:37:06 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 26 Sep 2012 10:37:06 +0000 Subject: [issue16053] "strict" parameter is not documented in csv module In-Reply-To: <1348655757.15.0.984566805089.issue16053@psf.upfronthosting.co.za> Message-ID: <1348655826.67.0.125287753404.issue16053@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python versions: +Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 12:58:43 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 26 Sep 2012 10:58:43 +0000 Subject: [issue13896] Make shelf instances work with 'with' as context managers In-Reply-To: <1327749150.13.0.147725255938.issue13896@psf.upfronthosting.co.za> Message-ID: <1348657123.68.0.913570427093.issue13896@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 13:12:19 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 26 Sep 2012 11:12:19 +0000 Subject: [issue16034] bz2 module appears slower in Python 3.x versus Python 2.x In-Reply-To: <1348547973.67.0.489000428853.issue16034@psf.upfronthosting.co.za> Message-ID: <1348657939.42.0.57061233395.issue16034@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file27310/bz2_faster_read.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 13:12:31 2012 From: report at bugs.python.org (Georg Brandl) Date: Wed, 26 Sep 2012 11:12:31 +0000 Subject: [issue16052] Typo in "What's new in 3.3" In-Reply-To: <1348655452.61.0.28429874777.issue16052@psf.upfronthosting.co.za> Message-ID: <1348657951.44.0.844750837326.issue16052@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks for the report. Note that we don't care for bundles instead of patches, since they are impossible to review online and clumsy to do so offline. Readable patches (as generated by e.g. hg export) are much preferred. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 13:12:42 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 26 Sep 2012 11:12:42 +0000 Subject: [issue16052] Typo in "What's new in 3.3" In-Reply-To: <1348655452.61.0.28429874777.issue16052@psf.upfronthosting.co.za> Message-ID: <3XRc210jPxzQrZ@mail.python.org> Roundup Robot added the comment: New changeset 6f456d9add40 by Georg Brandl in branch 'default': Closes #16052: fix typo. Patch by Lars Buitinck. http://hg.python.org/cpython/rev/6f456d9add40 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 13:14:18 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 26 Sep 2012 11:14:18 +0000 Subject: [issue16034] bz2 module appears slower in Python 3.x versus Python 2.x In-Reply-To: <1348547973.67.0.489000428853.issue16034@psf.upfronthosting.co.za> Message-ID: <1348658058.23.0.358639415222.issue16034@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file27310/bz2_faster_read.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 13:16:12 2012 From: report at bugs.python.org (Lars Buitinck) Date: Wed, 26 Sep 2012 11:16:12 +0000 Subject: [issue16052] Typo in "What's new in 3.3" In-Reply-To: <1348655452.61.0.28429874777.issue16052@psf.upfronthosting.co.za> Message-ID: <1348658172.55.0.84369256238.issue16052@psf.upfronthosting.co.za> Lars Buitinck added the comment: Sorry about the bundle, I'm an hg noob and only noticed that bundles are binary after I submitted it. Will create a regular patch next time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 13:25:56 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 26 Sep 2012 11:25:56 +0000 Subject: [issue16051] Documentation missing pipes.quote() In-Reply-To: <1348621787.28.0.392137899077.issue16051@psf.upfronthosting.co.za> Message-ID: <1348658756.77.0.344710765563.issue16051@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for the report. pipes.quote used to be an undocumented helper function in pipes. When we decided to make it public, we moved it to the shlex module. Therefore you'll find that as of Python 3.3 the source code has moved to shlex and it is documented in the shlex documentation. ---------- nosy: +r.david.murray resolution: -> out of date stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 14:56:17 2012 From: report at bugs.python.org (Mike Hoy) Date: Wed, 26 Sep 2012 12:56:17 +0000 Subject: [issue13440] Explain the "status quo wins a stalemate" principle in the devguide In-Reply-To: <1321833284.75.0.438515825131.issue13440@psf.upfronthosting.co.za> Message-ID: <1348664177.12.0.00137707352421.issue13440@psf.upfronthosting.co.za> Mike Hoy added the comment: I'd be willing to make a patch for this if you are agreed to just adding a couple of links to it (or otherwise). ---------- nosy: +mikehoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 15:04:29 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 13:04:29 +0000 Subject: [issue16036] simplify int() signature docs In-Reply-To: <1348568310.1.0.968219969881.issue16036@psf.upfronthosting.co.za> Message-ID: <1348664669.01.0.0797111441639.issue16036@psf.upfronthosting.co.za> Ezio Melotti added the comment: The latest patch is better, however I think it can be further improved. The text is currently divided in two paragraphs: 1) covers int(), int(num), int(x, base=b); 2) covers int(float), and int(x, base=b); I think it would be better to cover first int(), int(num), int(float), and then cover int(x, base=b). The attached patch does this. ---------- Added file: http://bugs.python.org/file27313/issue16036.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 15:08:43 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 13:08:43 +0000 Subject: [issue16048] Tutorial-classes-remarks: replace paragragh In-Reply-To: <1348603562.92.0.789475109772.issue16048@psf.upfronthosting.co.za> Message-ID: <1348664923.41.0.194759714395.issue16048@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 15:11:38 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 13:11:38 +0000 Subject: [issue16044] xml.etree.ElementTree.Element: append method iterator param is broken In-Reply-To: <1348574765.38.0.275058753456.issue16044@psf.upfronthosting.co.za> Message-ID: <1348665098.87.0.822007254813.issue16044@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +eli.bendersky, ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 15:54:26 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 13:54:26 +0000 Subject: [issue13386] Document documentation conventions for optional args In-Reply-To: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za> Message-ID: <1348667666.14.0.65738564679.issue13386@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +chris.jerdonek type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 16:09:37 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 26 Sep 2012 14:09:37 +0000 Subject: [issue16034] bz2 module appears slower in Python 3.x versus Python 2.x In-Reply-To: <1348547973.67.0.489000428853.issue16034@psf.upfronthosting.co.za> Message-ID: <1348668577.74.0.857999673566.issue16034@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file27310/bz2_faster_read.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 16:10:12 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 26 Sep 2012 14:10:12 +0000 Subject: [issue16034] bz2 module appears slower in Python 3.x versus Python 2.x In-Reply-To: <201209261306.31173.storchaka@gmail.com> Message-ID: <201209261709.55571.storchaka@gmail.com> Serhiy Storchaka added the comment: Patch updated. Fixed one error. Now readline() optimized too. Benchmark results (reading python.bz2): Py2.7 Py3.2 Py3.3 Py3.3 vanilla patched 4.8 4.8 - 31 read(1) 1 0.94 3.4e+02 3.6 read(10) 0.61 0.6 28 0.87 read(100) 0.58 0.58 3.4 0.61 read(1000) 0.59 0.57 0.88 0.58 read(10000) 0.57 0.56 0.62 0.58 read(100000) 0.57 0.57 0.59 0.58 read() - - - 30 read1(1) - - 3.2e+02 3.6 read1(10) - - 27 0.88 read1(100) - - 3.3 0.61 read1(1000) - - 0.88 0.58 read1(10000) - - 0.61 0.57 read1(100000) - - 0.58 0.57 read1() 1.7 1.7 11 0.67 readline() ---------- Added file: http://bugs.python.org/file27314/bz2_faster_read.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 6f456d9add40 Lib/bz2.py --- a/Lib/bz2.py Wed Sep 26 13:11:48 2012 +0200 +++ b/Lib/bz2.py Wed Sep 26 16:49:44 2012 +0300 @@ -79,7 +79,8 @@ mode = "rb" mode_code = _MODE_READ self._decompressor = BZ2Decompressor() - self._buffer = None + self._buffer = b'' + self._offset = 0 elif mode in ("w", "wb"): mode = "wb" mode_code = _MODE_WRITE @@ -124,7 +125,8 @@ self._fp = None self._closefp = False self._mode = _MODE_CLOSED - self._buffer = None + self._buffer = b'' + self._offset = 0 @property def closed(self): @@ -172,14 +174,14 @@ raise io.UnsupportedOperation("The underlying file object " "does not support seeking") - # Fill the readahead buffer if it is empty. Returns False on EOF. - def _fill_buffer(self): + # Non-buffered read and decompress next chunk of data. + # Always returns at least one byte of data, unless at EOF. + def _read1(self): # Depending on the input data, our call to the decompressor may not # return any data. In this case, try again after reading another block. + if self._mode == _MODE_READ_EOF: + return b'' while True: - if self._buffer: - return True - if self._decompressor.unused_data: rawblock = self._decompressor.unused_data else: @@ -189,48 +191,70 @@ if self._decompressor.eof: self._mode = _MODE_READ_EOF self._size = self._pos - return False + return b'' else: raise EOFError("Compressed file ended before the " - "end-of-stream marker was reached") + "end-of-stream marker was reached") # Continue to next stream. if self._decompressor.eof: self._decompressor = BZ2Decompressor() - self._buffer = self._decompressor.decompress(rawblock) + data = self._decompressor.decompress(rawblock) + if data: + return data # Read data until EOF. # If return_data is false, consume the data without returning it. def _read_all(self, return_data=True): + data = self._buffer[self._offset:] blocks = [] - while self._fill_buffer(): + self._buffer = b'' + self._offset = 0 + while True: if return_data: - blocks.append(self._buffer) - self._pos += len(self._buffer) - self._buffer = None + blocks.append(data) + self._pos += len(data) + data = self._read1() + if not data: + break if return_data: return b"".join(blocks) # Read a block of up to n bytes. # If return_data is false, consume the data without returning it. def _read_block(self, n, return_data=True): + if n <= 0: + return b'' + end = n + self._offset + data = self._buffer[self._offset:end] + if end <= len(self._buffer): + self._offset = end + self._pos += len(data) + return data + blocks = [] - while n > 0 and self._fill_buffer(): - if n < len(self._buffer): - data = self._buffer[:n] - self._buffer = self._buffer[n:] - else: - data = self._buffer - self._buffer = None + self._buffer = b'' + self._offset = 0 + while True: if return_data: blocks.append(data) self._pos += len(data) n -= len(data) + if not n: + break + data = self._read1() + if not data: + break + if n < len(data): + self._buffer = data + self._offset = n + data = data[:n] + if return_data: return b"".join(blocks) - def peek(self, n=0): + def peek(self, n=1): """Return buffered data without advancing the file position. Always returns at least one byte of data, unless at EOF. @@ -238,9 +262,11 @@ """ with self._lock: self._check_can_read() - if self._mode == _MODE_READ_EOF or not self._fill_buffer(): - return b"" - return self._buffer + data = self._buffer[self._offset:] + if not data: + self._buffer = data = self._read1() + self._offset = 0 + return data def read(self, size=-1): """Read up to size uncompressed bytes from the file. @@ -250,9 +276,7 @@ """ with self._lock: self._check_can_read() - if self._mode == _MODE_READ_EOF or size == 0: - return b"" - elif size < 0: + if size < 0: return self._read_all() else: return self._read_block(size) @@ -268,15 +292,18 @@ # In this case we make multiple reads, to avoid returning b"". with self._lock: self._check_can_read() - if (size == 0 or self._mode == _MODE_READ_EOF or - not self._fill_buffer()): + if size == 0: return b"" - if 0 < size < len(self._buffer): - data = self._buffer[:size] - self._buffer = self._buffer[size:] + if self._offset == len(self._buffer): + self._buffer = self._read1() + self._offset = 0 + if size > 0: + data = self._buffer[self._offset:self._offset + size] + self._offset += len(data) else: - data = self._buffer - self._buffer = None + data = self._buffer[self._offset:] + self._buffer = b'' + self._offset = 0 self._pos += len(data) return data @@ -299,6 +326,14 @@ raise TypeError("Integer argument expected") size = size.__index__() with self._lock: + if size < 0: + # Shortcut common case - newline found in buffer. + i = self._buffer.find(b'\n', self._offset) + 1 + if i > 0: + line = self._buffer[self._offset: i] + self._offset = i + return line + return io.BufferedIOBase.readline(self, size) def readlines(self, size=-1): @@ -345,7 +380,8 @@ self._mode = _MODE_READ self._pos = 0 self._decompressor = BZ2Decompressor() - self._buffer = None + self._buffer = b'' + self._offset = 0 def seek(self, offset, whence=0): """Change the file position. From report at bugs.python.org Wed Sep 26 16:27:34 2012 From: report at bugs.python.org (Fredy) Date: Wed, 26 Sep 2012 14:27:34 +0000 Subject: [issue16054] Preferences Crashes on click Message-ID: <1348669653.52.0.428448233738.issue16054@psf.upfronthosting.co.za> New submission from Fredy: Process: Python [3627] Path: /Applications/Python 3.2/IDLE.app/Contents/MacOS/Python Identifier: org.python.IDLE Version: 3.2.3 (3.2.3) Code Type: X86-64 (Native) Parent Process: launchd [231] User ID: 501 Date/Time: 2012-09-26 16:08:04.216 +0200 OS Version: Mac OS X 10.8.2 (12C54) Report Version: 10 Interval Since Last Report: 166823 sec Crashes Since Last Report: 122 Per-App Interval Since Last Report: 465 sec Per-App Crashes Since Last Report: 6 Anonymous UUID: 622CF890-F6C9-E63C-05B2-5E66F969E543 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000024 VM Regions Near 0x24: --> __TEXT 0000000100000000-0000000100001000 [ 4K] r-x/rwx SM=COW /Library/Frameworks/Python.framework/Versions/3.2/Resources/Python.app/Contents/MacOS/Python Application Specific Information: Performing @selector(preferences:) from sender NSMenuItem 0x1017a6d20 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 Tk 0x0000000101391e6c TkpConfigureMenuEntry + 1923 1 Tk 0x0000000101312ffe MenuWorldChanged + 61 2 Tk 0x00000001012eca99 RecomputeWidgets + 47 3 Tk 0x00000001012ecaa7 RecomputeWidgets + 61 4 Tk 0x00000001012ecaa7 RecomputeWidgets + 61 5 Tcl 0x000000010125ee81 TclServiceIdle + 76 6 Tcl 0x0000000101243432 Tcl_DoOneEvent + 329 7 Tk 0x000000010130d832 MapFrame + 42 8 Tcl 0x000000010125ee81 TclServiceIdle + 76 9 Tcl 0x0000000101243432 Tcl_DoOneEvent + 329 10 Tk 0x00000001012e3e26 Tk_TkwaitObjCmd + 555 11 Tcl 0x00000001011dd8ad TclEvalObjvInternal + 782 12 Tcl 0x00000001011dea9f Tcl_EvalObjv + 66 13 _tkinter.so 0x00000001011c268e Tkapp_Call + 190 14 org.python.python 0x00000001000b4034 PyEval_EvalFrameEx + 29204 15 org.python.python 0x00000001000b4ffa PyEval_EvalCodeEx + 1770 16 org.python.python 0x00000001000b4167 PyEval_EvalFrameEx + 29511 17 org.python.python 0x00000001000b4ffa PyEval_EvalCodeEx + 1770 18 org.python.python 0x0000000100039d0a function_call + 186 19 org.python.python 0x000000010000c828 PyObject_Call + 104 20 org.python.python 0x00000001000261aa method_call + 138 21 org.python.python 0x000000010000c828 PyObject_Call + 104 22 org.python.python 0x000000010006dd81 slot_tp_init + 177 23 org.python.python 0x0000000100060fe4 type_call + 212 24 org.python.python 0x000000010000c828 PyObject_Call + 104 25 org.python.python 0x00000001000ae0f2 PyEval_EvalFrameEx + 4818 26 org.python.python 0x00000001000b4ffa PyEval_EvalCodeEx + 1770 27 org.python.python 0x0000000100039d0a function_call + 186 28 org.python.python 0x000000010000c828 PyObject_Call + 104 29 org.python.python 0x00000001000ab5e7 PyEval_CallObjectWithKeywords + 87 30 _tkinter.so 0x00000001011c09c8 PythonCmd + 456 31 Tcl 0x00000001011da53b TclInvokeStringCommand + 105 32 Tcl 0x00000001011dd8ad TclEvalObjvInternal + 782 33 Tcl 0x00000001011de4bf TclEvalEx + 2183 34 Tcl 0x00000001011de8bd Tcl_Eval + 44 35 Tcl 0x00000001011de900 Tcl_GlobalEval + 45 36 Tk 0x000000010138c4c1 PrefsHandler + 79 37 com.apple.AppKit 0x00007fff9a555a59 -[NSApplication sendAction:to:from:] + 342 38 com.apple.AppKit 0x00007fff9a68b44c -[NSMenuItem _corePerformAction] + 406 39 com.apple.AppKit 0x00007fff9a68b13a -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 133 40 com.apple.AppKit 0x00007fff9a37846f -[NSMenu _internalPerformActionForItemAtIndex:] + 36 41 com.apple.AppKit 0x00007fff9a3782f7 -[NSCarbonMenuImpl _carbonCommandProcessEvent:handlerCallRef:] + 135 42 com.apple.AppKit 0x00007fff9a684245 NSSLMMenuEventHandler + 342 43 com.apple.HIToolbox 0x00007fff94e9bf0a DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1206 44 com.apple.HIToolbox 0x00007fff94e9b3d9 SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 410 45 com.apple.HIToolbox 0x00007fff94eb11bd SendEventToEventTarget + 40 46 com.apple.HIToolbox 0x00007fff94ee7e89 SendHICommandEvent(unsigned int, HICommand const*, unsigned int, unsigned int, unsigned char, void const*, OpaqueEventTargetRef*, OpaqueEventTargetRef*, OpaqueEventRef**) + 443 47 com.apple.HIToolbox 0x00007fff94e8cc11 SendMenuCommandWithContextAndModifiers + 59 48 com.apple.HIToolbox 0x00007fff94e8cbc3 SendMenuItemSelectedEvent + 254 49 com.apple.HIToolbox 0x00007fff94e8ca4f FinishMenuSelection(SelectionData*, MenuResult*, MenuResult*) + 94 50 com.apple.HIToolbox 0x00007fff94e68aab MenuSelectCore(MenuData*, Point, double, unsigned int, OpaqueMenuRef**, unsigned short*) + 605 51 com.apple.HIToolbox 0x00007fff94e680b8 _HandleMenuSelection2 + 565 52 com.apple.AppKit 0x00007fff9a5439c6 _NSHandleCarbonMenuEvent + 245 53 com.apple.AppKit 0x00007fff9a465b7f _DPSNextEvent + 2073 54 com.apple.AppKit 0x00007fff9a464ed2 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128 55 Tk 0x000000010139554f -[TKApplication(TKNotify) nextEventMatchingMask:untilDate:inMode:dequeue:] + 169 56 Tk 0x0000000101395986 TkMacOSXEventsCheckProc + 271 57 Tcl 0x0000000101243412 Tcl_DoOneEvent + 297 58 _tkinter.so 0x00000001011bff71 Tkapp_MainLoop + 177 59 org.python.python 0x00000001000b4034 PyEval_EvalFrameEx + 29204 60 org.python.python 0x00000001000b4ffa PyEval_EvalCodeEx + 1770 61 org.python.python 0x00000001000b4167 PyEval_EvalFrameEx + 29511 62 org.python.python 0x00000001000b4321 PyEval_EvalFrameEx + 29953 63 org.python.python 0x00000001000b4ffa PyEval_EvalCodeEx + 1770 64 org.python.python 0x00000001000b530f PyEval_EvalCode + 63 65 org.python.python 0x00000001000dc6ab PyRun_FileExFlags + 187 66 org.python.python 0x00000001000dc979 PyRun_SimpleFileExFlags + 521 67 org.python.python 0x00000001000f1e65 Py_Main + 3237 68 Python 0x0000000100000e0b 0x100000000 + 3595 69 Python 0x0000000100000c94 0x100000000 + 3220 Thread 1: 0 libsystem_kernel.dylib 0x00007fff930416d6 __workq_kernreturn + 10 1 libsystem_c.dylib 0x00007fff9a1a5eec _pthread_workq_return + 25 2 libsystem_c.dylib 0x00007fff9a1a5cb3 _pthread_wqthread + 412 3 libsystem_c.dylib 0x00007fff9a190171 start_wqthread + 13 Thread 2:: Dispatch queue: com.apple.libdispatch-manager 0 libsystem_kernel.dylib 0x00007fff93041d16 kevent + 10 1 libdispatch.dylib 0x00007fff8fd30dea _dispatch_mgr_invoke + 883 2 libdispatch.dylib 0x00007fff8fd309ee _dispatch_mgr_thread + 54 Thread 3: 0 libsystem_kernel.dylib 0x00007fff930416d6 __workq_kernreturn + 10 1 libsystem_c.dylib 0x00007fff9a1a5eec _pthread_workq_return + 25 2 libsystem_c.dylib 0x00007fff9a1a5cb3 _pthread_wqthread + 412 3 libsystem_c.dylib 0x00007fff9a190171 start_wqthread + 13 Thread 4: 0 libsystem_kernel.dylib 0x00007fff930416d6 __workq_kernreturn + 10 1 libsystem_c.dylib 0x00007fff9a1a5eec _pthread_workq_return + 25 2 libsystem_c.dylib 0x00007fff9a1a5cb3 _pthread_wqthread + 412 3 libsystem_c.dylib 0x00007fff9a190171 start_wqthread + 13 Thread 5: 0 libsystem_kernel.dylib 0x00007fff93041322 __select + 10 1 Tcl 0x0000000101276d1e NotifierThreadProc + 558 2 libsystem_c.dylib 0x00007fff9a1a3742 _pthread_start + 327 3 libsystem_c.dylib 0x00007fff9a190181 thread_start + 13 Thread 6: 0 libsystem_kernel.dylib 0x00007fff930416d6 __workq_kernreturn + 10 1 libsystem_c.dylib 0x00007fff9a1a5eec _pthread_workq_return + 25 2 libsystem_c.dylib 0x00007fff9a1a5cb3 _pthread_wqthread + 412 3 libsystem_c.dylib 0x00007fff9a190171 start_wqthread + 13 Thread 7: 0 libsystem_kernel.dylib 0x00007fff930416d6 __workq_kernreturn + 10 1 libsystem_c.dylib 0x00007fff9a1a5eec _pthread_workq_return + 25 2 libsystem_c.dylib 0x00007fff9a1a5cb3 _pthread_wqthread + 412 3 libsystem_c.dylib 0x00007fff9a190171 start_wqthread + 13 Thread 8: 0 libsystem_kernel.dylib 0x00007fff930416d6 __workq_kernreturn + 10 1 libsystem_c.dylib 0x00007fff9a1a5eec _pthread_workq_return + 25 2 libsystem_c.dylib 0x00007fff9a1a5cb3 _pthread_wqthread + 412 3 libsystem_c.dylib 0x00007fff9a190171 start_wqthread + 13 Thread 9: 0 libsystem_kernel.dylib 0x00007fff930416d6 __workq_kernreturn + 10 1 libsystem_c.dylib 0x00007fff9a1a5eec _pthread_workq_return + 25 2 libsystem_c.dylib 0x00007fff9a1a5cb3 _pthread_wqthread + 412 3 libsystem_c.dylib 0x00007fff9a190171 start_wqthread + 13 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x0000000000000000 rbx: 0x0000000000000008 rcx: 0x0000000000000000 rdx: 0x0000000000000000 rdi: 0x00000001017ca710 rsi: 0x0000000000000000 rbp: 0x00007fff5fbfc470 rsp: 0x00007fff5fbfc310 r8: 0x0000000000000010 r9: 0x000000000000007f r10: 0x0000000100440a50 r11: 0x00007fff7f98d0e0 r12: 0x0000000000000001 r13: 0x0000000000000002 r14: 0x0000000000000001 r15: 0x00000001033c1790 rip: 0x0000000101391e6c rfl: 0x0000000000010246 cr2: 0x0000000000000024 Logical CPU: 0 Binary Images: 0x100000000 - 0x100000ff7 +Python (???) <1768148D-C54D-CDEA-E308-66DD6F981E49> /Applications/Python 3.2/IDLE.app/Contents/MacOS/Python 0x100003000 - 0x100184ff7 +org.python.python (3.2.3, [c] 2004-2012 Python Software Foundation. - 3.2.3) /Library/Frameworks/Python.framework/Versions/3.2/Python 0x100570000 - 0x100570fff +_bisect.so (???) <78CC2A47-24FF-F895-B747-95A8E082C933> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/_bisect.so 0x1005a1000 - 0x1005a2ff7 +_heapq.so (???) <9E377F57-15D4-FA5A-C33F-79EE16CEFFAE> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/_heapq.so 0x1005e6000 - 0x1005eefff +_socket.so (???) <139F676E-9155-AFC9-1AD3-A782BEAC8C6B> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/_socket.so 0x1005f8000 - 0x1005fafff +time.so (???) /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/time.so 0x1007c0000 - 0x1007c3fff +select.so (???) /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/select.so 0x1007c9000 - 0x1007caff7 +fcntl.so (???) <56137A5B-9D40-321A-EA04-BA3BC276F687> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/fcntl.so 0x1007cd000 - 0x1007d1fff +_struct.so (???) <4146D1DF-404C-17A5-91BD-4D0EA49CA1A9> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/_struct.so 0x1007d8000 - 0x1007e7fff +_pickle.so (???) <201C5209-AB7F-A512-307F-8D2F0B5BA7A9> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/_pickle.so 0x1007f1000 - 0x1007f2ff7 +_posixsubprocess.so (???) /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/_posixsubprocess.so 0x1007f9000 - 0x1007fbff7 +_hashlib.so (???) /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/_hashlib.so 0x1011bd000 - 0x1011c4ff7 +_tkinter.so (???) <885013A0-8BE8-E15A-1150-94172642D585> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/_tkinter.so 0x1011cd000 - 0x1012aafe7 +Tcl (8.5.12 - 8.5.12) /Library/Frameworks/Tcl.framework/Versions/8.5/Tcl 0x1012d6000 - 0x1013e4fef +Tk (8.5.12 - 8.5.12) /Library/Frameworks/Tk.framework/Versions/8.5/Tk 0x1014fc000 - 0x1014fdff7 +_random.so (???) /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/_random.so 0x101ac6000 - 0x101acbfe7 +math.so (???) <5EE93FAE-A0BF-5D9D-7B68-F1BA2D893EAC> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/math.so 0x1039c1000 - 0x1039c7fe7 +array.so (???) <93D44AE8-82E4-1541-2172-0ECB419847E6> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/array.so 0x1039ea000 - 0x1039f3fe7 libcldcpuengine.dylib (2.1.19) <50800DA2-7233-32E5-9553-A02171B68399> /System/Library/Frameworks/OpenCL.framework/Libraries/libcldcpuengine.dylib 0x1039fc000 - 0x1039fcff3 +cl_kernels (???) <146C2B7C-12A5-4BA2-A52F-B7A6462B8C4C> cl_kernels 0x1065ec000 - 0x1065efff7 libCoreFSCache.dylib (24.4) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreFSCache.dylib 0x107cc8000 - 0x107d63fef +unicodedata.so (???) <001D04E6-0D6B-34D3-1DD9-A33C55E86885> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/unicodedata.so 0x10a4e0000 - 0x10a57bff7 unorm8_bgra.dylib (2.1.19) <904EA51D-225A-38AF-B66C-84493C55C065> /System/Library/Frameworks/OpenCL.framework/Libraries/ImageFormats/unorm8_bgra.dylib 0x7fff68dc4000 - 0x7fff68df893f dyld (210.2.3) /usr/lib/dyld 0x7fff8dfea000 - 0x7fff8dff0fff libGFXShared.dylib (8.6.1) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib 0x7fff8dff1000 - 0x7fff8dff2fff liblangid.dylib (116) <864C409D-D56B-383E-9B44-A435A47F2346> /usr/lib/liblangid.dylib 0x7fff8dff8000 - 0x7fff8e0cbff7 com.apple.DiscRecording (7.0 - 7000.2.4) <49FD2D2F-4F2C-39B6-877B-6E3172577D18> /System/Library/Frameworks/DiscRecording.framework/Versions/A/DiscRecording 0x7fff8e2c9000 - 0x7fff8e3c6fff libsqlite3.dylib (138.1) /usr/lib/libsqlite3.dylib 0x7fff8e3c7000 - 0x7fff8ed57c67 com.apple.CoreGraphics (1.600.0 - 324.6) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics 0x7fff8f206000 - 0x7fff8f20eff7 libsystem_dnssd.dylib (379.32.1) <62AA0B84-188A-348B-8F9E-3E2DB08DB93C> /usr/lib/system/libsystem_dnssd.dylib 0x7fff8f211000 - 0x7fff8f22efff com.apple.openscripting (1.3.6 - 148.2) <33B87CFB-CACC-3EBC-893D-38AECB94FB8A> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting 0x7fff8f22f000 - 0x7fff8f4fffff com.apple.security (7.0 - 55179.1) <639641EF-8156-3190-890C-1053658E044A> /System/Library/Frameworks/Security.framework/Versions/A/Security 0x7fff8f500000 - 0x7fff8f5c5ff7 com.apple.coreui (2.0 - 181.1) <83D2C92D-6842-3C9D-9289-39D5B4554C3A> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI 0x7fff8f724000 - 0x7fff8f75afff libsystem_info.dylib (406.17) <4FFCA242-7F04-365F-87A6-D4EFB89503C1> /usr/lib/system/libsystem_info.dylib 0x7fff8fa0a000 - 0x7fff8fa0cff7 libunc.dylib (25) <92805328-CD36-34FF-9436-571AB0485072> /usr/lib/system/libunc.dylib 0x7fff8fa0d000 - 0x7fff8fa44ff7 libssl.0.9.8.dylib (47) <923945E6-C489-3406-903B-A362410753F8> /usr/lib/libssl.0.9.8.dylib 0x7fff8fa71000 - 0x7fff8fa71fff libOpenScriptingUtil.dylib (148.2) /usr/lib/libOpenScriptingUtil.dylib 0x7fff8fa72000 - 0x7fff8fab1ff7 com.apple.QD (3.42 - 285) <8DF36FCA-C06B-30F4-A631-7BE2FF7E56D1> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD 0x7fff8fab2000 - 0x7fff8fb1afff libvDSP.dylib (380.6) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib 0x7fff8fb1b000 - 0x7fff8fb1cff7 libSystem.B.dylib (169.3) <365477AB-D641-389D-B8F4-A1FAE9657EEE> /usr/lib/libSystem.B.dylib 0x7fff8fb28000 - 0x7fff8fb3bff7 com.apple.LangAnalysis (1.7.0 - 1.7.0) <2F2694E9-A7BC-33C7-B4CF-8EC907DF0FEB> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis 0x7fff8fbe5000 - 0x7fff8fc72ff7 com.apple.SearchKit (1.4.0 - 1.4.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit 0x7fff8fcbb000 - 0x7fff8fcbbfff com.apple.ApplicationServices (45 - 45) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices 0x7fff8fcbc000 - 0x7fff8fcc8fff com.apple.CrashReporterSupport (10.8.2 - 414.3) /System/Library/PrivateFrameworks/CrashReporterSupport.framework/Versions/A/CrashReporterSupport 0x7fff8fcc9000 - 0x7fff8fcfeff7 libTrueTypeScaler.dylib (84.5) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libTrueTypeScaler.dylib 0x7fff8fd2c000 - 0x7fff8fd41ff7 libdispatch.dylib (228.23) /usr/lib/system/libdispatch.dylib 0x7fff8fd6b000 - 0x7fff8fd6bfff com.apple.CoreServices (57 - 57) <9DD44CB0-C644-35C3-8F57-0B41B3EC147D> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices 0x7fff8fd6c000 - 0x7fff8fd83fff com.apple.CFOpenDirectory (10.8 - 151.10) /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory 0x7fff8fd84000 - 0x7fff8fe41ff7 com.apple.ColorSync (4.8.0 - 4.8.0) <6CE333AE-EDDB-3768-9598-9DB38041DC55> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync 0x7fff90424000 - 0x7fff90479ff7 libTIFF.dylib (845) /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib 0x7fff9047a000 - 0x7fff90487ff7 com.apple.NetAuth (4.0 - 4.0) /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth 0x7fff90488000 - 0x7fff904cbfff com.apple.RemoteViewServices (2.0 - 80.5) /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices 0x7fff90523000 - 0x7fff90625fff libJP2.dylib (845) <405CAF25-0AA5-3C6B-A4A6-94471A1EDD2F> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib 0x7fff90626000 - 0x7fff9067cfff com.apple.HIServices (1.20 - 417) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices 0x7fff9067d000 - 0x7fff9079592f libobjc.A.dylib (532.2) <90D31928-F48D-3E37-874F-220A51FD9E37> /usr/lib/libobjc.A.dylib 0x7fff9093b000 - 0x7fff90d58fff FaceCoreLight (2.4.1) /System/Library/PrivateFrameworks/FaceCoreLight.framework/Versions/A/FaceCoreLight 0x7fff90d59000 - 0x7fff90da5ff7 libauto.dylib (185.1) <73CDC482-16E3-3FC7-9BB4-FBA2DA44DBC2> /usr/lib/libauto.dylib 0x7fff90da9000 - 0x7fff90e03fff com.apple.print.framework.PrintCore (8.1 - 387.1) <1FA17B75-33E6-35BD-9198-35F92E37B248> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore 0x7fff91735000 - 0x7fff917dbff7 com.apple.CoreServices.OSServices (557.4 - 557.4) <841878A8-6F3E-300D-8F01-444B3CC1F41D> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices 0x7fff91ca4000 - 0x7fff91ea4fff libicucore.A.dylib (491.11.1) /usr/lib/libicucore.A.dylib 0x7fff91ef1000 - 0x7fff91fe1ff7 com.apple.DiskImagesFramework (10.8 - 344) <3A30B9B5-5099-35E2-9DCD-C96764FA2D26> /System/Library/PrivateFrameworks/DiskImages.framework/Versions/A/DiskImages 0x7fff91fe2000 - 0x7fff92038ff7 com.apple.opencl (2.1.20 - 2.1.20) /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL 0x7fff92039000 - 0x7fff92088ff7 libFontRegistry.dylib (100) <2E03D7DA-9B8F-31BB-8FB5-3D3B6272127F> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib 0x7fff920bc000 - 0x7fff920d2fff com.apple.MultitouchSupport.framework (235.28 - 235.28) /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport 0x7fff920d3000 - 0x7fff920e0fff com.apple.AppleFSCompression (49 - 1.0) <5508344A-2A7E-3122-9562-6F363910A80E> /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression 0x7fff920e3000 - 0x7fff9212dff7 libGLU.dylib (8.6.1) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib 0x7fff92139000 - 0x7fff92173fff com.apple.GSS (3.0 - 2.0) <0BDF8090-5EF4-3759-94DE-8521D74188AA> /System/Library/Frameworks/GSS.framework/Versions/A/GSS 0x7fff927a3000 - 0x7fff927e3fff com.apple.MediaKit (13 - 659) <0C56D7FF-0430-3199-9952-CF8577519449> /System/Library/PrivateFrameworks/MediaKit.framework/Versions/A/MediaKit 0x7fff927f3000 - 0x7fff927f7ff7 com.apple.TCC (1.0 - 1) /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC 0x7fff927f8000 - 0x7fff9282efff com.apple.DebugSymbols (98 - 98) <14E788B1-4EB2-3FD7-934B-849534DFC198> /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols 0x7fff92f77000 - 0x7fff92fceff7 com.apple.ScalableUserInterface (1.0 - 1) /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/ScalableUserInterface.framework/Versions/A/ScalableUserInterface 0x7fff9302f000 - 0x7fff9304aff7 libsystem_kernel.dylib (2050.18.24) /usr/lib/system/libsystem_kernel.dylib 0x7fff9304b000 - 0x7fff93056fff com.apple.CommonAuth (3.0 - 2.0) <74A86DDD-57D0-3178-AB74-E1F31DBFFC39> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth 0x7fff93057000 - 0x7fff93131ff7 com.apple.backup.framework (1.4.1 - 1.4.1) /System/Library/PrivateFrameworks/Backup.framework/Versions/A/Backup 0x7fff93187000 - 0x7fff93199ff7 libz.1.dylib (43) <2A1551E8-A272-3DE5-B692-955974FE1416> /usr/lib/libz.1.dylib 0x7fff9319a000 - 0x7fff931bbff7 libCRFSuite.dylib (33) <736ABE58-8DED-3289-A042-C25AF7AE5B23> /usr/lib/libCRFSuite.dylib 0x7fff9320c000 - 0x7fff9320ffff com.apple.help (1.3.2 - 42) <343904FE-3022-3573-97D6-5FE17F8643BA> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help 0x7fff93210000 - 0x7fff93217fff com.apple.NetFS (5.0 - 4.0) <82E24B9A-7742-3DA3-9E99-ED267D98C05E> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS 0x7fff9321a000 - 0x7fff93241fff com.apple.framework.familycontrols (4.1 - 410) /System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls 0x7fff93242000 - 0x7fff93261ff7 libresolv.9.dylib (51) <0882DC2D-A892-31FF-AD8C-0BB518C48B23> /usr/lib/libresolv.9.dylib 0x7fff93262000 - 0x7fff932a6fff libcups.2.dylib (327) <9B3F3321-D2BC-3195-BF20-4008FC52A390> /usr/lib/libcups.2.dylib 0x7fff93302000 - 0x7fff93453fff com.apple.audio.toolbox.AudioToolbox (1.8 - 1.8) <833DA682-A3C1-39E7-AEC3-9EDC734DE2A9> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox 0x7fff9440f000 - 0x7fff9450cff7 libxml2.2.dylib (22.3) <47B09CB2-C636-3024-8B55-6040F7829B4C> /usr/lib/libxml2.2.dylib 0x7fff9450d000 - 0x7fff94535fff libJPEG.dylib (845) /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib 0x7fff945b4000 - 0x7fff945b6fff libquarantine.dylib (52) <4BE2E642-A14F-340A-B482-5BD2AEFD9C24> /usr/lib/system/libquarantine.dylib 0x7fff94615000 - 0x7fff9470afff libiconv.2.dylib (34) /usr/lib/libiconv.2.dylib 0x7fff94a68000 - 0x7fff94a96fff com.apple.CoreServicesInternal (154.2 - 154.2) <3E6196E6-F3B4-316F-9E1F-13B6B9694C7E> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal 0x7fff94e0d000 - 0x7fff94e4afe7 libGLImage.dylib (8.6.1) <7F31DD61-3110-3541-A9BB-035CD1262E50> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib 0x7fff94e54000 - 0x7fff94e62ff7 libsystem_network.dylib (77.10) <0D99F24E-56FE-380F-B81B-4A4C630EE587> /usr/lib/system/libsystem_network.dylib 0x7fff94e63000 - 0x7fff95193ff7 com.apple.HIToolbox (2.0 - 625) <317F75F7-4B0F-35F5-89A7-F20BA60AC944> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox 0x7fff951d8000 - 0x7fff951ddfff libcache.dylib (57) <65187C6E-3FBF-3EB8-A1AA-389445E2984D> /usr/lib/system/libcache.dylib 0x7fff951fc000 - 0x7fff951fcffd com.apple.audio.units.AudioUnit (1.8 - 1.8) <29E2C990-3617-3FA2-BDD7-DB7DF493E443> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit 0x7fff9532c000 - 0x7fff95374fff libcurl.4.dylib (69.2) /usr/lib/libcurl.4.dylib 0x7fff95375000 - 0x7fff9537ffff com.apple.speech.recognition.framework (4.1.5 - 4.1.5) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition 0x7fff95380000 - 0x7fff95380fff com.apple.Carbon (154 - 155) <372716D2-6FA1-3611-8501-3DD1D4A6E8C8> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 0x7fff95381000 - 0x7fff95386fff com.apple.OpenDirectory (10.8 - 151.10) /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory 0x7fff953cf000 - 0x7fff953d8fff com.apple.CommerceCore (1.0 - 26) <997CD214-BC78-3C61-A1B8-813EA1CB9997> /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Frameworks/CommerceCore.framework/Versions/A/CommerceCore 0x7fff953d9000 - 0x7fff95400ff7 com.apple.PerformanceAnalysis (1.16 - 16) /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis 0x7fff958f7000 - 0x7fff95954ff7 com.apple.AE (645.3 - 645.3) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE 0x7fff95955000 - 0x7fff95959fff com.apple.IOSurface (86.0.3 - 86.0.3) /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface 0x7fff9595a000 - 0x7fff959a9ff7 libcorecrypto.dylib (106.2) /usr/lib/system/libcorecrypto.dylib 0x7fff959aa000 - 0x7fff95a44fff libvMisc.dylib (380.6) <714336EA-1C0E-3735-B31C-19DFDAAF6221> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib 0x7fff95d70000 - 0x7fff95d76fff libmacho.dylib (829) /usr/lib/system/libmacho.dylib 0x7fff95d8e000 - 0x7fff95dbaff7 libRIP.A.dylib (324.6) <5A7EB5C2-BA60-36D7-BF41-9853F37837AA> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib 0x7fff95dbb000 - 0x7fff960d2ff7 com.apple.CoreServices.CarbonCore (1037.3 - 1037.3) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore 0x7fff960d3000 - 0x7fff960d3fff com.apple.Accelerate.vecLib (3.8 - vecLib 3.8) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib 0x7fff9612c000 - 0x7fff9612efff libCVMSPluginSupport.dylib (8.6.1) <7EFDA31E-E463-3897-A8DC-7FD266EB713E> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib 0x7fff9612f000 - 0x7fff9613dff7 libkxld.dylib (2050.18.24) <7027CE49-007D-3553-8FFA-3E3B428B2316> /usr/lib/system/libkxld.dylib 0x7fff9613e000 - 0x7fff96142fff libGIF.dylib (845) <2690CE83-E934-3EF8-A30A-996EDADCE3E4> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib 0x7fff96143000 - 0x7fff96149ff7 libunwind.dylib (35.1) <21703D36-2DAB-3D8B-8442-EAAB23C060D3> /usr/lib/system/libunwind.dylib 0x7fff961ed000 - 0x7fff961eeff7 libsystem_sandbox.dylib (220) <3C3B03CF-C525-3CB3-8557-62E91B93AC95> /usr/lib/system/libsystem_sandbox.dylib 0x7fff961f0000 - 0x7fff9622bfff com.apple.LDAPFramework (2.4.28 - 194.5) <0190B746-F684-3F43-B4D0-148EFE386CA4> /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP 0x7fff9622c000 - 0x7fff9622cfff libkeymgr.dylib (25) /usr/lib/system/libkeymgr.dylib 0x7fff963b1000 - 0x7fff963e9fff libtidy.A.dylib (15.10) <9009156B-84F5-3781-BFCB-B409B538CD18> /usr/lib/libtidy.A.dylib 0x7fff9643a000 - 0x7fff9650cff7 com.apple.CoreText (260.0 - 275.16) <5BFC1D67-6A6F-38BC-9D90-9C712684EDAC> /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText 0x7fff96590000 - 0x7fff965b2ff7 libxpc.dylib (140.41) /usr/lib/system/libxpc.dylib 0x7fff965b3000 - 0x7fff965e4ff7 com.apple.DictionaryServices (1.2 - 184.4) <054F2D6F-9CFF-3EF1-9778-25C551B616C1> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices 0x7fff96671000 - 0x7fff969cdfff com.apple.Foundation (6.8 - 945.11) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 0x7fff969ce000 - 0x7fff969d0fff com.apple.TrustEvaluationAgent (2.0 - 23) /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent 0x7fff969d1000 - 0x7fff96a6bfff com.apple.CoreSymbolication (3.0 - 87) <75F2C0DD-549A-36F6-BD9E-FB40A924344F> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication 0x7fff96a6c000 - 0x7fff96a74fff liblaunch.dylib (442.26.2) <2F71CAF8-6524-329E-AC56-C506658B4C0C> /usr/lib/system/liblaunch.dylib 0x7fff96d81000 - 0x7fff96d8cff7 com.apple.bsd.ServiceManagement (2.0 - 2.0) /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement 0x7fff96d8d000 - 0x7fff96e0bff7 com.apple.securityfoundation (6.0 - 55115.4) /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation 0x7fff96e0c000 - 0x7fff96e11fff libcompiler_rt.dylib (30) <08F8731D-5961-39F1-AD00-4590321D24A9> /usr/lib/system/libcompiler_rt.dylib 0x7fff96e12000 - 0x7fff96e3cff7 com.apple.CoreVideo (1.8 - 99.3) /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo 0x7fff96e49000 - 0x7fff96fbdfff com.apple.CFNetwork (596.2.3 - 596.2.3) <6A16C2BD-1035-30F9-AE96-D9E3BB54A976> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork 0x7fff96fc7000 - 0x7fff96fd5fff com.apple.Librarian (1.1 - 1) <1635162F-239A-341E-83C7-710C55E254AF> /System/Library/PrivateFrameworks/Librarian.framework/Versions/A/Librarian 0x7fff96fea000 - 0x7fff96ff7fff libbz2.1.0.dylib (29) /usr/lib/libbz2.1.0.dylib 0x7fff970ae000 - 0x7fff970c5fff com.apple.GenerationalStorage (1.1 - 132.2) <3F5C87BD-D866-3732-8CB9-D23ED9784D6E> /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/GenerationalStorage 0x7fff970c6000 - 0x7fff970c8fff com.apple.securityhi (4.0 - 55002) <34E45C60-DC7E-3FCC-A1ED-EBF48B77C559> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI 0x7fff970c9000 - 0x7fff970caff7 libremovefile.dylib (23.1) /usr/lib/system/libremovefile.dylib 0x7fff970cb000 - 0x7fff970f0ff7 libc++abi.dylib (24.4) /usr/lib/libc++abi.dylib 0x7fff970f1000 - 0x7fff9711cfff libxslt.1.dylib (11.3) <441776B8-9130-3893-956F-39C85FFA644F> /usr/lib/libxslt.1.dylib 0x7fff9711d000 - 0x7fff9719dff7 com.apple.ApplicationServices.ATS (332 - 341.1) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS 0x7fff97236000 - 0x7fff97258ff7 com.apple.Kerberos (2.0 - 1) /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos 0x7fff97259000 - 0x7fff9725bff7 com.apple.print.framework.Print (8.0 - 258) <34666CC2-B86D-3313-B3B6-A9977AD593DA> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print 0x7fff9725c000 - 0x7fff97445fff com.apple.CoreFoundation (6.8 - 744.12) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x7fff97470000 - 0x7fff9749efff com.apple.shortcut (2.2 - 2.2) /System/Library/PrivateFrameworks/Shortcut.framework/Versions/A/Shortcut 0x7fff9749f000 - 0x7fff974a3fff libCoreVMClient.dylib (24.4) <55F71158-ADEE-3863-92E9-4772DCEA8E31> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib 0x7fff975a3000 - 0x7fff975f4ff7 com.apple.SystemConfiguration (1.12.2 - 1.12.2) /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration 0x7fff975f5000 - 0x7fff97616fff com.apple.Ubiquity (1.2 - 243.10) /System/Library/PrivateFrameworks/Ubiquity.framework/Versions/A/Ubiquity 0x7fff9761c000 - 0x7fff9761dfff libsystem_blocks.dylib (59) /usr/lib/system/libsystem_blocks.dylib 0x7fff9765b000 - 0x7fff976c8fff com.apple.datadetectorscore (4.0 - 269.1) /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore 0x7fff976c9000 - 0x7fff97725ff7 com.apple.Symbolication (1.3 - 93) /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication 0x7fff97726000 - 0x7fff9772cfff libCGXCoreImage.A.dylib (324.6) <45864BEA-B2EA-3F5F-9D04-F9832AB67A00> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXCoreImage.A.dylib 0x7fff9777e000 - 0x7fff9778cfff libcommonCrypto.dylib (60026) <2D6537F5-1B5E-305C-A1CF-D1FA80CA3939> /usr/lib/system/libcommonCrypto.dylib 0x7fff9778d000 - 0x7fff978adfff com.apple.desktopservices (1.7.2 - 1.7.2) /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv 0x7fff98057000 - 0x7fff9805afff libRadiance.dylib (845) /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib 0x7fff9805b000 - 0x7fff980dcfff com.apple.Metadata (10.7.0 - 707.3) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata 0x7fff980dd000 - 0x7fff981e8fff libFontParser.dylib (84.5) <617A7D30-C7BC-39FC-A1FE-59367B4A5719> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib 0x7fff981e9000 - 0x7fff981e9fff com.apple.Accelerate (1.8 - Accelerate 1.8) <6AD48543-0864-3D40-80CE-01F184F24B45> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate 0x7fff981ea000 - 0x7fff98398fff com.apple.QuartzCore (1.8 - 304.0) /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore 0x7fff98399000 - 0x7fff98406ff7 com.apple.framework.IOKit (2.0 - 755.18.10) <142E19DD-1C8D-3D61-ABC8-83994A73279F> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 0x7fff98407000 - 0x7fff98427fff libPng.dylib (845) /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib 0x7fff98428000 - 0x7fff9852afff libcrypto.0.9.8.dylib (47) <74F165AD-4572-3B26-B0E2-A97477FE59D0> /usr/lib/libcrypto.0.9.8.dylib 0x7fff9852b000 - 0x7fff9853aff7 libxar.1.dylib (105) <370ED355-E516-311E-BAFD-D80633A84BE1> /usr/lib/libxar.1.dylib 0x7fff987e3000 - 0x7fff987e4ff7 libdnsinfo.dylib (453.18) /usr/lib/system/libdnsinfo.dylib 0x7fff987e5000 - 0x7fff987e9fff libCGXType.A.dylib (324.6) <2FC25246-A69F-3F81-9AC6-0A1753E1C6A8> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXType.A.dylib 0x7fff987ea000 - 0x7fff987f1fff libcopyfile.dylib (89) <876573D0-E907-3566-A108-577EAD1B6182> /usr/lib/system/libcopyfile.dylib 0x7fff98834000 - 0x7fff98849fff com.apple.ImageCapture (8.0 - 8.0) <17A45CE6-7DA3-36A5-B7EF-72BC136981AE> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture 0x7fff9884e000 - 0x7fff98851ff7 libdyld.dylib (210.2.3) /usr/lib/system/libdyld.dylib 0x7fff98852000 - 0x7fff9896bff7 com.apple.ImageIO.framework (3.2.0 - 845) <553B9828-A7D9-3AE4-A214-1C33417545FD> /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO 0x7fff98a12000 - 0x7fff98a12fff com.apple.Cocoa (6.7 - 19) <1F77945C-F37A-3171-B22E-F7AB0FCBB4D4> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa 0x7fff98a56000 - 0x7fff98a84ff7 libsystem_m.dylib (3022.6) /usr/lib/system/libsystem_m.dylib 0x7fff98a85000 - 0x7fff98a85fff com.apple.vecLib (3.8 - vecLib 3.8) <794317C7-4E38-338A-A874-5E18001C8503> /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib 0x7fff98a86000 - 0x7fff98a99ff7 libbsm.0.dylib (32) /usr/lib/libbsm.0.dylib 0x7fff98a9a000 - 0x7fff98b02ff7 libc++.1.dylib (65.1) <20E31B90-19B9-3C2A-A9EB-474E08F9FE05> /usr/lib/libc++.1.dylib 0x7fff98b49000 - 0x7fff98b4ffff com.apple.DiskArbitration (2.5.1 - 2.5.1) /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration 0x7fff98b50000 - 0x7fff98b5fff7 com.apple.opengl (1.8.6 - 1.8.6) <720CC06C-0D01-37AE-BB3D-D7F0242B262A> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL 0x7fff98b60000 - 0x7fff98f57fff libLAPACK.dylib (1073.4) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib 0x7fff98f58000 - 0x7fff9918dff7 com.apple.CoreData (106.1 - 407.7) <24E0A6B4-9ECA-3D12-B26A-72B9DCF09768> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData 0x7fff9918e000 - 0x7fff9919fff7 libsasl2.2.dylib (166) <649CAE0E-8FFE-3C60-A849-BE6300E4B726> /usr/lib/libsasl2.2.dylib 0x7fff991a0000 - 0x7fff991abfff libsystem_notify.dylib (98.5) /usr/lib/system/libsystem_notify.dylib 0x7fff991ac000 - 0x7fff991b0fff libpam.2.dylib (20) /usr/lib/libpam.2.dylib 0x7fff991b1000 - 0x7fff9920efff com.apple.audio.CoreAudio (4.1.0 - 4.1.0) /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio 0x7fff9920f000 - 0x7fff993aafef com.apple.vImage (6.0 - 6.0) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage 0x7fff9947a000 - 0x7fff9971efff com.apple.CoreImage (8.2.2 - 1.0.1) <930B0B23-DD84-3B0C-B5A9-C09B7068A6F0> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/CoreImage.framework/Versions/A/CoreImage 0x7fff9971f000 - 0x7fff99723ff7 com.apple.CommonPanels (1.2.5 - 94) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels 0x7fff99724000 - 0x7fff99731ff7 com.apple.HelpData (2.1.4 - 85) /System/Library/PrivateFrameworks/HelpData.framework/Versions/A/HelpData 0x7fff9975b000 - 0x7fff998e1fff libBLAS.dylib (1073.4) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib 0x7fff998e4000 - 0x7fff998f8fff com.apple.speech.synthesis.framework (4.1.12 - 4.1.12) <94EDF2AB-809C-3D15-BED5-7AD45B2A7C16> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis 0x7fff998f9000 - 0x7fff9997bfff com.apple.Heimdal (3.0 - 2.0) <660A6C64-4912-32C8-A332-B64164032A2D> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal 0x7fff9997c000 - 0x7fff9997dfff libDiagnosticMessagesClient.dylib (8) <8548E0DC-0D2F-30B6-B045-FE8A038E76D8> /usr/lib/libDiagnosticMessagesClient.dylib 0x7fff9998a000 - 0x7fff99c0dfff com.apple.RawCamera.bundle (4.00 - 658) <6786E9E0-3197-30A3-A0F4-22A6064B3EF2> /System/Library/CoreServices/RawCamera.bundle/Contents/MacOS/RawCamera 0x7fff99d00000 - 0x7fff99d69fff libstdc++.6.dylib (56) /usr/lib/libstdc++.6.dylib 0x7fff99d6a000 - 0x7fff99d89ff7 com.apple.ChunkingLibrary (2.0 - 133.2) /System/Library/PrivateFrameworks/ChunkingLibrary.framework/Versions/A/ChunkingLibrary 0x7fff9a025000 - 0x7fff9a0c3ff7 com.apple.ink.framework (10.8.2 - 150) <84B9825C-3822-375F-BE58-A753444FBDE2> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink 0x7fff9a0c4000 - 0x7fff9a175fff com.apple.LaunchServices (539.7 - 539.7) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices 0x7fff9a182000 - 0x7fff9a18efff libCSync.A.dylib (324.6) <2033247A-CABC-3E20-8498-7367A8F44A08> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib 0x7fff9a18f000 - 0x7fff9a25bfe7 libsystem_c.dylib (825.25) <8CBCF9B9-EBB7-365E-A3FF-2F3850763C6B> /usr/lib/system/libsystem_c.dylib 0x7fff9a2b7000 - 0x7fff9a2faff7 com.apple.bom (12.0 - 192) <0BF1F2D2-3648-36B7-BE4B-551A0173209B> /System/Library/PrivateFrameworks/Bom.framework/Versions/A/Bom 0x7fff9a2fb000 - 0x7fff9a30ffff libGL.dylib (8.6.1) <2E00615F-97F5-34EB-BE07-75A24F3C18D7> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib 0x7fff9a310000 - 0x7fff9af3dff7 com.apple.AppKit (6.8 - 1187.34) <1FF64844-EB62-3F96-AED7-6525B7CCEC23> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit External Modification Summary: Calls made by other processes targeting this process: task_for_pid: 2 thread_create: 0 thread_set_state: 0 Calls made by this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by all processes on this machine: task_for_pid: 3429 thread_create: 0 thread_set_state: 0 VM Region Summary: ReadOnly portion of Libraries: Total=156.9M resident=114.9M(73%) swapped_out_or_unallocated=42.0M(27%) Writable regions: Total=124.0M written=17.3M(14%) resident=24.7M(20%) swapped_out=0K(0%) unallocated=99.3M(80%) REGION TYPE VIRTUAL =========== ======= CG backing stores 1296K CG image 136K CG shared images 1216K CoreImage 4K CoreServices 3972K MALLOC 92.2M MALLOC guard page 48K MALLOC_LARGE (reserved) 384K reserved VM address space (unallocated) Memory tag=240 4K Memory tag=242 12K OpenCL 8K STACK GUARD 56.0M Stack 12.1M VM_ALLOCATE 16.1M __DATA 11.8M __IMAGE 528K __LINKEDIT 54.3M __TEXT 102.6M __UNICODE 544K mapped file 42.2M shared memory 308K =========== ======= TOTAL 395.6M TOTAL, minus reserved VM space 395.3M Model: MacBookPro9,1, BootROM MBP91.00D3.B08, 4 processors, Intel Core i7, 2.6 GHz, 8 GB, SMC 2.1f170 Graphics: Intel HD Graphics 4000, Intel HD Graphics 4000, Built-In, 512 MB Graphics: NVIDIA GeForce GT 650M, NVIDIA GeForce GT 650M, PCIe, 1024 MB Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80CE, 0x4D34373142353237334448302D434B302020 Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80CE, 0x4D34373142353237334448302D434B302020 AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0xF5), Broadcom BCM43xx 1.0 (5.106.98.81.22) Bluetooth: Version 4.0.9f33 10885, 2 service, 11 devices, 1 incoming serial ports Network Service: Ethernet, Ethernet, en0 Network Service: Wi-Fi, AirPort, en1 Serial ATA Device: TOSHIBA MK7559GSXF, 750.16 GB Serial ATA Device: OPTIARC DVD RW AD-5970H USB Device: hub_device, 0x8087 (Intel Corporation), 0x0024, 0x1a100000 / 2 USB Device: FaceTime HD Camera (Built-in), apple_vendor_id, 0x8509, 0x1a110000 / 3 USB Device: hub_device, 0x8087 (Intel Corporation), 0x0024, 0x1d100000 / 2 USB Device: hub_device, 0x0424 (SMSC), 0x2513, 0x1d180000 / 3 USB Device: Apple Internal Keyboard / Trackpad, apple_vendor_id, 0x0252, 0x1d183000 / 6 USB Device: IR Receiver, apple_vendor_id, 0x8242, 0x1d182000 / 5 USB Device: BRCM20702 Hub, 0x0a5c (Broadcom Corp.), 0x4500, 0x1d181000 / 4 USB Device: Bluetooth USB Host Controller, apple_vendor_id, 0x821d, 0x1d181300 / 7 ---------- components: IDLE messages: 171342 nosy: senshy11 at gmail.com priority: normal severity: normal status: open title: Preferences Crashes on click type: crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 16:55:27 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 14:55:27 +0000 Subject: [issue13224] Change str(x) to return only the (qual)name for some types In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za> Message-ID: <1348671327.51.0.972578281341.issue13224@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 16:58:16 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 14:58:16 +0000 Subject: [issue13263] Group some os functions in submodules In-Reply-To: <1319544377.25.0.706220454632.issue13263@psf.upfronthosting.co.za> Message-ID: <1348671496.12.0.586963518192.issue13263@psf.upfronthosting.co.za> Ezio Melotti added the comment: Now it's too late to fix this, so I'm closing it. ---------- resolution: -> out of date stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 18:11:24 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 26 Sep 2012 16:11:24 +0000 Subject: [issue16054] IDLE Preferences Crashes on click In-Reply-To: <1348669653.52.0.428448233738.issue16054@psf.upfronthosting.co.za> Message-ID: <1348675884.27.0.758663552935.issue16054@psf.upfronthosting.co.za> Ned Deily added the comment: This is due to a bug in the current Cocoa Tk as released in ActiveTcl 8.5.12.1 (and 8.5.12). Try installing the previous ActiveTcl version, 8.5.11.1: http://downloads.activestate.com/ActiveTcl/releases/8.5.11.1/ ---------- nosy: +ned.deily resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> IDLE crashes selecting Preferences menu with OS X ActiveState Tcl/Tk 8.5.12.1 title: Preferences Crashes on click -> IDLE Preferences Crashes on click versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 18:42:55 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 16:42:55 +0000 Subject: [issue6027] test_xmlrpc_net fails when the ISP returns "302 Found" In-Reply-To: <1242351266.25.0.645875354715.issue6027@psf.upfronthosting.co.za> Message-ID: <1348677775.55.0.674162542349.issue6027@psf.upfronthosting.co.za> Ezio Melotti added the comment: da148f0d86bd added a skip to the test (see #13434). Also xmlrpc.com now redirects to xmlrpc.scripting.com. ---------- resolution: -> out of date stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 18:47:21 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 16:47:21 +0000 Subject: [issue13056] test_multibytecodec.py:TestStreamWriter is skipped after PEP393 In-Reply-To: <1317260300.62.0.299015504355.issue13056@psf.upfronthosting.co.za> Message-ID: <1348678041.5.0.517086053766.issue13056@psf.upfronthosting.co.za> Ezio Melotti added the comment: Victor, do you know if multibytecodec has been ported to the new API yet? If I removed the "if", I still get a failure. test test_multibytecodec failed -- Traceback (most recent call last): File "/home/wolf/dev/py/py3k/Lib/test/test_multibytecodec.py", line 187, in test_gb18030 self.assertEqual(s.getvalue(), b'123\x907\x959') AssertionError: b'123\x907\x959\x907\x959' != b'123\x907\x959' ---------- keywords: +3.3regression _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 18:50:16 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 16:50:16 +0000 Subject: [issue12707] Deprecate addinfourl getters In-Reply-To: <1312760770.57.0.2285900636.issue12707@psf.upfronthosting.co.za> Message-ID: <1348678216.15.0.942089388393.issue12707@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- type: -> enhancement versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 18:51:37 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 16:51:37 +0000 Subject: [issue14097] Improve the "introduction" page of the tutorial In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za> Message-ID: <1348678297.79.0.657545533142.issue14097@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +chris.jerdonek versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 18:57:11 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 26 Sep 2012 16:57:11 +0000 Subject: [issue13056] test_multibytecodec.py:TestStreamWriter is skipped after PEP393 In-Reply-To: <1317260300.62.0.299015504355.issue13056@psf.upfronthosting.co.za> Message-ID: <1348678631.4.0.526176644268.issue13056@psf.upfronthosting.co.za> STINNER Victor added the comment: > Victor, do you know if multibytecodec has been ported to the new API yet? No, it has no. CJK codecs still use the legacy API (Py_UNICODE). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 19:02:03 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 26 Sep 2012 17:02:03 +0000 Subject: [issue1087] py3k os.popen result is not iterable, patch attached In-Reply-To: <1194531480.0.0.141906660951.issue1087@psf.upfronthosting.co.za> Message-ID: <3XRln61DF0zNXB@mail.python.org> Roundup Robot added the comment: New changeset c8cc94a0ba4c by Ezio Melotti in branch 'default': #1087: use proper skips in test_os. http://hg.python.org/cpython/rev/c8cc94a0ba4c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 19:06:23 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 17:06:23 +0000 Subject: [issue6973] subprocess.Popen.send_signal doesn't check whether the process has terminated In-Reply-To: <1253659668.76.0.344119676181.issue6973@psf.upfronthosting.co.za> Message-ID: <1348679183.33.0.657274024728.issue6973@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4 -Python 2.6, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 19:08:17 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 17:08:17 +0000 Subject: [issue6331] Add unicode script info to the unicode database In-Reply-To: <1245790259.44.0.08771310344.issue6331@psf.upfronthosting.co.za> Message-ID: <1348679297.86.0.74738756058.issue6331@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 19:10:40 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 17:10:40 +0000 Subject: [issue6412] Titlecase as defined in Unicode Case Mappings not followed In-Reply-To: <1246662889.32.0.498842923824.issue6412@psf.upfronthosting.co.za> Message-ID: <1348679440.51.0.292343261113.issue6412@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- versions: +Python 3.3, Python 3.4 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 19:12:32 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 17:12:32 +0000 Subject: [issue6519] Reorder 'with' statement for files in Python Tutorial In-Reply-To: <1247966369.75.0.40232300258.issue6519@psf.upfronthosting.co.za> Message-ID: <1348679552.72.0.747858388927.issue6519@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +chris.jerdonek versions: +Python 3.3, Python 3.4 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 19:13:29 2012 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 26 Sep 2012 17:13:29 +0000 Subject: [issue7844] Add -3 warning for absolute imports. In-Reply-To: <1265205081.99.0.588324125272.issue7844@psf.upfronthosting.co.za> Message-ID: <1348679609.43.0.613231747103.issue7844@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 19:17:24 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 26 Sep 2012 17:17:24 +0000 Subject: [issue16036] simplify int() signature docs In-Reply-To: <1348568310.1.0.968219969881.issue16036@psf.upfronthosting.co.za> Message-ID: <1348679844.01.0.798162396543.issue16036@psf.upfronthosting.co.za> ?ric Araujo added the comment: Latest patch LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 19:22:17 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 17:22:17 +0000 Subject: [issue8401] Strange behavior of bytearray slice assignment In-Reply-To: <1271259710.42.0.373058487219.issue8401@psf.upfronthosting.co.za> Message-ID: <1348680137.69.0.114532830626.issue8401@psf.upfronthosting.co.za> Ezio Melotti added the comment: > >>> a[:] = -1000000000000000000000 # This should raise ValueError, not TypeError. > >>> a[:] = 1000000000000000000000 # This should raise OverflowError, not TypeError. FTR, these two now raise OverflowError. ---------- versions: +Python 3.3, Python 3.4 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 19:23:55 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 17:23:55 +0000 Subject: [issue10669] Document Deprecation Warnings and how to fix In-Reply-To: <1291959647.89.0.597449973256.issue10669@psf.upfronthosting.co.za> Message-ID: <1348680235.27.0.576355478746.issue10669@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +chris.jerdonek versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 19:26:51 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 17:26:51 +0000 Subject: [issue4758] Python 3.x internet documentation needs work In-Reply-To: <1230383680.06.0.695552325819.issue4758@psf.upfronthosting.co.za> Message-ID: <1348680411.88.0.144624907143.issue4758@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- resolution: -> out of date stage: needs patch -> committed/rejected status: languishing -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 19:27:59 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 17:27:59 +0000 Subject: [issue11461] Reading UTF-16 with codecs.readline() breaks on surrogate pairs In-Reply-To: <1299752398.22.0.888282532941.issue11461@psf.upfronthosting.co.za> Message-ID: <1348680479.63.0.564666856773.issue11461@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 19:29:06 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 17:29:06 +0000 Subject: [issue5846] Deprecate obsolete functions in unittest In-Reply-To: <1240703100.05.0.329458142097.issue5846@psf.upfronthosting.co.za> Message-ID: <1348680546.7.0.693458334548.issue5846@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- type: -> enhancement versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 19:32:35 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 17:32:35 +0000 Subject: [issue11313] Speed up default encode()/decode() In-Reply-To: <1298586589.12.0.407554806858.issue11313@psf.upfronthosting.co.za> Message-ID: <1348680755.5.0.537655414466.issue11313@psf.upfronthosting.co.za> Ezio Melotti added the comment: Can this be closed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 19:43:23 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 26 Sep 2012 17:43:23 +0000 Subject: [issue16036] simplify int() signature docs In-Reply-To: <1348568310.1.0.968219969881.issue16036@psf.upfronthosting.co.za> Message-ID: <1348681403.21.0.221548665936.issue16036@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Good improvement. LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 19:45:54 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 17:45:54 +0000 Subject: [issue4153] Unicode HOWTO up to date? In-Reply-To: <1224525840.81.0.649106205615.issue4153@psf.upfronthosting.co.za> Message-ID: <1348681554.84.0.568843888513.issue4153@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: -> ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 19:51:51 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 17:51:51 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1348681911.2.0.982927615148.issue2292@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: -after moratorium versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 20:43:33 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 18:43:33 +0000 Subject: [issue14679] Define an __all__ for html.parser In-Reply-To: <1335470773.41.0.349037543033.issue14679@psf.upfronthosting.co.za> Message-ID: <1348685013.25.0.651553786323.issue14679@psf.upfronthosting.co.za> Ezio Melotti added the comment: The issue with Django seems to be solved, but as Terry suggested in http://mail.python.org/pipermail/python-dev/2012-April/119087.html, adding an __all__ would be a good idea. I'm changing the scope of the issue accordingly. ---------- assignee: -> ezio.melotti components: +Library (Lib) stage: -> needs patch title: Changes to html.parser break third-party code -> Define an __all__ for html.parser versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 20:46:07 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 18:46:07 +0000 Subject: [issue10665] Expand unicodedata module documentation In-Reply-To: <1291930276.17.0.60709403086.issue10665@psf.upfronthosting.co.za> Message-ID: <1348685167.74.0.868758215028.issue10665@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 20:48:58 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 18:48:58 +0000 Subject: [issue14886] json C vs pure-python implementation difference In-Reply-To: <1337765129.86.0.0917200779683.issue14886@psf.upfronthosting.co.za> Message-ID: <1348685338.46.0.542263542533.issue14886@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 20:49:26 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 18:49:26 +0000 Subject: [issue4733] Add a "decode to declared encoding" version of urlopen to urllib In-Reply-To: <1230068654.82.0.881542673607.issue4733@psf.upfronthosting.co.za> Message-ID: <1348685366.8.0.0907402099955.issue4733@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 20:50:11 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 18:50:11 +0000 Subject: [issue7300] Unicode arguments in str.format() In-Reply-To: <1257861455.06.0.0846130484851.issue7300@psf.upfronthosting.co.za> Message-ID: <1348685411.06.0.038067947849.issue7300@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +chris.jerdonek versions: -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 20:51:22 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 18:51:22 +0000 Subject: [issue6975] symlinks incorrectly resolved on Linux In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za> Message-ID: <1348685482.3.0.453742914406.issue6975@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 20:52:47 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 18:52:47 +0000 Subject: [issue13248] deprecated in 3.2/3.3, should be removed in 3.4 In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za> Message-ID: <1348685567.78.0.947722043415.issue13248@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- title: deprecated in 3.2, should be removed in 3.3 -> deprecated in 3.2/3.3, should be removed in 3.4 versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 20:57:34 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 18:57:34 +0000 Subject: [issue15815] Add numerator to ZeroDivisionError messages In-Reply-To: <1346268284.86.0.294059613354.issue15815@psf.upfronthosting.co.za> Message-ID: <1348685854.35.0.76496621824.issue15815@psf.upfronthosting.co.za> Ezio Melotti added the comment: Terry, do you still think that adding the numerator would be useful? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 21:11:09 2012 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 26 Sep 2012 19:11:09 +0000 Subject: [issue15815] Add numerator to ZeroDivisionError messages In-Reply-To: <1346268284.86.0.294059613354.issue15815@psf.upfronthosting.co.za> Message-ID: <1348686669.79.0.634069376941.issue15815@psf.upfronthosting.co.za> Mark Dickinson added the comment: I'll add my -1 to this; I don't really see the use. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 21:25:05 2012 From: report at bugs.python.org (Lino Mastrodomenico) Date: Wed, 26 Sep 2012 19:25:05 +0000 Subject: [issue4733] Add a "decode to declared encoding" version of urlopen to urllib In-Reply-To: <1230068654.82.0.881542673607.issue4733@psf.upfronthosting.co.za> Message-ID: <1348687505.76.0.248777441283.issue4733@psf.upfronthosting.co.za> Lino Mastrodomenico added the comment: FYI, the exact algorithm for determining the encoding of HTML documents is http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#determining-the-character-encoding There are lots of different algorithms documented all over the intertubes for determining HTML encoding; the one above is the one used by browsers. But that should only be used as part of a full HTML parsing library (e.g. https://code.google.com/p/html5lib/), urlopen should not attempt to do encoding sniffing from the data transferred. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 21:41:01 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 26 Sep 2012 19:41:01 +0000 Subject: [issue16055] incorrect error text for int(base=1000, x='1') Message-ID: <1348688461.13.0.427927679227.issue16055@psf.upfronthosting.co.za> New submission from Chris Jerdonek: The following error text is incorrect in at least one way: >>> int(base=1000, x='1') Traceback (most recent call last): File "", line 1, in ValueError: int() arg 2 must be >= 2 and <= 36 The *base* argument can also be 0. Secondly, the text should probably say "base arg" instead of "arg 2" since 1000 is not in position 2. The 2.7 code does not have the second issue: >>> int(base=1000, x='1') Traceback (most recent call last): File "", line 1, in ValueError: int() base must be >= 2 and <= 36 ---------- components: Library (Lib) keywords: easy messages: 171357 nosy: chris.jerdonek, ezio.melotti priority: normal severity: normal stage: test needed status: open title: incorrect error text for int(base=1000, x='1') type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 21:44:41 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 26 Sep 2012 19:44:41 +0000 Subject: [issue15815] Add numerator to ZeroDivisionError messages In-Reply-To: <1346268284.86.0.294059613354.issue15815@psf.upfronthosting.co.za> Message-ID: <1348688681.36.0.213241530209.issue15815@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Not enough, at present, to leave this open. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 21:44:50 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 26 Sep 2012 19:44:50 +0000 Subject: [issue16055] incorrect error text for int(base=1000, x='1') In-Reply-To: <1348688461.13.0.427927679227.issue16055@psf.upfronthosting.co.za> Message-ID: <1348688690.57.0.678476104038.issue16055@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Locations: Objects/longobject.c 1994: "int() arg 2 must be >= 2 and <= 36"); 4273: "int() arg 2 must be >= 2 and <= 36"); ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 22:06:08 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 26 Sep 2012 20:06:08 +0000 Subject: [issue11461] Reading UTF-16 with codecs.readline() breaks on surrogate pairs In-Reply-To: <1299752398.22.0.888282532941.issue11461@psf.upfronthosting.co.za> Message-ID: <1348689968.13.0.825101171699.issue11461@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- versions: +Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 22:07:36 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 26 Sep 2012 20:07:36 +0000 Subject: [issue11461] UTF-16 incremental decoder doesn't support partial surrogate pair In-Reply-To: <1299752398.22.0.888282532941.issue11461@psf.upfronthosting.co.za> Message-ID: <1348690056.53.0.836357067782.issue11461@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Reading UTF-16 with codecs.readline() breaks on surrogate pairs -> UTF-16 incremental decoder doesn't support partial surrogate pair _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 22:19:27 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 26 Sep 2012 20:19:27 +0000 Subject: [issue14771] Occasional failure in test_ioctl In-Reply-To: <1336673953.31.0.37144571556.issue14771@psf.upfronthosting.co.za> Message-ID: <1348690767.06.0.596055814093.issue14771@psf.upfronthosting.co.za> Ezio Melotti added the comment: Can you still reproduce this issue? Do you use any specific flag to run the tests? What OS is this? I tried on linux, solaris, and aix with ``./python -m test -F test_ioctl`` for about 1k loops, and couldn't reproduce the issue. ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 22:34:17 2012 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 26 Sep 2012 20:34:17 +0000 Subject: [issue16056] shadowed test names in std lib regression tests Message-ID: <1348691657.67.0.693161474206.issue16056@psf.upfronthosting.co.za> New submission from Xavier de Gaye: The attached script, named find_duplicate_test_names.py, prints duplicate regression test method names in a given directory tree. Running this script on the standard library test suite shows few duplicates, see below. It means that some of those tests are not run while they are probably meant to be. Here is find_duplicate_test_names.py output on the default branch: $ ./python find_duplicate_test_names.py Lib/test Duplicate test method names: Lib/test/test_types.py: .ClassCreationTests.test_new_class_exec_body Lib/test/test_heapq.py: .TestErrorHandling.test_get_only Lib/test/test_complex.py: .ComplexTest.test_truediv Lib/test/test_webbrowser.py: .OperaCommandTest.test_open_new Lib/test/test_dis.py: .DisTests.test_big_linenos Lib/test/test_dis.py: .DisTests.test_dis_object Lib/test/test_import.py: .ImportTests.test_import_name_binding Lib/test/test_email/test_email.py: .TestQuopri.test_encode_one_long_line Lib/test/test_email/test_email.py: .TestLongHeaders.test_splitter_split_on_punctuation_only_if_fws ---------- components: Library (Lib) files: find_duplicate_test_names.py messages: 171361 nosy: xdegaye priority: normal severity: normal status: open title: shadowed test names in std lib regression tests type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file27315/find_duplicate_test_names.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 22:44:50 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 26 Sep 2012 20:44:50 +0000 Subject: [issue16056] shadowed test names in std lib regression tests In-Reply-To: <1348691657.67.0.693161474206.issue16056@psf.upfronthosting.co.za> Message-ID: <1348692290.44.0.482141292967.issue16056@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 22:49:47 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 26 Sep 2012 20:49:47 +0000 Subject: [issue16056] shadowed test names in std lib regression tests In-Reply-To: <1348691657.67.0.693161474206.issue16056@psf.upfronthosting.co.za> Message-ID: <1348692587.53.0.840874201753.issue16056@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks a lot for the report. Does the 2.7 branch have similar instances? ---------- nosy: +ezio.melotti, michael.foord, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 26 23:40:43 2012 From: report at bugs.python.org (Justin Lebar) Date: Wed, 26 Sep 2012 21:40:43 +0000 Subject: [issue16057] Subclasses of JSONEncoder should not be insturcted to call JSONEncoder.decode Message-ID: <1348695643.05.0.172807817425.issue16057@psf.upfronthosting.co.za> New submission from Justin Lebar: The JSONEncoder documentation says we can implement our own encoder as: >>> class ComplexEncoder(json.JSONEncoder): ... def default(self, obj): ... if isinstance(obj, complex): ... return [obj.real, obj.imag] ... return json.JSONEncoder.default(self, obj) Later on, we give the following example of how to implement the default method in a subclass of json.JSONEncoder: def default(self, o): try: iterable = iter(o) except TypeError: pass else: return list(iterable) return JSONEncoder.default(self, o) These are both incorrect, as a quick reading of the source will reveal. JSONEncoder.default() throws for all input values. We should s/JSONEncoder.default/JSONEncoder.encode/ here, I think. ---------- assignee: docs at python components: Documentation messages: 171363 nosy: Justin.Lebar, docs at python priority: normal severity: normal status: open title: Subclasses of JSONEncoder should not be insturcted to call JSONEncoder.decode versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 02:18:53 2012 From: report at bugs.python.org (Robert Collins) Date: Thu, 27 Sep 2012 00:18:53 +0000 Subject: [issue16058] ConfigParser no longer deepcopy compatible in 2.7 Message-ID: <1348705133.3.0.138375656992.issue16058@psf.upfronthosting.co.za> New submission from Robert Collins: In 2.6 deepcopy(ConfigParser) worked, in 2.7 it doesn't due to the _optcre variable which is a compiled regex pattern. ---------- components: Library (Lib) messages: 171364 nosy: rbcollins priority: normal severity: normal status: open title: ConfigParser no longer deepcopy compatible in 2.7 versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 05:53:50 2012 From: report at bugs.python.org (Omanand Jha Vatsa) Date: Thu, 27 Sep 2012 03:53:50 +0000 Subject: [issue16032] IDLE 3.2 is crashing multiple times In-Reply-To: <1348544697.27.0.843034170589.issue16032@psf.upfronthosting.co.za> Message-ID: <1348718030.77.0.403862406414.issue16032@psf.upfronthosting.co.za> Omanand Jha Vatsa added the comment: Thanks Ned. It is working for me now. Followed your steps to verify the version. Thanks again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 05:54:24 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 27 Sep 2012 03:54:24 +0000 Subject: [issue16036] simplify int() signature docs In-Reply-To: <1348568310.1.0.968219969881.issue16036@psf.upfronthosting.co.za> Message-ID: <1348718064.39.0.801193157307.issue16036@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Ezio, do you want to commit this or should I? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 05:54:42 2012 From: report at bugs.python.org (Ned Deily) Date: Thu, 27 Sep 2012 03:54:42 +0000 Subject: [issue16032] IDLE 3.2 is crashing multiple times In-Reply-To: <1348544697.27.0.843034170589.issue16032@psf.upfronthosting.co.za> Message-ID: <1348718082.43.0.29389002985.issue16032@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 06:32:17 2012 From: report at bugs.python.org (Chris Rebert) Date: Thu, 27 Sep 2012 04:32:17 +0000 Subject: [issue16048] Tutorial-classes-remarks: replace paragragh In-Reply-To: <1348603562.92.0.789475109772.issue16048@psf.upfronthosting.co.za> Message-ID: <1348720337.06.0.620715793494.issue16048@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 06:37:07 2012 From: report at bugs.python.org (Ye Yuan) Date: Thu, 27 Sep 2012 04:37:07 +0000 Subject: [issue16059] Serialize MD5 computation-state and resume later Message-ID: <1348720627.28.0.14858065839.issue16059@psf.upfronthosting.co.za> New submission from Ye Yuan: Serialize/deserialize md5 context. Pseudocode: import md5 # Start hash generation m = md5.new() m.update("Content") # Serialize m serialized_m = serialize(m) # In another function/machine, deserialize m # and continue hash generation m2 = deserialize(serialized_m) m2.update("More content") m2.digest() There are C++ lib but no Python one. ---------- components: Library (Lib) messages: 171367 nosy: Ye.Yuan priority: normal severity: normal status: open title: Serialize MD5 computation-state and resume later type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 09:57:12 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 27 Sep 2012 07:57:12 +0000 Subject: [issue16045] add more unit tests for built-in int() In-Reply-To: <1348579722.08.0.96812684384.issue16045@psf.upfronthosting.co.za> Message-ID: <1348732632.02.0.334117642697.issue16045@psf.upfronthosting.co.za> Chris Jerdonek added the comment: >From http://bugs.python.org/review/16036/ for issue 16036: > Somewhere should be exposed that x must be str, bytes, bytearray or a subclass. We can add tests for this, too (if not already there). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 10:01:01 2012 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 27 Sep 2012 08:01:01 +0000 Subject: [issue16056] shadowed test names in std lib regression tests In-Reply-To: <1348691657.67.0.693161474206.issue16056@psf.upfronthosting.co.za> Message-ID: <1348732861.21.0.862969530488.issue16056@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Running find_duplicate_test_names.py (after changing the print statements) on the 2.7 branch, gives the following output: $ ./python find_duplicate_test_names.py Lib/test/ Duplicate test method names: Lib/test/test_unicode.py: .UnicodeTest.test_capitalize Lib/test/test_iter.py: .TestCase.test_unicode_join_endcase The duplicate in Lib/test/test_iter.py is defined on purpose. ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 10:04:44 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 27 Sep 2012 08:04:44 +0000 Subject: [issue16056] shadowed test names in std lib regression tests In-Reply-To: <1348691657.67.0.693161474206.issue16056@psf.upfronthosting.co.za> Message-ID: <1348733084.59.0.796625588053.issue16056@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- stage: -> needs patch versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 10:39:13 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 27 Sep 2012 08:39:13 +0000 Subject: [issue16056] shadowed test names in std lib regression tests In-Reply-To: <1348691657.67.0.693161474206.issue16056@psf.upfronthosting.co.za> Message-ID: <1348735153.69.0.656627436315.issue16056@psf.upfronthosting.co.za> Ezio Melotti added the comment: The script could be actually be added somewhere (e.g. Tools/scripts) and run as part of `make patchcheck` on the test files that got changed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 10:46:58 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 27 Sep 2012 08:46:58 +0000 Subject: [issue16060] Double decref and dereferencing after decref in int() Message-ID: <1348735618.32.0.1069610095.issue16060@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: In function convert_integral_to_int() in file Objects/abstract.c integral double decrefed and dereferenced after decrefing if returned value of __int__() is not int. Python 3.3 only affected. Here is a patch. ---------- components: Interpreter Core files: float2int_dbl_decref.patch keywords: patch messages: 171371 nosy: benjamin.peterson, storchaka priority: normal severity: normal status: open title: Double decref and dereferencing after decref in int() type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file27316/float2int_dbl_decref.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 10:48:46 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 27 Sep 2012 08:48:46 +0000 Subject: [issue16046] python -O does not find *.pyo files In-Reply-To: <1348581725.98.0.841014002753.issue16046@psf.upfronthosting.co.za> Message-ID: <1348735726.92.0.810004034706.issue16046@psf.upfronthosting.co.za> STINNER Victor added the comment: It would be nice to have a test. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 15:29:41 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 27 Sep 2012 13:29:41 +0000 Subject: [issue11461] UTF-16 incremental decoder doesn't support partial surrogate pair In-Reply-To: <1299752398.22.0.888282532941.issue11461@psf.upfronthosting.co.za> Message-ID: <1348752581.38.0.912975478834.issue11461@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In issue14624 utf-16 decoder has been significantly reworked. Here is adapted for 3.3 patch. ---------- keywords: +needs review nosy: +storchaka Added file: http://bugs.python.org/file27317/partial_utf16-3.3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 15:37:56 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 27 Sep 2012 13:37:56 +0000 Subject: [issue16059] Serialize MD5 computation-state and resume later In-Reply-To: <1348720627.28.0.14858065839.issue16059@psf.upfronthosting.co.za> Message-ID: <1348753076.19.0.306322937292.issue16059@psf.upfronthosting.co.za> R. David Murray added the comment: In the python context I believe what you are asking for is to make hashlib hash objects pickleable. ---------- nosy: +r.david.murray versions: +Python 3.4 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 16:16:18 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 27 Sep 2012 14:16:18 +0000 Subject: [issue8425] a -= b should be fast if a is a small set and b is a large set In-Reply-To: <1348601300.97.0.741657786048.issue8425@psf.upfronthosting.co.za> Message-ID: <201209271715.57399.storchaka@gmail.com> Serhiy Storchaka added the comment: > I find my first patch more readable and efficient, but if these comments > are conformant to pep7.. Attaching updated patch (issue8425.3.patch) It was only a suggestion. Both forms are good enougth. > Yes, but bench.py is available, fell free to run it with whatever > configuration; my example was done with a --with-pydebug and clang > compiler. Yes, I ran it in release mode (gcc, 32-bit Linux) and confirm your results. In general except minor whitespace defects last patch LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 17:33:54 2012 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 27 Sep 2012 15:33:54 +0000 Subject: [issue16060] Double decref and dereferencing after decref in int() In-Reply-To: <1348735618.32.0.1069610095.issue16060@psf.upfronthosting.co.za> Message-ID: <1348760034.42.0.952860354689.issue16060@psf.upfronthosting.co.za> Mark Dickinson added the comment: Nice catch! And indeed, the following code generates a segfault on my machine: class B(object): def __int__(self): return 43.0 class A(object): def __trunc__(self): return B() int(A()) The patch should probably include a regression test. ---------- nosy: +mark.dickinson priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 17:50:23 2012 From: report at bugs.python.org (ABR) Date: Thu, 27 Sep 2012 15:50:23 +0000 Subject: [issue5542] Socket is closed prematurely in httplib, if server sends response before request body has been sent In-Reply-To: <1237800550.85.0.782891199129.issue5542@psf.upfronthosting.co.za> Message-ID: <1348761023.09.0.762575568693.issue5542@psf.upfronthosting.co.za> ABR added the comment: I can report that this occurs on Python 2.7.3, when using urllib[x] wrapped in 'requests'. Trying to access a site using basic auth over https will not work with certain servers, whereas it will work over plain http. I tried searching to see if a corresponding https issue exists, but this came up instead. :-) ---------- nosy: +ABR _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 18:03:07 2012 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 27 Sep 2012 16:03:07 +0000 Subject: [issue16061] performance regression in string replace for 3.3 Message-ID: <1348761787.62.0.977797373088.issue16061@psf.upfronthosting.co.za> New submission from Mark Lawrence: Quoting Steven D'Aprano on c.l.p. "But add a call to replace, and things are very different: [steve at ando ~]$ python2.7 -m timeit -s "s = 'b'*1000" "s.replace('b', 'a')" 100000 loops, best of 3: 9.3 usec per loop [steve at ando ~]$ python3.2 -m timeit -s "s = 'b'*1000" "s.replace('b', 'a')" 100000 loops, best of 3: 5.43 usec per loop [steve at ando ~]$ python3.3 -m timeit -s "s = 'b'*1000" "s.replace('b', 'a')" 100000 loops, best of 3: 18.3 usec per loop Three times slower, even for pure-ASCII strings. I get comparable results for Unicode. Notice how slow Python 2.7 is: [steve at ando ~]$ python2.7 -m timeit -s "s = u'?'*1000" "s.replace(u'?', u'a')" 10000 loops, best of 3: 65.6 usec per loop [steve at ando ~]$ python3.2 -m timeit -s "s = '?'*1000" "s.replace('?', 'a')" 100000 loops, best of 3: 2.79 usec per loop [steve at ando ~]$ python3.3 -m timeit -s "s = '?'*1000" "s.replace('?', 'a')" 10000 loops, best of 3: 23.7 usec per loop Even with the performance regression, it is still over twice as fast as Python 2.7. Nevertheless, I think there is something here. The consequences are nowhere near as dramatic as jmf claims, but it does seem that replace() has taken a serious performance hit. Perhaps it is unavoidable, but perhaps not. If anyone else can confirm similar results, I think this should be raised as a performance regression. Quoting Serhiy Storchaka in response. "Yes, I confirm, it's a performance regression. It should be avoidable. Almost any PEP393 performance regression can be avoided. At least for such corner case. Just no one has yet optimized this case." ---------- messages: 171378 nosy: BreamoreBoy priority: normal severity: normal status: open title: performance regression in string replace for 3.3 type: performance versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 18:08:14 2012 From: report at bugs.python.org (ABR) Date: Thu, 27 Sep 2012 16:08:14 +0000 Subject: [issue16062] Socket closed prematurely in httplib for https Message-ID: <1348762094.47.0.227336838763.issue16062@psf.upfronthosting.co.za> New submission from ABR: When attempting to use basic auth over https with a server that sends 401 and closes the connection as soon as the headers missing auth are received, the process aborts with a broken pipe when (presumably) trying to send the POST body. session = requests.session(auth=(USER, PASSWORD), verify=False) resp = session.post('https://foo.com/something') --> requests.exceptions.ConnectionError: [Errno 32] Broken pipe ---------- components: Library (Lib) messages: 171379 nosy: ABR priority: normal severity: normal status: open title: Socket closed prematurely in httplib for https type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 18:48:13 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 27 Sep 2012 16:48:13 +0000 Subject: [issue16060] Double decref and dereferencing after decref in int() In-Reply-To: <1348735618.32.0.1069610095.issue16060@psf.upfronthosting.co.za> Message-ID: <1348764493.72.0.188335941104.issue16060@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > And indeed, the following code generates a segfault on my machine: I was going to give similar example and assign crash type to issue, but on my machine it does not generate a segfault. > The patch should probably include a regression test. Someone borrowed Guido's time machine and have already done this test (see NonIntegral in Lib/test/test_int.py). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 18:52:48 2012 From: report at bugs.python.org (Alexander L. Belikoff) Date: Thu, 27 Sep 2012 16:52:48 +0000 Subject: [issue10217] python-2.7.amd64.msi install fails In-Reply-To: <1288234706.92.0.436900381953.issue10217@psf.upfronthosting.co.za> Message-ID: <1348764768.71.0.937241437905.issue10217@psf.upfronthosting.co.za> Alexander L. Belikoff added the comment: Same problem for Python 3.2.3. Log file for failed installation attached. ---------- nosy: +abelikoff versions: +Python 3.2 -Python 2.7 Added file: http://bugs.python.org/file27318/python.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 19:02:51 2012 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 27 Sep 2012 17:02:51 +0000 Subject: [issue16060] Double decref and dereferencing after decref in int() In-Reply-To: <1348735618.32.0.1069610095.issue16060@psf.upfronthosting.co.za> Message-ID: <1348765371.74.0.736881704812.issue16060@psf.upfronthosting.co.za> Mark Dickinson added the comment: That test doesn't look quite the same, though: the return value of __trunc__ is an object that has __trunc__ rather than __int__. And all the existing tests pass on my machine without issues. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 19:08:47 2012 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 27 Sep 2012 17:08:47 +0000 Subject: [issue16060] Double decref and dereferencing after decref in int() In-Reply-To: <1348735618.32.0.1069610095.issue16060@psf.upfronthosting.co.za> Message-ID: <1348765727.56.0.779340854854.issue16060@psf.upfronthosting.co.za> Mark Dickinson added the comment: Here's patch that adds a regression test. ---------- Added file: http://bugs.python.org/file27319/float2int_dbl_decref_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 19:21:13 2012 From: report at bugs.python.org (Adam Glenn) Date: Thu, 27 Sep 2012 17:21:13 +0000 Subject: [issue16063] HMAC trans_5C is a string, causing a TypeError Message-ID: <1348766473.89.0.982631739774.issue16063@psf.upfronthosting.co.za> New submission from Adam Glenn: When passing 2 unicode objects to hmac.new() I'm getting "TypeError: character mapping must return integer, None or unicode" I've tried this using hashlib.sha1 and hashlib.md5 and the behavior is the same. What I think is happening is that the trans_5C join at the top of this module is a string so it's causing the type error when I try to generate the new hmac object at line 72. ---------- components: None messages: 171384 nosy: Adam.Glenn priority: normal severity: normal status: open title: HMAC trans_5C is a string, causing a TypeError type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 19:29:42 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 27 Sep 2012 17:29:42 +0000 Subject: [issue16060] Double decref and dereferencing after decref in int() In-Reply-To: <1348735618.32.0.1069610095.issue16060@psf.upfronthosting.co.za> Message-ID: <1348766982.57.0.946236263256.issue16060@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ah, it generates a segfault in debug mode. LGTM. ---------- type: behavior -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 19:33:47 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 27 Sep 2012 17:33:47 +0000 Subject: [issue16061] performance regression in string replace for 3.3 In-Reply-To: <1348761787.62.0.977797373088.issue16061@psf.upfronthosting.co.za> Message-ID: <1348767227.75.0.575799494544.issue16061@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Interpreter Core nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 20:39:18 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 27 Sep 2012 18:39:18 +0000 Subject: [issue16060] Double decref and dereferencing after decref in int() In-Reply-To: <1348735618.32.0.1069610095.issue16060@psf.upfronthosting.co.za> Message-ID: <3XSPts2PdbzR5W@mail.python.org> Roundup Robot added the comment: New changeset 690287f8ea95 by Mark Dickinson in branch 'default': Issue #16060: Fix a double DECREF in int() implementation. Thanks Serhiy Storchaka. http://hg.python.org/cpython/rev/690287f8ea95 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 20:41:20 2012 From: report at bugs.python.org (Larry Hastings) Date: Thu, 27 Sep 2012 18:41:20 +0000 Subject: [issue16064] unittest -m claims executable is "python", not "python3" Message-ID: <1348771280.27.0.553005427274.issue16064@psf.upfronthosting.co.za> New submission from Larry Hastings: I wrote the following script called "bonkers.py": -- import sys print(sys.argv[0]) -- then ran % python3 -m unittest bonkers It printed -- ['python -m unittest', 'bonkers'] -- Shouldn't it say "python3", not "python"? Maybe it should use sys.executable? (Though that gets tricky if there are spaces in the filename.) ---------- assignee: michael.foord components: Library (Lib) messages: 171387 nosy: larry, michael.foord priority: normal severity: normal stage: needs patch status: open title: unittest -m claims executable is "python", not "python3" type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 20:43:07 2012 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 27 Sep 2012 18:43:07 +0000 Subject: [issue16060] Double decref and dereferencing after decref in int() In-Reply-To: <1348735618.32.0.1069610095.issue16060@psf.upfronthosting.co.za> Message-ID: <1348771387.44.0.781451220657.issue16060@psf.upfronthosting.co.za> Mark Dickinson added the comment: Applied. Thanks! I'm not sure whether this is worthy of inclusion in Python 3.3.0; on one hand, it's a segfault from core Python. On the other, it doesn't look that easy to trigger by accident. On balance, I'd say it's safe to wait for Python 3.3.1 for this. Adding Georg to the nosy in case he disagrees. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 20:51:52 2012 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 27 Sep 2012 18:51:52 +0000 Subject: [issue16060] Double decref and dereferencing after decref in int() In-Reply-To: <1348735618.32.0.1069610095.issue16060@psf.upfronthosting.co.za> Message-ID: <1348771911.99.0.0764830696625.issue16060@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- assignee: -> mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 20:56:21 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 27 Sep 2012 18:56:21 +0000 Subject: [issue16061] performance regression in string replace for 3.3 In-Reply-To: <1348761787.62.0.977797373088.issue16061@psf.upfronthosting.co.za> Message-ID: <1348772181.38.0.755028732848.issue16061@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- components: +Unicode nosy: +ezio.melotti, haypo stage: -> needs patch versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 20:57:21 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 27 Sep 2012 18:57:21 +0000 Subject: [issue16057] Subclasses of JSONEncoder should not be insturcted to call JSONEncoder.decode In-Reply-To: <1348695643.05.0.172807817425.issue16057@psf.upfronthosting.co.za> Message-ID: <1348772241.5.0.226998573879.issue16057@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti, petri.lehtinen stage: -> needs patch type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 21:15:19 2012 From: report at bugs.python.org (Ron Hubbard) Date: Thu, 27 Sep 2012 19:15:19 +0000 Subject: [issue16065] Python/distutils setup.py: passing --prefix / makes --root ignored Message-ID: <1348773319.59.0.614057803377.issue16065@psf.upfronthosting.co.za> New submission from Ron Hubbard: setup.py loses the DESTDIR aka --root iff "/" is passed as prefix http://seclists.org/nmap-dev/2012/q3/1025 I can reproduce this now, but only with a prefix of "/". For example, this works: $ python setup.py install --prefix "/a" --root "/home/david/destdir" copying build/scripts-2.7/ndiff -> /home/david/destdir/a/bin But this doesn't: $ python setup.py install --prefix "/" --root "/home/david/destdir" copying build/scripts-2.7/ndiff -> /bin This looks like a Python/distutils bug. the same seems to happen on python install: when installing python 2.7.2, "2to3", "idle", "pydoc" and "smptd.py" are installed into /bin rather than into the chosen destdir ./python -E ./setup.py install \ --prefix=/ \ --install-scripts=//bin \ --install-platlib=//lib/python2.7/lib-dynload \ --root=//opt/python/ [...] running install running build running build_ext INFO: Can't locate Tcl/Tk libs and/or headers running install_scripts copying build/scripts-2.7/smtpd.py -> /bin copying build/scripts-2.7/idle -> /bin copying build/scripts-2.7/pydoc -> /bin copying build/scripts-2.7/2to3 -> /bin changing mode of /bin/smtpd.py to 755 changing mode of /bin/idle to 755 changing mode of /bin/pydoc to 755 changing mode of /bin/2to3 to 755 running install_egg_info Writing /lib/python2.7/lib-dynload/Python-2.7.2-py2.7.egg-info if test -f //opt/python//bin/python -o -h //opt/python//bin/python; \ then rm -f //opt/python//bin/python; \ else true; \ fi (cd //opt/python//bin; ln python2.7 python) rm -f //opt/python//bin/python-config (cd //opt/python//bin; ln -s python2.7-config python-config) test -d //opt/python//lib/pkgconfig || /bin/install -c -d -m 755 //opt/python//lib/pkgconfig rm -f //opt/python//lib/pkgconfig/python.pc [snip] ---------- components: Build messages: 171389 nosy: arschficker priority: normal severity: normal status: open title: Python/distutils setup.py: passing --prefix / makes --root ignored versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 21:28:04 2012 From: report at bugs.python.org (Ron Hubbard) Date: Thu, 27 Sep 2012 19:28:04 +0000 Subject: [issue16065] Python/distutils setup.py: passing --prefix / makes --root ignored In-Reply-To: <1348773319.59.0.614057803377.issue16065@psf.upfronthosting.co.za> Message-ID: <1348774084.93.0.547104197315.issue16065@psf.upfronthosting.co.za> Changes by Ron Hubbard : ---------- type: -> security _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 21:34:42 2012 From: report at bugs.python.org (Ron Hubbard) Date: Thu, 27 Sep 2012 19:34:42 +0000 Subject: [issue16065] Python/distutils setup.py: passing --prefix / makes --root ignored In-Reply-To: <1348773319.59.0.614057803377.issue16065@psf.upfronthosting.co.za> Message-ID: <1348774482.12.0.162165798013.issue16065@psf.upfronthosting.co.za> Ron Hubbard added the comment: python 2.7.2 installation: CFLAGS="-D_GNU_SOURCE -D_BSD_SOURCE" ./configure -C --prefix="/" || exit 1 make -j9 || exit 1 make DESTDIR="//opt/python" install || exit 1 what python generates out of --install-scripts=//bin \ --install-platlib=//lib/python2.7/lib-dynload \ is both wrong (i.e. the platlib stuff also ignores DESTDIR passed to make) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 21:38:47 2012 From: report at bugs.python.org (Ron Hubbard) Date: Thu, 27 Sep 2012 19:38:47 +0000 Subject: [issue13028] python wastes linux users time by checking for dylib on each dynamic library load In-Reply-To: <1316717807.43.0.635056141333.issue13028@psf.upfronthosting.co.za> Message-ID: <1348774727.86.0.904972370835.issue13028@psf.upfronthosting.co.za> Changes by Ron Hubbard : ---------- type: -> resource usage _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 22:21:18 2012 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 27 Sep 2012 20:21:18 +0000 Subject: [issue16056] shadowed test names in std lib regression tests In-Reply-To: <1348691657.67.0.693161474206.issue16056@psf.upfronthosting.co.za> Message-ID: <1348777278.24.0.507905104539.issue16056@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The attached patch uses the infrastructure of patchcheck.py and merges the script into patchcheck.py instead of adding a new script. ---------- keywords: +patch Added file: http://bugs.python.org/file27320/duplicate_test_names.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 22:25:53 2012 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 27 Sep 2012 20:25:53 +0000 Subject: [issue16056] shadowed test names in std lib regression tests In-Reply-To: <1348691657.67.0.693161474206.issue16056@psf.upfronthosting.co.za> Message-ID: <1348777553.88.0.376401383932.issue16056@psf.upfronthosting.co.za> Xavier de Gaye added the comment: patchcheck output with the patch applied: $ make patchcheck ./python ./Tools/scripts/patchcheck.py Getting the list of files that have been added/changed ... 1 file Fixing whitespace ... 0 files Fixing C file whitespace ... 0 files Fixing docs whitespace ... 0 files Duplicate test names found in ... 1 file: Lib/test/test_heapq.py: test name 'TestErrorHandling.test_get_only' Docs modified ... NO Misc/ACKS updated ... NO Misc/NEWS updated ... NO configure regenerated ... not needed pyconfig.h.in regenerated ... not needed Did you run the test suite? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 23:25:33 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 27 Sep 2012 21:25:33 +0000 Subject: [issue16036] simplify int() signature docs In-Reply-To: <1348568310.1.0.968219969881.issue16036@psf.upfronthosting.co.za> Message-ID: <1348781133.38.0.68789813977.issue16036@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attaching updated patch that clarifies the accepted non-numeric types as Serhiy suggested on Rietveld. I also made a few other changes like linking to "integer literal" and updating the "base-radix" reference. As I began to suspect, the latter was left over from a prior version of the docs (when the keyword argument was named "radix"): http://hg.python.org/cpython/file/18db8c4d4487/Doc/library/functions.rst#l559 I will commit later today unless there are further suggestions. ---------- Added file: http://bugs.python.org/file27321/issue-16036-4-default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 27 23:50:48 2012 From: report at bugs.python.org (Alexander Martin) Date: Thu, 27 Sep 2012 21:50:48 +0000 Subject: [issue16066] Truncated POST data in CGI script on Windows 7 Message-ID: <1348782648.4.0.8522398728.issue16066@psf.upfronthosting.co.za> New submission from Alexander Martin: POST data is truncated randomly when sent to a python script running on a simple python CGI server on Windows 7 with Python 3.2.3. The same server and script files run successfully on MAC OSX 10.8 with Python 3.2.3. A similar server (adapted for lower Python version) and the same script file do work fine on Windows 7 with Python 2.7.2. Steps to reproduce: Attached zip contains server script, HTML file and Python script, that receives an uploaded file and saves it to disk. Upload an image file and submit the form inside the HTML file to Python script. Repeat form submission multiple times. In more than 50% of test cases, the uploaded file will not be completely available inside the Python script. That means size of the same uploaded file varies with each POST request. Additionally, the Python server will reset the HTTP connection sometimes. ---------- components: Windows files: Truncated_POST_data_in_CGI_script_on_Win7.zip messages: 171394 nosy: Alexander.Martin, brian.curtin, tim.golden priority: normal severity: normal status: open title: Truncated POST data in CGI script on Windows 7 type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file27322/Truncated_POST_data_in_CGI_script_on_Win7.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 00:10:07 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 27 Sep 2012 22:10:07 +0000 Subject: [issue10217] python-2.7.amd64.msi install fails In-Reply-To: <1288234706.92.0.436900381953.issue10217@psf.upfronthosting.co.za> Message-ID: <1348783806.99.0.886012161478.issue10217@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The only trace to a potential error I could find is Assembly Error:The requested operation failed. A system reboot is required to roll back changes made. Assembly Error (sxs): Please look into Component Based Servicing Log located at -134744968ndir\logs\cbs\cbs.log to get more diagnostic information. So if you can find cbs.log on your system, please attach it as well. Please check that it doesn't contain any confidential information before posting it. However, some people reported that this problem actually means that you need to reboot before you can perform the installation (because of a failure to reboot after some prior installation that required reboot). So please also reboot and report whether it solved the problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 00:10:24 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 27 Sep 2012 22:10:24 +0000 Subject: [issue16056] shadowed test names in std lib regression tests In-Reply-To: <1348691657.67.0.693161474206.issue16056@psf.upfronthosting.co.za> Message-ID: <3XSVZR2xHxzR1r@mail.python.org> Roundup Robot added the comment: New changeset e99c0425da59 by Benjamin Peterson in branch 'default': renmae test method to avoid conflict (#16056) http://hg.python.org/cpython/rev/e99c0425da59 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 02:23:48 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 28 Sep 2012 00:23:48 +0000 Subject: [issue16056] shadowed test names in std lib regression tests In-Reply-To: <1348691657.67.0.693161474206.issue16056@psf.upfronthosting.co.za> Message-ID: <1348791828.83.0.465056000381.issue16056@psf.upfronthosting.co.za> Chris Jerdonek added the comment: To simplify and keep the discussions more focused, etc, I would create a new issue for the patch to patchcheck (and mark it "enhancement"). Both issues can still reference each other. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 03:49:50 2012 From: report at bugs.python.org (Edward Brey) Date: Fri, 28 Sep 2012 01:49:50 +0000 Subject: [issue16067] UAC prompt for installation shows temporary file name Message-ID: <1348796990.29.0.204354546612.issue16067@psf.upfronthosting.co.za> New submission from Edward Brey: When installing on Windows, the UAC prompt shows a temporary random file name for the MSI file. To solve this, use the /d switch with signtool when signing the MSI file. Cf. http://stackoverflow.com/q/4315840 ---------- components: Installation messages: 171398 nosy: breyed priority: normal severity: normal status: open title: UAC prompt for installation shows temporary file name type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 05:02:34 2012 From: report at bugs.python.org (Paul Wiseman) Date: Fri, 28 Sep 2012 03:02:34 +0000 Subject: [issue16068] with statement executes type(obj).__exit__ rather than getattr(obj, "__exit__") Message-ID: <1348801354.79.0.991137546164.issue16068@psf.upfronthosting.co.za> New submission from Paul Wiseman: I found this behaviour today and thought it was weird so asked the question on SO here http://stackoverflow.com/questions/12632894/why-doesnt-getattr-work-with-exit/12632972#12632972 basically if I attributes are returned dynamically, they seem to get overlooked by the code that runs the with statements. >>> class FileHolder(object): ... def __init__(self,*args,**kwargs): ... self.f= file(*args,**kwargs) ... def __getattr__(self,item): ... return getattr(self.f,item) ... >>> a= FileHolder("a","w") >>> a.write >>> with a as f: ... print f ... Traceback (most recent call last): File "", line 1, in AttributeError: __exit__ >>> a.__exit__ ---------- components: Library (Lib) messages: 171399 nosy: Paul.Wiseman priority: normal severity: normal status: open title: with statement executes type(obj).__exit__ rather than getattr(obj,"__exit__") type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 05:08:13 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 28 Sep 2012 03:08:13 +0000 Subject: [issue16069] packaging shows up on docs.python.org/dev Message-ID: <1348801693.29.0.778297350134.issue16069@psf.upfronthosting.co.za> New submission from Chris Jerdonek: Date: Tue, 11 Sep 2012 16:20:54 +0200 To: docs at python.org Subject: [docs] packaging documentation should be removed docs.python.org/dev still carries documentation for packaging, despite the package having been removed. http://docs.python.org/dev/library/packaging.html has "3.3.0a4 Documentation" in the footer, so I presume that the page is a leftover. Google returns results which point to the obsolete page, which is misleading. (from http://mail.python.org/pipermail/docs/2012-September/010519.html ) ---------- assignee: docs at python components: Documentation messages: 171400 nosy: chris.jerdonek, docs at python priority: normal severity: normal status: open title: packaging shows up on docs.python.org/dev type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 05:10:23 2012 From: report at bugs.python.org (Paul Wiseman) Date: Fri, 28 Sep 2012 03:10:23 +0000 Subject: [issue16068] with statement executes type(obj).__exit__ rather than getattr(obj, "__exit__") In-Reply-To: <1348801354.79.0.991137546164.issue16068@psf.upfronthosting.co.za> Message-ID: <1348801823.49.0.98478586241.issue16068@psf.upfronthosting.co.za> Paul Wiseman added the comment: I got pointed to an explanation in the docs! http://docs.python.org/reference/datamodel.html#special-method-lookup-for-new-style-classes It was confusing, though :) ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 05:19:04 2012 From: report at bugs.python.org (HCT) Date: Fri, 28 Sep 2012 03:19:04 +0000 Subject: [issue16070] Structure and native Structure (LittleEndianStructure on Windows) supports __slots__, but BigEndianStructure doesn't Message-ID: <1348802344.39.0.86334855376.issue16070@psf.upfronthosting.co.za> New submission from HCT: using official CPython 3.2.3 with a simple demonstration script (attached) to demonstrate inconsistency between ctypes structures from ctypes import * class cbs( BigEndianStructure ): __slots__ = tuple() def __init__( self, *args, **kw ): super().__init__( *args, **kw ) self.a = 11 class cls( LittleEndianStructure ): __slots__ = tuple() def __init__( self, *args, **kw ): super().__init__( *args, **kw ) self.a = 11 class cs( Structure ): __slots__ = tuple() def __init__( self, *args, **kw ): super().__init__( *args, **kw ) self.a = 11 try : cbs1=cbs() except AttributeError as e: print(e) try : cls1=cls() except AttributeError as e: print(e) try : cs=cs() except AttributeError as e: print(e) yields 'cls' object has no attribute 'a' 'cs' object has no attribute 'a' I expect cbs to throw error too, but itwent through the initalization and silently ignored the __slots__ defined in the class ---------- components: ctypes files: slots_test.py messages: 171402 nosy: hct priority: normal severity: normal status: open title: Structure and native Structure (LittleEndianStructure on Windows) supports __slots__, but BigEndianStructure doesn't type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file27323/slots_test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 05:21:28 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 28 Sep 2012 03:21:28 +0000 Subject: [issue16071] fix link to email.message.Message in mailbox docs Message-ID: <1348802488.29.0.674477031086.issue16071@psf.upfronthosting.co.za> New submission from Chris Jerdonek: > Date: Thu, 13 Sep 2012 00:28:20 -0700 > To: docs at python.org > Subject: [docs] Bug in documentation for mailbox module > > I think I may have found a minor bug in the documentation for the > mailbox module, at: > > http://docs.python.org/library/mailbox.html > > Right at the beginning of section 18.4.2. ("Message objects"), when > describing the mailbox.Message class, is the following: > > "A subclass of the email.Message module?s *Message*. Subclasses of > mailbox.Message add mailbox-format-specific state and behavior." > > The word "Message" indicated above with asterisks is a hyperlink to: > > http://docs.python.org/library/mailbox.html#mailbox.Message > > I think it should instead link to: > > http://docs.python.org/library/email.message.html#email.message.Message (from: http://mail.python.org/pipermail/docs/2012-September/010520.html ) ---------- assignee: docs at python components: Documentation keywords: easy messages: 171403 nosy: barry, chris.jerdonek, docs at python, r.david.murray priority: normal severity: normal stage: needs patch status: open title: fix link to email.message.Message in mailbox docs type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 05:28:48 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 28 Sep 2012 03:28:48 +0000 Subject: [issue16072] fix documentation of string.replace() signature Message-ID: <1348802928.91.0.483315900162.issue16072@psf.upfronthosting.co.za> New submission from Chris Jerdonek: > Date: Thu, 13 Sep 2012 09:42:47 -0400 > To: > Subject: [docs] Problem with the documentation for string.replace > > >From http://docs.python.org/library/string.html > > string.replace(str, old, new[, maxreplace])? > Return a copy of string str with all occurrences of substring old replaced by new. If the optional argument maxreplace is given, the first maxreplace occurrences are replaced. > > it would appear this needs to be > string.replace(old, new[, maxreplace])? (from: http://mail.python.org/pipermail/docs/2012-September/010521.html ) ---------- assignee: docs at python components: Documentation keywords: easy messages: 171404 nosy: chris.jerdonek, docs at python priority: normal severity: normal stage: needs patch status: open title: fix documentation of string.replace() signature type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 05:50:24 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 28 Sep 2012 03:50:24 +0000 Subject: [issue16073] fix map() statement in list comprehension example Message-ID: <1348804224.11.0.798375217467.issue16073@psf.upfronthosting.co.za> New submission from Chris Jerdonek: > Date: Thu, 20 Sep 2012 15:14:36 -0400 > To: docs at python.org > Subject: [docs] map objects are not lists > > 5.1.3. List Comprehensions > > List comprehensions provide a concise way to create lists. Common > applications are to make new lists where each element is the result of some > operations applied to each member of another sequence or iterable, or to > create a subsequence of those elements that satisfy a certain condition. > > For example, assume we want to create a list of squares, like: >>>> > >>>> squares = []>>> for x in range(10):... squares.append(x**2)...>>> squares[0, 1, 4, 9, 16, 25, 36, 49, 64, 81] > > We can obtain the same result with: > > squares = [x**2 for x in range(10)] > > This is also equivalent to squares = map(lambda x: x**2, range(10)), but > it?s more concise and readable. > > > I think that the last sentence above should read: > > squares = list(map(lambda x: x**2, range(10))) > > In other words, the map function returns a map object, not a list object, > so the list() function needs to be used to convert it to something that is > truly equivalent to the previous definitions of "squares". (In case it > matters, I am using Python-3.3.0rc2 on RHEL 6.3.) (from http://mail.python.org/pipermail/docs/2012-September/010525.html ) ---------- assignee: docs at python components: Documentation keywords: easy messages: 171405 nosy: chris.jerdonek, docs at python priority: normal severity: normal stage: needs patch status: open title: fix map() statement in list comprehension example type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 08:19:36 2012 From: report at bugs.python.org (Thomas Lee) Date: Fri, 28 Sep 2012 06:19:36 +0000 Subject: [issue13028] python wastes linux users time by checking for dylib on each dynamic library load In-Reply-To: <1316717807.43.0.635056141333.issue13028@psf.upfronthosting.co.za> Message-ID: <1348813176.99.0.185556514024.issue13028@psf.upfronthosting.co.za> Thomas Lee added the comment: I know this is an old-ish issue, but I can't reproduce anything like this on Debian Wheezy with either Python 2.7 or tip (3.x). I think we need more details of what you're trying to do here Roger. 1. What exactly did you do to reproduce the strace output below? 2. What flavor of Linux did you attempt this on? Further, a more detailed description of what you expected to happen vs. what actually happened would be a big help here. As Victor says, .dylib shouldn't appear in strace output on Linux at all (and my testing seems to confirm this). ---------- nosy: +thomaslee _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 08:39:48 2012 From: report at bugs.python.org (Thomas Lee) Date: Fri, 28 Sep 2012 06:39:48 +0000 Subject: [issue16061] performance regression in string replace for 3.3 In-Reply-To: <1348761787.62.0.977797373088.issue16061@psf.upfronthosting.co.za> Message-ID: <1348814388.88.0.637801900455.issue16061@psf.upfronthosting.co.za> Thomas Lee added the comment: My results aren't quite as dramatic as yours, but there does appear to be a regression: $ ./python -V Python 2.7.3+ $ ./python -m timeit -s "s = 'b'*1000" "s.replace('b', 'a')" 100000 loops, best of 3: 16.5 usec per loop $ ./python -V Python 3.3.0rc3+ $ ./python -m timeit -s "s = 'b'*1000" "s.replace('b', 'a')" 10000 loops, best of 3: 22.7 usec per loop ---------- nosy: +thomaslee _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 08:47:35 2012 From: report at bugs.python.org (Thomas Lee) Date: Fri, 28 Sep 2012 06:47:35 +0000 Subject: [issue16062] Socket closed prematurely in httplib for https In-Reply-To: <1348762094.47.0.227336838763.issue16062@psf.upfronthosting.co.za> Message-ID: <1348814855.68.0.711900747769.issue16062@psf.upfronthosting.co.za> Thomas Lee added the comment: Thanks ABR. You may be better off raising a ticket against requests (https://github.com/kennethreitz/requests). I'm assuming what you want to happen here is for the session.post() call to return the 401 response without raising an exception. Perfectly reasonable, but to the best of my knowledge the "requests" library isn't in Python's standard library -- and so this is not the place to get it fixed :) ---------- nosy: +thomaslee _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 08:59:55 2012 From: report at bugs.python.org (Thomas Lee) Date: Fri, 28 Sep 2012 06:59:55 +0000 Subject: [issue14886] json C vs pure-python implementation difference In-Reply-To: <1337765129.86.0.0917200779683.issue14886@psf.upfronthosting.co.za> Message-ID: <1348815595.44.0.174135728914.issue14886@psf.upfronthosting.co.za> Thomas Lee added the comment: FWIW, I think Mark's right here. I'm +1 on the implementations being consistent. Seems like a potentially nasty surprise if you move from one implementation to the other and, lacking awareness of this quirk, design your algorithm around semantics. I think this was Mark's original point. If the json API doesn't care how the type check is performed, then we get a (probably very small :)) win from the type(o) in (list, tuple) for the Python impl in addition to bringing consistency to the two implementations. ---------- nosy: +thomaslee _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 10:13:20 2012 From: report at bugs.python.org (Glenn Linderman) Date: Fri, 28 Sep 2012 08:13:20 +0000 Subject: [issue16074] bad error in rename Message-ID: <1348820000.8.0.496903200143.issue16074@psf.upfronthosting.co.za> New submission from Glenn Linderman: I've been using 3.3.0b1 for development, with mostly no problems, but today I was surprised and confused by an error message. It is an attempt to be an improvement over 3.2, giving the filename that os.rename cannot find... but instead, it gives the one it is renaming to. So I quickly upgraded to 3.3.0rc3, and it contains the same error. ---------- components: Windows files: test93.py messages: 171410 nosy: v+python priority: normal severity: normal status: open title: bad error in rename versions: Python 3.3 Added file: http://bugs.python.org/file27324/test93.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 10:21:09 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 28 Sep 2012 08:21:09 +0000 Subject: [issue16036] simplify int() signature docs In-Reply-To: <1348568310.1.0.968219969881.issue16036@psf.upfronthosting.co.za> Message-ID: <3XSm780mXfzNtM@mail.python.org> Roundup Robot added the comment: New changeset 9205277bc008 by Chris Jerdonek in branch '3.2': Issue #16036: Improve documentation of built-in int()'s signature and arguments. http://hg.python.org/cpython/rev/9205277bc008 New changeset 6ccb04c4cbae by Chris Jerdonek in branch 'default': Issue #16036: Merge update from 3.2. http://hg.python.org/cpython/rev/6ccb04c4cbae ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 10:26:08 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 28 Sep 2012 08:26:08 +0000 Subject: [issue16036] simplify int() signature docs In-Reply-To: <1348568310.1.0.968219969881.issue16036@psf.upfronthosting.co.za> Message-ID: <1348820768.3.0.92695771219.issue16036@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Leaving open until the change is made in 2.7 (the current wording is somewhat different there). I will do that in the next day or so. ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 10:28:01 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 28 Sep 2012 08:28:01 +0000 Subject: [issue16061] performance regression in string replace for 3.3 In-Reply-To: <1348814388.88.0.637801900455.issue16061@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Python 3.3 is 2x faster than Python 3.2 to replace a character with another if the string only contains the character 3 times. This is not acceptable, Python 3.3 must be as slow as Python 3.2! $ python3.2 -m timeit "ch='?'; sp=' '*1000; s = ch+sp+ch+sp+ch; after='?'; s.replace(ch, after)" 100000 loops, best of 3: 3.62 usec per loop $ python3.3 -m timeit "ch='?'; sp=' '*1000; s = ch+sp+ch+sp+ch; after='?'; s.replace(ch, after)" 1000000 loops, best of 3: 1.36 usec per loop $ python3.2 -m timeit "ch='?'; sp=' '*1000; s = ch+sp+ch+sp+ch; after='?'; s.replace(ch, after)" 100000 loops, best of 3: 3.15 usec per loop $ python3.2 -m timeit "ch='?'; sp=' '*1000; s = ch+sp+ch+sp+ch; after='?'; s.replace(ch, after)" 1000000 loops, best of 3: 1.91 usec per loop More seriously, I changed the algorithm of str.replace(before, after) when before and after are only one character: changeset c802bfc8acfc. The code is now using the heavily optimized findchar() function. PyUnicode_READ() is slow and should be avoided when possible: PyUnicode_READ() macro is expanded to 2 if, whereas findchar() uses directly pointer of the right type (Py_UCS1*, Py_UCS2* or Py_UCS4*). In Python 3.2, the code looks like: for (i = 0; i < u->length; i++) { if (u->str[i] == u1) { if (--maxcount < 0) break; u->str[i] = u2; } } In Python 3.3, the code looks like: pos = findchar(sbuf, PyUnicode_KIND(self), slen, u1, 1); if (pos < 0) goto nothing; ... while (--maxcount) { pos++; src += pos * PyUnicode_KIND(self); slen -= pos; index += pos; pos = findchar(src, PyUnicode_KIND(self), slen, u1, 1); if (pos < 0) break; PyUnicode_WRITE(rkind, PyUnicode_DATA(u), index + pos, u2); } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 10:33:11 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 28 Sep 2012 08:33:11 +0000 Subject: [issue16075] incoming.cia hook error when pushing commits Message-ID: <1348821191.61.0.603440976272.issue16075@psf.upfronthosting.co.za> New submission from Chris Jerdonek: When pushing commits to hg.python.org, I got the following error re: the "incoming.cia" hook: $ hg push ssh://hg at hg.python.org/cpython pushing to ssh://hg at hg.python.org/cpython searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 2 changesets with 4 changes to 2 files remote: buildbot: change(s) sent successfully remote: sent email to roundup at report at bugs.python.org remote: notified python-checkins at python.org of incoming changeset 9205277bc008 remote: error: incoming.cia hook raised an exception: remote: notified python-checkins at python.org of incoming changeset 6ccb04c4cbae remote: error: incoming.cia hook raised an exception: ---------- messages: 171414 nosy: chris.jerdonek, georg.brandl, pitrou priority: normal severity: normal status: open title: incoming.cia hook error when pushing commits _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 10:36:15 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 28 Sep 2012 08:36:15 +0000 Subject: [issue16060] Double decref and dereferencing after decref in int() In-Reply-To: <1348735618.32.0.1069610095.issue16060@psf.upfronthosting.co.za> Message-ID: <1348821375.76.0.805396040763.issue16060@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Serhiy, I wonder how you found this :) ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 10:37:37 2012 From: report at bugs.python.org (Georg Brandl) Date: Fri, 28 Sep 2012 08:37:37 +0000 Subject: [issue16075] incoming.cia hook error when pushing commits In-Reply-To: <1348821191.61.0.603440976272.issue16075@psf.upfronthosting.co.za> Message-ID: <1348821457.83.0.466039523709.issue16075@psf.upfronthosting.co.za> Georg Brandl added the comment: Looking at http://cia.vc/, it seems like CIA is dead for now. I've disabled the CIA hook on all hg.p.org repos. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 10:42:54 2012 From: report at bugs.python.org (Alexander Martin) Date: Fri, 28 Sep 2012 08:42:54 +0000 Subject: [issue16066] Truncated POST data in CGI script on Windows 7 In-Reply-To: <1348782648.4.0.8522398728.issue16066@psf.upfronthosting.co.za> Message-ID: <1348821774.52.0.697321563828.issue16066@psf.upfronthosting.co.za> Alexander Martin added the comment: The successful script execution was run under Python 2.7.3 (as of today one of the two as "production version" labeled releases). The initial report's reference to Python 2.7.2 was made by mistake. May anyone confirm this error behaviour on Python production version 3.2.3 on Windows? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 10:51:37 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 28 Sep 2012 08:51:37 +0000 Subject: [issue16001] small ints: cache string representation In-Reply-To: <1348272680.09.0.237238464287.issue16001@psf.upfronthosting.co.za> Message-ID: <1348822297.47.0.949752303482.issue16001@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 10:54:59 2012 From: report at bugs.python.org (=?utf-8?q?Einar_Fl=C3=B8ystad_D=C3=B8rum?=) Date: Fri, 28 Sep 2012 08:54:59 +0000 Subject: [issue16076] xml.etree.ElementTree.Element is no longer pickleable Message-ID: <1348822499.83.0.756048401766.issue16076@psf.upfronthosting.co.za> New submission from Einar Fl?ystad D?rum: The xml.etree.ElementTree.Element class is no longer pickleable in Python 3.3.0rc3 . This is a regression from Python 3.2 where the Element class was pickleable, while the xml.etree.cElementTree.Element was not. So this is probably related to switching the ElementTree implementation in Python 3.3. I've looked at the "what's new" documentation in Python 3.3, and there was nothing that indicated that the ElemenTree switchover would give this kind of issues. I've run into this issues because I use the multiprocessing module to pass parsed XML documents between processes, and when I can't pickle Element objects. This stops working. You can reproduce the issue with the following code: import pickle from xml.etree.ElementTree import Element print(pickle.dumps(Element("foo"))) ---------- components: Library (Lib) messages: 171418 nosy: einarfd priority: normal severity: normal status: open title: xml.etree.ElementTree.Element is no longer pickleable type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 10:55:52 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 28 Sep 2012 08:55:52 +0000 Subject: [issue16077] fix code example in docs for built-in reduce() Message-ID: <1348822552.23.0.324199631114.issue16077@psf.upfronthosting.co.za> New submission from Chris Jerdonek: > Date: Thu, 6 Sep 2012 20:38:21 +0800 > To: docs at python.org > Subject: [docs] There is bug about the built-in function reduce in the > document > > I found a bug in the document about reduce : > http://docs.python.org/library/functions.html#reduce > > Here is the patch: > def reduce(function, iterable, initializer=None): > it = iter(iterable) > if initializer is None: > try: > initializer = next(it) > except StopIteration: > raise TypeError('reduce() of empty sequence with no initial > value') > accum_value = initializer > - for x in iterable: > + for x in it: > accum_value = function(accum_value, x) > return accum_value > > It duplicated the first element of iterable > > For example: > In [4]: reduce(lambda x,y:x+y, [1,2,3,4]) > Out[4]: 10 > > In [5]: docreduce.reduce(lambda x,y:x+y ,[1,2,3,4]) > Out[5]: 11 (from: http://mail.python.org/pipermail/docs/2012-September/010513.html and http://mail.python.org/pipermail/docs/2012-September/010526.html ) ---------- assignee: docs at python components: Documentation keywords: easy messages: 171419 nosy: chris.jerdonek, docs at python priority: normal severity: normal stage: needs patch status: open title: fix code example in docs for built-in reduce() type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 11:09:11 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 28 Sep 2012 09:09:11 +0000 Subject: [issue16064] unittest -m claims executable is "python", not "python3" In-Reply-To: <1348771280.27.0.553005427274.issue16064@psf.upfronthosting.co.za> Message-ID: <1348823351.74.0.167768426012.issue16064@psf.upfronthosting.co.za> Chris Jerdonek added the comment: It looks like the offending line is here: http://hg.python.org/cpython/file/6ccb04c4cbae/Lib/unittest/__main__.py#l5 if sys.argv[0].endswith("__main__.py"): sys.argv[0] = "python -m unittest" ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 11:20:08 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 28 Sep 2012 09:20:08 +0000 Subject: [issue16064] unittest -m claims executable is "python", not "python3" In-Reply-To: <1348771280.27.0.553005427274.issue16064@psf.upfronthosting.co.za> Message-ID: <1348824008.33.0.168435647959.issue16064@psf.upfronthosting.co.za> Larry Hastings added the comment: Certainly. But what is the right thing to do? I talked to Michael about it in person this morning, and our consensus was: use basename of sys.executable. Patch attached. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file27325/larry.unittest.argv0.1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 11:24:33 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 28 Sep 2012 09:24:33 +0000 Subject: [issue16050] ctypes: callback from C++ to Python fails with Illegal Instruction call In-Reply-To: <1348618955.55.0.49066087682.issue16050@psf.upfronthosting.co.za> Message-ID: <1348824273.87.0.312310691921.issue16050@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Pavel, I think the FFI we use is a direct copy of libffi. Could you contact upstream?. ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 11:29:52 2012 From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=) Date: Fri, 28 Sep 2012 09:29:52 +0000 Subject: [issue14679] Define an __all__ for html.parser In-Reply-To: <1335470773.41.0.349037543033.issue14679@psf.upfronthosting.co.za> Message-ID: <1348824592.78.0.0351081550587.issue14679@psf.upfronthosting.co.za> Michele Orr? added the comment: "# Internal" appears only in HTMLParser's methods; how could __all__ fix this? ---------- nosy: +maker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 11:38:00 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 28 Sep 2012 09:38:00 +0000 Subject: [issue16060] Double decref and dereferencing after decref in int() In-Reply-To: <1348821375.76.0.805396040763.issue16060@psf.upfronthosting.co.za> Message-ID: <201209281237.44144.storchaka@gmail.com> Serhiy Storchaka added the comment: > Serhiy, I wonder how you found this :) I just looked at the code for issue16036. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 11:51:19 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 28 Sep 2012 09:51:19 +0000 Subject: [issue16077] fix code example in docs for built-in reduce() In-Reply-To: <1348822552.23.0.324199631114.issue16077@psf.upfronthosting.co.za> Message-ID: <1348825879.13.0.0533614989282.issue16077@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Indeed. Will probably want to add an example with 1-element sequence for functools.reduce in Doc/howto/functional.rst. ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 11:58:32 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 28 Sep 2012 09:58:32 +0000 Subject: [issue16076] xml.etree.ElementTree.Element is no longer pickleable In-Reply-To: <1348822499.83.0.756048401766.issue16076@psf.upfronthosting.co.za> Message-ID: <1348826312.26.0.854103876305.issue16076@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +XML keywords: +3.3regression _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 11:59:15 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 28 Sep 2012 09:59:15 +0000 Subject: [issue16076] xml.etree.ElementTree.Element is no longer pickleable In-Reply-To: <1348822499.83.0.756048401766.issue16076@psf.upfronthosting.co.za> Message-ID: <1348826355.72.0.813699737409.issue16076@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +eli.bendersky, storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 12:02:32 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 28 Sep 2012 10:02:32 +0000 Subject: [issue15953] Incorrect some fields declaration in the PyTypeObject documentation In-Reply-To: <1347873224.57.0.93636410461.issue15953@psf.upfronthosting.co.za> Message-ID: <1348826552.38.0.743227409404.issue15953@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 12:11:15 2012 From: report at bugs.python.org (Sasa Banjac) Date: Fri, 28 Sep 2012 10:11:15 +0000 Subject: [issue16078] Calendar.leapdays(y1,y2) bug Message-ID: <1348827075.77.0.28788504227.issue16078@psf.upfronthosting.co.za> New submission from Sasa Banjac: Hello! I am using the calendar.leapdays(y1,y2) function. It should return the number of leap years betwwen y1 and y2 (exclusive). However the function still cant process mutliple centuries. Example: between 1900 and 2000 we have 24 leap years: 1904,08,12,16,20,24,28,32,36,40,44,48,52,56,60,64,68,72,76,80,84,88,92,96 leapdays(1900,2000) returns 24 -> OK however leapdays(1899,2000) returns also 24 NOT OK leapdays(1899,2001) returns 25 NOT OK leapdays(1900,2001) returns 25 OK This means that the function has a problem with the lower boundary If I try to calculate the number of leap days in a larger interval of years, the error is considerable: leapdays(1,2001) returns 485 But 485 * 4 = 1940 ---------- components: Library (Lib) messages: 171427 nosy: sbanjac priority: normal severity: normal status: open title: Calendar.leapdays(y1,y2) bug versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 12:15:38 2012 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 28 Sep 2012 10:15:38 +0000 Subject: [issue16079] list duplicate test names with patchcheck Message-ID: <1348827338.06.0.659343787847.issue16079@psf.upfronthosting.co.za> New submission from Xavier de Gaye: See also issue 16056 for the current list of duplicate test names in the std lib. The attached patch improves patchcheck.py to list duplicate test names when running 'make patchcheck'. This patch to the default branch can also be applied asis to the 2.7 branch. An example of patchcheck output with the patch applied: ================== $ make patchcheck ./python ./Tools/scripts/patchcheck.py Getting the list of files that have been added/changed ... 1 file Fixing whitespace ... 0 files Fixing C file whitespace ... 0 files Fixing docs whitespace ... 0 files Duplicate test names ... 1 test: TestErrorHandling.test_get_only in file Lib/test/test_heapq.py Docs modified ... NO Misc/ACKS updated ... NO Misc/NEWS updated ... NO configure regenerated ... not needed pyconfig.h.in regenerated ... not needed Did you run the test suite? ================== ---------- components: Library (Lib) files: duplicate_test_names.patch keywords: patch messages: 171428 nosy: chris.jerdonek, ezio.melotti, xdegaye priority: normal severity: normal status: open title: list duplicate test names with patchcheck type: enhancement versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file27326/duplicate_test_names.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 12:21:27 2012 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 28 Sep 2012 10:21:27 +0000 Subject: [issue16056] shadowed test names in std lib regression tests In-Reply-To: <1348691657.67.0.693161474206.issue16056@psf.upfronthosting.co.za> Message-ID: <1348827687.03.0.200978766524.issue16056@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > To simplify and keep the discussions more focused, etc, I would > create a new issue for the patch to patchcheck New issue 16079 has been created. The proposed patch in the new issue 16079 is slightly improved to produce a cleaner output by printing the number of duplicate tests and not the number of files where there are duplicates. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 12:36:11 2012 From: report at bugs.python.org (Michael Foord) Date: Fri, 28 Sep 2012 10:36:11 +0000 Subject: [issue15280] Don't use builtins as variable names in urllib.request In-Reply-To: <1341675187.35.0.731342856867.issue15280@psf.upfronthosting.co.za> Message-ID: <1348828571.29.0.757107891192.issue15280@psf.upfronthosting.co.za> Michael Foord added the comment: Code cleanups for their own sake sound like a good thing, *iff* the cleanup is worthwhile (for example it makes debugging easier). i.e. the cleanup isn't "gratuitous" but worthwhile. This seems to be the case here and the rejected patch in issue #15137 had other (better) reasons to reject it as it stood. Not accepting cleanups greatly limits the opportunity for our code base to improve. ---------- nosy: +michael.foord status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 12:36:26 2012 From: report at bugs.python.org (=?utf-8?q?Manuel_P=C3=A9gouri=C3=A9-Gonnard?=) Date: Fri, 28 Sep 2012 10:36:26 +0000 Subject: [issue16080] test_decimal causes other tests to fail with LC_ALL=fr_FR Message-ID: <1348828586.78.0.854198311775.issue16080@psf.upfronthosting.co.za> New submission from Manuel P?gouri?-Gonnard: Some tests, namely test_email, test_locale and test_mailbox, normally pass, but fail if both of the following conditions are met: - the local is fr_FR (or probably any other non-C locale) - test_decimal is run before them Steps to repoduce: % LC_ALL=fr_FR ./python -m test test_email test_locale test_mailbox test_decimal [1/4] test_email [2/4] test_locale [3/4] test_mailbox [4/4] test_decimal All 4 tests OK. % LC_ALL=C ./python -m test test_decimal test_email test_locale test_mailbox [1/4] test_decimal [2/4] test_email [3/4] test_locale [4/4] test_mailbox All 4 tests OK. % LC_ALL=fr_FR ./python -m test test_decimal test_email test_locale test_mailbox [1/4] test_decimal [2/4] test_email Warning -- sys.path was modified by test_email test test_email failed -- Traceback (most recent call last): File "/home/mpg/src/cpython/Lib/test/test_email/test_email.py", line 2716, in test_formatdate_usegmt time.strftime('%a, %d %b %Y %H:%M:%S -0000', time.gmtime(now))) AssertionError: 'Fri, 28 Sep 2012 10:05:26 -0000' != 'ven., 28 sept. 2012 10:05:26 -0000' - Fri, 28 Sep 2012 10:05:26 -0000 ? ^^^ ^ + ven., 28 sept. 2012 10:05:26 -0000 ? ^^^^ ^ ++ [3/4/1] test_locale test test_locale failed -- Traceback (most recent call last): File "/home/mpg/src/cpython/Lib/test/test_locale.py", line 246, in test_percent_escape self.assertEqual(locale.format_string('%f%%', 1.0), '%f%%' % 1.0) AssertionError: '1,000000%' != '1.000000%' - 1,000000% ? ^ + 1.000000% ? ^ [4/4/2] test_mailbox test test_mailbox failed -- Traceback (most recent call last): File "/home/mpg/src/cpython/Lib/test/test_mailbox.py", line 1754, in test_mboxmmdf_to_maildir self.assertEqual(msg.get_date(), 0.0) AssertionError: 1348826768.3964105 != 0.0 1 test OK. 3 tests failed: test_email test_locale test_mailbox ---------- components: Tests messages: 171431 nosy: mpg priority: normal severity: normal status: open title: test_decimal causes other tests to fail with LC_ALL=fr_FR versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 12:49:17 2012 From: report at bugs.python.org (Brian Brazil) Date: Fri, 28 Sep 2012 10:49:17 +0000 Subject: [issue16081] Fix compile warnings in thread_pthread.h Message-ID: <1348829357.7.0.760845781586.issue16081@psf.upfronthosting.co.za> New submission from Brian Brazil: Please see attached patch to fix warnings about error being set but not used, I've eliminated error except for the one function that was using it. ---------- components: Interpreter Core files: pthread-warnings.patch keywords: patch messages: 171432 nosy: bbrazil priority: normal severity: normal status: open title: Fix compile warnings in thread_pthread.h type: compile error versions: Python 3.4 Added file: http://bugs.python.org/file27327/pthread-warnings.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 12:50:55 2012 From: report at bugs.python.org (Peter Inglesby) Date: Fri, 28 Sep 2012 10:50:55 +0000 Subject: [issue16078] Calendar.leapdays(y1,y2) bug In-Reply-To: <1348827075.77.0.28788504227.issue16078@psf.upfronthosting.co.za> Message-ID: <1348829455.51.0.983162454988.issue16078@psf.upfronthosting.co.za> Peter Inglesby added the comment: This behaviour is correct. Years divisible by 4 are leap years, except years divisible by 100, except years divisible 400. Source http://en.wikipedia.org/wiki/Leap_year. ---------- nosy: +inglesp _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 12:51:27 2012 From: report at bugs.python.org (=?utf-8?q?Einar_Fl=C3=B8ystad_D=C3=B8rum?=) Date: Fri, 28 Sep 2012 10:51:27 +0000 Subject: [issue16082] xml.etree.ElementTree.tostringlist does conform to it's documentation Message-ID: <1348829487.02.0.837389148596.issue16082@psf.upfronthosting.co.za> New submission from Einar Fl?ystad D?rum: The tostringlist documentation says "Returns a list of (optionally) encoded strings containing the XML data. It does not guarantee any specific sequence, except that "".join(tostringlist(element)) == tostring(element).". But in reality it is possible to get tostringlist to return a string and not a list. The following code will demonstrates problem, by failing with a TypeError: from xml.etree.ElementTree import Element, tostringlist, tostring element = Element("foo") print ("".join(tostringlist(element)) == tostring(element)) ---------- components: XML messages: 171434 nosy: einarfd priority: normal severity: normal status: open title: xml.etree.ElementTree.tostringlist does conform to it's documentation type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 12:52:14 2012 From: report at bugs.python.org (=?utf-8?q?Einar_Fl=C3=B8ystad_D=C3=B8rum?=) Date: Fri, 28 Sep 2012 10:52:14 +0000 Subject: [issue16076] xml.etree.ElementTree.Element is no longer pickleable In-Reply-To: <1348822499.83.0.756048401766.issue16076@psf.upfronthosting.co.za> Message-ID: <1348829534.22.0.930231018181.issue16076@psf.upfronthosting.co.za> Changes by Einar Fl?ystad D?rum : ---------- components: -Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 12:54:02 2012 From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=) Date: Fri, 28 Sep 2012 10:54:02 +0000 Subject: [issue16083] HTTPServer does not correctly handle bad headers Message-ID: <1348829642.54.0.0563748954245.issue16083@psf.upfronthosting.co.za> New submission from Michele Orr?: Sending a "GET /\0" causes a TypeEror to be raised and the connection to be unexpectedly closed. $ python -m SimpleHTTPServer 8000 $ printf "GET /\00" | nc localhost 8000 TypeError: must be encoded string without NULL bytes, not str ---------------------------------------- I think raising a 400 error should be fine. Also, shouldn't the error message contain a repr(string)? [From http://corte.si/posts/code/pathod/pythonservers/index.html] ---------- components: Library (Lib) messages: 171435 nosy: maker priority: normal severity: normal status: open title: HTTPServer does not correctly handle bad headers type: security versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 12:55:31 2012 From: report at bugs.python.org (Peter Inglesby) Date: Fri, 28 Sep 2012 10:55:31 +0000 Subject: [issue16078] Calendar.leapdays(y1,y2) bug In-Reply-To: <1348827075.77.0.28788504227.issue16078@psf.upfronthosting.co.za> Message-ID: <1348829731.37.0.487906348159.issue16078@psf.upfronthosting.co.za> Changes by Peter Inglesby : ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 12:56:32 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 28 Sep 2012 10:56:32 +0000 Subject: [issue16078] Calendar.leapdays(y1,y2) bug In-Reply-To: <1348827075.77.0.28788504227.issue16078@psf.upfronthosting.co.za> Message-ID: <1348829792.34.0.522192685551.issue16078@psf.upfronthosting.co.za> Larry Hastings added the comment: Agreed. Not a bug. Closing the issue. ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 13:17:54 2012 From: report at bugs.python.org (Peter Inglesby) Date: Fri, 28 Sep 2012 11:17:54 +0000 Subject: [issue16055] incorrect error text for int(base=1000, x='1') In-Reply-To: <1348688461.13.0.427927679227.issue16055@psf.upfronthosting.co.za> Message-ID: <1348831074.45.0.790066526689.issue16055@psf.upfronthosting.co.za> Peter Inglesby added the comment: The attached patch updates the error message to: >>> int(base=100, x='123') Traceback (most recent call last): File "", line 1, in ValueError: int() base must be >= 2 and <= 36, or 0 ---------- keywords: +patch nosy: +inglesp Added file: http://bugs.python.org/file27328/issue16055.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 13:18:41 2012 From: report at bugs.python.org (Brian Brazil) Date: Fri, 28 Sep 2012 11:18:41 +0000 Subject: [issue15350] {urllib,urllib.parse}.urlencode.__doc__ is unclear In-Reply-To: <1342263934.43.0.385544849615.issue15350@psf.upfronthosting.co.za> Message-ID: <1348831121.83.0.149552352795.issue15350@psf.upfronthosting.co.za> Brian Brazil added the comment: How does the attached patch look? I also reworded the first line to be a bit clearer, and be under 80 chars. ---------- keywords: +patch nosy: +bbrazil Added file: http://bugs.python.org/file27329/issue15350.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 13:32:01 2012 From: report at bugs.python.org (Michael Foord) Date: Fri, 28 Sep 2012 11:32:01 +0000 Subject: [issue10417] unittest triggers UnicodeEncodeError with non-ASCII character in the docstring of the test function In-Reply-To: <1289739891.46.0.690681439003.issue10417@psf.upfronthosting.co.za> Message-ID: <1348831921.05.0.442870130261.issue10417@psf.upfronthosting.co.za> Michael Foord added the comment: So on OS X (Python 2.7 only) the following still fails: PYTHONIOENCODING=ascii ./python.exe unicodetest.py --verbose ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 13:33:16 2012 From: report at bugs.python.org (Michael Foord) Date: Fri, 28 Sep 2012 11:33:16 +0000 Subject: [issue11798] Test cases not garbage collected after run In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za> Message-ID: <1348831996.79.0.977157983738.issue11798@psf.upfronthosting.co.za> Changes by Michael Foord : ---------- versions: +Python 3.4 -Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 13:34:16 2012 From: report at bugs.python.org (ABR) Date: Fri, 28 Sep 2012 11:34:16 +0000 Subject: [issue16062] Socket closed prematurely in httplib for https In-Reply-To: <1348762094.47.0.227336838763.issue16062@psf.upfronthosting.co.za> Message-ID: <1348832056.79.0.604228597422.issue16062@psf.upfronthosting.co.za> ABR added the comment: If that's where the bug is. I forgot to mention this issue seems identical to 5542 (http://bugs.python.org/issue5542), but for https. The fix there was in the underlying url/httplib. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 13:43:16 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 28 Sep 2012 11:43:16 +0000 Subject: [issue16064] unittest -m claims executable is "python", not "python3" In-Reply-To: <1348771280.27.0.553005427274.issue16064@psf.upfronthosting.co.za> Message-ID: <1348832596.54.0.131656530803.issue16064@psf.upfronthosting.co.za> Chris Jerdonek added the comment: (I was just including the line for the convenience of anyone that might happen to come across the issue. It was not to inform you of course! :) ) FWIW, if you already know from talking to Michael or looking at the code, I think a comment saying why sys.argv[0] is being rewritten in the first place would be useful. For example, is it strictly to have a nicer-looking usage string for --help, or are there other reasons? $ ./python.exe -m unittest --help Usage: python -m unittest [options] ... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 13:45:37 2012 From: report at bugs.python.org (Michael Foord) Date: Fri, 28 Sep 2012 11:45:37 +0000 Subject: [issue16064] unittest -m claims executable is "python", not "python3" In-Reply-To: <1348771280.27.0.553005427274.issue16064@psf.upfronthosting.co.za> Message-ID: <1348832737.3.0.630962973397.issue16064@psf.upfronthosting.co.za> Michael Foord added the comment: Yes it is for nicer help output, and a comment in the code is certainly warranted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 13:45:51 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 28 Sep 2012 11:45:51 +0000 Subject: [issue15144] Possible integer overflow in operations with addresses and sizes. In-Reply-To: <1340395368.97.0.504662983992.issue15144@psf.upfronthosting.co.za> Message-ID: <1348832751.25.0.165178327515.issue15144@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 13:48:44 2012 From: report at bugs.python.org (Brian Brazil) Date: Fri, 28 Sep 2012 11:48:44 +0000 Subject: [issue15677] Gzip/zlib allows for compression level=0 In-Reply-To: <1345062923.32.0.954619584637.issue15677@psf.upfronthosting.co.za> Message-ID: <1348832924.94.0.907470938281.issue15677@psf.upfronthosting.co.za> Brian Brazil added the comment: The attached patch fixes this. ---------- keywords: +patch nosy: +bbrazil Added file: http://bugs.python.org/file27330/issue15677.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 13:49:44 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 28 Sep 2012 11:49:44 +0000 Subject: [issue15992] Strict aliasing violations in Objects/unicodeobject.c In-Reply-To: <1348172219.51.0.84674051024.issue15992@psf.upfronthosting.co.za> Message-ID: <1348832984.75.0.821363178113.issue15992@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 13:59:02 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 28 Sep 2012 11:59:02 +0000 Subject: [issue16055] incorrect error text for int(base=1000, x='1') In-Reply-To: <1348688461.13.0.427927679227.issue16055@psf.upfronthosting.co.za> Message-ID: <1348833542.17.0.925593492784.issue16055@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I should have said that I had started working on this issue. I think failing tests for both messages should accompany the patch (otherwise I would have already submitted a patch). The tricky one is the error message for PyLong_FromString(), which I believe can only be tested from C (e.g. by adding to Modules/_testcapimodule.c). ---------- keywords: -easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 14:06:28 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 28 Sep 2012 12:06:28 +0000 Subject: [issue16082] xml.etree.ElementTree.tostringlist does conform to it's documentation In-Reply-To: <1348829487.02.0.837389148596.issue16082@psf.upfronthosting.co.za> Message-ID: <1348833988.29.0.725715997567.issue16082@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Bug in the documentation, but not in the implementation. See also issue8047 and issue1767933 (changeset 63845:57e631f088d7). ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, eli.bendersky, storchaka versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 14:16:41 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 28 Sep 2012 12:16:41 +0000 Subject: [issue16072] fix documentation of string.replace() signature In-Reply-To: <1348802928.91.0.483315900162.issue16072@psf.upfronthosting.co.za> Message-ID: <1348834601.71.0.812453917803.issue16072@psf.upfronthosting.co.za> Andrew Svetlov added the comment: No it shoudn't. It works exactly as described: Return a copy of string *str* with all occurrences of substring *old* replaced by *new*. If the optional argument *maxreplace* is given, the first *maxreplace* occurrences are replaced. *str* is updated string and it is definitelly required. ---------- nosy: +asvetlov resolution: -> invalid stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 14:24:42 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 28 Sep 2012 12:24:42 +0000 Subject: [issue16072] fix documentation of string.replace() signature In-Reply-To: <1348802928.91.0.483315900162.issue16072@psf.upfronthosting.co.za> Message-ID: <1348835082.31.0.736970373519.issue16072@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks, Andrew. I didn't look closely enough when reading the e-mail or I wouldn't have posted. I had assumed from the e-mail that this was in the string *method* section rather than string module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 14:28:59 2012 From: report at bugs.python.org (Georg Brandl) Date: Fri, 28 Sep 2012 12:28:59 +0000 Subject: [issue9374] urlparse should parse query and fragment for arbitrary schemes In-Reply-To: <1280012321.31.0.791086727515.issue9374@psf.upfronthosting.co.za> Message-ID: <1348835339.05.0.325278239006.issue9374@psf.upfronthosting.co.za> Georg Brandl added the comment: After encountering an instance of people relying on fragment not being parsed for "irc://" URLs, with resulting breakage, I don't think we should change this in point releases. IOW, it's fine for 3.3.0, but not for 2.7.x or 3.2.x. It may be fixing a bug, but the bug is not obvious and the fix is not backward compatible. I therefore suggest to roll back the commits to 3.2 and 2.7. ---------- priority: release blocker -> critical status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 14:37:02 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 28 Sep 2012 12:37:02 +0000 Subject: [issue16072] fix documentation of string.replace() signature In-Reply-To: <1348802928.91.0.483315900162.issue16072@psf.upfronthosting.co.za> Message-ID: <1348835822.48.0.684725096501.issue16072@psf.upfronthosting.co.za> Chris Jerdonek added the comment: [Reopening] It looks like at least *some* change is warranted here. Notice that all the functions document "s" for the string argument but string.replace() documents "str". However, we have (in 2.7): >>> string.replace(str='aab', old='a', new='b') Traceback (most recent call last): File "", line 1, in TypeError: replace() got an unexpected keyword argument 'str' >>> string.replace(s='aab', old='a', new='b') 'bbb' ---------- resolution: invalid -> stage: committed/rejected -> needs patch status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 14:45:26 2012 From: report at bugs.python.org (Christian Heimes) Date: Fri, 28 Sep 2012 12:45:26 +0000 Subject: [issue9650] format codes in time.strptime docstrings In-Reply-To: <1282319380.5.0.724924373031.issue9650@psf.upfronthosting.co.za> Message-ID: <1348836326.8.0.0767805464481.issue9650@psf.upfronthosting.co.za> Christian Heimes added the comment: If we want to archive platform independence from the libc's strftime() and strptime() function and its bugs, we could include our own implementation. Or rather than writing our own code we may be able to include some working and well tested code. BSD's libc contains the functions. Its license should allow the inclusion into Python core. http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdtime/ If you like my idea we should discuss it on python-ideas and start a new tracker entry. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 14:47:25 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 28 Sep 2012 12:47:25 +0000 Subject: [issue9374] urlparse should parse query and fragment for arbitrary schemes In-Reply-To: <1280012321.31.0.791086727515.issue9374@psf.upfronthosting.co.za> Message-ID: <1348836445.36.0.723485245753.issue9374@psf.upfronthosting.co.za> Ezio Melotti added the comment: If there is a list of known protocols that don't use the fragment, can't we include it in urlparse as we already do in Lib/urlparse.py:34? If #channel in irc://example.com/#channel should not be parsed as fragment, then this can be considered as a regression. This doesn't necessary mean that the whole change is a regression though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 14:47:25 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 28 Sep 2012 12:47:25 +0000 Subject: [issue16072] fix documentation of string.replace() signature In-Reply-To: <1348802928.91.0.483315900162.issue16072@psf.upfronthosting.co.za> Message-ID: <1348836445.36.0.323423652228.issue16072@psf.upfronthosting.co.za> Andrew Svetlov added the comment: If you want just to change parameter name in the docs ? I'm ok with that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 14:49:25 2012 From: report at bugs.python.org (Christian Heimes) Date: Fri, 28 Sep 2012 12:49:25 +0000 Subject: [issue15992] Strict aliasing violations in Objects/unicodeobject.c In-Reply-To: <1348172219.51.0.84674051024.issue15992@psf.upfronthosting.co.za> Message-ID: <1348836565.76.0.931041132824.issue15992@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 15:03:17 2012 From: report at bugs.python.org (Peter Inglesby) Date: Fri, 28 Sep 2012 13:03:17 +0000 Subject: [issue16055] incorrect error text for int(base=1000, x='1') In-Reply-To: <1348688461.13.0.427927679227.issue16055@psf.upfronthosting.co.za> Message-ID: <1348837397.11.0.396996959426.issue16055@psf.upfronthosting.co.za> Peter Inglesby added the comment: Ah, sorry about that. Are you happy for me to write the test? Poking around the C API docs suggests that I should call PyErr_Fetch() to get the value of the a raised exception, but I can't see any precedent for this in existing test code. Can you point me to something I could use for inspiration? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 15:13:23 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 28 Sep 2012 13:13:23 +0000 Subject: [issue16064] unittest -m claims executable is "python", not "python3" In-Reply-To: <1348771280.27.0.553005427274.issue16064@psf.upfronthosting.co.za> Message-ID: <1348838003.04.0.998410927758.issue16064@psf.upfronthosting.co.za> Larry Hastings added the comment: Michael, you're the one who came up with the feature. If you write the comment I'll fold it into the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 15:14:19 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 28 Sep 2012 13:14:19 +0000 Subject: [issue12376] unittest.TextTestResult.__init__ does not pass on its init arguments in super call In-Reply-To: <1308591554.84.0.206840920137.issue12376@psf.upfronthosting.co.za> Message-ID: <3XStdP2LfrzN9V@mail.python.org> Roundup Robot added the comment: New changeset 0362d64c783a by Michael Foord in branch '3.2': Closes issue #12376 : Pass on parameters in unittest.TextTestResult.__init__ super call http://hg.python.org/cpython/rev/0362d64c783a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 15:19:46 2012 From: report at bugs.python.org (Christian Heimes) Date: Fri, 28 Sep 2012 13:19:46 +0000 Subject: [issue16083] HTTPServer does not correctly handle bad headers In-Reply-To: <1348829642.54.0.0563748954245.issue16083@psf.upfronthosting.co.za> Message-ID: <1348838386.51.0.869690622458.issue16083@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 15:22:13 2012 From: report at bugs.python.org (Michael Foord) Date: Fri, 28 Sep 2012 13:22:13 +0000 Subject: [issue12376] unittest.TextTestResult.__init__ does not pass on its init arguments in super call In-Reply-To: <1308591554.84.0.206840920137.issue12376@psf.upfronthosting.co.za> Message-ID: <1348838533.11.0.777219106776.issue12376@psf.upfronthosting.co.za> Michael Foord added the comment: Fixed in 2.7, 3.2 and 3.3.1. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 15:24:54 2012 From: report at bugs.python.org (Peter Russell) Date: Fri, 28 Sep 2012 13:24:54 +0000 Subject: [issue15593] urlparse.parse_qs documentation wrong re: urlencode In-Reply-To: <1344455271.07.0.337513141168.issue15593@psf.upfronthosting.co.za> Message-ID: <1348838694.86.0.798404312673.issue15593@psf.upfronthosting.co.za> Peter Russell added the comment: Attached is a patch which adds a reference to the doseq parameter to urlencode to the documentation for parse_qs ---------- keywords: +patch nosy: +qwertyface Added file: http://bugs.python.org/file27331/Issue-15593.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 15:25:23 2012 From: report at bugs.python.org (Michael Foord) Date: Fri, 28 Sep 2012 13:25:23 +0000 Subject: [issue14295] PEP 417: adding mock module In-Reply-To: <1331688038.8.0.131181977771.issue14295@psf.upfronthosting.co.za> Message-ID: <1348838723.05.0.668285214152.issue14295@psf.upfronthosting.co.za> Michael Foord added the comment: unittest.mock addition is complete. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 15:28:52 2012 From: report at bugs.python.org (Peter Inglesby) Date: Fri, 28 Sep 2012 13:28:52 +0000 Subject: [issue16073] fix map() statement in list comprehension example In-Reply-To: <1348804224.11.0.798375217467.issue16073@psf.upfronthosting.co.za> Message-ID: <1348838932.44.0.594898494017.issue16073@psf.upfronthosting.co.za> Peter Inglesby added the comment: Have attached a patch with suggested update. Have also grepped for similar issues elsewhere in documentation, and haven't found anything, but may have missed something. ---------- keywords: +patch nosy: +inglesp Added file: http://bugs.python.org/file27332/issue16073.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 15:29:37 2012 From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=) Date: Fri, 28 Sep 2012 13:29:37 +0000 Subject: [issue16083] HTTPServer does not correctly handle bad headers In-Reply-To: <1348829642.54.0.0563748954245.issue16083@psf.upfronthosting.co.za> Message-ID: <1348838977.26.0.495295653934.issue16083@psf.upfronthosting.co.za> Changes by Michele Orr? : ---------- nosy: +exarkun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 15:31:04 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 28 Sep 2012 13:31:04 +0000 Subject: [issue16055] incorrect error text for int(base=1000, x='1') In-Reply-To: <1348688461.13.0.427927679227.issue16055@psf.upfronthosting.co.za> Message-ID: <1348839064.27.0.220390614501.issue16055@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > Are you happy for me to write the test? I had started working on that, but sure, be my guest. :) You seem to be on the right track. I didn't find precedent nearby either. We basically want a C version of unittest's assertRaisesRegex() (but it can be a straight string match). CHECK_INVALID comes close to that. I would suggest defining a helper function that accepts an exception type and message text, and that clears the current error if it matches. If the error doesn't match, you can restore the existing one with PyErr_Restore(), or else call raiseTestError() if there isn't one (similar to CHECK_INVALID). I was thinking of putting the test right after the call to TESTNAME() in test_long_api(), but maybe you know a better location: http://hg.python.org/cpython/file/default/Modules/_testcapimodule.c#l313 I'll upload what I had for the pure Python failing test since that portion was finished. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 15:31:20 2012 From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=) Date: Fri, 28 Sep 2012 13:31:20 +0000 Subject: [issue16083] HTTPServer does not correctly handle bad headers In-Reply-To: <1348829642.54.0.0563748954245.issue16083@psf.upfronthosting.co.za> Message-ID: <1348839080.95.0.26381004114.issue16083@psf.upfronthosting.co.za> Changes by Michele Orr? : ---------- nosy: -exarkun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 15:35:29 2012 From: report at bugs.python.org (Georg Brandl) Date: Fri, 28 Sep 2012 13:35:29 +0000 Subject: [issue16060] Double decref and dereferencing after decref in int() In-Reply-To: <1348735618.32.0.1069610095.issue16060@psf.upfronthosting.co.za> Message-ID: <1348839329.56.0.976256131405.issue16060@psf.upfronthosting.co.za> Georg Brandl added the comment: Applied: d23eb81bd482. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 15:36:17 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 28 Sep 2012 13:36:17 +0000 Subject: [issue16072] fix documentation of string.replace() signature In-Reply-To: <1348802928.91.0.483315900162.issue16072@psf.upfronthosting.co.za> Message-ID: <1348839377.84.0.487835175959.issue16072@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Fixed in c34a177d1f38 ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 15:37:33 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 28 Sep 2012 13:37:33 +0000 Subject: [issue16055] incorrect error text for int(base=1000, x='1') In-Reply-To: <1348688461.13.0.427927679227.issue16055@psf.upfronthosting.co.za> Message-ID: <1348839453.44.0.219314461421.issue16055@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attaching failing test for pure Python portion. ---------- Added file: http://bugs.python.org/file27333/issue-16055-1-failing-test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 15:39:06 2012 From: report at bugs.python.org (Michael Foord) Date: Fri, 28 Sep 2012 13:39:06 +0000 Subject: [issue15593] urlparse.parse_qs documentation wrong re: urlencode In-Reply-To: <1344455271.07.0.337513141168.issue15593@psf.upfronthosting.co.za> Message-ID: <1348839546.41.0.620270930225.issue15593@psf.upfronthosting.co.za> Michael Foord added the comment: UTF-16 patches are relatively unusual... ---------- nosy: +michael.foord _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 15:40:07 2012 From: report at bugs.python.org (Georg Brandl) Date: Fri, 28 Sep 2012 13:40:07 +0000 Subject: [issue9374] urlparse should parse query and fragment for arbitrary schemes In-Reply-To: <1280012321.31.0.791086727515.issue9374@psf.upfronthosting.co.za> Message-ID: <1348839607.09.0.671118890544.issue9374@psf.upfronthosting.co.za> Georg Brandl added the comment: People make up URL schemes all the time, irc:// is not a special case. This change will mean breakage for them, unwarranted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 15:40:59 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 28 Sep 2012 13:40:59 +0000 Subject: [issue15593] urlparse.parse_qs documentation wrong re: urlencode In-Reply-To: <1344455271.07.0.337513141168.issue15593@psf.upfronthosting.co.za> Message-ID: <3XSvDB4DfFzNpC@mail.python.org> Roundup Robot added the comment: New changeset 8590e9b05069 by Michael Foord in branch 'default': urllib.parse.urlencode doc updarte. http://hg.python.org/cpython/rev/8590e9b05069 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 15:57:27 2012 From: report at bugs.python.org (Tim Golden) Date: Fri, 28 Sep 2012 13:57:27 +0000 Subject: [issue9035] os.path.ismount on windows doesn't support windows mount points In-Reply-To: <1277023751.91.0.438330382261.issue9035@psf.upfronthosting.co.za> Message-ID: <1348840647.98.0.247692309294.issue9035@psf.upfronthosting.co.za> Tim Golden added the comment: Unfortunately this missed the boat for 3.3; I'll target 3.4 when we've got a branch to commit to. ---------- versions: +Python 3.4 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 15:58:47 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 28 Sep 2012 13:58:47 +0000 Subject: [issue16073] fix map() statement in list comprehension example In-Reply-To: <1348804224.11.0.798375217467.issue16073@psf.upfronthosting.co.za> Message-ID: <1348840727.06.0.188505096533.issue16073@psf.upfronthosting.co.za> Chris Jerdonek added the comment: 2.7 is not affected. ---------- assignee: docs at python -> chris.jerdonek versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 16:01:24 2012 From: report at bugs.python.org (Tim Golden) Date: Fri, 28 Sep 2012 14:01:24 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1348840884.36.0.687638516747.issue6839@psf.upfronthosting.co.za> Changes by Tim Golden : ---------- assignee: tim.golden -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 16:05:18 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 28 Sep 2012 14:05:18 +0000 Subject: [issue9374] urlparse should parse query and fragment for arbitrary schemes In-Reply-To: <1280012321.31.0.791086727515.issue9374@psf.upfronthosting.co.za> Message-ID: <1348841118.49.0.505678048924.issue9374@psf.upfronthosting.co.za> ?ric Araujo added the comment: One would hope that people making up URI schemes would follow the generic syntax (and thus irc would be an exception), but as the risk exists I agree we should not break code in bugfix releases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 16:05:27 2012 From: report at bugs.python.org (Arnav Khare) Date: Fri, 28 Sep 2012 14:05:27 +0000 Subject: [issue16064] unittest -m claims executable is "python", not "python3" In-Reply-To: <1348771280.27.0.553005427274.issue16064@psf.upfronthosting.co.za> Message-ID: <1348841127.2.0.922162999844.issue16064@psf.upfronthosting.co.za> Arnav Khare added the comment: Added comment explaining why we alter the executable string. ---------- nosy: +Arnav.Khare Added file: http://bugs.python.org/file27334/arnav.unittest.argv0.1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 16:14:52 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 28 Sep 2012 14:14:52 +0000 Subject: [issue16064] unittest -m claims executable is "python", not "python3" In-Reply-To: <1348771280.27.0.553005427274.issue16064@psf.upfronthosting.co.za> Message-ID: <3XSvzG5SYjzNsr@mail.python.org> Roundup Robot added the comment: New changeset c76f1d78ff78 by Michael Foord in branch 'default': Closes issue 16064. No longer hard code executable name in unittest help output. http://hg.python.org/cpython/rev/c76f1d78ff78 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 16:15:03 2012 From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=) Date: Fri, 28 Sep 2012 14:15:03 +0000 Subject: [issue16083] HTTPServer does not correctly handle bad headers In-Reply-To: <1348829642.54.0.0563748954245.issue16083@psf.upfronthosting.co.za> Message-ID: <1348841703.39.0.297385423449.issue16083@psf.upfronthosting.co.za> Michele Orr? added the comment: Note: on python3, the error is File "/[...]/cpython/Lib/genericpath.py", line 41, in isdir st = os.stat(s) TypeError: embedded NUL character (same exception but different message.) I don't know where to start fixing, because the documentation for os.stat says "Perform the equivalent of a stat() system call on the given path.", which is not exactly the correct behavior in this case. I see that $ printf "/\00" | xargs stat stat()s correctly the root directory, and $ printf "/\00tmp" | xargs stat stat()s still '/'. So, is this a bug of os.stat? Noising some coredevs. ---------- nosy: +eric.araujo, ezio.melotti, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 16:26:09 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 28 Sep 2012 14:26:09 +0000 Subject: [issue16055] incorrect error text for int(base=1000, x='1') In-Reply-To: <1348688461.13.0.427927679227.issue16055@psf.upfronthosting.co.za> Message-ID: <1348842369.81.0.619136608047.issue16055@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > + with self.assertRaises(ValueError) as e: > + int('100', 1) > + self.assertEquals(str(e.exception), > + "int() arg base must be 0 or >= 2 and <= 36") Why not use assertRaisesRegex()? self.assertRaisesRegex(ValueError, r'^int\() arg base must be 0 or >= 2 and <= 36$', int, '100', 1) ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 16:26:10 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 28 Sep 2012 14:26:10 +0000 Subject: [issue16073] fix map() statement in list comprehension example In-Reply-To: <1348804224.11.0.798375217467.issue16073@psf.upfronthosting.co.za> Message-ID: <3XSwDK0gLyzNnl@mail.python.org> Roundup Robot added the comment: New changeset 6c96878eb729 by Chris Jerdonek in branch '3.2': Close issue #16073: fix map() example in list comprehension documentation. http://hg.python.org/cpython/rev/6c96878eb729 New changeset 8a4a88b1e964 by Chris Jerdonek in branch 'default': Close issue #16073: merge fix from 3.2. http://hg.python.org/cpython/rev/8a4a88b1e964 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 16:29:16 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 28 Sep 2012 14:29:16 +0000 Subject: [issue16080] test_decimal causes other tests to fail with LC_ALL=fr_FR In-Reply-To: <1348828586.78.0.854198311775.issue16080@psf.upfronthosting.co.za> Message-ID: <3XSwHq4GlXzNsr@mail.python.org> Roundup Robot added the comment: New changeset 3f5fedb17a78 by Stefan Krah in branch 'default': Issue #16080: Use run_with_locale() decorator to reset the locale properly. http://hg.python.org/cpython/rev/3f5fedb17a78 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 16:30:14 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 28 Sep 2012 14:30:14 +0000 Subject: [issue16073] fix map() statement in list comprehension example In-Reply-To: <1348804224.11.0.798375217467.issue16073@psf.upfronthosting.co.za> Message-ID: <1348842614.8.0.0209868851851.issue16073@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks for helping with the patch and search, Peter. ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 16:32:53 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 28 Sep 2012 14:32:53 +0000 Subject: [issue16080] test_decimal causes other tests to fail with LC_ALL=fr_FR In-Reply-To: <1348828586.78.0.854198311775.issue16080@psf.upfronthosting.co.za> Message-ID: <1348842773.73.0.275347956553.issue16080@psf.upfronthosting.co.za> Stefan Krah added the comment: Thanks for the report. -- The locale wasn't properly reset in test_wide_char_separator_decimal_point(). Should be fixed now. ---------- nosy: +skrah resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 16:35:39 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 28 Sep 2012 14:35:39 +0000 Subject: [issue15953] Incorrect some fields declaration in the PyTypeObject documentation In-Reply-To: <1347873224.57.0.93636410461.issue15953@psf.upfronthosting.co.za> Message-ID: <3XSwRG4qcRzNwK@mail.python.org> Roundup Robot added the comment: New changeset 08aa289a757c by Jesus Cea in branch '2.7': Closes #15953: Incorrect some fields declaration in the PyTypeObject documentation http://hg.python.org/cpython/rev/08aa289a757c New changeset c87ea480ddf3 by Jesus Cea in branch '3.2': Closes #15953: Incorrect some fields declaration in the PyTypeObject documentation http://hg.python.org/cpython/rev/c87ea480ddf3 New changeset 3bb53816f9c5 by Jesus Cea in branch 'default': MERGE: Closes #15953: Incorrect some fields declaration in the PyTypeObject documentation http://hg.python.org/cpython/rev/3bb53816f9c5 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 16:36:46 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 28 Sep 2012 14:36:46 +0000 Subject: [issue15953] Incorrect some fields declaration in the PyTypeObject documentation In-Reply-To: <1347873224.57.0.93636410461.issue15953@psf.upfronthosting.co.za> Message-ID: <1348843006.45.0.867885715307.issue15953@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Thanks!. ---------- nosy: +jcea resolution: fixed -> stage: committed/rejected -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 16:37:24 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 28 Sep 2012 14:37:24 +0000 Subject: [issue15953] Incorrect some fields declaration in the PyTypeObject documentation In-Reply-To: <1347873224.57.0.93636410461.issue15953@psf.upfronthosting.co.za> Message-ID: <1348843044.9.0.261944980306.issue15953@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 16:43:36 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 28 Sep 2012 14:43:36 +0000 Subject: [issue16080] test_decimal causes other tests to fail with LC_ALL=fr_FR In-Reply-To: <1348828586.78.0.854198311775.issue16080@psf.upfronthosting.co.za> Message-ID: <1348843416.4.0.260445982326.issue16080@psf.upfronthosting.co.za> Stefan Krah added the comment: Here we go. The new code fails if ps_AF isn't available. ---------- resolution: fixed -> stage: committed/rejected -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 16:47:22 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 28 Sep 2012 14:47:22 +0000 Subject: [issue15963] Improve ./configure's support for 32/64-bit debug|release|profiled builds w/ vendor (non-gcc) compilers on proprietary UNIX systems (Solaris/HP-UX/AIX et al). In-Reply-To: <1347975635.66.0.0788814924298.issue15963@psf.upfronthosting.co.za> Message-ID: <1348843642.2.0.456367585677.issue15963@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 16:47:32 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 28 Sep 2012 14:47:32 +0000 Subject: [issue16055] incorrect error text for int(base=1000, x='1') In-Reply-To: <1348688461.13.0.427927679227.issue16055@psf.upfronthosting.co.za> Message-ID: <1348843652.92.0.516448544748.issue16055@psf.upfronthosting.co.za> Chris Jerdonek added the comment: It could be done that way. It just seems simpler to me to do a simple string check when regex's aren't necessary. Then you don't have to worry about escaping characters, etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 16:49:42 2012 From: report at bugs.python.org (Peter Russell) Date: Fri, 28 Sep 2012 14:49:42 +0000 Subject: [issue13863] import.c sometimes generates incorrect timestamps on Windows + NTFS In-Reply-To: <1327519681.79.0.252690630069.issue13863@psf.upfronthosting.co.za> Message-ID: <1348843782.1.0.161353509824.issue13863@psf.upfronthosting.co.za> Peter Russell added the comment: I can confirm that the current equivalent to Mark's original test case works as expected on default. I recommend closing this issue. ---------- nosy: +qwertyface _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 17:01:07 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 28 Sep 2012 15:01:07 +0000 Subject: [issue16083] HTTPServer does not correctly handle bad headers In-Reply-To: <1348829642.54.0.0563748954245.issue16083@psf.upfronthosting.co.za> Message-ID: <1348844467.04.0.480208141449.issue16083@psf.upfronthosting.co.za> R. David Murray added the comment: There has been some discussion about what the correct behavior of os.stat is, as well, I think. Alex Gaynor raised a question about testing our behavior when nulls are present. But clearly, if the desired behavior for url processing is different from the actual behavior of os.stat, you need to catch the error and turn it into the correct response. I don't think we can change this aspect of the behavior of os.stat for a bug fix, even if we decide we want to. ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 17:03:39 2012 From: report at bugs.python.org (Georg Brandl) Date: Fri, 28 Sep 2012 15:03:39 +0000 Subject: [issue16069] packaging shows up on docs.python.org/dev In-Reply-To: <1348801693.29.0.778297350134.issue16069@psf.upfronthosting.co.za> Message-ID: <1348844619.91.0.379730384951.issue16069@psf.upfronthosting.co.za> Georg Brandl added the comment: Should be fixed now. The daily builds are just copied over to /dev, so removed pages don't get removed automatically. I could add an "rm -r" to the dailybuild steps, but that would cause a few moments of missing pages for everyone browsing /dev at that moment. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 17:05:15 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 28 Sep 2012 15:05:15 +0000 Subject: [issue15280] Don't use builtins as variable names in urllib.request In-Reply-To: <1341675187.35.0.731342856867.issue15280@psf.upfronthosting.co.za> Message-ID: <1348844715.28.0.741904806793.issue15280@psf.upfronthosting.co.za> ?ric Araujo added the comment: Well, here I don?t see the benefit in avoiding the use of ?file?, given that the builtin of the same name is not needed thanks to the open function (contrary to id, type, str, string and others). If you think our (unwritten?) policy of not doing cleanup-only commits is wrong, you could bring it up on a mailing list (maybe committers to avoid an endless thread). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 17:08:28 2012 From: report at bugs.python.org (Arnav Khare) Date: Fri, 28 Sep 2012 15:08:28 +0000 Subject: [issue15323] Provide target name in output message when Mock.assert_called_once_with fails In-Reply-To: <1341976761.94.0.831856606531.issue15323@psf.upfronthosting.co.za> Message-ID: <1348844908.1.0.511739600112.issue15323@psf.upfronthosting.co.za> Arnav Khare added the comment: Added a test to the patch supplied. ---------- nosy: +Arnav.Khare Added file: http://bugs.python.org/file27335/mock_assert_called_once_with_output_update_including_test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 17:16:36 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 28 Sep 2012 15:16:36 +0000 Subject: [issue15323] Provide target name in output message when Mock.assert_called_once_with fails In-Reply-To: <1341976761.94.0.831856606531.issue15323@psf.upfronthosting.co.za> Message-ID: <3XSxLW54DLzNpb@mail.python.org> Roundup Robot added the comment: New changeset 70d43fedb2d7 by Michael Foord in branch 'default': Closes issue 15323. Improve failure message of Mock.assert_called_once_with http://hg.python.org/cpython/rev/70d43fedb2d7 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 17:17:24 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 28 Sep 2012 15:17:24 +0000 Subject: [issue15821] PyMemoryView_FromBuffer() behavior change (possible regression) In-Reply-To: <1346320388.88.0.494685067241.issue15821@psf.upfronthosting.co.za> Message-ID: <1348845444.96.0.763697976823.issue15821@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 17:19:45 2012 From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=) Date: Fri, 28 Sep 2012 15:19:45 +0000 Subject: [issue16083] HTTPServer does not correctly handle bad headers In-Reply-To: <1348829642.54.0.0563748954245.issue16083@psf.upfronthosting.co.za> Message-ID: <1348845585.66.0.525333343257.issue16083@psf.upfronthosting.co.za> Michele Orr? added the comment: Attaching tests that asserts the issue, and a patch for http.server. Works on tip. Should be ported also to 2.x? Note: that 'f = None' is unnecessary, maybe an isolated commit for that? ---------- keywords: +patch Added file: http://bugs.python.org/file27336/issue16083.tests.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 17:19:56 2012 From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=) Date: Fri, 28 Sep 2012 15:19:56 +0000 Subject: [issue16083] HTTPServer does not correctly handle bad headers In-Reply-To: <1348829642.54.0.0563748954245.issue16083@psf.upfronthosting.co.za> Message-ID: <1348845596.02.0.337734714182.issue16083@psf.upfronthosting.co.za> Changes by Michele Orr? : Added file: http://bugs.python.org/file27337/issue16083.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 17:21:21 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 28 Sep 2012 15:21:21 +0000 Subject: [issue15323] Provide target name in output message when Mock.assert_called_once_with fails In-Reply-To: <1341976761.94.0.831856606531.issue15323@psf.upfronthosting.co.za> Message-ID: <1348845681.22.0.549849956765.issue15323@psf.upfronthosting.co.za> ?ric Araujo added the comment: Cool change. I assume when you use mock.patch as decorator the mock name is set to the mocked object? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 17:25:19 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 28 Sep 2012 15:25:19 +0000 Subject: [issue16080] test_decimal causes other tests to fail with LC_ALL=fr_FR In-Reply-To: <1348828586.78.0.854198311775.issue16080@psf.upfronthosting.co.za> Message-ID: <3XSxXY1kgRzQHq@mail.python.org> Roundup Robot added the comment: New changeset f1094697d7dc by Stefan Krah in branch 'default': Closes #16080: The decorator ignores failed attempts to set the required http://hg.python.org/cpython/rev/f1094697d7dc ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 17:26:09 2012 From: report at bugs.python.org (James Salt) Date: Fri, 28 Sep 2012 15:26:09 +0000 Subject: [issue16026] csv.DictReader argument names documented incorrectly In-Reply-To: <1348505583.77.0.632308357055.issue16026@psf.upfronthosting.co.za> Message-ID: <1348845969.86.0.854517030418.issue16026@psf.upfronthosting.co.za> James Salt added the comment: This diff shows a correction of the documentation to reflect the name for the csv file used in the implementation - this change seemed like the easiest and simplest thing to do and avoids potential backwards incompatibility issues. ---------- nosy: +James.Salt Added file: http://bugs.python.org/file27338/james.salt-corrections_to_documentation_in_csv-01.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 17:27:32 2012 From: report at bugs.python.org (Michael Foord) Date: Fri, 28 Sep 2012 15:27:32 +0000 Subject: [issue15323] Provide target name in output message when Mock.assert_called_once_with fails In-Reply-To: <1341976761.94.0.831856606531.issue15323@psf.upfronthosting.co.za> Message-ID: <1348846052.4.0.049436817118.issue15323@psf.upfronthosting.co.za> Michael Foord added the comment: Eric: yes, patch sets the name on the mock objects it creates. A mock only knows its direct name, not its full 'dotted' name (i.e. a mock knows it is called 'time' but not that it is 'time.time'). It is possible (but harder) to deduce that name (follow the chain of parents), so for the moment this change will do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 17:28:58 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 28 Sep 2012 15:28:58 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1348846138.83.0.139112128151.issue2771@psf.upfronthosting.co.za> Ezio Melotti added the comment: testing irker ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 17:31:21 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 28 Sep 2012 15:31:21 +0000 Subject: [issue16026] csv.DictReader argument names documented incorrectly In-Reply-To: <1348505583.77.0.632308357055.issue16026@psf.upfronthosting.co.za> Message-ID: <1348846281.85.0.0292461879476.issue16026@psf.upfronthosting.co.za> Larry Hastings added the comment: Eric, iirc you're the de facto csv guy? Does this seem reasonable to you? ---------- nosy: +eric.araujo, larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 17:36:11 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 28 Sep 2012 15:36:11 +0000 Subject: [issue16026] csv.DictReader argument names documented incorrectly In-Reply-To: <1348505583.77.0.632308357055.issue16026@psf.upfronthosting.co.za> Message-ID: <1348846571.3.0.545050075485.issue16026@psf.upfronthosting.co.za> ?ric Araujo added the comment: I?m not a dedicated maintainer for csv (for one thing I don?t know C :), I just happen to reply to many bug reports. This doc patch looks good to me. ---------- nosy: +sandro.tosi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 17:47:10 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 28 Sep 2012 15:47:10 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1348847230.5.0.0864920617919.issue2771@psf.upfronthosting.co.za> Ezio Melotti added the comment: Another irker test ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 17:54:38 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 28 Sep 2012 15:54:38 +0000 Subject: [issue16069] packaging shows up on docs.python.org/dev In-Reply-To: <1348801693.29.0.778297350134.issue16069@psf.upfronthosting.co.za> Message-ID: <1348847678.92.0.155300023085.issue16069@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks a lot, Georg. FYI, though, the page linked to in the original e-mail still seems to show up for me: http://docs.python.org/dev/library/packaging.html Is this change something that won't necessarily take effect right away? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 18:12:41 2012 From: report at bugs.python.org (Georg Brandl) Date: Fri, 28 Sep 2012 16:12:41 +0000 Subject: [issue16069] packaging shows up on docs.python.org/dev In-Reply-To: <1348801693.29.0.778297350134.issue16069@psf.upfronthosting.co.za> Message-ID: <1348848761.96.0.118901778005.issue16069@psf.upfronthosting.co.za> Georg Brandl added the comment: Ah yes, I missed those as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 18:19:08 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 28 Sep 2012 16:19:08 +0000 Subject: [issue16079] list duplicate test names with patchcheck In-Reply-To: <1348827338.06.0.659343787847.issue16079@psf.upfronthosting.co.za> Message-ID: <1348849148.06.0.0325591773432.issue16079@psf.upfronthosting.co.za> ?ric Araujo added the comment: Nice feature to do without adding a dependency on a lint tool! ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 18:24:44 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 28 Sep 2012 16:24:44 +0000 Subject: [issue16048] Tutorial-classes-remarks: replace paragragh In-Reply-To: <1348603562.92.0.789475109772.issue16048@psf.upfronthosting.co.za> Message-ID: <1348849484.66.0.923060560282.issue16048@psf.upfronthosting.co.za> ?ric Araujo added the comment: Well there is http://docs.python.org/reference/datamodel.html#special-method-names (even thought we have a lot of evidence people miss that). ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 18:25:14 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 28 Sep 2012 16:25:14 +0000 Subject: [issue16049] Create abstract base classes by inheritance rather than a direct invocation of __metaclass__ In-Reply-To: <1348615231.16.0.514985949274.issue16049@psf.upfronthosting.co.za> Message-ID: <1348849514.08.0.494031771461.issue16049@psf.upfronthosting.co.za> ?ric Araujo added the comment: Agreed. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 18:25:54 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 28 Sep 2012 16:25:54 +0000 Subject: [issue16053] "strict" parameter is not documented in csv module In-Reply-To: <1348655757.15.0.984566805089.issue16053@psf.upfronthosting.co.za> Message-ID: <1348849554.13.0.151915121457.issue16053@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- keywords: +easy stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 18:32:46 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 28 Sep 2012 16:32:46 +0000 Subject: [issue16065] setup.py: passing --prefix=/ makes --root ignored In-Reply-To: <1348773319.59.0.614057803377.issue16065@psf.upfronthosting.co.za> Message-ID: <1348849966.77.0.170497957451.issue16065@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks for the report. This bug was already known, but I haven?t had the time yet to fix it. I?m adding you to the nosy list on the other bug so that you can follow progress and maybe help testing the fix. ---------- assignee: -> eric.araujo components: +Distutils, Distutils2 -Build nosy: +alexis, eric.araujo, tarek resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> make install DESTDIR=/home/blah fails when the prefix specified is / title: Python/distutils setup.py: passing --prefix / makes --root ignored -> setup.py: passing --prefix=/ makes --root ignored type: security -> behavior versions: +3rd party, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 18:33:09 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 28 Sep 2012 16:33:09 +0000 Subject: [issue9674] make install DESTDIR=/home/blah fails when the prefix specified is / In-Reply-To: <1282677588.85.0.771807305266.issue9674@psf.upfronthosting.co.za> Message-ID: <1348849989.34.0.854399423427.issue9674@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +arschficker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 18:43:05 2012 From: report at bugs.python.org (Roger Serwy) Date: Fri, 28 Sep 2012 16:43:05 +0000 Subject: [issue15862] IDLE not working when due to wrong Hard Drive point of os.path.expanduser In-Reply-To: <1346795014.76.0.789021764596.issue15862@psf.upfronthosting.co.za> Message-ID: <1348850585.21.0.460081848617.issue15862@psf.upfronthosting.co.za> Roger Serwy added the comment: With Python 2.7.3 on Win7, I tried the following: C:\Python27>set HOME=H:\ C:\Python27>python -m idlelib.idle I do receive the same warning messages described by Cemal, since I don't have a valid H:\ drive. However, IDLE is responsive. Running IDLE using Lib\idlelib\idle.bat fails, though. Also, launching IDLE from the start menu still works. Cemal, can you confirm this? ---------- status: open -> pending type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 18:50:58 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 28 Sep 2012 16:50:58 +0000 Subject: [issue16055] incorrect error text for int(base=1000, x='1') In-Reply-To: <1348688461.13.0.427927679227.issue16055@psf.upfronthosting.co.za> Message-ID: <1348851058.62.0.0946701551017.issue16055@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Can't you test the PyLong_FromString code path by passing bytes to int()? int(b"42") ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 18:52:06 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 28 Sep 2012 16:52:06 +0000 Subject: [issue16079] list duplicate test names with patchcheck In-Reply-To: <1348827338.06.0.659343787847.issue16079@psf.upfronthosting.co.za> Message-ID: <1348851126.27.0.943013617698.issue16079@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I would like to see this written in a way that would let one run it globally or on a single file independent of a patch (e.g. an independent script from which patchcheck could import certain functions). Or is that what you explicitly didn't want ?ric? :) This would let one do a report or global check as was done for issue 16056. It would also make it a bit easier to check manually that the script is checking for duplicates correctly. Also, some suggestions: +def testmethod_names(code, name=[]): It might be clearer to use the name=None form. + test_files = [fn for fn in python_files if + fn.startswith(os.path.join('Lib', 'test'))] Are you getting the test files in test/ subdirectories of subpackages? I think checking that the file name starts with "test_" might be sufficient to get all test files. + if name[-1].startswith('test_'): I believe 'test' is the prefix that unittest uses. I'm pretty sure we have some tests that don't start with 'test_'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 19:04:47 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 28 Sep 2012 17:04:47 +0000 Subject: [issue16055] incorrect error text for int(base=1000, x='1') In-Reply-To: <1348688461.13.0.427927679227.issue16055@psf.upfronthosting.co.za> Message-ID: <1348851887.04.0.271211851217.issue16055@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Benjamin, unless I'm overlooking something, long_new() does its own check of the base argument before calling PyLong_FromString(): http://hg.python.org/cpython/file/default/Objects/longobject.c#l4251 So long_new() won't let you pass a bad base to PyLong_FromString() (which is one of the code paths to be checked). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 19:06:41 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 28 Sep 2012 17:06:41 +0000 Subject: [issue16026] csv.DictReader argument names documented incorrectly In-Reply-To: <1348505583.77.0.632308357055.issue16026@psf.upfronthosting.co.za> Message-ID: <1348852001.4.0.832338417916.issue16026@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It is not consistent with reader and writer. I propose to close the issue as "won't fix" or change the argument name in the sources. Unfortunately, Python syntax does not allow to specify the positional-only arguments. ---------- keywords: +patch nosy: +storchaka Added file: http://bugs.python.org/file27339/csv_csvfile_arg.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 19:08:47 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 28 Sep 2012 17:08:47 +0000 Subject: [issue16055] incorrect error text for int(base=1000, x='1') In-Reply-To: <1348688461.13.0.427927679227.issue16055@psf.upfronthosting.co.za> Message-ID: <1348852127.59.0.109515710542.issue16055@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Ah, sorry, I misread what you wanted to be testing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 19:31:27 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 28 Sep 2012 17:31:27 +0000 Subject: [issue16079] list duplicate test names with patchcheck In-Reply-To: <1348827338.06.0.659343787847.issue16079@psf.upfronthosting.co.za> Message-ID: <1348853487.23.0.600802110701.issue16079@psf.upfronthosting.co.za> Ezio Melotti added the comment: > I would like to see this written in a way that would let one > run it globally or on a single file independent of a patch +1 It can be added to Tools/scripts and imported by patchcheck. > I'm pretty sure we have some tests that don't start with 'test_'. IIRC those are just test helpers that are not executed directly. OTOH I don't see why looking for test_*, every py file might contain duplicate names so they should all be checked. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 19:35:34 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 28 Sep 2012 17:35:34 +0000 Subject: [issue16026] csv.DictReader argument names documented incorrectly In-Reply-To: <1348505583.77.0.632308357055.issue16026@psf.upfronthosting.co.za> Message-ID: <1348853734.87.0.190803281644.issue16026@psf.upfronthosting.co.za> ?ric Araujo added the comment: I don?t understand the proposal. Changing the code has a high bar; here it would break code without benefit. Fixing the doc so that it reflects the code accurately is a no-cost improvement. (Inconsistency is unfortunate, but we?ll have to live with that.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 19:38:09 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 28 Sep 2012 17:38:09 +0000 Subject: [issue16079] list duplicate test names with patchcheck In-Reply-To: <1348827338.06.0.659343787847.issue16079@psf.upfronthosting.co.za> Message-ID: <1348853889.58.0.194249174776.issue16079@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Here are a couple examples of test method names that don't begin with "test_": def testLoadTk(self): def testLoadTkFailure(self): http://hg.python.org/cpython/file/f1094697d7dc/Lib/tkinter/test/test_tkinter/test_loadtk.py#l9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 19:38:48 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 28 Sep 2012 17:38:48 +0000 Subject: [issue16079] list duplicate test names with patchcheck In-Reply-To: <1348827338.06.0.659343787847.issue16079@psf.upfronthosting.co.za> Message-ID: <1348853928.07.0.632548175348.issue16079@psf.upfronthosting.co.za> ?ric Araujo added the comment: sqlite3 tests use CheckThing style (urgh). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 19:45:48 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 28 Sep 2012 17:45:48 +0000 Subject: [issue16079] list duplicate test names with patchcheck In-Reply-To: <1348827338.06.0.659343787847.issue16079@psf.upfronthosting.co.za> Message-ID: <1348854348.53.0.644472527955.issue16079@psf.upfronthosting.co.za> Ezio Melotti added the comment: > Here are a couple examples of test method names that don't begin with "test_": I thought you were talking about test files. I still don't see why looking for test_* methods, every class might contain duplicate method names, so they should all be checked. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 19:55:54 2012 From: report at bugs.python.org (Kushal Das) Date: Fri, 28 Sep 2012 17:55:54 +0000 Subject: [issue16053] "strict" parameter is not documented in csv module In-Reply-To: <1348655757.15.0.984566805089.issue16053@psf.upfronthosting.co.za> Message-ID: <1348854954.45.0.674131008192.issue16053@psf.upfronthosting.co.za> Kushal Das added the comment: csv.Dialect.strict is now documented. ---------- keywords: +patch nosy: +kushaldas Added file: http://bugs.python.org/file27340/csv_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 20:06:32 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 28 Sep 2012 18:06:32 +0000 Subject: [issue16074] bad error message in os.rename In-Reply-To: <1348820000.8.0.496903200143.issue16074@psf.upfronthosting.co.za> Message-ID: <1348855592.41.0.834889054732.issue16074@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Could you give a specific example of the message you got, why it is wrong, and what you think it should be? Is there any reason to think that this is Windows-specific? ---------- components: +Library (Lib) -Windows nosy: +terry.reedy stage: -> needs patch title: bad error in rename -> bad error message in os.rename type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 20:26:23 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 28 Sep 2012 18:26:23 +0000 Subject: [issue16026] csv.DictReader argument names documented incorrectly In-Reply-To: <1348505583.77.0.632308357055.issue16026@psf.upfronthosting.co.za> Message-ID: <1348856783.21.0.601192065654.issue16026@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Changing the documentation is changing the specification, it has the higher bar than changing the implementation. It can break the alternative implementations. This is unlikely to break somebody's existing code, because the one who used the argument as a keyword argument should have paid attention to the discrepancy of the documentation. But fixing the name, we will be difficult to change it in the future (to eliminate inconsistency). I believe this change is too serious for bugfix. This is the case when never is better than *right* now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 20:32:58 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 28 Sep 2012 18:32:58 +0000 Subject: [issue16074] bad error message in os.rename In-Reply-To: <1348820000.8.0.496903200143.issue16074@psf.upfronthosting.co.za> Message-ID: <1348857178.21.0.553877158959.issue16074@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I confirm the bug. >>> import os >>> os.rename('non-existent-name', 'new-name') Traceback (most recent call last): File "", line 1, in FileNotFoundError: [Errno 2] No such file or directory: 'new-name' It obviously should be "No such file or directory: 'non-existent-name'". ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 20:36:03 2012 From: report at bugs.python.org (Kushal Das) Date: Fri, 28 Sep 2012 18:36:03 +0000 Subject: [issue16057] Subclasses of JSONEncoder should not be insturcted to call JSONEncoder.decode In-Reply-To: <1348695643.05.0.172807817425.issue16057@psf.upfronthosting.co.za> Message-ID: <1348857363.52.0.301402777639.issue16057@psf.upfronthosting.co.za> Kushal Das added the comment: The implementation clearly says that default method should return a serializable object or calls the base implementation to raise TypeError. So I don't think any of the examples is a bug. ---------- nosy: +kushaldas _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 20:53:01 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 28 Sep 2012 18:53:01 +0000 Subject: [issue16079] list duplicate test names with patchcheck In-Reply-To: <1348827338.06.0.659343787847.issue16079@psf.upfronthosting.co.za> Message-ID: <1348858381.03.0.456828226138.issue16079@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > I thought you were talking about test files. Oh, I see why you said that then. To find the test files themselves, this logic was used in the patch: + fn.startswith(os.path.join('Lib', 'test'))] Regarding your question for the general case, I'm not sure if there is ever a use case for duplicate method names. Is there? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 20:53:24 2012 From: report at bugs.python.org (Kushal Das) Date: Fri, 28 Sep 2012 18:53:24 +0000 Subject: [issue16071] fix link to email.message.Message in mailbox docs In-Reply-To: <1348802488.29.0.674477031086.issue16071@psf.upfronthosting.co.za> Message-ID: <1348858404.01.0.259347826614.issue16071@psf.upfronthosting.co.za> Kushal Das added the comment: But the whole 18.4.2 is mount mailbox.Message so, it seems to be correct documentation. email.Message.Message is properly mentioned in the 4th line properly. I don't think it is bug. ---------- nosy: +kushaldas _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 20:53:28 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 28 Sep 2012 18:53:28 +0000 Subject: [issue16026] csv.DictReader argument names documented incorrectly In-Reply-To: <1348505583.77.0.632308357055.issue16026@psf.upfronthosting.co.za> Message-ID: <1348858408.66.0.650654206885.issue16026@psf.upfronthosting.co.za> ?ric Araujo added the comment: I disagree that we can never fix argument names in the docs, as we have done it already. You raise a good point however, that we should check what other VMs do. I would not be surprised if they followed the code instead of the docs. ---------- keywords: +3.3regression -easy, patch nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 20:53:57 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 28 Sep 2012 18:53:57 +0000 Subject: [issue16026] csv.DictReader argument names documented incorrectly In-Reply-To: <1348505583.77.0.632308357055.issue16026@psf.upfronthosting.co.za> Message-ID: <1348858437.34.0.774405664851.issue16026@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- keywords: +needs review, patch -3.3regression _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 20:55:26 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 28 Sep 2012 18:55:26 +0000 Subject: [issue16053] "strict" parameter is not documented in csv module In-Reply-To: <1348655757.15.0.984566805089.issue16053@psf.upfronthosting.co.za> Message-ID: <1348858526.66.0.405630433379.issue16053@psf.upfronthosting.co.za> ?ric Araujo added the comment: Please use ``True`` instead of :const: (this is explained in the doc about the docs in the devguide). ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 20:57:47 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 28 Sep 2012 18:57:47 +0000 Subject: [issue16071] fix link to email.message.Message in mailbox docs In-Reply-To: <1348802488.29.0.674477031086.issue16071@psf.upfronthosting.co.za> Message-ID: <1348858667.88.0.452199095494.issue16071@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > But the whole 18.4.2 is mount mailbox.Message But the first reference is a reference to email.Message's Message, so that word should link to email.Message.Message. Sphinx lets you to link to classes, etc. outside the current scope. It's a simple one word or so fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 20:58:07 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 28 Sep 2012 18:58:07 +0000 Subject: [issue16074] bad error message in os.rename In-Reply-To: <1348820000.8.0.496903200143.issue16074@psf.upfronthosting.co.za> Message-ID: <1348858687.72.0.523949040384.issue16074@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Error in argument of path_error in function internal_rename. For some errcode it should be dst, for some src, for some both, for some none, and for some it is unknown. And this can be platform-specific. I suggest rollback this enhancement. ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 20:59:14 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 28 Sep 2012 18:59:14 +0000 Subject: [issue16074] bad error message in os.rename In-Reply-To: <1348820000.8.0.496903200143.issue16074@psf.upfronthosting.co.za> Message-ID: <1348858754.25.0.777076428627.issue16074@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Error in argument of path_error in function internal_rename. In file Modules/posixmodule.c. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 21:01:47 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 28 Sep 2012 19:01:47 +0000 Subject: [issue16053] "strict" parameter is not documented in csv module In-Reply-To: <1348655757.15.0.984566805089.issue16053@psf.upfronthosting.co.za> Message-ID: <1348858907.63.0.420173943791.issue16053@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Can native speakers review the patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 21:03:00 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 28 Sep 2012 19:03:00 +0000 Subject: [issue16053] "strict" parameter is not documented in csv module In-Reply-To: <1348655757.15.0.984566805089.issue16053@psf.upfronthosting.co.za> Message-ID: <1348858980.14.0.000916630254597.issue16053@psf.upfronthosting.co.za> ?ric Araujo added the comment: LGTM, except for my previous remark and a missing period after the first line. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 21:12:48 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 28 Sep 2012 19:12:48 +0000 Subject: [issue16071] fix link to email.message.Message in mailbox docs In-Reply-To: <1348802488.29.0.674477031086.issue16071@psf.upfronthosting.co.za> Message-ID: <1348859568.69.0.7158511797.issue16071@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- assignee: docs at python -> chris.jerdonek versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 21:13:04 2012 From: report at bugs.python.org (Glenn Linderman) Date: Fri, 28 Sep 2012 19:13:04 +0000 Subject: [issue16074] bad error message in os.rename In-Reply-To: <1348820000.8.0.496903200143.issue16074@psf.upfronthosting.co.za> Message-ID: <1348859584.61.0.370401510657.issue16074@psf.upfronthosting.co.za> Glenn Linderman added the comment: Terry, I thought the test case would demonstrate the error details. As far as Windows, I encountered it there, and it seemed like the sort of error that could be in a Windows-specific module. Serhiy, thanks for confirming, and analyzing. At this point in the release cycle, rolling back the enhanced message is probably better than trying to fix it. The 3.2 message was imprecise, but not confused with the sometimes-wrong file name. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 21:18:13 2012 From: report at bugs.python.org (Kushal Das) Date: Fri, 28 Sep 2012 19:18:13 +0000 Subject: [issue16053] "strict" parameter is not documented in csv module In-Reply-To: <1348655757.15.0.984566805089.issue16053@psf.upfronthosting.co.za> Message-ID: <1348859893.61.0.85025452942.issue16053@psf.upfronthosting.co.za> Kushal Das added the comment: Updated with new patch ---------- Added file: http://bugs.python.org/file27341/csv_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 21:20:35 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 28 Sep 2012 19:20:35 +0000 Subject: [issue16071] fix link to email.message.Message in mailbox docs In-Reply-To: <1348802488.29.0.674477031086.issue16071@psf.upfronthosting.co.za> Message-ID: <3XT2m32V6bzNLV@mail.python.org> Roundup Robot added the comment: New changeset be94d100f846 by R David Murray in branch '3.2': #16071: fix links to email.message.Message in mailbox docs. http://hg.python.org/cpython/rev/be94d100f846 New changeset 2a14542371b7 by R David Murray in branch 'default': Merge #16071: fix links to email.message.Message in mailbox docs. http://hg.python.org/cpython/rev/2a14542371b7 New changeset 70af6b53b52a by R David Murray in branch '3.2': #16071: fix more email.message links in mailbox docs. http://hg.python.org/cpython/rev/70af6b53b52a New changeset f3bd51cdd958 by R David Murray in branch 'default': Merge #16071: fix more email.message links in mailbox docs. http://hg.python.org/cpython/rev/f3bd51cdd958 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 21:21:45 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 28 Sep 2012 19:21:45 +0000 Subject: [issue16071] fix link to email.message.Message in mailbox docs In-Reply-To: <1348802488.29.0.674477031086.issue16071@psf.upfronthosting.co.za> Message-ID: <3XT2nP146vzNZP@mail.python.org> Roundup Robot added the comment: New changeset aad3cec524f9 by R David Murray in branch '2.7': #16071: fix email.message links in the mailbox docs. http://hg.python.org/cpython/rev/aad3cec524f9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 21:23:06 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 28 Sep 2012 19:23:06 +0000 Subject: [issue16071] fix link to email.message.Message in mailbox docs In-Reply-To: <1348802488.29.0.674477031086.issue16071@psf.upfronthosting.co.za> Message-ID: <1348860186.7.0.25156759636.issue16071@psf.upfronthosting.co.za> R. David Murray added the comment: Two words and a tilde. But there were also a number of other places where the links were broken. Hopefully I caught them all. ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 21:26:54 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 28 Sep 2012 19:26:54 +0000 Subject: [issue16071] fix link to email.message.Message in mailbox docs In-Reply-To: <1348802488.29.0.674477031086.issue16071@psf.upfronthosting.co.za> Message-ID: <1348860414.28.0.927576319817.issue16071@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- assignee: chris.jerdonek -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 21:45:44 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Fri, 28 Sep 2012 19:45:44 +0000 Subject: [issue13886] readline-related test_builtin failure In-Reply-To: <1327659819.71.0.475160045664.issue13886@psf.upfronthosting.co.za> Message-ID: <1348861544.43.0.933853198921.issue13886@psf.upfronthosting.co.za> Changes by Petri Lehtinen : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 21:48:59 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 28 Sep 2012 19:48:59 +0000 Subject: [issue16029] pickle.dumps(xrange(sys.maxsize)) produces xrange(0) In-Reply-To: <1348518540.13.0.547483002596.issue16029@psf.upfronthosting.co.za> Message-ID: <3XT3Np5ttQzNPV@mail.python.org> Roundup Robot added the comment: New changeset bff269ee7288 by Mark Dickinson in branch '2.7': Issues #16029, #16030: Fix pickling and repr of large xranges. http://hg.python.org/cpython/rev/bff269ee7288 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 21:49:00 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 28 Sep 2012 19:49:00 +0000 Subject: [issue16030] xrange repr broken for large arguments In-Reply-To: <1348521797.77.0.407946912471.issue16030@psf.upfronthosting.co.za> Message-ID: <3XT3Nq4Hg7zNPV@mail.python.org> Roundup Robot added the comment: New changeset bff269ee7288 by Mark Dickinson in branch '2.7': Issues #16029, #16030: Fix pickling and repr of large xranges. http://hg.python.org/cpython/rev/bff269ee7288 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 21:50:33 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 28 Sep 2012 19:50:33 +0000 Subject: [issue16029] pickle.dumps(xrange(sys.maxsize)) produces xrange(0) In-Reply-To: <1348518540.13.0.547483002596.issue16029@psf.upfronthosting.co.za> Message-ID: <1348861833.93.0.475512229775.issue16029@psf.upfronthosting.co.za> Mark Dickinson added the comment: Now fixed. Thanks for the report! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 21:51:15 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 28 Sep 2012 19:51:15 +0000 Subject: [issue16030] xrange repr broken for large arguments In-Reply-To: <1348521797.77.0.407946912471.issue16030@psf.upfronthosting.co.za> Message-ID: <1348861875.09.0.317504940519.issue16030@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 21:52:51 2012 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 28 Sep 2012 19:52:51 +0000 Subject: [issue16079] list duplicate test names with patchcheck In-Reply-To: <1348827338.06.0.659343787847.issue16079@psf.upfronthosting.co.za> Message-ID: <1348861971.78.0.858785482034.issue16079@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Note that using the module code object to find duplicates does not allow for selecting among the different code types: function, nested function, method or class. Duplicates are extensively used within the std lib: Running find_duplicate_test_names.py, the initial script from issue 16056, on the whole std lib instead of just Lib/test, after updating the script to list all the duplicates (except , , ...) with: if not name[-1].startswith('<'): yield '.'.join(name) prints 347 (on a total of 1368 std lib .py files) duplicate functions, methods or classes. To eliminate module level functions (but not nested functions), the script is run now with the following change: if len(name) > 2 and not name[-1].startswith('<'): yield '.'.join(name) and lists 188 duplicate nested functions, methods or classes. In this list there are 131 duplicates in .py files located in the subdirectory of a "test" directory. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 21:58:39 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 28 Sep 2012 19:58:39 +0000 Subject: [issue16053] "strict" parameter is not documented in csv module In-Reply-To: <1348655757.15.0.984566805089.issue16053@psf.upfronthosting.co.za> Message-ID: <1348862319.65.0.914240551987.issue16053@psf.upfronthosting.co.za> ?ric Araujo added the comment: LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 22:10:46 2012 From: report at bugs.python.org (Kushal Das) Date: Fri, 28 Sep 2012 20:10:46 +0000 Subject: [issue16074] bad error message in os.rename In-Reply-To: <1348820000.8.0.496903200143.issue16074@psf.upfronthosting.co.za> Message-ID: <1348863046.84.0.174702740466.issue16074@psf.upfronthosting.co.za> Kushal Das added the comment: Now the printing the source name instead of the destination as the bug described. ---------- keywords: +patch nosy: +kushaldas Added file: http://bugs.python.org/file27342/os_rename.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 22:12:23 2012 From: report at bugs.python.org (Kushal Das) Date: Fri, 28 Sep 2012 20:12:23 +0000 Subject: [issue16074] bad error message in os.rename In-Reply-To: <1348820000.8.0.496903200143.issue16074@psf.upfronthosting.co.za> Message-ID: <1348863143.16.0.386147780691.issue16074@psf.upfronthosting.co.za> Kushal Das added the comment: Just for record the same issue can be seen in a Linux box also. I tested in a Fedora 17 system. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 22:13:32 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 28 Sep 2012 20:13:32 +0000 Subject: [issue16074] bad error message in os.rename In-Reply-To: <1348820000.8.0.496903200143.issue16074@psf.upfronthosting.co.za> Message-ID: <1348863212.1.0.428049394191.issue16074@psf.upfronthosting.co.za> Larry Hastings added the comment: As Serhiy says, which filename to display is wholly context-sensitive to which errno it is. And there's no cheap way to display both. The cheap fix is to call path_error with a nulled-out "path" object; this will display the error without a filename. Patch doing this attached. By default we can't fix this in 3.3.0. I'll add Georg on the off chance he wants to cherry-pick it. Perhaps for 3.3.1 I can fix this properly, with a switch on the errno. ---------- nosy: +georg.brandl Added file: http://bugs.python.org/file27343/larry.rename_error.1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 22:13:51 2012 From: report at bugs.python.org (Kushal Das) Date: Fri, 28 Sep 2012 20:13:51 +0000 Subject: [issue16074] bad error message in os.rename In-Reply-To: <1348820000.8.0.496903200143.issue16074@psf.upfronthosting.co.za> Message-ID: <1348863231.03.0.264189754849.issue16074@psf.upfronthosting.co.za> Changes by Kushal Das : Removed file: http://bugs.python.org/file27342/os_rename.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 22:23:02 2012 From: report at bugs.python.org (Justin Lebar) Date: Fri, 28 Sep 2012 20:23:02 +0000 Subject: [issue16057] Subclasses of JSONEncoder should not be insturcted to call JSONEncoder.decode In-Reply-To: <1348695643.05.0.172807817425.issue16057@psf.upfronthosting.co.za> Message-ID: <1348863782.0.0.180493370899.issue16057@psf.upfronthosting.co.za> Justin Lebar added the comment: Ah, I see. The examples do what you think they should do, but not for the reason you think they should do it -- the JSON encoding logic calls the encoder's encode() method before calling its default() method. I still think the examples could be improved, perhaps by adding a comment to the effect of # Raises a TypeError. before the call to JSONEncoder.default(). Explicit is better than implicit, after all. :) Thanks for looking at this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 22:29:57 2012 From: report at bugs.python.org (Kushal Das) Date: Fri, 28 Sep 2012 20:29:57 +0000 Subject: [issue16057] Subclasses of JSONEncoder should not be insturcted to call JSONEncoder.decode In-Reply-To: <1348695643.05.0.172807817425.issue16057@psf.upfronthosting.co.za> Message-ID: <1348864197.89.0.0426987318759.issue16057@psf.upfronthosting.co.za> Kushal Das added the comment: Ok, I will submit a patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 22:45:55 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 28 Sep 2012 20:45:55 +0000 Subject: [issue16074] bad error message in os.rename In-Reply-To: <1348820000.8.0.496903200143.issue16074@psf.upfronthosting.co.za> Message-ID: <1348865155.66.0.0419467359732.issue16074@psf.upfronthosting.co.za> Larry Hastings added the comment: New patch, just calling posix_error directly. ---------- Added file: http://bugs.python.org/file27344/larry.rename_error.2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 22:49:30 2012 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 28 Sep 2012 20:49:30 +0000 Subject: [issue16079] list duplicate test names with patchcheck In-Reply-To: <1348827338.06.0.659343787847.issue16079@psf.upfronthosting.co.za> Message-ID: <1348865370.4.0.0726724696647.issue16079@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Using the python class browser (pyclbr.py) in conjunction with the search for duplicates in the module code object would allow to restrict the listing of duplicates to functions and methods or even just to methods (depending on the feature requirements), without listing the duplicate classes and duplicate nested functions. With an associated performance cost. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 23:06:49 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 28 Sep 2012 21:06:49 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1348866409.72.0.0770810617396.issue2771@psf.upfronthosting.co.za> Ezio Melotti added the comment: Another irker test ---------- nosy: -eric.araujo, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 28 23:59:28 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 28 Sep 2012 21:59:28 +0000 Subject: [issue15204] Deprecate the 'U' open mode In-Reply-To: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za> Message-ID: <1348869568.66.0.0206867363481.issue15204@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Ideally, this proposed deprecation should be mentioned on python-dev so that those folks will have an opportunity to respond. http://comments.gmane.org/gmane.comp.python.devel/134996 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 00:02:50 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 28 Sep 2012 22:02:50 +0000 Subject: [issue15204] Deprecate the 'U' open mode In-Reply-To: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za> Message-ID: <1348869770.54.0.50243947196.issue15204@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Chris, you did a great job on improving the documentation (including about universal newlines). Can you help with this issue? For the first stage should be clearly shown that "U" mode is not only should not be used in new code, but must be removed from the old code. Stage 1 patch updated to resolve conflicts with Chris changes. ---------- Added file: http://bugs.python.org/file27345/deprecate-U-mode-stage1_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 00:03:00 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 28 Sep 2012 22:03:00 +0000 Subject: [issue15204] Deprecate the 'U' open mode In-Reply-To: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za> Message-ID: <1348869780.78.0.833617589635.issue15204@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file26197/deprecate-U-mode-stage1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 00:58:56 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 28 Sep 2012 22:58:56 +0000 Subject: [issue16079] list duplicate test names with patchcheck In-Reply-To: <1348827338.06.0.659343787847.issue16079@psf.upfronthosting.co.za> Message-ID: <1348873136.82.0.852616473139.issue16079@psf.upfronthosting.co.za> Ezio Melotti added the comment: It doesn't necessary have to be limited to methods, anything duplicate might turn out to be a bug. If the script doesn't mix scopes there shouldn't be too many false positives, and if they are it shouldn't be a big deal if they are reported on the changed file by `make patchcheck`. > I'm not sure if there is ever a use case for duplicate > method names. Is there? Nothing that can't be done in a more elegant way afaict. It might make sense for variables though, where you have e.g.: foo = do_something(x) foo = do_something_more(foo) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 01:28:52 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 28 Sep 2012 23:28:52 +0000 Subject: [issue15204] Deprecate the 'U' open mode In-Reply-To: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za> Message-ID: <1348874932.03.0.63107925601.issue15204@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks, Serhiy. :) Sure, I should be able to help with the documentation portion of this issue if the community is in agreement. Would the deprecation need to be moved up to 3.4 though now? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 01:51:58 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 28 Sep 2012 23:51:58 +0000 Subject: [issue16045] add more unit tests for built-in int() In-Reply-To: <1348579722.08.0.96812684384.issue16045@psf.upfronthosting.co.za> Message-ID: <1348876318.2.0.627170420088.issue16045@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attaching first version of patch. Interestingly, not all of these pass when I tried applying to 2.7. For example, >>> int(base='foo') Traceback (most recent call last): File "", line 1, in TypeError: an integer is required So at least one modification will be needed there. ---------- keywords: +needs review, patch stage: test needed -> patch review versions: +Python 2.7, Python 3.2 Added file: http://bugs.python.org/file27346/issue-16045-1-default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 04:08:45 2012 From: report at bugs.python.org (Tim Chase) Date: Sat, 29 Sep 2012 02:08:45 +0000 Subject: [issue16071] fix link to email.message.Message in mailbox docs In-Reply-To: <1348802488.29.0.674477031086.issue16071@psf.upfronthosting.co.za> Message-ID: <1348884525.69.0.511367783942.issue16071@psf.upfronthosting.co.za> Tim Chase added the comment: http://docs.python.org/library/mailbox.html#mailbox.Message still points to mailbox.Message instead of email.Message "A subclass of the email.Message module?s {bad link}Message{/bad link}" Not sure if this is a matter of changes that haven't yet been deployed, or just one that slipped through the cracks. ---------- nosy: +Gumnos _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 04:13:19 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 29 Sep 2012 02:13:19 +0000 Subject: [issue16071] fix link to email.message.Message in mailbox docs In-Reply-To: <1348802488.29.0.674477031086.issue16071@psf.upfronthosting.co.za> Message-ID: <1348884799.62.0.547646698766.issue16071@psf.upfronthosting.co.za> Chris Jerdonek added the comment: It can take up to 24 hours for the changes to show up on the web site. They are regenerated at least once per day. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 08:59:41 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 29 Sep 2012 06:59:41 +0000 Subject: [issue9374] urlparse should parse query and fragment for arbitrary schemes In-Reply-To: <1280012321.31.0.791086727515.issue9374@psf.upfronthosting.co.za> Message-ID: <1348901981.01.0.262248258595.issue9374@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 09:27:37 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 29 Sep 2012 07:27:37 +0000 Subject: [issue16046] python -O does not find *.pyo files In-Reply-To: <1348581725.98.0.841014002753.issue16046@psf.upfronthosting.co.za> Message-ID: <3XTLtw5khQzNp2@mail.python.org> Roundup Robot added the comment: New changeset ff50579241cd by Benjamin Peterson in branch 'default': don't depend on __debug__ because it's baked in at freeze time (issue #16046) http://hg.python.org/cpython/rev/ff50579241cd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 09:27:38 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 29 Sep 2012 07:27:38 +0000 Subject: [issue16022] Mistake in "What's New in Python 3.3" In-Reply-To: <1348498015.65.0.0485764115741.issue16022@psf.upfronthosting.co.za> Message-ID: <3XTLtx49SDzNp2@mail.python.org> Roundup Robot added the comment: New changeset f6155d9111a2 by Victor Stinner in branch 'default': Close #16022: What's New in Python 3.3 document is no more at beta stage http://hg.python.org/cpython/rev/f6155d9111a2 ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 09:27:39 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 29 Sep 2012 07:27:39 +0000 Subject: [issue16012] pyexpat: Argument for UseForeignDTD should be optional In-Reply-To: <1348481405.23.0.796569447482.issue16012@psf.upfronthosting.co.za> Message-ID: <3XTLty2WyQzNwx@mail.python.org> Roundup Robot added the comment: New changeset b907f99272c5 by Georg Brandl in branch 'default': Port #16012 fix: parameter parsing regression in pyexpat parser UseForeignDTD() method. http://hg.python.org/cpython/rev/b907f99272c5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 09:27:39 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 29 Sep 2012 07:27:39 +0000 Subject: [issue16060] Double decref and dereferencing after decref in int() In-Reply-To: <1348735618.32.0.1069610095.issue16060@psf.upfronthosting.co.za> Message-ID: <3XTLtz0vDjzNwx@mail.python.org> Roundup Robot added the comment: New changeset d23eb81bd482 by Mark Dickinson in branch 'default': Issue #16060: Fix a double DECREF in int() implementation. Thanks Serhiy Storchaka. http://hg.python.org/cpython/rev/d23eb81bd482 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 09:27:40 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 29 Sep 2012 07:27:40 +0000 Subject: [issue9374] urlparse should parse query and fragment for arbitrary schemes In-Reply-To: <1280012321.31.0.791086727515.issue9374@psf.upfronthosting.co.za> Message-ID: <3XTLtz6P5lzNy0@mail.python.org> Roundup Robot added the comment: New changeset 950320c70fb4 by Georg Brandl in branch 'default': Add a versionchanged note for #9374 changes. http://hg.python.org/cpython/rev/950320c70fb4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 11:31:55 2012 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 29 Sep 2012 09:31:55 +0000 Subject: [issue16079] list duplicate test names with patchcheck In-Reply-To: <1348827338.06.0.659343787847.issue16079@psf.upfronthosting.co.za> Message-ID: <1348911115.12.0.27409197861.issue16079@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > I'm not sure if there is ever a use case for duplicate method > names. Is there? property getter, setter, and deleter methods do have the same name. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 12:41:11 2012 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 29 Sep 2012 10:41:11 +0000 Subject: [issue16079] list duplicate test names with patchcheck In-Reply-To: <1348827338.06.0.659343787847.issue16079@psf.upfronthosting.co.za> Message-ID: <1348915271.24.0.969862103935.issue16079@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > Here are a couple examples of test method names that don't begin > with "test_": > > def testLoadTk(self): > def testLoadTkFailure(self): Also Lib/test/test_smtplib.py test method names start with 'test' instead of 'test_' although the 'Regression tests package for Python' documentation states: "The test methods in the test module should start with test_". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 12:53:10 2012 From: report at bugs.python.org (pystranger) Date: Sat, 29 Sep 2012 10:53:10 +0000 Subject: [issue7171] Add inet_ntop and inet_pton support for Windows In-Reply-To: <1255994426.45.0.89635983538.issue7171@psf.upfronthosting.co.za> Message-ID: <1348915990.2.0.465666936813.issue7171@psf.upfronthosting.co.za> pystranger added the comment: I can't do that but I think the stage of the bug should be changed to "patch review" instead of "needs patch". ---------- nosy: +pystranger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 12:54:56 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 29 Sep 2012 10:54:56 +0000 Subject: [issue7171] Add inet_ntop and inet_pton support for Windows In-Reply-To: <1255994426.45.0.89635983538.issue7171@psf.upfronthosting.co.za> Message-ID: <1348916096.8.0.751059909933.issue7171@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 13:18:30 2012 From: report at bugs.python.org (Christian Heimes) Date: Sat, 29 Sep 2012 11:18:30 +0000 Subject: [issue7171] Add inet_ntop and inet_pton support for Windows In-Reply-To: <1255994426.45.0.89635983538.issue7171@psf.upfronthosting.co.za> Message-ID: <1348917510.4.0.244703204537.issue7171@psf.upfronthosting.co.za> Christian Heimes added the comment: As it's a new feature it must go into 3.4. ---------- components: +Extension Modules -Library (Lib) nosy: +christian.heimes versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 14:28:34 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 29 Sep 2012 12:28:34 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1348921714.7.0.806619145666.issue2771@psf.upfronthosting.co.za> Ezio Melotti added the comment: ????????????????????????????????????? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 14:30:24 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 29 Sep 2012 12:30:24 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1348921824.63.0.599468494355.issue2771@psf.upfronthosting.co.za> Ezio Melotti added the comment: ????????????????????????????????????? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 14:38:58 2012 From: report at bugs.python.org (Sebastian Noack) Date: Sat, 29 Sep 2012 12:38:58 +0000 Subject: [issue8800] add threading.RWLock In-Reply-To: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za> Message-ID: <1348922338.55.0.379890802813.issue8800@psf.upfronthosting.co.za> Sebastian Noack added the comment: I would love to see a reader/writer lock implementation shipped with Python's threading (and multiprocessing) module. But I have some issues with the patch: 1. I would avoid the terms 'read' and 'write' as those terms are referring just to one of many use cases. A better and more generic name would be shared and exclusive lock. 2. If we add a new synchronization primitive to the threading module we really should add it also to the multiprocessing module, for consistency and to keep switching between threading and multiprocessing as easy as it is right now. 3. The methods rdlock() and wrlock() might even block if you call them with blocking=False. That's because of they acquire the internal lock in a blocking fashion before they would return False. 4. As Antoine already pointed out, it is a bad idea to make acquiring the exclusive (write) lock, the default behavior. That clearly violates the Zen of Python, since explicit is better than implicit. 5. The issue above only raises from the idea that the RWLock should provide the same API as the Lock and RLock primitives. So everywhere where a lock primitive is expected, you can pass either a Lock, RLock or RWLock. That is actually a good idea, but in that case you should explicitly specify, whether to pass the shared (read) or the exclusive (write) lock. Both issues 4. and 5. only raise from the idea that a shared/exclusive lock should be implemented as a single class. But having two different lock primitives, one for the shared lock and one for the exclusive lock and a function returning a pair of those, would be much more flexible, pythonic and compatible with existing lock primitives. def ShrdExclLock() class _ShrdLock(object): def acquire(self, blocking=True): ... def release(self, blocking=True): ... def __enter__(self): self.acquire() retrun self def __exit__(self, exc_value, exc_type, tb): self.release() class _ExclLock(object): def acquire(self, blocking=True): ... def release(self, blocking=True): ... def __enter__(self): self.acquire() retrun self def __exit__(self, exc_value, exc_type, tb): self.release() return _ShrdLock(), _ExclLock() # create a shared/exclusive lock shrd_lock, excl_lock = ShrdExclLock() ---------- nosy: +Sebastian.Noack _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 14:46:22 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sat, 29 Sep 2012 12:46:22 +0000 Subject: [issue8800] add threading.RWLock In-Reply-To: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za> Message-ID: <1348922782.38.0.603623492357.issue8800@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Excellent points. For 3. however, I don't consider access to synchronized state to be "blocking". Blocking means to block while waiting for the lock. The internal lock is never held for any amount of time. Perhaps I'll cook up a new patch with these thoughts. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 14:50:05 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 29 Sep 2012 12:50:05 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1348923005.78.0.0114329850315.issue2771@psf.upfronthosting.co.za> Ezio Melotti added the comment: another test ---------- versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 14:56:40 2012 From: report at bugs.python.org (Christian Heimes) Date: Sat, 29 Sep 2012 12:56:40 +0000 Subject: [issue8800] add threading.RWLock In-Reply-To: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za> Message-ID: <1348923400.66.0.451602069507.issue8800@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 15:13:34 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Sat, 29 Sep 2012 13:13:34 +0000 Subject: [issue16084] couple of code examples not highlighted in "What's new in Python 3" Message-ID: <1348924414.8.0.371561507125.issue16084@psf.upfronthosting.co.za> New submission from Ramchandra Apte: A couple of code examples are not highlighted in http://docs.python.org/py3k/whatsnew/3.3.html#pep-380-syntax-for-delegating-to-a-subgenerator They should be highlighted with Python highlighting. ---------- assignee: docs at python components: Documentation messages: 171570 nosy: docs at python, ramchandra.apte priority: normal severity: normal status: open title: couple of code examples not highlighted in "What's new in Python 3" versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 15:28:25 2012 From: report at bugs.python.org (Ron Hubbard) Date: Sat, 29 Sep 2012 13:28:25 +0000 Subject: [issue9674] make install DESTDIR=/home/blah fails when the prefix specified is / In-Reply-To: <1282677588.85.0.771807305266.issue9674@psf.upfronthosting.co.za> Message-ID: <1348925305.66.0.0477352297686.issue9674@psf.upfronthosting.co.za> Ron Hubbard added the comment: this is a very ugly bug and should be fixed ASAP it's not only breaking python itself, but any package that uses this python installer, for example http://seclists.org/nmap-dev/2012/q3/1025 what is preventing a merge of the existing patch ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 15:37:37 2012 From: report at bugs.python.org (Ron Hubbard) Date: Sat, 29 Sep 2012 13:37:37 +0000 Subject: [issue13028] python wastes linux users time by checking for dylib on each dynamic library load In-Reply-To: <1316717807.43.0.635056141333.issue13028@psf.upfronthosting.co.za> Message-ID: <1348925857.7.0.227998797947.issue13028@psf.upfronthosting.co.za> Ron Hubbard added the comment: i'll try to reproduce this later. looking at the below strace output, python's behaviour seems pretty stupid tho, for example if /lib is the only existing path out of /lib, /lib64, /usr/lib/, /usr/local/lib, etc etc, it should check for all these directories once, and then not try to open .so in unexisting directories over and over again, inflicting multiple syscalls for each dso. ---------- nosy: +arschficker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 15:43:43 2012 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 29 Sep 2012 13:43:43 +0000 Subject: [issue16085] Minor config parser doc change Message-ID: <1348926223.26.0.285259885807.issue16085@psf.upfronthosting.co.za> New submission from Mark Lawrence: >From http://docs.python.org/library/configparser.html#examples float = config.getfloat('Section1', 'float') int = config.getint('Section1', 'int') print float + int It's not a good idea to have float or int used like this in examples. Maybe my_float and my_int or sec1_float and sec_int? ---------- assignee: docs at python components: Documentation messages: 171573 nosy: BreamoreBoy, docs at python priority: normal severity: normal status: open title: Minor config parser doc change type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 18:04:15 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 29 Sep 2012 16:04:15 +0000 Subject: [issue16086] tp_flags: Undefined behaviour with 32 bits long Message-ID: <1348934655.6.0.704339106877.issue16086@psf.upfronthosting.co.za> New submission from STINNER Victor: "1L << 31" is undefined if long is 32 bits long. We should use unsigned long for PyTypeObject.tp_flags. Attached patch implements this fix. I don't know if it breaks somehow the backward compatibility. See also issues #1621 and #7406. ---------- components: Interpreter Core files: unsigned_tp_flags.patch keywords: patch messages: 171574 nosy: ezio.melotti, haypo, mark.dickinson priority: normal severity: normal status: open title: tp_flags: Undefined behaviour with 32 bits long versions: Python 3.4 Added file: http://bugs.python.org/file27347/unsigned_tp_flags.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 18:14:29 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 29 Sep 2012 16:14:29 +0000 Subject: [issue16001] small ints: cache string representation In-Reply-To: <1348272680.09.0.237238464287.issue16001@psf.upfronthosting.co.za> Message-ID: <1348935269.32.0.403895910547.issue16001@psf.upfronthosting.co.za> STINNER Victor added the comment: str(int) is less common than "%s" % int or "%i" % int, and str%args has now "fast path" in Python 3.3 for integers. So I agree that my patch adds useless complexity and I'm closing this idea, thanks. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 18:16:26 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 29 Sep 2012 16:16:26 +0000 Subject: [issue16079] list duplicate test names with patchcheck In-Reply-To: <1348827338.06.0.659343787847.issue16079@psf.upfronthosting.co.za> Message-ID: <1348935383.95.0.159376064441.issue16079@psf.upfronthosting.co.za> Chris Jerdonek added the comment: For informational purposes, here is where unittest defaults to the prefix "test" for finding test methods: http://hg.python.org/cpython/file/f11649b21603/Lib/unittest/loader.py#l48 sqlite3 is able to use "Check" because it manages its own test discovery. For example-- http://hg.python.org/cpython/file/f11649b21603/Lib/sqlite3/test/regression.py#l306 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 18:58:10 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 29 Sep 2012 16:58:10 +0000 Subject: [issue16086] tp_flags: Undefined behaviour with 32 bits long In-Reply-To: <1348934655.6.0.704339106877.issue16086@psf.upfronthosting.co.za> Message-ID: <1348937890.58.0.58111089704.issue16086@psf.upfronthosting.co.za> Mark Dickinson added the comment: Victor: you missed one. :-) #define Py_TPFLAGS_HAVE_STACKLESS_EXTENSION (3L<<15) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 19:05:18 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 29 Sep 2012 17:05:18 +0000 Subject: [issue16084] couple of code examples not highlighted in "What's new in Python 3" In-Reply-To: <1348924414.8.0.371561507125.issue16084@psf.upfronthosting.co.za> Message-ID: <1348938318.45.0.11430745149.issue16084@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- assignee: docs at python -> chris.jerdonek nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 19:06:42 2012 From: report at bugs.python.org (Berker Peksag) Date: Sat, 29 Sep 2012 17:06:42 +0000 Subject: [issue16048] Tutorial-classes-remarks: replace paragraph In-Reply-To: <1348603562.92.0.789475109772.issue16048@psf.upfronthosting.co.za> Message-ID: <1348938402.54.0.189328053276.issue16048@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- title: Tutorial-classes-remarks: replace paragragh -> Tutorial-classes-remarks: replace paragraph _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 19:14:01 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 29 Sep 2012 17:14:01 +0000 Subject: [issue16086] tp_flags: Undefined behaviour with 32 bits long In-Reply-To: <1348934655.6.0.704339106877.issue16086@psf.upfronthosting.co.za> Message-ID: <1348938841.63.0.341405579516.issue16086@psf.upfronthosting.co.za> Mark Dickinson added the comment: Actually, I think it'll be messy to make this work: PyType_GetFlags is part of the stable ABI, so that's got to continue to return a long rather than an unsigned long. And then we've got, in object.h: #ifdef Py_LIMITED_API #define PyType_HasFeature(t,f) ((PyType_GetFlags(t) & (f)) != 0) #else #define PyType_HasFeature(t,f) (((t)->tp_flags & (f)) != 0) #endif So we'd need an extra cast from long to unsigned long in the first branch. I suggest instead just replacing that one occurrence of (1L << 31) with (long)(1UL << 31) to get around the undefined behaviour. P.S. The docs would also need to be updated in these two files: Doc/c-api/typeobj.rst Doc/includes/typestruct.h ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 19:25:14 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 29 Sep 2012 17:25:14 +0000 Subject: [issue16086] tp_flags: Undefined behaviour with 32 bits long In-Reply-To: <1348934655.6.0.704339106877.issue16086@psf.upfronthosting.co.za> Message-ID: <1348939514.09.0.982708293325.issue16086@psf.upfronthosting.co.za> Mark Dickinson added the comment: Martin, some things I'm not clear on w.r.t. the stable ABI. (1) Do defined constants like Py_TPFLAGS_INT_SUBCLASS form part of the stable ABI? (2) Would changing the type of Py_TPFLAGS_INT_SUBCLASS from long to unsigned long break the stable ABI? ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 19:31:59 2012 From: report at bugs.python.org (Kason) Date: Sat, 29 Sep 2012 17:31:59 +0000 Subject: [issue16087] How to open a csv file in universal new line mode? Message-ID: <1348939919.11.0.991356894827.issue16087@psf.upfronthosting.co.za> New submission from Kason: I am trying to follow the tutorial at http://www.slideshare.net/niloyghosh1984/qgis-tutorial-1 and I got to slide 24 of 47 whereupon I tried to use the mmqgis plugin to open the csv file, but I got this error: Error: new-line character seen in unquoted field - do you need to open the file in universal-newline mode? After searching for solutions to this error it indeed appears that I need to open this file in universal-newline mode...rU How do I do that? ---------- assignee: ronaldoussoren components: Macintosh messages: 171580 nosy: kason561, ronaldoussoren priority: normal severity: normal status: open title: How to open a csv file in universal new line mode? type: compile error versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 19:32:31 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 29 Sep 2012 17:32:31 +0000 Subject: [issue16084] couple of code examples not highlighted in "What's new in Python 3" In-Reply-To: <1348924414.8.0.371561507125.issue16084@psf.upfronthosting.co.za> Message-ID: <1348939951.89.0.303314512483.issue16084@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks for the report. Closing though as this is a duplicate. ---------- resolution: -> duplicate superseder: -> docs: 2 code examples not Pygmented (syntax color coded) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 19:37:19 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 29 Sep 2012 17:37:19 +0000 Subject: [issue16084] couple of code examples not highlighted in "What's new in Python 3" In-Reply-To: <1348924414.8.0.371561507125.issue16084@psf.upfronthosting.co.za> Message-ID: <1348940239.89.0.552310491282.issue16084@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 19:38:27 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 29 Sep 2012 17:38:27 +0000 Subject: [issue16084] couple of code examples not highlighted in "What's new in Python 3" In-Reply-To: <1348924414.8.0.371561507125.issue16084@psf.upfronthosting.co.za> Message-ID: <1348940307.18.0.375261085954.issue16084@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- stage: -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 19:40:13 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 29 Sep 2012 17:40:13 +0000 Subject: [issue14503] docs: "yield from" breaks Pygments syntax coloring in doc examples In-Reply-To: <1333613053.66.0.675522025893.issue14503@psf.upfronthosting.co.za> Message-ID: <1348940413.8.0.13199571624.issue14503@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- title: docs: 2 code examples not Pygmented (syntax color coded) -> docs: "yield from" breaks Pygments syntax coloring in doc examples _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 19:41:54 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 29 Sep 2012 17:41:54 +0000 Subject: [issue16087] How to open a csv file in universal new line mode? In-Reply-To: <1348939919.11.0.991356894827.issue16087@psf.upfronthosting.co.za> Message-ID: <1348940514.77.0.750324134354.issue16087@psf.upfronthosting.co.za> R. David Murray added the comment: The bug tracker isn't a good place to get help on using Python. You are more likely to find people to answer this sort of question on the python-list mailing list. If you are using python3, the answer is to use newline='', as discussed in the documentation. ---------- assignee: ronaldoussoren -> nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> closed type: compile error -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 19:48:44 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 29 Sep 2012 17:48:44 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1333386986.79.0.369810234487.issue14478@psf.upfronthosting.co.za> Message-ID: <1348940924.52.0.618354682733.issue14478@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 19:53:17 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 29 Sep 2012 17:53:17 +0000 Subject: [issue16077] fix code example in docs for built-in reduce() In-Reply-To: <1348822552.23.0.324199631114.issue16077@psf.upfronthosting.co.za> Message-ID: <1348941197.84.0.367596087784.issue16077@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- assignee: docs at python -> chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 20:10:53 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 29 Sep 2012 18:10:53 +0000 Subject: [issue16074] bad error message in os.rename In-Reply-To: <1348820000.8.0.496903200143.issue16074@psf.upfronthosting.co.za> Message-ID: <1348942253.18.0.0248326425973.issue16074@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Same issue for os.link and os.symlink. >>> import os >>> os.link('non-existent-name', 'new-name') Traceback (most recent call last): File "", line 1, in FileNotFoundError: [Errno 2] No such file or directory: 'new-name' >>> os.symlink('long-name'*1000, 'new-name') Traceback (most recent call last): File "", line 1, in OSError: [Errno 36] File name too long: 'new-name' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 20:44:36 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 29 Sep 2012 18:44:36 +0000 Subject: [issue16085] Minor config parser doc change In-Reply-To: <1348926223.26.0.285259885807.issue16085@psf.upfronthosting.co.za> Message-ID: <3XTdw30DlszQRk@mail.python.org> Roundup Robot added the comment: New changeset 178e7183931e by R David Murray in branch '3.2': #16085: Don't promote shadowing builtins in the configparser example. http://hg.python.org/cpython/rev/178e7183931e New changeset 769247e6edbf by R David Murray in branch '3.3': Merge #16085: Don't promote shadowing builtins in the configparser example. http://hg.python.org/cpython/rev/769247e6edbf New changeset 1c9b0b37f097 by R David Murray in branch 'default': Merge #16085: Don't promote shadowing builtins in the configparser example. http://hg.python.org/cpython/rev/1c9b0b37f097 New changeset 1ee270d522f3 by R David Murray in branch '2.7': #16085: Don't promote shadowing builtins in the configparser example. http://hg.python.org/cpython/rev/1ee270d522f3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 20:45:27 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 29 Sep 2012 18:45:27 +0000 Subject: [issue16085] Minor config parser doc change In-Reply-To: <1348926223.26.0.285259885807.issue16085@psf.upfronthosting.co.za> Message-ID: <1348944327.98.0.979391913729.issue16085@psf.upfronthosting.co.za> R. David Murray added the comment: Fixed. Thanks, Mark. ---------- nosy: +r.david.murray resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 20:51:57 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 29 Sep 2012 18:51:57 +0000 Subject: [issue16077] fix code example in docs for built-in reduce() In-Reply-To: <1348822552.23.0.324199631114.issue16077@psf.upfronthosting.co.za> Message-ID: <3XTf4X4zNszNwK@mail.python.org> Roundup Robot added the comment: New changeset a6779524962c by Chris Jerdonek in branch '2.7': Close issue #16077: fix code example in documentation of reduce() built-in (from docs@). http://hg.python.org/cpython/rev/a6779524962c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 20:54:04 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 29 Sep 2012 18:54:04 +0000 Subject: [issue16077] fix code example in docs for built-in reduce() In-Reply-To: <1348822552.23.0.324199631114.issue16077@psf.upfronthosting.co.za> Message-ID: <1348944844.83.0.379814369145.issue16077@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Serhiy, feel free to create a new issue for Doc/howto/functional.rst if you feel an addition there is warranted. ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 20:58:44 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 29 Sep 2012 18:58:44 +0000 Subject: [issue15756] subprocess.poll() does not handle errno.ECHILD "No child processes" In-Reply-To: <1345576517.75.0.906463701582.issue15756@psf.upfronthosting.co.za> Message-ID: <3XTfDM5xkpzNkx@mail.python.org> Roundup Robot added the comment: New changeset 484c50bf445c by Gregory P. Smith in branch '3.2': Fixes issue #15756: subprocess.poll() now properly handles errno.ECHILD http://hg.python.org/cpython/rev/484c50bf445c New changeset ba8d85552e34 by Gregory P. Smith in branch '3.3': Fixes issue #15756: subprocess.poll() now properly handles errno.ECHILD http://hg.python.org/cpython/rev/ba8d85552e34 New changeset 9032b3f52819 by Gregory P. Smith in branch 'default': Fixes issue #15756: subprocess.poll() now properly handles errno.ECHILD to http://hg.python.org/cpython/rev/9032b3f52819 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 21:03:25 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 29 Sep 2012 19:03:25 +0000 Subject: [issue15756] subprocess.poll() does not handle errno.ECHILD "No child processes" In-Reply-To: <1345576517.75.0.906463701582.issue15756@psf.upfronthosting.co.za> Message-ID: <3XTfKm351HzP8b@mail.python.org> Roundup Robot added the comment: New changeset 53e91fa35f8e by Gregory P. Smith in branch '2.7': Issue #15756: subprocess.poll() now properly handles errno.ECHILD to http://hg.python.org/cpython/rev/53e91fa35f8e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 21:03:53 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 29 Sep 2012 19:03:53 +0000 Subject: [issue15756] subprocess.poll() does not handle errno.ECHILD "No child processes" In-Reply-To: <1345576517.75.0.906463701582.issue15756@psf.upfronthosting.co.za> Message-ID: <1348945433.64.0.259964315586.issue15756@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 21:07:02 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 29 Sep 2012 19:07:02 +0000 Subject: [issue14331] Python/import.c uses a lot of stack space due to MAXPATHLEN In-Reply-To: <1331858549.21.0.813321528381.issue14331@psf.upfronthosting.co.za> Message-ID: <1348945622.73.0.379227664066.issue14331@psf.upfronthosting.co.za> Gregory P. Smith added the comment: This was fixed in April. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 21:07:42 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 29 Sep 2012 19:07:42 +0000 Subject: [issue16077] fix code example in docs for built-in reduce() In-Reply-To: <1348822552.23.0.324199631114.issue16077@psf.upfronthosting.co.za> Message-ID: <1348945662.24.0.0377531243933.issue16077@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I thought and decided it wasn't worth it. Howtos for general cases, and not for corner cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 21:12:33 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 29 Sep 2012 19:12:33 +0000 Subject: [issue12268] file readline, readlines & readall methods can lose data on EINTR In-Reply-To: <1307306343.57.0.342192724444.issue12268@psf.upfronthosting.co.za> Message-ID: <1348945953.16.0.311386652304.issue12268@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 21:36:30 2012 From: report at bugs.python.org (Mike Hoy) Date: Sat, 29 Sep 2012 19:36:30 +0000 Subject: [issue9650] format codes in time.strptime docstrings In-Reply-To: <1282319380.5.0.724924373031.issue9650@psf.upfronthosting.co.za> Message-ID: <1348947390.67.0.281631941387.issue9650@psf.upfronthosting.co.za> Mike Hoy added the comment: >If you like my idea we should discuss it on python-ideas and start a new tracker entry. In the meantime I'd like to create a patch that incorporates Alexander's ideas. If any objections let me know. ---------- nosy: +mikehoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 21:41:10 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 29 Sep 2012 19:41:10 +0000 Subject: [issue2489] Patch for bugs in pty.py In-Reply-To: <1206494149.11.0.607365562092.issue2489@psf.upfronthosting.co.za> Message-ID: <3XTg9K73m7zNg6@mail.python.org> Roundup Robot added the comment: New changeset ec2921d4de37 by Gregory P. Smith in branch 'default': pty.spawn() now returns the child process status as returned by os.waitpid(). http://hg.python.org/cpython/rev/ec2921d4de37 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 21:41:30 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 29 Sep 2012 19:41:30 +0000 Subject: [issue2489] Patch for bugs in pty.py In-Reply-To: <1206494149.11.0.607365562092.issue2489@psf.upfronthosting.co.za> Message-ID: <1348947690.36.0.972249353858.issue2489@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 22:03:48 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 29 Sep 2012 20:03:48 +0000 Subject: [issue2489] Patch for bugs in pty.py In-Reply-To: <1206494149.11.0.607365562092.issue2489@psf.upfronthosting.co.za> Message-ID: <1348949028.77.0.906812680156.issue2489@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The test breaks on OpenIndiana (and possibly elsewhere): http://buildbot.python.org/all/builders/x86%20OpenIndiana%203.x/builds/4640 ====================================================================== FAIL: test_spawn_returns_status (test.test_pty.PtyTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_pty.py", line 200, in test_spawn_returns_status status = pty.spawn([sys.executable, '-c', 'import sys; sys.exit(0)']) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/pty.py", line 175, in spawn _copy(master_fd, master_read, stdin_read) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/pty.py", line 147, in _copy rfds, wfds, xfds = select(fds, [], []) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_pty.py", line 65, in handle_sig self.fail("isatty hung") AssertionError: isatty hung ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 22:54:48 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 29 Sep 2012 20:54:48 +0000 Subject: [issue16045] add more unit tests for built-in int() In-Reply-To: <1348579722.08.0.96812684384.issue16045@psf.upfronthosting.co.za> Message-ID: <1348952088.23.0.676863232248.issue16045@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Adding patch modified for 2.7. Here are the differences I found from 3.3. Unlike 3.3-- (1) 2.7 does not accept bytearrays for x (though it accepts str/bytes). (2) 2.7 raises a TypeError if passed a string base without providing x. Is it acceptable to add tests like this to the 2.7 branch? This information also helps in preparing the 2.7 documentation patch for issue 16036 and ensuring that it is correct. ---------- Added file: http://bugs.python.org/file27348/issue-16045-2-27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 22:57:13 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Sat, 29 Sep 2012 20:57:13 +0000 Subject: [issue12014] str.format parses replacement field incorrectly In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za> Message-ID: <1348952233.75.0.106403180994.issue12014@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 29 23:04:12 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 29 Sep 2012 21:04:12 +0000 Subject: [issue16036] simplify int() signature docs In-Reply-To: <1348568310.1.0.968219969881.issue16036@psf.upfronthosting.co.za> Message-ID: <1348952652.66.0.996385511145.issue16036@psf.upfronthosting.co.za> Chris Jerdonek added the comment: See the following comment to issue 16045 for a couple differences in the behavior of int() in 2.7: http://bugs.python.org/issue16045#msg171595 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 01:02:31 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 29 Sep 2012 23:02:31 +0000 Subject: [issue16088] http.server's send_error could set the content-length of the error body Message-ID: <1348959751.44.0.331357335713.issue16088@psf.upfronthosting.co.za> New submission from Antoine Pitrou: BaseHTTPRequestHandler.send_error() sets "connection: close", so the client shouldn't need a content-length, but it can still be nicer to send it (e.g. it seems to solve an issue with wget, see issue15991). ---------- components: Library (Lib) messages: 171597 nosy: orsenthil, pitrou priority: low severity: normal status: open title: http.server's send_error could set the content-length of the error body type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 01:05:08 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 29 Sep 2012 23:05:08 +0000 Subject: [issue16088] http.server's send_error could set the content-length of the error body In-Reply-To: <1348959751.44.0.331357335713.issue16088@psf.upfronthosting.co.za> Message-ID: <1348959908.47.0.00877248091145.issue16088@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch. ---------- keywords: +patch Added file: http://bugs.python.org/file27349/http_error_content_length.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 01:46:52 2012 From: report at bugs.python.org (Sebastian Noack) Date: Sat, 29 Sep 2012 23:46:52 +0000 Subject: [issue8800] add threading.RWLock In-Reply-To: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za> Message-ID: <1348962412.65.0.849993361986.issue8800@psf.upfronthosting.co.za> Sebastian Noack added the comment: Using a lock as context manager is the same as calling lock.acquire(blocking=True) and it will in fact block while waiting for an other thread to release the lock. In your code, the internal lock is indeed just hold for a very short period of time while acquiring or releasing a shared or exclusive lock, but it might add up to a notable amount of time dependent on how much concurrent threads are using the same RWLock and how slow/busy your computer is. But what made me reconsider my point are following facts: 1. For example, when you acquire a shared (read) lock in non-blocking mode and False is returned, you assume that an other thread is holding an exclusive (write) lock. But that isn't necessarily the case, if it also returns False, when the internal lock is acquired by an other thread for example in order to acquire or release another shared (read) lock. 2. The internal lock must be acquired also in order to release a shared/exclusive lock. And the 'release' method (at least if implemented as for Lock and RLock) don't have a 'blocking' argument, anyway. For that reasons, I think it is ok to block while waiting for the internal lock, even if the shared/exclusive lock was acquired in non-blocking mode. At least it seems to lead to less unexpected side effects, than returning False in case the internal lock is acquired. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 04:01:42 2012 From: report at bugs.python.org (Sebastian Noack) Date: Sun, 30 Sep 2012 02:01:42 +0000 Subject: [issue8800] add threading.RWLock In-Reply-To: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za> Message-ID: <1348970502.75.0.793622682381.issue8800@psf.upfronthosting.co.za> Sebastian Noack added the comment: I've added a new patch, that implements a shared/exclusive lock as described in my comments above, for the threading and multiprocessing module. ---------- Added file: http://bugs.python.org/file27350/Added-ShrdExclLock-to-threading-and-multiprocessing.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 04:02:20 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 30 Sep 2012 02:02:20 +0000 Subject: [issue16034] bz2 module appears slower in Python 3.x versus Python 2.x In-Reply-To: <1348547973.67.0.489000428853.issue16034@psf.upfronthosting.co.za> Message-ID: <3XTqd75x2dzNSY@mail.python.org> Roundup Robot added the comment: New changeset 1a08f4887cff by Nadeem Vawda in branch '3.3': Issue #16034: Fix performance regressions in the new BZ2File implementation. http://hg.python.org/cpython/rev/1a08f4887cff New changeset cf50a352fe22 by Nadeem Vawda in branch 'default': Merge #16034: Fix performance regressions in the new BZ2File implementation. http://hg.python.org/cpython/rev/cf50a352fe22 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 04:06:23 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Sun, 30 Sep 2012 02:06:23 +0000 Subject: [issue16034] bz2 module appears slower in Python 3.x versus Python 2.x In-Reply-To: <1348547973.67.0.489000428853.issue16034@psf.upfronthosting.co.za> Message-ID: <1348970783.65.0.779777082133.issue16034@psf.upfronthosting.co.za> Nadeem Vawda added the comment: Thanks for the bug report, Victor, and thank you Serhiy for the patch! Serhiy, would you be OK with me also including this patch in the bz2file package? ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 04:07:42 2012 From: report at bugs.python.org (Christian Heimes) Date: Sun, 30 Sep 2012 02:07:42 +0000 Subject: [issue16089] _elementtree causes segfault in GC Message-ID: <1348970862.81.0.736695242293.issue16089@psf.upfronthosting.co.za> New submission from Christian Heimes: The issue was reported by Arfrever on #python-dev. The test suite of simpletal [1] was segfaulting with Python 3.3. It doesn't segfault without the _elementtree C extension. I'm able to reproduce the issue. It may take a couple of runs with a debug build of Python but eventually Python segfaults. So far segfaults occur inside a GC collection run. Benjamin suspects the issue is related to the new GC code in _elementtree. #0 visit_decref (op=, data=0x0) at Modules/gcmodule.c:361 #1 0x00000000004bccd5 in subtract_refs (containers=) at Modules/gcmodule.c:386 #2 collect (generation=0, n_collected=0x7fffe3eedb70, n_uncollectable=0x7fffe3eedb78) at Modules/gcmodule.c:891 #3 0x00000000004bd7e6 in collect_with_callback (generation=0) at Modules/gcmodule.c:1048 #4 collect_generations () at Modules/gcmodule.c:1071 #5 _PyObject_GC_Malloc (basicsize=) at Modules/gcmodule.c:1580 #6 0x00000000004bddcc in _PyObject_GC_Malloc (basicsize=) at Modules/gcmodule.c:1567 #7 _PyObject_GC_New (tp=0x8322a0) at Modules/gcmodule.c:1590 #8 0x0000000000548a3a in new_dict (values=0x0, keys=0xd02e60) at Objects/dictobject.c:395 #9 _PyDict_NewPresized (minused=) at Objects/dictobject.c:1044 #10 0x000000000047a449 in PyEval_EvalFrameEx (f=, throwflag=) at Python/ceval.c:2245 #11 0x0000000000480b03 in fast_function (nk=, na=1, n=, pp_stack=0x7fffe3eede40, func= ) at Python/ceval.c:4150 [1] http://www.owlfish.com/software/simpleTAL/downloads/SimpleTAL-5.1.tar.gz ---------- components: Extension Modules keywords: 3.3regression messages: 171603 nosy: christian.heimes priority: critical severity: normal stage: needs patch status: open title: _elementtree causes segfault in GC type: crash versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 04:12:49 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 30 Sep 2012 02:12:49 +0000 Subject: [issue16089] _elementtree causes segfault in GC In-Reply-To: <1348970862.81.0.736695242293.issue16089@psf.upfronthosting.co.za> Message-ID: <1348971169.6.0.554719127164.issue16089@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 04:53:28 2012 From: report at bugs.python.org (Christian Heimes) Date: Sun, 30 Sep 2012 02:53:28 +0000 Subject: [issue14007] xml.etree.ElementTree - XMLParser and TreeBuilder's doctype() method missing In-Reply-To: <1329193190.72.0.667201124226.issue14007@psf.upfronthosting.co.za> Message-ID: <1348973608.27.0.990895045618.issue14007@psf.upfronthosting.co.za> Christian Heimes added the comment: It seems like your changes have introduced a segfault: #16089 ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 04:56:01 2012 From: report at bugs.python.org (Christian Heimes) Date: Sun, 30 Sep 2012 02:56:01 +0000 Subject: [issue16089] _elementtree causes segfault in GC In-Reply-To: <1348970862.81.0.736695242293.issue16089@psf.upfronthosting.co.za> Message-ID: <1348973761.81.0.738966374696.issue16089@psf.upfronthosting.co.za> Christian Heimes added the comment: The issue could be related to #14007. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 05:12:46 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Sun, 30 Sep 2012 03:12:46 +0000 Subject: [issue16084] couple of code examples not highlighted in "What's new in Python 3" In-Reply-To: <1348924414.8.0.371561507125.issue16084@psf.upfronthosting.co.za> Message-ID: <1348974766.26.0.788254077419.issue16084@psf.upfronthosting.co.za> Ramchandra Apte added the comment: LOL the duplicate is my bug ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 05:18:03 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Sun, 30 Sep 2012 03:18:03 +0000 Subject: [issue15201] C argument errors and Python arguments error are different In-Reply-To: <1340787562.9.0.381014932259.issue15201@psf.upfronthosting.co.za> Message-ID: <1348975083.55.0.261684677065.issue15201@psf.upfronthosting.co.za> Changes by Ramchandra Apte : ---------- versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 05:23:20 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Sun, 30 Sep 2012 03:23:20 +0000 Subject: [issue16090] but is needed somewhere in http://www.python.org/dev/peps/pep-3138/ Message-ID: <1348975400.05.0.784015887596.issue16090@psf.upfronthosting.co.za> New submission from Ramchandra Apte: subject I can't remember where the but is needed but I am sure a but is missing somewhere there. ---------- assignee: docs at python components: Documentation messages: 171607 nosy: docs at python, ramchandra.apte priority: normal severity: normal status: open title: but is needed somewhere in http://www.python.org/dev/peps/pep-3138/ versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 05:28:10 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 30 Sep 2012 03:28:10 +0000 Subject: [issue16084] couple of code examples not highlighted in "What's new in Python 3" In-Reply-To: <1348924414.8.0.371561507125.issue16084@psf.upfronthosting.co.za> Message-ID: <1348975690.95.0.799098255436.issue16084@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Yes, I noticed that later, too. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 05:31:04 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Sun, 30 Sep 2012 03:31:04 +0000 Subject: [issue16091] changing sidebar links in http://docs.python.org/ Message-ID: <1348975864.27.0.424310551967.issue16091@psf.upfronthosting.co.za> New submission from Ramchandra Apte: In http://docs.python.org/ the "Python 3.3 (in development)" link goes to the Python 3.4 docs. It should be renamed to "Python 3.3". A new link should be added for the Python 3.4 docs and the Python 3.2 link may be removed. ---------- assignee: docs at python components: Documentation messages: 171609 nosy: docs at python, ramchandra.apte priority: normal severity: normal status: open title: changing sidebar links in http://docs.python.org/ _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 07:50:41 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 30 Sep 2012 05:50:41 +0000 Subject: [issue15201] C argument errors and Python arguments error are different In-Reply-To: <1340787562.9.0.381014932259.issue15201@psf.upfronthosting.co.za> Message-ID: <1348984241.83.0.516990766413.issue15201@psf.upfronthosting.co.za> Benjamin Peterson added the comment: This is won't fix at least for now. The way arguments to C functions are parsed prevents them from ever really being the same. Specific improvements can be considered. ---------- nosy: +benjamin.peterson resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 07:53:51 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 30 Sep 2012 05:53:51 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1348984431.84.0.00292351488034.issue15533@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Chris, please commit your patch. It's fine for me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 07:55:33 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 30 Sep 2012 05:55:33 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1348984533.89.0.827362791039.issue15533@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- assignee: docs at python -> chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 08:06:56 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 30 Sep 2012 06:06:56 +0000 Subject: [issue16036] simplify int() signature docs In-Reply-To: <1348568310.1.0.968219969881.issue16036@psf.upfronthosting.co.za> Message-ID: <1348985216.39.0.371642403577.issue16036@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Attaching patch updated for backport to 2.7. In cases where the 2.7 language was substantively different, I preserved the 2.7 language (e.g. I preserved the reference to plain and long integers). I also added the lone "0" prefix for octals, which is a difference from 3.x: ``0o``/``0O``/``0``. ---------- Added file: http://bugs.python.org/file27351/issue-16036-5-27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 08:53:46 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 30 Sep 2012 06:53:46 +0000 Subject: [issue16092] test_recursion_limit in test_threading fails on Mac OS X in 3.2 Message-ID: <1348988026.7.0.663169616771.issue16092@psf.upfronthosting.co.za> New submission from Chris Jerdonek: The test_threading.ThreadingExceptionTests.test_recursion_limit test fails on Mac OS X with the standard compilation command: $ ./configure --with-pydebug && make -j2 Python 3.2.3+ (3.2:247d3e3c08ca, Sep 29 2012, 23:45:43) [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)] on darwin Mac OS X Lion 10.7.5 ====================================================================== FAIL: test_recursion_limit (test.test_threading.ThreadingExceptionTests) ---------------------------------------------------------------------- Traceback (most recent call last): File ".../cpython/Lib/test/test_threading.py", line 774, in test_recursion_limit self.assertEqual(p.returncode, 0, "Unexpected error: " + stderr.decode()) AssertionError: -10 != 0 : Unexpected error: ---------------------------------------------------------------------- This seems very similar to issue 14184 (copying the nosy list). ---------- components: Library (Lib) messages: 171613 nosy: chris.jerdonek, dk, meador.inge, ned.deily priority: normal severity: normal status: open title: test_recursion_limit in test_threading fails on Mac OS X in 3.2 type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 08:56:13 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 30 Sep 2012 06:56:13 +0000 Subject: [issue16090] but is needed somewhere in http://www.python.org/dev/peps/pep-3138/ In-Reply-To: <1348975400.05.0.784015887596.issue16090@psf.upfronthosting.co.za> Message-ID: <1348988173.8.0.622214647382.issue16090@psf.upfronthosting.co.za> Georg Brandl added the comment: I've gone through the PEP; I've found a few typos and fixed them, but no missing "but". Sorry, but without a more specific location I don't think it's sensible to keep this open. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 09:00:34 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 30 Sep 2012 07:00:34 +0000 Subject: [issue16093] Documentation: links to 3.3 Message-ID: <1348988434.58.0.811959538249.issue16093@psf.upfronthosting.co.za> New submission from Stefan Krah: A couple of links still need to be updated: http://docs.python.org/ Python 3.3 says "in development" and points to 3.4. http://docs.python.org/dev/ Python 3.3 is missing. ---------- assignee: docs at python components: Documentation messages: 171615 nosy: docs at python, skrah priority: normal severity: normal status: open title: Documentation: links to 3.3 type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 09:00:42 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 30 Sep 2012 07:00:42 +0000 Subject: [issue16091] changing sidebar links in http://docs.python.org/ In-Reply-To: <1348975864.27.0.424310551967.issue16091@psf.upfronthosting.co.za> Message-ID: <3XTyFQ1wBWzNmk@mail.python.org> Roundup Robot added the comment: New changeset eac9a50a2bdd by Georg Brandl in branch 'default': Closes #16091: fix the references to 3.3/3.4 in the Doc sidebar. http://hg.python.org/cpython/rev/eac9a50a2bdd ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 09:01:15 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 30 Sep 2012 07:01:15 +0000 Subject: [issue16093] Documentation: links to 3.3 In-Reply-To: <1348988434.58.0.811959538249.issue16093@psf.upfronthosting.co.za> Message-ID: <1348988475.77.0.410710513682.issue16093@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- resolution: -> duplicate status: open -> closed superseder: -> changing sidebar links in http://docs.python.org/ _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 09:20:40 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 30 Sep 2012 07:20:40 +0000 Subject: [issue16092] test_recursion_limit in test_threading fails on Mac OS X in 3.2 In-Reply-To: <1348988026.7.0.663169616771.issue16092@psf.upfronthosting.co.za> Message-ID: <1348989640.97.0.385735786342.issue16092@psf.upfronthosting.co.za> Ned Deily added the comment: As far as I know, this is currently only an issue if you use the llvm-gcc-4.2 compiler on OS X to do a debug mode build. That compiler is no longer maintained by Apple and is known to miscompile Python 3.3 builds. There are checks in configure.ac for 3.3 to avoid using it. With Xcode 4, use clang instead (./configure ... CC=clang); for Xcode 3, use the standard gcc-4.2 (CC=gcc-4.2). ---------- resolution: -> wont fix stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 09:42:30 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 30 Sep 2012 07:42:30 +0000 Subject: [issue16034] bz2 module appears slower in Python 3.x versus Python 2.x In-Reply-To: <1348547973.67.0.489000428853.issue16034@psf.upfronthosting.co.za> Message-ID: <1348990950.78.0.553532433112.issue16034@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Serhiy, would you be OK with me also including this patch in the bz2file package? Yes, of course. We can even speed up 1.5 times the reading of small chunks, if we inline _check_can_read() and _read_block(). The same approach is applied for LZMAFile. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 10:02:40 2012 From: report at bugs.python.org (Florent Xicluna) Date: Sun, 30 Sep 2012 08:02:40 +0000 Subject: [issue16089] _elementtree causes segfault in GC In-Reply-To: <1348970862.81.0.736695242293.issue16089@psf.upfronthosting.co.za> Message-ID: <1348992160.1.0.117299941304.issue16089@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- components: +XML nosy: +eli.bendersky, flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 10:13:31 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 30 Sep 2012 08:13:31 +0000 Subject: [issue16089] _elementtree causes segfault in GC In-Reply-To: <1348970862.81.0.736695242293.issue16089@psf.upfronthosting.co.za> Message-ID: <1348992811.55.0.518526406732.issue16089@psf.upfronthosting.co.za> Stefan Krah added the comment: I can't reproduce this, so just a wild guess: Does the segfault still happen if you replace Py_XDECREF() with Py_CLEAR() in xmlparser_gc_clear()? ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 11:24:38 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 30 Sep 2012 09:24:38 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <3XV1RT5Vs6zNBr@mail.python.org> Roundup Robot added the comment: New changeset abfaa4368263 by Chris Jerdonek in branch '3.2': Issue #15533: Clarify docs and add tests for subprocess.Popen()'s cwd argument. http://hg.python.org/cpython/rev/abfaa4368263 New changeset f66ff96f0030 by Chris Jerdonek in branch '3.3': Issue #15533: Merge fix from 3.2. http://hg.python.org/cpython/rev/f66ff96f0030 New changeset 37f4aa15a1c6 by Chris Jerdonek in branch 'default': Issue #15533: Merge fix from 3.3. http://hg.python.org/cpython/rev/37f4aa15a1c6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 11:26:32 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 30 Sep 2012 09:26:32 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1348997192.52.0.891645211181.issue15533@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I will commit to 2.7 separately. ---------- versions: +Python 3.2, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 12:03:04 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 30 Sep 2012 10:03:04 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1348999384.48.0.2788643948.issue15533@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Two of the tests fail on at least some of the Windows bots. I am investigating. ====================================================================== ERROR: test_cwd_with_relative_arg (test.test_subprocess.ProcessTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\Buildslave\3.2.moore-windows\build\lib\test\test_subprocess.py", line 222, in test_cwd_with_relative_arg self._assert_cwd(python_dir, rel_python, cwd=python_dir) File "D:\Buildslave\3.2.moore-windows\build\lib\test\test_subprocess.py", line 195, in _assert_cwd **kwargs) File "D:\Buildslave\3.2.moore-windows\build\lib\subprocess.py", line 745, in __init__ restore_signals, start_new_session) File "D:\Buildslave\3.2.moore-windows\build\lib\subprocess.py", line 964, in _execute_child startupinfo) WindowsError: [Error 2] The system cannot find the file specified ====================================================================== ERROR: test_cwd_with_relative_executable (test.test_subprocess.ProcessTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\Buildslave\3.2.moore-windows\build\lib\test\test_subprocess.py", line 240, in test_cwd_with_relative_executable cwd=python_dir) File "D:\Buildslave\3.2.moore-windows\build\lib\test\test_subprocess.py", line 195, in _assert_cwd **kwargs) File "D:\Buildslave\3.2.moore-windows\build\lib\subprocess.py", line 745, in __init__ restore_signals, start_new_session) File "D:\Buildslave\3.2.moore-windows\build\lib\subprocess.py", line 964, in _execute_child startupinfo) WindowsError: [Error 2] The system cannot find the file specified http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.2/builds/210 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 12:12:32 2012 From: report at bugs.python.org (Tom Wardill) Date: Sun, 30 Sep 2012 10:12:32 +0000 Subject: [issue11798] Test cases not garbage collected after run In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za> Message-ID: <1348999952.86.0.355070831504.issue11798@psf.upfronthosting.co.za> Tom Wardill added the comment: Patch attached using setting test to None after execution. ---------- keywords: +patch nosy: +tomwardill Added file: http://bugs.python.org/file27352/11798.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 12:18:28 2012 From: report at bugs.python.org (Tom Wardill) Date: Sun, 30 Sep 2012 10:18:28 +0000 Subject: [issue15505] unittest.installHandler incorrectly assumes SIGINT handler is set. In-Reply-To: <1343666222.08.0.345756863201.issue15505@psf.upfronthosting.co.za> Message-ID: <1349000308.08.0.485785276188.issue15505@psf.upfronthosting.co.za> Changes by Tom Wardill : ---------- nosy: +michael.foord _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 12:21:09 2012 From: report at bugs.python.org (Tom Wardill) Date: Sun, 30 Sep 2012 10:21:09 +0000 Subject: [issue11770] inspect.dir_static In-Reply-To: <1302001735.74.0.572603626553.issue11770@psf.upfronthosting.co.za> Message-ID: <1349000469.75.0.229872855541.issue11770@psf.upfronthosting.co.za> Changes by Tom Wardill : ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 12:24:12 2012 From: report at bugs.python.org (Tom Wardill) Date: Sun, 30 Sep 2012 10:24:12 +0000 Subject: [issue13476] Simple exclusion filter for unittest autodiscovery In-Reply-To: <1322186223.31.0.112270498917.issue13476@psf.upfronthosting.co.za> Message-ID: <1349000652.43.0.989408198101.issue13476@psf.upfronthosting.co.za> Changes by Tom Wardill : ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 12:57:46 2012 From: report at bugs.python.org (Peter Inglesby) Date: Sun, 30 Sep 2012 10:57:46 +0000 Subject: [issue16055] incorrect error text for int(base=1000, x='1') In-Reply-To: <1348688461.13.0.427927679227.issue16055@psf.upfronthosting.co.za> Message-ID: <1349002666.26.0.191227797616.issue16055@psf.upfronthosting.co.za> Peter Inglesby added the comment: Ok, I've now attached a patch with tests. ---------- Added file: http://bugs.python.org/file27353/issue16055-fix-with-tests.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 12:59:03 2012 From: report at bugs.python.org (Christian Heimes) Date: Sun, 30 Sep 2012 10:59:03 +0000 Subject: [issue16089] _elementtree causes segfault in GC In-Reply-To: <1348970862.81.0.736695242293.issue16089@psf.upfronthosting.co.za> Message-ID: <1349002743.66.0.940127455155.issue16089@psf.upfronthosting.co.za> Christian Heimes added the comment: No, it doesn't make a difference when I replace Py_XDECREF() with Py_CLEAR(). I've also replaced Py_(X)DECREF() in the other *_gc_clear() methods without success. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 13:02:39 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sun, 30 Sep 2012 11:02:39 +0000 Subject: [issue8800] add threading.RWLock In-Reply-To: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za> Message-ID: <1349002959.22.0.918956447587.issue8800@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Yes, any "blocking" on the internal lock is not semantic blocking due to the use of the Shared lock itself, but merely a technical aspect, not semantically visible to the program. It is equivalent to the operating system pausing the thread, a techical detail opaque to the user program and somethign it cannot affect or influence. "Blocking" in the sense of the lock is due to the semantic use of the lock itself and the resources that it protects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 13:07:12 2012 From: report at bugs.python.org (GlitchMr) Date: Sun, 30 Sep 2012 11:07:12 +0000 Subject: [issue16094] Tuple extraction in lambda isn't supported with more than one argument Message-ID: <1349003232.56.0.742514252911.issue16094@psf.upfronthosting.co.za> New submission from GlitchMr: Tuple extraction in lambda isn't supported with more than one argument. ---------- components: 2to3 (2.x to 3.x conversion tool) files: lambda.py messages: 171627 nosy: GlitchMr priority: normal severity: normal status: open title: Tuple extraction in lambda isn't supported with more than one argument versions: Python 2.7 Added file: http://bugs.python.org/file27354/lambda.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 13:16:09 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Sun, 30 Sep 2012 11:16:09 +0000 Subject: [issue16034] bz2 module appears slower in Python 3.x versus Python 2.x In-Reply-To: <1348547973.67.0.489000428853.issue16034@psf.upfronthosting.co.za> Message-ID: <1349003769.09.0.435194952922.issue16034@psf.upfronthosting.co.za> Nadeem Vawda added the comment: > Yes, of course. Awesome. I plan to do a new release for this in the next couple of days. > We can even speed up 1.5 times the reading of small chunks, if we inline _check_can_read() and _read_block(). Interesting idea, but I don't think it's worthwhile. It looks like this is only a noticeable improvement if size is 10 or 1, and I don't think these are common cases (especially not for users who care about performance). Also, I'm reluctant to have two copies of the code for _read_block(); it makes the code harder to read, and increases the chance of introducing a bug when changing the code. > The same approach is applied for LZMAFile. Of course. I'll apply these optimizations to LZMAFile next weekend. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 13:17:19 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 30 Sep 2012 11:17:19 +0000 Subject: [issue16089] _elementtree causes segfault in GC In-Reply-To: <1348970862.81.0.736695242293.issue16089@psf.upfronthosting.co.za> Message-ID: <1349003839.71.0.623581529136.issue16089@psf.upfronthosting.co.za> Stefan Krah added the comment: I'm now able to reproduce the issue with a non-debug build. As Christian says, using Py_CLEAR() does not help (though I wonder if it shouldn't be used anyway). Reverting part of 20b8f0ee3d64 "fixes" the segfault, see the attached diff. I don't know the code well enough to say if this is a valid possibility. ---------- keywords: +patch Added file: http://bugs.python.org/file27355/issue16089-pseudo-fix.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 13:35:00 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 30 Sep 2012 11:35:00 +0000 Subject: [issue16089] _elementtree causes segfault in GC In-Reply-To: <1348970862.81.0.736695242293.issue16089@psf.upfronthosting.co.za> Message-ID: <1349004900.54.0.643501055056.issue16089@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 13:45:28 2012 From: report at bugs.python.org (Christian Heimes) Date: Sun, 30 Sep 2012 11:45:28 +0000 Subject: [issue16089] _elementtree causes segfault in GC In-Reply-To: <1348970862.81.0.736695242293.issue16089@psf.upfronthosting.co.za> Message-ID: <1349005528.06.0.433995498573.issue16089@psf.upfronthosting.co.za> Christian Heimes added the comment: I can confirm that Stefan's fix works. I ran the SimpleTAL test suite about hundred times in a loop without a segfault. But I don't understand why the change fixes the issue. Could the alteration just lead to another code path so the erroneous code isn't triggered? +1 for Py_CLEAR() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 13:52:21 2012 From: report at bugs.python.org (Cemal Duman) Date: Sun, 30 Sep 2012 11:52:21 +0000 Subject: [issue15862] IDLE not working when due to wrong Hard Drive point of os.path.expanduser In-Reply-To: <1346795014.76.0.789021764596.issue15862@psf.upfronthosting.co.za> Message-ID: <1349005941.41.0.771283629924.issue15862@psf.upfronthosting.co.za> Cemal Duman added the comment: Hi, yes exactly... I changed my home by using below commands. C:\Python27>set HOME=C:\ C:\Python27>python -m idlelib.idle it is working. But if i reboot my computer HOME changes again to network drive. I think sth abour corporate programs rewrites this paramters. Thanks / Cemal ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 14:37:14 2012 From: report at bugs.python.org (mani and ram) Date: Sun, 30 Sep 2012 12:37:14 +0000 Subject: [issue16090] but is needed somewhere in http://www.python.org/dev/peps/pep-3138/ In-Reply-To: <1348988173.8.0.622214647382.issue16090@psf.upfronthosting.co.za> Message-ID: mani and ram added the comment: When I find it I will open it. On 30 September 2012 12:26, Georg Brandl wrote: > > Georg Brandl added the comment: > > I've gone through the PEP; I've found a few typos and fixed them, but no > missing "but". Sorry, but without a more specific location I don't think > it's sensible to keep this open. > > ---------- > nosy: +georg.brandl > resolution: -> fixed > status: open -> closed > > _______________________________________ > Python tracker > > _______________________________________ > ---------- nosy: +maniandram _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 14:46:57 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Sun, 30 Sep 2012 12:46:57 +0000 Subject: [issue16090] but is needed somewhere in http://www.python.org/dev/peps/pep-3138/ In-Reply-To: <1348975400.05.0.784015887596.issue16090@psf.upfronthosting.co.za> Message-ID: <1349009217.1.0.0852244923062.issue16090@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Somehow my name is displayed as "mani and ram" when replying by email (I changed my email name from that to "Ramchandra Apte") Just so that you know that "mani and ram" is the same person as "Ramchandra Apte" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 14:47:48 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Sun, 30 Sep 2012 12:47:48 +0000 Subject: [issue16090] but is needed somewhere in http://www.python.org/dev/peps/pep-3138/ In-Reply-To: <1348975400.05.0.784015887596.issue16090@psf.upfronthosting.co.za> Message-ID: <1349009268.46.0.138209375388.issue16090@psf.upfronthosting.co.za> Changes by Ramchandra Apte : ---------- resolution: fixed -> postponed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 15:03:24 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Sun, 30 Sep 2012 13:03:24 +0000 Subject: [issue16094] Tuple extraction in lambda isn't supported with more than one argument In-Reply-To: <1349003232.56.0.742514252911.issue16094@psf.upfronthosting.co.za> Message-ID: <1349010204.8.0.544924995039.issue16094@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Python 2.7 and earlier are in bug-fix mode (means no new features) Tuple unpacking is not there in Python 3. Please close this bug as invalid. ---------- nosy: +ramchandra.apte type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 15:08:56 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 30 Sep 2012 13:08:56 +0000 Subject: [issue16094] Tuple extraction in lambda isn't supported with more than one argument In-Reply-To: <1349003232.56.0.742514252911.issue16094@psf.upfronthosting.co.za> Message-ID: <1349010536.33.0.250542387603.issue16094@psf.upfronthosting.co.za> Mark Dickinson added the comment: Works for me (Python 2.7.3): >>> x = lambda (a, b), c: a + b + c >>> x((2, 3), 4) 9 What issue are you seeing? ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 15:20:37 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 30 Sep 2012 13:20:37 +0000 Subject: [issue16094] Tuple extraction in lambda isn't supported with more than one argument In-Reply-To: <1349003232.56.0.742514252911.issue16094@psf.upfronthosting.co.za> Message-ID: <1349011237.1.0.195153782457.issue16094@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The issue is in lib2to3. tuple_params does not work with lambdas. I confirm the bug. $ ./python -m lib2to3 -f tuple_params lambda_tuple_params.py RefactoringTool: Refactored lambda_tuple_params.py --- lambda_tuple_params.py (original) +++ lambda_tuple_params.py (refactored) @@ -1,3 +1,3 @@ lambda (a, b), c: a + b + c -def f((a, b), c): return a + b + c +def f(xxx_todo_changeme, c): (a, b) = xxx_todo_changeme; return a + b + c RefactoringTool: Files that need to be modified: RefactoringTool: lambda_tuple_params.py ---------- nosy: +benjamin.peterson, storchaka stage: -> needs patch type: enhancement -> behavior versions: +Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file27356/lambda_tuple_params.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 15:35:32 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 30 Sep 2012 13:35:32 +0000 Subject: [issue16034] bz2 module appears slower in Python 3.x versus Python 2.x In-Reply-To: <1348547973.67.0.489000428853.issue16034@psf.upfronthosting.co.za> Message-ID: <1349012132.46.0.20386050874.issue16034@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Also, I'm reluctant to have two copies of the code for _read_block(); it makes the code harder to read, and increases the chance of introducing a bug when changing the code. Recursive inline _check_can_read() will be enough. Now this check calls 4 Python functions (_check_can_read(), readable(), _check_non_closed(), closed). Recursive inlining only readable() in _check_can_read() is achieved significant but less (about 30%) effect. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 15:47:21 2012 From: report at bugs.python.org (Sam Breese) Date: Sun, 30 Sep 2012 13:47:21 +0000 Subject: [issue15812] inspect.getframeinfo() cannot show first line In-Reply-To: <1346252079.7.0.669819400342.issue15812@psf.upfronthosting.co.za> Message-ID: <1349012841.64.0.285641545171.issue15812@psf.upfronthosting.co.za> Sam Breese added the comment: Looking into this now. Should have a patch either later today or tommorow. ---------- nosy: +Sam.Breese _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 16:00:26 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 30 Sep 2012 14:00:26 +0000 Subject: [issue8800] add threading.RWLock In-Reply-To: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za> Message-ID: <1349013626.57.0.524502900149.issue8800@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > I've added a new patch, that implements a shared/exclusive lock as > described in my comments above, for the threading and multiprocessing > module. The patch does not seem to touch the threading mode and does not come with tests. I doubt the multiprocessing version is actually picklable since self._requirement is a lambda function. Also it would be best to avoid making multiprocessing.synchronize depend on ctypes. (See implementation of multiprocessing.Barrier or Issue #14953.) Personally, I would prefer to make the shared and exclusive locks attributes of the same object, so one could do with selock.shared: ... with selock.exclusive: ... ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 16:02:46 2012 From: report at bugs.python.org (Sam Breese) Date: Sun, 30 Sep 2012 14:02:46 +0000 Subject: [issue15812] inspect.getframeinfo() cannot show first line In-Reply-To: <1346252079.7.0.669819400342.issue15812@psf.upfronthosting.co.za> Message-ID: <1349013766.07.0.839525892459.issue15812@psf.upfronthosting.co.za> Sam Breese added the comment: Also, would you mind posting an example? I'm having trouble replicating. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 16:16:12 2012 From: report at bugs.python.org (Sam Breese) Date: Sun, 30 Sep 2012 14:16:12 +0000 Subject: [issue15812] inspect.getframeinfo() cannot show first line In-Reply-To: <1346252079.7.0.669819400342.issue15812@psf.upfronthosting.co.za> Message-ID: <1349014572.64.0.0867780553653.issue15812@psf.upfronthosting.co.za> Sam Breese added the comment: Nevermind, replicated it. Changing start = max(start, 1) to start = max(start, 0) DOES fix. Writing a test case now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 16:39:05 2012 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 30 Sep 2012 14:39:05 +0000 Subject: [issue16089] _elementtree causes segfault in GC In-Reply-To: <1348970862.81.0.736695242293.issue16089@psf.upfronthosting.co.za> Message-ID: <1349015945.78.0.0058176046043.issue16089@psf.upfronthosting.co.za> Eli Bendersky added the comment: I'm currently somewhat "offline" for a while (cross-continental move), but I'll do my best to try to recreate my setup to test this problem and the proposed solution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 16:52:12 2012 From: report at bugs.python.org (Sam Breese) Date: Sun, 30 Sep 2012 14:52:12 +0000 Subject: [issue15812] inspect.getframeinfo() cannot show first line In-Reply-To: <1346252079.7.0.669819400342.issue15812@psf.upfronthosting.co.za> Message-ID: <1349016732.0.0.244237450427.issue15812@psf.upfronthosting.co.za> Sam Breese added the comment: Here's a patch. Very, very simple, just changed that one line in inspect.py and wrote a highly primitive test case for inspect.getframeinfo. The test isn't actually testing the primary functionality right now, just this one bug. I can probably write more expansive coverage later, but in the interest of an expeditious reply I'm submitting now. ---------- keywords: +patch Added file: http://bugs.python.org/file27357/inspect_getframeinfo_line1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 16:55:51 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 30 Sep 2012 14:55:51 +0000 Subject: [issue16089] _elementtree causes segfault in GC In-Reply-To: <1348970862.81.0.736695242293.issue16089@psf.upfronthosting.co.za> Message-ID: <1349016951.9.0.685289346596.issue16089@psf.upfronthosting.co.za> Stefan Krah added the comment: Do note that the patch is somewhat cargo-cult. I don't understand yet why it works; it may very well just silence the real problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 17:25:25 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 30 Sep 2012 15:25:25 +0000 Subject: [issue16055] incorrect error text for int(base=1000, x='1') In-Reply-To: <1348688461.13.0.427927679227.issue16055@psf.upfronthosting.co.za> Message-ID: <1349018725.31.0.221940801894.issue16055@psf.upfronthosting.co.za> Chris Jerdonek added the comment: A few comments on the patch: 1) You should also check the exception type (e.g. by using PyErr_ExceptionMatches()). 2) If the exception doesn't match, you should restore the original exception so that the pure Python test framework will in turn raise it and the caller can inspect it. Currently, the caller will find out only that it doesn't match but not why. Take a look at CHECK_INVALID() to see an example of this pattern being used. 3) I would expose the functionality that checks an exception's type and text as a helper function so that it can be used throughout _testcapimodule.c. The function is nontrivial enough that we wouldn't want to be copying and pasting it throughout if we want to check exception texts for other parts of the C API. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 17:44:10 2012 From: report at bugs.python.org (Mike Hoy) Date: Sun, 30 Sep 2012 15:44:10 +0000 Subject: [issue9650] format codes in time.strptime docstrings In-Reply-To: <1282319380.5.0.724924373031.issue9650@psf.upfronthosting.co.za> Message-ID: <1349019850.85.0.902773911796.issue9650@psf.upfronthosting.co.za> Mike Hoy added the comment: Changed docstring for timemodule.c to include format codes listed here: http://bugs.python.org/msg169193 ---------- keywords: +patch Added file: http://bugs.python.org/file27358/issue9650-format-codes.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 18:15:02 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 30 Sep 2012 16:15:02 +0000 Subject: [issue14503] docs: "yield from" breaks Pygments syntax coloring in doc examples In-Reply-To: <1333613053.66.0.675522025893.issue14503@psf.upfronthosting.co.za> Message-ID: <1349021702.05.0.438159750594.issue14503@psf.upfronthosting.co.za> Georg Brandl added the comment: I've updated the version of Pygments used by 3.3 and 3.4 branches, which fixes this and the "raise from" issue. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed versions: +Python 3.4 -Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 18:15:45 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 30 Sep 2012 16:15:45 +0000 Subject: [issue13801] The Python 3 Docs don't highlight nonlocal In-Reply-To: <1326720484.97.0.730349515473.issue13801@psf.upfronthosting.co.za> Message-ID: <1349021745.64.0.0208580427666.issue13801@psf.upfronthosting.co.za> Georg Brandl added the comment: Pygments is now updated to 1.5pre. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 18:33:08 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 30 Sep 2012 16:33:08 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1349022788.8.0.209925444879.issue15533@psf.upfronthosting.co.za> Chris Jerdonek added the comment: So it seems the cwd argument to Popen() currently works differently on Windows from Mac OS X. For example, the following doesn't work on Windows (but does on Mac). Windows doesn't look for arg0 relative to arg_cwd: def test_cwd(arg0, arg_cwd): os.chdir('foo') # Make sure we're in a different directory from arg0. p = subprocess.Popen([arg0, "-c", "import os, sys; " "sys.stdout.write(os.getcwd()); " "sys.exit(47)"], stdout=subprocess.PIPE, cwd=arg_cwd) p.wait() print("stdout: " + p.stdout.read().decode("utf-8")) print("return_code: %s" % p.returncode) python_path = os.path.realpath(sys.executable) python_dir, python_base = os.path.split(python_path) rel_python = os.path.join(os.curdir, python_base) # Raises: WindowsError: [Error 2] The system cannot find the file specified test_cwd(rel_python, python_dir) I'm going to mark the two tests as "skipped" on Windows pending a resolution. ---------- keywords: -easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 18:41:03 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 30 Sep 2012 16:41:03 +0000 Subject: [issue16094] Tuple extraction in a lambda isn't supported by 2to3 In-Reply-To: <1349003232.56.0.742514252911.issue16094@psf.upfronthosting.co.za> Message-ID: <1349023263.98.0.895336873863.issue16094@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- title: Tuple extraction in lambda isn't supported with more than one argument -> Tuple extraction in a lambda isn't supported by 2to3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 18:41:31 2012 From: report at bugs.python.org (Pietro Battiston) Date: Sun, 30 Sep 2012 16:41:31 +0000 Subject: [issue16095] urllib2 failing with squid proxy and digest authentication Message-ID: <1349023291.71.0.297566179231.issue16095@psf.upfronthosting.co.za> New submission from Pietro Battiston: If you run the following code: #! /usr/bin/python import urllib2 MyHTTPPasswordMgr = urllib2.HTTPPasswordMgr proxy = urllib2.ProxyHandler({'http': 'http://proxybiblio2.si.unimib.it:8080'}) auth = urllib2.ProxyDigestAuthHandler(MyHTTPPasswordMgr()) auth.add_password(None, "proxybiblio2.si.unimib.it", "a", "b" ) opener = urllib2.build_opener(proxy, auth, urllib2.HTTPHandler) urllib2.install_opener(opener) conn = urllib2.urlopen('http://webofknowledge.com') an "HTTP Error 407: Proxy Authentication Required" is raised, and under the hood here's what's happening: - the request is made without authentication - the server replies it must be made with digest authentication, and gives the nonce - the error is raised. Instead, urllib2 should now try to connect with the username and password, and do so up to 5 times (as hardcoded in urllib2.http_error_auth_reqed), and then raise a "HTTP Error 401: digest auth failed". And it's indeed what it does if you replace the line "MyHTTPPasswordMgr = urllib2.HTTPPasswordMgr" with class MyHTTPPasswordMgr(urllib2.HTTPPasswordMgr): def find_user_password(self, realm, authuri): return "a", "b" So the problem is in HTTPPasswordMgr, which is apparently unable to match the authentication data with the realm. Some tests? suggest that this can vary according to the proxy engine and to the proxy address format (works with apache, but doesn't if then you add "http://" in front of the proxy address). This reminds a bit bug 680577, and in particular I noticed that (possibly unrelated) the behaviour reported in the following message: http://bugs.python.org/msg14444 has not changed: In [1]: import urllib2 In [2]: urllib2.HTTPPasswordMgr().is_suburi("/foo/spam", "/foo/eggs")Out[2]: True This affects also python 3.2, you can try the following: #! /usr/bin/python from urllib import request MyHTTPPasswordMgr = request.HTTPPasswordMgr proxy = request.ProxyHandler({'http': 'http://proxybiblio2.si.unimib.it:8080'}) auth = request.ProxyDigestAuthHandler(MyHTTPPasswordMgr()) auth.add_password(None, "proxybiblio2.si.unimib.it", "a", "b" ) opener = request.build_opener(proxy, auth, request.HTTPHandler) request.install_opener(opener) conn = request.urlopen('http://webofknowledge.com') ? http://lists.python.it/pipermail/python/2012-September/013309.html (in Italian) ---------- components: Library (Lib) messages: 171650 nosy: toobaz priority: normal severity: normal status: open title: urllib2 failing with squid proxy and digest authentication type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 18:41:50 2012 From: report at bugs.python.org (Pietro Battiston) Date: Sun, 30 Sep 2012 16:41:50 +0000 Subject: [issue16095] urllib2 failing with squid proxy and digest authentication In-Reply-To: <1349023291.71.0.297566179231.issue16095@psf.upfronthosting.co.za> Message-ID: <1349023310.72.0.389819789688.issue16095@psf.upfronthosting.co.za> Changes by Pietro Battiston : ---------- versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 18:46:13 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 30 Sep 2012 16:46:13 +0000 Subject: [issue16082] xml.etree.ElementTree.tostringlist does conform to it's documentation In-Reply-To: <1348829487.02.0.837389148596.issue16082@psf.upfronthosting.co.za> Message-ID: <1349023573.05.0.201825630122.issue16082@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 18:46:21 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 30 Sep 2012 16:46:21 +0000 Subject: [issue16076] xml.etree.ElementTree.Element is no longer pickleable In-Reply-To: <1348822499.83.0.756048401766.issue16076@psf.upfronthosting.co.za> Message-ID: <1349023581.46.0.921736652006.issue16076@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 18:47:00 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 30 Sep 2012 16:47:00 +0000 Subject: [issue16094] Tuple extraction in a lambda isn't supported by 2to3 In-Reply-To: <1349003232.56.0.742514252911.issue16094@psf.upfronthosting.co.za> Message-ID: <1349023620.87.0.0283255806824.issue16094@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 18:47:27 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 30 Sep 2012 16:47:27 +0000 Subject: [issue16089] _elementtree causes segfault in GC In-Reply-To: <1348970862.81.0.736695242293.issue16089@psf.upfronthosting.co.za> Message-ID: <1349023647.86.0.428767630953.issue16089@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 18:49:14 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 30 Sep 2012 16:49:14 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <3XVCJT04XVzMtd@mail.python.org> Roundup Robot added the comment: New changeset d8d52b5b4bc2 by Chris Jerdonek in branch '3.2': Issue #15533: Skip test_cwd_with_relative_*() tests on Windows pending resolution of issue. http://hg.python.org/cpython/rev/d8d52b5b4bc2 New changeset 17d709f0b69b by Chris Jerdonek in branch '3.3': Issue #15533: Merge update from 3.2. http://hg.python.org/cpython/rev/17d709f0b69b New changeset d10a7c1ac3a7 by Chris Jerdonek in branch 'default': Issue #15533: Merge update from 3.3. http://hg.python.org/cpython/rev/d10a7c1ac3a7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 18:56:46 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 30 Sep 2012 16:56:46 +0000 Subject: [issue16007] Improved Error message for failing re expressions In-Reply-To: <1348416868.74.0.37879499143.issue16007@psf.upfronthosting.co.za> Message-ID: <1349024206.05.0.11091905825.issue16007@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 19:03:03 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 30 Sep 2012 17:03:03 +0000 Subject: [issue16009] Json error messages could provide more information about the error In-Reply-To: <1348420465.53.0.405036591258.issue16009@psf.upfronthosting.co.za> Message-ID: <1349024583.29.0.0467499562649.issue16009@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 19:03:44 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 30 Sep 2012 17:03:44 +0000 Subject: [issue16074] bad error message in os.rename In-Reply-To: <1348820000.8.0.496903200143.issue16074@psf.upfronthosting.co.za> Message-ID: <1349024624.75.0.34569450795.issue16074@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 19:07:28 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 30 Sep 2012 17:07:28 +0000 Subject: [issue9650] format codes in time.strptime docstrings In-Reply-To: <1282319380.5.0.724924373031.issue9650@psf.upfronthosting.co.za> Message-ID: <1349024848.89.0.210026289.issue9650@psf.upfronthosting.co.za> Ezio Melotti added the comment: The patch contains non-ascii apostrophes: s/Locale?s/Locale's/ ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 19:08:42 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 30 Sep 2012 17:08:42 +0000 Subject: [issue16095] urllib2 failing with squid proxy and digest authentication In-Reply-To: <1349023291.71.0.297566179231.issue16095@psf.upfronthosting.co.za> Message-ID: <1349024922.14.0.39722937027.issue16095@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- assignee: -> orsenthil nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 19:19:07 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sun, 30 Sep 2012 17:19:07 +0000 Subject: [issue8800] add threading.RWLock In-Reply-To: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za> Message-ID: <1349025547.74.0.0202692057577.issue8800@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: I can't say that I'm that familiar with multiprocessing to comment on that in particular. But I do find your approach strange, to create two "lock-like" objects, in stead of the more familiar construct of having a "RWLock" (this is known from other languages) with two ways of claiming it. Attached is a new patch. I've adopted the name "SharableLock" perhaps it is bad. It uses your idea of returning "lock-like" objects that do either shared or exclusive locking. There are two implementations: SharableLock is much like the original patch, with two conditions and writer priority. SimpleSharableLock drops all that, and uses a single condition and ad-hoc priority. I've added unittests that show that writer-starvation does not appear to be a problem. Createing a Multiprocessing lock using the SharableLockBase should pose no difficulties. The use of the SharableLock with Condition objects is forced to be Exclusive, since Condition objects typcially rely on their associated lock to synchronize internal state. ---------- Added file: http://bugs.python.org/file27359/sharablelock.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 19:20:11 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 30 Sep 2012 17:20:11 +0000 Subject: [issue14783] Make int() and str() docstrings correct In-Reply-To: <1336751413.58.0.519130225761.issue14783@psf.upfronthosting.co.za> Message-ID: <1349025611.93.0.415251351026.issue14783@psf.upfronthosting.co.za> Chris Jerdonek added the comment: The change for issue 15831 contains a number of places where a single signature line was converted to multiple -- but in the docs and not the docstrings. Those instances can also be examined for this issue. The signature line for str() was not updated in that patch, however. ---------- stage: commit review -> needs patch versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 20:28:31 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 30 Sep 2012 18:28:31 +0000 Subject: [issue16086] tp_flags: Undefined behaviour with 32 bits long In-Reply-To: <1348934655.6.0.704339106877.issue16086@psf.upfronthosting.co.za> Message-ID: <1349029711.63.0.375874281636.issue16086@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, I'm not Martin, but I'll try to answer. An ABI pertains to the interfaces exposed by compiled object code, not source code. With C, function signatures in compiled code don't keep any type information (*), and they obviously doesn't know about macros either. So I'd answer "No" to both questions :-) (*) it would be different with C++, because of name mangling ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 20:30:11 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 30 Sep 2012 18:30:11 +0000 Subject: [issue13028] python wastes linux users time by checking for dylib on each dynamic library load In-Reply-To: <1316717807.43.0.635056141333.issue13028@psf.upfronthosting.co.za> Message-ID: <1349029811.17.0.467724376645.issue13028@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Which was the command run under strace exactly? ---------- nosy: +brett.cannon, ncoghlan, pitrou versions: +Python 3.4 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 20:34:11 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 30 Sep 2012 18:34:11 +0000 Subject: [issue16096] Get rid of dangerous integer overflow tricks Message-ID: <1349030051.26.0.323672452753.issue16096@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: In several places such dungerous code used to check the integer overflow: size = n *?itemsize; if (size / itemsize != n) raise exception... Because these values are signed, this results in undefined behavior. The proposed patches replace similar unsafe code to safe one. Note that the patches for the different versions are substantially different. ---------- components: Extension Modules, Interpreter Core files: size_overflow-3.3.patch keywords: patch messages: 171657 nosy: mark.dickinson, storchaka priority: normal severity: normal status: open title: Get rid of dangerous integer overflow tricks type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file27360/size_overflow-3.3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 20:34:50 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 30 Sep 2012 18:34:50 +0000 Subject: [issue16096] Get rid of dangerous integer overflow tricks In-Reply-To: <1349030051.26.0.323672452753.issue16096@psf.upfronthosting.co.za> Message-ID: <1349030090.44.0.91826547128.issue16096@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file27361/size_overflow-3.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 20:35:34 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 30 Sep 2012 18:35:34 +0000 Subject: [issue16096] Get rid of dangerous integer overflow tricks In-Reply-To: <1349030051.26.0.323672452753.issue16096@psf.upfronthosting.co.za> Message-ID: <1349030134.63.0.449069924703.issue16096@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file27362/size_overflow-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 20:36:51 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 30 Sep 2012 18:36:51 +0000 Subject: [issue16049] Create abstract base classes by inheritance rather than a direct invocation of __metaclass__ In-Reply-To: <1348615231.16.0.514985949274.issue16049@psf.upfronthosting.co.za> Message-ID: <1349030211.5.0.285277576981.issue16049@psf.upfronthosting.co.za> Antoine Pitrou added the comment: It looks slightly better, but it would also violate "there is one obvious way to do it". ---------- nosy: +gvanrossum, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 20:40:17 2012 From: report at bugs.python.org (Sebastian Noack) Date: Sun, 30 Sep 2012 18:40:17 +0000 Subject: [issue8800] add threading.RWLock In-Reply-To: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za> Message-ID: <1349030417.43.0.125540679322.issue8800@psf.upfronthosting.co.za> Sebastian Noack added the comment: I was just waiting for a comment pointing out, that my patch comes without tests. :) Note that we are still discussing the implementation and this patch is just a proof of concept. And since the way it is implemented and the API it provides could still change, its quite pointless to write tests, until we at least agreed on the API. I have uploaded a new patch. The way it is implemented now, is more like the Barrier is implemented. The common code is shared in the threading module and the shared/exclusive lock objects can be pickled now. I have also fixed a bug related to acquiring locks in non-blocking mode. However the code still uses c_uint, but ctypes (and multiprocessing.sharedtypes) is only imported when ShrdExclLock is called. So it is just a lazy dependency, now. However the reason why I am using ctypes instead of python integers for threading and a BufferWrapper for multiprocessing (as the Barrier does) is, because of 2 of the 4 counters need to be continuously incremented, and c_uint has the nice feature that it can overflow, in contrast to python integers and integers in arrays. Also that way the implementation is simpler and it seems that there isn't much difference under the hood between using BufferWrapper() and RawValue(). A shared/exclusive lock isn't one lock but two locks, which are synchronized, but must be acquired separately. Similar to a pipe, which isn't one file, but one file connected to another file that reads whatever you have written into the first file. So it isn't strange to create two lock objects, as it also isn't strange that os.pipe() returns two file descriptors. Also having a separate lock object for the shared and exclusive lock, each providing the same API (as Lock and RLock), gives you huge flexibility. You can acquire both locks using the with statement or pass them separately around. So for example when you have a function, thread or child process, that should only be able to acquire either the shared or the exclusive lock, you don't have to pass both locks. That also means that existing code that expects a lock-like object will be compatible with both the shared and exclusive lock. ---------- Added file: http://bugs.python.org/file27363/Added-ShrdExclLock-to-threading-and-multiprocessing-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 21:04:20 2012 From: report at bugs.python.org (Mike Hoy) Date: Sun, 30 Sep 2012 19:04:20 +0000 Subject: [issue9650] format codes in time.strptime docstrings In-Reply-To: <1282319380.5.0.724924373031.issue9650@psf.upfronthosting.co.za> Message-ID: <1349031860.83.0.976353016194.issue9650@psf.upfronthosting.co.za> Mike Hoy added the comment: Updated patch as per Ezio's comment. ---------- Added file: http://bugs.python.org/file27364/issue9650-format-codes_v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 21:28:03 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 30 Sep 2012 19:28:03 +0000 Subject: [issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0 In-Reply-To: <1344473974.14.0.584788696764.issue15599@psf.upfronthosting.co.za> Message-ID: <1349033283.42.0.346939940106.issue15599@psf.upfronthosting.co.za> Stefan Krah added the comment: For once a Linux bot shows the failure that is the topic of this issue: http://buildbot.python.org/all/builders/x86%20Gentoo%20Non-Debug%203.x/builds/3101/steps/test/logs/stdio ====================================================================== FAIL: test_circular_imports (test.test_threaded_import.ThreadedImportTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/test_threaded_import.py", line 205, in test_circular_imports self.assertEqual(set(results), {'a', 'b'}) AssertionError: Items in the second set but not the first: 'b' 'a' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 21:30:40 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 30 Sep 2012 19:30:40 +0000 Subject: [issue14783] Make int() and str() docstrings correct In-Reply-To: <1336751413.58.0.519130225761.issue14783@psf.upfronthosting.co.za> Message-ID: <1349033440.04.0.51852383154.issue14783@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > So (a) there is precedent for multiple signatures in docstrings For the record, this is also true of 2.7: http://hg.python.org/cpython/file/15fd0b4496e0/Objects/bytearrayobject.c#l2870 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 21:45:54 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 30 Sep 2012 19:45:54 +0000 Subject: [issue9674] make install DESTDIR=/home/blah fails when the prefix specified is / In-Reply-To: <1282677588.85.0.771807305266.issue9674@psf.upfronthosting.co.za> Message-ID: <1349034354.64.0.929406628608.issue9674@psf.upfronthosting.co.za> ?ric Araujo added the comment: A unit test is needed. ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 21:49:05 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 30 Sep 2012 19:49:05 +0000 Subject: [issue15801] Weird string interpolation behaviour In-Reply-To: <1346187982.17.0.733777939563.issue15801@psf.upfronthosting.co.za> Message-ID: <3XVHJ04WFqzQgB@mail.python.org> Roundup Robot added the comment: New changeset 8f07ab82de92 by Ezio Melotti in branch '2.7': #15923: fix a mistake in asdl_c.py that resulted in a TypeError after 2801bf875a24 (see #15801). http://hg.python.org/cpython/rev/8f07ab82de92 New changeset cb988d601803 by Ezio Melotti in branch '3.2': #15923: fix a mistake in asdl_c.py that resulted in a TypeError after 2801bf875a24 (see #15801). http://hg.python.org/cpython/rev/cb988d601803 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 21:49:06 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 30 Sep 2012 19:49:06 +0000 Subject: [issue15923] Building from a fresh clone breaks on Parser/asdl_c.py In-Reply-To: <1347398039.31.0.775610002592.issue15923@psf.upfronthosting.co.za> Message-ID: <3XVHJ12xwnzQbv@mail.python.org> Roundup Robot added the comment: New changeset 8f07ab82de92 by Ezio Melotti in branch '2.7': #15923: fix a mistake in asdl_c.py that resulted in a TypeError after 2801bf875a24 (see #15801). http://hg.python.org/cpython/rev/8f07ab82de92 New changeset cb988d601803 by Ezio Melotti in branch '3.2': #15923: fix a mistake in asdl_c.py that resulted in a TypeError after 2801bf875a24 (see #15801). http://hg.python.org/cpython/rev/cb988d601803 New changeset e7a55a393a80 by Ezio Melotti in branch '3.3': #15923: merge with 3.2. http://hg.python.org/cpython/rev/e7a55a393a80 New changeset b392a39970bb by Ezio Melotti in branch 'default': #15923: merge with 3.3. http://hg.python.org/cpython/rev/b392a39970bb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 21:54:05 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 30 Sep 2012 19:54:05 +0000 Subject: [issue15923] Building from a fresh clone breaks on Parser/asdl_c.py In-Reply-To: <1347398039.31.0.775610002592.issue15923@psf.upfronthosting.co.za> Message-ID: <1349034845.79.0.514677888101.issue15923@psf.upfronthosting.co.za> Ezio Melotti added the comment: This is now fixed. self.emit("default:" % name, 2) worked until #15801 got fixed, Since asdl_c.py is executed using the system Python, this was failing only when the system Python included the fix. ---------- assignee: -> ezio.melotti components: +Build nosy: +ezio.melotti resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> behavior versions: +Python 2.7, Python 3.2, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 21:55:19 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sun, 30 Sep 2012 19:55:19 +0000 Subject: [issue8800] add threading.RWLock In-Reply-To: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za> Message-ID: <1349034919.24.0.79435220317.issue8800@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: >A shared/exclusive lock isn't one lock but two locks, which are >synchronized, but must be acquired separately. Similar to a pipe, >which isn't one file, but one file connected to another file that >reads whatever you have written into the first file. So it isn't >strange to create two lock objects, as it also isn't strange that >os.pipe() returns two file descriptors That's one way to look at it. Another (and the more common) is to say that it is one lock, which can be in two different states. The original patch is modeled on seveal such constructs that exist in the field, such as for example the SRW locks in windows: http://msdn.microsoft.com/en-us/library/windows/desktop/aa904937(v=vs.85).aspx (In fact, I am rather leaning back towards the RWLock name again, since that seems to be the most commonly used on other platforms. Oh, how tempting it is to bikeshed about such trivialities.) Note that in my last patch, I provide the exclusive_locked() and shared_locked() methods that return exactly such locks as you describe. I'd much rather have a single RW Lock object, with retgular locking proxies, rather than two distinct object, attached only by some shared common variables. Also, with the structured approach I suggest, you can relatively easily create such a lock that also works across process boundaries by implementing a concrete class with SharableLockBase as a base. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 22:07:35 2012 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 30 Sep 2012 20:07:35 +0000 Subject: [issue16049] Create abstract base classes by inheritance rather than a direct invocation of __metaclass__ In-Reply-To: <1349030211.5.0.285277576981.issue16049@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: In practice this is indeed how most users of met a classes do it. E.g. Django. So, +1. --Guido van Rossum (sent from Android phone) On Sep 30, 2012 11:36 AM, "Antoine Pitrou" wrote: > > Antoine Pitrou added the comment: > > It looks slightly better, but it would also violate "there is one obvious > way to do it". > > ---------- > nosy: +gvanrossum, pitrou > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 22:10:50 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 30 Sep 2012 20:10:50 +0000 Subject: [issue8800] add threading.RWLock In-Reply-To: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za> Message-ID: <1349035850.1.0.773756049578.issue8800@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, since we're bikeshedding, I like Richard's proposal best: > Personally, I would prefer to make the shared and exclusive locks > attributes of the same object, so one could do > > with selock.shared: > ... > > with selock.exclusive: > ... Please note, the "same object" could simply be a namedtuple instance. Also I think "shared/exclusive" indeed conveys the semantics better than "read/write". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 22:15:14 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 30 Sep 2012 20:15:14 +0000 Subject: [issue13028] python wastes linux users time by checking for dylib on each dynamic library load In-Reply-To: <1316717807.43.0.635056141333.issue13028@psf.upfronthosting.co.za> Message-ID: <1349036114.29.0.305214854868.issue13028@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 22:30:08 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 30 Sep 2012 20:30:08 +0000 Subject: [issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0 In-Reply-To: <1349033283.42.0.346939940106.issue15599@psf.upfronthosting.co.za> Message-ID: <1349036939.3381.2.camel@localhost.localdomain> Antoine Pitrou added the comment: > For once a Linux bot shows the failure that is the topic of this > issue: Hmm, so there may be a small race condition after all? The problem is that I can't reproduce, on a non-debug build as on that buildbot, after more than 43000 (!) test runs. Either this failure is incredibly sporadic, or it needs certain conditions my system doesn't meet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 22:35:56 2012 From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=) Date: Sun, 30 Sep 2012 20:35:56 +0000 Subject: [issue16081] Fix compile warnings in thread_pthread.h In-Reply-To: <1348829357.7.0.760845781586.issue16081@psf.upfronthosting.co.za> Message-ID: <1349037356.26.0.907679704908.issue16081@psf.upfronthosting.co.za> Michele Orr? added the comment: That's ok for me. Tested with OSX 10.8 and clang. ---------- nosy: +maker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 22:37:53 2012 From: report at bugs.python.org (Brian Brazil) Date: Sun, 30 Sep 2012 20:37:53 +0000 Subject: [issue16081] Fix compile warnings in thread_pthread.h In-Reply-To: <1348829357.7.0.760845781586.issue16081@psf.upfronthosting.co.za> Message-ID: <1349037473.15.0.310102186361.issue16081@psf.upfronthosting.co.za> Brian Brazil added the comment: I'm on gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, this was the only warning I saw (though I don't have all the optional libraries installed). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 22:54:39 2012 From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=) Date: Sun, 30 Sep 2012 20:54:39 +0000 Subject: [issue1052827] filelist.findall should not fail on dangling symlinks Message-ID: <1349038479.68.0.182324176932.issue1052827@psf.upfronthosting.co.za> Changes by Michele Orr? : ---------- nosy: +maker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 23:00:11 2012 From: report at bugs.python.org (Chris Rebert) Date: Sun, 30 Sep 2012 21:00:11 +0000 Subject: [issue9650] format codes in time.strptime docstrings In-Reply-To: <1282319380.5.0.724924373031.issue9650@psf.upfronthosting.co.za> Message-ID: <1349038811.52.0.234832639568.issue9650@psf.upfronthosting.co.za> Chris Rebert added the comment: I'm going to bikeshed and again suggest that %I and %p be included for handling 12-hour clock times. Also, the patch seems to only be for strftime(), and not strptime(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 23:00:32 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 30 Sep 2012 21:00:32 +0000 Subject: [issue8800] add threading.RWLock In-Reply-To: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za> Message-ID: <1349038832.54.0.527105445086.issue8800@psf.upfronthosting.co.za> Richard Oudkerk added the comment: @Sebastian: Both your patch sets are missing the changes to threading.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 23:12:33 2012 From: report at bugs.python.org (Roger Serwy) Date: Sun, 30 Sep 2012 21:12:33 +0000 Subject: [issue15862] IDLE not working when due to wrong Hard Drive point of os.path.expanduser In-Reply-To: <1346795014.76.0.789021764596.issue15862@psf.upfronthosting.co.za> Message-ID: <1349039553.3.0.255872957502.issue15862@psf.upfronthosting.co.za> Roger Serwy added the comment: In your original message, did IDLE eventually start when you ran: C:\Python27>python.exe Lib\idlelib\idle.py ? If yes, then the bug is likely due to issue13582. If I understand correctly, when you reboot your computer, IDLE won't launch from the shortcut in the start menu? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 30 23:44:27 2012 From: report at bugs.python.org (Mike Hoy) Date: Sun, 30 Sep 2012 21:44:27 +0000 Subject: [issue9650] format codes in time.strptime docstrings In-Reply-To: <1282319380.5.0.724924373031.issue9650@psf.upfronthosting.co.za> Message-ID: <1349041467.26.0.249541242267.issue9650@psf.upfronthosting.co.za> Mike Hoy added the comment: New patch includes time.strptime and the additional changes suggested by Chris Rebert. ---------- Added file: http://bugs.python.org/file27365/issue9650-format-codes_v3.diff _______________________________________ Python tracker _______________________________________